Evaluación de software y procesos de desarrollo

ESCUELA DE CIENCIAS BASICAS TECNOLOGIA E INGENIERIA
MDULO EVALUACIN DE SOFTWARE Cdigo del Curso: 301569

Francisco Nicols Javier Solarte Solarte
francisco.solarte@unad.edu.co solartefrancisco@gmail.com 2010
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD 2 ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA - ECBTI CURSO DE EVALUACIN DE SOFTWARE - CDIGO 301569__________________________________________
TABLA DE CONTENIDO UNIDAD 1. PROCESO DE DESARROLLO DE SOFTWARE Capitulo 1 CICLO DE VIDA PARA PRODUCTOS SOFTWARE Leccin 1 Conceptos Generales sobre ciclos de vida Leccin 2 Ciclos de vida tradicionales Leccin 3 Ciclos de vida alternativos Leccin 4 Modelos de proceso de produccin de software Leccin 5 Ciclos de vida giles Capitulo 2 DESARROLLO DE SOFTWARE Leccin 1 Procesos de Gestin del Proyecto Leccin 2 Procesos de Pre-desarrrollo Leccin 3 Procesos de Desarrollo Leccin 4 Procesos de Post-Desarrollo Leccin 5 Procesos Integrales del Proyecto Capitulo 3 CONCEPTOS DE CALIDAD Y CALIDAD DEL SOFTWARE Leccin 1 Definicin de Calidad Leccin 2 Sistemas de Calidad en la empresa Leccin 3 Normatividad de Calidad Leccin 4 Ingeniera de Software y Calidad Leccin 5 Gestin de la Calidad del Software UNIDAD 2. ESTNDARES, METRICAS DE CALIDAD Y PRUEBAS DEL SOFTWARE Capitulo 4 Calidad del Software Leccin 1 La Calidad del Software Leccin 2 Calidad del Producto Software Norma ISO/IEC 9126 Leccin 3 Calidad del Producto software Norma ISO/IEC 14598 Leccin 4 Calidad del Producto Software Norma ISO/IEC 25000 (SquaRE) Leccin 5 Modelos de Mejora de Procesos de Software Capitulo 5 MTRICAS DE CALIDAD DEL SOFTWARE Leccin 1 Conceptos Bsicos de Mtricas Leccin 2 Mtricas del Software Leccin 3 Mtricas de Calidad del Software Leccin 4 Mtricas Tcnicas del Software Leccin 5 Estructura para las Mtricas de Calidad del software Capitulo 6 PRUEBAS DEL SOFTWARE Leccin 1 La Prueba del software Leccin 2 Tcnicas de diseo de Casos de Prueba Leccin 3 Estrategias de Aplicacin de Pruebas del Software Leccin 4 Pruebas de Software para Objetos Leccin 5 Pruebas de Software Basado en Componentes UNIDAD 3. EVALUACIN DE SOFTWARE Capitulo 7 METODOLOGA TCNICA PARA LA EVALUACIN 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
Leccin 1 Leccin 2 Leccin 3 Leccin 4 Leccin 5 Capitulo 8 Leccin 1 Leccin 2 Leccin 3 Leccin 4 Leccin 5 Capitulo 9 Leccin 1 Leccin 2 Leccin 3 Leccin 4 Leccin 5
Modelos Tradicionales para la Evaluacin de la Calidad del software Norma de Evaluacin ISO/IEC 9126 Proceso de Evaluacin de Software Mtricas Externas Basados en ISO/IEC 9126 Mtricas Internas Basados en ISO/IEC 9126 METODOLOGIAS DE EVALUACIN DE LA ARQUITECTURA DEL SOFTWARE Evaluacin de la Arquitectura del software Tcnicas de Evaluacin de la arquitectura del software Mtodos de Evaluacin de la arquitectura de software Mtodos de Evaluacin de Arquitectura de un Atributo Especfico Mtodo de evaluacin de la Arquitectura de Software MECABIT APLICACIONES DE LA EVALUACIN DE SOFTWARE Metodologa para la Evaluacin de la Calidad en Modelos UML Implementacin de la Metodologa con SPEM y EPFC Evaluacin de Software Educativo Multimedia Modelos de Evaluacin de Software Educativo Multimedia Plantillas de Evaluacin 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 Iniciacin del Proyecto Proceso de Seguimiento y Control del Proyecto Proceso de Gestin de Calidad del software Proceso de Exploracin de Conceptos Proceso de asignacin de Sistema Proceso de requisitos o Requerimientos Proceso de requisitos o Requerimientos Proceso de Implementacin Proceso de Instalacin Proceso de Operacin y Soporte Proceso de Mantenimiento Proceso de Retiro Proceso de verificacin y Validacin Proceso de gestin de la Configuracin Proceso de Desarrollo de la documentacin Proceso de Formacin Caractersticas de Calidad interna y externa ISO/IEC 9126 Caractersticas 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 Tamao Tabla para Clculo de Puntos de Funvin Caractersticas y definicin de puntos de funcin (a) Caractersticas y definicin de puntos de funcin (b) Factores de calidad de McCall Mtricas para el esquema de puntuacin Mtricas del modelo de Calidad FURPS Caractersticas y Subcaractersticas modelo ISO/IEC 9126 Actividades y definicin de Mtricas Tcnicas de Software Mtrica Bang Medidas de Complecin de pruebas Objetivos, Principios, y Caractersticas 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 Integracin de Software Orientado a Objetos Pruebas de Sistema de Software Orientado a Objetos Tabla de criterios a tener en cuenta al evaluar un software Caractersticas y Subcaratersticas ISO/IEC 9126 Mtricas 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
Mtricas Internas ISO/IEC 9126 Descripcin de atributos de calidad observables va ejecucin Descripcin de atributos de calidad no observables va ejecucin Perfiles, Categorias, Pesos, y Mtricas Asociados a atributos de Calidad Pasos para la Evaluacin Basada en Simulacin Pasos para la Evaluacin Basada en Modelos Matemticos Instrumentos asociados a las distintas tcnicas de evaluacin de arquitecturas de software Pasos contemplados por el mtodo de evaluacin SAAM Pasos del mtodo de evaluacin ATAM Pasos del mtodo de evaluacin ARID Pasos del mtodo de evaluacin CBAM Etapas contempladas por el mtodo de evaluacin de arquitecturas propuesto por Bosch Actividades del Mtodo de Comparacin de Arquitecturas Basado en el Modelo ISO/IEC 9126 Adaptado para Arquitecturas de Software de Losavio Comparacin entre los mtodos ALMA, PASA, SALUTA y SNA Grupos de Trabajo en el Mtodo MECABIT Fases Contempladas en el Mtodo de evaluacin de Arquitecturas MECABIT Subconjunto del rbol de Utilidad Iinicial Propuesto por el Mtodo MECABIT Algunas Preguntas para Analizar los Elementos de Diseo Identificados Tabla de Personas, grupos y Roles Catlogo de Elementos Fases del Proceso de Evaluacin Caractersticas 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 informtico Elementos Considerados en la Valoracin Comprensiva del MEC Algunos elementos de la valoracin por experto en contenido del MEC Elementos considerados en la valoracin por experto en metodologa Aspectos tcnicos de la evaluacin 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 pedaggicos de la evaluacin de software de Bostock Esquema de evaluacin del producto final Criterios y Subcriterios para Evaluacin de la Calidad del Software Educativo Caractersticas de las variables segn criterios de calidad Algunas caractersticas de la ficha de evaluacin de software Ficha de Catalogacin y Evaluacin Ficha de Diseo de actividades
210 211 211 212 213 215 218
LISTADO DE GRFICOS 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 validacin Ciclo de vida en espiral Ciclo de vida XP Metodologa SCRUM Ciclo de vida FDD Modelo de Gestin 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 Mtricas del Proceso y Mejoras en el Proceso de Software Anlisis de Problemas y causas de calidad del software Identificacin de causas de errores o defectos en un software Prueba de Caja Blanca Prueba de Caja Negra Integracin Incremental Descendente Depuracin de errores Norma de Evaluacin ISO/IEC 9126 Evaluacin Interna, externa y Calidad de Uso ISO/IEC 9126 Caracterstica de Funcionalidad Caracterstica de Confiabilidad Caracterstica de Usabilidad Caracterstica de Eficiencia Caracterstica de Mantenibilidad Caracterstica de Portabilidad Caracterstica de Calidad de Uso Clasificacin de las Tcnicas de Evaluacin Mtodo de evaluacin de arquitecturas ALMA Mtodo de evaluacin de arquitecturas PASA Mtodo de evaluacin de arquitecturas SALUTA Mtodo de evaluacin de arquitecturas SNA Roles y relaciones en el proceso de evaluacin Diagrama de actividad generado por EPFC para la actividad Obtencin y Anlisis de Artefactos a Evaluar de la fase 2 (Especificacin), del proceso de evaluacin 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 mdulo ha sido compilado y diseado en el ao 2010 por el Ingeniero de sistemas Francisco Nicols Javier Solarte Solarte, docente de la UNAD, quien a la fecha labora en el CEAD de Pasto, dentro de su currculo 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 Nario y Magister en docencia de la Universidad de La Salle. Adems cuenta con experiencia en Docencia Universitaria desde 1995 en las diferentes universidades de la ciudad de san Juan de Pasto y actualmente se desempea como docente auxiliar de la UNAD. Esta es la primera versin actualizada del curso y en el proceso de revisin participa la Escuela ECBTI con respecto a los contenidos y la VIMMEP en la revisin del CORE quienes apoyan el proceso de revisin del estilo del mdulo y dan recomendaciones disciplinares, didcticos y pedaggicos para acreditar y mejorar el curso. El mdulo fue iniciado el mes de julio de 2010, y se termina en el mes de noviembre del mismo ao, a peticin de la directora nacional de la Cadena de Formacin de Sistemas, Ingeniera Alexandra Aparicio.
UNIDAD 1
Nombre de la Unidad Introduccin PROCESO DE DESARROLLO DE SOFTWARE Esta unidad esta dedicada principalmente a la explicacin 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 evaluacin 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 evaluacin del software es importante recalcar que no solo se evala el producto, sino tambin, el proceso de desarrollo de software y es de vital importancia que el ingeniro de software y la empresa conozcan los modelos y la metodologa basada en estndares 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 estndares y cada una de las etapas de desarrollo de software - El estudiante conoce los conceptos de calidad, calidad de software y algunos de los estndares ms reconocidos aplicados al producto software. CAPITULO 1: CICLOS DE VIDA DEL SOFTWARE Leccin 1. Conceptos Generales sobre ciclos de vida Leccin 2. Ciclos de vida tradicionales Leccin 3. Ciclos de vida alternativos Leccin 4. Modelos de proceso de produccin de software Leccin 5. Ciclos de vida giles CAPITULO 2: DESARROLLO DE SOFTWARE Leccin 1. Procesos de Gestin del Proyecto Leccin 2. Procesos de Pre-Desarrrollo Leccin 3. Procesos de Desarrollo Leccin 4. Procesos de Post-Desarrollo
Justificacin
Intencionalidades Formativas
Denominacin de captulos Denominacin de Lecciones Denominacin de Lecciones Denominacin de Lecciones Denominacin de Lecciones Denominacin de Lecciones Denominacin de captulos Denominacin de Lecciones Denominacin de Lecciones Denominacin de Lecciones Denominacin de Lecciones
Denominacin de Lecciones Denominacin de captulos Denominacin de Lecciones Denominacin de Lecciones Denominacin de Lecciones Denominacin de Lecciones Denominacin de Lecciones
Leccin 5. Procesos Integrales del Proyecto CAPITULO 3: CONCEPTOS DE CALIDAD Y CALIDAD DEL SOFTWARE Leccin 1.Definicin de Calidad Leccin 2. Sistemas de Calidad en la empresa Leccin 3: Normatividad de Calidad Leccin 4: Ingeniera de Software y Calidad Leccin 5. Gestin de la Calidad del Software
INTRODUCCIN Hace algunos aos, el desarrollo de aplicaciones informticas se llevaba a cabo de forma individual, generando lneas de cdigo y probando lo realizado. Este proceso se realizaba sin necesidad de documentacin alguna y como haba baja movilidad las empresas pensaban que cuando hubiera necesidad de la persona para realizar modificaciones l estara all para solucionar los problemas. A pesar de que esa forma de escribir cdigo era un adelanto, nunca se llego a pensar que posteriormente se convertira en un problema y que en el caso de software que contena errores en la base de datos este deba desecharse completamente y comenzar nuevamente. Esta forma de desarrollar software es muy comn 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 planificacin, pues normalmente, se codifica y se prueba dando buenos resultados cuando el software es pequeo. 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 mtodos 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 documentacin 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. Adems 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 concepcin hasta finalizar con el retiro del mismo cuando ya no se utiliza. Todas las organizaciones y estudiosos de la ingeniera de software se han ocupado del estudio de estos problemas para proponer nuevos enfoques y actividades tendientes a mejorar los procesos de construccin y revisin de software. As se han desarrollado modelos de referencia para la adquisicin, desarrollo, explotacin, soporte y mantenimiento de software. El instituto de ingeniera de software ha desarrollado el Modelo de Madurez de la Capacidad ( Capability Maturity Model, CMM), el cual proporciona a las organizaciones de software una orientacin sobre como hacerse con el control del proceso de desarrollo y mantenimiento de software, y como evolucionar hacia una cultura de la ingeniera de software y de gestin 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 evaluacin de software un informe tcnico alineado con el anterior, ISO/IEC TR 15504-2, y especficamente la La serie de normas ISO/IEC 14598 para evaluacin de software, la norma ISO/IEC 9126 que posteriormente se unificaran 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 informticos, desde que surge la idea o necesidad de desarrollar las aplicaciones hasta que estos se retiran de explotacin. Sin embargo ninguno de estos modelos impone la utilizacin de un ciclo de vida especfico o mtodo de desarrollo concreto, sino que cada empresa debera seleccionar los procesos que considere necesario realizar, estableciendo sus propios ciclos de vida software. La Ingeniera de software y especficamente el curso de Evaluacin de software es uno de los componentes fundamentales de la estructura curricular del programa de Ingeniera de sistemas, pues incorpora en su contenido todo lo referente a los ciclos de vida de los sistemas, el proceso de construccin de software, las mtricas de software, las pruebas de software, los estndares de calidad, la evaluacin de la arquitectura de los sistemas, y la evaluacin general de productos software de diferente tipo, con el propsito de verificar y evaluar su correcta realizacin. Este curso, se enmarca dentro del campo de formacin profesional y tiene como objetivo la preparacin de los estudiantes y futuros profesionales en su labor como desarrolladores de software, auditores o consultores de productos informticos dentro de una organizacin. El mdulo esta compuesto de tres unidades generales, y cada una de ellas esta integrada por captulos 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 metodologas de desarrollo de software, la gestin de proyectos de software y aspectos relacionados con estos temas. Unidad 2: Calidad del Software, dentro de esta unidad se incluye las mtricas de calidad, estandares de calidad de software, pruebas del software, gestin de la calidad de software. Unidad 3: Evaluacin de software, dentro de esta unidad se incluye la especificacin de las mtricas ISO/IEC 9126, los mtodos de evaluacin y las aplicaciones que aunque diversas, tratan de recoger las nuevas investigaciones sobre estos temas tan importantes para la vida profesional del ingeniero.
JUSTIFICACIN Uno de los intereses en la formacin de los estudiantes del programa de ingeniera de sistemas y en mbito disciplinar, es su formacin integral a travs del desarrollo de competencias, que le permitan interactuar en diferentes contextos, haciendo de ellos profesionales competitivos, generadores de cambio y progreso. El curso de evaluacin de software no es la excepcin, ya que centra al estudiante en aspectos relacionados con los sistemas de informacin empresarial donde con sus habilidades y conocimientos puede contribuir al desempeo y cumplimiento exitoso de los procedimientos de la organizacin. El estudiante como profesional estar preparado para planificar, disear, 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 formacin y especficamente que conozcan el campo de la Ingeniera de Software, ya que los mtodos de evaluacin de software estn ligados al proceso de construccin o adquisicin del software. El curso permite el desarrollo de competencias cognitivas, comunicativas, contextuales y valorativas, fundamentales para la formacin profesional y la interaccin en otros contextos. El logro de estas competencias exige una planificacin responsable en su proceso de aprendizaje autnomo si se quieren obtener resultados positivos en el desarrollo del curso, ya que el trabajo es en parte individual y otra la interaccin en grupos colaborativos pequeos. La evaluacin de software permite llevar a la prctica los conocimientos adquiridos en los cursos del componente de ingeniera de software que son la base del profesional en sistemas y permite integrar las otras reas del conocimiento necesarias para realizar un proceso de evaluacin bajo normas estndares. Adems una de las tareas ms difciles en la eleccin de software, una vez conocidos los requerimientos del sistema, es el de determinar si un cierto producto de software cumple con los requerimientos. Despus de la seleccin inicial, es necesario conocer los estndares de calidad y hacer una revisin exhaustiva del cumplimiento de las normas, y cuales son las ventajas frente a los otros productos.
INTENCIONALIDADES FORMATIVAS PROPSITO Fundamentalmente, el curso pretende desarrollar las capacidades, habilidades y destrezas de los estudiantes durante el proceso de evaluacin de software, donde deber conocer y aplicar los conocimientos acerca de ciclos de vida, estndares de calidad, las mtricas de calidad y las para hacer la revisin de los diferentes tipos de productos software. Con esto se contribuir al mejoramiento de los procesos de calidad del software en las organizaciones, a travs de la aplicacin de procedimientos y estndares de calidad tanto en el proceso de produccin de software como en la bsqueda de soluciones apropiadas para dar solucin a problemas del uso y la integracin de sistemas de informacin 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 bsicos y las caractersticas de la evaluacin de software - Conocer los tipos de pruebas, mtricas y estndares de calidad para la evaluacin de software y aplicar procedimientos para la evaluacin de software tendientes a evaluar el proceso de desarrollo y los productos comerciales. - Identificar y analizar los estndares 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 evaluacin de software y aplicar procedimientos para la evaluacin 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 estndares y mtricas de calidad de software - Conocer y comprender los procedimientos para la evaluacin 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 cmo asegurar la calidad durante cada una de las fases. - El estudiante esta en capacidad de identificar los estndares de calidad, las mtricas, los factores y requisitos que se deben cumplir los productos software. - El estudiantes esta en la capacidad de realizar los procedimientos de evaluacin 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 desempeo de las mismas contribuyendo al desarrollo de la regin.
UNIDAD 1
PROCESO DE DESARROLLO DE SOFTWARE
CAPITULO 1
CICLOS DE VIDA DEL SOFTWARE
1.1
LECCIN 1: CONCEPTOS GENERALES SOBRE CICLOS DE VIDA
El ciclo de vida de software es la descripcin de las distintas formas de desarrollo de un proyecto informtico. Es la orientacin 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 ms tcnicas, dice que un ciclo de vida es un conjunto de fases o etapas, procesos y actividades requeridas para el desarrollo y la explotacin 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 ejecucin 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 trminos 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 implementacin de cada uno de los requerimientos del cliente una vez terminado el desarrollo. La solucin a algunos de los problemas presentados por las metodologas tradicionales se logra con una gran evolucin del modelo espiral. El proceso unificado propone la elaboracin 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 metodologas giles. Las metodologas giles, promueve la formalizacin de procesos adaptables. La compilacin de los principios y valores que resaltan las metodologas giles fue formalizada en el manifiesto para el desarrollo de software gil. La metodologa XP, una de las metodologias giles ms difundidas que define pocas reglas y pocas prcticas. XP promueve la adaptabilidad de los procesos de desarrollo basndose en los principios y prcticas que presenta.
Quienes trabajan usando XP deben seguir procesos disciplinados, adems de combinar la disciplina con la adaptabilidad necesaria del proceso. Las metodologas de Cristal se basan en el principio de que tipos diferentes de proyectos requieren tipos diferentes de metodologas. La metodologa escogida debe depender de dos factores: el nmero de personas en el proyecto, y las consecuencias de los errores. Conforme al principio de las metodologas giles, Scrum recalca la imposibilidad de encontrar procesos definidos y repetibles cuando no existen problemas, personas, ni ambientes definidos y repetibles. Al utilizar las metodologas tradicionales el problema es que casi nunca se logra planear bien el esfuerzo requerido para seguir la metodologa. Pero si se logra definir mtricas que apoyen la estimacin 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 adaptacin de los procesos de desarrollo que son llevados por parte de los equipos que construyen software. Tener metodologas diferentes para aplicar de acuerdo con el proyecto que se desarrolle resulta interesante ya que estas pueden involucrar prcticas tanto de metodologas giles como de metodologas tradicionales. De esta manera se puede plantear una metodologa por cada proyecto, el problema se centrar en definir cada una de las prcticas, y en el momento preciso definir parmetros para saber cual usar. Al elegir el modelo de ciclo de vida se debe tener en cuenta algunos factores como el contexto, fundamentos bsicos, los obstculos y ventajas. Esto incluye realizar un estudio de las prcticas que se van a poner en ejecucin dentro de un proyecto. Los modelos deben ser estructurados teniendo en cuenta las caractersticas propias del proyecto y pueden ser hbridos 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 Tecnolgicos que incluyen empresas de desarrollo de software, se debe tomar en cuenta las caractersticas propias del contexto de un grupo de jvenes emprendedores sin altos recursos para realizar inversin, 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 trminos de un conjunto de atributos como pueden ser la calidad del software y la precisin de los planes realizados. Tambin surgen las preguntas de cmo evaluar el proceso de desarrollo, la identificacin del conjunto de caractersticas que rodean los desarrollos, e impactan de manera significativa los resultados del equipo y cmo identificar el conjunto de prcticas adecuadas para incluir en un nuevo modelo de ciclo de vida de desarrollo. A continuacin 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
especfico el ciclo de vida ms adecuado, teniendo en cuenta la cultura empresarial, el deseo de asumir riesgos, el rea de aplicacin, 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 LECCIN 2: CICLOS DE VIDA TRADICIONALES
1.2.1. Ciclo de vida clsico 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 evolucin del producto software procede a travs de una secuencia ordenada de transiciones de una fase a la siguiente segn el orden lineal. Este modelo semeja una mquina de estados finitos para la descripcin de la evolucin 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 iteracin 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 anlisis 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 ms utilizado, aunque incorporando infinidad de variaciones que eliminan el carcter simplista del mismo. An hoy en da 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 sealar las siguientes: El modelo asume que los requisitos se pueden conseguir antes de iniciar la etapa de diseo, eso para los sistemas nuevos es poco realista, el mantener los requisitos requiere seleccionar el hardware, pero la terminacin de un proyecto puede llevar aos, y dada la velocidad de obsolescencia de la tecnologa, es probable que el software final utilice hardware obsoleto, en caso de sistemas no desarrollados para clientes especficos, 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 ms lgido de este modelo es que enva al cliente el producto solamente despus de que se han consumido el 90% de los recursos, esto significa que la mayor parte de la retroalimentacin del cliente sobre sus necesidades se obtiene al final. Este ciclo de vida tiene tres factores muy positivos: El primero, es que las etapas estn organizadas de un modo lgico, una etapa no puede llevarse a cabo hasta que se haya tomado las decisiones de continuar a la siguiente, es as como, el diseo espera a los requisitos, la codificacin espera al diseo, el segundo es que cada etapa incluye un proceso de revisin y se necesita la aceptacin 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 visin alternativa de este modelo que enfatiza la validacin de los productos y el proceso de composicin existente en la construccin 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 anlisis preliminar de mltiples funciones, cada una de las cuales se expande en el diseo detallado que a su vez evoluciona en un nmero mayor de programas unitarios, al ensamblar el producto se procede al contrario, dentro de un proceso de sntesis o composicin, donde primero se aceptan los programas unitarios probados, estos se agrupan en mdulos que a su vez deben ser aceptados una vez probados, luego, los mdulos 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 informtico 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 tambin 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 prximo paso de descomposicin, pero tambin se documentan los criterios para determinar si el producto compuesto que resulta satisface las intencionalidades que se tenan 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 realizacin sigue el mismo orden. Sin embargo, este modelo recomienda desarrollar los sistemas software a travs de un refinamiento y mejora continuos desde las especificaciones de alto nivel del sistema hasta los componentes de cdigo 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 generacin de productos de manera iterativa mediante un proceso de refinamiento. Debido a la marcha atrs permitida en el modelo en cascada, se abre un camino desde una etapa hacia otra anterior, el refinamiento iterativo puede producirse tambin a nivel global de todas las etapas.
Figura 2: ciclo de vida en cascada con validacin
1.2.3 Ciclo de vida con emisin gradual Este modelo propone desarrollar sistemas produciendo, en primer lugar, las funciones esenciales de operacin y posteriormente proporcionar a los usuarios mejoras y versiones ms capaces del sistema a intervalos regulares. Este modelo combina el ciclo de vida clsico de software con mejoras iterativas a nivel del desarrollo del sistema global. Tambin proporciona una manera de distribuir peridicamente actualizaciones del mantenimiento de software comercial. 1.2.4 Estndares militares y prcticas industriales Las empresas industriales adoptan con frecuencia alguna variacin del modelo clsico como base de la prctica del desarrollo de software. Muchos proveedores de la administracin americana organizan sus actividades de acuerdo con los modelos del ciclo de vida del estndar militar, tal como el de la norma MIL-STD-2167 de 1987. Tales estndares subrayan no solo alguna variacin de las actividades del ciclo de vida clsico, sino que tambin contienen lo documentos que deben entregarse a los clientes que necesitan sistemas software o mecanismos complejos como sistemas software embebidos. Estos estndares deben ser compatibles con la garanta de calidad del software, la gestin de configuraciones y la verificacin y validacin independiente de servicios en un proyecto de desarrollo con ms de un contratista. Estos modelos ponen especial nfasis en la definicin de productos entregables, revisones, hitos y tcnicas requeridas en cada caso. 1.3 LECCIN 3: CICLOS DE VIDA ALTERNATIVOS
Existen por lo menos tres conjuntos alternativos a los modelos de evolucin de los productos software tradicionales. Estos modelos centran su atencin bien sobre productos diferentes a los clsicos o sobre procesos especiales de produccin o sobre entornos de produccin. Dado que estos modelos no estn an muy extendidos, se considera fundamental su presentacin aqu por las potencialidades que presentan. 1.3.1 Ensamblaje de componentes reutilizables El enfoque bsico de la reutilizacin es configurar y especializar componentes de software ya existentes. Sin embargo, la granularidad de los componentes, es decir, el tamao, complejidad y capacidad funcional, vara grandemente a lo largo de los distintos enfoques. La mayora de ciclos de vida basados en ensamblaje de componentes intentan utilizar componentes similares a estructuras de datos con los algoritmos incorporados para su manipulacin
denominados componentes de grano fino. Sin embargo, el uso de componentes de grano fino no constituye un enfoque distinto a la evolucin del producto software tradicional. Otros enfoques intentan utilizar componentes ensamblando funcionalmente sistemas o subsistemas completos; por ejemplo, sistemas de gestin de interfaces de usuario, en este caso se trata de componentes de grano grueso. El uso o la reutilizacin 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 implementacin rpida es usarlo durante el diseo arquitectnico. Los componentes reutilizables tambin pueden usarse con propsitos de prototipado. 1.3.2 Generacin de aplicaciones Es un enfoque de desarrollo de software similar a la reutilizacin de componentes de software de grano grueso, pero en este caso, parametrizados. Tales componentes estn especializados en un dominio de aplicacin, va un lenguaje de especificacin formalizado usado como entrada para el generador de la aplicacin. Ejemplos comunes de este enfoque son las interfaces estandarizados de aplicaciones de sistemas de gestin de bases de datos que incluyen generadores de informes, grficos, editores especficos de la aplicacin e interfaz de usuario. El uso de generadores da lugar a un modelo de evolucin del producto software mediante el cual la actividad de diseo del software o es casi eliminada, o reducida a un problema de diseo de bases de datos. Similarmente los usuarios de los generadores de aplicaciones esperan habitualmente proporcionar especificaciones de entrada y servicios de mantenimiento de la aplicacin. Estas capacidades son posibles dado que los generadores pueden producir solo sistemas software especfico para un pequeo nmero de dominios de aplicacin similares y en especial aquellos que dependen de un sistema de gestin de bases de datos. 1.4 LECCIN SOFTWARE 4: MODELOS DE PROCESO DE PRODUCCIN DE
1.4.1 Modelos operativos El enfoque operativo para el desarrollo de software supone la existencia de un lenguaje de especificain formal y un entorno de proceso. Las especificaciones estn 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 ms completos que siempre estn 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.1Automatizacin de la programacin y del proceso software: La automatizacin del proceso y la programacin estn relacionados con el desarrollo de las especificaciones formales de cmo una familia de sistemas software debe desarrollarse, estas especificaciones deberan proporcionar una estimacin para la organizacin y descripcin de las distintas cadenas de produccin software, como estn interrelacionadas, cundo iteran, y qu herramientas software deberan utilizarse. El desarrollo de software utilizando tcnicas de cuarta generacin se caracteriza por facilitar la especificacin de algunas de las funcionalidades de alto nivel. La herramienta genera a continuacin, el cdigo o parte de l a partir de la especificacin. Esta especificacin se hace en un lenguaje lo ms prximo al lenguaje natural. El concepto de desarrollo con uso de herramientas de cuarta generacin se utiliza varias herramientas dentro de las cuales se encuentran los lenguajes no procedimentales para las bases de datos, generacin de informes y pantallas de captura, para la generacin de cdigo y las capacidades grficas de alto nivel combinados con hojas de clculo. Una vez hecha la especificacin de los requerimientos, la generacin de cdigo es casi automtica, con lo que el tiempo de desarrollo se reduce drsticamente. Con el cdigo generado se empieza a revisar las funcionalidades de la aplicacin y se va aadiendo prestaciones de forma interactiva hasta completar el producto. Esta tcnica permite la construccin de programas al usuario y permite la revisin y actualizacin personal, con lo que es muy difcil la equivocacin en cuanto al cumplimiento de requerimientos. En la actualidad su uso se reduce a sistemas de gestin con un grado de complejidad no muy elevado. 1.4.1.2 Automatizacin del Software Basado en Conocimientos: Este modelo intenta llevar el proceso de automatizacin hasta sus lmites 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 tcnicas de prototipado, pero la expansin al sistema final a partir del prototipo es mucho ms directa, ya que pueden bastar con incrementar la base de reglas de inferencia o la base de conocimientos.
Por otra parte, la definicin 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: Identificacin del problema, estudio de factibilidad, identificacin de subproblemas, identificacin de conceptos y relaciones, diseo conceptual, diseo detallado, cdigo, prueba de razonamiento, prueba del conocimiento, validacin, conversin, 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 interactan, pero que estn una al lado de la otra en el tiempo. El enfoque comn a estos tres modelos mencionados es buscar la automatizacin del modelo de transformacin 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 implementacin. 1.4.2 Modelos no operativos Estos modelos incorporan mtodos 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 anlisis de riesgos y estructuracin de procesos de software. El enfoque incorpora mtodos 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 anlisis y prototipado temprano, y los externos el modelo clsico. La dimensin radial indica los costos de desarrollo acumulativos y la angular el progreso hecho en cada desarrollo en espiral. El anlisis 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 anlisis 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 anlisis 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 construccin de software tradicionales, mientras su orientacin al riesgo evita muchas dificultades. De hecho, en situaciones apropiadas, el modelo en espiral proporciona una combinacin de los modelos existentes para un proyecto determinado. Otras ventajas de este modelo son las siguientes: Presta atencin a las opciones que permiten la reutilizacin de software existente, est centrado en la eliminacin de errores y alternativas poco atractivas, no establece una diferenciacin entre desarrollo de software y mantenimiento del sistema, y proporciona un marco estable para desarrollos integrados hardware - software. 1.4.2.2 Modelos de Transformacin contnua: Estos modelos proponen un proceso por el cual los sistemas software se desarrollan a travs 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 ms 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 transformacin continuada tambin se acomodan al inters 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 matemticamente en propiedades que una implementacin fuente debera satisfacer. 1.4.2.3 Modelos de Procesos Miscelneos: 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 satisfaccin de sus precondiciones y sus postcondiciones as como a las variaciones de los componentes sobre el ciclo de vida tradicional y modelos de transformacin contina. 1.4.2.4 Modelos de entorno de produccin software: El proceso de produccin o de producto de la evolucin del software, los modelos del entorno de produccin dirigen su atencin a la organizacin y gestin de estrategias para desarrollar y producir sistemas software. Como tales, el foco es menos tecnolgico y ms estratgico. Pero debera quedar claro que tales estrategias afectan tanto a los productos software que consiguen desarrollarse, como a la forma que ser organizado el proceso de produccin del software. Entre estos modelos se pueden mencionar los siguientes: Modelos de proceso de Gestin de Proyectos software, Modelos Organizadores de Desarrollo de Software, Modelos de ciclo de Vida de Recursos de Clientes, modelos de Transicin y Transferencia de tecnologa software y otros modelos para la organizacin, fabricacin y produccin de sistemas software. 1.5 LECCIN 5: CICLOS DE VIDA GILES
El trmino gil aplicado al desarrollo de software nace en el ao 2001, tras una reunin en donde participan un grupo de 17 expertos de la industria del software, incluyendo algunos de los creadores o impulsores de metodologas de software. Su objetivo fue esbozar los valores y principios que deberan permitir a los grupos desarrollar software rpidamente y respondiendo a los cambios que puedan surgir a lo largo del proyecto. Se pretenda ofrecer una alternativa a los procesos de desarrollo de software tradicionales, caracterizados por ser rgidos y dirigidos por la documentacin que se genera en cada una de las actividades desarrolladas. Despus de dicha reunin nace The Agile Alliance, una organizacin, 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 ms difundidos pertenecientes a esta filosofa son:
1.5.1 Programacin Extrema (XP) Kent Beck, el padre de XP, describe la filosofa de XP como una metodologa gil que potencia las relaciones interpersonales como clave para el xito en desarrollo de software, promoviendo el trabajo en equipo, preocupndose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en realimentacin continua entre el cliente y el equipo de desarrollo, comunicacin fluida entre todos los participantes, simplicidad en las soluciones implementadas y disposicin para enfrentar los cambios. XP se define como adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo tcnico. Los principios y prcticas son de sentido comn 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 prcticas 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 gestin de proyectos de desarrollo de software, se puede usar tambin para la ejecucin de equipos de mantenimiento de software o como un enfoque de gestin de programas. SCRUM define un marco para la gestin de proyectos, que se ha utilizado con xito durante los ltimos 10 aos. Est especialmente indicada para proyectos con un rpido cambio de requisitos. Sus principales caractersticas se pueden
resumir en dos. El desarrollo de software se realiza mediante iteraciones, denominadas sprints, con una duracin de 30 das, el resultado de cada sprint es un incremento ejecutable que se muestra al cliente. La segunda caracterstica importante son las reuniones a lo largo proyecto, entre ellas destaca la reunin diaria de 15 minutos del equipo de desarrollo para coordinacin e integracin. SCRUM es un esqueleto de proceso que incluye un conjunto de prcticas 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 iteracin (sprint- periodos de tiempo), tpicamente un periodo de 2 a 4 semanas (longitud decidida por el equipo), el equipo crea un incremento de software operativo.
Figura 5: Metodologa SCRUM El conjunto de caractersticas que entra en una iteracin 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 iteracin se determinan durante la reunin de planificacin de la iteracin. Durante esta reunin, 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 iteracin.
1.5.3 Agile Unified Process (AUP) El proceso unificado gil (AUP) es una versin simplificada de RUP desarrollada por Scout Ambler. Describe un enfoque simple, fcil de entender, del desarrollo de software de aplicacin de negocios usando tcnicas y conceptos giles. AUP aplica tcnicas giles incluyendo desarrollo orientado a pruebas, modelado gil, gestin de cambios gil y refactorizacin 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 aceptacin por parte de las personas involucradas en el negocio; la elaboracin, el objetivo es probar la arquitectura del sistema; la construccin, el objetivo es construir software operativo de forma incremental que cumpla con las necesidades de prioridad ms altas de las personas involucradas en el negocio; transicin, el objetivo es validar y desplegar el sistema en el entorno de produccin. 1.5.4 Dynamic System Development Method (DSDM) Nace en 1994 con el objetivo de crear una metodologa RAD unificada. Sus principales caractersticas 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, diseo y construccin, y finalmente implementacin. Las tres ltimas son iterativas, adems de existir realimentacin a todas las fases. El mtodo de desarrollo de sistemas dinmico (DSDM) es una metodologa de desarrollo de software originalmente basada en la metodologa RAD. DSDM es un enfoque iterativo e incremental que enfatiza la participacin continua del usuario cuyo objetivo es entregar sistemas software en tiempo y presupuesto ajustndose a los cambios de requisitos durante el proceso de desarrollo. DSDM es uno de los mtodos giles para el desarrollo de software, y forma parte de la Alianza gil. Como extensin del desarrollo rpido de aplicaciones, DSDM se centra en proyectos de sistemas de informacin que se caracterizan por planificaciones y presupuestos estrictos. DSDM trata las caractersticas ms comunes de los proyectos de sistemas de informacin, incluyendo presupuestos sobrepasados, plazos de entrega desaparecidos y falta de participacin del usuario y compromiso de la alta gerencia. 1.5.5 Crystal Methodologies Se trata de un conjunto de metodologas para el desarrollo de software caracterizadas por estar centradas en las personas que componen el equipo y la
reduccin al mximo del nmero de artefactos producidos. El desarrollo de software se considera un juego cooperativo de invencin y comunicacin, 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 polticas de trabajo en equipo definidas. Estas polticas dependern del tamao del equipo, establecindose una clasificacin 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 metodologas Crystal como describe Alistair Cockburn y se considera un ejemplo de metodologa gil. Crystal Clear est pensado para aplicarse a equipos pequeos de 6 a 8 desarrolladores ubicados en el mismo sitio trabajando en sistemas que no son crticos. La familia de metodologas 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 cdigo usable a los usuarios, mejora reflexiva, comunicacin osmtica preferiblemente estando en la misma ubicacin, seguridad personal, fcil acceso a los usuarios expertos y pruebas automatizadas, gestin de la configuracin e integracin frecuente. 1.5.6 Adaptive Software Development (ASD) Sus principales caractersticas son: iterativo, orientado a los componentes software ms que a las tareas y tolerante a los cambios. El ciclo de vida que propone tiene tres fases esenciales: especulacin, colaboracin y aprendizaje. En la primera de ellas se inicia el proyecto y se planifican las caractersticas del software; en la segunda desarrollan las caractersticas y finalmente en la tercera se revisa su calidad, y se entrega al cliente. La revisin 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 diseo e implementacin del sistema partiendo de una lista de caractersticas 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 automvil en los aos 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 caracterstica es introducir un mecanismo para implementar dichos cambios.
CAPITULO 2
DESARROLLO DE SOFTWARE
INTRODUCCIN A continuacin se describe en detalle las fases o subprocesos que conforman el proceso base de construccin de software correspondiente al estndar IEEE 1074-1989. Cada subproceso detalla el nivel de propsito, actividades involucradas y documentacin principal propuesta por el estndar. El estndar 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 estndar ha sido escrito por organizaciones responsables de la gestin y desarrollo de software y est dirigido a los gestores de proyectos, a los desarrolladores de software, a los responsables de la garanta de calidad, a quienes ejecutan tareas de apoyo, y al personal de mantenimiento. El proceso base para la construccin de software consiste en analizar las necesidades de la organizacin en un dominio, bajo un marco de gestin, seguimiento, control y gestin 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 realizacin de sus requisitos asociados. Estos son los siguientes: Proceso de seleccin 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 gestin del proyecto, donde se crean la estructura del proyecto y aseguran el nivel apropiado de la gestin 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 terminacin y calidad de las funciones del mismo. Son simultneos 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 seleccin del ciclo de vida, el proceso de gestin dl proyecto, los procesos orientados al desarrollo del software y los procesos integrales del proyecto.
2.1
LECCIN 1: PROCESOS DE GESTIN DEL PROYECTO
La gestin del proyecto presupone establecer condiciones para el desarrollo del mismo, la gestin involucra actividades dentro de las cuales tenemos: La planificacin de proyectos, define la prediccin de la duracin de las actividades y tareas a nivel individual, los recursos requeridos, la concurrencia y la superposicin de tareas para que sean desarrollados en paralelo y el camino crtico a travs de la red de actividades. La estimacin, que se define como la prediccin de personal, el esfuerzo y costos que se requerir para terminar todas las actividades y productos conocidos asociados con el proyecto. La determinacin del tamao del producto a desarrollar, que es una de las primeras tareas en la gestin del proyecto, ya que sin conocerlo adecuadamente, no es posible planificar y estimar el esfuerzo necesario. El tamao se define como la cantidad de cdigo fuente, especificaciones, casos de prueba, documentacin del usuario y otros productos tangibles que son la salida del proyecto. El seguimiento de proyectos, que es la recoleccin de datos y su acumulacin sobre recursos consumidos, costos generados, e hitos asociados con el proyecto. La medicin de un proyecto, que se define como el registro de todos los productos generados en el mismo, de todos los recursos requeridos, planificacin y superposicin de todas las actividades y de todos los factores que impactan en el proyecto como los conocimientos, mtodos, herramientas, lenguajes, limitaciones, problemas y el entorno fsico. 2.1.1 Proceso de iniciacin del proyecto Abarca aquellas actividades de creacin de la estructura del proyecto, aqu se define el ciclo de vida del software para este proyecto y se establecen los planes para su gestin. Se determinan los costos y recursos necesarios a fin de ejecutar las distintas tareas que demanda el proyecto. Se identifican y seleccionan estndares, metodologas y herramientas para la gestin, herramientas para la ejecucin del mismo y por ltimo se prepara y establece un plan para su implementacin adecuada y oportuna. El plan de gestin de proyectos software que conducir al desarrollo se produce como culminacin de este proceso. A continuacin se presenta una tabla de actividades a realizar, la documentacin que se obtine y cuales tcnicas se aplican.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD 37 ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA - ECBTI CURSO DE EVALUACIN DE SOFTWARE - CDIGO 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 gestin del proyecto Documentacin de salida Plan de gestin del proyecto Plan de retiro Tcnicas a utilizar Anlisis de camino crtico (CPM) Anlisis PERT Diagrama de GANTT Tcnicas Estadsticas Tcnicas de simulacin (mtodo de MONTECARLO) Puntos de funcin Modelos empricos de estimacin (COCOMO, PUTMAN) Tcnicas de Descomposicin Funcional
Tabla 1: Proceso de iniciacin del proyecto 2.1.2 Proceso de seguimiento y control del proyecto Es un proceso iterativo de seguimiento, registro y gestin de costos, problemas y rendimiento de un proyecto durante su ciclo de vida. En este proceso se realiza un anlisis de riesgos de tipo econmico, tcnico, 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 gestin. De aqu surge el plan de contingencias donde se identifica los riesgos, se evalan y se gestionan. En la siguiente tabla se identifican las actividades a realizar, la documentacin que se obtine y cuales tcnicas se aplican.
Actividades a realizar Analizar los riesgos Realizar la planificacin de contingencias Gestionar el proyecto Archivar los registros Implementar el sistema de informes de problemas Documentacin de salida Anlisis de riesgos Plan de contingencias Registro histrico de proyectos Tcnicas a utilizar Anlisis de riesgo tcnico (Modelizacin y Simulacin Esttica y Dinmica, prototipado, revisiones, auditorias) Anlisis de riego econmico (Anlisis de finanzas, Retorno de la inversin) Anlisis de riesgo operativo y de soporte Anlisis de ri riesgo de programa (Anlisis del camino crtico CPM, Tcnicas de nivelacin de recursos)
Tabla 2: Proceso de seguimiento y control del proyecto
2.1.3 Proceso de gestin de la calidad del software El objetivo es la planificacin y administracin de las acciones necesarias para proveer una confianza adecuada en la calidad de los productos software que satisfagan los requerimientos tcnicos establecidos. En el proceso de gestin de la calidad del software se abarcan actividades en todo el ciclo de vida y se documenta en un plan de garanta de la calidad del software. Para abordar este proceso de proteccin del software globalmente se consideran los siguientes aspectos: Las mtricas para el control del proyecto, la verificacin y validacin, incluyendo pruebas, procesos de revisin, y la gestin de la configuracin del producto. Las mtricas del software se definen como la aplicacin continua de tcnicas basadas en las medidas de los procesos de desarrollo de software y de sus productos para producir una informacin de gestin significativa y oportuna, a la vez que se mejoran los procesos y sus productos. La verificacin y la validacin del software involucran actividades imprescindibles para el control de la calidad del software. Se entiende por verificacin al conjunto de actividades para la comprobacin de que un producto software esta tcnicamente 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 validacin trata la comprobacin 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 documentacin que se obtine y cuales tcnicas se aplican.
Actividades a realizar Planificar la garanta de la calidad del software Desarrollar mtricas de calidad Gestionar la calidad del software Identificar necesidades de mejora de la calidad Documentacin de salida Plan de garanta de calidad del software Recomendacio nes de mejora de calidad del software Tcnicas a aplicar Tcnicas de planificacin y Estimacin Mtricas de calidad del software
Tabla 3: Proceso de gestin de calidad del software
2.2
LECCIN 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 identificacin de una necesidad de automatizacin. Esta necesidad para ser satisfecha necesita de una nueva aplicacin, o cambio de todo o parte de la aplicacin existente. El proceso de pre-desarrollo abarca desde el reconocimiento del problema hasta la determinacin de los requisitos funcionales a nivel de sistema, pasando por el estudio de viabilidad de la solucin software. 2.2.1 Proceso de exploracin de conceptos Este proceso incluye la identificacin de una necesidad, la formulacin de soluciones potenciales, el estudio de viabilidad, y refinamiento a nivel de sistema. Una vez establecidos sus lmites, se genera el informe de la necesidad del sistema a desarrollar. Este informe inicia el proceso de asignacin del sistema y/o el proceso de requisitos, y alimentan los procesos de gestin del proyecto. El informe de la necesidad es un documento que constituye la base de todo el trabajo de ingeniera posterior. En la siguiente tabla se identifican las actividades a realizar, la documentacin y cuales tcnicas se aplican.
Actividades a realizar Identificar ideas o necesidades Formular soluciones potenciales Conducir estudios de viabilidad Planificar la transicin del sistema Refinar y finalizar la idea o necesidad Documentacin de salida Modelo de la situacin actual Modelo del dominio del problema Informe preliminar de necesidades Soluciones alternativas posibles Soluciones recomendadas Plan de transicin Informe del impacto de la transicin Tcnicas a aplicar Tcnicas de adquisicin de conocimientos Anlisis econmico Anlisis tcnico Anlisis alternativos Tcnicas de modelizacin (Diagramas DFD) Prototipado
Tabla 4: Proceso de exploracin de conceptos 2.2.2 Procesos de asignacin 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 especificacin de requisitos del software, la especificacin de requisitos del hardware y la especificacin 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 anlisis 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 anlisis de sistema requiere una comunicacin 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 investigacin realizar, pues si la comunicacin se rompe, el xito del proyecto entero estar en peligro. En el anlisis del sistema se definen los objetivos del mismo, la informacin que se va a obtener, la informacin que se va a suministrar, las funciones, el comportamiento y el rendimiento requerido. Una vez que la funcin, el rendimiento y las interfaces estn delimitados, se procede a realizar la tarea denominada asignacin. Durante la asignacin, las funciones son asignadas a uno o ms elementos genricos del sistema, es decir, software, hardware, personal, bases de datos, documentacin, 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 anlisis de requisitos y de diseo. Se representa el sistema definido mediante modelos de la arquitectura del sistema (salida, entrada, proceso y control, interfaz de usuario, mantenimiento y autocomprobacin). En primer lugar se realiza un diagrama de contexto de la arquitectura, que establece los lmites de informacin 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 ms detalle la funcin 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 lneas importantes de flujo de informacin (control y datos). El diagrama inicial de flujo de la arquitectura se constituye en el nodo raz de la jerarqua 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 descomposicin de arriba hacia abajo permite disponer de una jerarqua de diagramas de flujo del sistema, donde cada uno de ellos se puede utilizar como punto de partida para los posteriores pasos de ingeniera del subsistema que describe. En la siguiente tabla se identifican las actividades a realizar, la documentacin y cuales tcnicas se aplican.
Actividades a realizar Analizar funciones sistema Desarrollar arquitectura sistema Descomponer requisitos sistema las del la del los del
Documentacin de salida Especificacin de requisitos del sistema Especificacin de requisitos funcionales del hardware Especificacin de la interfaz del sistema Descripcin funcional del sistema Arquitectura del sistema
Tcnicas a aplicar Tcnicas de adquisicin de conocimientos Tcnicas de modelizacin (Diagramas DFD)
Tabla 5: Proceso de asignacin del sistema 2.3 LECCIN 3: PROCESOS DE DESARROLLO
Son los procesos que se deben realizar para la construccin del producto software. Estos definirn qu informacin obtener y como estructurar los datos, qu algoritmos usar para procesar los datos y cmo implementarlos, y qu interfaces desarrollar para operar con el software y cmo hacerlo. A partir del informe de la necesidad, con el soporte de las actividades de los procesos integrales y bajo el plan de gestin del proyecto, los procesos de desarrollo producen el software (cdigo y documentacin). 2.3.1 Procesos de requisitos Incluye actividades iterativas dirigidas al desarrollo de la especificacin de requisitos del software. Para la determinacin completa y consistente de todos los requerimientos del software el anlisis se enfatiza sobre la salida resultante, la descomposicin de los datos, el procesamiento de los datos, las bases de datos y las interfaces de usuario, del software y del hardware. La especificacin 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 operacin y soporte. Este documento es la salida con la cual culmina este proceso. Existen tres tipos de requerimientos: Requerimiento Funcional, que especifica la funcin que un sistema componente de un sistema debe ser capaz de realizar. o
Un requerimiento de rendimiento especifica una caracterstica numrica tanto esttica (nmero de terminales del sistema, nmero de usuarios simultneos que soportar el sistema, nmero de archivos o registros del mismo, etc.) como dinmica (tiempo de procesamiento en el sistema) que debe tener un sistema o componente de un sistema. Los requisitos de interfaz, que determinan caractersticas que el software debe soportar para cada interfaz humano del producto software (interfaz de usuario), las caractersticas lgicas 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 gestin de base de datos, un sistema operativo, un paquete estadstico) e interfaces con otros sistemas de aplicacin (interfaz de software). Existen adems otros atributos del software (seguridad, consistencia, facilidad de traza, etc.) que pueden dar lugar a requisitos especficos del mismo, por ejemplo la restriccin a determinados datos. En la siguiente tabla se identifican las actividades a realizar, la documentacin y cuales tcnicas se aplican.
Actividades a realizar Definir y desarrollar los requerimientos del software Definir los requerimientos de interfaz Priorizar e integrar los requerimientos del software Documentacin de salida Especificacin de requisitos del software Especificacin de requisitos de interfaz con el usuario Especificacin de requisitos de interfaz con otro software Especificacin de requisitos de interfaz con hardware Especificacin de requisitos de interfaz con el sistema fsico Tcnicas a utilizar Tcnicas orientadas a los procesos: Anlisis estructurado (Diagramas de flujo de datos DFD, Diccionario de datos DD, Especificacin de procesos primitivos EPP), SADT, Diagramas de transicin de estados, Diagramas de descomposicin, WRS, RBS, OBS, Actigramas. Tcnicas orientadas a datos: Diagramas entidad-relacin, datagramas Tcnicas orientadas a objetos: Diagramas de clases y objetos, jerarqua de clases y objetos Tcnicas formales de especificacin: Tcnicas relacionales (relaciones recurrentes, expresiones regulares), Tcnicas Orientadas al estado (Tablas de decisin, tablas de eventos, tablas de transicin, redes de PETRI), Tcnicas de prototipos.
Tabla 6: Proceso de requisitos o requerimientos
2.3.2 Proceso de diseo Su objetivo es realizar una representacin coherente y organizada del sistema software que satisfaga la especificacin de requisitos del software. La calidad de dicha representacin se puede evaluar. El proceso de diseo traduce el qu hacer de las especificaciones de los requerimientos en el cmo hacerlo de las especificaciones de diseo. Inicialmente, la representacin describe una visin sistmica y holstica del software. Posteriores refinamientos de diseo conducen a una representacin que se acerca al cdigo fuente. El diseo de software puede verse desde dos perspectivas: la tcnica y la de gestin del proyecto. Desde el punto de vista tcnico el diseo comprende cuatro actividades: diseo de los datos, diseo arquitectnico, diseo procedimental y diseo de interfaces. Desde el punto de vista de gestin del proyecto, el diseo va del diseo arquitectnico (diseo preliminar o de alto nivel) al diseo detallado (diseo de bajo nivel). Desde el punto de vista de la gestin, el nivel de diseo arquitectnico se focaliza en las funciones y estructuras de las componentes que conforman el sistema software. El nivel de diseo detallado se ocupa del refinamiento de la representacin arquitectnica que lleva a una estructura de datos detallada y a las representaciones algortmicas que se usan para cada componente modular del software. El proceso de diseo de software comienza con la actividad de realizar el diseo arquitectnico. Esta actividad genera la descripcin del diseo arquitectnico 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 diseo es realizar el diseo detallado, donde se genera la descripcin del diseo del software, que especifica la estructura de los datos, los algoritmos y la informacin de control de cada componente software, y los detalles de las interfaces (usuario, hardware y software). El diseo detallado se deriva del diseo preliminar; en consecuencia, sus correspondientes actividades se realizan en consecuencia mientras que el resto de las actividades de este proceso (analizar el flujo de informacin, disear la base de datos, disear las interfaces, desarrollar los algoritmos) se ejecutan en paralelo. Una actividad relevante es el diseo de la base de datos que comprende el diseo conceptual, lgico y fsico, 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 lgico dependiente de la implementacin. Finalmente, se definen las estructuras fsicas de datos y los caminos de acceso.
Como ya se mencion, desde el punto de vista tcnico y en el contexto de los diseos preliminar y detallado, se llevan a cabo varias actividades de diseo diferentes: diseo de datos, diseo arquitectnico, diseo procedimental y diseo de la interfaz. El diseo de datos, que transforma el modelo del campo de informacin, creado durante el anlisis, en las estructuras de datos que se van a requerir para implementar el software. El diseo arquitectnico, que define las relaciones entre los principales elementos estructurales del programa. El objetivo principal de este diseo es desarrollar una estructura de programa modular y representar las relaciones de control entre los mdulos. El diseo arquitectnico 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 diseo procedimental, que transforma los elementos estructurales en una descripcin procedimental del software; se realiza despus de que se ha establecido la estructura del programa y de los datos. El diseo de la interfaz, que establece principalmente la disposicin y los mecanismos para la interaccin hombre - mquina. El diseo 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 diseo es la nica forma mediante la cual se puede traducir con precisin los requerimientos del cliente en un producto o sistema acabado. El diseo de software sirve como base de todas las posteriores etapas del desarrollo y del proceso de mantenimiento. Para evaluar la calidad de una representacin del diseo se deben tener en cuenta las siguientes consideraciones: 1. Jerarquizacin, es decir, que debe exhibir una organizacin jerrquica que haga un uso inteligente del control entre los componentes del software. Modularidad, esto es, que el software debe estar dividido de forma lgica en elementos que realicen funciones y subfunciones especficas. separabilidad, o contener representaciones distintas y separadas de los datos y de los procedimientos. Independencia funcional, de modo que lleve a conseguir mdulos que exhiban caractersticas funcionales independientes.
2. 3. 4.
5. 6.
Conectividad, que lleva a producir interfaces que reduzcan la complejidad de las conexiones entre los mdulos y el entorno exterior. Reproductibilidad, es decir, que debe obtenerse mediante un mtodo que sea reproducible y que est conducido por la informacin obtenida durante el anlisis de los requerimientos del software.
En la siguiente tabla se identifican las actividades a realizar, la documentacin y cuales tcnicas se aplican.
Actividades a realizar Realizar el diseo arquitectnico Analizar el flujo de informacin Disear la base de datos Disear las interfaces Seleccionar o desarrollar algoritmos Realizar el diseo detallado Documentacin de salida Descripcin de diseo del software Descripcin de la arquitectura del software Descripcin del flujo de informacin Descripcin de la base de datos Descripcin de las interfaces Descripcin de los algoritmos Tcnicas a aplicar Tcnicas orientadas a los procesos: Diseo estructurado (Anlisis de transformacin, Anlisis de transaccin), Diseo del dilogo de las interfaces, Diseo lgico o diseo del perfil, HIPO. Tcnicas orientadas a datos: Modelo lgico de datos, modelo fsico de datos, Warnier, Jackson. Tcnicas orientadas a objetos: Modelos de clases/objetos, diagrama de mdulos. Tcnicas de diseo a bajo nivel: Programacin estructurada (diagramas arborescentes, diagramas de chapin), Programacin orientada a objetos (diagrama de procesos), warnier, Jackson, tcnicas de prototipado, tcnicas de refinamiento.
Tabla 7: Proceso de diseo 2.2.3 Proceso de Implementacin Este proceso transforma la representacin del diseo detallado de un producto software a una realizacin en un lenguaje de programacin apropiado. El proceso de implementacin produce el cdigo fuente, el cdigo de la base de datos y la documentacin, que constituyen la manifestacin fsica del diseo de acuerdo a los estndares y metodologas del proyecto. Adems, en este proceso se debe integrar el cdigo y la base de datos. En el caso de que el sistema conste de componentes hardware y software, se debe planificar y realizar la integracin del sistema.
La salida de este proceso esta sujeta a las pruebas de verificacin y validacin adecuadas. El cdigo y la base de datos junto con la documentacin producida durante los procesos previos son la primera representacin completa del producto software. En la siguiente tabla se identifican las actividades a realizar, la documentacin y cuales tcnicas se aplican.
Actividades a realizar Crear los datos de prueba Crear el cdigo fuente Generar el cdigo objeto Crear la documentacin de operacin Planificar la integracin Realizar la integracin Documentacin de salida Datos para las pruebas Documentacin del sistema Documentacin de usuario Plan de integracin Sistema software integrado Tcnicas a utilizar Warnier Jackson Lenguajes de programacin.
Tabla 8: Proceso de Implementacin 2.4 LECCIN 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 garanta de calidad para asegurar que se hayan generado y catalogado los registros, y documentos internos adecuados, que se ha desarrollado una documentacin 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 construccin al mantenimiento; correccin de errores, adaptacin al entorno y mejora de la funcionalidad. En todos los casos, la modificacin del software no solo afecta al cdigo, sino tambin a la configuracin entera, es decir, a todos los documentos, datos y programas desarrollados en la fase de planificacin y desarrollo. 2.4.1 Proceso de instalacin Implica el transporte y la instalacin 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 aceptacin del cliente. Si durante la instalacin surge un problema se identifica e informa acerca de l.
El proceso de instalacin verifica que se implemente la configuracin adecuada del software y termina con la aceptacin formal del mismo por parte del cliente conforme a lo especificado en el plan de gestin del proceso software y la realizacin con xito de la prueba de aceptacin del usuario. En la siguiente tabla se identifican las actividades a realizar y la documentacin.
Actividades a realizar Planificar la instalacin Distribuir el software Instalar el software Cargar la base de datos Aceptar el software en el entorno de operacin Documentacin de salida Plan de instalacin de software Informe de instalacin
Tabla 9: Proceso de instalacin 2.4.2 Proceso de operacin y soporte Involucra la operacin del sistema por parte del usuario y el soporte continuo al usuario que incluye asistencia tcnica, consultas con el usuario y registro de las peticiones de soporte en el histrico de peticiones de soporte. As, este proceso puede desencadenar la actividad del proceso de mantenimiento que provee informacin de realimentacin al ciclo de vida del software. En la siguiente tabla se identifican las actividades a realizar, y la documentacin.
Actividades a realizar Operar el sistema Proveer de asistencia tcnica y consultas Mantener el histrico de las peticiones de soporte Documentacin de salida Histrico de las peticiones de soporte
Tabla 10: Proceso de operacin 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 correccin de errores, a las adaptaciones requeridas por la evolucin 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:
Correccin: Incluso llevando a cabo las mejores actividades de garanta de calidad, es muy probable que el cliente descubra defectos en el software. El mantenimiento correctivo cambia el software para corregir los defectos. Adaptacin: 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 podra interesar que estuvieran incorporadas al software. El mantenimiento perfectivo ampla el software ms 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 exploracin de conceptos para mejorar la calidad del sistema software. En la siguiente tabla se identifican las actividades a realizar, y la documentacin.
Actividades a realizar Operar el sistema Proveer de asistencia tcnica y consultas Mantener el histrico de las peticiones de soporte Documentacin de salida Histrico de las peticiones de soporte
Tabla 11: Proceso de Mantenimiento 2.4.4 Proceso de Retiro Se puede decir que es la jubilacin de un sistema existente de su soporte activo o de su uso mediante el cese de su operacin o soporte, o su reemplazo por un nuevo sistema o por su actualizacin. Si el sistema en uso se reemplaza por un nuevo sistema se requiere un tiempo de operacin en paralelo. En este periodo se utiliza el sistema en retiro para los resultados oficiales, mientras se prepara el nuevo sistema para su operacin formal. Es un perodo de formacin para el usuario sobre el nuevo sistema y de validacin del mismo. En la siguiente tabla se identifican las actividades a realizar, y la documentacin.
Actividades a realizar Notificar al usuario Conducir las operaciones en paralelo Retirar el sistema Documentacin de salida Plan de retiro
Tabla 12: Proceso de retiro
2.5
LECCIN 5: PROCESOS INTEGRALES DEL PROYECTO
Son procesos simultneos y complementarios a los procesos orientados hacia el desarrollo. Incluyen actividades imprescindibles para que el sistema construido sea fiable (procesos de verificacin y validacin, gestin de la configuracin) y sea utilizado al mximo de sus capacidades (procesos de formacin, documentacin). 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 verificacin y validacin Abarca la planificacin y la realizacin de todas las tareas de verificacin, incluyendo pruebas de verificacin, revisiones y auditorias, y de todas las tareas de validacin, incluyendo pruebas de validacin, 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 verificacin y la validacin del software es la prueba del software. Constituye el proceso de ejecucin del software con determinados datos de entrada, para observar los resultados que produce y compararlos con los resultados tericos que debera producir, para esos datos de entrada, con el objeto de detectar posibles fallas. Las pruebas del software solo podrn realizarse cuando en el proceso de desarrollo ya exista cdigo ejecutable. La depuracin es un proceso frecuentemente asociado a las pruebas que consiste en tratar de deducir donde estn 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 documentacin y cuales tcnicas se aplican.
Actividades a realizar Planificar la verificacin y validacin Ejecutar las tareas de verificacin y validacin Recoger y analizar los datos de las mtricas Planificar las pruebas Desarrollar las especificaciones de las pruebas Ejecutar las pruebas Documentacin de salida Plan de verificacin y validacin Informes de evaluacin Plan de pruebas Especificacin de las pruebas Informe resumen de las pruebas Software aprobado Tcnicas a utilizar Tcnicas de prueba de caja blanca (cobertura de sentencias, cobertura de decisin y de ramificacin, cobertura de condicin, cobertura de decisin/condicin, cobertura de condicin mltiple) Tcnicas de prueba de caja negra (Particin de equivalencias, anlisis de valores lmites, grficos de causa/efecto, conjetura de error)
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD 50 ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA - ECBTI CURSO DE EVALUACIN DE SOFTWARE - CDIGO 301569__________________________________________ Revisiones formales Auditorias
Tabla 13: Proceso de verificacin y validacin 2.5.2 Proceso de gestin de la configuracin 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, mdulos, datos, archivos lo componen) en un momento dado a lo que se le denomina configuracin 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 evolucin de las configuraciones. La gestin de la configuracin realiza las siguientes funciones: Identificacin de la configuracin de un sistema o descripcin documentada de las caractersticas reales del sistema en un determinado momento; control de la configuracin, establece la configuracin inicial o bsica y controla los cambios en los elementos de la misma; informes del estado de la configuracin; auditorias de la configuracin, revisiones independientes de la configuracin para comprobar que los elementos de la configuracin cumplen los requisitos de configuracin establecidos. En la siguiente tabla se identifican las actividades a realizar, y la documentacin.
Actividades a realizar Planificar la gestin de la configuracin Realizar la identificacin de la configuracin Realizar el control de configuracin Realizar la informacin del estado de la configuracin Documentacin de salida Plan de gestin de configuracin del software Orden de cambio de ingeniera Cambio de estado Informe de estado
Tabla 14: Proceso de gestin de la configuracin 2.5.3 Proceso de desarrollo de documentacin El proceso de desarrollo de documentacin para el desarrollo y uso del software es el conjunto de actividades que planifican, disean, 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 documentacin.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD 51 ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA - ECBTI CURSO DE EVALUACIN DE SOFTWARE - CDIGO 301569__________________________________________ Actividades a realizar Planificar la documentacin Implementar la documentacin Producir y distribuir la documentacin Documentacin de salida Plan de documentacin
Tabla 15: Proceso de desarrollo de documentacin 2.5.4 Proceso de formacin Incluye la planificacin, desarrollo, validacin e implementacin de los programas de formacin de desarrolladores, personal de soporte tcnico y clientes o usuarios y la elaboracin de los materiales de formacin adecuados. Para conseguir una utilizacin efectiva del sistema software, se debe proporcionar a los usuarios del sistema instrucciones, gua y ayuda para el entendimiento de las capacidades del sistema y de sus limitaciones. Por ello es imprescindible la formacin 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 formacin de los desarrolladores y personal de soporte tcnico. En la siguiente tabla se identifican las actividades a realizar, y la documentacin.
Actividades a realizar Planificar el programa de formacin Desarrollar los materiales de formacin Validar el programa de formacin Implementar el programa de formacin Documentacin de salida Plan de formacin
Tabla 16: Proceso de desarrollo de formacin
CAPITULO 3
CONCEPTOS DE CALIDAD Y CALIDAD DEL SOFTWARE
INTRODUCCIN El avance informtico actual es muy alto comparado con lo se tena en los aos 90, al hablar de desarrollo de software se hace ms notable, en el hecho por ejemplo de pasar de una programacin de cdigo lnea a lnea, a un mtodo de programacin grfico orientado a objetos donde el desarrollo es mas rpido y atractivo para el cliente. Ms 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 grfica, 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 auditora de cualquier aplicacin informtica del mercado, teniendo en cuenta que hoy en da es muy importante para las empresas privadas o pblicas la inversin en este tipo de producto, los cuales verifican la calidad a la hora de entrar a produccin, donde se detectan las falencias, reportando all prdidas. Este captulo presenta indicadores de calidad de un software; al momento de la entrega, basados en los estndares de calidad sugeridos la norma ISO/IEC 9126; de la ISO (Organizacin Internacional de Normalizacin) y la IEC (Comisin Electrotcnica Internacional).
3.1
LECCIN 1: DEFINICIN 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 definicin breve: Quality is fitness for use; es decir, la calidad es la adecuacin del producto al uso donde esta definicin incluye las caractersticas del producto que permiten obtener la satisfaccin del usuario y, adems, supone la ausencia de deficiencias. Para P. Crossby el concepto de Juran se asume pero tambin destaca la prevencin: Cero defectos o Hacerlo bien a la primera. En la bibliografa son frecuentes las definiciones de calidad pero en su gran mayora todas ellas se acercan al concepto expresado por Juran. La definicin oficial, y ms completa, es la de la norma ISO 9000:2000 que define la calidad en general como: Grado en el que un conjunto de caractersticas inherentes cumple con los requisitos, donde los requisitos son las necesidades o expectativas establecidas, generalmente implcitas u obligatorias y las caractersticas se refieren a cualquier tipo de rasgo diferenciador. Tambin se debe recordar que las necesidades pueden variar en el tiempo, por lo que hay que prever la revisin de la especificacin. Esta definicin permite comprender que la consecucin de la calidad puede tener tres orgenes: 3.1.1 La calidad realizada: Que es la calidad obtenida por la persona que realiza el trabajo gracias a su habilidad en la ejecucin de una tarea. Se potencia con la mejora de las habilidades personales y tcnicas 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 elaboracin de una especificacin que sirva de buena referencia a los participantes en un proceso. Esta aperece descrita en una especificacin, en un documento de diseo o en un plano constructivo. 3.1.3 La calidad necesaria: La que el cliente exige con mayor o menor grado de concrecin o, al menos, la que le gustara recibir. Se potencia con una adecuada obtencin de informacin de la idea de calidad de los clientes y de su percepcin de la misma. La gestin de la calidad pretender entonces, conseguir que estos tres crculos coincidan entre s.
3.2
LECCIN 2: SISTEMAS DE CALIDAD EN LA EMPRESA
La poltica de la calidad forma parte de la poltica general de la empresa, por eso es importante que la direccin o gerencia exprese dicha poltica de manera explcita al igual que lo hace para la poltica financiera, de personal, etc. Por lo tanto, la gestin de la calidad forma parte de las tareas de la direccin, y para tener xito, se debe contar con el compromiso y la participacin de todos. Incluye la planificacin estratgica, la asignacin de recursos, las actividades sistemticas, y evaluaciones entre otras. Actualmente, de forma general, se suele apoyar en la creacin de lo que se denomina sistema de calidad para la organizacin. Un sistema de gestin de calidad es un un sistema para establecer polticas y los objetivos con respecto a la calidad y para lograr dichos objetivos se debe aplicar a la direccin y control de una organizacin. Este sistema de calidad se adeca a los objetivos fijados por la empresa en cuanto al tema. La direccin es la responsable de fijar las polticas 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 lneas de jerarqua y de comunicacin ligada al sistema de gestin de calidad. Para ser til el sistema de calidad debe cumplir con las siguientes caractersticas: 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 prctica. La parte escrita est en una serie de documentos en los cuales se describe el sistema, los procedimientos, entre otros, ajustndose a una norma habitualmente se usa la noma ISO 9001. Y la parte prctica que tiene dos vertientes principales, una que tiene en cuenta los aspectos fsicos (locales, herramientas, computadores) y otra que toma los aspectos humanos como la formacin del personal (tanto en tcnicas de calidad corno en tcnicas de reuniones, comunicacin) y en creacin y coordinacin 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 polticas y procedimientos. El manual de calidad debe describir adecuadamente el sistema de gestin de la calidad para servir como referencia permanente al implantar o al aplicar el sistema. El manual de calidad incluye las polticas de calidad que se han adoptado, la definicin del sistema de calidad, la presentacin de la estructura de la organizacin y la referencia a los procedimientos aplicables. Segn 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 Captulos de introduccin ndice Declaracin de la direccin de la empresa Poltica de calidad y objetivos generales de la empresa respecto a la calidad Objeto y campo de aplicacin del manual de calidad Terminologa Gestin del manual de calidad (procedimiento para cambios, aprobacin, etc.) Presentacin 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, adems es un elemento clave en el proceso de certificacin del sistema de calidad de la empresa. El manual de calidad se completa con procedimientos o instrucciones especficas para ciertas actividades o procesos que deben mencionarse explcitamente en dicho manual. Para cada empresa suelen existir procedimientos particulares, cuyo fundamento debe ser la buena prctica y la experiencia en el trabajo diario y los cdigos, las normas y las especificaciones a los que deben ajustarse. Para las organizaciones de desarrollo de software, se suelen incluir los procedimientos (tcnicas y metodologas) para realizar y documentar el anlisis de los sistemas, para realizar y documentar el diseo de los sistemas o de sus bases de datos, entre otros. En general, indicarn la metodologa a aplicar, algunos ejemplos tpicos de procedimientos relacionados con el desarrollo pueden ser el procedimiento de especificacin de requisitos del software, el procedimiento para las pruebas del software, el procedimiento de estilo de codificacin, etc. Otros documentos importantes en el sistema de calidad son los que aportan evidencias sobre la aplicacin 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 evaluacin 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 despus de acabar el proyecto para analizar las tendencias de la calidad obtenida y corregir las causas de defectos. Algunas de las caractersticas que debera tener la documentacin en cualquier caso son las siguientes: Tener como objetivo facilitar los medios para el buen funcionamiento del sistema de calidad, Tambin 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
LECCIN 3: NORMATIVIDAD DE CALIDAD
La normativa de calidad surge inicialmente en empresas de algunos de los sectores de seguridad crtica como el militar, nuclear, y aeroespacial. La normativa nuclear ha inspirado muchas otras normas, sin embargo, La revolucin normativa para todos los sectores se produjo con la llegada de la serie de normas ISO 9000, inicialmente con la norma de gestin 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 gestin interna de la calidad. Sin embargo, la reciente revisin de la serie 9000 realizada en el ao 2000, cambi la filosofa 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, aplicarn la ISO 9001:2000 limitando su mbito de aplicacin. El cambio de filosofa experimentado se basa en incrementar la importancia de la mejora continua y el ciclo PDCA (Plan-Do-Check-Act), as como una mayor definicin de los procesos y de la evaluacin de la satisfaccin 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 Gestin de calidad ISO 9001: 2000
En el caso del software que es un producto muy especial, fue necesario hacer una interpretacin de la versin ISO 9001:1994 generando la gua ISO 9000-3:1997 que es la Gua para aplicar ISO 9001 al desarrollo, suministro y mantenimiento de software. Con la llegada de la norma ISO 9001:2000, la gua ISO 9000-3 es aplicable y til aunque requiere una actualizacin. La gua contempla tres aspectos principales de disposiciones adaptadas a la terminologa y caractersticas especiales del software como producto, el primero es el marco de trabajo de la empresa (sistema de calidad, responsabilidad de la direccin y la realizacin de acciones correctivas), el segundo que muestra las actividades del ciclo de vida (Revisin de contrato, especificacin, planificacin, planificacin de la calidad, diseo, implementacin, revisiones, pruebas, aceptacin, replicacin, entrega, instalacin y mantenimiento), y el tercero donde estn las actividades de apoyo (Gestin de configuracin, control de documentos, mtricas, convenciones y reglas, herramientas, formacin, registros de calidad y compras). Desde el punto de vista prctico, la ISO 9001:2000 incluye las siguientes disposiciones: 3.3.1 Responsabilidad de la direccin Desde un mbito general muestra el compromiso con la satisfaccin del cliente, promoviendo una determinacin eficaz de requisitos y de las necesidades del cliente, establece una poltica de calidad que debe llevar a una planificacin de la calidad y de sus objetivos, a travs de un sistema de gestin de calidad en el que deben existir revisiones formales de la gestin realizada. 3.3.2 Gestin de recursos Para determinar y proporcionar lo necesario para la gestin de calidad, especialmente en el mbito de los recursos humanos donde debe realizarse la adecuada poltica de asignacin a tareas, determinar, realizar y evaluar el impacto de las acciones de formacin y cualificacin, y de competencias profesionales. No se deben olvidar otros recursos como la informacin, las infraestructuras necesarias y el entorno de trabajo. 3.3.3 Gestin de los procesos Con disposiciones para las actividades de gestin, los procesos relacionados con el cliente, el diseo y el desarrollo de productos y servicios, la gestin de compras y proveedores, la produccin y la operacin de servicios, el control de las no-conformidades de las entregas respecto de los requisitos establecidos y los servicios post-entrega.
3.3.4 Medicin, anlisis y mejora Contempla la medicin del rendimiento del sistema, medicin de procesos, medicin de productos y/o servicios y el control de la propia medicin y de los medios de inspeccin y prueba. En cuanto a anlisis de datos, se trata de obtener las conclusiones apropiadas para emprender acciones de mejora relacionadas con correcin de errores, prevencin de problemas para el futuro y el establecimiento de procesos de mejora continua. 3.4 LECCIN 4: INGENIERA DE SOFTWARE Y CALIDAD
Para hablar de la calidad en el software, se debe tener en cuenta que este es un producto con caractersticas particulares, por lo cual se hace necesario adaptar la terminologa creada y aplicada en los sectores industriales. Algunas de estas caractersticas del software son las siguientes: El software se desarrolla, no se fabrica ya que todo el costo de produccin se centra en el diseo de la primera copia. El software es un producto lgico, el verdadero producto del software es el diseo de una serie de instrucciones para el computador, su existencia en papel o en soporte magntico no es ms que una representacin en un cdigo o lenguaje de las instrucciones. El software no se degrada con el uso, ya que la naturaleza lgica del software permite que permanezca inalterable por muy intensa que sea su utilizacin. Se puede degradar su representacin magntica 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 pblicamente declarados. En el sector informtico, 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 produccin de software se hace an a medida. En vez de emplear componentes existentes y ensamblarlos, aunque las bibliotecas de funciones o componentes estn ya cambiando en parte esta situacin. 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 tambin un peligro que hay que controlar. El diccionario estndar de ingeniera del software IEEE Std.6l0, indica que software son los programas de ordenador, los procedimientos y, posiblemente, la documentacin asociada y los datos relativos a la operacin del sistema informtico. No se limita al cdigo solamente y se debe tener en cuenta el software en cualquier estado de evolucin (diseos, especificaciones, datos de prueba, etc), si se quiere obtener calidad en el software. Tambin conviene
recordar que la calidad del software se debe obtener a medida que se construye; no es un aadido que se pueda poner una vez desarrollado el software. 3.5 LECCIN 5: GESTIN DE LA CALIDAD DEL SOFTWARE
La definicin del estndar 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 definicin es la que ms se ajusta al concepto de concordancia del software producido con los requisitos explcitamente establecidos, con los estndares de desarrollo expresamente fijados y con los requisitos implcitos, no establecidos formalmente, que desea el usuario. Los requisitos se reflejan en la especificacin de requisitos de manera explcita, el documento constituye la culminacin de la etapa de anlisis 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 estndares y las normas, determinan cmo se debe realizar el proceso de desarrollo de software. Adems, existen requisitos implcitos, 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 trminos empleados en esta rea, algunos de ellos son: 3.5.1 Gestin de la calidad del software (Software Quality Management) Son las actividades coordinadas para dirigir y controlar una organizacin en lo relativo a la calidad. Esto se puede entender como el aspecto de la funcin general de la gestin que detemina y aplica la poltica de calidad (objetivos y directrices generales de calidad de una empresa). Normalmente la gestin de calidad se aplica a nivel de empresa, por lo que incluye planificacin estratgica, asignacin de recursos, etc. 3.5.2 Aseguramiento Assurance) de la calidad del software (Software Quality
Es la parte de la gestin de la calidad orientada a proporcionar confianza en que se cumplirn los requisitos de la calidad. A nivel del software, podra presentarse como el conjunto de actividades planificadas y sistemticas necesarias para aportar la confianza en que el producto satisfar los requisitos dados de calidad. Tambin 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 gestin de la calidad orientada al cumplimiento de los requisitos de la calidad. Suele incluir las tcnicas y actividades de carcter 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. Tambin, en el software, puede ser el proceso de verificar el propio trabajo o el de un compaero. 3.5.4 Verificacin y validacin del software (Software Verication and Validation) Que es una actividad ligada al control de la calidad en el mbito del software. La verificacin 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 tcnicamente bien construido y si funciona. Y la validacin que se refiere a comprobar si el software construido satisface los requisitos del usuario. Por lo tanto, son las actividades de comprobacin 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 haban solicitado.
GLOSARIO DE TRMINOS Automatizacin: Es el uso de sistemas o elementos computarizados y electromecnicos para controlar maquinarias y/o procesos industriales sustituyendo a operadores humanos. Ciclo de Vida: El ciclo de vida de software es la descripcin de las distintas formas de desarrollo de un proyecto informtico. Ciclo de Vida gil: Es un marco de trabajo conceptual de la ingeniera de software que promueve iteraciones en el desarrollo a lo largo de todo el ciclo de vida del proyecto. Existen muchos mtodos de desarrollo gil; la mayora minimiza riesgos desarrollando software en cortos lapsos de tiempo. El software desarrollado en una unidad de tiempo es llamado una iteracin, la cual debe durar de una a cuatro semanas. Cada iteracin del ciclo de vida incluye: planificacin, anlisis de requerimientos, diseo, codificacin, revisin y documentacin. 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. Estndar: 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 espaol Instituto de Ingenieros Elctricos y Electrnicos, una asociacin tcnico-profesional mundial dedicada a la estandarizacin, entre otras cosas. ISO: (Internacional Standards Organization) Organizacin Internacional de estndares fundada en 1946, con sede principal en Ginebra, ISO establece o fija estndares internacionales. Se ocupa de todos los campos, excepto la electricidad y la electrnica, que se rigen por la Internacional Electrotechnical Comisin (IEC), tambin 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 podran ser sistematizadas. Proceso: El proceso de ingeniera de software se define como un conjunto de etapas parcialmente ordenadas con la intencin de logra un objetivo, en este caso, la obtencin de un producto de software de calidad. Requerimientos: Caractersticas que se desea que posea un sistema o un software.
Calidad: La calidad es herramienta bsica para una propiedad inherente de cualquier cosa que permite que esta sea comparada con cualquier otra de su misma especie. Calidad de Software: Caractersticas propias del software que se desea controlar y asegurar, el software es un producto inmaterial que no se fabrica, tampoco se degradan fsicamente, sino que se desarrolla; El software puede tener errores, incidencias pero no son similares a lo que cualquier equipo de carcter fsico. ISO 9001: Es un conjunto de normas sobre la calidad y la gestin. Gestin de Calidad de Software: Es un conjunto de actividades de la funcin general de la Direccin que determina la calidad, los objetivos y las responsabilidades. Se basa en la determinacin y aplicacin de las polticas de calidad de la empresa.
FUENTES DOCUMENTALES Bibliografa de referencia: Beck, K.. .Extreme Programming Explained. Embrace Change., Pearson Education, 1999. Traducido al espaol como: .Una explicacin de la programacin extrema. Aceptar el cambio., Addison Wesley, 2000. CETTICO, Centro Transferencia tecnolgica en Informtica y Comuicaciones., Enciclopedia de Informtica y Computacin, Ingeniera de software e Inteligencia artificial. Universidad Politcnica de Madrid 1999. De Domingo, J. y Arranz, A., Calidad y mejora continua, Ed Donostiarra. 1997. Piatini, Mario y col. Analisis y Diseo de Aplicaciones Informticas de Gestin, Una Perspectiva de Ingeniera de Software, Alfaomega 2004. Pginas 109 164. BRAUDE. Ingeniera de software, una perspectiva orientada a objetos. Mxico. 2003. Alfaomega grupo editor. S.A. HUMPHREY, Watts S. Introduccin al proceso de software personal. Pearson Addison wesley. 2001. NORRIS. Ingeniera de software explicada. Grupo Noriega editores de Colombia. PIATTINI, Mario. VILLALBA, Jose y otros. Mantenimiento del software: modelos, tcnicas y mtodos para la gestin del cambio. Editorial Alfaomega-Rama. PRESSMAN, Roger S. Ingeniera del Software. Un enfoque prctico. Quinta edicin. Espaa. 2002. Editorial McGraw Hill. SOMMERVILLE, Ian. Ingeniera de software. 6. Edicin. Pearson Addison Wesley. 2001 Direcciones Electronicas (webgrafa) 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
UNIDAD 2
Nombre de la Unidad Introduccin ESTNDARES, MTRICAS DE CALIDAD Y PRUEBAS DEL SOFTWARE En este captulo se trata los temas que son el fundamento de la calidad del software y su evaluacin, entre ellas estn los modelos y estndares actuales de calidad, que detallan las caractersticas mediante las cuales se hace la evaluacin, las mtricas de calidad y las mtricas tcnicas de calidad del software que son los indicadores, las escalas de medicin cualitativa o cuantitaiva y las pruebas del software que se ejecutan para verificacin de la calidad del producto o proceso. Esta unidad es quiza una de las ms importantes para la evaluacin del software, ya que se identifica en ella los tipos de evaluacin esttica y dinmica mediante el uso de las mtricas y las pruebas del software. Los estndares son los que permiten referencias cuales caractersticas se evaluar y que mtricas y pruebas se asocian a ellas. - El estudiante conoce los estndares y modelos utilizados para la evaluacin de la calidad del software - El estudiante reconoce las caractersticas internas, externas y de usabilidad dentro de los estndares - El estudiante asocia cada una de las caractersticas con las mtricas y las pruebas a realizar en cada caso - El estudiante define de acuerdo a las especificaciones del cliente, las caractersticas, subcaractersticas, mtricas y pruebas a utilizar CAPITULO 4: ESTANDARES Y MODELOS DE CALIDAD DEL SOFTWARE Leccin 1. La Calidad del Software Leccin 2. Calidad del Producto Software Norma ISO/IEC 9126 Leccin 3. Calidad del Producto software Norma ISO/IEC 14598 Leccin 4. Calidad del Producto Software Norma ISO/IEC 25000 (SquaRE) Leccin 5. Modelos de Mejora de Procesos de Software. CAPITULO 5: MTRICAS DE CALIDAD SOFTWARE Leccin 1. Conceptos Bsicos de Mtricas DEL
Justificacin
Denominacin de captulos Denominacin de lecciones Denominacin de lecciones Denominacin de lecciones Denominacin de lecciones Denominacin de lecciones Denominacin de captulos Denominacin de
lecciones Denominacin de lecciones Denominacin de lecciones Denominacin de lecciones Denominacin de lecciones Denominacin de captulos Denominacin de lecciones Denominacin de lecciones Denominacin de lecciones Denominacin de lecciones Denominacin de lecciones
Leccin 2. Mtricas del Software Leccin 3. Mtricas de Calidad del Software Leccin 4. Mtricas Tcnicas del Software Leccin 5. Estructura para las Mtricas de Calidad del software CAPITULO 6: PRUEBAS DEL SOFTWARE Leccin 1. La Prueba del software Leccin 2. Tcnicas de diseo de Casos de Prueba Leccin 3. Estrategias de Aplicacin de Pruebas del Software Leccin 4. Pruebas de Software para Objetos Leccin 5. Pruebas de Software Basado en Componentes
UNIDAD 2
ESTNDARES, MTRICAS DE CALIDAD Y PRUEBAS DEL SOFTWARE
CAPITULO 4
ESTNDARES Y MODELOS DE CALIDAD DEL SOFTWARE
INTRODUCCIN La calidad es un concepto complejo, que se viene aplicando en el campo de la informtica desde hace muchos aos. En particular, la aplicacin de la calidad al producto software toma cuerpo con la aparicin 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 acadmico. En el ao de 1987 la oficina internacional para la estandarizacin (ISO) y la Comisicin Electrotcnica internacional (IEC), constituyeron un comit tcnico conjunto con la finalidad de proponer normas internacionales en el campo de las tecnologas de la informacin y los equipos. En 1985 se inici el desarrollo la norma internacional ISO/IEC y fue publicada en 1991 como ISO/IEC 9126:1991: Tecnologa de la Informacin Evaluacin del Producto Software Caractersticas de la Calidad y Gua para su Aplicacin. Utilizaron como base para la definicin de las caractersticas, el concepto de calidad que posteriormente aparecera en la norma ISO 8402 y que est basada en las necesidades del usuario. Antes de la publicacin 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 trminos de calidad referido al producto software y proponer una estructura basada en caractersticas y subcaractersticas de calidad. En 1994, se determina la revisin de la norma ISO/IEC 9126 debido a que se estaban desarrollando normas internacionales en el rea de evaluacin de la calidad de productos. Resultado de la revisin, 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 evaluacin de la calidad del producto. La publicacin completa de ambas series, se iniciaron en julio de 1998 y concluyeron en abril de 2004, habindose 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 orientndose a ver la calidad del producto como resultado de un proceso. La serie de normas internacionales tendrn la numeracin 25000 y an no esta completa. Cada una de estas normas est dividida en caractersticas y subcaractersticas internas, externas y de usabilidad que hacen posible definir las mtricas asociadas a cada una de estas y el tipo de pruebas que se deben llevar a cabo en la evaluacin de software.
4.1
LECCIN 1: LA CALIDAD DEL SOFTWARE
El software es un componente presente en una gran cantidad de actividades y su correcta operacin es a menudo crtica para el xito del negocio y/o la seguridad de las personas. El desarrollo o seleccin de productos software de gran calidad es, por tanto, de suma importancia. Una especificacin y evaluacin 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 caractersticas de la calidad y teniendo en cuenta el propsito del uso del producto software. Es importante que cada caracteristica relevante de la calidad del producto software sea especificada y evaluada utilizando mtricas validadas o de amplia aceptacin. En la norma ISO/IEC 14598 se define al modelo de calidad como un conjunto de caractersticas y la relacin 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 caractersticas y subcaractersticas y en el tercer nivel presenta las mtricas; estas ltimas se pueden obtener de la medicin de los diversos atributos que tiene el producto y que influyen en cada subcaracterstica.
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 visin trascendental que puede ser reconocida pero no definida, la visin del usuario como la adecuacin al propsito del usuario, la visin del productor como conformidad con la especificacin, la visin del producto basada en las caractersticas observables del producto, y la visin 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 visin 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 grfico tambin 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 comprobarn en un proceso de verificacin que permitir medirlo, el cumpliemiento de requisitos de calidad externa se comprobarn en un proceso de validacin que permitir medirlo y finalmente la satisfaccin de las necesidades de la calidad del producto se comprobarn en un proceso de evaluacin que permitir medir la calidad en uso.
Figura 10: Calidad en el ciclo de vida del software 4.2 LECCIN 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 continuacin 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 caractersticas 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 caractersticas del producto software desde una perspectiva externa. Es la calidad del software cuando es ejecutado, la cual es tpicamente medida y evaluada mientras se prueba en un ambiente simulado, con datos simulados y usando mtricas externas. Durante las pruebas, muchas fallas sern descubiertas y eliminadas. Sin embargo algunas fallas todava pueden permanecer despus de las pruebas. Como es difcil corregir la arquitectura de software u otros aspectos fundamentales del diseo del software, el diseo fundamental permanece sin cambios a travs de las pruebas. En la siguiente figura se representa el modelo de calidad interna o externa, se muestra un conjunto de seis caractersticas: 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 caractersticas y las definiciones de cada una de ellas.
Caracterstica Funcionalidad Fiabilidad Usabilidad Eficiencia Facilidad mantenimiento Portabilidad de Definicin Capacidad del producto software para proveer las funciones que satisfacen las necesidades explcitas e implcitas cuando el software se utiliza bajo condiciones especficas. Capacidad del producto software para mantener un nivel especificado de funcionamiento cuando se est utilizando bajo condiciones especficadas 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 desempeo 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 adaptacin 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: Caractersticas 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 especfico y un contexto de uso especfico. ste mide la extensin 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 caractersticas: efectividad, productividad, integridad, y satisfaccin.
Figura 12: Modelo de calidad del producto software para la calidad en uso. La definicin de cada una de las caractersticas de la calidad en uso se muestra en la siguiente tabla:
Carcaterstica Efectividad Productividad Integridad Satisfaccin Definicin La capacidad del producto software para permitir a los usuarios lograr las metas especificadas con precisin y completitud en un contexto de uso especfico La capacidad del producto software para permitir a los usuarios emplear cantidades apropiadas de recursos en relacin a la efectividad lograda en un contexto de uso especfico La capacidad del producto software para lograr niveles aceptables de riesgo de dao a las personas, negocio, software, propiedad o entorno en un contexto de uso especfico La capacidad del producto software para satisfacer a los usuarios en un contexto de uso especfico
Tabla 18: Caractersticas de la calidad en uso ISO/IEC 9126 Las mtricas de calidad del producto se aplican a los diversos atributos del producto y permiten determinar posteriormente los niveles de calidad del producto. Las mtricas que se pueden aplicar de acuerdo a los atributos estn 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 sealan que las mtricas presentadas no pretenden ser exhaustivas y completas, ni limita la posibilidad de usar otras mtricas de acuerdo a las necesidades del usuario. Las mtricas internas pueden ser aplicadas durante el diseo y la codificacin del producto software no ejecutable y proporciona a todos los involucrados el beneficio de conocer la calidad del producto duracte su
construccin y tomar decisiones sobre esa base para conseguir el producto con la calidad esperada. Las mtricas externas pueden ser aplicadas durante la prueba y operacin del producto software ejecutable y proporciona a todos los involucrados el beneficio de conocer la calidad del producto software durante las pruebas u operacin y saber si cumple con la calidad esperada. Las mtricas de calidad en uso miden el nivel en que un producto software cumple con las necesidades especficas de los usuarios en un contexto de uso determinado por los escenarios en los que el usuario realiza sus tareas. 4.3 LECCIN 3: CALIDAD DEL PRODUCTO SOFTWARE NORMA ISO/IEC 14598 El estandar ISO/IEC 14598 es actualmente usado como base metodolgica para la evaluacin del producto software. Los productos de software son solo una parte de la historia, tambin es necesario considerar mediciones en el proceso empleado para disear, desarrollar, probar, y controlar el producto. En esto juega un papel importante la ISO/IEC 14598 que ofrece una visin general, explica la relacin entre su serie y el modelo de calidad de la ISO/IEC 9126, define los trminos tcnicos utilizados, contiene requisitos generales para la especificacin y evaluacin de la calidad del software, y clarifica los conceptos generales. Adems provee un marco de trabajo para evaluar la calidad de todos los tipos de productos software y establece requisitos para los mtodos de medicin y evaluacin de los productos de software. Es importante sealar 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 mtodos de medicin y para el proceso de evaluacin. La norma ISO/IEC 14598 consta de seis partes que describen los requisitos del proceso de evaluacin 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: Visin General Bsicamente provee una visin general de las otras cinco partes y explica la relacin entre la evaluacin del producto software y el modelo de calidad definido en la ISO/IEC 9126. Adicionalmente, hace la presentacin del proceso de evaluacin desglosado en los siguientes pasos: Establecer los requerimientos de evaluacin, especificar la evaluacin, planear la evaluacin, Ejecutar la evaluacin. 4.3.2 ISO/IEC 14598 Parte 2: Planificacin y Gestin Esta parte contiene los requerimientos y las guas para las funciones de soporte tales como el planeamiento y gestin para la evaluacin del producto del software. Fundamentalmente, en esta parte, se planifican las mediciones y las actividades de evaluacin, especficamente se incluye: Preparacin de las polticas, definicin de objetivos organizacionales y de mejora, identificacin de la tecnologa, asignacin de responsabilidades, Identificacin e implementacin de tcnicas de evaluacin para software desarrollado y adquirido, entrenamiento en tecnologa, recopilacin de datos y herramientas, comparacin y administracin de mejoras dentro de la organizacin. 4.3.3 ISO/IEC 14598 Parte 3. El Proceso para desarrolladores Esta parte provee los requerimientos y las recomendaciones para la evaluacin del producto software cuando la evaluacin 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 evaluacin 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 caractersticas fundamentales de calidad y el marco de trabajo, deben ser definidas las etapas siguientes: 4.3.3.1 Organizacin: 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 tcnicamente 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 relacin 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 medicin y valores objetivos que contribuyan a la cuantificacin de la calidad del software, todo esto puede enfocarse por proyecto o por producto. 4.3.3.4 Diseo y planeamiento: Los procedimientos requeridos para el anlisis y recopilacin de datos necesitan ser definidos. De esta manera, el plan incluir: Cronogramas, asignacin de responsabilidades, uso de herramientas, bases de datos y entrenamiento especializado requerido. La precisin de las mediciones y tcnicas estadsticas deben ser especificadas. En esta fase tambin deber consideerarse como los resultados de las mediciones impactarn 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 anlisis apropiados y se toman acciones necesarias. En cada fase del desarrollo debe procurarse lograr un montaje primeramente enfocado a las caractersticas 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 revisin general para determinar la efectividad global del ejercicio de recoleccin, para identificar costos versus costos, establecer la validez de las mtricas usadas e identificar puntos en los cuales podran obtenerse beneficios para proyectos futuros. El resultado de esta revisin podra 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 evaluacin del producto software sea conducida en funcin 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 segn ciertas especificaciones o pre-desarrollados para un mercado ms general. Los compradores tambin podran ser desarrolladores que desean integrar productos estndar en sus propios diseos de software, o de desarrolladores buscando herramientas especficas de software. Al respecto, cuatro etapas son necesarias: Establecimiento de los requerimientos: El alcance de la evaluacin 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 debern ser tambin considerados. El tiempo de la evaluacin necesita ser consistente con los objetivos; enfoques muy tempranos podran no proporcionar una figura adecuada de la situacin mientras que enfoques muy tardos podran ser muy limitados en su uso. 4.3.4.1 Especificacin de la Evaluacin: Durante la redaccin de las especificaciones, debe considerarse: Los requerimientos de calidad a ser evaluados correlacionados con la calidad en uso y mtricas externas con prioridades adems de un umbral de aceptacin definido, el alcance y lo que cubren los casos de prueba donde sean aplicables referencias a mdulos de evaluacin, los mtodos de recoleccin de mediciones, informacin requerida y mtodos de anlisis. 4.3.4.2 Diseo de la Evaluacin: El tipo de evaluacin depende del tipo de software que est siendo evaluado. Software bajo desarrollo puede ser abordado en puntos discretos durante el desarrollo o cuando estcompleto. Un plan de evaluacin necesita considerar: Necesidades de acceso a la documentacin del producto, herramientas de desarrollo y personal, requerimientos en costos y conocimientos, cronograma de evaluacin y arreglos de contingencia, y criterio para decisiones de evaluacin, mtodos y herramientas de reporte, procedimientos para la validacin y estandarizacin sobre proyectos futuros. 4.3.4.3 Ejecucin de la Evaluacin: Aunque esta etapa podra ser simplemente un registro en un libro de seguimiento, podra tenerse la necesidad de incluir: Los resultados mismos y la trazabilidad del producto as como informacin de configuracin, registros de anlisis, resultados y decisiones, problemas, limitaciones en las mediciones y cualquier compromiso con relacin a los objetivos originales, conclusiones sobre los resultados de la evaluacin pero tambin sobre los mtodos empleados.
4.3.5 ISO/IEC 14598 - Parte 5: El Proceso para Evaluadores Esta parte provee los requerimientos y recomendaciones para la evaluacin del producto software cuando la evaluacin es conducida por evaluadores independientes. En esta parte tiene un rol importante los requerimientos de evaluacin, las especificaciones de evaluacin,el diseo de la evaluacin, las actividades de evaluacin y el reporte de evaluacin.Estas etapas son resumidas a continuacin: 4.3.5.1 Requerimientos de Evaluacin: Los requerimientos deberan adicionalmente definir: La extensin del la cobertura (o el alcance), los objetivos de evaluacin y mtodos de reporte, las calificaciones e independencia requeridas de un evaluador. 4.3.5.2 Especificacin de la Evaluacin: Las especificaciones adicionalmente deberan cubrir: Definicin del alcance y formato en las mtricas empleadas identificando como debern ser derivadas a partir de los requerimientos del producto, la identificacin de mediciones no determinsticas para asegurar que ciertos niveles de frecuentabilidad y objetividad requeridos sean obtenidos, la identificacin de mtodos de correlacin con relacin a los resultados de las mediciones. Se tienen identificadas tres sub-actividades con relacin a la especificacin de la evaluacin: El anlisis de la descripcin del producto, la especificacin de las mediciones a ser realizadas, la verificacin de la especificacin resultante frente a los requerimientos de evaluacin. 4.3.6 ISO/IEC 14598 - Parte 6: Documentacin de los Mdulos de Evaluacin Esta parte provee las guas para la documentacin del mdulo de evaluacin. Estos mdulos representan la especificacin del modelo de calidad y las correspondientes mtricas internas y externas que sern aplicadas a una evaluacin en particular. Incluye mtodos y tcnicas de evaluacin ms las mediciones actuales resultantes de su aplicacin. En esta parte tambinse considera la administracin efectiva de complejidades inherentes a las cuestiones de medicin. Las actividades de medicin coordinadas son una caracterstica para una evaluacin efectiva y un plan necesita proveer un cronograma de evaluacin que provea al mismo tiempo informacin ptima cuando la evaluacin sea conducida durante el desarrollo. Los mdulos de la evaluacin son componentes claves de la ISO/IEC 14598-6 y son usados para proveer un formato consistente y repetible de reporte.Dichos mdulos proveen: Visibilidad de la informacin necesitada para cuadrar con requerimientos especficos de calidad, Documentacin de las interfaces necesarias con herramientas de medicin.
4.4 LECCIN 4: CALIDAD DEL PRODUCTO SOFTWARE NORMA ISO/IEC 25000 (SquaRE) Desde el ao 2000 se viene trabajando el proyecto SquaRE que pretende establecer un modelo para la especificacin y evaluacin de un producto software, lo que ha llevado a reordenar la actual distribucin 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 (Evaluacin del software). Uno de los principales objetivos de la serie SQuaRE es la coordinacin y harmonizacin del contenido de ISO 9126 y de ISO 15939:2002 (Measurement Information Model). ISO 15939 tiene un modelo de informacin que ayuda a determinar que se debe especificar durante la planificacin, performance y evaluacin de la medicin. Para su aplicacin, cuenta con los siguientes pasos: Recopilar los datos, Preparacin de los datos y Anlisis de los datos. La integracin de ISO 9126 e ISO 15939 permiten plantear un proceso de 4 pasos: El primero, la identificacin 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 evaluacin de calidad, el segundo, la identificacin del contexto de interpretacin. Es decir, seleccin de los valores de referencia y determinacin de los target especificados en un contexto determinado, tercero, uso de las medidas derivadas de la etapa de preparacin de los datos, y el cuarto, comparacin y anlisis de los resultados obtenidos respecto de un conjunto de valores de referencia.
SQuaRE incluye un estndar de requerimientos de calidad. Est compuesto por 14 documentos agrupados en 5 tpicos: Administracin de la Calidad 2500n, Modelo de Calidad 2501n, Medidas de Calidad 2502n, Requerimientos de Calidad 2503n y Evaluacin de la Calidad 2504n. Administracin de la Calidad: Abarca la Gua para SquaRE y Planificacin y Administracin. Modelo de Calidad: Describe el modelo de calidad interno / externo y la calidad en uso y presenta caractersticas y subcaractersticas. Medidas de Calidad: Medicin 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 trminos de requerimientos de calidad durante todo el ciclo de vida de un proyecto de software o adquisicin, mantenimiento y operacin. Evaluacin de la Calidad: Evaluacin de la Calidad, Proceso para desarrolladores, Proceso para compradores, Proceso para evaluadores y Documentacin del mdulo de evaluacin. En la figura siguiente se puede apreciar el modelo de referencia SquaRE, de la cual hay una reestructuracin de los contenidos, se alinea a otros documentos existentes, y se amplian aspectos que las normas anteriores slo se seala a manera de informacin.
Figura 15: Modelo de referencia para la arquitectura Square
LECCIN 5: MODELOS DE MEJORA DE PROCESOS DE SOFTWARE La mejora de proceso software es un mecanismo de mejora continua de la calidad, el cual bsicamente consiste en aplicar de forma consistente las prcticas que proporcionan buenos resultados y eliminar o cambiar aquellas prcticas que causan problemas. Para aplicar la mejora de proceso software, es necesario tener claro tres aspectos fundamentales: Seleccin del modelo de mejora del proceso a utilizar, Seleccin del modelo de proceso a utilizar como referencia, Seleccin del mtodo a utilizar en la etapa de evaluacin. A continuacin se indican de forma breve cmo han ido surgiendo los diferentes modelos de mejora continua del proceso software, as como los diferentes mtodos de evaluacin en el mundo. 5.1 Estados Unidos
En noviembre de 1986, el Instituto de Ingeniera 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 versin 1.0 del Modelo de Madurez de Capacidad para el Software (Capahility Maturity Model, CMM). Utilizando este modelo como base, el SEI comercializ dos mtodos para determinar la madurez del proceso software de una empresa: Evaluacin del Proceso Software y Valoracin de la Capacidad Software. La versin 1.1 del CMM public en febrero de 1993 junto con la actualizacin del mtodo SCE (v.2.0) para que estuviese alineado con la versin 1.1 del CMM. Muchas empresas han modificado el mtodo SPA para alinearlo con la versin 1.1 del CMM; una de estas empresas ha sido el Instituto para la Mejora del Proceso Software que ha propuesto el mtodo de Evaluacin Enfocado en la Accin. En mayo de 1995, el SEI actualiz el SPA, denominndose mtodo de Evaluacin 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 ms 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
Unin Europea
En 1988, la Comisin de la Comunidad Europea comenz a realizar un estudio sobre el comportamiento de su principal programa de Tecnologas de la Informacin, el Programa Estratgico Europeo para la Investigacin en Tecnologas de la Informacin descubrindose que la transferencia de tecnologa en el rea particular de la ingeniera del software no haba tenido el xito esperado a diferencia de lo acaecido en otras reas como la fabricacin. As, entre octubre de 1990 y febrero de 1993, la CEC desarroll un proyecto ESPRIT de investigacin denominado BOOTSTRAP para dotar a Europa de un mtodo de evaluacin 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 estndares lSO 9000 y el modelo genrico de proceso, PSS 005, de la Agencia Espacial Europea. A partir de febrero de 1991, el mtodo ha sido gestionado y desarrollado por un grupo de inters econmico europeo, llamado Instituto Bootstrap, el cual public la versin 2.3 en septiembre de 1995 y la versin 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 investigacin, denominado ImprovelT, para analizar los mtodos de evaluacin y valorar la capacidad de ingeniera del software de los contratistas potenciales. Este estudio descubri que existan numerosos mtodos de evaluacin que estaban en uso o bajo desarrollo. Tambin identific un apoyo muy extendido por parte de las empresas al desarrollo de un mtodo comn de dominio pblico y, preferiblemente, respaldado por un estndar internacional. As, en junio de 1991, el grupo de Estndares Internacionales para la Ingeniera del Software aprob un perodo de estudio con base de ImprovelT, para investigar la necesidad y las caractersticas de un estndar de evaluacin del proceso software. El informe del estudio indicaba que exista un consenso internacional sobre la necesidad y los requisitos de un estndar de evaluacin del proceso software. En junio de 1992 se estableci un nuevo grupo de trabajo para desarrollar este estndar internacional que, en enero de 1993, lanz el proyecto denominado Mejora del Proceso Software y Determinacin de la Capacidad para desarrollar un estndar internacional de evaluacin y mejora del proceso software. El proyecto toma como base las mejores caractersticas de los siguientes mtodos y/o modelos de evaluacin: CMM, TRILLIUM, Software Technology Diagnostic (STD) y Bootstrap. El conjunto de los borradores de SPICE se publicaron como informes tcnicos durante 1995; posteriormente le ha seguido un perodo de prueba que an no ha finalizado. De hecho, se dice que actualmente se encuentra en fase de pruebas y slo en el entorno de grandes empresas, sin existir todava experimentacin comercial con el mtodo. Finalmente, en 1998 se convirti en el estndar internacional ISO/IEC 15504 versin 3.3 de evaluacin del proceso software.
Actualmente, las dos lneas, CMM e ISO 15504, han confluido en lo que se ha denominado CMMI (capability Maturity Model integration). CMMI contempla ambas visiones mediante su representacin continua (perspectiva ISO) [CMMI, 2001a] y por etapas (perspectiva CMM) [CMMI, 2001b]. Tambin se incluye un mtodo de evaluacin 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 evala el estado actual de la prctica de software (diagnstico). Posteriormente, se establecen la estrategia de implementacin y los planes de accin para la mejora (establecimiento). Por ltimo, se ejecutan los planes y las mejoras recomendadas (actuacin) y se difunden (analizando las lecciones aprendidas y los resultados de la mejora, al mismo tiempo que se revisa la aproximacin realizada) para el siguiente ciclo de mejora. 5.5 ISO/IEC TR 1550 Parte 7
Gua para utilizacin 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 continuacin, se describen brevemente cada una de las etapas del modelo de mejora: Compromiso a la mejora del proceso software por parte de la Alta Direccin para que se involucre en el proyecto de mejora, Evaluacin del proceso software para determinar cul es el estado actual del proceso software de la compaa, es decir sus puntos fuertes y dbiles, 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, Implantacin 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 evaluacin son el Modelo de Madurez de la Capacidad (CMM) y la parte 2 del estndar ISO 15504. Como se ha indicado anteriormente, el modelo de procesos se utiliza en la etapa de evaluacin con objeto de conocer cmo est el propio proceso software de la empresa con respecto a dicho modelo.
La etapa de evaluacin se puede llevar a cabo desde dos puntos de vista diferentes: Enfoque de evaluacin del proceso que es un enfoque colaborativo y su objeto es determinar las fortalezas y debilidades del proceso software de la compaa, y el enfoque de valoracin de la capacidad software que se trata ms bien de un enfoque auditor y su objeto es identificar qu subcontratistas cualificados podrn llevar a cabo el desarrollo software a contratar. Actualmente, con el nuevo CMMI se utiliza el mtodo SCAMPI como mtodo de evaluacin para la mejora del proceso.
CAPITULO 5
MTRICAS DE CALIDAD DEL SOFTWARE
INTRODUCCIN Los trminos de mtricas, medicin, y medida en muchos de los casos han sido relacionados con los instrumentos utilizados mediante un mtodo especfico al acto mecnico de tomar una medicin mediante escalas cualitativas o cuantitativas que determinan los valores de esa medicin. En general es as, pero los tres conceptos son diferentes, y sern tratados en este captulo. Pero lo que no se puede admitir es que sea un acto mecnico ya que el proceso de medicin involucra muchas actividades, inicia con la seleccin y definicin de la caracterstica que se quiere medir, posteriormente se definir que mtricas es posible usar para la medicin, luego se definir la escala de tipo cuantitativo o cualitativo y el mtodo, y por ltimo se procede a hacer al anlisis de cmo se hara la medicin. En este captulo se tratar estos temas tan importantes para el proceso y procedimiento de la evaluacin de software, que se convertirn en la clave para realizarla, ya que, de ella depende el xito o fracaso de la evaluacin.
5.1
LECCIN 1: CONCEPTOS BSICOS DE MTRICAS
La palabra mtrica, es muy comn asociarla con las palabras medicin y medida, aunque estas tres son distintas. La medicin es el proceso por el cual los nmeros o smbolos son asignados a atributos o entidades en el mundo real tal como son descritos de acuerdo a reglas claramente definidas. La medida proporciona una indicacin cuantitativa de la extensin, cantidad, dimensiones, capacidad o tamao de algunos atributos de un proceso o producto. Mtrica se define como una medida cuantitativa del grado en que un sistema, componente o proceso posee un atributo dado o tambin una medida cuantitativa del grado en que el sistema, componente o proceso posee un atributo dado. Un Indicador es la mtrica o una combinacin de mtricas que proporcionan una visin profunda del proceso del software, del proyecto software o del producto en s. Un indicador proporciona una visin 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 visin de la eficacia de un proceso existente. Durante un tiempo considerable se recopilan las mtricas de todos los proyectos y se proporcionan indicadores para obtener mejoras en el software. Los mtodos de medicin o clculo son unas secuencias lgicas de operaciones y potenciales heursticas, expresadas de forma genrica, que permite la realizacin de una descripcin de actividad. El tipo de mtodo de medicin va a depender de la naturaleza de las operaciones utilizadas para cuantificar el atributo. Pueden distinguirse dos tipos: Subjetivo, cuando la cuantificacin supone un juicio realizado por un ser humano, y Objetivo, cuando la cuantificacin est basada en mtodos numricos. Una escala es un conjunto de valores con propiedades definidas. Las escalas pueden ser escalas numricas (Continua o Discreta) o escala Categrica. Los tipos de escala pueden ser: Nominal, Ordinal, Intervalo, entre otras. En este sentido la mtrica es la correspondencia de un dominio real o emprico a un mundo formal, matemtico. La medida incluye al valor numrico o nominal asignado al atributo de un ente por medio de dicha correspondencia. Las mtricas peden ser de tipo directo cuando no dependen de ninguna mtrica de otro atributo e indirecta cuando se deriva de una o ms mtricas de otros atributos. Algunos ejemplos de Mtricas Directas son: Longitud del Texto del Cuerpo de una Pgina (medido por cantidad de palabras), Cantidad de Enlaces Rotos Internos (medidos por la presencia de errores del tipo 404), Cantidad de Imgenes con Texto Alternativo (medido por la presencia de la etiqueta ALT o con texto no nulo, en cada una de las imgenes vinculadas a las pginas de un sitio Web). Algunos ejemplos de Mtricas 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 mtricas del software, ya que es la tcnica que junto a revisiones, pruebas y gestin de configuracin constituye el conjunto principal de medios operativos para el aseguramiento de la calidad en el proyecto. En general, para la evaluacin de la calidad es ms 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 algn perodo de prueba, etc. Para mejorar cualquier proceso se debe medir atributos del proceso, definir y desarrollar un juego de mtricas para esos atributos, y utilizar las mtricas para encontrar indicadores para la estrategia de mejora.
Figura 16: Mtricas del Proceso y Mejoras en el Proceso de Software La eficacia de un proceso de software se mide a travs de un juego de mtricas segn 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 planificacin. Tambin se debe incluir mtricas para medir las caractersticas de tareas especficas de la ingeniera del software, como la medida del tiempo y del esfuerzo para llevar a cabo actividades de proteccin, actividades genricas de ingeniera de software. Para una organizacin es importante estar a gusto con la recopilacin y la utilizacin de mtricas de proceso, de stas se deriva la identificacin de
indicadores llevando a un enfoque ms riguroso denominado Mejora estadstica del proceso de software (MEPS). Este enfoque utiliza el anlisis de fallas del software para recopilar informacin de errores y defectos. Para realizar un anlisis 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 nmero de errores y de defectos de cada categora, calcular el costo global de errores y defectos de cada categora, para posteriormente, desarrollar planes para eliminar los errores y defectos ms 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 organizacin 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 lnea central, representa el factor de calidad o el problema en consideracin. Las lneas diagonales conectadas a la lnea central indican una causa potencial del problema de calidad.
Figura 17: Anlisis 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 Especificacin de requisitos Diseo Cdigo Causa Lgica Manejo de datos estndares Especificaciones Interfaz de software Interfaz de Hardware Comprobacin de errores Interfaz de usuario % 20 10.9 6.9 25.5 6.0 7.7 10.9 11.7
Tabla 19: Origen de errores o defectos y causas en un proyecto software
Utilizando el diagrama de espina para la identificacin de las causas especficas para este problema, sera:
Figura 18: Identificacin de causas de errores o defectos en un software Las mtricas del Proyecto se utilizan para minimizar la planificacin de desarrollo, ya que realizan ajustes y minimizan los retrazos. Adems se utilizan para evaluar la calidad de los productos. A medida que mejora la calidad se minimizan los defectos. Las mtricas del proyecto de software sugiere que los proyectos deben medir: Las entradas, la dimensin de los recursos que se requieren para realizar el trabajo, las salidas, medidas de las entradas o productos creados durante el proceso de ingeniera de software, y resultados, medidas que indican la efectividad de las entregas. 5.2 LECCIN 2: MTRICAS DEL SOFTWARE
Las mtricas del software se pueden categorizar en: 5.2.1 Medidas Directas: Dentro de estas se pueden incluir: el costo y el esfuerzo aplicado, Las lneas de cdigo producidas (LCD), La velocidad reejecucin, El tamao de la memoria y los defectos informados durante un periodo de tiempo establecido. 5.2.2 Mtricas Indirectas: Dentro de estas estn la funcionalidad, La calidad, La complejidad, La eficiencia, la Fiabilidad, La facilidad de uso y La facilidad de mantenimiento. 5.2.3 Mtricas orientadas al tamao: Provienen de la normalizacin de las medidas de calidad y/o productividad considerando el tamao 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 BSICAS, TECNOLOGA E INGENIERA - ECBTI CURSO DE EVALUACIN DE SOFTWARE - CDIGO 301569__________________________________________ Proyecto IRIS LCD 18.200 Esfuerzo 24 Costo $ 200000 Pginas de documentacin 945 Errores 134 Defectos 86 Personas 4
Tabla 20: Tabla de registro de datos de mtricas orientadas al tamao Teniendo en cuenta los datos de la tabla anterior, se puede derivar otras mtricas para comparar varios proyectos. Por ejemplo: Errores por KLDC (miles de lneas de cdigo), Defectos por KLDC, Pginas de documentacin por KLDC, Errores por persona/mes, LDC por persona/mes, Costo ($) por pgina de documentacin 5.3.4 Mtricas orientadas a la funcin: Las mtricas del software orientadas a la funcin permiten la medida de la funcionalidad de la aplicacin. Esta mtrica fue propuesta busca identificar los factores crticos que determinan el tamao del software y por consiguiente, estimar el esfuerzo y el costo para desarrollarlo. De aqu nace la tcnica de anlisis de puntos de funcin, que mide una aplicacin con base en las funciones que ste realiza por solicitud del usuario final. Los puntos de funcin se obtienen utilizando una funcin emprica basado en medidas cuantitativas del dominio de informacin del software y valoraciones subjetivas de la complejidad del software. Los puntos de funcin se calculan utilizando la siguiente tabla:
Parmetros de medicin Nmero de entradas de usuario Nmero de salidas de usuario Nmero de peticiones de usuario Nmero de archivos Nmero de interfaces externas Cuenta X X X X X Factor de ponderacin Simple Medio Complejo 3 4 6 4 3 7 5 5 4 10 7 7 6 15 10
= = = = = Costo_total
Tabla 21: Tabla de clculo de puntos de funcin Se determinan 5 caractersticas del mbito de la informacin y los clculos aparecen en la posicin apropiada en la tabla. Los valores del mbito de informacin estn definidos de la siguiente forma:
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD 93 ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA - ECBTI CURSO DE EVALUACIN DE SOFTWARE - CDIGO 301569__________________________________________ Caracteratica Nmero de entradas de usuario Nmero de salidas de usuario Definicin Se cuenta cada entrada de usuario que proporcione al software diferentes datos orientados a la aplicacin Se cuenta cada salida que proporciona al usuario informacin orientada a la aplicacin. En este contexto las salidas se refieren a informes, pantallas, mensajes de error Una peticin esta definida como una entrada interactiva que resulta de la generacin de algn tipo de respuesta en forma de salida interactiva. Se cuenta cada peticin por separado Se cuenta cada archivo maestro lgico Se cuentan todas las interfaces legibles por la mquina por ejemplo: archivos de datos, en cinta o discos que son utilizados para transmitir informacin a otro sistema.
Nmero de peticiones de usuario
Nmero de archivos Nmero de interfaces externas
Tabla 22: Caractersticas y definicin de puntos de funcin (a) Cuando han sido recogidos los datos anteriores, se asocia el valor de complejidad a cada cuenta. Las organizaciones que utilizan mtodos de puntos de funcin desarrollan criterios para determinar si una entrada es denominada simple, media o compleja. No obstante la determinacin dela complejidad es algo subjetivo. PF = Cuenta_total * [0.65 + 0.01* sumatoria (fi)]
PF Cuenta_total fi Punto de funcin 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 sealadas 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 recuperacin fiable? Se requiere comunicacin de datos? Existen funciones de procesamiento distribuido? Es crtico 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 mltiples pantallas u operaciones? Se actualizan los archivos maestros de forma interactiva?
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD 94 ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA - ECBTI CURSO DE EVALUACIN DE SOFTWARE - CDIGO 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 diseado el cdigo para ser reutilizable? Estn incluidas en el diseo la conversin y la instalacin? Se ha diseado el sistema para soportar mltiples instalaciones en diferentes organizaciones? Se ha diseado la aplicacin para facilitar los cambios y para ser fcilmente utilizada por el usuario?
Tabla 23: Caractersticas y definicin de puntos de funcin (b) Una vez calculados los puntos de funcin se usan como medida de la productividad, calidad y otros productos del software. Productividad= PF/persona-mes Calidad= Errores/ PF Costo= Pesos/PF Documentacin= Pginas_documentadas/ PF 5.3 LECCION 3: MTRICAS DE CALIDAD DEL SOFTWARE
El objetivo de la Ingeniera de Software es desarrollar y producir software de alta calidad y para lograrlo es fundamental aplicar mtodos y herramientas efectivos dentro del contexto de un proceso de desarrollo de software. Dentro de las medidas de calidad del software estn: 5.3.1 Correccin: Es el grado en el que el software cumple su funcin, la medida ms comn es: Defectos por KDLC (miles de lneas de cdigo) 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 peticin, Disear una modificacin, 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 funcin de: Habilidad intelectual o fsica para aprender el sistema, El tiempo requerido para hacer uso eficiente del sistema, Aumento de la productividad y la Valoracin subjetiva de la disposicin de los usuarios hacia el sistema.
5.3.5 Eficacia de la eliminacin de defectos: La eficacia de la eliminacin de defectos (EED), es una mtrica que permite medir la habilidad de filtrar las actividades de la garanta 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 nmero de errores encontrados antes de la entrega del software y D es el nmero de defectos encontrados despus de la entrega. El valor ptimo de EED es 1, que significa que no se han encontrado defectos en el software. 5.4 LECCIN 4: MTRICAS TCNICAS DEL SOFTWARE
Las mtricas tcnicas para el software proporcionan una manera sistemtica de valorar la calidad basndose en un conjunto de reglas. Tambin proporcionan al ingeniero del software descubrir y corregir problemas potenciales antes de que se conviertan en defectos catastrficos. 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 mtricas de a calidad del software. Estos factores evalan el software desde tres puntos de vista distintos: Operacin del producto, Revisin del producto y Transicin del producto. A continuacin se muestran los factores de calidad de McCall, las caractersticas asociadas y la definicin de cada una de ellas:
1. Operaciones del producto - Caractersticas operativas Correccin: Hace lo que se El grado en que una aplicacin 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 aplicacin lleve a cabo forma fiable todo el tiempo? las operaciones especificadas y con a precisin requerida. Eficiencia: Qu recursos La cantidad de recursos hardware y software que necesita hardware y software una aplicacin 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 fcil y El esfuerzo requerido para aprender el manejo de una cmodo de aplicacin, trabajar con ella, introducir datos y conseguir manejar? resultados 2. Revisin del producto - Capacidad para soportar cambios Facilidad de mantenimiento: El esfuerzo requerido para localizar y reparar errores. Puedo localizar los fallos? Fiexibilidad: Puedo aadir El esfuerzo requerido para modificar una aplicacin en nuevas opciones? funcionamiento. Facilidad de prueba: Puedo El esfuerzo requerido para probar una aplicacin de forma que probar todas las opciones? cumpla con lo especificado en los requisitos. 3. Transicin del producto - Adaptabilidad a nuevos entornos Portabilidad: Podr usarlo El esfuerzo requerido para transferir a aplicacin a otro en otra mquina? hardware o sistema operativo. Reusabilidad: Podr utilizar Grado en que partes de una aplicacin pueden utilizarse en alguna parte del software en otras aplicaciones
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD 96 ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA - ECBTI CURSO DE EVALUACIN DE SOFTWARE - CDIGO 301569__________________________________________ otra aplicacin? Interoperabilidad: Podr comunicarse con otras aplicaciones o sistemas informticos?
El esfuerzo necesario para comunicar la aplicacin con otras aplicaciones o sistemas informticos
Tabla 24: Factores de calidad de McCall 5.4.2 Mtricas para el esquema de puntuacin Las mtricas pueden ir en forma de lista de comprobacin para evaluar y puntuar atributos especficos del software. La puntucin va en una escala del O (bajo) al 10 (alto). Se emplean las siguientes mtricas en el esquema de puntuacin:
Facilidad de auditora Exactitud Estandarizacin de comunicaciones Complexin Concisin Consistencia Estandarizacin de datos Tolerancia al error Eficiencia de ejecucin Capacidad de expansin Generalidad Independencia del software Instrumentacin Modularidad Operatividad Seguridad Autodocumentacin Simplicidad Independencia del sistema software Trazabilidad Formacin La facilidad con la que se puede comprobar el cumplimiento de los estndares. La exactitud de los clculos y del control. El grado de empleo de estndares de interfaces, protocolos y anchos de banda. El grado con que se ha logrado la implementacin total de una funcin. Lo compacto que es el programa en trminos de lneas de cdigo. El empleo de un diseo uniforme y de tcnicas de documentacin a lo largo del proyecto de desarrollo del software El empleo de estructuras y tipos de datos estndares a lo largo del programa. El dao causado cuando un programa encuentra un error. El rendimiento del funcionamiento de un programa. El grado con que se pueden ampliar el diseo arquitectnico, de datos o procedimental. La amplitud de aplicacin 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 operacin de programa La disponibilidad de mecanismos que controlan o protegen los programas y tos datos. El grado en que el cdigo fuente proporcionan documentacin significativa El grado de facilidad con que se puede entender un programa. El grado de independencia de programa respecto a las caractersticas del lenguaje de programacin no estndar, caractersticas del sistema operativo y otras restricciones. La capacidad de seguir una representacin del diseo 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: Mtricas para el esquema de puntuacin
5.4.3 Mtricas 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 acrnimo de FURPS. F Functionality - funcionalidad R Usability usabilidad facilidad de uso R Realiability confiabilidad P Performance desempeo S supportability-capacidad de soporte La siguiente tabla, presenta la clasificacin de los atributos de calidad que se incluyen en el modelo, junto con las caractersticas asociadas a cada uno de ellos:
Factor de Calidad Funcionalidad Facilidad de uso Atributos Caractersticas y capacidades del programa Generalidad de las funciones . Seguridad del sistema Factores humanos Factores estticos Consistencia de la interfaz Documentacin Frecuencia y severidad de las fallas Exactitud de las salidas Tiempo medio de fallos Capacidad de recuperacin ante fallas Capacidad de prediccin Velocidad del procesamiento Tiempo de respuesta Consumo de recursos Rendimiento efectivo total Eficacia Extensibilidad Adaptabilidad Capacidad de pruebas Capacidad de confl9uracin Compatibilidad Requisitos de instalacin
Confiabilidad
Rendimiento
Capacidad de Soporte
Tabla 26: Mtricas del modelo de Calidad FURPS El modelo FURPS incluye, adems de los factores de calidad y los atributos, restricciones de diseo y requerimientos de implementacin, fsicos y de interfaz. Las restricciones de diseo especifican o restringen el diseo del sistema. Los requerimientos de implementacin especifican o restringen la codficacion o construccin 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 fsicos especifican ciertas propiedades que el sistema debe poseer, en trminos de materiales, forma, peso, tamao. 5.4.4 Factores de calidad ISO 9126 El estndar ISO/IEC 9126 ha sido desarrollado en un intento de identificar los atributos clave de calidad para un producto de software. Este estndar es una simplificacin del Modelo de McCalI, e identifica seis caractersticas bsicas de calidad que pueden estar presentes en cualquier producto de software. El estndar provee una descomposicin de las caractersticas en subcaractersticas, que se muestran en la siguiente tabla:
Caracterstica Funcionalidad Subcaracterstica Adecuacin 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
Confiabilidad Usabilidad Eficiencia Mantenibilidad
Portabilidad
Tabla 27: Caractersticas y Subcaractersticas modelo ISO/IEC 9126 Las mtricas 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 LECCIN 5: ESTRUCTURA PARA LAS MTRICAS TCNICAS DEL SOFTWARE Es importante establecer una estructura fundamental y un conjunto de principios bsicos para la medicin de mtricas tcnicas para el software. Los principios bsicos de la medicin, sugeridos por Roche, pueden caracterizarse mediante cinco actividades:
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD 99 ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA - ECBTI CURSO DE EVALUACIN DE SOFTWARE - CDIGO 301569__________________________________________ Actividad Formulacin Coleccin Anlisis Interpretacin Realimentacin Definicin Obtencin de medidas y mtricas del software apropiadas para la representacin de software Mecanismo empleado para acumular datos necesarios para obtener las mtricas formuladas. Clculo de las mtricas y aplicacin de herramientas matemticas. Evaluacin de los resultados de las mtricas en un esfuerzo por conseguir una visin interna de la calidad de la representacin. Recomendaciones obtenidas de a interpretacin de mtricas tcnicas transmiitidas al equipo software.
Tabla 28: Actividades y definicin de Mtricas Tcnicas de Software Los principios que se pueden asociar con la formulacin de las mtricas tcnicas son los siguientes: Los objetivos de la medicin que deben establecerse antes de empezar la recoleccin de datos, Todas las tcnicas sobre mtricas deben definirse sin ambigedades, Las mtricas deberan obtenerse basndose en una teora vlida para el dominio de aplicacin, Hay que hacer las mtricas a medida para acomodar mejor los productos y procesos especficos. Roche sugiere los siguientes principios para la recoleccin y anlisis de datos: Siempre que sea posible, la recogida de datos y el anlisis debe automatizarse, Se deben aplicar tcnicas estadsticas vlidas para establecer las relaciones entre os atributos internos del producto y las caractersticas externas de la calidad, Se deben establecer directrices de interpretacin y recomendaciones para todas las mtricas. La mtrica obtenida y las medidas que conducen a ello deben tener las siguientes caractersticas: Simples y fciles de calcular, Emprica e intuitivamente persuasivas, Consistentes y objetivas, Consistentes en el empleo de unidades y tamaos, Independiente del lenguaje de programacin, Un mecanismo eficaz para la realimentacin de calidad. 5.5.1 Mtricas del Modelo de Anlisis En esta fase, las mtricas tcnicas proporcionan una visin interna a la calidad del modelo de anlisis. Estas mtricas examinan el modelo de anlisis con la intencin de predecir el tamao del sistema resultante; es probable que el tamao y la complejidad del diseo estn directamente relacionados. Dentro de las mtricas del modelo de anlisis tenemos: 5.5.1.1 Mtricas basadas en la Funcin: La mtrica del punto de funcin se utiliza como medio para predecir el tamao de un sistema obtenido a partir de un modelo de anlisis. Para visualizar esta mtrica se utiliza un diagrama de flujo de datos, el cual se evaluar para determinar las siguientes medidas clave que son necesarias para el clculo de a mtrica de punto de funcin: Nmero de entradas
del usuario, Nmero de salidas del usuario, Nmero de consultas del usuario, Nmero de archivos, Nmero de interfaces externas. 5.5.1.2 Mtrica Bang Puede aplicarse para desarrollar una indicacin del tamao del software a implementar como consecuencia del modelo del anlisis. Para calcular la mtrica bang, el desarrollador de software evala primero un conjunto de primitivas. Las primitivas se determinan evaluando el modelo de anlisis y desarrollando cuentas para los siguientes elementos de la tabla:
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 nmero de estados observables por el usuario en el diagrama de transicin de estados. Transiciones (TR El nmero de transacciones de estado en el diagrama de transicin de estado. Adems, se determinan medidas adicionales para: Primitivas modificadas de Funciones que caen fuera del limite del sistema y que deben funcin 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 relacin Las relaciones que conectan el i-simo objeto en el modelo de (Rei) datos con otros objetos. Primitivas funcionales (Pfu)
Tabla 29: Mtrica Bang 5.5.2 Mtricas del Modelo de Diseo Se concentran en las caractersticas de la arquitectura del programa, con nfasis en la estructura arquitectnica y en la eficiencia de los mdulos. Estas mtricas son de caja negra en el sentido que no requieren ningn conocimiento del trabajo interno de un mdulo en particular del sistema. Card y Glass definen las siguientes tres medidas de complejidad: La complejidad estructural, S(i), de un mdulo i se define de a siguiente manera: S(i)=f2out(i) Donde fout(i) es la expansin del mdulo i. La expansin indica el nmero de mdulos que son invocados directamente por el mdulo 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 indicacin de la complejidad en la interfaz interna de un mdulo y se define como: D(i)=v(i)/[fout(i) + 1]. Donde v(i) es el nmero de variables de entrada y salida que entran y salen del mdulo i. Fenton sugiere varias mtricas de morfologa simples que permiten comparar diferentes arquitecturas mediante un conjunto de dimensiones directas. Las mtricas a aplicar son: Tamao= n + a. Donde n es el nmero de nodos (mdulos) y a es el nmero de arcos (lneas de control). Para la arquitectura mostrada se tiene tamao= 17+18=35. Profundidad= camino ms largo desde el nodo raz a un nodo hoja. Para el ejemplo Profundidad= 4 Amplitud=nmero mximo de nados de cualquier nivel de la arquitectura. Para el ejemplo amplitud= 6 Relacin arco a nodo, r=a/n, mide la densidad de conectividad de la arquitectura y proporciona una indicacin sencilla de acoplamiento de la arquitectura. Para el ejemplo r=18/17= 1.06 5.5.3 Mtricas del Codigo Fuente Utiliza un conjunto de medidas primitivas que pueden obtenerse una vez que se han generado o estimado el cdigo despus de completar el diseo. Estas medidas son: n1: nmero de operadores diferentes que aparecen en el programa. N2: nmero de operandos diferentes que aparecen en el programa. N1: nmero total de veces que aparece el operador. N2: nmero total de veces que aparecen el operando. Halstead utiliza medidas primitivas para desarrollar expresiones par la longitud global del programa; volumen mnimo potencial para un algoritmo; el volumen real (nmero 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 caractersticas tales como el esfuerzo de desarrollo, tiempo de desarrollo e incluso el nmero esperado de fallos en el software. Halstead propone las siguientes mtricas: 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 programacin y representa el volumen de informacin (en bits) necesarios para especificar un programa. 5.5.4 Mtricas para Pruebas Las mtricas para pruebas se concentran en el proceso de prueba, no en las caractersticas tcnicas de as pruebas mismas. En general, los responsables de las pruebas deben fiarse en las mtricas de anlisis, diseo y cdigo para que sirvan de gua en el diseo y ejecucin de los casos de prueba. El esfuerzo de las pruebas tambin se puede estimar utilizando mtricas obtenidas de las medidas de Halstead. Usando la definicin 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 mdulo k se puede estimar utilizando la siguiente relacin: Porcentaje de esfuerzo de pruebas (k) = e(k)/ Se(i) (Ec. 3) Donde e(k) se calcula para el mdulo k utilizando las ecuaciones (Ec. 1) y (Ec. 2) la suma en el denominador de la ecuacin (Ec. 3) es la suma del esfuerzo de la ciencia del software a o largo de todos los mdulos del sistema. A medida que se van haciendo las pruebas, tres medidas diferentes proporcionan una indicacin de la complecin de las pruebas:
Medida de amplitud de las pruebas. Profundidad de las pruebas Proporciona una indicacin de cuantos requisitos se han probado del nmero total de ellos. Indica la complecin del plan de pruebas. Medida del porcentaje de los caminos bsicos independientes probados con relacin al nmero total de estos caminos en el programa. e puede calcular una estimacin razonablemente exacta del nmero de caminos bsicos sumando a complejidad ciclomtica de todos los mdulos del programa. e emplean para dar prioridad y categorizar los errores. La prioridad indica la severidad del problema. Las categoras de los fallos proporcionan una descripcin de un error, de manera que se puedan llevar a cabo anlisis estadstco de errores.
Perfiles de fallos
Tabla 30: medidas de Complecin de pruebas 5.5.5 Mtricas del Mantenimiento Todas las mtricas descritas pueden utilizarse para el desarrollo de nuevo software y para el mantenimiento del existente. El estndar IEEE 982.1-1988
sugiere el ndice de madurez del software (IM ) que proporciona una indicacin de la estabilidad de un producto software basada en los cambios que ocurren con cada versin del producto. Con el IM se determina a siguiente informacin: MT= Nmero de mdulos en la versin Actual Fc = Nmero de mdulos en la versin actual que se han cambiado Fa= Nmero de mdulos en a versin actual que se han aadido Fe= Nmero de mdulos en la versin 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 tambin como mtrica para la planificacin de las actividades de mantenimiento del software.
CAPITULO 6
PRUEBAS DEL SOFTWARE
INTRODUCCIN Una de las caractersticas tpicas del desarrollo de software basado en el ciclo de vida es la realizacin de controles peridicos, norrnalmente coincidiendo con la terminacin de cada una de las etapas, del producto o los documentos. Estos controles pretenden una evaluacin de la calidad de los productos generados para poder detectar posibles defectos cuanto antes. in embargo, todo sistema o aplicacin, independientemente de estas revisiones, debe ser probado mediante su ejecucin controlada antes de ser entregado al cliente. Estas ejecuciones o ensayos de funcionamiento, posteriores a la terminacin del cdigo 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 ingeniera de software, a partir de cual se han generado un gran nmero de trabajos. En este captulo se presenta una revisin tcnica sobre la prueba de software, abordndose 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 mtodo ms para poder verificar y validar el software cuando ya est en forma de cdigo ejecutable. La verificacin es el proceso de evaluacin 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 validacin hace referencia al proceso de evaluacin 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 aplicacin implica comprobar si satisface los requisitos marcados por el usuario.
6.1
LECCIN 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 diseo. As mismo, una prueba de software permite detectar la presencia de errores que pudieran generar salidas o comportamientos inapropiados durante su ejecucin. 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 especficas, se observan o almacenan los resultados y se realiza una evaluacin de algn 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 especficas, se puede suponer la presencia de una especie de ambiente de operacin de la prueba, para el cual deben existir determinados valores para las entradas y las salidas, as como tambin ciertas condiciones que delimitan a dicho ambiente de operacin, formalmente esto es conocido como Caso de Prueba. El objetivo de las pruebas es la deteccin de errores o fallas y defectos en el software. Se trata de una actividad a posteriori, para la deteccin de problemas en el software, y la posterior rectificacin. La mayora de los estudios revelan que los mejores programadores incluyen una cierta media de defectos por cada 1.000 lneas de cdigo. Los defectos no son siempre el resultado de la negligencia, sino que en su aparicin influyen mltiples factores como la mala comunicacin 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 ejecucin en la prueba. Las discrepancias entre ambos se consideran sntomas 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 sera que probara el software el peor enemigo de quien lo ha construido, ya que as se asegurara una bsqueda implacable de cualquier error cometido. 3. Se debe inspeccionar a conciencia el resultado de cada prueba para descubrir posibles sntomas de defectos. Lamentablemente es frecuente pasar por alto sntomas bastante claros. Esto invalida todo el esfuerzo realizado en la planificacin, diseo y ejecucin de pruebas.
4. Al generar casos de prueba, se deben incluir datos de entrada vlidos 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 diseados 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 diseo 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 estadsticas confirman cerca del 40% del esfuerzo de desarrollo se consume en pruebas y depuracin. 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 nmero de defectos ya descubierto. 9. Las pruebas son una tarea ms creativa que el desarrollo de software. Siempre se han considerado las pruebas como una tarea destructiva y rutinaria. No existen tcnicas rutinarias para el diseo de pruebas y hay que recurrir al ingenio para alcanzar un buen nivel de deteccin de defectos con los recursos disponibles. La filosofa ms adecuada para las pruebas consiste en planificarlas y disearlas de forma sistemtica para poder detectar el mximo nmero y variedad de defectos con el mnimo consumo de tiempo y esfuerzo. Un buen caso de prueba es aquel que tiene una gran probabilidad de encontrar un defecto no descubierto an, ya que el xito de una prueba consiste en detectar un defecto no encontrado antes. La prueba de software se realiza con el propsito 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 caractersticas y los atributos principales que deben tener las pruebas:
Objetivos pruebas de las La prueba es un proceso de ejecucin de un programa con la intencin 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 disear las pruebas antes de generar ningn cdigo El 80% de todos los errores se centran en solo en el 20% de los
Principios Pruebas
de
las
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD 108 ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA - ECBTI CURSO DE EVALUACIN DE SOFTWARE - CDIGO 301569__________________________________________ mdulos Empezar las pruebas en mdulos 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 descomposicin Simplicidad Estabilidad Facilidad de comprensin Ms alta probabilidad de encontrar un error. No debe ser redundante No debera ser ni demasiado sencilla ni demasiado compleja
Caractersticas de un software fcil de probar
Atributos de buena prueba
una
Tabla 31: Objetivos, Principios, y Caractersticas de los Atributos de la Prueba 6.2 LECCIN 2: TCNICAS DE DISEO DE CASOS DE PRUEBA
El objetivo de las tcnicas de diseo de casos de prueba es el de conseguir una confianza aceptable en que se detectarn 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 diseo de casos de prueba consiste en la elleccin de algunas posibilidades de funcionamiento del software que por sus caractersticas, 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 eleccin 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 atencin a los detalles procedimentales del software, por ello la implementacin de estas pruebas depende fuertemente de la disponibilidad de cdigo fuente. Este tipo de pruebas, permiten generar casos para ejercitar y validar los caminos de cada mdulo, las condiciones lgicas, los bucles y sus lmites, as como tambin para las estructuras de datos. Las pruebas inician con la observacin de que un programa difcilmente puede considerarse como probado por completo si su cdigo contiene partes que nunca han sido ejecutadas. Este mtodo analiza la estructura lgica del programa y, para cada alternativa que puede presentarse, los datos de prueba ideados conducirn a ella. Se procura escoger los que verifiquen cada posibilidad en las
proposiciones case, las clusulas de cada proposicin if y la condicin de terminacin de cada ciclo.
Figura 19: Prueba de Caja Blanca En un programa complejo este mtodo es imprctico, pero en un mdulo pequeo constituye un excelente medio de prueba y depuracin. En una prueba que se vale del mtodo de la caja blanca, se tornan patentes las ventajas de un diseo de programa modular. Un buen criterio de prueba para proyectos extensos consiste en aplicar los mtodos a cada mdulo pequeo conforme se escriba; luego se usan esos datos en las secciones ms amplias del programa una vez terminadas. Las pruebas de caja blanca tambin son conocidas como pruebas de caja de cristal o pruebas estructurales. Algunas de las pruebas ms significativas dentro de este enfoque son mostradas en la siguiente tabla:
Prueba Prueba de caminos Definicin En este tipo de prueba se realiza un anlisis sobre una representacin grfica de un programa denominada grafo de control. En este grafo, los nodos representan bloques de instrucciones de un programa y los flujos de ejecucin para dichas instrucciones se representan por medio de aristas. A partir de este grafo, se puede identificar un conjunto bsico de caminos de ejecucin, sobre el cual se pueden realizar pruebas con el propsito de ejercitar el flujo de ejecucin de los caminos en una unidad. Basndose en un grafo de control, pueden generarse casos de prueba para elementos individuales de expresiones lgicas. De esta forma se pretende probar cada condicin 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 propsito de verificar si se realizan de forma correcta. Estas pruebas son realizadas con el objetivo de encontrar posibles contradicciones o redundancias en la definicin de los datos utilizados en el software. Para ello se realiza un anlisis del comportamiento de cada uno de los datos o cada una de los flujos de ejecucin.
Prueba de condiciones Prueba de ciclos Prueba de definicin de datos
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 atencin 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 lgica 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 disean 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 escogern atendiendo a las especificaciones del problema, sin importar los detalles internos del programa, a fin de verificar que el programa corra bien. Los criterios mnimos que guiarn al escoger los datos de prueba: Valores Fciles: El programa se depurar con datos de fcil comprobabilidad. Valores tpicos 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 indicacin de errores en la entrada y que realice clculos que sigan siendo factibles luego de desechar la entrada equivocada.
Figura 20: Prueba de Caja Negra Con la aplicacin 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 inicializacin y terminacin. Con la aplicacin de esa tcnica se obtiene un conjunto de pruebas que reduce el nmero de casos de pruebas y dicen algo sobre la presencia o
ausencia de errores. Algunas de las pruebas ms conocidas en este contexto se muestran en la siguiente tabla:
Prueba Particin equivalente Definicin La idea de esta tcnica, es en dividir los valores vlidos y no vlidos para entradas y salidas en un nmero reducido de particiones de forma que, el comportamiento del software sea el mismo para cualquier valor contenido en una particin particular. El propsito principal de una particin es reducir la cantidad de casos de prueba generados en el proceso. La generacin de casos de prueba en esta tcnica, se enfoca en los valores limites, esto bajo la consideracin 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 mnimo, valores un poco arriba del mnimo, valor mximo y valores un poco arriba del mximo. Este tipo de prueba la generacin de casos se realiza a partir de la intuicin y la experiencia. La idea bsica es redactar una lista de las posibles fallas o de las posibles situaciones en las cuales suele ocurrir algn problema y as desarrollar casos de prueba basados en la informacin 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 lgicos y (and), o (or) y no (not). Al involucrar aspectos de lgica, se dice que este tipo de prueba se hace ms rigurosa, que permite adems transformar una especificacin en lenguaje natural en una especificacin ms formal.
Anlisis de los valores lmite
Pruebas segn la experiencia (error guessing) Tablas de decisin
Tabla 33: Pruebas de Caja Negra A continuacin se presentan las distintas tcnicas de diseo 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 mximo nmero de entradas, Debe tratarse el dominio de valores de entrada dividido en un nmero 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 mtodo de diseo de casos consiste en la identificacin de clases de equivalencia y la creacin de los casos de prueba corespondientes. Para identificar las posibles clases de equivalencia de un programa a partir de su especificacin deben seguirse los siguientes pasos: primero, la identificacin de Ia condiciones de entradas al programa, Segundo, a partir de ellas, se identifican clases de equivalencia que pueden ser de datos vlidos o de datos no vlidos o errneos.
La identificacin de las clases se realiza basndose 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 nmero estar comprendido entre 1 y 49), se crear una clase vlida (1>= nmero <= 49) y dos clases no vlidas (nmero < 1 y nmero > 49). Si se especifica un nmero de valores (por ejemplo. se pueden registrar de uno a tres propietarios de un piso), se crear una clase vlida (1<= propietarios >=3) y dos no vlidas (propietarios< 1 y propietarios>3). Una situacin del tipo booleana (por ejemplo, el primer carcter debe ser una letra), se identifican una clase vlida (es una letra) y una no vlida (no es una letra). Si se especfica 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 vlida por cada valor (en este caso son tres: Casas, apartamentos y locales comerciales) y una no vlida (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 aplicacin de estas reglas para la derivacin de clases de equivalencia permite desarrolla los casos de prueba para cada elemento de datos del dominio de entrada. El ltimo paso del mtodo 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 asignacin de un nmero 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 vlidas, no incorporadas, como sea posible. Fase 3, hasta que todas las clases de equivalencia no vlidas hayan sido cubiertas por casos de prueba, escribir un caso para una nica clase no vlida sin cubrir. 6.2.2.2 Anlisis de Valores Lmite (AVL): Mediante la experiencia, se ha podido constatar que los casos de prueba que exploran las condiciones lmite de un programa producen un mejor resultado pura la deteccin de defectos, es decir, es ms probable que los defectos del software se acumulen en estas condiciones. Se puede definir las condiciones lmite como las situaciones que se hallan directamente arriba, abajo y en los mrgenes de las clases de equivalencia.
El anlisis de valores lmite es un tcnica de diseo de casos que complementa a la de particiones de equivalencia. Aunque parezca que el AVL es simple de usar, su aplicacin tiene mltiples matices que requieren un gran cuidado a la hora de disear las pruebas. Las reglas para identificar clases son las siguientes: Si una condicin 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 vlidos para situaciones justo ms all de los extremos (-1.001 y +1.001, en el caso que se admitan tres decimales). Si la condicin de entrada especifica un nmero de valores (el archivo de entrada tendr de 1 a 255 registros), hay que escribir casos para Ios nmeros mximo, mnimo, uno ms del mximo y uno menos del mnimo de valores (0, 1,255 y 256 registros). Usar la regla 1 para la condicin de salida (el descuento mximo aplicable en compra al contado ser el 50%, el mnimo ser el 6%). Se escribirn casos para intentar obtener descuentos de 5.99%, 6%, 50% y 50.01%. Usar la regla 2 para cada condicin 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 aplicacin del AVL. 6.2.3 Conjetura de errores Esta tcnica consiste en enumerar una lista de errores posibles que pueden cometer los desarrolladores o de situaciones propensas a ciertos errores. Despus se generan casos de prueba en base a dicha lista que suelen corresponder con defectos que aparecen comnmente 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 tcnica. Algunos valores a tener en cuenta para los casos especiales son los siguientes: El valor 0 es una situacin propensa a error tanto en la salida como en la entrada. En situaciones en las que se introduce un nmero variable de valores, conviene centrarse en el caso de no introducir ningn valor y el de un solo valor. Tambin puede ser interesante el de todos los valores iguales.
es recomendable suponer que el programador haya podido malinterpretar algo en la especificacin. Tambin 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 podran aparecer en la prctica diaria, de forma contnua, sin descanso. Esto implica usar herramientas denominadas generadores de pruebas a las que se alimenta con una descripcin de datos y secuencias de entradas posibles as como una estimacin de probabilidad de ocurrir cada una de ellas en el uso real. Si el proceso de generacin de pruebas se ha realizado correctamente, se crearn todas las posibles entradas del programa en todas las combinaciones posibles, aunque no sea necesario hacer esto para una prueba adecuada. Tambin se puede conseguir, indicando la distribucin estadstica que siguen, que la frecuencia de entrada para orientar correctamente nuestras pruebas hacia aquello que es ms probable que suceda en la prctica real. 6.3 LECCIN 3: ESTRATEGIAS DE APLICACIN DE PRUEBAS DEL SOFTWARE Una estrategia de prueba integra las tcnicas de diseo de casos de prueba en un conjunto de pasos bien planeados que dan como resultado la correcta construccin del software. Una estrategia de prueba de software proporciona una gua para los desarrolladores del software, para la organizacin de control de calidad y para el cliente. Por tanto una estrategia de software debe incorporar la planificacin de la prueba, el diseo de casos de prueba, la ejecucin de pruebas y la agrupacin y evaluacin de los datos resultantes. 6.3.1 Prueba de unidad La prueba de unidad centra el proceso de verificacin en la menor unidad del diseo del software. Aqu se prueban los caminos de control importantes, con el fin de descubrir errores dentro del mbito de un mdulo. 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 mdulo para asegurar que la informacin 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 ejecucin del algoritmo. Se prueba las condiciones lmite para asegurar que el mdulo funciona correctamente dentro
de los lmites establecidos por el procesamiento, se activan los caminos bsicos de la estructura de control con el fin de asegurar de que las sentencias del mdulo 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 mdulo Es igual el nmero de parmetros de entrada al nmero de argumentos? Coinciden las caractersticas (atributos) de los parmetros con los argumentos? Coinciden el sistema de unidades de los parmetros con el de los argumentos? Son correctos el nmero, atributos y el orden de los argumentos de las funciones incorporadas? Existen referencias o parmetros que no estn asociados con el punto de entrada actual? Entran slo argumentos alterados? Son consistentes las definiciones de variables globales entre mdulos? 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 tamao del buffer con el tamao 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 algn error textual en la informacin de salida?
Cuando un mdulo tenga operaciones bsicas de Entrada/Salida externa, se deben llevar a cabo pruebas adicionales
Tabla 34: Lista de comprobaciones para la prueba de interfaces Se deben disear casos de prueba para descubrir errores tales como: Tipificacin impropia o inconsistente, Inicializacin o valores implcitos errneos, Nombres de variables incorrectos, Tipos de datos inconsistentes, Desbordamiento o errores en el direccionamiento de memoria. Adems se deben disear casos de prueba para detectar errores causados por clculos incorrectos o flujos de control inapropiados. Entre los errores ms comunes en los clculos estn: Procedencia aritmtica incorrecta mal aplicada, Operaciones de modo mixto, Inicializaciones incorrectas, Falta de precisin, Representacin incorrecta de una expresin. Los casos de prueba deben descubrir errores como: Comparaciones entre tipos de datos distintos, Operadores lgicos o de procedencia incorrecta, Terminacin de ciclos inapropiada o inexistente, Falta de salida cuando se encuentra una iteracin mal aplicada, Variables internas a un ciclo modificadas en forma inadecuada.
Entre los errores que se deben comprobar estn los siguientes: La condicin de error hace que intervenga el sistema antes que el mecanismo de errores, Descripcin ilegible del error, El error sealado no corresponde con el error encontrado, La descripcin del error no proporciona suficiente informacin para ayudar en la localizacin de la causa del error. La prueba de los lmites es la ltima etapa de la prueba de unidad y quiz la ms importante. El software falla en sus condiciones lmite, 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 repeticin de un ciclo de x pasos o cuando se llega a los valores mximo mnimo permitidos. Los casos de prueba que ejerciten las estructuras de datos por debajo o encima de los mnimos y mximos permitidos son apropiados para descubrir estos errores. La estrategia de aplicacin y la planificacin de las pruebas pretenden integrar el diseo de los casos de prueba en una serie de pasos bien coordinados a travs de la creacin de distintos niveles de prueba, con diferentes objetivos. Adems, permite la coordinacin del personal de desarrollo, y del cliente, gracias a la definicin de los papeles que deben desempear cada uno y la forma de llevarlos a cabo. En general, la estrategia de pruebas es la siguiente: Las pruebas comienzan a nivel de mdulo, una vez terminadas, progresan hacia la integracin del sistema completo y su instalacin, y culminan cuando el cliente acepta el producto y se pasa a su explotacin inmediata. Esta serie tpica de etapas se describe con mayor detalle a continuacin: Se comienza en la prueba de cada mdulo, que normalmente la realiza el propio personal de desarrollo en su entorno. Con el esquema del diseo del software, los mdulos 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 aceptacin para que el usuario compruebe en su propio entorno de explotacin si lo acepta como est o no. 6.3.2 Pruebas de integracin Las pruebas de integracin estn 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 integracin implican una progresin 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 mdulos. La prueba de Integracin es una tcnica sistemtica para construir la estructura del programa mientras que al mismo tiempo, se llevan a cabo pruebas para detectar errores asociados con la interaccin. El objetivo es tomar los mdulos probados en unidad y estructurar un programa que est de acuerdo con lo que dicta el diseo. Una vez que los mdulos funcionen por separado y hayan pasado la prueba de unidad es necesario realizar las pruebas para ver cmo funcionan juntos todos los mdulos. Normalmente aqu es donde pueden surgir los problemas en la unin de los mdulos. Los datos se pueden perder en una interfaz, un mdulo puede tener un efecto adverso sobre otro mdulo; las subfunciones, cuando se combinan, pueden no producir el objetivo principal deseado, las estructuras de datos globales pueden presentar problemas. Existen 2 tipos de integracin, la primera es no incremental en donde se intenta elaborar software en mdulos grandes, en otros casos un slo mdulo, pero en ellos es ms difcil aislar los errores y cuando alguno de ellos es corregido produce otros errores. El segundo tipo de integracin es incremental en donde se desarrollan mdulos pequeos y funcionales que hacen que los errores sean ms fcil de aislar y corregir, es ms probable que se puedan probar completamente las interfaces y aplicar un enfoque de prueba sistemtico. 6.3.2.1 Integracin incremental ascendente: El proceso empieza combinando primero los mdulos de ms bajo nivel en grupos que realizan alguna subfuncin especfica, donde se busca reducir el nmero de pasos de integracin. Luego se describe para cada grupo un mdulo impulsor o conductor, que es un mdulo que permite simular la llamada a los mdulos, introducir los datos de prueba a travs de los parmetros de llamada y recoger los resultados a travs de los de salida. Posteriormente, se prueba cada grupo empleando su impulsor y por ltimo se eliminan los mdulos impulsores de cada grupo y se sustituyen por los mdulos del nivel superior de la jerarqua. 6.3.2.2 Integracin Incremental Descendente: La integracin incremental descendente comienza con el mdulo de control principal y va incorporando mdulos subordinados progresivamente. No existe un procedimiento general para determinar cul de los mdulos subordinados posibles es mejor incorporar primero, es decir, no se puede dar una regla general que permita determinar la secuencia ptima de incorporacin de mdulos. Hay que estudiar en cada caso cul es el mejor orden de incorporacin para minimizar el esfuerzo o para lograr una mejor organizacin. La siguiente figura muestra la integracin incremental descendente
Figura 21: Integracin Incremental Descendente Las etapas fundamentales de la integracin descendente son las siguientes: El mdulo raz es el primero. e escriben mdulos ficticios para simular la presencia de los subordinados ausentes que sern llamados por el mdulo raz. Una vez probado el mdulo raz se sustituye uno de los subordinados ficticios por el mdulo correspondiente segn el orden elegido. e incorporan ficticios para recoger las llamadas del ltimo incorporado. e ejecutan las correspondientes pruebas cada vez que se incorpora un mdulo nuevo. Al terminar cada prueba, se sustituye un ficticio por su correspondiente real. 6.3.2.3 Integracin no incremental: En este tipo de integracin cada mdulo requiere de los siguientes elementos para ser probado: Un mdulo impulsor, que transmite o impulsa los datos de prueba al mdulo y muestra los resultados de dichos casos de prueba. Uno o ms mdulos ficticios que simulan la funcin de cada mdulo subordinado llamado por el mdulo que se va a probar. Despus de probar cada mdulo por separado, se ensamblan todos ellos de una sola vez para formar el programa completo y probarlo en conjunto. La
integracin no incremental es el nico caso en el que las pruebas de unidad y las de integracin estn 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, Adecuacin de la documentacin de usuario, Ejecucin y rendimiento en condiciones lmite y de sobrecarga. Los casos para la prueba del sistema tienen tres fuentes principales para su diseo: Casos basados en los requisitos gracias a tcnicas 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 lmites de procesamiento, etc.), Casos basados en el diseo de alto nivel aplicando tcnicas 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 aceptacin 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 organizacin de desarrollo tener confianza en que estaba listo para su funcionamiento, la prueba de aceptacin es la prueba planificacda y organizada formalmente para determinar si se cumplen los requisitos de aceptacin marcados por el cliente. Las caracteristicas principales de esta prueba son las siguientes: Participacin 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 explotacin. Las recomendaciones generales que pueden darse para la prueba de aceptacin son las siguientes: Debe contarse con criterios de aceptacin previamente aprobados por el usuario, No hay que olvidar validar tambin la documentacin 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 organizacin de desarrollo en el entorno real de trabajo ayudando al usuario (prueba alfa). En el caso de productos de inters general, se entregan versiones (versiones beta) a usuarios de confianza, sin control directo, que informarn de la opinin que les merece la aplicacin.
6.3.5 Prueba de validacin y verificacin Al conjunto de actividades que aseguran que el software implementa correctamente una funcin especfica se denomina Verificacin. La Validacin se refiere a un conjunto diferente de actividades que aseguran que el software construido se ajusta a los requisitos y necesidades del cliente. La definicin de Verificacin y Validacin envuelve lo que se conoce como calidad del software, en donde los mtodos de anlisis, de diseo y de implementacin actan para mejorar la calidad al proporcionar tcnicas continuas y resultados predecibles. Las revisiones tcnicas formales de inspeccin ayudan a asegurar la calidad la calidad de los productos, a lo largo del proceso la medicin y el control se aplican sobre cada elemento de una configuracin 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 aplicacin adecuada de los mtodos y de las herramientas, las revisiones tcnicas formales efectivas y una slida gestin y medida, conducen a la calidad, que se confirma durante la prueba. Es importante mencionar que la validacin y verificacin abarcan un amplio rango de la calidad del software que incluyen revisiones tcnicas formales, auditoras de configuracin y calidad, supervisin de rendimiento, simulacin, estudio de viabilidad, revisin de la documentacin, revisin de la base de datos, anlisis de algoritmos, pruebas de desarrollo, prueba de calificacin y prueba de instalacin. La prueba de validacin se logra cuando las expectativas razonables del cliente se cumplen, en donde incluyen la especificacin de requisitos, documentos en donde se describen los atributos del software visibles para el usuario, esta informacin forma la base del enfoque a la prueba de validacin. El procedimiento de prueba estar diseado para asegurar que se satisfacen los requisitos funcionales, que se alcanzan todos los requisitos de rendimiento, que la documentacin es correcta y que se alcanzan otros requisitos tales como portabilidad, compatibilidad, recuperacin 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 Recuperacin: La prueba de recuperacin es una prueba que se hace al sistema forzando a que produzca fallas de software de muchas maneras y verificando que la recuperacin se lleve a cabo, ya sea
automticamente o manual, tomando en cuenta los recursos que se requieran para efectuar la recuperacin. 6.3.6.2 Prueba de Seguridad: La prueba de seguridad intenta verificar la aplicacin de los mecanismos de proteccin incorporados en el sistema. Durante la prueba el encargado de la prueba desempea 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 adems de producir errores a propsito en el sistema; o debe curiosear los datos pblicos intentando encontrar una clave de acceso al sistema. 6.3.6.3 Prueba de Resistencia: La prueba de resistencia est diseada para enfrentar a los programas en situaciones anormales, es decir ejecutar el sistema en forma que demande recursos en cantidad, frecuencia o volmenes anormales. El encargado de la prueba debe intentar colapsar el sistema y para lograrlo se puede tomar en consideracin lo siguiente: Disear pruebas especiales que generen 10 o ms 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 mximo de memoria o de espacio en disco, Disear casos de prueba que produzcan excesivas bsquedas de datos almacenados en disco. 6.3.7 Depuracin La depuracin aparece como resultado de una prueba efectiva, es decir, cuando en un caso de prueba se encuentra un error, la depuracin es el proceso que resulta en la eliminacin de un error. Se debe tomar en cuenta que la depuracin no es una tcnica de prueba, aunque siempre se da como consecuencia de la prueba. En la siguiente figura se muestra que el proceso de depuracin comienza en los casos de prueba, se evalan los resultados y resulta una falta de correspondencia entre los esperados y los reales, el proceso de depuracin intenta hacer corresponder el sistema con una causa, llevando as a la correccin del error.
Figura 22: Depuracin de errores La depuracin tiene como objetivo principal encontrar y corregir la causa de un error en el software, existen 3 enfoques que se pueden proponer en la depuracin: La categora de depuracin "eliminacin de causas" se manifiesta mediante induccin o deduccin. 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 categora de depuracin por "fuerza bruta" es la categora probablemente la ms comn y la menos eficiente en el momento de aislar la causa del error del software en donde se confa que en algn lugar de la gran cantidad de informacin producida nos puede llevar finalmente al xito, lo ms frecuente es que se desperdicie tiempo y esfuerzo. La vuelta atrs es el enfoque ms normal para la depuracin, que se puede usar con gran xito en programas pequeos. Partiendo de donde se detecta el error hacia atrs en el cdigo fuente hasta llegar a la posicin del error. 6.4 LECCIN 4: PRUEBA DE SOFTWARE PARA OBJETOS
El software construido a partir del modelo orientado a objetos tambin requiere ser sometido a pruebas con el propsito de garantizar su calidad. En trminos generales, se puede decir que los dos enfoques ms 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 caractersticas
del software orientado a objetos que generan problemas adicionales no cubiertos por las tcnicas tradicionales de prueba. La unidad bsica 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 caracterstica importante del enfoque orientado a objetos es la encapsulacin. Un objeto encapsula su estado y sus funciones asociadas. La abstraccin, concepto que define la capacidad de solo destacar las caractersticas esenciales de un objeto de tal forma que se puede separar su comportamiento esencial de su implementacin, va estrechamente ligada con la encapsulacin. El ocultar todos los detalles del objeto que no contribuyen a sus caractersticas esenciales, por ejemplo su estructura y la implementacin de sus mtodos, 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 difcil de realizar con caractersticas como la encapsulacin y la abstraccin, pues la dificultad de visualizar el estado interno del objeto impide consultar informacin que podra requerirse para el desarrollo de la prueba. La herencia es otra de las caractersticas que han venido a facilitar en gran medida el desarrollo de sistemas orientados a objetos. Puede pensarse que esto apoya la prevencin de fallas al construir software. Desgraciadamente, se ha comprobado que mediante esta prctica, se tienen muchas posibilidades de cometer errores, porque generalmente los elementos heredados son sometidos a algn tipo de refinamiento o redefinicin y en algunos casos eliminacin de componentes. Todas estas situaciones hacen pensar que realizar una prueba a los mtodos heredados debe ser una regla ms que una excepcin. La herencia en cierta medida trae como consecuencia reuso, lo que genera una interrogante con respecto a la formulacin 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 nmero 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 mtodos, se requiere una prueba separada. Realizar una prueba separada para cada una de la formas de un mtodo es una tarea difcil, la complejidad y el tiempo requerido crece considerablemente cuando se tienen que definir todos los posibles errores y obstculos 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 operacin para examinar o alterar su estado. El paso de mensajes es un punto fundamental al realizar la prueba. 6.4.1 Mtodos de prueba de software orientado a objetos. Muchas de las generalidades de los mtodos de prueba tradicionales han sido adaptadas considerando las caractersticas del modelo orientado a objetos, con el propsito 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 mtodos robustos para garantizar la realizacin de las pruebas de forma eficaz. En este panorama se presenta el estado actual en cuanto a prueba de software orientado a objetos en trminos 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 pequea unidad trabaje correctamente en forma aislada, antes de proceder a integrarla en el sistema. Los mtodos contenidos en una clase pueden ser muchos y una operacin 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 disearla bajo ciertas consideraciones. Se han propuesto estrategias para llevar a cabo las pruebas de unidad considerando aspectos como el orden en que los mtodos son sometidos a la prueba, el orden en que una jerarqua de clases puede ser probada, ejercitar el flujo de datos o bien el anlisis 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, ms an, 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 mtodo de la clase ejecute su responsabilidad especificada. Algunas de las tcnicas ms populares para realizar pruebas de unidad se muestran en la siguiente tabla:
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD 125 ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA - ECBTI CURSO DE EVALUACIN DE SOFTWARE - CDIGO 301569__________________________________________ Prueba Pruebas estructurales Definicin Si se tiene la disponibilidad de cdigo fuente, pueden realizarse pruebas estructurales a las unidades sometidas a la prueba. Las acciones de esta actividad pueden disearse con el propsito de ejercitar todas las rutas del cdigo, las condiciones establecidas o bien las ciclos definidos en el programa. Mediante esta tcnica se prueba la unidad bajo situaciones inusuales o extremas, con el propsito verificar cmo son manejadas por el software. Para ello, los casos de prueba suministrados son diseados considerando valores frontera, es decir los valores mnimo y mximo que la unidad puede aceptar, as como tambin aquellos valores cercanos a las fronteras identificadas. Para esta tcnica, se generarn casos de prueba para un contexto en donde una clase se modela como una mquina 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 mtodos necesarios para poder observar los cambios de estado. La aplicacin de esta tcnica 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 bin, se produce un estado indefinido incorrecto. La prueba incremental dirige su atencin 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 estaran de ms: cuando se han agregado o modificado propiedades y/o mtodos, cuando existen propiedades y mtodos que se han heredado y no se han alterado, pero que realizan algn tipo de interaccin con elementos nuevos o modificados.
Prueba de valores limite
Prueba basada en estados
Prueba incremental
Tabla 35: Pruebas de Unidad de Software Orientado a Objetos 6.4.1.2 Pruebas de integracin. Cuando se aplican pruebas de integracin 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 interactan y se integran con otras unidades del sistema. Prcticamente, el trabajo de esta prueba se concentra en la interaccin de mtodos 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 mtodos para realizar pruebas de integracin:
Prueba Mtodo de Caminos Mensajes El mtodo de Overbek
de
El mtodo de Kung
Definicin Este mtodo se concentra principalmente en probar aquellos caminos que se generan por un evento de entrada y terminan con un evento de salida En este mtodo se prueban las clases por pares, donde una hace el papel de cliente y otra el de servidor, establecindose 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 adems de lo anterior, si la clase cliente siempre satisface las precondiciones de la clase servidora, as como tambin si satisface las salidas esperadas por la clase servidora. Este mtodo emplea una estrategia de ingeniera en reversa sobre el cdigo de las unidades con el propsito 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 acclico, que puede contener varios clusters de objetos y los ordenan topolgicamente. Su mtodo involucra las etapas de pruebas de unidad y de integracin y puede usarse tambin para pruebas de regresin.
Tabla 36: Pruebas de Integracin 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 integracin, se han generado pocos trabajos, por lo que se emplean muchos de los mtodos tradicionales.
Prueba Prueba de funcin Definicin La prueba de funcin comnmente es llevada a cabo por el grupo de personas que desarrollaron el producto. Este enfoque se orienta a confirmar que la aplicacin alcanza los requerimientos y la funcionalidad especificadas por el usuario En este tipo de pruebas, versiones que an no han sido liberadas en el mercado, son ofrecidas a ciertos grupos de usuarios con el propsito de que las utilicen. El propsito 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 nmero de usuarios. Aplicando este enfoque, se puede verificar si el sistema se comporta como se espera an ante este tipo de escenarios.
Pruebas de aceptacin
Prueba bajo stress
Tabla 37: Pruebas de Sistema de Software Orientado a Objetos
6.5
LECCIN 5: PRUEBA DE SOFTWARE BASADO EN COMPONENTES.
La construccin de software a partir de componentes es una prctica relativamente nueva, por lo que no es extrao 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, encapsulacin, polimorfismo, liga dinmica o mecanismos de comunicacin, son comunes entre ambos modelos. Es evidente que para hacer las pruebas de componentes ms robustas, ser necesario considerar las caractersticas propias del enfoque de componentes. En la mayora de los casos, los criterios de prueba de caja negra son los ms aplicados a los componentes, puesto que la disponibilidad del cdigo fuente es nula en la mayora de las veces. Debido a que un componente es una unidad concreta, con una funcin bien definida, no basta realizar pruebas para su evaluacin; de igual forma se requieren procesos de prueba para su seleccin y para su integracin. Durante la etapa de construccin de un componente, el desarrollador puede aplicar las tcnicas de prueba de unidad y de integracin tradicionales del modelo Orientado a Objetos, sin embargo en lo que respecta a la seleccin y evaluacin, considerar el punto vista del usuario es un aspecto vital para la realizacin de la prueba. Finalmente en el marco de pruebas de integracin, consideraciones como la arquitectura de la aplicacin, el software intermediario y los modelos de los componentes, deben agregarse a los criterios de evaluacin. Con el propsito de organizar algunas de las estrategias de prueba de componentes ms comunes, en las siguientes secciones se presenta una descripcin de las mismas en los trminos que se presentaron para el enfoque orientado a objetos, de nivel unidad y nivel de integracin. 6.5.1 Pruebas de unidad. Aunque la realizacin de pruebas de unidad es una actividad que en algn 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 mquinas virtuales de Java cada vez que se carga una clase. Trusted Components, es un proyecto de investigacin paras asistir a la industria de construccin de software mediante libreras probadas de
componentes. Las pruebas que se aplican a los componentes se construyen bajo la combinacin de varios enfoques como diseo por contrato, como pruebas matemticas, mtricas, validacin exhaustiva en proyectos prcticos y manejo de cambios rigurosos. 6.5.2 Pruebas de integracin. Si las pruebas de nivel de unidad para componentes muestran severas carencias, en nivel de integracin, al igual que en otros enfoques de desarrollo, las carencias son an ms notables. Sin embargo, existen coincidencias en cuanto a las problemticas 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 cdigo no sea necesario. Este problema se agrava cuando se tienen sistemas grandes, afectndose as su rendimiento. 6.5.2.2 Los mecanismos de comunicacin utilizados: Se han presentado algunas contrariedades e inconsistencias al utilizar dentro de un mismo sistema varios mecanismos de comunicacin como eventos, mensajes o bien el paso de parmetros.
GLOSARIO DE TRMINOS Arquitectura de software: Es un diseo global de una aplicacin que incluye su descomposicin en partes. Calidad: La calidad es herramienta bsica para una propiedad inherente de cualquier cosa que permite que esta sea comparada con cualquier otra de su misma especie. Calidad de Software: Caractersticas propias del software que se desea controlar y asegurar, el software es un producto inmaterial que no se fabrica, tampoco se degradan fsicamente, sino que se desarrolla; El software puede tener errores, incidencias pero no son similares a lo que cualquier equipo de carcter fsico. Calidad externa: La magnitud de satisfaccin de un producto con relacin a necesidades establecidas cuando es usado bajo condiciones especficas. Calidad interna: El total de atributos de un producto que determina su capacidad para satisfacer necesidades establecidas cuando es usado bajo condiciones especficas. 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. Documentacin de pruebas del software: Documento que especifica todos los aspectos del proceso de pruebas para una aplicacin. Estndar: Base o modelo en el que todo el mundo se ha puesto de acuerdo. Gestin de Calidad de Software: Es un conjunto de actividades de la funcin general de la Direccin que determina la calidad, los objetivos y las responsabilidades. Se basa en la determinacin y aplicacin de las polticas de calidad de la empresa. ISO: (Internacional Standards Organization) Organizacin Internacional de estndares fundada en 1946, con sede principal en Ginebra, ISO establece o fija estndares internacionales. Se ocupa de todos los campos, excepto la electricidad y la electrnica, que se rigen por la Internacional Electrotechnical Comisin (IEC), tambin en Ginebra. ISO 9001: Es un conjunto de normas sobre la calidad y la gestin. ISO/IEC 9126: Es un estndar internacional para la evaluacin del software. Est supervisado por el proyecto SQuaRE, ISO 25000:2005, el cul sigue los mismos
conceptos. El estndar est dividido en cuatro partes las cuales dirigen, respectivamente, lo siguiente: modelo de calidad, mtricas externas, mtricas internas y calidad en las mtricas de uso. ISO/IEC 14598: Norma para la evaluacin del producto software. Esta norma comprende las siguientes seis partes que especifican el proceso a seguir para evaluar software: ISO/IEC 14598-1 Visin general; ISO/IEC 14598-2 Planificacin y Gestin; 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 Documentacin de los mdulos de evaluacin. ISO/IEC 25000: Especificacin de requerimientos de calidad del software y evaluacin de la calidad del software, soportada por el proceso de medicin de calidad del software. Mtrica: Una escala de medicin y un mtodo usado para la medicin. Modelo: Un modelo es una estructura conceptual que sugiere un marco de ideas para un conjunto de descripciones que de otra manera no podran ser sistematizadas. Proceso: El proceso de ingeniera de software se define como un conjunto de etapas parcialmente ordenadas con la intencin de logra un objetivo, en este caso, la obtencin 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 implementacin. Pruebas del sistema: Proceso de probar una aplicacin completa (no sus partes).
FUENTES DOCUMENTALES Bibliografa de referencia: BRAUDE. Ingeniera de software, una perspectiva orientada a objetos. Mxico. 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. Introduccin 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. Construccin de software orientado a objetos. Segunda edicin. 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 Diseo de Aplicaciones Informticas de Gestin, Una Perspectiva de Ingeniera de Software, Alfaomega 2004. Pginas 109 164.
PIATTINI, Mario. VILLALBA, Jose y otros. Mantenimiento del software: modelos, tcnicas y mtodos para la gestin del cambio. Editorial Alfaomega-Rama. PRESSMAN, Roger S. Ingeniera del Software. Un enfoque prctico. Quinta edicin. Espaa. 2002. Editorial McGraw Hill. SOMMERVILLE, Ian. Ingeniera de software. 6. Edicin. Pearson Addison Wesley. 2001 T.J. McCabe. A software complexity measure. IEEE Transactions on Software Engineering, 2(4):308320, 1976. Direcciones Electronicas (webgrafa) 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. Fernndez Carrasco1, Delba Garca Len2 y Alfa Beltrn 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
UNIDAD 3
Nombre de la Unidad Introduccin EVALUACIN DE SOFTWARE La evaluacin de software en la actualidad es uno de los elementos que debe ser tenido en cuenta en el proceso de construccin de un producto software, como tambin, en el producto terminado. La evaluacin del producto software es la garanta que debe brindar el fabricante de que su producto cumple con las normas de calidad internacionales para estos productos tan especiales. Adems la evaluacin de productos software contribuye al mejoramiento de los procesos en la empresa, ya que, permite la verificacin y validacis de todas y cada una de las caractersticas del producto no importando si se trate de una aplicacin pequea o compleja. En este captulo se tratar de identificar la metodologa tcnica para la evaluacin de software, las metodologias de evaluacin de la arquitectura y algunas de las aplicaciones de la evaluacin de software. Actualmente cada uno de los productos de software que salen comercialmente al mercado deben garantizar al menos el cumplimiento de normas estndares 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 ms apropiado para la organizacin 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 organizacin. - El estudiante conoce y aplica la norma de calidad ISO/IEC 9126 para la evaluacin de software - El estudiante esta en capacidad de relacionar los conceptos de evaluacin, caractersticas, metricas, pruebas y llevarlos a la prctica - El estudiante conoce las diferentes metodoligias para la evaluacin del proceso y producto software - El estudiante adquire nuevos conocimientos y puede transferirlos aplicandolos a su entorno laboral llevndolos a la prctica CAPTULO 7. METODOLOGA TCNICA PARA LA EVALUACIN DE SOFTWARE Leccin 1. Modelos Tradicionales para la Evaluacin de la
Justificacin
Denominacin de captulos Denominacin de
lecciones Denominacin de lecciones Denominacin de lecciones Denominacin de lecciones Denominacin de lecciones Denominacin de captulos Denominacin de lecciones Denominacin de lecciones Denominacin de lecciones Denominacin de lecciones Denominacin de lecciones Denominacin de captulos Denominacin de lecciones Denominacin de lecciones Denominacin de lecciones Denominacin de lecciones Denominacin de lecciones
Calidad del software Leccin 2. Norma de Evaluacin ISO/IEC 9126 Leccin 3. Proceso de Evaluacin de Software Leccin 4. Mtricas Externas Basados en ISO/IEC 9126 Leccin 5. Mtricas Internas Basados en ISO/IEC 9126 CAPTULO 8: METODOLOGAS DE EVALUACIN PARA ARQUITECTURA DEL SOFTWARE Leccin 1. Evaluacin de la Arquitectura del software Leccin 2. Tcnicas de Evaluacin de la arquitectura del software Leccin 3. Mtodos de Evaluacin de la arquitectura de software Leccin 4. Mtodos de Evaluacin de Arquitectura de un Atributo Especfico Leccin 5. Mtodo de evaluacin de la Arquitectura de Software MECABIT CAPTULO 9: APLICACIONES DE LA EVALUACIN DE SOFTWARE Leccin 1. Metodologa para la Evaluacin de la Calidad en Modelos UML Leccin 2. Implementacin de la Metodologa con SPEM y EPFC Leccin 3. Evaluacin de Software Educativo Multimedia Leccin 4. Modelos de Evaluacin de Software Educativo Multimedia Leccin 5. Plantillas de Evaluacin de Software Multimedia
UNIDAD 3
EVALUACIN DE SOFTWARE
CAPITULO 7
MTODOLOGA TCNICA DE EVALUACIN DE SOFTWARE
INTRODUCCIN La metodologa para evaluacin tcnica 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 evaluacin del producto. Dentro de los estndares de calidad ms utilizados esta el estndar definido por la ISO/IEC 9126 el cual toma en consideracin la evaluacin de las caractersticas internas, externas y de calidad en uso. A su vez cada una de las caractersticas se divide en subcaractersticas que se pueden definir y a las cuales se les puede establecer unas mtricas, pruebas y escalas de medicin que permitan establecer una valoracin para el producto en la caracerstica que haya sido elegida. En este captulo se tratar el tema de algunas de las metodologias existentes para la evaluacin de software, dentro de ella se ha elegido la norma ISO/IEC y de ella se har el seguiemiento hasta llegar a definir las mtricas que son la base para realizar el proceso de evaluacin de software.
7.1 LECCIN 1: MODELOS TRADICIONALES DE EVALUACIN 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, adems, depende mucho del punto de vista que se adopte. La evaluacin se basa en la descomposicin del concepto genrico de calidad en propiedades ms sencillas de medir y evaluar. Este tipo de descomposicin recibe el nombre de modelo de calidad. Los modelos de calidad ms 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 operacin, la capacidad para ser modificado y la capacidad de transicin o de adaptacin 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 ms fcilmente que las capacidades para tener una visin apropiada de la calidad. Estos factores son conceptos de alto nivel de abstraccin, a continuacin 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. Correccin: 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 correccin o depuracin 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 operacin a otro. Capacidad de reutilizacin: Capacidad o grado de esfuerzo para que el software o alguna de sus partes puedan ser utilizadas en otros desarrollos de software. Capacidad de Interoperacin: 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 genrica 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 ms bajo nivel osea ms detallados. Estas propiedades elementales o criterios son propiedades internas del software, que no dependen en su apreciacin de quin est observndolas y que los desarrolladores de software consideran que influyen en la calidad, algunos de estos son: Facilidad de Operacin: Propiedades del software que determinan la facilidad de las operaciones y de los procedimientos relativos a la explotacin del software. Facilidad de Comunicacin: Propiedades del software que proporciona1 eficacia y facilidad en las comunicaciones. Facilidad de Formacin o Aprendizaje: Propiedades del software que proporcionan al usuario informacin de operaciones reales o que facilitan la familiarizacin 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 ejecucin: Propiedades del software que proporcionan un consumo mnimo de recursos de procesamiento al realizar sus operaciones. Eficiencia de Almacenamiento: Propiedades del software que proporcionan unas necesidades mnimas de memoria para su operacin. Exactitud o Precisin: Propiedades del software que proporcionan el grado de precisin requerido para los resultados que hay que obtener.
Consistencia: Propiedades del soflware que proporcionan tcnicas documentacin uniforme y coherente a las distintas etapas del software.
Tolerancis a Fallos: Propiedades que proporcionan la continuidad del funcionamiento bajo condiciones no habituales. Modularidad: Propiedades del software que proporcionan una estructura de mdulos adecuadamente independientes. Simplicidad: Propiedades del software que proporcionan la implantacin de funcioncs de la manera ms comprensible posible. Complecin: Propiedades del software que proporcionan la implantacin 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 implantacin en relacin a un desarrollo especfico y a un determinado entorno de operaciones. Autodescripcin: Propiedades del software que proporcionan explicaciones sobre el desarrollo de cada funcin. Capacidad de Expansin: Propiedades del software que proporcionan facilidades para aadir nuevas capacidades funcionales o datos al sistema. Generalidad: Propiedades del software que proporcionan amplitud a las funciones realizadas. Instrumentacin: Propiedades de] software que proporcionan la posibilidad de observar el comportamiento del software durante su ejecucin. Independencia entre Sistema y Software: Propiedades del software que determinan su dependencia de su entorno lgico de trabajo. Independencia del Hardware: Propiedades del software que determinan su dependencia de su entorno fsico de trabajo (CPU, dispositivos, etc.). Normalizacin o Compatibilidad de Comunicaciones: Propiedades del software que favorecen una fcil intercomunicacin del sistema con otros. Normalizacin o Compatibilidad de Datos: Propiedades del software que determinan la posibilidad de utilizacin comn de datos con otros sistemas. Este tipo de modelos de evaluacin de la calidad han gozado de una gran aceptacin en el mundo del software. Esto ha motivado que se hayan intentado establecer como estndares por parte de diversos organismos. As, la norma IEEE 1061 propone un modelo de medicin muy parecido al de McCall denominado
modelo factor/criterio/mtrica, y la norma ISO 9126 establece un modelo propio de calidad cuya base es similar al de McCaIl. En los aos ochenta, cambi el enfoque de los modelos de evaluacin de la calidad, ya que se impuls la creacin 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 creacin de una especificacin 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 caractersticas que definen la calidad de la aplicacin. Dichas caractersticas pueden ser totalmente originales, aunque lo ms normal es que se inspiren o se tomen directamente de alguno de los modelos tradicionales. Las distintas caractersticas se pueden medir mediante varias subcaractersticas o mtricas detalladas. Para cada una de stas se deben especificar los siguientes conceptos: Nombre y definicin de la caracterstica. Escala o unidades de medicin. 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 filosofa QFD (Quality Function Deplovrnent: Despliegue de la funcin de la calidad) que se aplica en el mbito de la gestin de la calidad industrial, aunque existen trabajos especficos de aplicacin 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 ms apropiado para un proyecto. Otro enfoque relativista de medicin de la calidad del software es el representado por el paradigma GQM (Goal-Question-Metric: Objetivo-PreguntaMtrica) propuesto por Basili y Rombach. Aunque se trata de un enfoque general de la medicin, se trata de un mtodo muy apropiado para evaluar la calidad del software en cada proyecto. La idea consiste en que toda actividad de medicin debe estar precedida por la identificacin de un objetivo a lograr, que lleva a plantearse una serie de interrogantes sobre aspectos ms puntuales de la calidad, esto llevar, a su vez, a disponer de una serie de mtricas que nos permitan responderlas. Aunque inicialmente puede parecer poco prctico el uso del modelo GQM, la reflexin que implica su construccin 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 ms 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 fcilmente slo con mantener un sistema de registro de la informacin generada en el proyecto a partir de los datos aportados por las tcnicas de deteccin 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 gestin de la configuracin, etc. Es muy habitual obtener medidas que relacionan el nmero de defectos con el tamao del software. As, por ejemplo, una propuesta tpica de recoleccin de datos incluye: N de problemas informados. N de problemas evaluados. N de problemas reales. N de problemas abiertos, pendientes de resolucin. N de problemas cerrados. Tiempo que permanece un problema abierto. Tiempo que permanece un problema hasta ser evaluado. Distribucin de problemas por fase del desarrollo, por prioridad, por categora (grave, leve, esttico), etc. Este enfoque de medicin est inspirado en el control estadstico de procesos aplicado en la industria convencional de fabricacin. Uno de los casos ms conocidos de aplicacin de este enfoque es el del programa de medicin 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 mnimarnente organizada, la recogida de datos resulta barata y relativamente sencilla. 7.2 LECCIN 2: NORMA DE EVALUACIN ISO/IEC 9126
Esta norma Internacional fue publicada en 1992, la cual es usada para la evaluacin de la calidad de software, llamado Information technology-Software product evaluation-Quality characteristics and guidelines for their use; o tambin conocido como ISO 9126 (o ISO/IEC 9126). Este estndar describe 6 caractersticas 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 adquisicin, requerimientos, desarrollo, uso, evaluacin, 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 caractersticas para calidad interna y externa, las cuales, estn subdivididas. Estas divisiones se manifiestan externamente cuando el software es usado como parte de un sistema Informtico, 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 caractersticas de la calidad interna y externa del software. Especifica 4 caractersticas para la calidad en uso. Al unir la calidad interna y externa con la calidad en uso se define un modelo de evaluacin 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 pasaran hacer sus atributos, mirndolo grficamente quedara asi:
Figura 23: Norma de Evaluacin ISO/IEC 9126 Se establecen categoras 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 mtrica interna o externa.
Figura 24: Evaluacin Interna, externa y Calidad de Uso ISO/IEC 9126 Las definiciones se dan para cada caracterstica y subcaracterstica de calidad del software que influye en la calidad. Para cada caracterstica y subcaracterstica, la capacidad del software es determinada por un conjunto de atributos internos que pueden ser medidos. Las caractersticas y sub caractersticas 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 explcitas e implcitas cuando es utilizado en condiciones especficas. A continuacin se muestra la caracterstica de Funcionalidad y las subcaractersticas que cubre:
Figura 25: Caracterstica de Funcionalidad La funcionalidad se divide en 5 criterios: Adecuacin: 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 precisin o de forma esperada. Interoperabilidad: La capacidad del software de interactuar con uno o ms sistemas especficos. Seguridad: La capacidad del software para proteger la informacin 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 estndares 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 funcin requerida.
Figura 26: Caracterstica 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 estndares 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 fcil y atractiva. Algunos criterios de funcionalidad, fiabilidad y eficiencia afectan la usabilidad, pero para los propsitos 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 preparacin del uso y el resultado obtenido.
Figura 27: Caracterstica 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 fcil como ser utilizado para las tareas y las condiciones particulares de la aplicacin. En este criterio se debe tener en cuenta la documentacin y de las ayudas que el software entrega. Aprendizaje: La forma como el software permite al usuario aprender su uso. Tambin es importante considerar la documentacin. Operabilidad: La manera como el software permite al usuario operarlo y controlarlo. Atraccin: La presentacin del software debe ser atractiva al usuario. Esto se refiere a las cualidades del software para hacer ms agradable al usuario, ejemplo, el diseo grfico. Conformidad de uso: La capacidad del software de cumplir los estndares o normas relacionadas a su usabilidad. 7.2.4 Eficiencia La eficiencia del software es la forma del desempeo adecuado, de acuerdo a al nmero recursos utilizados segn las condiciones planteadas. Se debe tener en cuenta otros aspectos como la configuracin de hardware, el sistema operativo, entre otros.
Figura 28: Caracterstica de Eficiencia La usabilidad se divide en 3 criterios: Comportamiento de tiempos: Los tiempos adecuados de respuesta y procesamiento, el rendimiento cuando realiza su funcin en condiciones especificas. Ejemplo, ejecutar el procedimiento mas complejo del software y esperar su tiempo de respuesta, realizar la misma funcin pero con mas cantidad de registros. Utilizacin 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 estndares 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: Caracterstica de Mantenimiento El mantenimiento se divide en 5 criterios: Capacidad de ser analizado: La forma como el software permite diagnsticos de deficiencias o causas de fallas, o la identificacin de partes modificadas. Cambiabilidad: La capacidad del software para que la implementacin de una modificacin se pueda realizar, incluye tambin codificacin, diseo y documentacin 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 estndares de facilidad de mantenimiento. 7.2.6 Portabilidad La capacidad que tiene el software para ser trasladado de un entorno a otro.
Figura 30: Caracterstica 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, volmenes de transacciones, formatos de reporte, etc.). Facilidad de instalacin: 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 versin 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 estndares 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 satisfaccin, eficiencia y exactitud. La calidad en uso debe asegurar la prueba o revisin de todas las opciones que el usuario trabaja diariamente y los procesos que realiza espordicamente relacionados con el mismo software.
Figura 31: Caracterstica 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 relacin a la eficacia lograda en un contexto especfico 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 dao 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. Satisfaccin: La satisfaccin es la respuesta del usuario a la interaccin con el software, e incluye las actitudes hacia el uso del mismo. A continuacin se describe un cuadro donde podemos resumir las caractersticas y cada uno de sus atributos, este cuadro le ayudara a visualizar elporceso de evaluacion. 7.3 LECCIN 3: PROCESO DE EVALUACIN DE SOFTWARE
El proceso de evaluacin de software se inicia con una visin cualitativa y deriva en una evaluacin 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 ofimtica, lenguaje de programacin, base de datos, aplicativo a la medida, entre otros. 7.3.3 Perfiles de Evaluadores Teniendo como marco conceptual al estndar ISO/IEC9126, se consideran tres perfiles de usuario, a un alto nivel de abstraccin para desarrollo de software, usuarios finales, desarrolladores, y gerentes. El estndar afirma que la relativa importancia de las caractersticas de calidad vara dependiendo del punto de vista considerado y de la crtica de los componentes del software a evaluar. La visin del usuario final, concierne al inters de los mismos en usar el software, como as tambin su performance, su eficiencia, su facilidad de uso, entre otros aspectos. Los usuarios finales no estn interesados en caractersticas internas o de desarrollo del software. La visin de calidad del desarrollador debe considerar no slo los requerimientos del software para la visin del usuario sino tambin la calidad para los desarrollos intermedios resultantes de las actividades de la fase de desarrollo. Se debe tener en cuenta que los desarrolladores estn preocupados en caractersticas de calidad del software como mantenibilidad y portabilidad. La visin de calidad del gerente es una visin integradora, que incorporar requerimientos de negocio a las caractersticas 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 especficos 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 evaluacin, el instrumento debe ser aprobado por los participantes.
7.3.6 Criterios de la evaluacin Donde se tiene en cuenta los criterios de evaluacin que parten de los 7 indicadores principales los cuales fueron especificacdos en la leccin 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 evaluacin segn el tipo de software, para el cual debe conformar un equipo evaluador, este ejercicio ayuda a definir que opciones se deben evaluar con ms detalle y valor.
tipos de software financieros ejemplos contabilidad, bancarios, carteras, pagos, costos, nominas, etc recursos humanos, administracin de documentos, hospitalarios, etc materias acadmicas, enciclopedias, tutores, manuales produccin, radio terapia, control de maquinas, etc orden del criterio de evaluacin 1. Seguridad 2. Tiempo de respuesta 3. Exactitud de la informacin 4. Recuperabilidad 1. Tiempo de respuesta 2. Seguridad 3. Exactitud de la informacin 4. Recuperabilidad 1. Facilidad de comprensin 2. calidad grafica 3. portabilidad Los criterios o indicadores estn sujetos a la actividad especfica 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 automtico, cliente
administrativos
educativos
a la medida
Tabla 38: Tabla de criterios a tener en cuenta al evaluar un software 7.3.7 Seleccionar mtricas: 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 asignacin de puntajes, por ejemplo a cada mtrica seleccionada se le asigna un puntaje mximo de referencia, se debe tener en cuenta que la suma de los puntajes mximos de todas las mtricas debe ser igual o aproximado a 100 puntos, que el personal que participa en la evaluacin debe establecer niveles de calificacin cualitativa con base a los puntajes (por ejemplo: de 0 a 1 Inaceptable, de 2 a 3 mnimo aceptable, ms de 3 Aceptable o satisfactorio), otro ejemplo de calificacin cualitativa puede ser (Deficiente, Insuficiente, Aceptable, Sobresaliente, Excelente), en la mtricas se permite usar nmeros enteros o hasta con un decimal de aproximacin, se debe definir por cada mtrica, un puntaje mnimo de aprobacin, y al final de de la evaluacin, 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 evaluacin 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 medicin, las mtricas seleccionadas se aplican al software. Los resultados son valores expresados en las escalas de las mtricas, definidos previamente. 7.3.10 Resultados: Los resultados del proceso de evaluacin genera un cuadro de resultados por cada uno de losprincipales indicadores y el total final de resultado. 7.3.11 Documentacin: El proceso de evaluacin se documenta, indicando la fecha, empresa, los cargos, nombres y apellidos, dependencia de las personas que participan en el proceso de evaluacin, especificando las etapas en las que participaron. 7.3.12 Seguimiento: Donde si el resultado de la evaluacin tiene observaciones o indicadores de calidad bajos, y el personal que lo evala permite realizar la correccin, se programa otra evaluacin donde se verifique que el proceso mejora, el tiempo que se estime debe influir en los criterios de la aproxima evaluacin. A partir de cada una de las caractersticas, y subcaractersticas de la norma ISO/IEC 9126, se ha includo las preguntas generales para cada una de ellas, la siguiente tabla muestra las caractersticas, la pregunta planteada para ella, las subcaractersticas y los cuestionamientos para cada una de ellas:
CARACTERISTICA FUNCIONALIDAD PREGUNTA Las funciones y Propiedades satisfacen las necesidades Explcitas e implcitas; esto es, el qu? SUBCARATERISTICA ADECUACIN PREGUNTA Tiene el conjunto de funciones apropiadas para las tareas especificadas? Hace lo que fue acordado en forma esperada y correcta? Interacta con otros sistemas especificados? Est de acuerdo con las leyes o normas y estndares, u otras prescripciones? Con qu frecuencia presenta fallas por defectos o errores? Si suceden fallas, como se comporta en cuanto a la performancia
EXACTITUD INTEROPERABILIDAD CONFORMIDAD
CONFIABILIDAD
Puede mantener el nivel de rendimiento, bajo ciertas condiciones
MADUREZ TOLERANCIA ERRORES A
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD 155 ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA - ECBTI CURSO DE EVALUACIN DE SOFTWARE - CDIGO 301569__________________________________________ y por cierto tiempo? RECUPERABILIDAD USABILIDAD El software, es fcil de usar y de aprender? ENTENDIMIENTO especificada? Es capaz de recuperar datos en caso de fallas? Es fcil de entender y reconocer la estructura y la lgica y su aplicabilidad? Es fcil de aprender a usar? Es fcil de operar y controlar? Es atractivo el diseo del software? Cul es el tiempo de respuesta y performancia en la ejecucin de la funcin? Cuntos recursos usa y durante cunto tiempo? Es fcil diagnosticar una falla o identificar partes a modificar? Es fcil de modificar y adaptar? Hay riesgos o efectos inesperados cuando se realizan cambios? Son fciles de validar las modificaciones? Es fcil de adaptar a otros entornos con lo provisto? Es fcil de instalar en el ambiente especificado? Es fcil 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 especfico? El software tiene niveles de Riesgo que causan dao al usuario final?
APRENDIZAJE OPERABILIDAD ATRACCIN EFICIENCIA Es rpido y minimalista en cuanto a uso de recursos, bajo ciertas condiciones? Es fcil de modificar y testear? COMPORTAMIENTO DE TIEMPOS UTILIZACION DE RECURSOS CAPACIDAD DE SER ANALIZADO CAMBIALIDAD ESTABILIDAD FACILIDAD PRUEBA PORTABILIDAD Es fcil de transferir de un ambiente a otro? ADAPTABILIDAD FACILIDAD INSTALACION DE DE
CAPACIDAD DE MANTENIMIENTO
REMPLAZABILIDAD COEXISTENCIA CALIDAD EN USO Muestra usuario aceptacin seguridad software? el final y del EFICACIA PRODUCTIVIDAD
SEGURIDAD
Tabla 39: Caractersticas y Subcaratersticas ISO/IEC 9126 7.4 LECCIN 4: MTRICAS EXTERNAS BASADOS EN ISO/IEC 9126 Adems de los cuestionarios generales, se presenta cada caracterstica, la sub caracterstica, y las mtricas a evaluar, estas mtricas pueden ser la base para elaborar cuestionarios teniendo en cuenta la norma ISO/IEC 9126, para poder realizar el anlisis de las mtricas externas de acuerdo a las caractrsticas propias del software a evaluar y a las caractersticas y subcaracteraticas seleccionadas para la evaluacin, en la siguiente tabla se muestra las mtricas externas para evaluacin de software.
caracterstica Funcionalidad sub caracterstica Idoneidad nombre mtrica Adecuacin funcional Integridad funcional de aplicacin Cobertura de aplicacin funcional Estabilidad de la especificacin funcional (volatilidad) Precisin a la expectativa Precisin de cmputo Precisin 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 prevencin de la corrupcin Cumplimiento funcional Interfaz estndar de cumplimiento latente estimada de densidad de fallos Falta de densidad en contra de casos de prueba Falta de resolucin Error de la densidad Error de la eliminacin 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 recuperacin Reinicio Restaurabilidad Restaurar la eficacia Confiabilidad de cumplimiento
Precisin Interoperabilidad
Seguridad Funcionalidad Cumplimiento Confiabilidad Madurez de
Tolerancia a Fallos Recuperacin
Fiabilidad Cumplimiento
de
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD 157 ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA - ECBTI CURSO DE EVALUACIN DE SOFTWARE - CDIGO 301569__________________________________________ Usabilidad Comprensibilidad Integridad de la Descripcin Integridad de acceso Integridad de acceso en uso Demostracin de la eficacia Funciones evidentes Funcin comprensibilidad Comprender la entrada y salida Facilidad de funcin de aprendizaje Facilidad de aprendizaje para realizar una tarea en uso Eficacia de la documentacin del usuario y / o sistema de ayuda Eficacia de la documentacin del usuario y / o ayudar a los sistemas en uso Ayuda de accesibilidad Ayuda de frecuencia Coherencia operacional en el uso Correccin de errores Correccin de errores en el uso Disponibilidad predeterminada del valor de uso Mensaje comprensibilidad en uso No necesita explicacin en mensajes de error Recuperacin de error operativo en uso Tiempo entre las operaciones de un error humano en uso Capacidad de deshacer (correccin de error del usuario) Personalizacin Operacin de reduccin de procedimiento Accesibilidad fsica Atractivo de interaccin Personalizacin de interfaz de aspecto Usabilidad de cumplimiento Tiempo de respuesta 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 utilizacin Entrada / Salida lmites de carga Entrada/Salida errores relacionados Entrada/Salida radio de cumplimiento
Aprendizaje
Operabilidad
Atractivo Cumplimiento Usabilidad Tiempo Comportamiento de de
Eficiencia
Utilizacin de Recursos
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD 158 ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA - ECBTI CURSO DE EVALUACIN DE SOFTWARE - CDIGO 301569__________________________________________ Tiempo de espera de E / S de la utilizacin de los dispositivos Mxima utilizacin de la memoria Media de ocurrencia de errores de memoria Relacin entre el error de memoria / hora Mxima utilizacin de la transmisin Medios de comunicacin la utilizacin del dispositivo de equilibrio Media de ocurrencia de errores de transmisin Media de error de transmisin por tiempo Utilizacin de la capacidad de transmisin Eficiencia de Cumplimiento Pistas de capacidad de auditoria Apoyar la funcin de diagnstico Falta capacidad de anlisis Falta de eficiencia de anlisis Estado de capacidad de supervisin Cambiar la eficiencia del ciclo Cambiar la implementacin mientras transcurre el tiempo Modificacin de la complejidad Parametrizado modificable Cambio del software de capacidad de control Cambio de porcentaje de xito Modificacin de la localizacin del impacto(Error emergentes despus del cambio) Disponibilidad de una funcin de prueba Vuelva a probar la eficiencia Prueba de reinicio Cumplimiento de mantenimiento Capacidad de adaptacin de las estructuras de datos Hardware adaptabilidad ambiental Organizacin de adaptacin al medio ambiente Trasladar la facilidad de uso Sistema de adaptacin de software del medio ambiente Facilidad de instalacin Facilidad de instalacin, Reintentar Disponible co-existencia Uso continuo de los datos Funcin de la inclusin Apoyo a los usuarios la coherencia funcional Cumplimiento de portabilidad
Mantenimiento
Cumplimiento Eficiencia Analizabilidad
de
Modificacin
Estabilidad
Comprobabilidad Cumplimiento Mantenimiento Adaptabilidad de
Portabilidad
Instalacin Co-existencia Sustituir Cumplimiento Portabilidad
Tabla 40: Mtricas Externas ISO/IEC 9126
7.5
LECCIN 5: MTRICAS INTERNAS BASADOS EN ISO/IEC 9126
Ahora se presenta las caractersticas, la sub caractersticas, y las mtricas internas para evaluar software, esta tabla ha sido elaborada teniendo en cuenta la norma ISO/IEC 9126. Para el anlisis de las mtricas internas, tambin pueden ser complementados de acuerdo a las caractrsticas propias del software a evaluar.
caracterstica Funcionalidad sub caracterstica IDONEIDAD nombre mtrica Adecuacin funcional Integridad funcional de aplicacin Cobertura de aplicacin funcional Estabilidad de la especificacin funcional (volatilidad) Precisin de cmputo Precisin Intercambiabilidad de datos (formato de base de datos) Coherencia de interfaz (protocolo) Acceso auditabilidad Acceso controlabilidad Datos de prevencin de la corrupcin Cifrado de datos Cumplimiento funcional Entre sistemas estndar de cumplimiento Deteccin de fallas Eliminacin de fallos Prueba de adecuacin Evitar fallas Evitar el funcionamiento incorrecto Restauracin Restauracin efectiva Confiabilidad de cumplimiento Integridad de la Descripcin Demostracin de la capacidad Funciones evidentes Funcin de la comprensibilidad Integridad de la documentacin del usuario y / o sistema de ayuda Entrada, asegurar su validez Usuario, cancela la operacin Usuario, deshacer la operacin Personalizacin
PRECISIN INTEROPERABILIDAD
SEGURIDAD
FUNCIONALIDAD DE CUMPLIMIENTO Confiabilidad MADUREZ
TOLERANCIA A FALLOS RECUPERACIN FIABILIDAD DE CUMPLIMIENTO COMPRENSIBILIDAD
Usabilidad
APRENDIZAJE OPERABILIDAD
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD 160 ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA - ECBTI CURSO DE EVALUACIN DE SOFTWARE - CDIGO 301569__________________________________________ Accesibilidad fsica Estado de operacin capacidad de vigilancia Consistencia operacional Claridad en los mensajes Interfaz claridad en los elementos Recuperacin de errores operacional Atractivo de interaccin Aparicin de personalizacin Usabilidad de cumplimiento Tiempo de respuesta Rendimiento de tiempo Tiempo por turno Utilizacin de Entradas y Salidas Utilizacin de mensaje de Entrada y Salida Utilizacin de memoria Utilizacin de memoria de mensajes densos Transmisin de Utilizacin Eficiencia de Cumplimiento Actividad de grabacin Preparacin de la funcin de diagnstico Cambio de Registros Impacto del cambio Modificacin de la localizacin del impacto Integridad de los incorporados en las pruebas de funcin Autonoma de la capacidad de prueba Prueba de observabilidad de progreso Cumplimiento de mantenimiento Capacidad de adaptacin de las estructuras de datos Hardware adaptabilidad ambiental Organizacin de adaptacin al medio ambiente Trasladar la facilidad de uso Sistema de adaptacin de software del medio ambiente Facilidad de instalacin, vuelva a intentar Esfuerzo de instalacin Flexibilidad de instalacin Disponible co-existencia Uso continuo de los datos Funcin de la inclusin
ATRACTIVO CUMPLIMIENTO DE USABILIDAD TIEMPO DE COMPORTAMIENTO
Eficiencia
UTILIZACIN DE RECURSOS
Mantenimiento
CUMPLIMIENTO DE EFICIENCIA ANALIZABILIDAD MODIFICACIN ESTABILIDAD COMPROBABILIDAD
Portabilidad
CUMPLIMIENTO DE MANTENIMIENTO ADAPTABILIDAD
INSTALACIN
CO-EXISTENCIA SUSTITUIR
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD 161 ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA - ECBTI CURSO DE EVALUACIN DE SOFTWARE - CDIGO 301569__________________________________________ CUMPLIMIENTO PORTABILIDAD Cumplimiento de portabilidad
Tabla 41: Mtricas Internas ISO/IEC 9126
CAPITULO 8
METODOLOGIAS DE EVALUACIN DE LA ARQUITECTURA DEL SOFTWARE
INTRODUCCIN La Arquitectura de Software es una prctica joven tiene sus orgenes en la dcada de 1960, pero solo hasta los aos 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, desarrollndose los de estilos arquitectnicos, los ADL (Leguajes de Descripcin Arquitectnica), que aunque poco difundidos, han dado al traste con la creacin 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 corazn de todo sistema informtico y determina cules sern 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 disear 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 prctica de ingeniera, es recomendable realizar evaluaciones a la arquitectura del software. En este captulo se explica el procedimiento para realizar la evaluacin de una arquitectura, destacando algunos mtodos de evaluacin existentes, al final se har el estudio de una propuesta denominada MECABIC o Mtodo de Evaluacin de la Calidad de Arquitecturas Basadas en la Integracin de Componentes, cuyo objetivo principal es evaluar y analizar la calidad de este tipo de Arquitectura de Software. Aqu se har la revisin de los diferentes mtodos de la evaluacin de arquitecturas de software, para analizar e identificar potencialidades de los diferentes mtodos o procedimientos y hacer el estudio de las caractersticas comparativas de cada una de ellas. Se realizar un estudio del estado del arte de la evaluacin de arquitecturas de software. Para introducirse en el tema se tratan aspectos como los principales problemas que causa la arquitectura en un proyecto, tambin se define que es la evaluacin de arquitecturas, sus caractersticas, objetivos que persigue. Se hace adems un anlisis de cundo y por qu una determinada arquitectura debe ser evaluada y los beneficios que reporta.
8.1
LECCIN 1: EVALUACIN DE LA ARQUITECTURA DE SOFTWARE
La evaluacin de software es como un estudio de factibilidad que pretende detectar posibles riesgos, y buscar recomendaciones para contenerlos, teniendo en cuenta que la evaluacin se realiza antes de la implementacin de la solucin. 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 estn relacionadas con el sistema. La evaluacin de una arquitectura de software es una tarea donde se pretende medir propiedades del sistema en base a especificaciones abstractas, como por ejemplo los diseos arquitectnicos. Las mediciones que se realizan sobre una arquitectura de software pueden tener distintos objetivos de tipo cualitativo, cuantitativo, o mximos y mnimos tericos. La medicin cualitativa se aplica para la comparacin entre arquitecturas candidatas y tiene relacin con la intencin de saber la opcin que se adapta mejor a cierto atributo de calidad. La medicin cuantitativa busca la obtencin de valores que permitan tomar decisiones en cuanto a los atributos de calidad de una arquitectura de software, el esquema general es la comparacin con mrgenes establecidos, como lo son los requerimientos de desempeo, para establecer el grado de cumplimiento de una arquitectura candidata, o tomar decisiones sobre ella. La medicin de mximo y mnimo terico contempla los valores tericos para efectos de la comparacin de la medicin con los atributos de calidad especificados, el conocimiento de los valores mximos o mnimos permite el establecimiento claro del grado de cumplimiento de los atributos de calidad. El propsito 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 estn presentes en la arquitectura, as como determinar el grado de stisfaccin de los atributos de calidad. Un atributo de calidad es una caracterstica de calidad que afecta a un elemento, donde el trmino caracterstica se refiere a aspectos no funcionales y el termino elemento a componente. La evaluacin de la arquitectura puede realizarse en cualquier momento, pero se propone dos etapas distintas para realizarlas: La evaluacin temprana que puede realizarse sin necesidad de que la arquitectura est completamente especificada para efectuar la evaluacin, abarca las fases tempranas de diseo y del desarrollo, y la evaluacin tarde que se hace cuando la arquitectura ya esta establecida y la implementacin se ha completado. Generalmente las evaluaciones a la arquitectura se hacen por miembros del equipo de desarrollo, arquitecto, diseador, entre otros. Otro actor interesado por
los resultados de una evaluacin es el cliente, ya que dependiendo de los resultados puede tomar decisiones de continuar o no con el proyecto. Las tnicas de evaluacin de arquitecturas se clasifican en tcnicas cualitativas y tcnicas cuantitativas. Las tcnicas cualitativas basadas en preguntas sobre la arquitectura (cuestionarios: abiertas y tempranas, checklist: especfico del dominio de la aplicacin, y escenarios: especficas del sistema, para arquitectura avanzada), y las cuantitativas que utiliza mtricas como acoplamiento, cohesividad en los mdulos, profundidad en herencias, modificabilidad. Generalmente las tcnicas de evaluacin cualitativas son utilizadas cuando la arquitectura est en construccin, mientras que las tcnicas de evaluacin cuantitativas se usan cuando la arquitectura ya ha sido implantada.
Figura 32: Clasificacin de las Tcnicas de Evaluacin. 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 tardas del desarrollo. La arquitectura puede ser evaluada teniendo en cuenta la clasificacin de los atributos de calidad, donde se hace la clasificacin en dos categoras: Observables va ejecucin que son aquellos atributos que se determinan del comportamiento del sistema en tiempo de ejecucin. La descripcin de algunos de estos atributos se presenta en la siguiente tabla:
Atributo de calidad Disponibilidad Confidencialidad Descripcin Es la medida de disponibilidad del sistema para el uso. Es la ausencia de acceso no autorizado a la informacin.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD 166 ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA - ECBTI CURSO DE EVALUACIN DE SOFTWARE - CDIGO 301569__________________________________________ Funcionalidad Desempeo 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 catastrficas en el ambiente. Es la medida de ausencia de errores que generan prdidas de informacin Es la medida de la habilidad del sistema para resistir a intentos de uso no autorizados y negacin del servicio, mientras se sirve a usuarios legtimos
Tabla 42: Descripcin de atributos de calidad observables va ejecucin No observables va ejecucin: aquellos atributos que se establecen durante el desarrollo del sistema. La descripcin 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 Prueba Descripcin 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 informacin 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 evolucin Es la habilidad del sistema para ser ejecutado en diferentes ambientes de computacin. Estos ambientes pueden ser hardware, software o una combinacin de los dos Es la capacidad de disear 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 diseo arquitectnico, 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
Tabla 43: Descripcin de atributos de calidad no observables va ejecucin 8.2 LECCIN 2: TCNICAS DE EVALUACIN DE ARQUITECTURAS DE SOFTWARE Las tcnicas utilizadas para la evaluacin de atributos de calidad requieren grandes esfuerzos del ingeniero de software para crear especificaciones y predicciones. Estas tcnicas requieren informacin del sistema a desarrollar que no est disponible durante el diseo arquitectnico, sino al principio del diseo detallado del sistema.
Las tcnicas existentes en la actualidad para evaluar arquitecturas permiten hacer una evaluacin cuantitativa sobre los atributos de calidad a nivel arquitectnico, pero se tienen pocos medios para predecir el mximo (o mnimo) terico para las arquitecturas de software. Debido al costo de realizar este tipo de evaluacin, en muchos casos los arquitectos de software evalan cualitativamente, para decidir entre las alternativas de diseo. Se han propuesto diferentes tcnicas de evaluacin de arquitecturas de software, algunas son: Evaluacin basada en escenarios, Evaluacin basada en simulacin, Evaluacin basada en modelos matemticos y Evaluacin basada en experiencia. 8.2.1 Evaluacin basada en escenarios Un escenario es una breve descripcin de la interaccin de alguno de los involucrados en el desarrollo del sistema con ste. Por ejemplo, un usuario har la descripcin en trminos de la ejecucin 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 construccin o prediccin de su desempeo. Un escenario consta de tres partes: El estmulo, que es la parte del escenario que explica o escribe lo que el involucrado en el desarrollo hace para iniciar la interaccin con el sistema, incluye la ejecucin de tareas, cambios en el sistema, ejecucin de pruebas, configuracin, etc. El contexto, que describe qu sucede en el sistema al momento del estmulo. Y la respuesta que describe a travs de la arquitectura, cmo debera responder el sistema ante el estmulo. Este ltimo elemento es el que permite establecer cul 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 slo para efectos de la evaluacin de arquitecturas de software. Actualmente las tcnicas basadas en escenarios cuentan con dos instrumentos de evaluacin 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 intencin del uso del Utility Tree es la identificacin de los atributos de calidad ms 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 construccin del rbol. El Utility Tree contiene como nodo raz la utilidad general del sistema. Los atributos de calidad asociados al mismo conforman el segundo nivel del rbol, los cuales se refinan hasta la obtencin 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 evaluacin 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 ms precisas del requerimiento para un atributo de calidad. Los perfiles tienen asociados dos formas de especificacin: Los perfiles completos que definen los escenarios importantes como parte del perfil. Esto permite al ingeniero de software realizar un anlisis 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 pequeos y slo es posible predecir conjuntos de escenarios completos para algunos atributos de calidad. Los perfiles seleccionados que se asemejan a la seleccin de muestras sobre una poblacin en los experimentos estadsticos. Se toma un conjunto de escenarios de forma aleatoria, de acuerdo a algunos requerimientos. La aleatoriedad no es totalmente cierta por limitaciones prcticas, por lo que se fuerza la realizacin de una seleccin estructurada de elementos para el conjunto de muestra. Si bien es informal, permite hacer proposiciones cientficamente vlidas. Para la definicin de un perfil, es necesario seguir tres pasos: definicin de las categoras del escenario, seleccin y definicin de los escenarios para la categora y asignacin del peso a los escenarios. La definicin de categoras de escenarios divide la poblacin de escenarios en poblaciones ms pequeas, que cubren aspectos particulares del sistema. La seleccin y definicin de escenarios para cada categora selecciona un conjunto de escenarios representativo para la subpoblacin. Luego, en la asignacin 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 ms de un atributo de calidad. Han sido seleccionados cinco atributos de calidad que son considerados de mayor relevancia para una perspectiva general de ingeniera de software, ellos son: desempeo (performance), mantenibilidad (maintainability), confiabilidad (reliability), seguridad externa (safety) y seguridad interna (security). La efectividad de la tcnica es altamente dependiente de la representatividad de los escenarios. Existe la evaluacin de funcionalidad basada en escenarios, y es utilizada en el diseo orientado a objetos para especificar comportamiento del sistema. La diferencia entre este tipo de evaluacin y la evaluacin arquitectnica basada en escenarios radica en que la ltima utiliza los escenarios para evaluar atributos de calidad, en lugar de verificar o describir
funcionalidad, adems 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 categoras, el significado de los pesos y posibles mtricas de evaluacin.
Atributo Mantenibilid ad Perfil Perfil de mantenimiento (Maintainance profile) Categoras 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 perodo de tiempo Mtricas - Impacto en trmino de lneas de cdigo que tienen que cambiarse - Se requiere un estimado de lneas de cdigo de los componentes arquitectnicos. - Funcionalidad de componentes - Comportamiento del sistema en respuesta a los escenarios de uso en el perfil - Promedio y peor caso de latencia por sincronizacin y sobrecarga en el sistema - Datos estimados de confiabilidad del componente - Datos histricos de confiabilidad del componente Depende del aspecto de seguridad a ser evaluado. Por ejemplo, la disponibilidad puede evaluarse en trminos del nmero de veces que se ejecutan operaciones de seguridad. Bosch (2000) no establece ejemplos
Desempeo
Perfil de uso (Usage profile)
Representan la frecuencia relativa del escenario
Confiabilida d
Perfil de uso (Usage profile)
Confiabilidad de los componentes, genera la confiabilidad de los escenarios de uso Basada en todas las interfaces del sistema
Indica robustez del sistema
la
Seguridad Interna
Perfil de seguridad (Security profile) Perfil de uso (usage profile)
Indica la probabilidad de fallas
Seguridad Externa
Perfil de peligro (Hazard profile)
Se organizan de a acuerdo documentos de certificacin (puntos de interaccin del sistema con el mundo real, o componentes crticos del sistema)
Indican la probabilidad de falla u ocurrencia de consecuencias desastrosas.
Tabla 44: Perfiles, categorias, Pesos, y Mtricas Asociados a atributos de Calidad La evaluacin basada en escenarios puede ser empleada para comparar dos arquitecturas y para la evaluacin absoluta de una arquitectura. La diferencia est en que la evaluacin absoluta requiere mayor cantidad de datos estimados y cuantitativos necesarios para la evaluacin. La tcnica se puede descompones en dos etapas: El anlisis de impacto, que toma como entrada el perfil y la arquitectura de software, para cada escenario del perfil, se evala el impacto de la arquitectura y se obtienen los resultados. La etapa de prediccin de resultados, donde los resultados sern usados para pronosticar el valor del atributo de calidad estudiado de acuerdo a las mtricas existentes. 8.2.2 Evaluacin basada en simulacin La evaluacin basada en simulacin utiliza una implementacin de alto nivel de la arquitectura de software. El enfoque bsico consiste en la implementacin de componentes de la arquitectura y la implementacin 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 evaluacin basada en simulacin sigue los pasos mostrados en la siguiente tabla:
Pasos implementacin Definicin Consiste en identificar las interfaces de la arquitectura de software con su contexto, y decidir cmo ser simulado el comportamiento del contexto en tales interfaces. La descripcin del diseo arquitectnico debe definir las interfaces y las conexiones de los componentes, por lo que estas partes pueden ser tomadas directamente de la descripcin de diseo. La descripcin del diseo arquitectnico debe definir las interfaces y las conexiones de los componentes, por lo que estas partes pueden ser tomadas directamente de la descripcin de diseo. Dependiendo del atributo de calidad que el arquitecto de software intenta evaluar usando simulacin, el perfil asociado necesitar ser implementado en el sistema. El arquitecto de software debe ser capaz de activar escenarios individuales, as como tambin ejecutar un perfil completo usando seleccin aleatoria, basado en los pesos normalizados de los mismos. El arquitecto de software ejecutar la simulacin y activar escenarios de forma manual o automtica, y obtendr resultados de acuerdo al atributo de calidad que est siendo evaluado.
Definicin contexto
del
Implementacin de componentes arquitectnicos Implementacin de componentes arquitectnicos Implementacin del perfil
los
los
Simulacin del sistema e inicio del perfil
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD 171 ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA - ECBTI CURSO DE EVALUACIN DE SOFTWARE - CDIGO 301569__________________________________________ Prediccin de atributos de calidad Dependiendo del tipo de simulacin 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 Evaluacin Basada en Simulacin En el mbito de las simulaciones, se encuentra la tcnica de implementacin de prototipos. Esta tcnica 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 desempeo y confiabilidad. 8.2.3 Evaluacin basada en modelos matemticos La evaluacin basada en modelos matemticos se utiliza para evaluar atributos de calidad operacionales. Permite una evaluacin esttica de los modelos de diseo arquitectnico, y se presentan como alternativa a la simulacin, dado que evalan el mismo tipo de atributos. Ambos enfoques pueden ser combinados, utilizando los resultados de uno como entrada para el otro. El proceso de evaluacin basada en modelos matemticos sigue los pasos mostrados en la siguiente tabla:
Pasos Seleccin y adaptacin del modelo matemtico Definicin Existen varios modelos matemticos para medir sus atributos de calidad, los cuales tienden a ser muy elaborados y detallados, as como tambin requieren de cierto tipo de datos y anlisis. Parte de estos datos requeridos no estn disponibles a nivel de arquitectura, y la tcnica requiere mucho esfuerzo para la evaluacin arquitectnica, por lo cual se debe adaptar el modelo. El modelo matemtico 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 trminos del modelo. El modelo matemtico an cuando ha sido adaptado, requiere datos de entrada que no estn incluidos en la definicin bsica de la arquitectura. Es necesario estimar y deducir estos datos de la especificacin de requerimientos y de la arquitectura diseada. Una vez que la arquitectura es expresada en trminos del modelo y se encuentran disponibles todos los datos de entrada requeridos, el arquitecto est en capacidad de calcular la prediccin resultante del atributo de calidad evaluado.
Representacin de la arquitectura en trminos del modelo
Estimacin de los datos de entrada requeridos
Prediccin de atributos de calidad
Tabla 46: Pasos para la Evaluacin Basada en Modelos Matemticos
Entre los instrumentos que se cuentan para las tcnicas de evaluacin de arquitecturas de software basada en modelos matemticos, se encuentran las Cadenas de Markov y los denominados Reliability Block Diagrams. 8.2.4 Evaluacin basada en experiencia En muchas ocasiones los arquitectos e ingenieros de software otorgan valiosas ideas que resultan de utilidad para evitar decisiones erradas de diseo. Aunque todas estas experiencias se basan en factores subjetivos como la intuicin y la experiencia. Sin embargo, la mayora de ellas puede ser justificada por una lnea lgica de razonamiento, y pueden ser la base de otros enfoques de evaluacin. Existen dos tipos de evaluacin basada en experiencia: la evaluacin informal, que es realizada por los arquitectos de software durante el proceso de diseo, y la realizada por equipos externos de evaluacin de arquitecturas. La siguiente tabla muestra los instrumentos utilizados por las diferentes tcnicas de evaluacin.
Tcnica de Evaluacin Basada en Escenarios Basada en Simulacin Basada en Modelos Matemticos Basada en Experiencia Instrumento de Evaluacin - Profiles - Utility Tree - Lenguajes de Descripcin Arquitectnica (ADL) - Modelos de colas - Cadenas de Markov - Reliability Block Diagrams - Intuicin y experiencia - Tradicin - Proyectos similares
Tabla 47: Instrumentos asociados a las distintas tcnicas de evaluacin de arquitecturas de software 8.3 LECCIN 3: MTODOS DE EVALUACIN DE ARQUITECTURAS DE SOFTWARE Los mtodos de anlisis de arquitecturas de software hace que el proceso sea repetible, y ayuda a garantizar que las respuestas correctas con relacin a la arquitectura pueden hacerse durante las fases tempranas de diseo. Es en este punto donde los problemas encontrados pueden ser solucionados de una forma relativamente poco costosa. Un mtodo de evaluacin sirve de gua a los involucrados en el desarrollo del sistema, en la bsqueda de conflictos que puede presentar una arquitectura, y sus soluciones.
Actualmente existen mltiples mtodos de evaluacin han sido propuestos para la evaluacin de la arquitectura del software. A continuacin se presentan algunos de los ms importantes:
8.3.1 Software Architecture Analysis Method (SAAM) El Mtodo de Anlisis de Arquitecturas de Software denominado SAAM, es el primero que fue ampliamente promulgado y documentado. El mtodo fue originalmente creado para el anlisis de la modificabilidad de una arquitectura, pero en la prctica ha demostrado ser muy til para evaluar de forma rpida distintos atributos de calidad, tales como modificabilidad, portabilidad, escalabilidad e integrabilidad. El mtodo de evaluacin SAAM, se enfoca en la enumeracin 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 descripcin de la arquitectura a ser evaluada. Las salidas de la evaluacin del mtodo SAAM son las siguientes: - Una proyeccin 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 comparacin de mltiples arquitecturas con respecto al nivel de funcionalidad que cada una soporta sin modificacin Si se evala una sola arquitectura se obtienen los lugares en los que la misma puede fallar, en trminos de los requerimientos de modificabilidad. Para el caso en el que se cuenta con varias arquitecturas candidatas, el mtodo produce una escala relativa que permite observar qu opcin satisface mejor los requerimientos de calidad con la menor cantidad de modificaciones. Los pasos que contempla el mtodo de evaluacin SAAM se muestran en la siguiente tabla:
1. Desarrollo de escenarios 2. Descripcin arquitectura de la Un escenario es una breve descripcin 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 notacin arquitectnica que sea comn a todas las partes involucradas en el anlisis. Deben incluirse los componentes de datos y conexiones relevantes, as como la descripcin del comportamiento general del sistema. La clasificacin 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
3. Clasificacin y asignacin de prioridad de los escenarios
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD 174 ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA - ECBTI CURSO DE EVALUACIN DE SOFTWARE - CDIGO 301569__________________________________________ en la arquitectura para poder satisfacerse. Los escenarios indirectos son de especial inters para SAAM, pues son los que permiten medir el grado en el que una arquitectura puede ajustarse a los cambios de evolucin 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 modificacin sobre la arquitectura significa que debe introducirse un nuevo componente o conector, o que alguno de los existentes requiere cambios en su especificacin. Cuando dos o ms escenarios indirectos proponen cambios sobre un mismo componente, se dice que interactan sobre ese componente. Es necesario evaluar este hecho, puesto que la interaccin de componentes semnticamente no relacionados revela que los componentes de la arquitectura efectan funciones semnticamente distintas. De forma similar, puede verificarse si la arquitectura se encuentra documentada a un nivel correcto de descomposicin estructural. Debe asignrsele un peso a cada escenario, en trminos de su importancia relativa al xito del sistema. Esta asignacin de peso suele hacerse con base en las metas del negocio que cada escenario soporta. En el caso de la evaluacin de mltiples arquitecturas, la asignacin de pesos puede ser utilizada para la determinacin de una escala general.
4. Evaluacin individual de los escenarios indirectos
5. Evaluacin de la interaccin entre escenarios
6. Creacin de la evaluacin global
Tabla 48: Pasos contemplados por el mtodo de evaluacin SAAM 8.3.2 Architecture Trade-off Analysis Method (ATAM) El Mtodo de Anlisis de Acuerdos de Arquitectura denominado ATAM, est inspirado en tres reas distintas: los estilos arquitectnicos, el anlisis de atributos de calidad y el mtodo de evaluacin SAAM. El mtodo ATAM revela la forma en que una arquitectura especfica satisface ciertos atributos de calidad, y provee una visin de cmo los atributos de calidad interactan con otros; osea, los tipos de acuerdos que se establecen entre ellos. El mtodo se concentra en la identificacin de los estilos arquitectnicos o enfoques arquitectnicos utilizados. Estos elementos representan los medios empleados por la arquitectura para alcanzar los atributos de calidad, as como tambin permiten describir la forma en la que el sistema puede crecer, responder a cambios, e integrarse con otros sistemas. El mtodo de evaluacin ATAM comprende nueve pasos, agrupados en cuatro fases. La siguiente tabla presenta las fases y sus pasos enumerados, junto con su descripcin.
Fase 1: Presentacin 1. Presentacin del ATAM 2. Presentacin de las metas del negocio El lder de evaluacin describe el mtodo a los participantes, trata de establecer las expectativas y responde las preguntas propuestas. Se realiza la descripcin de las metas del negocio que motivan el esfuerzo, y aclara que se persiguen objetivos de tipo arquitectnico.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD 175 ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA - ECBTI CURSO DE EVALUACIN DE SOFTWARE - CDIGO 301569__________________________________________ 3. Presentacin arquitectura de la El arquitecto describe la arquitectura, enfocndose en cmo sta cumple con los objetivos del negocio.
Fase 2: Investigacin y anlisis 4. Identificacin de los enfoques Estos elementos son detectados, pero no analizados. arquitectnicos 5. Generacin del Utility Tree Se elicitan los atributos de calidad que engloban la utilidad del sistema (desempeo, disponibilidad, seguridad, modificabilidad, usabilidad, etc.), especificados en forma de escenarios. Se anotan los estmulos y respuestas, as como se establece la prioridad entre ellos. 6. Anlisis de los enfoques Con base en los resultados del establecimiento de prioridades arquitectnicos del paso anterior, se analizan los elementos del paso 4. En este paso se identifican riesgos arquitectnicos, puntos de sensibilidad y puntos de balance. Fase 3: Pruebas 7. Lluvia de ideas y establecimiento de prioridad de escenarios. 8. Anlisis de los enfoques arquitectnicos Fase 4: Reporte 9. Presentacin resultados Con la colaboracin 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 anlisis realizado hasta el momento. Basado en la informacin recolectada a lo largo de la evaluacin del ATAM, se presentan los hallazgos a los participantes.
de
los
Tabla 49: Pasos del mtodo de evaluacin ATAM 8.3.3 Active Reviews for Intermediate Designs (ARID) El mtodo ARID es conveniente para realizar la evaluacin de diseos parciales en las etapas tempranas del desarrollo. En ocasiones, es necesario saber si un diseo propuesto es conveniente, desde el punto de vista de otras partes de la arquitectura. ARID es un hbrido entre Active Design Review (ADR) y Architecture Trade-Off Method (ATAM). ADR es utilizado para la evaluacin de diseos detallados de unidades del software como los componentes o mdulos. Las preguntas giran en torno a la calidad y completitud de la documentacin y la suficiencia, el ajuste y la conveniencia de los servicios que provee el diseo propuesto. Tanto ADR como ATAM proveen caractersticas tiles para el problema de la evaluacin de diseos preliminares. En el caso de ADR, los involucrados reciben documentacin detallada y completan cuestionarios, cada uno por separado. En el caso de ATAM, est orientado a la evaluacin de toda una arquitectura. Ante la necesidad de evaluacin en las fases tempranas del diseo, se propone la utilizacin de las caractersticas que proveen tanto ADR como ATAM
por separado. De la combinacin de ambas filosofas surge ARID, para efecto de la evaluacin temprana de los diseos de una arquitectura de software. La siguiente tabla muestra los pasos del mtodo de evaluacin ARID, con una breve descripcin de cada uno:
Fase 1: Actividades Previas 1. Identificacin de los encargados de la revisin 2. Preparar Diseo el informe de
3. Preparar base
los
escenarios
4. Preparar los materiales Fase 2: Revisin 5. Presentacin del ARID 6. Presentacin del diseo
Los encargados de la revisin son los ingenieros de software que se espera que usen el diseo, y todos los involucrados en el diseo. En este punto, converge el concepto de encargado de revisin de ADR e involucrado del ATAM. El diseador prepara un informe que explica el diseo. Se incluyen ejemplos del uso del mismo para la resolucin de problemas reales. Esto permite al facilitador anticipar el tipo de preguntas posibles, as como identificar reas en las que la presentacin puede ser mejorada. El diseador y el facilitador preparan un conjunto de escenarios base. De forma similar a los escenarios del ATAM y el SAAM, se disean para ilustrar el concepto de escenario, que pueden o no ser utilizados para efectos de la evaluacin. Se reproducen los materiales preparados para ser presentados en la segunda fase. Se establece la reunin, y los involucrados son invitados. Se explica los pasos del ARID a los participantes. El lder del equipo de diseo realiza una presentacin, con ejemplos incluidos. Se propone evitar preguntas que conciernen a la implementacin o argumentacin, as como alternativas de diseo. El objetivo es verificar que el diseo es conveniente. Se establece una sesin para la lluvia de ideas sobre los escenarios y el establecimiento de prioridad de escenarios. Los involucrados proponen escenarios a ser usados en el diseo para resolver problemas que esperan encontrar. Luego, los escenarios son sometidos a votacin, y se utilizan los que resultan ganadores para hacer pruebas sobre el diseo. Comenzando con el escenario que cont con ms votos, el facilitador solicita pseudo-cdigo que utiliza el diseo para proveer el servicio, y el diseador no debe ayudar en esta tarea. Este paso contina hasta que ocurra alguno de los siguientes eventos: - Se agota el tiempo destinado a la revisin - Se han estudiado los escenarios de ms alta prioridad - El grupo se siente satisfecho con la conclusin alcanzada. Puede suceder que el diseo presentado sea conveniente, con la exitosa aplicacin 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
7. Lluvia de ideas establecimiento de prioridad de escenarios
8. Aplicacin escenarios
de
los
9. Resumen
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD 177 ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA - ECBTI CURSO DE EVALUACIN DE SOFTWARE - CDIGO 301569__________________________________________ de revisin, y agradece por su participacin.
Tabla 50: Pasos del mtodo de evaluacin ARID
8.3.4 Modelo de Negociacin WinWin El modelo WinWin provee un marco de referencia general para identificar y resolver conflictos de requerimientos. El modelo utiliza la teora 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 resolucin de posibles conflictos, no siempre es posible llegar a un acuerdo. En este sentido, el mtodo CBAM provee medios para establecer los balances necesarios, y un marco de referencia para la discusin que puede llevar a una posible solucin del problema. 8.3.5 Cost-Benefit Analysis Method (CBAM) El mtodo de anlisis 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 mtodo son las llamadas estrategias arquitectnicas, que consisten en posibles opciones para la resolucin de conflictos entre atributos de calidad presentes en una arquitectura. El mtodo CBAM abarca los siguientes aspectos: Seleccin de escenarios, Evaluacin de los beneficios de los atributos de calidad, Cuantificacin de los beneficios de las estrategias arquitectnicas, Cuantificacin de los costos de las estrategias arquitectnicas y las implicaciones de calendario, Clculo del nivel de deseabilidad y la Toma de decisiones. La siguiente tabla muestra los pasos pertenecientes al marco de referencia para evaluacin de arquitecturas de software para este mtodo:
1. Seleccin de escenarios Cada involucrado en el desarrollo identifica sus condiciones de ganancia. Este paso provee las bases para la identificacin de las caractersticas ideales del sistema esperadas por los involucrados. La lista de condiciones de ganancia es revisada con la intencin 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 resolucin de conflictos, o estrategias arquitectnicas. 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 arquitectnicas elaboradas en el paso
2. Identificacin de los conflictos entre atributos de calidad 3. Exploracin de las opciones en busca de la resolucin de conflictos 4. Medicin de los beneficios de los atributos de calidad
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD 178 ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA - ECBTI CURSO DE EVALUACIN DE SOFTWARE - CDIGO 301569__________________________________________ 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 evaluacin de las estrategias arquitectnicas planteadas en el paso 3. El resultado de la evaluacin permite observar el beneficio de cada uno de los cambios arquitectnicos propuestos. En este paso se calculan los costos e implicaciones de calendario que aplican para cada una de las estrategias arquitectnicas propuestas en el paso 3. No se propone un modelo especfico para la realizacin de la estimacin de costos y tiempo. Este paso contempla una mtrica especial, que se refleja como el cociente entre los beneficios y los costos obtenidos. Las estrategias arquitectnicas que resulten con valores mayores se proponen como las ms recomendables. La recomendacin general es la documentacin del proceso. La acumulacin 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.
5. Cuantificacin beneficios
de
los
6. Cuantificacin de costos e implicaciones de calendario
7. Clculo del nivel de Deseabilidad 8. Alcanzar un acuerdo
Tabla 51: Pasos del mtodo de evaluacin CBAM 8.3.6 Mtodo Diseo y Uso de Arquitecturas de Software propuesto por Bosch Bosch plantea, en su mtodo de diseo de arquitecturas de software, que el proceso de evaluacin debe ser visto como una actividad iterativa, que forma parte del proceso de diseo, tambin iterativo. Una vez que la arquitectura es evaluada, pasa a una fase de transformacin, asumiendo que no satisface todos los requerimientos. Luego, la arquitectura transformada es evaluada de nuevo. El proceso de evaluacin propuesto por Bosch se divide en dos etapas, que son presentadas en la siguiente tabla:
Etapa I 1. Seleccin de atributos de calidad Deben seleccionarse aquellos atributos que se consideran cruciales para el xito del sistema, y cuya satisfaccin 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 evaluacin. Para la evaluacin de los atributos de calidad dependientes del diseo de la arquitectura se recomienda utilizar la evaluacin basada en escenarios, as como tambin los modelos basados en mtricas o modelos matemticos. Los atributos de calidad operacionales (observables va ejecucin) pueden evaluarse con tcnicas de simulacin o modelos matemticos. La seleccin de la tcnica, y la implementacin concreta de sta depende del objetivo y exactitud de la evaluacin. Para cada atributo de calidad, las tcnicas arrojan valores
2. Definicin de los perfiles 3. Seleccin de una tcnica de evaluacin
Etapa II 4. Ejecucin de la evaluacin
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD 179 ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA - ECBTI CURSO DE EVALUACIN DE SOFTWARE - CDIGO 301569__________________________________________ 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 relacin negativa con otro atributo de calidad. El arquitecto puede decidir acerca de la realizacin de transformaciones sobre la arquitectura actual, y efectuar una nueva evaluacin. Una vez que concluye el proceso de evaluacin, con los resultados obtenidos es posible decidir entre la continuacin, renegociacin o cancelacin del proyecto.
5. Obtencin de resultados
Tabla 52: Etapas contempladas por el mtodo de evaluacin de arquitecturas propuesto por Bosch 8.3.7 Mtodo de Comparacin de Arquitecturas Basada en el Modelo ISO/IEC 9126 Adaptado para Arquitecturas de Software Losavio proponen un mtodo para evaluar y comparar arquitecturas de software candidatas, que hace uso del modelo de especificacin de atributos e calidad adaptado del modelo ISO/IEC 9126. Para la evaluacin se plantea la especificacin de los atributos de calidad haciendo uso de un modelo basado en estndares 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 evaluacin. El mtodo 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 mtricas 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 subcaractersticas 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 Mtodo de Comparacin de Arquitecturas Basado en el Modelo ISO/IEC 9126 Adaptado para Arquitecturas de Software de Losavio 8.4 LECCIN 4: MTODOS DE EVALUACIN DE ARQUITECTURA DE UN ATRIBUTO ESPECFICO
Existen otros mtodos de evaluacin de arquitectura del software, que evalan solamente uno de los atributos de calidad especficado por el evaluador, algunos de ellos son:
8.4.1 Architecture Level Modifiability Analysis ALMA Este mtodo es el resultado de los trabajo de investigacin de Brengtsson y Lassing, el atributo de calidad que analiza este mtodo es la facilidad de modificacin, 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 adicin de nuevas funcionalidades. ALMA es un mtodo de evaluacin orientado a metas, que se apoya en el uso de escenarios de cambio, los cuales escriben los eventos posibles que provocaran cambios al sistema, y como se llevaran a cabo estos. El mismo consta de cinco pasos como se muestran en la siguiente figura:
Figura 33: Mtodo de evaluacin 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 tcnicas de evaluacin, tales como la aplicacin de estilos
arquitectnicos, anti-patrones, guas de diseo y modelos. El atributo de calidad que analiza este mtodo es el desempeo, se interesa en saber qu tanto tiempo le toma al sistema software responder cuando una o varios eventos ocurren, as como determinar el nmero de eventos procesados en un intervalo de tiempo dado. Este mtodo tambin se basa en escenarios y puede aplicarse de forma temprana o tarda. Los escenarios generados en este mtodo sirven como punto de partida para la construccin de modelos de desempeo. 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 informacin a los miembros del equipo.
Figura 34: Mtodo de evaluacin de arquitecturas PASA 8.4.3 Scenario based Architecture Level Usability Analysis SALUTA Es el primer mtodo 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 mtodo 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 diseo como patrones de diseos u propiedades que tienen un efecto positivo sobre la facilidad de uso en un sistema software. SALUTA analiza cuatro atributos que estn directamente relacionados con la facilidad de uso de un sistema de software: Facilidad de aprendizaje, Eficiencia
de uso, Confiabilidad y Satisfaccin. El mtodo se basa en escenarios, que en este caso, son escenarios de uso que agrupan uno a ms 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 mtodo:
Figura 35: Mtodo de evaluacin de arquitecturas SALUTA 8.4.4 Survivable Network Analysis SNA Es un mtodo desarrollado por el CERT (Computer Emergency Response Team) que forma parte del SEI (Software Engineering Institute). Este mtodo 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 misin a tiempo, ante la presencia de ataques, fallas o accidentes. Para evaluar esta supervivencia SNA utiliza tres propiedades claves: Resistencia, Reconocimiento y Recuperacin. Este procedimiento puede ser realizado despus de la especificacin de la arquitectura, durante la implementacin de esta, o posteriormente. SNA se basa en la tcnica 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 intrusin, en los que se representan diferentes tipos de ataques al sistema. En la siguiente tabla se muestra cada uno de los pasos del mtodo:
Figura 36: Mtodo de evaluacin de arquitecturas SNA La siguiente tabla muestra una tabla comparativa de cada uno de los mtodos de evaluacin de arquitectura mencionados anteriormente:
Meta ALMA Predecir el costo de mantenimiento, evaluar riesgos, comparacin entre arquitecturas Facilidad modificacin Escenarios cambio de de PASA Analizar la arquitectura con respecto a los objetivos de desempeo de un sistema desempeo escenarios SALUTA Predecir la facilidad de uso de un sistema analizando la arquitectura Facilidad de uso Escenarios uso de de SNA Identificar la capacidad de supervivencia de un sistema ante presencia de ataques, fallas o accidentes supervivencia Escenarios de uso normales y escenarios de intrusin Especificacin de la arquitectura
Atributo de calidad Tcnica de evaluacin entradas
Especificacin de la arquitectura, requerimientos no funcionales
Especificacin la arquitectura
Especificacin de la arquitectura, requerimientos no funcionales relacionados con la facilidad de uso
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD 184 ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA - ECBTI CURSO DE EVALUACIN DE SOFTWARE - CDIGO 301569__________________________________________ salidas Dependiendo de la meta de evaluacin se generan los resultados Arquitecto y equipo de desarrollo Hallazgos encontrados, pasos especficos a seguir y recomendaciones Arquitecto, equipo de desarrollo y administradores del proyecto 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, diseador principal, propietarios del sistema, usuarios No especificado Sistemas comerciales y de gobierno
Personas involucradas
Duracin Validacin del mtodo
No especificado Sistemas de control embebido, sistemas mdicos, telecomunicacione s, sistemas administrativos
7 das Sistemas basados en la web, aplicaciones financieras, y sistemas en tiempo real
Tabla 54: Comparacin entre los mtodos ALMA, PASA, SALUTA y SNA. 8.5 LECCIN 5: MTODO DE EVALUACIN DE ARQUITECTURA MECABIC
MECABIT es uno de los mtodos para evaluar Arquitecturas de Software Basadas en Componentes con el objetivo de que sea aplicado en Arquitecturas Orientadas a Servicios. Este anlisis 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 mtodo se le incluyeron en algunos de sus pasos un enfoque de integracin de elementos de diseo, inspirado en la construccin de partes arquitectnicas adoptado por el Architecture Based Design (ABD). Adems 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 adopcin de este modelo por parte del MECABIC permite concentrarse en caractersticas que dependen exclusivamente de la arquitectura, y al ser un estndar facilita la correspondencia con caractersticas de calidad consideradas por los mtodos estudiados. Los escenarios incluidos en este rbol son especficos para aplicaciones basadas en componentes. En el mtodo MECABIC participan tres grupos de trabajo: Los arquitectos, el evaluador y los relacionados. Para la especificacin de la calidad se hace uso de un rbol de utilidad, el cual tiene como nodo raz 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 especficas y posibles de evaluar. La generacin del rbol de calidad incluye un paso que permite establecer prioridades. Para el anlisis de la arquitectura se utiliza la
tcnica de escenarios, soportada por cuestionarios, para identificar lo que desean los participantes. La siguiente tabla muestra los participantes en el mtodo MECABIT:
Equipo Arquitectos Evaluador Relacionados
Definicin Responsables de generar y documentar una Arquitectura de Software para el sistema estudiado. Integrado por personas expertas en asuntos de calidad quienes guiarn el proceso de evaluacin de la arquitectura Son las personas involucradas de alguna manera con el sistema: programadores, usuarios, gerentes, entre otros.
Fases en las que participan Todas Todas Fases 1, 3 y 4.
Tabla 55: Grupos de Trabajo en el Mtodo MECABIT. 8.5.1 Fases del Mtodo El mtodo consta de cuatro fases, la de presentacin, la de investigacin y anlisis, la de prueba y la presentacin de resultados. A continuacin se describe cada una de las fases: 8.5.1.1 Fase1 Presentacin: En esta fase se da a conocer el mtodo entre todos los grupos, el sistema y su organizacin, y finalmente se presenta cul es la arquitectura que debe ser evaluada. En esta fase se realiza una presentacin del mtodo MECABIC para que los participantes comprendan en qu punto de la aplicacin del mtodo se encuentran en cada momento.Tambin se da a conocer la arquitectura inicial a evaluar y qu caractersticas de calidad se esperan lograr. 8.5.1.2 Fase2 Investigacin y Anlisis: En esta fase se determina de qu manera se va estudiar la arquitectura, se pide a las personas que estn 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 slo participan el grupo evaluador y grupo de arquitectos. En esta fase se identifican elementos de diseo que ayuden a analizar la arquitectura, se especifican los requerimientos planteados durante el paso 2 y se analiza cmo responden los elementos de diseo considerados a los requerimientos. 8.1.1.3 Fase3 - Prueba: Consiste en la revisin de la segunda fase y en ella participan todos los grupos. 8.1.1.4 Fase4 Presentacin de Resultados: En la ltima fase se lleva a cabo a presentacin de los resultados. En esta fase participan todos los grupos. Fase de Generacin de la arquitectura final y reporte. En este momento se cuenta ya con un anlisis 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 evaluacin, entonces se puede pasar al paso 10 directamente. Si por el contrario en algn elemento de diseo existen decisiones en las que resulte favorecido algn requerimiento, entonces los usuarios y desarrolladores son los que tienen que determinar o acordar cules requerimientos favorecer. En la siguiente tabla se muestra el mtodo MECABIT, con cada una de las fases y el detalle de los pasos que se deben dar para la aplicacin del mtodo:
Fase 1: Fase de presentacin 1. Presentacin del mtodo. En el primer paso el director de evaluacin presenta el mtodo 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 mtodo. Se pide a las personas que comenten sus expectativas o que hagan preguntas particulares acerca de lo que esperan de la aplicacin del mtodo. Cada persona que posee una responsabilidad sobre la evaluacin, 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 tpicos que debera contener esta presentacin son: las funcionalidades ms importantes del sistema, los objetivos del negocio y el contexto relacionado con el proyecto, el grupo dirigente de los desarrolladores y usuarios, las directrices arquitectnicas, restricciones tcnicas, gerenciales, econmicas y polticas y obertura de la evaluacin y lmites del sistema. El arquitecto o grupo de representantes explican a las personas como desarrollador, usuario o gerente, cul es la arquitectura evaluada. Debe contener una clara diferenciacin estructural, la cual deber mostrar claramente las relaciones entre componentes de la arquitectura y las diferentes granularidades involucradas. El arquitecto cubre restricciones tcnicas y los alcances arquitectnicos usados para alcanzar los requerimientos. El arquitecto debe transmitir lo esencial y de esta manera abreviada la informacin de la arquitectura que requiere el equipo.
2. Presentacin de directrices del negocio.
las
3. Presentacin arquitectura.
de
la
Fase2: Investigacin y Anlisis 4. Identificacin de Contemplan alternativas de diseo de la arquitectura, que elementos de diseo. posteriormente sern analizadas para ver cmo responden a los requerimientos de calidad. La arquitectura debe ser evaluada completamente desde el sistema con sus componentes de mayor granularidad, hasta el mnimo nivel de granularidad que corresponde a los componentes. Se propone identificar elementos de diseo dentro de una arquitectura basada en componentes, como un componente, y el conjunto de componentes con los cuales interacta, un conjunto de asociaciones que sea de inters sobre alguna caracterstica de
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD 187 ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA - ECBTI CURSO DE EVALUACIN DE SOFTWARE - CDIGO 301569__________________________________________ calidad particular o conjunto de decisiones que tenga influencia considerable sobre otros elementos de diseo. Para identificar un elemento de diseo 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 diseo depende de la importancia que pueda tener dentro de la evaluacin, del conjunto de decisiones o adaptaciones a realizar, y del conocimiento de las personas que estn relacionadas con el sistema y estn en la evaluacin. El rbol de utilidad inicial especifico a partir del cual seleccionan un conjunto de escenarios de inters, est basado en el modelo de calidad ISO/IEC 9126-1 para arquitecturas de software. Se asume que al aplicar el mtodo, las funcionalidades presentes en el sistema son las que necesitan los usuarios, y no se incluye escenarios de aptitud (subcaracterstica 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 cules son los que sern incluidos en el rbol de utilidad. Este paso brinda la posibilidad de verificar si es necesario incluir en el rbol de utilidad algn otro escenario. La seleccin del resto de los escenarios puede realizarse por votacin como propone originalmente el ATAM. Luego se organizan los escenarios de calidad introducidos no contemplados en la tabla de generacin del rbol de utilidad inicial por caractersticas de calidad. Posteriormente, se procede a priorizarlos, es decir, ordenar los escenarios ya que de esta manera se puede tener una orientacin para tomar decisiones arquitectnicas, 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?, cuntas 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). Finalmente, se construye el rbol de utilidad con las salidas del paso anterior. La prioridad del escenario define en este mtodo 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 diseo identificados en el paso 4 o de nuevos elementos de diseo que puedan ser identificados, para determinar cmo influyen sobre la realizacin de los escenarios de calidad presentes en el rbol de utilidad generado en el paso 5.
5. Generacin del rbol de utilidad.
6. Anlisis de elementos de diseo para ASBC.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD 188 ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA - ECBTI CURSO DE EVALUACIN DE SOFTWARE - CDIGO 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 relacin entre puertos, de acuerdo a algn criterio de calidad. Los escenarios de calidad deben ser aplicados a la arquitectura que ha sido generada. El equipo de evaluacin se orienta con las preguntas de anlisis propuestas por el mtodo 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 diseo. Se deben estudiar los riesgos que introduce la decisin en particular, o si sta contribuye a algn riesgo ya determinado. Tambin se pueden documentar decisiones que no han sido tomadas o asuntos no resueltos que a juicio del equipo de evaluacin pueden ser resueltos en un futuro estudiando con ms detalle el elemento de diseo considerado. Fase3: prueba 7. Revisin del rbol de utilidad. Se propone utilizar escenarios de calidad para representar los intereses de todos los grupos de la evaluacin y confirmar que se han evaluado los requerimientos deseados de calidad. El equipo de evaluacin puede facilitar la elaboracin 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 consideracin y priorizacin 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 tambin 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 haba 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 algn aspecto de calidad importante y puede existir un riesgo a documentar. El equipo evaluador debe estudiar de qu manera los elementos de diseo analizados en el paso 6, promueven los escenarios propuestos por el nuevo grupo de usuarios y desarrolladores. En
8. Revisin de los elementos de diseo definidos.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD 189 ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA - ECBTI CURSO DE EVALUACIN DE SOFTWARE - CDIGO 301569__________________________________________ caso que no promuevan las caractersticas de calidad deseadas, deben ser reconsiderados. Fase4: Presentacin de los resultados 9. Generacin de los Se decide cul 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 negociacin crtica, ya que de fallar, implicara 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 estn contentos con el sistema. Finalmente, se documentan todos aquellos requerimientos de calidad para los cuales no es posible encontrar una solucin, justificando las razones. 10. Presentacin de los Se presenta un resumen de la aplicacin del mtodo, de forma resultados. oral y/o escrita. Se deben incluir entonces, los siguientes documentos a partir de los cuales se inici la evaluacin: a) b) c) d) e) f) g) h) i) j) Contexto del negocio. Requerimientos de Calidad. Restricciones. Arquitectura producida. Anlisis de elementos de diseo identificados. Conjunto de escenarios negociados. Conjunto de preguntas para evaluacin de atributos. rbol de Utilidad. No-riesgos documentado. Puntos sensibles y de negociacin.
Tabla 56: Fases Contempladas en el Mtodo de evaluacin de Arquitecturas MECABIT. La generacin del rbol de utilidades, descrito en el punto 5 de la fase 2, acerca de la Investigacin y Anlisis, del mtodo es tomada de acuerdo a la norma ISO/IEC 9126 y adaptada para la evaluacin de la arquitectura de software. A continuacin se muestra el rbol de utilidad aplicado para el mtodo MECABIT.
Caracterstica Funcionalidad Sub-caracterstica Interoperabilidad 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 comunicacin entre los componentes no altera la exactitud de los datos El sistema detecta la actuacin de un intruso e
Precisin
Seguridad
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD 190 ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA - ECBTI CURSO DE EVALUACIN DE SOFTWARE - CDIGO 301569__________________________________________ impide acceso a los componentes que manejen informacin sensible El sistema asegura que los componentes no pierdan datos ante un ataque (interno o externo). Los componentes respetan un estndar de fiabilidad. La comunicacin entre los componentes no viola los estndares 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 ningn 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 sustitucin/adaptacin de un componente. El sistema debe continuar funcionando correctamente aun cuando los servicios de los componentes provistos por el ambiente varen. Los componentes pueden instalarse fcilmente en todos los ambientes donde debe funcionar. Los componentes manejan adecuadamente recursos compartidos del sistema.
Obediencia (Compliance) Fiabilidad Madurez Tolerancia a fallas Capacidad restablecimiento recuperacin Eficiencia Tiempo comportamiento de o
de
Recursos utilizados
Mantenibilidad
Habilidad de cambio, estabilidad, prueba
Portabilidad
Adaptabilidad Capacidad Instalacin Co-existencia de
Tabla 57: Subconjunto del rbol de Utilidad Iinicial Propuesto por el Mtodo MECABIT A continuacin tambin se presenta una tabla de preguntas sobre los elementos de revisin del diseo identificados en el punto 8 de la fase 3, del mtodo MECABIT.
Caracterstica Funcionalidad Sub-caracterstica Precisin Interoperabilidad Preguntas de anlisis Puede la comunicacin entre los componentes introducir imprecisiones en los servicios ofrecidos por los componentes? Dnde se encuentran los componentes que permiten al sistema interactuar con otros sistemas?
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD 191 ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA - ECBTI CURSO DE EVALUACIN DE SOFTWARE - CDIGO 301569__________________________________________ Fiabilidad Madurez Tolerancia a fallas Eficiencia Mantenibilidad Tiempo comportamiento de Existen decisiones para minimizar el manejo incorrecto de datos en la comunicacin entre componentes? Cmo se detecta el funcionamiento incorrecto de un componente? Cmo es la relacin entre el nmero de componentes de las diferentes partes de la arquitectura? Cmo se verifica el funcionamiento correcto de un componente? Cmo se verifica el estado de una comunicacin entre componentes? Cmo 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?
Habilidad de cambio, estabilidad, prueba
Portabilidad
Capacidad Instalacin Co-existencia
de
Tabla 58: Algunas Preguntas para Analizar los Elementos de Diseo Identificados
CAPITULO 3
APLICACIONES DE EVALUACIN DEL SOFTWARE
INTRODUCCIN La industria de software cada vez esta ms consolidada y ofrece un sinnmero de productos que pretenden satisfacer las necesidades en diversos campos, y por eso es necesario que se tome en consideracin las diversas metodologas de evaluacin que estn surgiendo, ya que cada una de ella pretende evaluar productos software especficos. Actualmente el campo de la evaluacin de software ha adquirido mayor madurez y debe responder a la medicin de calidad de cada uno de los productos y del proceso de construccin, es por eso que en este captulo se tratan dos aplicaciones la primera esta relacionada conla evaluacin del proceso y es la aplicacin de la evaluacin a los diseos 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 educacin presencial. A continuacin se describir algunos de los metodos para realizar la evaluacin UML y los modelos ms reconocidos para la evaluacin de los productos software educativos multimedia.
9.1 LECCIN 1: METODOLOGA PARA LA EVALUACIN DE LA CALIDAD EN LOS MODELOS UML El campo de la calidad de las especificaciones y ms 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 todava de suficiente madurez. Por eso, se ha elaborado en esta leccin un seguimiento a una de las metodologas de evaluacin de la calidad en los modelos UML, enmarcada dentro del proyecto denominado EVVE Entorno para la Verificacin y Validacin de Especificaciones software. A partir de los principales estndares, normas y metodologas existentes en la actualidad relacionados con la evaluacin del software, se ha elaborado l a m e t o d o l o g a E V V E , analizando las caractersticas clave de cada uno de ellos y seleccionando, adaptando e integrando los aspectos ms relevantes. Las principales caractersticas de la metodologIa EVVE, se pueden resumir en los siguientes principios bsicos: Est formada por un conjunto estructurado de procesos, Est orientada a la relacin con el cliente y a la externalizacin de la evaluacin de calidad, Est pensada para ser una metodologIa fcilmente adaptable, y Est soportada por un conjunto de tcnicas y herramientas. La metodologa EVVE proporciona un marco de trabajo donde se identifica claramente el qu, cundo, y el quin, 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 evaluacin. Adems, est orientada a la relacin con el cliente de manera que el cliente se encuentra involucrado en la toma de decisiones. La metodologa contempla el modo de trabajo externalizado, de manera que para realizar la evaluacin no sea necesario encontrarse en las instalaciones del cliente, sino que se pueda planificar, disear y realizar la evaluacin externamente, ponindose en contacto con el cliente en los momentos puntuales en los que sea necesario. La metodologa de evaluacin EVVE, puede ser adaptada a las distintas necesidades del cliente, existiendo unos catlogos de tcnicas de evaluacin que determinan el nivel y profundidad con el que se desea realizar la evaluacin, las mtricas de calidad que se obtendrn y las herramientas de evaluacin que se utilizarn. La metodologa EVVE define un marco de trabajo que permite determinar los procesos para llevar a cabo la evaluacin de los modelos UML del software. La metodologa, en un principio estaba pensada para trabajar con diagramas de casos de uso, diagramas de clases, y diagramas de transicin de estados. La
metodologa de evaluacin EVVE se puede aplicar a cualquier modelo de anlisis y diseo, siempre que est especificado bajo la notacin UML. Adems 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 metodologa de evaluacin. 9.1.1 Personas, Grupos y Roles A continuacin se detallan los roles y grupos identificados a lo largo del proceso de evaluacin, 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 evaluacin segn la metodologa EVVE, as como la relacin que existe entre ellos:
Figura 37: Roles y relaciones en el proceso de evaluacin. Tal y como se aprecia en la figura, la comunicacin entre las empresas (cliente y evaluadora) es realizada a travs del patrocinador y del evaluador jefe. stos a su vez sern los que se comuniquen directamente con sus equipos internos. A continuacin se muestra en una tabla los roles y grupos involucrados en la metodologa EVVE.
Roles y Grupos Empresa cliente Patrocinador evaluacin de la Descripcin Representa a la organizacin que ha expresado su intencin y/o necesidad de contratar los servicios de evaluacin de la calidad de los modelos UML. El patrocinador de la evaluacin es el representante de la empresa cliente que se pone en contacto con la empresa evaluadora para expresar la necesidad de evaluacin de la calidad de sus modelos UML. En algunos
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD 196 ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA - ECBTI CURSO DE EVALUACIN DE SOFTWARE - CDIGO 301569__________________________________________ casos, el patrocinador de la evaluacin podr disponer de un equipo de trabajo interno formado por personal propio de la empresa. Sirve de apoyo al patrocinador de la evaluacin. 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 organizacin que ha sido contratada para llevar a cabo el proceso de evaluacin. 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 evaluacin. Es el representante de la empresa evaluadora y lder del equipo de evaluacin, cuyo objetivo es asegurar el correcto desarrollo del proceso de evaluacin. Este rol debe ser ocupado por un profesional con conocimientos en el anlisis y diseo con UML y con experiencia en la prctica de las principales normas y estndares sobre evaluacin del producto y procesos software. Est encargado de realizar las actividades y tareas propias del proceso de evaluacin. Este rol deber ser ocupado por una persona con conocimientos de modelado UML y de la metodologa de evaluacin. Las principales responsabilidades son, realizar las actividades de evaluacin asignadas por el evaluador jefe y recoger informacin del propio proceso de evaluacin. Representa el equipo de la empresa evaluadora, formado por el evaluador jefe y un conjunto de uno o varios evaluadores de calidad (segn los requisitos del proyecto). Su principal objetivo es cumplir con los requisitos de evaluacin acordados con el patrocinador dentro de los tiempos planificados.
Equipo de la empresa cliente
Empresa evaluadora
Evaluador jefe
Evaluador
Equipo de evaluacin
T a b l a 5 9 : T a b l a d e Personas, Grupos y Roles 9.1.2 Catlogo de elementos Los elementos pueden ser de entrada y/o salida para las actividades del proceso de evaluacin, siendo algunos de ellos entregables finales del proyecto de evaluacin. En la siguiente tabla se detallan todos los elementos (documentos, informes, catlogos, artefactos, etc.) que se identifican a lo largo de las actividades de evaluacin.
Elemento Informacin de contacto Detalle Documento donde la empresa evaluadora recoge los datos de contacto de la empresa cliente. Como mnimo debe presentar la siguiente informacin: Nombre de la empresa, la direccin, el telfono/Fax, Pgina Web, Persona de contacto, Email de contacto. Este documento representa el primer entregable del
Contrato de evaluacin
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD 197 ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA - ECBTI CURSO DE EVALUACIN DE SOFTWARE - CDIGO 301569__________________________________________ proyecto de evaluacin y ser generado como resultado de la pla n if ica cin . En l se recogen las condiciones bajo las que se realizar el proyecto de evaluacin. Est dividido en dos partes: 1. Propuesta tcnica de evaluacin: contiene aspectos tcnicos del contrato de evaluacin tales como el objetivo de la evaluacin, el plan de trabajo, el equipo de trabajo, el calendario y el esfuerzo necesario. 2. Propuesta econmica de evaluacin: contiene aspectos econmicos del contrato de evaluacin tales como el precio, el modo de facturacin, las clusulas, las condiciones generales, etc. Es un documento propiedad de la empresa evaluadora y contiene el conjunto de caractersticas, subcaractersticas y atributos de calidad que se pueden evaluar para cada artefacto software. Las caractersticas y subcaractersticas de calidad se encuentran detalladas en la norma ISO 25010. Es un documento que solo contiene el conjunto de caractersticas, subcaractersticas y atributos de calidad que la empresa cliente ha seleccionado para el proyecto de evaluacin. Este documento es pblico y est integrado dentro de la especificacin de la evaluacin que representa el tercer entregable del proceso de evaluacin. Es un documento propiedad de la empresa evaluadora y que permite identificar las herramientas necesarias y su modo de utilizacin, en funcin de las tcnicas de evaluacin que se vayan a utilizar para evaluar los modelos UML. Este documento pblico para ambas partes, y representa el segundo entregable del proyecto de evaluacin. Una primera versin se desarrolla previamente al inicio del proyecto de evaluacin, incluida en la propuesta tcnica del contrato de evaluacin. Esta primera versin es refinada por ambas partes tras la aceptacin del contrato, generndose as la versin definitiva del plan de evaluacin, que guiar todos los procesos y actividades realizados durante el proyecto. Este documento es generado como resultado de la planificacin del proceso de evaluacin y est sujeta a cambios durante todo el proyecto de evaluacin. Entendiendo por artefactos los modelos UML que la empresa cliente quiere validar, y toda la documentacin 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 estn 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 tcnicas y herramientas que se van a utilizar en el proceso de evaluacin. Este documento representa el tercer entregable del proyecto de evaluacin y como tal es pblico para ambas empresas. La especificacin de la evaluacin ser generada como resultado de la especificacin del
Modelo de calidad genrico
Modelo de calidad especfico
Catlogo de herramientas de evaluacin
Plan de evaluacin
Conjunto de artefactos a evaluar
Especificacin de la evaluacin
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD 198 ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA - ECBTI CURSO DE EVALUACIN DE SOFTWARE - CDIGO 301569__________________________________________ proceso de evaluacin donde se recoje el conjunto de artefactos a analizar, el modelo de calidad especfico que se va a analizar, qu tcnicas se van a utilizar, qu mtricas se esperan obtener, qu herramientas se van a manejar, entre otros. En definitiva un conjunto de caractersticas a evaluar por cada uno de los modelos UML, las tcnicas y herramientas que se utilizarn y el listado de mtricas e indicadores que se esperan obtener. Esta especificacin posteriormente se incluye dentro del informe final de evaluacin, 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 evaluacin y como tal es pblico para ambas empresas. El informe de evaluacin se genera como resultado de la fase de conclusin y estar formado por un documento con todos los resultados obtenidos mediante las tcnicas de evaluacin, las conclusiones obtenidas del anlisis de dichos resultados y un conjunto de recomendaciones y acciones futuras para la mejora de los modelos UML, adems de la especificacin de la evaluacin. Una caracterstica importante del informe es la retroalimentacin que se produce posteriormente a la presentacin de los resultados y en cuyo caso la empresa cliente reporta a la empresa evaluadora mediante el documento peticin de modificacin. Este artefacto representa el quinto entregable del proceso de evaluacin y como tal es pblico para ambas empresas. Este documento se genera como resultado de la fase de conclusin 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 evaluacin. La empresa evaluadora recibir el documento que evaluar, revisar y actualizar el informe de evaluacin 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 peticin no es ms que un refinamiento del informe de evaluacin as como la mejora del proceso de evaluacin. Adems durante la evaluacin se genera documentacin relacionada con el propio proceso. Esta informacin principalmente son informes del proceso de gestin y monitorizacin, informes de mtricas de la propia evaluacin, informes de cambios y ajustes realizados durante la evaluacin, informes de defectos y adaptaciones realizadas en la infraestructura de evaluacin, entre otros. Posteriormente esta informacin e s utilizada por los procesos Gestin de la Evaluacin y Gestin de la Infraestructura para realizar una mejora continua del proceso de evaluacin.
Informe de evaluacin
Peticin de modificacin
Informacin evaluacin
interna
de
Tabla 60: Catlogo de Elementos
9.1.3 Procesos de la metodologa de evaluacin La metodologa de evaluacin EVVE se encuentra compuesta por tres procesos principales: Proceso de gestin de la evaluacin, Proceso de evaluacin y Proceso de gestin de la infraestructura. 9.1.3.1 Proceso de evaluacin: Este proceso representa el esqueleto de la metodologa de evaluacin ya que contiene las fases de planificacin, especificacin, ejecucin y conclusin del proyecto de evaluacin. El proceso de evaluacin se descompone en cuatro fases que son mostradas en la siguiente tabla:
Fase Fase 1: Planificacin Descripcin El objetivo de esta fase es la elaboracin del contrato y la obtencin de un plan de evaluacin de los modelos UML. Esta fase est formada por cuatro actividades: Contratacin, Arranque del proyecto, Planificacin detallada y Consolidacin del plan. El objetivo de esta fase es definir el alcance de la evaluacin, determinando el conjunto de caractersticas que se van a evaluar para cada uno de los modelos UML (artefactos), las tcnicas y herramientas que se van a utilizar para realizar la evaluacin, los niveles de evaluacin (bajo, medio o alto) que se van a aplicar a cada artefacto y el listado de indicadores y mtricas que se esperan obtener. Esta fase est formada por cuatro actividades: Obtencin y anlisis de artefactos a evaluar, Seleccin del modelo de calidad y las tcnicas, Planificacin interna de la evaluacin, Verificacin de la especificacin. El objetivo de la fase de ejecucin es la aplicacin de las de las tcnicas de evaluacin y el lanzamiento herramientas (utilizando como entrada los artefactos a evaluar) para obtener los resultados iniciales (mtricas de ms 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 explotacin. Esta fase est formada por tres actividades: Aplicacin de tcnicas de evaluacin, Anlisis de la ejecucin, Unificacin de resultados. El objetivo de la fase de conclusin es la elaboracin del informe de evaluacin y la presentacin de los resultados tanto al patrocinador como al resto de personas involucradas dentro de la empresa cliente. Esta fase est formada por tres actividades: Elaboracin del informe de evaluacin, Presentacin de resultados, Correccin del informe y finalizacin de la evaluacin.
Fase 2: Especificacin
Fase 3: Ejecucin
Fase 4: Conclusin
Tabla 61: Fases del Proceso de Evaluacin
9.1.3.2 Proceso de gestin de la evaluacin: Es el proceso de soporte al proceso de evaluacin, que permite controlar, evaluar y mejorar el propio proceso de evaluacin. 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: Monitorizacin, Documentacin, Ajuste y Evolucin. 9.1.3.3 Proceso de gestin de la infraestructura: Es el proceso de soporte al proceso de evaluacin, que permite gestionar todo lo relacionado con la infraestructura necesaria para llevar a cabo el proceso de evaluacin (tcnicas y herramientas de evaluacin). 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: Especificacin de la infraestructura, Mantenimiento de la infraestructura, Adaptacin y transferencia de la infraestructura. 9.2 LECCIN 2: IMPLEMENTACIN DE LA METODOLOGA CON SPEM Y EPFC SPEM 2.0 (Software & System Process Engineering Metamodel) es un metamodelo de OMG considerado como el estndar de facto en la industria para la representacin de modelos de procesos de ingeniera del software e ingeniera 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 mtodos y procesos. De modo que con EPFC se pueden crear implementaciones en formato SPEM 2 de cualquier mtodo, proceso o metodologa de ingeniera del software. La idea central de SPEM 2 para representar procesos est basada en tres elementos bsicos: rol, producto de trabajo y tarea. Las tareas representan el esfuerzo a hacer. Los roles representan quin 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 implementacin prctica de la metodologa EVVE, frente a otras alternativas son las que se describen a continuacin:
El formato en el que se maneja la informacin en las metodologas suelen ser documentos de texto natural. La creacin, revisin, reutilizacin, adaptacin y generacin de documentacin para las metodologas suele ser un proceso puramente manual. EPFC permite crear metodologas y procesos con un rico contenido (texto con formato, imgenes, elementos multimedia, etc.). EPFC proporciona una estructura de gestin comn para todo el contenido metodolgico de una organizacin. EPFC proporciona un entendimiento claro y visual de cmo se relacionan las diferentes tareas de una metodologa. EPFC permite seleccionar, combinar, adaptar y ensamblar de forma rpida procesos a partir del contenido de mtodo creado. EPFC permite publicar la documentacin metodologas modelados en formato para la web. de los procesos y
EPFC reduce el coste de reutilizacin de contenidos de mtodo en una organizacin.
9.2.2 Diagrama de actividad generado por EPFC A continuacin, se presenta el flujo de trabajo generado por EPFC para las tareas que se realizan en la actividad Obtencin y Anlisis de Artefactos a Evaluar, actividad que pertenece a la fase 2 (Especificacin) del proceso de evaluacin 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. Adems para cada una de las tareas se muestra en el margen superior izquierdo la abreviatura del rol implicado en su realizacin. EPFC permite la generacin automtica de este tipo de diagramas a partir de la informacin de la metodologa introducida en el sistema. Adems, desde este tipo de diagramas, EPFC facilita la navegacin directa a cada uno de los componentes de la metodologa (roles, tareas, productos de trabajo) identificando la trazabilidad bidireccional entre todos estos elementos.
Figura 38: Diagrama de actividad generado por EPFC para la actividad Obtencin y Anlisis de Artefactos a Evaluar de la fase 2 (Especificacin), del proceso de evaluacin. 9.3 LECCIN 3: EVALUACIN DE SOFTWARE EDUCATIVO MULTIMEDIA
Una de las aplicaciones ms estudiadas en la actualidad es la Evaluacin del Software Educativo Multimedia. Las caractersticas que debe cumplir un buen software multimedia formativo atienden a diversos aspectos funcionales, tcnicos y pedaggicos, que se enuncian a continuacin en la siguiente tabla:
Caracterstica Facilidad de uso e instalacin Descripcin Hace referencia a que los programas puedan ser realmente utilizados por la mayora de las personas, y para ello se hace necesario que sean agradables, fciles 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 configuracin. En cada momento el usuario debe conocer el lugar del programa donde se encuentra y tener la posibilidad de moverse segn sus preferencias: retroceder, avanzar, y un sistema de ayuda online solucione las dudas que puedan surgir. Adems la instalacin del programa deber ser sencilla, rpida y transparente. Tambin se debe tener en cuenta la existencia
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD 203 ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA - ECBTI CURSO DE EVALUACIN DE SOFTWARE - CDIGO 301569__________________________________________ de una utilidad para desintalar para cuando se quiera quitar el programa. Hace referencia a la funcionalidad, es decir, que sean fcilmente integrables con otros medios didcticos en los diferentes contextos formativos, pudindose adaptar a diversos entornos, estrategias didcticas, y usuarios. Para lograr esta versatilidad debe tener unas caractersticas que permitan su adaptacin a los distintos contextos. Por ejemplo que sean programables (que permitan la modificacin de parmetros como grado de dificultad, tiempo para las respuestas, nmero de usuarios simultneos, idioma), que sean abiertos (permitiendo la modificacin de los contenidos de las bases de datos), que incluyan un sistema de evaluacin 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 realizacin 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 ms deben cuidarse son: el diseo general claro y atractivo de las pantallas (sin exceso de texto y que resalte los hechos notables), la calidad tcnica y esttica en sus elementos (ttulos, mens, ventanas, iconos, botones, espacios de textoimagen, formularios, barras de navegacin, barras de estado, elementos hipertextuales, fondo), elementos multimedia (grficos, fotografas, animaciones, vdeos, voz, msica), estilo y lenguaje, tipografa, color, composicin, entre otros, la adecuada integracin de medios. Adems de las consideraciones pedaggicas sobre la seleccin y estructuracin de los contenidos segn las caractersticas de los usuarios, se debe tener en cuenta: La informacin que se presenta es correcta y actual, los textos no tienen fallas, no hay discriminaciones, la presentacin y documentacin. Los sistemas de navegacin 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 navegacin, Sistema de navegacin, la velocidad entre el usuario y el programa es adecuada, el uso del teclado, el anlisis de respuestas, La gestin de preguntas, respuestas y acciones, la ejecucin del programa. Los programas deben presentar entornos originales, bien diferenciados de otros materiales didcticos, y que utilicen las crecientes potencialidades del computador y de las tecnologas multimedia e hipertexto en general, donde el computador resulte potenciador del proceso de aprendizaje, favorezca la asociacin de ideas y la creatividad, permita la prctica de nuevas tcnicas, la reduccin del tiempo y del esfuerzo necesarios para aprender y facilite aprendizajes ms completos y significativos. Para motivar al estudiante, las actividades de los programas deben despertar y mantener la curiosidad y el inters de los usuarios hacia la temtica de su contenido, sin provocar
Versatilidad (adaptacin diversos contextos)
Calidad audiovisual
del
entorno
La calidad en los contenidos (bases de datos)
Navegacin e interaccin
Originalidad y uso tecnologa avanzada
de
Capacidad de motivacin
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD 204 ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA - ECBTI CURSO DE EVALUACIN DE SOFTWARE - CDIGO 301569__________________________________________ ansiedad y evitando que los elementos ldicos interfieren negativamente en los aprendizajes. Tambin 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 tcnicas. Esta adecuacin se manifestar en tres mbitos principales: Los contenidos deben ser significativos para los estudiantes y estar relacionados con situaciones y problemas de su inters, actividades de tipo de interaccin, duracin, elementos motivacionales, mensajes de correccin de errores y de ayuda, niveles de dificultad, itinerarios, progresin y profundidad de los contenidos segn los aprendizajes realizados, Y el entorno de comunicacin. Los programas multimedia utilizan potentes recursos didcticos para facilitar los aprendizajes de sus usuarios. Entre estos recursos se pueden destacar: Proponer diversos tipos de actividades que permitan diversas formas de utilizacin y de acercamiento al conocimiento, utilizar organizadores previos al introducir los temas, sntesis, resmenes y esquemas, emplear diversos cdigos comunicativos, incluir preguntas para orientar la relacin de los nuevos conocimientos con los conocimientos anteriores de los estudiantes, tutorizacin 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 autnomo de los usuarios, proporcionando herramientas cognitivas para que los estudiantes hagan el mximo 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. Adems estimularn el desarrollo de habilidades metacognitivas y estrategias de aprendizaje en los usuarios, que les permitirn planificar, regular y evaluar su propia actividad de aprendizaje, provocando la reflexin sobre su conocimiento y sobre los mtodos 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 pedaggicas actuales, para que su uso en las aulas y dems entornos educativos provoque un cambio metodolgico en este sentido. Por lo tanto los programas evitarn la simple memorizacin y presentarn entornos heursticos centrados en los estudiantes que tengan en cuenta las teoras constructivistas y los principios del aprendizaje significativo donde adems de comprender los contenidos puedan investigar y buscar nuevas relaciones. Los programas debern tener una informacin acerca de sus caractersticas, forma de uso y posibilidades didcticas. Esta documentacin debe tener una presentacin 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 caractersticas bsicas del programa), El
Adecuacin a los usuarios y a su ritmo de trabajo
Potencialidad de los recursos didcticos
Fomento de la iniciativa y el autoaprendizaje
Enfoque pedaggico actual
La documentacin
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD 205 ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA - ECBTI CURSO DE EVALUACIN DE SOFTWARE - CDIGO 301569__________________________________________ manual del usuario (Presenta el programa, informa sobre su instalacin y explica sus objetivos, contenidos, destinatarios, modelo de aprendizaje que propone, sus opciones y funcionalidades), la gua didctica (con sugerencias didcticas y ejemplos de utilizacin que propone estrategias de uso y indicaciones para su integracin 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 desarrollarn las capacidades y las estructuras mentales de los estudiantes y sus formas de representacin del conocimiento (categoras, 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, expresin, crear, experimentar, explorar, reflexin metacognitivareflexin sobre su conocimiento y los mtodos que utilizan al pensar y aprender).
Esfuerzo cognitivo
Tabla 62: Caractersticas de los Productos de Software Educativo Multimedia 9.4 LECCIN 4: MODELOS DE EVALUACIN DE SOFTWARE EDUCATIVO MULTIMEDIA Existe una diversidad de herramientas y modelos para la evaluacin de productos de software multimea educativos, dentro de ellos se han elegido algunos que son los ms representativos y de los cuales se describir la metodologa de aplicacin. Cada modelo tiene unas caractersticas especficas que diferencian y a la vez complementan a los otros modelos. A continuacin se har una descripcin de los modelos seleccionados, las caractersticas y componentes que deben ser evaluados. 9.4.1 Modelo de evaluacin de materiales educativos computarizados de Galvis Uno de los modelos ms conocidos para la evaluacin 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 evaluacin como actividad necesaria para la elaboracin de informacin requerida en la toma de decisiones, siendo aplicable a cualquier sistema. Para la evaluacin sistemtica de los MEC, se establecen criterios relevantes y consistentes, Adems de la creacin de instrumentos de evaluacin vlidos y confiables segn las fuentes de informacin apropiadas al respecto. Los MEC se desarrollan para satisfacer necesidades educativas que no pueden ser abordadas por otros medios de enseanza, y por consiguiente, debe ser de calidad y viables de utilizar por parte de los usuarios a quienes va dirigido.
La evaluacin sistemtica de los MEC comprende evaluar los aspectos de Calidad educativa, Calidad computacional y Probabilidad de uso del recurso informtico. A continuacin se presentan las tablas donde se muestra las partes en que se descompone cada aspecto mencionado anteriormente.
ASPECTOS Generales Enseanza VARIABLES Funcin educativa del tipo de MEC Funcin administrativa Objetivos del material Contenido Estrategias de Instruccin Aprendizaje Opinin y actitud del estudiante. Realimentacin de su desempeo CRITERIOS Aborda la necesidad educativa Suministra informacin 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 Tcnicos VARIABLES Funciones segn el usuario Caractersticas de: interfaz, programa, programacin. Estructura de la informacin Recursos computacionales INDICADORES Fcil 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 mximo
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 fciles de usar El personal tcnico de orientacin al usuario es localizable. Estos son accesibles a los aprendices del programa.
Tabla 65: Elementos considerados en la viabilidad del recurso informtico En cuanto a los tipos de evaluaciones de los recursos educativos computarizados, este autor propone la Valoracin comprensiva del MEC por expertos y la Prueba con estudiantes. En la siguiente tabla se muestra las variables, indicadores y criterios de valoracin considerados en esta prueba.
VARIABLES Relevancia y pertinencia INDICADORES Contenido, objetivos. Tipo de software educativo. CRITERIOS PARA VALORAR 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 BSICAS, TECNOLOGA E INGENIERA - ECBTI CURSO DE EVALUACIN DE SOFTWARE - CDIGO 301569__________________________________________ Viabilidad Requerimientos computacionales. Requerimientos fsicos.Costos Participacin que exige del usuario. Funciones educativas que asume el MEC. El software educativo es viable de utilizar por los usuarios a quien se dirige considerando sus recursos disponibles. Los costos de adquisicin y mantenimiento permiten la accesibilidad del MEC por los aprendices. El MEC emplea al mximo la capacidad de interaccin que suministra el computador. El tipo o combinaciones de MEC requeridos segn la necesidad educativa son un buen prototipo de estos.
Interactividad Calidad como tipo de aplicacin
Tabla 66: Elementos Considerados en la Valoracin Comprensiva del MEC La evaluacin por expertos del MEC, se refiere a la revisin y crtica por especialistas en contenido, metodologa e informtica, de grupos distintos a sus desarrolladores a fin de que exista objetividad en las apreciaciones. La valoracin de software educativo por experto en contenido y en metodologa se muestra en las siguientes tablas. Estas se refieren a los aspectos generales relativos a: objetivos que persigue, contenidos, motivacin, metodologa, interfaz y otros. Cada tem puede ser evaluado con cinco opciones de respuesta (excelente, bueno, regular, malo, no aplica). Adems en el instrumento se solicita la anotacin de los defectos encontrados en el MEC, su ubicacin y posible solucin, junto con las fortalezas, debilidades, el uso potencial y las sugerencias para lograr su aplicacin.
VARIABLES Objetivos Contenido Desarrollo del contenido Herramientas Retroinformacin INDICADORES El nivel de complejidad es adecuado para el uso de software Es coherente, suficiente y actualizado en relacin a los objetivos El estudiante siempre esta informado sobre su ubicacin dentro del contenido. Estas son: adecuadas, sencillas de usar y facilitan la exploracin. Su orientacin es suficiente y adecuada a la actuacin del aprendiz.
Tabla 67: Algunos elementos de la valoracin por experto en contenido del MEC
VARIABLES Objetivos Motivacin Metodologa Interfaz de salida INDICADORES Definidos claramente. Se mantiene el inters por el logro de los objetivos. Se sustenta en una didctica adecuada al contenido a ensear. Las pantallas no se encuentran sobrecargadas de informacin. El vocabulario o terminologa es apropiada para el nivel cultural del usuario.
Tabla 68: Elementos considerados en la valoracin por experto en metodologa 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 poblacin a la que se dirige el software) y de campo (se aplica a toda la poblacin). Adicionalmente, se propone la encuesta final del MEC para
recabar informacin sobre sus aspectos didcticos, lo que permitir hacer los ajustes y recomendaciones necesarias para su uso en el proceso de enseanzaaprendizaje. El aporte de Galvis al modelo de evaluacin de software educativo lo constituye el tratamiento sistmico de la valoracin de los materiales educativos computarizados, por cuanto establece diversos tipos de pruebas (juicio de expertos en contenido, metodologa e informtica; pruebas piloto y de campo, encuestas a los usuarios) son realizadas por diferentes fuentes de informacin (informantes). Adems especifica las variables, indicadores y criterios de evaluacin que responden a la calidad educativa y computacional del recurso informtico. En los instrumentos de evaluacin resalta la consideracin de los problemas del material, su localizacin y posible solucin, junto con sus aspectos positivos, negativos y sugerencias de uso en el proceso de enseanza-aprendizaje real. 9.4.2 Lista de control para la evaluacin de software educativo de Bostock Otro de los autores que propone una lista de Control para la Evaluacin de Software Educativo es Bostock, la cual ha sido reestructurada y actualizada. Las siguientes tablas presentan las variables, caractersticas ms importantes y los indicadores de los aspectos tcnicos y pedaggicos. En referencia a los aspectos tcnicos ms importantes se muestran las siguientes categoras: Proteccin del programa, Calidad y disposicin de las pantallas e Interactividad. Al evaluar el software se debe considerar los casos en que el formato del programa tenga daos, 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 aplicacin. Los aspectos pedaggicos abarcan desde los objetivos hasta la adaptabilidad del software. Esta ltima categora define el rol del docente durante la aplicacin del software en funcin de lo que le permita realizar el programa frente a sus estudiantes. La evidencia de progreso del estudiante, muestra las formas como la aplicacin puede llevar a cabo este seguimiento, que junto a la realimentacin, establecen un posible tratamiento frente a respuestas incorrectas del aprendiz.
VARIABLES Requerimientos tcnicos CARACTERSTICAS Y/O INDICADORES Equipos necesarios y materiales de apoyo del Software: Se dispone de informacin sobre la capacidad de memoria y los perifricos requeridos? Hay un manual sobre la instalacin y la puesta en marcha del programa? Especifica las caractersticas mnimas necesarias para su correcta operacin? Asistencia tcnica: La ofrece? Te ayuda a recuperar fallas? Proteccin del programa: Posee un mecanismo de seguridad que no permite la copia no autorizada del programa? Tiene el usuario un
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD 209 ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA - ECBTI CURSO DE EVALUACIN DE SOFTWARE - CDIGO 301569__________________________________________ respaldo disponible? Reemplazan los CDs defectuosos? La informacin se limita a un nmero determinado de estaciones de trabajo? Se debe mantener el CD o el Internet conectado para poder acceder al material? Validacin: El programa fue validado por especialistas? Puede el usuario obtener una versin de prueba? Organizacin de la Pantalla: Se refiere al uso del espacio y la forma en que la informacin se despliega en la pantalla. Texto en la pantalla: La presentacin del texto le permite al usuario leerlo de forma sistemtica? Estn las palabras importantes de los prrafos enfatizadas? El fondo de la pantalla permite leer sin problemas el texto? Hay un cambio en la pgina cuando se presenta nueva informacin? El espaciado entre las palabras y las lneas es ptimo? Grficos: Se encuentran bien posicionados? Son las imgenes ambiguas? Hay acceso a una ilustracin cada vez que sea necesario? Color: Se usa el color para captar la atencin hacia puntos importantes? Hay suficiente contraste de color entre el fondo, los grficos y el texto? Hay colores especficos para ciertos tipos de mensajes? Sonido: Puede el usuario controlar el sonido? Se usa apropiadamente el sonido para captar la atencin? Calidad y disposicin de las pantallas: Hay variedad? La transicin es adecuada? Se pueden sobreponer? Es posible controlar la velocidad de transicin? Se utilizan seales para atraer la atencin hacia partes importantes? Interactividad: Definida para un software educativo como, si reacciona de una manera que sea variada y adaptable segn 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 presentacin? Controlar la cantidad de informacin? Respecto al programa, despus de elecciones del usuario: Puede mostrar diferentes mensajes? Puede seleccionar diferentes alternativas dependiendo de la dificultad? Puede proveer una retroalimentacin diferenciada adaptada? Puede tomar en cuenta las diferentes formas de trabajar? Puede ayudar al usuario? Le da pistas o acepta respuestas aproximadas?
Diseo de la Interfase
Tabla 69: Aspectos tcnicos de la evaluacin de software de Bostock

VARIABLES Estructura interna software Legibilidad del CARACTERSTICAS Y/O INDICADORES Es la divisin de los mdulos la apropiada? Estn 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 educacin del usuario? Las oraciones estn estructuradas con coherencia? Grficos: Complementan y se identifican con el texto? Son de tamao apropiado? Su complejidad esta adecuada al nivel de educacin del aprendiz? Consiste en todas las operaciones que se utilizan para lidiar con las respuestas en un lenguaje comn. Su calidad depende de la extensin y la variedad de las respuestas que es capaz de
Analizador de respuestas
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD 210 ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA - ECBTI CURSO DE EVALUACIN DE SOFTWARE - CDIGO 301569__________________________________________ interpretar. Hay varias maneras de expresar los mismos resultados numricos? Se especifica la unidad requerida? Acepta que la respuesta numrica en unidades se exprese de distintas maneras? Permite el uso de respuestas aproximadas o equivalentes semnticos? 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 informacin 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 cul sera la correcta? Puede el usuario evaluar los resultados de una sesin 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 documentacin 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?
Contenido
Retroalimentacin
Evidencia del progreso del usuario
Adaptabilidad
Tabla 70: Aspectos pedaggicos de la evaluacin de software de Bostock Esta lista de control de evaluacin de software educativo aporta una variedad de preguntas que orientan al evaluador en el proceso. Otro elemento importante lo constituye la proteccin del programa, factor que se debe considerar cuando se presentan fallas en la aplicacin. El instrumento integra explicaciones de algunas variables, aspecto que puede canalizar las dudas del evaluador y lo hace bastante concreto y prctico. Por otra parte, ofrece resultados cualitativos ya que no especifica una valoracin cuantitativa de los tems. 9.4.3 Metodologa de evaluacin de software educativo de Cataldi Otra de las autoras que propone un modelo de evaluacin es Cataldi, quien establece la importancia de la evaluacin del software educativo por el crecimiento rpido de la cantidad de stos en el mercado. Los docentes tienen la necesidad de evaluarlos para determinar su grado de adecuacin a su propio entorno, mientras que los estudiantes requieren saber cmo pueden mejorar sus aprendizajes mediante una aplicacin especfica. En general, el desarrollo de instrumentos de evaluacin y el hecho de utilizarlos con un programa en particular y un grupo de usuarios especfico no aporta resultados generalizables a todas las reas de uso, pero ofrece orientaciones en su seleccin para los docentes. Cataldi propone una metodologa de evaluacin de software educativo en tres momentos de su ciclo de vida. Una evaluacin interna realizada por el equipo de desarrolladores del programa durante la creacin de prototipos. Otra externa,
aplicada al producto final por los docentes; y la evaluacin contextualizada efectuada en un contexto parecido a aquel para el cual fue elaborado el software, que brinda informacin sobre las reacciones de los usuarios de la eficacia de la aplicacin. El software educativo integra dos aspectos fundamentales a evaluar: el tcnico y el pedaggico que conlleva a establecer la calidad tcnica y educativa. La calidad educativa de estas aplicaciones se refiere a la potenciacin de habilidades cognitivas y de adquisicin de conocimientos a partir del uso del software en particular. La siguiente tabla muestra los aspectos pedaggicos, didcticos y los tcnicos
ASPECTOS Utilidad Pedaggicos y didcticos CRITERIOS Facilidad de Uso Grado de adaptacin a otros niveles de usuarios Claridad de contenidos Nivel de actualizacin Interfase de navegacin Nivel de Motivacin Es adecuado para la comprensin del tema? Es adecuado para el aprendizaje del tema? Hay documentacin y ayudas? Son adecuados los recursos que necesita?
Tcnicos
Tabla 71: Esquema de evaluacin del producto final La autora sostien que el software educativo debe reunir algunas caractersticas de acuerdo a las necesidades de aplicacin y los objetivos educativos a lograr, y tambin debe responder a la calidad y pertinencia, as se establece en la siguiente tabla el criterio de usabilidad y varios subcriterios, valorados segn 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 adiccin. Nivel de legibilidad; grado de comprensin; uso de mens, grficos e imgenes; mensajes de errores e informacin; ayudas online; definicin de adecuacin de la interfase VALORACIN Muy bueno, bueno y malo. Muy bueno, bueno y malo.
Tabla 72: Criterios y Subcriterios para Evaluacin de la Calidad del Software Educativo A partir de la revisin de la informacin presentada en las tablas anteriores, junto al cuestionario de evaluacin del producto final, se presenta la siguiente tabla que indica las caractersticas de las variables segn los criterios de calidad previstos.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD 212 ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA - ECBTI CURSO DE EVALUACIN DE SOFTWARE - CDIGO 301569__________________________________________ CATEGORAS Tcnica DIMENSIONES Interfase ALGUNAS CARACTERSTICAS La interfase es amigable y de fcil manejo. El diseo general de la pantalla es adecuado. La secuenciacin 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 utilizacin de teclas rpidas es til. Su seleccin 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 comprensin del tema al aprendiz. Despierta su inters. Prefiere que el programa sea tutorial. Le gustara sonidos en los videos El programa le permite ver cosas que no se hubiese imaginado.
Pedaggica
Contenidos
Condiciones relativas al usuario
Tabla 73: Caractersticas de las variables segn criterios de calidad En cuanto a la evaluacin 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 metodologa extendida en los aspectos pedaggicos y otro de idntica funcionalidad pero desarrollado con una metodologa tradicional. 9.4.4 Instrumento de evaluacin de recursos multimedia de Soto y Gmez Soto y Gmez, proponen un instrumento de evaluacin de recursos multimedia para la atencin a la diversidad, denominado EVALA, que es una base de datos sobre software educativo que pretende ser un instrumento de apoyo a los docentes en la labor de evaluacin y seleccin de recursos informticos, con el propsito de favorecer la integracin de las TIC en el sistema educativo. La ficha de evaluacin del software contiene las siguientes partes: Datos del programa (datos descriptivos de la aplicacin), Aspectos curriculares (relativos al currculum, destinatarios y la descripcin educativa), Aspectos pedaggicos (motivacin, contenidos, interactividad y las capacidades que desarrolla), Aspectos tcnicos-estticos (el entorno audiovisual, navegacin y calidad de contenidos), Observaciones y valoracin global. Los aspectos pedaggicos y tcnicos-estticos son valorados en una escala cuantitativa de 1 a 5 puntos, uno es muy bajo y 5 muy alto. A continuacin se muestra la siguiente tabla, donde se presentan algunas caractersticas de este instrumento.
ASPECTOS Datos del programa VARIABLES Identificacin del programa Requerimientos CARACTERSTICA O INDICADORES Ttulo de la aplicacin. Datos del autor o empresa. Informacin sobre el procesador mnimo.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD 213 ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA - ECBTI CURSO DE EVALUACIN DE SOFTWARE - CDIGO 301569__________________________________________ tcnicos Tipo de adquisicin del software. Tipo de dificultad que aborda Destinatarios Ubicacin en el currculum Contenidos curriculares Descripcin educativa del programa Capacidad de motivacin Adecuacin a los contenidos Espacio que ocupa en disco. Configuracin de colores y rea de pantalla. La aplicacin 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, impresin, informes de evaluacin la etapa.
Curriculares
opciones
de
Pedaggicos
Interactividad
Capacidades que desarrolla Tcnico-esttico Entorno audiovisual
Navegacin
Calidad de los contenidos Observaciones Aspectos relevantes
Valoracin global
Puntuacin aspectos
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 relacin con situaciones y problemas de su inters. 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 accin del aprendiz, orientando su actividad, prestando ayuda efectiva oportunamente y ofrece refuerzos positivos. Segn los niveles cognoscitivos de Bloom: conocimientos, comprensin, anlisis, creatividad, resolucin de problemas. Diseo general claro y atractivo de las pantallas, sin exceso de texto y que resalte a simple vista los hechos notables. Calidad tcnica y esttica de: ttulos, mens, ventanas, iconos, botones, grficos, animaciones, videos, voz. Adecuada integracin de medias al servicio del aprendizaje sin redundancias. Facilidad de uso y amigabilidad del software. Mapa de navegacin bien estructurado, de acceso fcil y rpido a los distintos elementos del programa. Sistema de navegacin transparente que permita al aprendiz ejercer el control efectivo sobre el programa. Informacin presentada cientficamente 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 suinstalacin, manejo y funcionamiento. Se ilustra con nmero de estrellas.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD 214 ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA - ECBTI CURSO DE EVALUACIN DE SOFTWARE - CDIGO 301569__________________________________________ Pedaggicos y tcnicos-estticos.
Tabla 74: Algunas caractersticas de la ficha de evaluacin de software Este instrumento de evaluacin aporta una forma sencilla para la valoracin de software educativos, integrando aspectos cualitativos con cuantitativos, utiliza smbolos para la valoracin global y para identificar el tipo de dificultad que aborda. En los aspectos pedaggicos resalta el establecimiento de niveles de dificultad de acuerdo a los usuarios, adems de precisar las capacidades que desarrolla el programa. Desde el punto de vista tcnico-esttico esta integracin resulta muy favorable, permitiendo que especficamente el entorno audiovisual, presente tanto un diseo claro en las pantallas como atractivo en sus componentes. 9.5 LECCIN MULTIMEDIA 5: PLANTILLAS DE EVALUACIN DE SOFTWARE
Al seleccionar un programa para utilizarlo en una determinada situacin educativa hay que considerar dos aspectos fundamentales: sus caractersticas y su adecuacin al contexto en el que se quiere utilizar. Para conocer las caractersticas de un programa, el profesor debe leer el manual e interactuar con l con el propsito de determinar sus objetivos, los contenidos, el planteamiento didctico, el tipo de actividades que presenta, la calidad tcnica, es decir, deber realizar una evaluacin del programa. Para facilitar esta evaluacin objetiva de las caractersticas de un programa, se propone una ficha de catalogacin y evaluacin que permitir recoger los rasgos principales del programa y algunas valoraciones sobre sus aspectos tcnicos, pedaggicos y funcionales.
FICHA DE CATALOGACIN Y EVALUACIN MULTIMEDIA Ttulo del programa (+ versin, idiomas) Autores (+ e-mail) Editorial (+ ao, lugar, web) Temtica (rea, materia)
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD 215 ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA - ECBTI CURSO DE EVALUACIN DE SOFTWARE - CDIGO 301569__________________________________________ Objetivos . . . Contenidos que se tratan (hechos, conceptos, procedimientos, actitudes) . . . Destinatarios (caractersticas, etapa educativa) (subrayar uno o varios de cada apartado) TIPOLOGA: EJERCITACIN-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 PEDAGGICO: CONDUCTISTA COGNITIVISTA CONSTRUCTIVISTA -
DOCUMENTACIN: MANUAL - GUA DIDCTICA - MANUAL ON-LINE - GUA DIDCTICA ON-LINE - OTROS NINGUNA Breve descripcin . . . Requisitos tcnicos (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 instalacin (entorno amable) - Versatilidad (ajustable, modificable, niveles de dificultad, evaluacin, informes) ASPECTOS TCNICOS Y ESTTICOS - Calidad del entorno audiovisual (pantallas ) - Calidad en los contenidos (texto,audiovisual...) - Navegacin e interaccin - Originalidad y uso de tecnologa avanzada ASPECTOS PEDAGGICOS Esfuerzo cognitivo que exigen sus actividades: marcar uno o varios CONTROL PSICOMOTRIZ MEMORIZACIN /EVOCACIN COMPRENSIN / INTERPRETACIN COMPARACIN / RELACIN (orden, clases...) ANLISIS / SNTESIS CLCULO RAZONAMIENTO (deductivo, inductivo, crtico) PENSAMIENTO DIVERGENTE / IMAGINACIN RESOLUCIN DE PROBLEMAS EXPRESIN (verbal, escrita, grfica...) / CREAR EXPLORACIN / EXPERIMENTACIN REFLEXIN METACOGNITIVA
OBSERVACIONES Ventajas que comporta respecto a otros medios . Problemas e inconvenientes . A destacar... . IMPRESIN PERSONAL. me ha gustado: si no lo recomendara: NOMBRE DE LA PERSONA EVALUADORA Y FECHA: si no
Tabla 75: Ficha de Catalogacin y Evaluacin 9.5.1 Aspectos a considerar en la seleccin de producto multimedia
Para cada situacin educativa concreta puede aconsejar, la utilizacin 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 ms ventajas que la aplicacin de otros medios didcticos alternativos. Y en cuanto a la forma de utilizacin, nuevamente ser la que proporcione ms ventajas. La utilizacin de los medios debe venir condicionada por los siguientes factores: Las caractersticas del material: Hardware necesario, calidad tcnica, facilidad de uso, objetivos y contenidos, actividades, planteamiento pedaggico... La adecuacin del material a las circunstancias: Que caracterizan la situacin educativa donde se piensan aplicar: objetivos, caractersticas de los estudiantes, contexto, entre otros. El coste: Costo del material o el esfuerzo que hay que realizar para poder disponer de l. Tambin hay que considerar la posibilidad de utilizar otros medios alternativos que puedan realizar la misma funcin pero de manera ms eficiente. 9.5.2 Diseo de actividades con soporte multimedia Para disear actividades formativas con soporte multimedia hay que tener en cuenta diversos aspectos: Las caractersticas del contexto educativo: Marco general, caractersticas. Las caractersticas de los estudiantes: Edad, capacidades, conocimientos y habilidades previas, experiencias, actitudes, intereses, entorno sociocultural. Los objetivos educativos que se persiguen: Con la realizacin de la actividad y su importancia dentro del marco del programa de la materia. Los contenidos: que se tratarn. La seleccin de los materiales didcticos: Se considerarn las caractersticas de los materiales, adecuacin a la situacin educativa (estudiantes, objetivos) y el costo de los diversos materiales al alcance. La funcin que tendr el material: Segn las caractersticas del material y segn la manera en que se utilice, un mismo programa puede realizar diversas funciones: Motivacin del estudiante; Fuente de informacin y transmisin de contenidos; Entrenamiento, ejercitacin, prctica, adquisicin de habilidades de procedimiento, memorizar; Instruir (conducir aprendizajes); Introduccin y actualizacin de conocimientos previos; Ncleo central de un tema; Repaso,
refuerzo; Recuperacin; Ampliacin, perfeccionamiento; Entorno para la exploracin (libre o guiada), descubrimiento; Entorno para experimentar, Investigar (explorar el conocimiento); Evaluacin; Medio de expresin personal (escrita, oral, grfica); Medio de comunicacin; 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 informtica, en la empresa, en casa; Tiempo, escolar/laboral, extraescolar, en casa; Otras caractersticas y condicionantes. La organizacin de la actividad: Se considerar especialmente: Agrupamiento, individual, parejas, grupo pequeo, grupo grande; mbito de aplicacin, todos los estudiantes, slo algunos estudiantes (refuerzo, recuperacin, ampliacin de conocimientos), slo el profesor. La metodologa: La manera en la que se va a utilizar el programa: Papel del programa (Informacin que facilitar al estudiante, Tareas que propondr, Modo en que debern realizarse); Papel de los estudiantes (Tareas que realizarn los estudiantes; Nivel de autonoma en el uso del programa, si es libre, semidirigido, dirigido, siguiendo las instrucciones especficas del profesor; Interacciones de cada estudiante (Con el programa, Con otros compaeros: consultas, opiniones, comentarios, Con el profesor: consultas, orientaciones, ayudas, Con otros materiales fuentes de informacin); Tcnicas de aprendizaje que se utilizarn ( Repetitivas (memorizando), Elaborativas (relacionando la nueva informacin con la anterior): subrayar, resumir, esquematizar, elaborar diagramas y mapas conceptuales, Exploratorias: explorar, experimentar, Regulativas (analizando y reflexionando sobre los propios procesos cognitivos, metacognicin)); Papel del profesor (Informacin inicial a los estudiantes (objetivos, trabajo a realizar, materiales y metodologa, fuentes de informacin), Orientacin y seguimiento de los trabajos (dinamizacin, asesoramiento y orientacin); Tcnicas de enseanza que se utilizarn ( Motivacin, Ejercicios de memorizacin, Prcticas para la adquisicin de habilidades de procedimiento, Enseanza directiva, Exploracin guiada, Experimentacin guiada, Descubrimiento personal, Expresin personal, Comunicacin interpersonal, Metacognicin. Empleo de materiales complementarios. Cules?, cmo? El sistema de evaluacin que se seguir para determinar en que medida los estudiantes han logrado los aprendizajes previstos y la funcionalidad de las estrategias didcticas utilizadas.
DISEO DE ACTIVIDADES CON SOPORTE MULTIMEDIA Contexto educativo .
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD 219 ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA - ECBTI CURSO DE EVALUACIN DE SOFTWARE - CDIGO 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) FUNCIN QUE REALIZAR: ENTRENAR EXPERIMENTAR INSTRUIR INFORMAR MOTIVAR -
EXPRESARSE - COMUNICARSE - ENTRETENER - EVALUAR - PROCESAR DATOS ENTORNO DE USO:CLASE-AULA INFORMTICA-OTRAS SALAS-USO EXTRAESCOLARCASA ORGANIZACIN: TODOS LOS ESTUDIANTES-ALGUNOS-SLO PROFESOR USO INDIVIDUAL - PAREJAS - GRUPO - - - TODOS A LA VEZ - SUCESIVAMENTE El programa (informacin que facilitar, tareas que propondr) . . El estudiante (tareas, autonoma, interacciones, tcnicas de aprendizaje) .
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD 220 ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA - ECBTI CURSO DE EVALUACIN DE SOFTWARE - CDIGO 301569__________________________________________ . El profesor (informacin inicial, seguimiento, tcnicas de enseanza) . . Sistema de evaluacin .
Tabla 76: Ficha de Diseo de actividades 9.5.3 Aspectos a considerar en la evaluacin contextual La evaluacin contextual considera la forma en la que un determinado programa, independientemente de su calidad tcnica y pedaggica, ha sido utilizado en un contexto educativo concreto, valorando su eficacia y eficiencia. Como en definitiva durante la sesin de trabajo con el programa los estudiantes han realizado unas actividades cognitivas, se trata de valorar en que medida han sido las ms idneas para lograr los objetivos previstos y de que manera se poda haber organizado mejor la sesin. La evaluacin contextual tiene en cuenta los objetivos educativos que se pretendan y el grado en el que se han logrado, los contenidos tratados, el empleo de la infraestructura disponible, las caractersticas de los estudiantes y la estrategia didctica utilizada por el profesor. Los objetivos educativos y los resultados obtenidos: A partir de la consideracin de los objetivos educativos previstos y los contenidos que se han tratado se evalan los aprendizajes realizados por los estudiantes para determinar el grado en el que se han conseguido. Este estudio constituye la parte ms importante de la evaluacin contextual. Si se han conseguido los objetivos previstos queda demostrado que la utilizacin del programa ha sido correcta; en caso contrario, habr que revisar con ms detalle los dems elementos: la adecuacin del programa a los estudiantes, el aprovechamiento de la infraestructura y la metodologa que se ha empleado. Los contenidos tratados: Su grado de profundidad y extensin. 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 ms eficiente.
Los alumnos: Aqu deben considerarse las caractersticas de los estudiantes: edad, conocimientos y habilidades previas, experiencias anteriores, capacidades, estilos cognitivos e intereses, a fin de determinar el grado de adecuacin de las actividades del programa a las circunstancias de los alumnos. Tambin se considerarn aspectos como la motivacin de los estudiantes durante la sesin y su opinin sobre las actividades realizadas. La organizacin y la metodologa didctica: La metodologa didctica utilizada por el profesor constituye el principal elemento determinante del xito de la intervencin didctica, por lo tanto se considerarn: las actividades previas realizadas sobre la materia del programa, la motivacin que ha realizado el profesor antes de la sesin, la distribucin de los estudiantes, la autonoma que se les ha dado para interactuar con el programa, las sugerencias y seguimiento que ha realizado durante la sesin, las actividades posteriores, etc. Instrumentos para la evaluacin contextual: La evaluacin de la eficacia y la eficiencia de un programa debe realizarse a partir de la observacin de su utilizacin por parte de los estudiantes y de los profesores y mediante la recogida de informaciones de diverso tipo: Informes ( caractersticas de los estudiantes); Informes(aprendizajes realizados y objetivos previstos); Observacin e informacin del profesorado (utilizacin de los recursos disponibles, caractersticas del material, metodologa utilizada); Valoraciones de los estudiantes sobre su percepcin de los aprendizajes realizados, utilidad del programa y nivel de satisfaccin; Valoraciones de los profesores sobre los aprendizajes realizados por los estudiantes, utilidad del programa y nivel de satisfaccin.
FUENTES DOCUMENTALES Bibliografa 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 Muhlhauser, M. (ed.), Special Issues in Object-Oriented Programming. Workshop Reader of ECOOP96, pags. 131138. Dpunkt Verlag. BRAUDE. Ingeniera de software, una perspectiva orientada a objetos. Mxico. 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. Introduccin 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. Ingeniera del Software. Un enfoque prctico. Quinta edicin. Espaa. 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. Rodrguez Nuria, Martnez William.Planificacin y evaluacin de Proyectos Informticos. Editorial Universidad Estatal a Distancia, San Jos, Costarrica. 2006. SOMMERVILLE, Ian. Ingeniera de software. 6. Edicin. Pearson Addison Wesley. 2001 Direcciones Electronicas (webgrafa) 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

Evaluación de software y procesos de desarrollo

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Evaluación de software y procesos de desarrollo

Uploaded by

Copyright:

Available Formats

ESCUELA DE CIENCIAS BASICAS TECNOLOGIA E INGENIERIA

MDULO EVALUACIN DE SOFTWARE Cdigo del Curso: 301569

francisco.solarte@unad.edu.co solartefrancisco@gmail.com 2010

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

210 211 211 212 213 215 218

PROCESO DE DESARROLLO DE SOFTWARE

CICLOS DE VIDA DEL SOFTWARE

LECCIN 1: CONCEPTOS GENERALES SOBRE CICLOS DE VIDA

Figura 2: ciclo de vida en cascada con validacin

software pueden emerger de algunas coevolucionando.

LECCIN 1: PROCESOS DE GESTIN DEL PROYECTO

Tabla 2: Proceso de seguimiento y control del proyecto

Tabla 3: Proceso de gestin de calidad del software

LECCIN 2: PROCESOS DE PRE-DESARROLLO

Tcnicas a aplicar Tcnicas de adquisicin de conocimientos Tcnicas de modelizacin (Diagramas DFD)

Tabla 5: Proceso de asignacin del sistema 2.3 LECCIN 3: PROCESOS DE DESARROLLO

Tabla 6: Proceso de requisitos o requerimientos

Tabla 8: Proceso de Implementacin 2.4 LECCIN 4: PROCESOS DE POST-DESARROLLO

Tabla 12: Proceso de retiro

LECCIN 5: PROCESOS INTEGRALES DEL PROYECTO

Tabla 16: Proceso de desarrollo de formacin

CONCEPTOS DE CALIDAD Y CALIDAD DEL SOFTWARE

LECCIN 1: DEFINICIN DE CALIDAD

LECCIN 2: SISTEMAS DE CALIDAD EN LA EMPRESA

LECCIN 3: NORMATIVIDAD DE CALIDAD

Figura 7: Modelo de Gestin de calidad ISO 9001: 2000

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

ESTNDARES, MTRICAS DE CALIDAD Y PRUEBAS DEL SOFTWARE

ESTNDARES Y MODELOS DE CALIDAD DEL SOFTWARE

LECCIN 1: LA CALIDAD DEL SOFTWARE

Figura 15: Modelo de referencia para la arquitectura Square

MTRICAS DE CALIDAD DEL SOFTWARE

LECCIN 1: CONCEPTOS BSICOS DE MTRICAS

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

Nmero de peticiones de usuario

Nmero de archivos Nmero de interfaces externas

Tabla 25: Mtricas para el esquema de puntuacin

Confiabilidad Usabilidad Eficiencia Mantenibilidad

PRUEBAS DEL SOFTWARE

LECCIN 1: LA PRUEBA DEL SOFTWARE

Caractersticas de un software fcil de probar

Atributos de buena prueba

Prueba de condiciones Prueba de ciclos Prueba de definicin de datos

Tabla 32: Pruebas de Caja Blanca

Anlisis de los valores lmite

Pruebas segn la experiencia (error guessing) Tablas de decisin

Prueba de valores limite

Prueba basada en estados

Prueba Mtodo de Caminos Mensajes El mtodo de Overbek

Prueba bajo stress

Tabla 37: Pruebas de Sistema de Software Orientado a Objetos

LECCIN 5: PRUEBA DE SOFTWARE BASADO EN COMPONENTES.

Denominacin de captulos Denominacin de

MTODOLOGA TCNICA DE EVALUACIN DE SOFTWARE

EXACTITUD INTEROPERABILIDAD CONFORMIDAD

Puede mantener el nivel de rendimiento, bajo ciertas condiciones

MADUREZ TOLERANCIA ERRORES A

Seguridad Funcionalidad Cumplimiento Confiabilidad Madurez de

Tolerancia a Fallos Recuperacin

Atractivo Cumplimiento Usabilidad Tiempo Comportamiento de de

Cumplimiento Eficiencia Analizabilidad

Comprobabilidad Cumplimiento Mantenimiento Adaptabilidad de

Instalacin Co-existencia Sustituir Cumplimiento Portabilidad