modulo evaluacion software 2010

ESCUELA DE CIENCIAS BASICASTECNOLOGIA E INGENIERIA

MÓDULO EVALUACIÓN DE SOFTWARE

Código del Curso: 301569

Francisco Nicolás Javier Solarte Solarte

[email protected]@gmail.com

2010

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNADESCUELA DE CIENCIAS BÁSICAS, TECNOLOGÍA E INGENIERÍA - ECBTICURSO DE EVALUACIÓN DE SOFTWARE - CÓDIGO 301569__________________________________________

2

TABLA DE CONTENIDO

UNIDAD 1. PROCESO DE DESARROLLO DE SOFTWARE Pag.Capitulo 1 CICLO DE VIDA PARA PRODUCTOS SOFTWARE 17Lección 1 Conceptos Generales sobre ciclos de vida 18Lección 2 Ciclos de vida tradicionales 20Lección 3 Ciclos de vida alternativos 23Lección 4 Modelos de proceso de producción de software 24Lección 5 Ciclos de vida Ágiles 28Capitulo 2 DESARROLLO DE SOFTWARE 34Lección 1 Procesos de Gestión del Proyecto 36Lección 2 Procesos de Pre-desarrrollo 39Lección 3 Procesos de Desarrollo 41Lección 4 Procesos de Post-Desarrollo 46Lección 5 Procesos Integrales del Proyecto 49Capitulo 3 CONCEPTOS DE CALIDAD Y CALIDAD DEL SOFTWARE 52Lección 1 Definición de Calidad 54Lección 2 Sistemas de Calidad en la empresa 55Lección 3 Normatividad de Calidad 57Lección 4 Ingeniería de Software y Calidad 59Lección 5 Gestión de la Calidad del Software 60

UNIDAD 2. ESTÁNDARES, METRICAS DE CALIDAD Y PRUEBAS DELSOFTWARE

Capitulo 4 Calidad del Software 68Lección 1 La Calidad del Software 70Lección 2 Calidad del Producto Software – Norma ISO/IEC 9126 72Lección 3 Calidad del Producto software – Norma ISO/IEC 14598 75Lección 4 Calidad del Producto Software – Norma ISO/IEC 25000

(SquaRE)80

Lección 5 Modelos de Mejora de Procesos de Software 82Capitulo 5 MÉTRICAS DE CALIDAD DEL SOFTWARE 87Lección 1 Conceptos Básicos de Métricas 88Lección 2 Métricas del Software 91Lección 3 Métricas de Calidad del Software 94Lección 4 Métricas Técnicas del Software 95Lección 5 Estructura para las Métricas de Calidad del software 98Capitulo 6 PRUEBAS DEL SOFTWARE 104Lección 1 La Prueba del software 106Lección 2 Técnicas de diseño de Casos de Prueba 108Lección 3 Estrategias de Aplicación de Pruebas del Software 114Lección 4 Pruebas de Software para Objetos 122Lección 5 Pruebas de Software Basado en Componentes 127

UNIDAD 3. EVALUACIÓN DE SOFTWARECapitulo 7 METODOLOGÍA TÉCNICA PARA LA EVALUACIÓN DE

SOFTWARE136


3

Lección 1 Modelos Tradicionales para la Evaluación de la Calidaddel software

138

Lección 2 Norma de Evaluación ISO/IEC 9126 142Lección 3 Proceso de Evaluación de Software 151Lección 4 Métricas Externas Basados en ISO/IEC 9126 156Lección 5 Métricas Internas Basados en ISO/IEC 9126 159Capitulo 8 METODOLOGIAS DE EVALUACIÓN DE LA

ARQUITECTURA DEL SOFTWARE162

Lección 1 Evaluación de la Arquitectura del software 164Lección 2 Técnicas de Evaluación de la arquitectura del software 166Lección 3 Métodos de Evaluación de la arquitectura de software 172Lección 4 Métodos de Evaluación de Arquitectura de un Atributo

Específico179

Lección 5 Método de evaluación de la Arquitectura de SoftwareMECABIT

184

Capitulo 9 APLICACIONES DE LA EVALUACIÓN DE SOFTWARE 192Lección 1 Metodología para la Evaluación de la Calidad en Modelos

UML194

Lección 2 Implementación de la Metodología con SPEM y EPFC 200Lección 3 Evaluación de Software Educativo Multimedia 202Lección 4 Modelos de Evaluación de Software Educativo Multimedia 205Lección 5 Plantillas de Evaluación de Software Multimedia 214


4

LISTADO DE TABLAS

Pag.Tabla 1 Proceso de Iniciación del Proyecto 37Tabla 2 Proceso de Seguimiento y Control del Proyecto 37Tabla 3 Proceso de Gestión de Calidad del software 38Tabla 4 Proceso de Exploración de Conceptos 39Tabla 5 Proceso de asignación de Sistema 41Tabla 6 Proceso de requisitos o Requerimientos 42Tabla 7 Proceso de requisitos o Requerimientos 45Tabla 8 Proceso de Implementación 46Tabla 9 Proceso de Instalación 47Tabla 10 Proceso de Operación y Soporte 47Tabla 11 Proceso de Mantenimiento 48Tabla 12 Proceso de Retiro 48Tabla 13 Proceso de verificación y Validación 50Tabla 14 Proceso de gestión de la Configuración 50Tabla 15 Proceso de Desarrollo de la documentación 51Tabla 16 Proceso de Formación 51Tabla 17 Características de Calidad interna y externa ISO/IEC 9126 73Tabla 18 Características de Calidad en Uso ISO/IEC 9126 74Tabla 19 Origen de Errores y Defectos en un Proyecto Software 90Tabla 20 Tabla de Registro de Datos de Metricas Orientadas Hacia el

Tamaño92

Tabla 21 Tabla para Cálculo de Puntos de Funvión 92Tabla 22 Características y definición de puntos de función (a) 93Tabla 23 Características y definición de puntos de función (b) 94Tabla 24 Factores de calidad de McCall 95Tabla 25 Métricas para el esquema de puntuación 96Tabla 26 Métricas del modelo de Calidad FURPS 97Tabla 27 Características y Subcaracterísticas modelo ISO/IEC 9126 98Tabla 28 Actividades y definición de Métricas Técnicas de Software 99Tabla 29 Métrica Bang 100Tabla 30 Medidas de Compleción de pruebas 102Tabla 31 Objetivos, Principios, y Características de los Atributos de la

Prueba108

Tabla 32 Pruebas de Caja Blanca 109Tabla 33 Pruebas de Caja Negra 111Tabla 34 Lista de comprobaciones para la prueba de interfaces 115Tabla 35 Pruebas de Unidad de Software Orientado a Objetos 125Tabla 36 Pruebas de Integración de Software Orientado a Objetos 126Tabla 37 Pruebas de Sistema de Software Orientado a Objetos 126Tabla 38 Tabla de criterios a tener en cuenta al evaluar un software 153Tabla 39 Características y Subcaraterísticas ISO/IEC 9126 155Tabla 40 Métricas Externas ISO/IEC 9126 156


5

Tabla 41 Métricas Internas ISO/IEC 9126 159Tabla 42 Descripción de atributos de calidad observables vía ejecución 166Tabla 43 Descripción de atributos de calidad no observables vía

ejecución166

Tabla 44 Perfiles, Categorias, Pesos, y Métricas Asociados a atributosde Calidad

169

Tabla 45 Pasos para la Evaluación Basada en Simulación 170Tabla 46 Pasos para la Evaluación Basada en Modelos Matemáticos 171Tabla 47 Instrumentos asociados a las distintas técnicas de evaluación

de arquitecturas de software172

Tabla 48 Pasos contemplados por el método de evaluación SAAM 173Tabla 49 Pasos del método de evaluación ATAM 174Tabla 50 Pasos del método de evaluación ARID 175Tabla 51 Pasos del método de evaluación CBAM 177Tabla 52 Etapas contempladas por el método de evaluación de

arquitecturas propuesto por Bosch178

Tabla 53 Actividades del Método de Comparación de ArquitecturasBasado en el Modelo ISO/IEC 9126 Adaptado paraArquitecturas de Software de Losavio

179

Tabla 54 Comparación entre los métodos ALMA, PASA, SALUTA ySNA

183

Tabla 55 Grupos de Trabajo en el Método MECABIT 185Tabla 56 Fases Contempladas en el Método de evaluación de

Arquitecturas MECABIT186

Tabla 57 Subconjunto del Árbol de Utilidad Iinicial Propuesto por elMétodo MECABIT

189

Tabla 58 Algunas Preguntas para Analizar los Elementos de DiseñoIdentificados

189

Tabla 59 Tabla de Personas, grupos y Roles 195Tabla 60 Catálogo de Elementos 197Tabla 61 Fases del Proceso de Evaluación 199Tabla 62 Características de los Productos de Software Educativo

Multimedia203

Tabla 63 Partes de la calidad educacional del MEC 206Tabla 64 Calidad computacional del MEC y sus elementos 206Tabla 65 Elementos considerados en la viabilidad del recurso

informático206

Tabla 66 Elementos Considerados en la Valoración Comprensiva delMEC

207

Tabla 67 Algunos elementos de la valoración por experto en contenidodel MEC

207

Tabla 68 Elementos considerados en la valoración por experto enmetodología

207

Tabla 69 Aspectos técnicos de la evaluación de software de Bostock 209


6

Tabla 70 Aspectos pedagógicos de la evaluación de software deBostock

210

Tabla 71 Esquema de evaluación del producto final 211Tabla 72 Criterios y Subcriterios para Evaluación de la Calidad del

Software Educativo211

Tabla 73 Características de las variables según criterios de calidad 212Tabla 74 Algunas características de la ficha de evaluación de software 213Tabla 75 Ficha de Catalogación y Evaluación 215Tabla 76 Ficha de Diseño de actividades 218


7

LISTADO DE GRÁFICOS Y FIGURAS

Pag.Figura 1 Modelo en Cascada 20Figura 2 Ciclo de vida en cascada con validación 22Figura 3 Ciclo de vida en espiral 27Figura 4 Ciclo de vida XP 29Figura 5 Metodología SCRUM 30Figura 6 Ciclo de vida FDD 33Figura 7 Modelo de Gestión de calidad ISO 9001: 2000 58Figura 8 Esquema general de un modelo de calidad del software 70Figura 9 Ciclo de vida de la calidad 71Figura 10 Calidad en el ciclo de vida del software 72Figura 11 Modelo de calidad interna y externa del producto software 73Figura 12 Modelo de calidad del producto software para la calidad en

uso74

Figura 13 Norma ISO/IEC 14598 76Figura 14 Arquitectura de la serie de normas ISO/IEC 25000 80Figura 15 Modelo de referencia para la arquitectura Square 81Figura 16 Métricas del Proceso y Mejoras en el Proceso de Software 89Figura 17 Análisis de Problemas y causas de calidad del software 90Figura 18 Identificación de causas de errores o defectos en un

software91

Figura 19 Prueba de Caja Blanca 109Figura 20 Prueba de Caja Negra 110Figura 21 Integración Incremental Descendente 118Figura 22 Depuración de errores 122Figura 23 Norma de Evaluación ISO/IEC 9126 143Figura 24 Evaluación Interna, externa y Calidad de Uso ISO/IEC 9126 144Figura 25 Característica de Funcionalidad 145Figura 26 Característica de Confiabilidad 146Figura 27 Característica de Usabilidad 147Figura 28 Característica de Eficiencia 148Figura 29 Característica de Mantenibilidad 149Figura 30 Característica de Portabilidad 150Figura 31 Característica de Calidad de Uso 151Figura 32 Clasificación de las Técnicas de Evaluación 165Figura 33 Método de evaluación de arquitecturas ALMA 180Figura 34 Método de evaluación de arquitecturas PASA 181Figura 35 Método de evaluación de arquitecturas SALUTA 182Figura 36 Método de evaluación de arquitecturas SNA 183Figura 37 Roles y relaciones en el proceso de evaluación 195Figura 38 Diagrama de actividad generado por EPFC para la actividad

“Obtención y Análisis de Artefactos a Evaluar” de la fase 2(Especificación), del proceso de evaluación

202


8

ASPECTOS DE PROPIEDAD INTELECTUAL Y VERSIONAMIENTO

El presente módulo ha sido compilado y diseñado en el año 2010 por elIngeniero de sistemas Francisco Nicolás Javier Solarte Solarte, docente de laUNAD, quien a la fecha labora en el CEAD de Pasto, dentro de su currículoformativo cuenta con los siguientes estudios: Ingeniero de Sistemas de laUniversidad INCCA de Colombia, Especialista en Multimedia educativa, yEspecialista en Auditoria de Sistemas de la Universidad antonio Nariño y Magisteren docencia de la Universidad de La Salle. Además cuenta con experiencia enDocencia Universitaria desde 1995 en las diferentes universidades de la ciudad desan Juan de Pasto y actualmente se desempeña como docente auxiliar de laUNAD.

Esta es la primera versión actualizada del curso y en el proceso de revisiónparticipa la Escuela ECBTI con respecto a los contenidos y la VIMMEP en larevisión del CORE quienes apoyan el proceso de revisión del estilo del módulo ydan recomendaciones disciplinares, didácticos y pedagógicos para acreditar ymejorar el curso.

El módulo fue iniciado el mes de julio de 2010, y se termina en el mes denoviembre del mismo año, a petición de la directora nacional de la Cadena deFormación de Sistemas, Ingeniera Alexandra Aparicio.


9

UNIDAD 1Nombre de la Unidad PROCESO DE DESARROLLO DE SOFTWAREIntroducción Esta unidad esta dedicada principalmente a la explicación

de los modelos de cilo de vida de los sistemas, al procesode de desarrollo de software y a los conceptos de calidady calidad en el ámbito del software, estos temas sirven debase al proceso de evaluación del proceso y el productosoftware obtenido para que el ingeniero de software tengalos fundamentos y una perspectiva sufiecientes parapoder evaluar el software.

Justificación En la evaluación del software es importante recalcar queno solo se evalúa el producto, sino también, el proceso dedesarrollo de software y es de vital importancia que elingeniro de software y la empresa conozcan los modelos yla metodología basada en estándares para el desarrollode un producto tan especial como lo es el software.

IntencionalidadesFormativas

- El estudiante reconoce los ciclos de vida aplicables parael desarrollo de los difrentes productos software- El estudiante conoce uno de los estándares y cada unade las etapas de desarrollo de software- El estudiante conoce los conceptos de calidad, calidadde software y algunos de los estándares más reconocidosaplicados al producto software.

Denominación decapítulos

CAPITULO 1: CICLOS DE VIDA DEL SOFTWARE

Denominación deLecciones

Lección 1. Conceptos Generales sobre ciclos de vida


Lección 2. Ciclos de vida tradicionales


Lección 3. Ciclos de vida alternativos


Lección 4. Modelos de proceso de producción de software


Lección 5. Ciclos de vida Ágiles


CAPITULO 2: DESARROLLO DE SOFTWARE


Lección 1. Procesos de Gestión del Proyecto


Lección 2. Procesos de Pre-Desarrrollo


Lección 3. Procesos de Desarrollo


Lección 4. Procesos de Post-Desarrollo


10


Lección 5. Procesos Integrales del Proyecto


CAPITULO 3: CONCEPTOS DE CALIDAD Y CALIDADDEL SOFTWARE


Lección 1.Definición de Calidad


Lección 2. Sistemas de Calidad en la empresa


Lección 3: Normatividad de Calidad


Lección 4: Ingeniería de Software y Calidad


Lección 5. Gestión de la Calidad del Software


11

INTRODUCCIÓN

Hace algunos años, el desarrollo de aplicaciones informáticas se llevaba acabo de forma individual, generando líneas de código y probando lo realizado.Este proceso se realizaba sin necesidad de documentación alguna y como habíabaja movilidad las empresas pensaban que cuando hubiera necesidad de lapersona para realizar modificaciones él estaría allí para solucionar los problemas.A pesar de que esa forma de escribir código era un adelanto, nunca se llego apensar que posteriormente se convertiría en un problema y que en el caso desoftware que contenía errores en la base de datos este debía desecharsecompletamente y comenzar nuevamente.

Esta forma de desarrollar software es muy común en las empresas ysucede normalmente porque no se sigue un enfoque de desarrollo conocido comociclo de vida, y es el escaso tiempo dedicado a la planificación, pues normalmente,se codifica y se prueba dando buenos resultados cuando el software es pequeño.Pero para otro tipo de proyectos resulta peligroso ya que no se conoce el progresodel proyecto, ni tampoco su calidad simplemente se codifica y se prueba hastaterminar el proyecto.

Por este motivo es probable que las aplicaciones desarrolladas utilizandoestos métodos sean poco flexibles y ante posibles modificaciones se puedanincrementar los costos de los proyectos y en algunos casos se vuelvanirrealizables por la no existencia de documentación para efectuarlas. Otroproblema es que las aplicaciones resulten incompletas y no reflejen en sutotalidad los requerimientos de los clientes, que no esten completamentefuncionales o que tengan baja fiabilidad. Además pueden provocar el descontentoen los clientes pues, pueden producir retrasos en la entrega o que aparezcanerrores una vez entregados.

Por lo tanto es necesario que todo el esfuerzo de desarrollo de software seenfoque en el uso de un ciclo de vida que contemple todas sus etapas desde laconcepción hasta finalizar con el retiro del mismo cuando ya no se utiliza.

Todas las organizaciones y estudiosos de la ingeniería de software se hanocupado del estudio de estos problemas para proponer nuevos enfoques yactividades tendientes a mejorar los procesos de construcción y revisión desoftware. Así se han desarrollado modelos de referencia para la adquisición,desarrollo, explotación, soporte y mantenimiento de software.

El instituto de ingeniería de software ha desarrollado el Modelo de Madurezde la Capacidad ( Capability Maturity Model, CMM), el cual proporciona a lasorganizaciones de software una orientación sobre como hacerse con el control delproceso de desarrollo y mantenimiento de software, y como evolucionar hacia unacultura de la ingeniería de software y de gestión por excelencia.


12

Los organismos IEEE e ISO/IEC han publicado normas respectivamente,IEEE-1074, e ISO/IEC 12207-1. Actualmente, ISO/IEC ha desarrollado dentro delmarco de la evaluación de software un informe técnico alineado con el anterior,ISO/IEC TR 15504-2, y específicamente la La serie de normas ISO/IEC 14598para evaluación de software, la norma ISO/IEC 9126 que posteriormente seunificarían en la serie de normas ISO/IEC 25000 denominadas SQuaRE, queabarcará a la serie ISO/IEC 14598 e ISO/IEC 9126. Todos estos modelos establecenlos diferentes procesos implicados a la hora de desarrollar sistemas informáticos,desde que surge la idea o necesidad de desarrollar las aplicaciones hasta queestos se retiran de explotación.

Sin embargo ninguno de estos modelos impone la utilización de un ciclo devida específico o método de desarrollo concreto, sino que cada empresa deberíaseleccionar los procesos que considere necesario realizar, estableciendo suspropios ciclos de vida software.

La Ingeniería de software y específicamente el curso de Evaluación desoftware es uno de los componentes fundamentales de la estructura curricular delprograma de Ingeniería de sistemas, pues incorpora en su contenido todo loreferente a los ciclos de vida de los sistemas, el proceso de construcción desoftware, las métricas de software, las pruebas de software, los estándares decalidad, la evaluación de la arquitectura de los sistemas, y la evaluación generalde productos software de diferente tipo, con el propósito de verificar y evaluar sucorrecta realización. Este curso, se enmarca dentro del campo de formaciónprofesional y tiene como objetivo la preparación de los estudiantes y futurosprofesionales en su labor como desarrolladores de software, auditores oconsultores de productos informáticos dentro de una organización.

El módulo esta compuesto de tres unidades generales, y cada una de ellasesta integrada por capítulos y lecciones, dentro de las cuales se distingue:

Unidad 1: Proceso de Desarrollo de software dentro de esta unidad seincluye los ciclos de vida del software, los procesos de software, las metodologíasde desarrollo de software, la gestión de proyectos de software y aspectosrelacionados con estos temas.

Unidad 2: Calidad del Software, dentro de esta unidad se incluye lasmétricas de calidad, estandares de calidad de software, pruebas del software,gestión de la calidad de software.

Unidad 3: Evaluación de software, dentro de esta unidad se incluye laespecificación de las métricas ISO/IEC 9126, los métodos de evaluación y lasaplicaciones que aunque diversas, tratan de recoger las nuevas investigacionessobre estos temas tan importantes para la vida profesional del ingeniero.


13

JUSTIFICACIÓN

Uno de los intereses en la formación de los estudiantes del programa deingeniería de sistemas y en ámbito disciplinar, es su formación integral a través deldesarrollo de competencias, que le permitan interactuar en diferentes contextos,haciendo de ellos profesionales competitivos, generadores de cambio y progreso.

El curso de evaluación de software no es la excepción, ya que centra alestudiante en aspectos relacionados con los sistemas de información empresarialdonde con sus habilidades y conocimientos puede contribuir al desempeño ycumplimiento exitoso de los procedimientos de la organización. El estudiante comoprofesional estará preparado para planificar, diseñar, desarrollar y evaluarsoftware, identificando situaciones de riesgo y sugerir controles que garantice lacalidad de los productos de software.

El curso, esta dirigido a estudiantes que se encuentren en la etapa final delproceso de formación y específicamente que conozcan el campo de la Ingenieríade Software, ya que los métodos de evaluación de software están ligados alproceso de construcción o adquisición del software.

El curso permite el desarrollo de competencias cognitivas, comunicativas,contextuales y valorativas, fundamentales para la formación profesional y lainteracción en otros contextos. El logro de estas competencias exige unaplanificación responsable en su proceso de aprendizaje autónomo si se quierenobtener resultados positivos en el desarrollo del curso, ya que el trabajo es enparte individual y otra la interacción en grupos colaborativos pequeños.

La evaluación de software permite llevar a la práctica los conocimientosadquiridos en los cursos del componente de ingeniería de software que son labase del profesional en sistemas y permite integrar las otras áreas delconocimiento necesarias para realizar un proceso de evaluación bajo normasestándares.

Además una de las tareas más difíciles en la elección de software, una vezconocidos los requerimientos del sistema, es el de determinar si un cierto productode software cumple con los requerimientos. Después de la selección inicial, esnecesario conocer los estándares de calidad y hacer una revisión exhaustiva delcumplimiento de las normas, y cuales son las ventajas frente a los otros productos.


14

INTENCIONALIDADES FORMATIVAS

PROPÓSITO

Fundamentalmente, el curso pretende desarrollar las capacidades,habilidades y destrezas de los estudiantes durante el proceso de evaluación desoftware, donde deberá conocer y aplicar los conocimientos acerca de ciclos devida, estándares de calidad, las métricas de calidad y las para hacer la revisión delos diferentes tipos de productos software.

Con esto se contribuirá al mejoramiento de los procesos de calidad delsoftware en las organizaciones, a través de la aplicación de procedimientos yestándares de calidad tanto en el proceso de producción de software como en labúsqueda de soluciones apropiadas para dar solución a problemas del uso y laintegración de sistemas de información computacionales.

OBJETIVOS

- Identificar dentro de los procesos de desarrollo de software los diferentesenfoques o ciclos de vida de acuerdo a cada proyecto, conocer cada una de lasfases o etapas de cada ciclo de vida

- Reconocer los conceptos básicos y las características de la evaluación desoftware

- Conocer los tipos de pruebas, métricas y estándares de calidad para laevaluación de software y aplicar procedimientos para la evaluación de softwaretendientes a evaluar el proceso de desarrollo y los productos comerciales.

- Identificar y analizar los estándares actuales utilizados para evaluar la calidad delsoftware y cuales son los significados de los factores y requisitos que debe cumplirun software de calidad.

- Aplicar los conceptos de la evaluación de software y aplicar procedimientos parala evaluación de software tendientes a evaluar el proceso de desarrollo y losproductos 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


15

- Identificar y conocer los estándares y métricas de calidad de software- Conocer y comprender los procedimientos para la evaluación de software.

COMPETENCIAS

- El estudiante identifica, analiza, y comprende los diferentes enfoques o ciclos devida utilizados para el desarrollo de software de acuerdo al tipo de proyecto, cadauna de las fases y cómo asegurar la calidad durante cada una de las fases.

- El estudiante esta en capacidad de identificar los estándares de calidad, lasmétricas, los factores y requisitos que se deben cumplir los productos software.

- El estudiantes esta en la capacidad de realizar los procedimientos de evaluaciónde software de manera objetiva y respetando los principios de la ética profesional.

- El estudiante esta en capacidad de comprender la realidad de un entornoempresarial y elabora propuestas para el desarrollo de software y evaluar posiblessoluciones mejorando el desempeño de las mismas contribuyendo al desarrollo dela región.


16

UNIDAD 1

PROCESO DEDESARROLLO DE

SOFTWARE


17

CAPITULO 1

CICLOS DE VIDA DELSOFTWARE


18

1.1 LECCIÓN 1: CONCEPTOS GENERALES SOBRE CICLOS DE VIDA

El ciclo de vida de software es la descripción de las distintas formas dedesarrollo de un proyecto informático. Es la orientación que se sigue para que apartir de los requerimientos del cliente se obtengan sistemas que puedan serutilizados por los usuarios. Otra de las definiciones más técnicas, dice que un ciclode vida es un conjunto de fases o etapas, procesos y actividades requeridas parael desarrollo y la explotación de un producto software.

El ciclo de vida seleccionado en un proyecto, influye en el éxito del mismo,asegurando que cada actividad aporte al cumplimiento del objetivo que se hapropuesto. Dependiendo del ciclo de vida seleccionado, se puede aumentar lavelocidad de desarrollo, mejorar la calidad, el control y el seguimiento delproyecto, minimizar los costos y los riesgos, y mejorar las relaciones con losclientes.

El ciclo de vida en cascada, fue uno de los primeros modelos de ciclo devida que formalizó un conjunto de procesos de desarrollo de software. Estemodelo describe un orden secuencial en la ejecución de los procesos asociados.El modelo espiral se postuló como una alternativa al modelo de cascada. Laventaja de este modelo radica en el perfeccionamiento de las solucionesencontradas con cada ciclo de desarrollo, en términos de dar respuesta a losrequerimientos inicialmente analizados. El modelo de cascada y el modelo espiralsuponen que los requerimientos del cliente no cambian radicalmente en eltranscurso del desarrollo del sistema.

Los prototipos apoyan diferentes modelos de ciclo de vida. Un prototipotiene el objetivo de mostrar al cliente o a la gerencia del proyecto el resultado quese obtendrá de la implementación de cada uno de los requerimientos del clienteuna vez terminado el desarrollo. La solución a algunos de los problemaspresentados por las metodologías tradicionales se logra con una gran evolucióndel modelo espiral. El proceso unificado propone la elaboración de varios ciclos dedesarrollo, donde cada uno finaliza con la entrega al cliente de un productoterminado. Este se enmarca entre los conocidos modelos iterativo-incremental.

Algunos grupos de desarrollo han experimentado soluciones que basan sufundamento en la adaptabilidad de los procesos de desarrollo, esta comunidad dedesarrolladores e investigadores han nombrado su trabajo bajo lo que se conocecomo metodologías ágiles. Las metodologías ágiles, promueve la formalización deprocesos adaptables. La compilación de los principios y valores que resaltan lasmetodologías ágiles fue formalizada en el manifiesto para el desarrollo de softwareágil.

La metodología XP, una de las metodologias ágiles más difundidas quedefine pocas reglas y pocas prácticas. XP promueve la adaptabilidad de losprocesos de desarrollo basándose en los principios y prácticas que presenta.


19

Quienes trabajan usando XP deben seguir procesos disciplinados, además decombinar la disciplina con la adaptabilidad necesaria del proceso. Lasmetodologías de Cristal se basan en el principio de que tipos diferentes deproyectos requieren tipos diferentes de metodologías. La metodología escogidadebe depender de dos factores: el número de personas en el proyecto, y lasconsecuencias de los errores. Conforme al principio de las metodologías ágiles,Scrum recalca la imposibilidad de encontrar procesos definidos y repetiblescuando no existen problemas, personas, ni ambientes definidos y repetibles.

Al utilizar las metodologías tradicionales el problema es que casi nunca selogra planear bien el esfuerzo requerido para seguir la metodología. Pero si selogra definir métricas que apoyen la estimación de las actividades de desarrollo. Elno poder predecir siempre los resultados de cada proceso significa queactualmente se debe hacer frente a la necesidad de adaptación de los procesosde desarrollo que son llevados por parte de los equipos que construyen software.

Tener metodologías diferentes para aplicar de acuerdo con el proyecto quese desarrolle resulta interesante ya que estas pueden involucrar prácticas tanto demetodologías ágiles como de metodologías tradicionales. De esta manera sepuede plantear una metodología por cada proyecto, el problema se centrará endefinir cada una de las prácticas, y en el momento preciso definir parámetros parasaber cual usar.

Al elegir el modelo de ciclo de vida se debe tener en cuenta algunosfactores como el contexto, fundamentos básicos, los obstáculos y ventajas. Estoincluye realizar un estudio de las prácticas que se van a poner en ejecución dentrode un proyecto. Los modelos deben ser estructurados teniendo en cuenta lascaracterísticas propias del proyecto y pueden ser híbridos con una mezcla demodelos tradicionales y ágiles.

Un modelo de ciclo de vida exitoso en un contexto, no necesariamente lo esen otro contexto. Por ejemplo, ante el surgimiento de los Parques Tecnológicosque incluyen empresas de desarrollo de software, se debe tomar en cuenta lascaracterísticas propias del contexto de un grupo de jóvenes emprendedores sinaltos recursos para realizar inversión, con necesidad de poner en el mercado enrelativo poco tiempo un software altamente funcional de excelente calidad. Anteeste panorama se plantea la necesidad de redefinir el modelo de desarrollo con elfin de mejorar los resultados en términos de un conjunto de atributos como puedenser la calidad del software y la precisión de los planes realizados. También surgenlas preguntas de cómo evaluar el proceso de desarrollo, la identificación delconjunto de características que rodean los desarrollos, e impactan de manerasignificativa los resultados del equipo y cómo identificar el conjunto de prácticasadecuadas para incluir en un nuevo modelo de ciclo de vida de desarrollo.

A continuación se hace un repaso de los diferentes ciclos de vidaexistentes, teniendo en claro que no existe un modelo de ciclo de vida generalpara cualquier tipo de proyecto. Cada proyecto debe seleccionar para cada caso


20

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

1.2 LECCIÓN 2: CICLOS DE VIDA TRADICIONALES

1.2.1. Ciclo de vida clásico o en cascada

Este modelo fue presentado por primera vez por Royce en 1970. Serepresenta frecuentemente como un simple modelo con forma de cascada de lasetapas del software, como lo muestra la siguiente figura:

Figura 1. Modelo en Cascada

En este modelo la evolución del producto software procede a través de unasecuencia ordenada de transiciones de una fase a la siguiente según el ordenlineal. Este modelo semeja una máquina de estados finitos para la descripción dela evolución del producto software. El modelo en cascada ha sido útil para ayudara estructurar y gestionar grandes proyectos de desarrollo de software dentro delas organizaciones. Este modelo permite iteraciones durante el desarrollo, dentrode un mismo estado o de un estado a otro anterior. La mayor iteración se producecuando una vez terminado el desarrollo y cuando se ha visto el softwareproducido, se decide comenzar de nuevo y redefinir los requerimientos delusuario.


21

Sin embargo, durante el desarrollo se puede tomar decisiones que denlugar a las diferentes alternativas. Por ejemplo, dependiendo del análisis derequisitos se puede implementar el sistema desde cero, o adoptar uno yaexistente, o comprar un paquete que proporcione las funcionalidades requeridas.

El modelo en cascada ha sido transformado numerosas veces y es el másutilizado, aunque incorporando infinidad de variaciones que eliminan el caráctersimplista del mismo. Aún hoy en día se asume que para que un proyecto tengaéxito, todas las fases del modelo deben cumplirse y cualquier desarrollo endiferente orden de estados dará un producto de inferior calidad.

Entre las limitaciones que se argumentan a este modelo se pueden señalarlas siguientes: El modelo asume que los requisitos se pueden conseguir antes deiniciar la etapa de diseño, eso para los sistemas nuevos es poco realista, elmantener los requisitos requiere seleccionar el hardware, pero la terminación deun proyecto puede llevar años, y dada la velocidad de obsolescencia de latecnología, es probable que el software final utilice hardware obsoleto, en caso desistemas no desarrollados para clientes específicos, y los desarrollados porterceros, que frecuentemente salen al mercado, los requisitos son determinadospor los desarrolladores, por eso es mejor desarrollar primero una parte del sistemay posteriormente optimizarlo.

Pero el punto más álgido de este modelo es que envía al cliente el productosolamente después de que se han consumido el 90% de los recursos, estosignifica que la mayor parte de la retroalimentación del cliente sobre susnecesidades se obtiene al final.

Este ciclo de vida tiene tres factores muy positivos: El primero, es que lasetapas están organizadas de un modo lógico, una etapa no puede llevarse a cabohasta que se haya tomado las decisiones de continuar a la siguiente, es así como,el diseño espera a los requisitos, la codificación espera al diseño, el segundo esque cada etapa incluye un proceso de revisión y se necesita la aceptación delproducto antes de que la salida de la etapa pueda utilizarse, y el tercero es que elciclo es iterativo, en cuanto a que reconoce que los problemas encontrados enetapas inferiores afectan a las decisiones de las etapas superiores.

Existe una visión alternativa de este modelo que enfatiza la validación delos productos y el proceso de composición existente en la construcción desistemas software. Este proceso consiste en lo siguiente: Los requerimientosgenerales se dividen en requerimientos de hardware y software, losrequerimientos de software llevan al análisis preliminar de múltiples funciones,cada una de las cuales se expande en el diseño detallado que a su vezevoluciona en un número mayor de programas unitarios, al ensamblar el productose procede al contrario, dentro de un proceso de síntesis o composición, dondeprimero se aceptan los programas unitarios probados, estos se agrupan enmódulos que a su vez deben ser aceptados una vez probados, luego, los módulosse agrupan para certificar el grupo formado por todos ellos incluyen todas las


22

funcionalidades deseadas y finalmente, el software es integrado con el hardwarehasta formar un único sistema informático que satisface los requerimientosglobales.

El producto obtenido en cada etapa no solo determina que debe hacerse enla fase siguiente del proceso, sino que también establece los criterios paradeterminar si el producto compuesto y ensamblado satisface los objetivos de laetapa. El ciclo de vida esta estructurado de tal modo que en cada etapa se definequé debe hacerse en el próximo paso de descomposición, pero también sedocumentan los criterios para determinar si el producto compuesto que resultasatisface las intencionalidades que se tenían hacia él.

1.2.2 Ciclo de vida de refinamiento sucesivo o mejora iterativa

Las etapas que forman este ciclo de vida son las mismas que el modelo encascada y su realización sigue el mismo orden. Sin embargo, este modelorecomienda desarrollar los sistemas software a través de un refinamiento ymejora continuos desde las especificaciones de alto nivel del sistema hasta loscomponentes de código fuente. Este modelo asume que el producto generado encada etapa no se produce de manera lineal, del principio al final de la etapa, sinoal contrario, predica la generación de productos de manera iterativa mediante unproceso de refinamiento. Debido a la marcha atrás permitida en el modelo encascada, se abre un camino desde una etapa hacia otra anterior, el refinamientoiterativo puede producirse también a nivel global de todas las etapas.

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


23

1.2.3 Ciclo de vida con emisión gradual

Este modelo propone desarrollar sistemas produciendo, en primer lugar, lasfunciones esenciales de operación y posteriormente proporcionar a los usuariosmejoras y versiones más capaces del sistema a intervalos regulares. Este modelocombina el ciclo de vida clásico de software con mejoras iterativas a nivel deldesarrollo del sistema global. También proporciona una manera de distribuirperiódicamente actualizaciones del mantenimiento de software comercial.

1.2.4 Estándares militares y prácticas industriales

Las empresas industriales adoptan con frecuencia alguna variación delmodelo clásico como base de la práctica del desarrollo de software. Muchosproveedores de la administración americana organizan sus actividades deacuerdo con los modelos del ciclo de vida del estándar militar, tal como el de lanorma MIL-STD-2167 de 1987. Tales estándares subrayan no solo algunavariación de las actividades del ciclo de vida clásico, sino que también contienen lodocumentos que deben entregarse a los clientes que necesitan sistemas softwareo mecanismos complejos como sistemas software embebidos. Estos estándaresdeben ser compatibles con la garantía de calidad del software, la gestión deconfiguraciones y la verificación y validación independiente de servicios en unproyecto de desarrollo con más de un contratista. Estos modelos ponen especialénfasis en la definición de productos entregables, revisones, hitos y técnicasrequeridas en cada caso.

1.3 LECCIÓN 3: CICLOS DE VIDA ALTERNATIVOS

Existen por lo menos tres conjuntos alternativos a los modelos de evoluciónde los productos software tradicionales. Estos modelos centran su atención biensobre productos diferentes a los clásicos o sobre procesos especiales deproducción o sobre entornos de producción. Dado que estos modelos no estánaún muy extendidos, se considera fundamental su presentación aquí por laspotencialidades que presentan.

1.3.1 Ensamblaje de componentes reutilizables

El enfoque básico de la reutilización es configurar y especializarcomponentes de software ya existentes. Sin embargo, la granularidad de loscomponentes, es decir, el tamaño, complejidad y capacidad funcional, varíagrandemente a lo largo de los distintos enfoques. La mayoría de ciclos de vidabasados en ensamblaje de componentes intentan utilizar componentes similares aestructuras de datos con los algoritmos incorporados para su manipulación


24

denominados componentes de grano fino. Sin embargo, el uso de componentesde grano fino no constituye un enfoque distinto a la evolución del productosoftware tradicional. Otros enfoques intentan utilizar componentes ensamblandofuncionalmente sistemas o subsistemas completos; por ejemplo, sistemas degestión de interfaces de usuario, en este caso se trata de componentes de granogrueso. El uso o la reutilización de estos componentes aparecen como un enfoquealternativo al desarrollo de sistemas software. Hay probablemente, muchas formasde emplear componentes de software reutilizables al desarrollar software. Sinembargo, hasta ahora parece ser que la mejor forma de implementación rápida esusarlo durante el diseño arquitectónico. Los componentes reutilizables tambiénpueden usarse con propósitos de prototipado.

1.3.2 Generación de aplicaciones

Es un enfoque de desarrollo de software similar a la reutilización decomponentes de software de grano grueso, pero en este caso, parametrizados.Tales componentes están especializados en un dominio de aplicación, vía unlenguaje de especificación formalizado usado como entrada para el generador dela aplicación. Ejemplos comunes de este enfoque son las interfacesestandarizados de aplicaciones de sistemas de gestión de bases de datos queincluyen generadores de informes, gráficos, editores específicos de la aplicación einterfaz de usuario. El uso de generadores da lugar a un modelo de evolución delproducto software mediante el cual la actividad de diseño del software o es casieliminada, o reducida a un problema de diseño de bases de datos. Similarmentelos usuarios de los generadores de aplicaciones esperan habitualmenteproporcionar especificaciones de entrada y servicios de mantenimiento de laaplicación. Estas capacidades son posibles dado que los generadores puedenproducir solo sistemas software específico para un pequeño número de dominiosde aplicación similares y en especial aquellos que dependen de un sistema degestión de bases de datos.

1.4 LECCIÓN 4: MODELOS DE PROCESO DE PRODUCCIÓN DESOFTWARE

1.4.1 Modelos operativos

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


25

buscado, o bien situaciones donde los prototipos especificados se conservanoperativos pero refinados dentro de un sistema completo.

1.4.1.1Automatización de la programación y del proceso software: Laautomatización del proceso y la programación están relacionados con el desarrollode las especificaciones formales de cómo una familia de sistemas software debedesarrollarse, estas especificaciones deberían proporcionar una estimación para laorganización y descripción de las distintas cadenas de producción software, comoestán interrelacionadas, cuándo iteran, y qué herramientas software deberíanutilizarse.

El desarrollo de software utilizando técnicas de cuarta generación secaracteriza por facilitar la especificación de algunas de las funcionalidades de altonivel. La herramienta genera a continuación, el código o parte de él a partir de laespecificación. Esta especificación se hace en un lenguaje lo más próximo allenguaje natural. El concepto de desarrollo con uso de herramientas de cuartageneración se utiliza varias herramientas dentro de las cuales se encuentran loslenguajes no procedimentales para las bases de datos, generación de informes ypantallas de captura, para la generación de código y las capacidades gráficas dealto nivel combinados con hojas de cálculo.

Una vez hecha la especificación de los requerimientos, la generación decódigo es casi automática, con lo que el tiempo de desarrollo se reducedrásticamente. Con el código generado se empieza a revisar las funcionalidadesde la aplicación y se va añadiendo prestaciones de forma interactiva hastacompletar el producto.

Esta técnica permite la construcción de programas al usuario y permite larevisión y actualización personal, con lo que es muy difícil la equivocación encuanto al cumplimiento de requerimientos. En la actualidad su uso se reduce asistemas de gestión con un grado de complejidad no muy elevado.

1.4.1.2 Automatización del Software Basado en Conocimientos: Este modelointenta llevar el proceso de automatización hasta sus límites al suponer quepueden usarse las especificaciones de proceso para desarrollar directamentesistemas software y configurar entornos de desarrollo para soportar las tareas encurso.

Los sistemas expertos son un caso particular en el ciclo de vida delsoftware, 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 encualquier momento, sin necesidad de ejecutar ciclos completos. Se pueden utilizartécnicas de prototipado, pero la expansión al sistema final a partir del prototipo esmucho más directa, ya que pueden bastar con incrementar la base de reglas deinferencia o la base de conocimientos.


26

Por otra parte, la definición interna de lo que debe hacer el sistema expertono queda clara ni siquiera al final del desarrollo, porque lo que se trata demodelizar es el razonamiento de los expertos humanos. Por lo tanto no existennunca unos requisitos claros para poder validar el resultado.

Las fases de desarrollo de un sistema experto son las siguientes:Identificación del problema, estudio de factibilidad, identificación de subproblemas,identificación de conceptos y relaciones, diseño conceptual, diseño detallado,código, prueba de razonamiento, prueba del conocimiento, validación, conversión,mantenimiento y mejoras.

Muchas de estas etapas se producen en paralelo e influyen unas en otras,con lo que el diagrama de bloques que lo representa, en vez de ser secuencial esun grupo de cajas que interactúan, pero que están una al lado de la otra en eltiempo.

El enfoque común a estos tres modelos mencionados es buscar laautomatización del modelo de transformación continuo. A su vez, esto implica unentorno automatizable capaz de registrar el desarrollo formalizado de lasespecificaciones operativas, transformando y refinando sucesivamente dichasespecificaciones en un sistema implementado, asimilando los requisitos demanteniemiento al insertar las especificaciones nuevas en el desarrollo, y luegollevando el desarrollo revisado a la implementación.

1.4.2 Modelos no operativos

Estos modelos incorporan métodos de proceso dirigidos por lasespecificaciones y por los prototipos.

1.4.2.1 Modelo en espiral: El modelo en espiral representa un enfoque dirigido alanálisis de riesgos y estructuración de procesos de software. El enfoque incorporamétodos de proceso dirigidos por las especificaciones y por los prototipos. Esto selleva a cabo representando ciclos de desarrollo iterativos en forma de espiral,denotando los ciclos internos del ciclo de vida análisis y prototipado temprano, ylos externos el modelo clásico. La dimensión radial indica los costos de desarrolloacumulativos y la angular el progreso hecho en cada desarrollo en espiral.

El análisis de riesgos, que busca identificar situaciones que pueden causarel fracaso o sobrepasar el presupuesto o el plazo, aparecen durante cada ciclo dela espiral. En cada ciclo, el análisis de riesgos representa la misma cantidad dedesplazamiento angular, mientras que el volumen desplazado barrido denota elcrecimiento de los niveles de esfuerzo requeridos para el análisis de riesgo comolo muestra la siguiente figura:


27

Figura 3: ciclo de vida en espiral

Una de las ventajas de este modelo es que permite utilizar los modelos deproceso de construcción de software tradicionales, mientras su orientación alriesgo evita muchas dificultades. De hecho, en situaciones apropiadas, el modeloen espiral proporciona una combinación de los modelos existentes para unproyecto determinado.

Otras ventajas de este modelo son las siguientes: Presta atención a lasopciones que permiten la reutilización de software existente, está centrado en laeliminación de errores y alternativas poco atractivas, no establece unadiferenciación entre desarrollo de software y mantenimiento del sistema, yproporciona un marco estable para desarrollos integrados hardware - software.

1.4.2.2 Modelos de Transformación contínua: Estos modelos proponen unproceso por el cual los sistemas software se desarrollan a través de una serie detransformaciones continuas de problemas establecidos en especificacionesabstractas dentro de implementaciones concretas.

Se propone un esquema por el cual no hay ciclo de vida tradicional nietapas separadas, en su lugar se llevan a cabo una serie de transformaciones yrefinamientos graduales de especificaciones abstractas para llegar a programasmás concretos. En este sentido, las frases que definen el problema y los sistemas


28

software pueden emerger de algunas maneras juntas y así continuarcoevolucionando.

Los modelos de transformación continuada también se acomodan al interésde los formalistas del software que buscan de manera precisa, las propiedadesformales de las especificaciones de los sistemas software. De acuerdo a esto, losformalismos especificados pueden ser transformados matemáticamente enpropiedades que una implementación fuente debería satisfacer.

1.4.2.3 Modelos de Procesos Misceláneos: Se han propuesto muchasvariaciones de los modelos de proceso y ciclos de vida no operativos. Esto incluyeciclos de vida completamente interconectados que se acomodan a las transicionesentre dos fases sujetas a la satisfacción de sus precondiciones y suspostcondiciones así como a las variaciones de los componentes sobre el ciclo devida tradicional y modelos de transformación continúa.

1.4.2.4 Modelos de entorno de producción software: El proceso de produccióno de producto de la evolución del software, los modelos del entorno de produccióndirigen su atención a la organización y gestión de estrategias para desarrollar yproducir sistemas software. Como tales, el foco es menos tecnológico y másestratégico. Pero debería quedar claro que tales estrategias afectan tanto a losproductos software que consiguen desarrollarse, como a la forma que seráorganizado el proceso de producción del software. Entre estos modelos se puedenmencionar los siguientes: Modelos de proceso de Gestión de Proyectos software,Modelos Organizadores de Desarrollo de Software, Modelos de ciclo de Vida deRecursos de Clientes, modelos de Transición y Transferencia de tecnologíasoftware y otros modelos para la organización, fabricación y producción desistemas software.

1.5 LECCIÓN 5: CICLOS DE VIDA ÁGILES

El término “Ágil” aplicado al desarrollo de software nace en el año 2001, tras unareunión en donde participan un grupo de 17 expertos de la industria del software,incluyendo algunos de los creadores o impulsores de metodologías de software.Su objetivo fue esbozar los valores y principios que deberían permitir a los gruposdesarrollar software rápidamente y respondiendo a los cambios que puedan surgira lo largo del proyecto. Se pretendía ofrecer una alternativa a los procesos dedesarrollo de software tradicionales, caracterizados por ser rígidos y dirigidos porla documentación que se genera en cada una de las actividades desarrolladas.

Después de dicha reunión nace “The Agile Alliance”, una organización,dedicada a promover los conceptos relacionados con el desarrollo ágil de softwarey ayudar a las organizaciones para que adopten dichos conceptos, algunos deestos modelos propuestos y más difundidos pertenecientes a esta filosofía son:


29

1.5.1 Programación Extrema (XP)

Kent Beck, el padre de XP, describe la filosofía de XP como una metodología ágilque potencia las relaciones interpersonales como clave para el éxito en desarrollode software, promoviendo el trabajo en equipo, preocupándose por el aprendizajede los desarrolladores, y propiciando un buen clima de trabajo. XP se basa enrealimentación continua entre el cliente y el equipo de desarrollo, comunicaciónfluida entre todos los participantes, simplicidad en las soluciones implementadas ydisposición para enfrentar los cambios. XP se define como adecuada paraproyectos con requisitos imprecisos y muy cambiantes, y donde existe un altoriesgo técnico. Los principios y prácticas son de sentido común pero llevadas alextremo, 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 controlardesarrollos complejos de software y productos usando prácticas iterativas eincrementales. Es un proceso incremental iterativo para desarrollar cualquierproducto o gestionar cualquier trabajo. Aunque este proceso estaba previsto quefuera para la gestión de proyectos de desarrollo de software, se puede usartambién para la ejecución de equipos de mantenimiento de software o como unenfoque de gestión de programas.

SCRUM define un marco para la gestión de proyectos, que se ha utilizadocon éxito durante los últimos 10 años. Está especialmente indicada para proyectoscon un rápido cambio de requisitos. Sus principales características se pueden


30

resumir en dos. El desarrollo de software se realiza mediante iteraciones,denominadas sprints, con una duración de 30 días, el resultado de cada sprint esun incremento ejecutable que se muestra al cliente. La segunda característicaimportante son las reuniones a lo largo proyecto, entre ellas destaca la reunióndiaria de 15 minutos del equipo de desarrollo para coordinación e integración.

SCRUM es un esqueleto de proceso que incluye un conjunto de prácticas yroles predefinidos, los roles principales son el “ScrumMaster” que mantiene losprocesos y trabaja junto con el jefe de proyecto, el “Product Owner” querepresenta a las personas implicadas en el negocio y el “Team” que incluye a losdesarrolladores. Durante cada iteración (sprint- periodos de tiempo), típicamenteun periodo de 2 a 4 semanas (longitud decidida por el equipo), el equipo crea unincremento de software operativo.

Figura 5: Metodología SCRUM

El conjunto de características que entra en una iteración viene del “backlog”del producto, que es un conjunto priorizado de requisitos de trabajo de alto nivelque se han de hacer. Los ítems que entran en una iteración se determinan durantela reunión de planificación de la iteración. Durante esta reunión, el Product Ownerinforma al equipo de los ítems en el backlog del producto que quiere que secompleten. El equipo determina entonces a cuanto de eso puede comprometersea completar durante la siguiente iteración.


31

1.5.3 Agile Unified Process (AUP)

El proceso unificado ágil (AUP) es una versión simplificada de RUPdesarrollada por Scout Ambler. Describe un enfoque simple, fácil de entender, deldesarrollo de software de aplicación de negocios usando técnicas y conceptoságiles. AUP aplica técnicas ágiles incluyendo desarrollo orientado a pruebas,modelado ágil, gestión de cambios ágil y refactorización de bases de datos paramejorar la productividad.

La naturaleza en serie de AUP se presenta en cuatro fases: Inicio, elobjetivo es identificar el alcance inicial del proyecto, una arquitectura potencialpara el sistema y obtener fondos y aceptación por parte de las personasinvolucradas en el negocio; la elaboración, el objetivo es probar la arquitectura delsistema; la construcción, el objetivo es construir software operativo de formaincremental que cumpla con las necesidades de prioridad más altas de laspersonas involucradas en el negocio; transición, el objetivo es validar y desplegarel sistema en el entorno de producción.

1.5.4 Dynamic System Development Method (DSDM)

Nace en 1994 con el objetivo de crear una metodología RAD unificada. Susprincipales características son: es un proceso iterativo e incremental y el equipo dedesarrollo y el usuario trabajan juntos. Propone cinco fases: estudio viabilidad,estudio del negocio, modelado funcional, diseño y construcción, y finalmenteimplementación. Las tres últimas son iterativas, además de existir realimentación atodas las fases.

El método de desarrollo de sistemas dinámico (DSDM) es una metodologíade desarrollo de software originalmente basada en la metodología RAD. DSDM esun enfoque iterativo e incremental que enfatiza la participación continua delusuario cuyo objetivo es entregar sistemas software en tiempo y presupuestoajustándose a los cambios de requisitos durante el proceso de desarrollo. DSDMes uno de los métodos ágiles para el desarrollo de software, y forma parte de laAlianza Ágil.

Como extensión del desarrollo rápido de aplicaciones, DSDM se centra enproyectos de sistemas de información que se caracterizan por planificaciones ypresupuestos estrictos. DSDM trata las características más comunes de losproyectos de sistemas de información, incluyendo presupuestos sobrepasados,plazos de entrega desaparecidos y falta de participación del usuario y compromisode la alta gerencia.

1.5.5 Crystal Methodologies

Se trata de un conjunto de metodologías para el desarrollo de softwarecaracterizadas por estar centradas en las personas que componen el equipo y la


32

reducción al máximo del número de artefactos producidos. El desarrollo desoftware se considera un juego cooperativo de invención y comunicación, limitadopor los recursos a utilizar. El equipo de desarrollo es un factor clave, por lo que sedeben invertir esfuerzos en mejorar sus habilidades y destrezas, así como tenerpolíticas de trabajo en equipo definidas. Estas políticas dependerán del tamaño delequipo, estableciéndose una clasificación por colores, por ejemplo Crystal Clear (3a 8 miembros) y Crystal Orange (25 a 50 miembros).

Crystal Clear es un miembro de la familia de metodologías Crystal comodescribe Alistair Cockburn y se considera un ejemplo de metodología ágil. CrystalClear está pensado para aplicarse a equipos pequeños de 6 a 8 desarrolladoresubicados en el mismo sitio trabajando en sistemas que no son críticos. La familiade metodologías Crystal se centra en la eficiencia y habitabilidad comocomponentes de la seguridad del proyecto. Crystal Clear se centra en laspersonas, no en los procesos o artefactos.

Crystal Clear cuenta con las siguientes propiedades: Entrega frecuente decódigo usable a los usuarios, mejora reflexiva, comunicación osmóticapreferiblemente estando en la misma ubicación, seguridad personal, fácil acceso alos usuarios expertos y pruebas automatizadas, gestión de la configuración eintegración frecuente.

1.5.6 Adaptive Software Development (ASD)

Sus principales características son: iterativo, orientado a los componentessoftware más que a las tareas y tolerante a los cambios. El ciclo de vida quepropone tiene tres fases esenciales: especulación, colaboración y aprendizaje. Enla primera de ellas se inicia el proyecto y se planifican las características delsoftware; en la segunda desarrollan las características y finalmente en la tercerase revisa su calidad, y se entrega al cliente. La revisión de los componentes sirvepara 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 soncortas (hasta 2 semanas). Se centra en las fases de diseño e implementación delsistema partiendo de una lista de características que debe reunir el software.


33

Figura 6: Ciclo de vida FDD

1.5.8 Lean Development (LD)

Definida por Bob Charette a partir de su experiencia en proyectos con laindustria japonesa del automóvil en los años 80 y utilizada en numerososproyectos de telecomunicaciones en Europa. En LD, los cambios se consideranriesgos, pero si se manejan adecuadamente se pueden convertir en oportunidadesque mejoren la productividad del cliente. Su principal característica es introducir unmecanismo para implementar dichos cambios.


34

CAPITULO 2

DESARROLLO DE SOFTWARE


35

INTRODUCCIÓN

A continuación se describe en detalle las fases o subprocesos queconforman el proceso base de construcción de software correspondiente alestándar IEEE 1074-1989. Cada subproceso detalla el nivel de propósito,actividades involucradas y documentación principal propuesta por el estándar. Elestándar determina el conjunto de actividades esenciales, no ordenadas en eltiempo, que deben ser incorporadas dentro de un modelo de ciclo de vida de unproducto software. Este modelo es seleccionado y establecido por el usuario parael proyecto a desarrollar, ya que la norma no define un ciclo de vida particular.

El estándar ha sido escrito por organizaciones responsables de la gestión ydesarrollo de software y está dirigido a los gestores de proyectos, a losdesarrolladores de software, a los responsables de la garantía de calidad, aquienes ejecutan tareas de apoyo, y al personal de mantenimiento.

El proceso base para la construcción de software consiste en analizar lasnecesidades de la organización en un dominio, bajo un marco de gestión,seguimiento, control y gestión de la calidad. El proceso de software estácompuesto de cuatro procesos principales cada uno de los cuales agrupa unaserie de actividades que se encargan de la realización de sus requisitosasociados. Estos son los siguientes:

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

- Proceso de gestión del proyecto, donde se crean la estructura del proyectoy aseguran el nivel apropiado de la gestión del mismo durante todo el ciclode 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 enprocesos de pre-desarrollo, desarrollo y post-desarrollo.

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

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


36

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

La gestión del proyecto presupone establecer condiciones para el desarrollodel mismo, la gestión involucra actividades dentro de las cuales tenemos:

La planificación de proyectos, define la predicción de la duración de lasactividades y tareas a nivel individual, los recursos requeridos, la concurrencia y lasuperposición de tareas para que sean desarrollados en paralelo y el caminocrítico a través de la red de actividades.

La estimación, que se define como la predicción de personal, el esfuerzo ycostos que se requerirá para terminar todas las actividades y productos conocidosasociados con el proyecto.

La determinación del tamaño del producto a desarrollar, que es una de lasprimeras tareas en la gestión del proyecto, ya que sin conocerlo adecuadamente,no es posible planificar y estimar el esfuerzo necesario. El tamaño se define comola cantidad de código fuente, especificaciones, casos de prueba, documentacióndel usuario y otros productos tangibles que son la salida del proyecto.

El seguimiento de proyectos, que es la recolección de datos y suacumulación sobre recursos consumidos, costos generados, e hitos asociados conel proyecto.

La medición de un proyecto, que se define como el registro de todos losproductos generados en el mismo, de todos los recursos requeridos, planificacióny superposición de todas las actividades y de todos los factores que impactan enel proyecto como los conocimientos, métodos, herramientas, lenguajes,limitaciones, problemas y el entorno físico.

2.1.1 Proceso de iniciación del proyecto

Abarca aquellas actividades de creación de la estructura del proyecto, aquíse define el ciclo de vida del software para este proyecto y se establecen losplanes para su gestión. Se determinan los costos y recursos necesarios a fin deejecutar las distintas tareas que demanda el proyecto. Se identifican y seleccionanestándares, metodologías y herramientas para la gestión, herramientas para laejecución del mismo y por último se prepara y establece un plan para suimplementación adecuada y oportuna. El plan de gestión de proyectos softwareque conducirá al desarrollo se produce como culminación de este proceso.

A continuación se presenta una tabla de actividades a realizar, ladocumentación que se obtine y cuales técnicas se aplican.


37

Actividades a realizar Documentación desalida

Técnicas a utilizar

• Establecer el mapa deactividades para el ciclode vida del softwareseleccionado

• Asignar los recursos delproyecto

• Definir el entorno delproyecto

• Planificar la gestión delproyecto

• Plan degestión delproyecto

• Plan de retiro

• Análisis de camino crítico(CPM)

• Análisis PERT• Diagrama de GANTT• Técnicas Estadísticas• Técnicas de simulación

(método de MONTECARLO)• Puntos de función• Modelos empíricos de

estimación (COCOMO,PUTMAN)

• Técnicas deDescomposición Funcional

Tabla 1: Proceso de iniciación del proyecto

2.1.2 Proceso de seguimiento y control del proyecto

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


Técnicas a utilizar

• Analizar los riesgos• Realizar la

planificación decontingencias

• Gestionar el proyecto• Archivar los registros• Implementar el

sistema de informesde problemas

• Análisis deriesgos

• Plan decontingencias

• Registro históricode proyectos

• Análisis de riesgo técnico(Modelización ySimulación Estática yDinámica, prototipado,revisiones, auditorias)

• Análisis de riegoeconómico (Análisis definanzas, Retorno de lainversión)

• Análisis de riesgooperativo y de soporte

• Análisis de ri riesgo deprograma (Análisis delcamino crítico CPM,Técnicas de nivelación derecursos)

Tabla 2: Proceso de seguimiento y control del proyecto


38

2.1.3 Proceso de gestión de la calidad del software

El objetivo es la planificación y administración de las acciones necesariaspara proveer una confianza adecuada en la calidad de los productos software quesatisfagan los requerimientos técnicos establecidos. En el proceso de gestión de lacalidad del software se abarcan actividades en todo el ciclo de vida y sedocumenta en un plan de garantía de la calidad del software. Para abordar esteproceso de protección del software globalmente se consideran los siguientesaspectos: Las métricas para el control del proyecto, la verificación y validación,incluyendo pruebas, procesos de revisión, y la gestión de la configuración delproducto.

Las métricas del software se definen como la aplicación continua detécnicas basadas en las medidas de los procesos de desarrollo de software y desus productos para producir una información de gestión significativa y oportuna, ala vez que se mejoran los procesos y sus productos.

La verificación y la validación del software involucran actividadesimprescindibles para el control de la calidad del software. Se entiende porverificación al conjunto de actividades para la comprobación de que un productosoftware esta técnicamente bien construido, es decir, que el producto funciona.

En general, comprobar si los productos construidos en el ciclo de vidasatisfacen los requisitos establecidos en las fases anteriores, decidiendo si elproducto hasta el momento es consistente y completo. De modo complementariola validación trata la comprobación de que el producto software construido es elque se deseaba construir, es decir que funciona como el usuario quiere y hace lasfunciones que fueron concertadas con él. En la siguiente tabla se identifican lasactividades a realizar, la documentación que se obtine y cuales técnicas seaplican.


Técnicas a aplicar

• Planificar la garantía de lacalidad del software

• Desarrollar métricas decalidad

• Gestionar la calidad delsoftware

• Identificar necesidades demejora de la calidad

• Plan degarantía decalidad delsoftware

• Recomendaciones de mejorade calidad delsoftware

• Técnicas de planificacióny Estimación

• Métricas de calidad delsoftware

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


39

2.2 LECCIÓN 2: PROCESOS DE PRE-DESARROLLO

Son los procesos que se deben realizar antes de que comience eldesarrollo propiamente dicho del software. El desarrollo se inicia con laidentificación de una necesidad de automatización. Esta necesidad para sersatisfecha necesita de una nueva aplicación, o cambio de todo o parte de laaplicación existente. El proceso de pre-desarrollo abarca desde el reconocimientodel problema hasta la determinación de los requisitos funcionales a nivel desistema, pasando por el estudio de viabilidad de la solución software.

2.2.1 Proceso de exploración de conceptos

Este proceso incluye la identificación de una necesidad, la formulación desoluciones potenciales, el estudio de viabilidad, y refinamiento a nivel de sistema.Una vez establecidos sus límites, se genera el informe de la necesidad del sistemaa desarrollar. Este informe inicia el proceso de asignación del sistema y/o elproceso de requisitos, y alimentan los procesos de gestión del proyecto. El informede la necesidad es un documento que constituye la base de todo el trabajo deingeniería posterior. En la siguiente tabla se identifican las actividades a realizar, ladocumentación y cuales técnicas se aplican.

Actividades a realizar Documentación de salida Técnicas a aplicar

• Identificar ideas onecesidades

• Formular solucionespotenciales

• Conducir estudiosde viabilidad

• Planificar latransición delsistema

• Refinar y finalizar laidea o necesidad

• Modelo de la situaciónactual

• Modelo del dominio delproblema

• Informe preliminar denecesidades

• Soluciones alternativasposibles

• Solucionesrecomendadas

• Plan de transición• Informe del impacto de

la transición

• Técnicas deadquisición deconocimientos

• Análisis económico• Análisis técnico• Análisis alternativos• Técnicas de

modelización(Diagramas DFD)

• Prototipado

Tabla 4: Proceso de exploración de conceptos

2.2.2 Procesos de asignación del sistema

Este proceso se realiza cuando el sistema requiere tanto del desarrollo dehardware como el de software, o cuando no se está seguro que solo se necesitadesarrollo de software. En el informe de necesidad se identifica las entradas, elprocesamiento que se aplica a la entrada, las salidas requeridas y las funcionesdel sistema total, que permiten desarrollar la arquitectura del sistema e identificarlas funciones del hardware, del software y de las interfaces. Este proceso culmina


40

con la especificación de requisitos del software, la especificación de requisitos delhardware y la especificación de la interfaz del sistema.

Se comienza estableciendo los requisitos de todos los elementos delsistema y luego asignando un subconjunto de estos requisitos del software, parasu análisis y refinamiento en el proceso de requisitos. Este planteamiento delsistema es esencial cuando el software debe interrelacionarse con otroselementos, tales como hardware, personas y bases de datos.

El análisis de sistema requiere una comunicación intensa entre el cliente yel analista. El cliente debe comprender los objetivos del sistema y ser capaz deexponerlos claramente. El analista debe ser qué preguntas hacer, que consejosdar y qué investigación realizar, pues si la comunicación se rompe, el éxito delproyecto entero estará en peligro. En el análisis del sistema se definen losobjetivos del mismo, la información que se va a obtener, la información que se vaa suministrar, las funciones, el comportamiento y el rendimiento requerido.

Una vez que la función, el rendimiento y las interfaces están delimitados, seprocede a realizar la tarea denominada asignación. Durante la asignación, lasfunciones son asignadas a uno o más elementos genéricos del sistema, es decir,software, hardware, personal, bases de datos, documentación, procedimientos.Esencialmente, lo que se hace es asignar a cada elemento del sistema un ámbitode funcionamiento y de rendimiento.

Asignadas las funciones, se puede crear un modelo que represente lasinterrelaciones, entre los distintos elementos del sistema y establezca una basepara los posteriores pasos de análisis de requisitos y de diseño. Se representa elsistema definido mediante modelos de la arquitectura del sistema (salida, entrada,proceso y control, interfaz de usuario, mantenimiento y autocomprobación). Enprimer lugar se realiza un diagrama de contexto de la arquitectura, que establecelos límites de información entre los que se esta implementando el sistema y elentorno en el que va a funcionar. Luego, se refina el diagrama de contexto de laarquitectura considerando con más detalle la función del sistema. Se identificanlos subsistemas principales que permiten el funcionamiento del sistemaconsiderado en el contexto definido por el diagrama. Se definen los subsistemasprincipales en un diagrama de flujo de arquitectura. El diagrama de flujo dearquitectura muestra los subsistemas principales y las líneas importantes de flujode información (control y datos).

El diagrama inicial de flujo de la arquitectura se constituye en el nodo raízde la jerarquía de diagramas de flujo. Se puede ampliar cada subsistema deldiagarama de flujo inicial en otro diagrama de arquitectura dedicadoexclusivamente a él. Este proceso de descomposición de arriba hacia abajopermite disponer de una jerarquía de diagramas de flujo del sistema, donde cadauno de ellos se puede utilizar como punto de partida para los posteriores pasos deingeniería del subsistema que describe. En la siguiente tabla se identifican lasactividades a realizar, la documentación y cuales técnicas se aplican.


41

Actividades a realizar Documentación de salida Técnicas a aplicar

• Analizar lasfunciones delsistema

• Desarrollar laarquitectura delsistema

• Descomponer losrequisitos delsistema

• Especificación de requisitosdel sistema

• Especificación de requisitosfuncionales del hardware

• Especificación de la interfazdel sistema

• Descripción funcional delsistema

• Arquitectura del sistema

• Técnicas deadquisición deconocimientos

• Técnicas demodelización(Diagramas DFD)

Tabla 5: Proceso de asignación del sistema

2.3 LECCIÓN 3: PROCESOS DE DESARROLLO

Son los procesos que se deben realizar para la construcción del productosoftware. Estos definirán qué información obtener y como estructurar los datos,qué algoritmos usar para procesar los datos y cómo implementarlos, y quéinterfaces desarrollar para operar con el software y cómo hacerlo. A partir delinforme de la necesidad, con el soporte de las actividades de los procesosintegrales y bajo el plan de gestión del proyecto, los procesos de desarrolloproducen el software (código y documentación).

2.3.1 Procesos de requisitos

Incluye actividades iterativas dirigidas al desarrollo de la especificación derequisitos del software. Para la determinación completa y consistente de todos losrequerimientos del software el análisis se enfatiza sobre la salida resultante, ladescomposición de los datos, el procesamiento de los datos, las bases de datos ylas interfaces de usuario, del software y del hardware.

La especificación de requerimientos del software es el establecimientoconciso y preciso de un conjunto de requisitos que deben ser satisfechos por unproducto software, indicando el procedimiento mediante el cual se puededeterminar si se satisfacen los requerimientos dados. Describe los requisitosfuncionales, de rendimiento y de interfaz de software y definen los entornos deoperación y soporte. Este documento es la salida con la cual culmina esteproceso.

Existen tres tipos de requerimientos:

Requerimiento Funcional, que especifica la función que un sistema ocomponente de un sistema debe ser capaz de realizar.


42

Un requerimiento de rendimiento especifica una característica numéricatanto estática (número de terminales del sistema, número de usuarios simultáneosque soportará el sistema, número de archivos o registros del mismo, etc.) comodinámica (tiempo de procesamiento en el sistema) que debe tener un sistema ocomponente de un sistema.

Los requisitos de interfaz, que determinan características que el softwaredebe soportar para cada interfaz humano del producto software (interfaz deusuario), las características lógicas de cada interfaz entre el producto software ylos componentes de hardware del sistema (interfaz del hardware), el uso de otrosproductos software (un sistema de gestión de base de datos, un sistema operativo,un paquete estadístico) e interfaces con otros sistemas de aplicación (interfaz desoftware).

Existen además otros atributos del software (seguridad, consistencia,facilidad de traza, etc.) que pueden dar lugar a requisitos específicos del mismo,por ejemplo la restricción a determinados datos. En la siguiente tabla se identificanlas actividades a realizar, la documentación y cuales técnicas se aplican.

Actividades a realizar Documentación de salida Técnicas a utilizar• Definir y

desarrollar losrequerimientosdel software

• Definir losrequerimientosde interfaz

• Priorizar eintegrar losrequerimientosdel software

• Especificación derequisitos delsoftware

• Especificación derequisitos de interfazcon el usuario

• Especificación derequisitos de interfazcon otro software

• Especificación derequisitos de interfazcon hardware

• Especificación derequisitos de interfazcon el sistema físico

• Técnicas orientadas a losprocesos: Análisisestructurado (Diagramas deflujo de datos DFD,Diccionario de datos DD,Especificación de procesosprimitivos EPP), SADT,Diagramas de transición deestados, Diagramas dedescomposición, WRS, RBS,OBS, Actigramas.

• Técnicas orientadas a datos:Diagramas entidad-relación,datagramas

• Técnicas orientadas aobjetos: Diagramas declases y objetos, jerarquíade clases y objetos

• Técnicas formales deespecificación: Técnicasrelacionales (relacionesrecurrentes, expresionesregulares), TécnicasOrientadas al estado (Tablasde decisión, tablas deeventos, tablas de transición,redes de PETRI), Técnicasde prototipos.

Tabla 6: Proceso de requisitos o requerimientos


43

2.3.2 Proceso de diseño

Su objetivo es realizar una representación coherente y organizada delsistema software que satisfaga la especificación de requisitos del software. Lacalidad de dicha representación se puede evaluar. El proceso de diseño traduce el“qué hacer” de las especificaciones de los requerimientos en el “cómo hacerlo” delas especificaciones de diseño. Inicialmente, la representación describe una visiónsistémica y holística del software. Posteriores refinamientos de diseño conducen auna representación que se acerca al código fuente.

El diseño de software puede verse desde dos perspectivas: la técnica y lade gestión del proyecto. Desde el punto de vista técnico el diseño comprendecuatro actividades: diseño de los datos, diseño arquitectónico, diseñoprocedimental y diseño de interfaces. Desde el punto de vista de gestión delproyecto, el diseño va del diseño arquitectónico (diseño preliminar o de alto nivel)al diseño detallado (diseño de bajo nivel).

Desde el punto de vista de la gestión, el nivel de diseño arquitectónico sefocaliza en las funciones y estructuras de las componentes que conforman elsistema software. El nivel de diseño detallado se ocupa del refinamiento de larepresentación arquitectónica que lleva a una estructura de datos detallada y a lasrepresentaciones algorítmicas que se usan para cada componente modular delsoftware.

El proceso de diseño de software comienza con la actividad de realizar eldiseño arquitectónico. Esta actividad genera la descripción del diseñoarquitectónico del software en donde se describe cada una de las componentessoftware, se especifican los datos, las relaciones y restricciones, y se definentodas las interfaces externas (usuario, software y hardware) y los internos (entrecomponentes). La última actividad del proceso de diseño es realizar el diseñodetallado, donde se genera la descripción del diseño del software, que especificala estructura de los datos, los algoritmos y la información de control de cadacomponente software, y los detalles de las interfaces (usuario, hardware ysoftware).

El diseño detallado se deriva del diseño preliminar; en consecuencia, suscorrespondientes actividades se realizan en consecuencia mientras que el restode las actividades de este proceso (analizar el flujo de información, diseñar la basede datos, diseñar las interfaces, desarrollar los algoritmos) se ejecutan en paralelo.

Una actividad relevante es el diseño de la base de datos que comprende eldiseño conceptual, lógico y físico, de la base de datos. Los requisitos se modelizandentro de un esquema externo que describe las entidades de datos, atributos,relaciones y restricciones. Los distintos esquemas externos se integran en unesquema conceptual único. El esquema conceptual se aplica entonces en unesquema lógico dependiente de la implementación. Finalmente, se definen lasestructuras físicas de datos y los caminos de acceso.


44

Como ya se mencionó, desde el punto de vista técnico y en el contexto delos diseños preliminar y detallado, se llevan a cabo varias actividades de diseñodiferentes: diseño de datos, diseño arquitectónico, diseño procedimental y diseñode la interfaz.

El diseño de datos, que transforma el modelo del campo de información,creado durante el análisis, en las estructuras de datos que se van a requerir paraimplementar el software.

El diseño arquitectónico, que define las relaciones entre los principaleselementos estructurales del programa. El objetivo principal de este diseño esdesarrollar una estructura de programa modular y representar las relaciones decontrol entre los módulos. El diseño arquitectónico mezcla la estructura deprogramas y la estructura de datos y define las interfaces que facilitan el flujo delos datos a lo largo del programa.

El diseño procedimental, que transforma los elementos estructurales en unadescripción procedimental del software; se realiza después de que se haestablecido la estructura del programa y de los datos.

El diseño de la interfaz, que establece principalmente la disposición y losmecanismos para la interacción hombre - máquina.

El diseño es el proceso en el que se asienta la calidad del desarrollo desoftware ya que produce las representaciones del software de las que puedeevaluarse su calidad. El diseño es la única forma mediante la cual se puedetraducir con precisión los requerimientos del cliente en un producto o sistemaacabado. El diseño de software sirve como base de todas las posteriores etapasdel desarrollo y del proceso de mantenimiento.

Para evaluar la calidad de una representación del diseño se deben tener encuenta las siguientes consideraciones:

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

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

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

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


45

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

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

En la siguiente tabla se identifican las actividades a realizar, la documentacióny cuales técnicas se aplican.

Actividades a realizar Documentación de salida Técnicas a aplicar• Realizar el diseño

arquitectónico• Analizar el flujo de

información• Diseñar la base de

datos• Diseñar las

interfaces• Seleccionar o

desarrollaralgoritmos

• Realizar el diseñodetallado

• Descripción dediseño del software

• Descripción de laarquitectura delsoftware

• Descripción delflujo de información

• Descripción de labase de datos

• Descripción de lasinterfaces

• Descripción de losalgoritmos

• Técnicas orientadas a losprocesos: Diseñoestructurado (Análisis detransformación, Análisis detransacción), Diseño deldiálogo de las interfaces,Diseño lógico o diseño delperfil, HIPO.

• Técnicas orientadas adatos: Modelo lógico dedatos, modelo físico dedatos, Warnier, Jackson.

• Técnicas orientadas aobjetos: Modelos declases/objetos, diagramade módulos.

• Técnicas de diseño a bajonivel: Programaciónestructurada (diagramasarborescentes, diagramasde chapin), Programaciónorientada a objetos(diagrama de procesos),warnier, Jackson, técnicasde prototipado, técnicas derefinamiento.

Tabla 7: Proceso de diseño

2.2.3 Proceso de Implementación

Este proceso transforma la representación del diseño detallado de unproducto software a una realización en un lenguaje de programación apropiado. Elproceso de implementación produce el código fuente, el código de la base dedatos y la documentación, que constituyen la manifestación física del diseño deacuerdo a los estándares y metodologías del proyecto. Además, en este procesose debe integrar el código y la base de datos. En el caso de que el sistema constede componentes hardware y software, se debe planificar y realizar la integracióndel sistema.


46

La salida de este proceso esta sujeta a las pruebas de verificación yvalidación adecuadas. El código y la base de datos junto con la documentaciónproducida durante los procesos previos son la primera representación completadel producto software. En la siguiente tabla se identifican las actividades a realizar,la documentación y cuales técnicas se aplican.

Actividades a realizar Documentación de salida Técnicas a utilizar• Crear los datos de

prueba• Crear el código fuente• Generar el código objeto• Crear la documentación

de operación• Planificar la integración• Realizar la integración

• Datos para las pruebas• Documentación del

sistema• Documentación de

usuario• Plan de integración• Sistema software

integrado

• Warnier• Jackson• Lenguajes de

programación.

Tabla 8: Proceso de Implementación

2.4 LECCIÓN 4: PROCESOS DE POST-DESARROLLO

Son los procesos que se deben realizar para instalar, operar, soportar,mantener y retirar un producto software. Una vez terminada la prueba delsoftware, éste está casi preparado para ser entregado a los usuarios finales. Sinembargo, antes de la entrega se llevan a cabo una serie de actividades degarantía de calidad para asegurar que se hayan generado y catalogado losregistros, y documentos internos adecuados, que se ha desarrollado unadocumentación de alta calidad para el usuario, y que se han establecido losmecanismos apropiados de control de configuraciones.

Tan pronto como se entregue el software a los usuarios finales, el trabajodel ingeniero del software cambia, en este momento el enfoque pasa de laconstrucción al mantenimiento; corrección de errores, adaptación al entorno ymejora de la funcionalidad. En todos los casos, la modificación del software nosolo afecta al código, sino también a la configuración entera, es decir, a todos losdocumentos, datos y programas desarrollados en la fase de planificación ydesarrollo.

2.4.1 Proceso de instalación

Implica el transporte y la instalación de un sistema software desde elentorno de desarrollo al entorno de destino. Incluye la carga de la base de datos,las modificaciones necesarias del software, las comprobaciones en el entorno dedestino y la aceptación del cliente. Si durante la instalación surge un problema seidentifica e informa acerca de él.


47

El proceso de instalación verifica que se implemente la configuraciónadecuada del software y termina con la aceptación formal del mismo por parte delcliente conforme a lo especificado en el plan de gestión del proceso software y larealización con éxito de la prueba de aceptación del usuario. En la siguiente tablase identifican las actividades a realizar y la documentación.

Actividades a realizar Documentación de salida• Planificar la instalación• Distribuir el software• Instalar el software• Cargar la base de datos

Aceptar el software en el entorno de operación

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

Tabla 9: Proceso de instalación

2.4.2 Proceso de operación y soporte

Involucra la operación del sistema por parte del usuario y el soportecontinuo al usuario que incluye asistencia técnica, consultas con el usuario yregistro de las peticiones de soporte en el histórico de peticiones de soporte. Así,este proceso puede desencadenar la actividad del proceso de mantenimiento queprovee información de realimentación al ciclo de vida del software. En la siguientetabla se identifican las actividades a realizar, y la documentación.

Actividades a realizar Documentación de salida• Operar el sistema• Proveer de asistencia técnica y

consultas• Mantener el histórico de las peticiones

de soporte

• Histórico de las peticiones de soporte

Tabla 10: Proceso de operación y soporte

2.4.3 Proceso de mantenimiento

Se interesa por los errores, defectos, fallas, mejoras y cambios del software.Un requisito de mantenimiento del software inicia los cambios del ciclo de vida delsoftware; éste se reasigna y se ejecuta.

El mantenimiento se centra en el cambio que va asociado a la corrección deerrores, a las adaptaciones requeridas por la evolución del entorno del software ya las modificaciones debidas a los cambios de los requisitos del cliente dirigidos areforzar o ampliar el sistema. El proceso de mantenimiento vuelve a aplicar lospasos del ciclo de vida, pero en el contexto del software ya existente.

Durante el mantenimiento se encuentran tres tipos de cambios:


48

Corrección: Incluso llevando a cabo las mejores actividades de garantía decalidad, es muy probable que el cliente descubra defectos en el software. Elmantenimiento correctivo cambia el software para corregir los defectos.

Adaptación: con el paso del tiempo es probable que cambie el entornooriginal para el que se desarrolló el software. El mantenimiento adaptativo consisteen modificar el software para acomodarlo a los cambios de su entorno externo.

Mejora: conforme utilice el software, el cliente o usuario puede descubrirfunciones adicionales que podría interesar que estuvieran incorporadas alsoftware. El mantenimiento perfectivo amplía el software más allá de susrequisitos funcionales originales.

La salida de este proceso son las recomendaciones del mantenimiento queentran al ciclo de vida del software en el proceso de exploración de conceptospara mejorar la calidad del sistema software. En la siguiente tabla se identifican lasactividades a realizar, y la documentación.

Actividades a realizar Documentación de salida• Operar el sistema• Proveer de asistencia técnica y

consultas• Mantener el histórico de las peticiones

de soporte

• Histórico de las peticiones de soporte

Tabla 11: Proceso de Mantenimiento

2.4.4 Proceso de Retiro

Se puede decir que es la jubilación de un sistema existente de su soporteactivo o de su uso mediante el cese de su operación o soporte, o su reemplazopor un nuevo sistema o por su actualización. Si el sistema en uso se reemplazapor un nuevo sistema se requiere un tiempo de operación en paralelo. En esteperiodo se utiliza el sistema en retiro para los resultados oficiales, mientras seprepara el nuevo sistema para su operación formal. Es un período de formaciónpara el usuario sobre el nuevo sistema y de validación del mismo. En la siguientetabla se identifican las actividades a realizar, y la documentación.

Actividades a realizar Documentación de salida• Notificar al usuario• Conducir las operaciones en paralelo• Retirar el sistema

• Plan de retiro

Tabla 12: Proceso de retiro


49

2.5 LECCIÓN 5: PROCESOS INTEGRALES DEL PROYECTO

Son procesos simultáneos y complementarios a los procesos orientadoshacia el desarrollo. Incluyen actividades imprescindibles para que el sistemaconstruido sea fiable (procesos de verificación y validación, gestión de laconfiguración) y sea utilizado al máximo de sus capacidades (procesos deformación, documentación). Los procesos integrales comprenden dos tipos deactividades: Aquellas que se realizan discretamente y se aplican dentro de unciclo de vida del software y las que se realizan para completar otra actividad, estassolo se invocan y no se aplican dentro del ciclo de vida para cada instancia.

2.5.1 Proceso de verificación y validación

Abarca la planificación y la realización de todas las tareas de verificación,incluyendo pruebas de verificación, revisiones y auditorias, y de todas las tareasde validación, incluyendo pruebas de validación, que se ejecutan durante el ciclode vida del software para asegurar que se satisfacen todos los requisitos delsoftware.

Una actividad útil para la verificación y la validación del software es laprueba del software. Constituye el proceso de ejecución del software condeterminados datos de entrada, para observar los resultados que produce ycompararlos con los resultados teóricos que debería producir, para esos datos deentrada, con el objeto de detectar posibles fallas. Las pruebas del software solopodrán realizarse cuando en el proceso de desarrollo ya exista código ejecutable.

La depuración es un proceso frecuentemente asociado a las pruebas queconsiste en tratar de deducir donde están los defectos en el software queprovocan que éste no funcione adecuadamente. Estudia los resultados de laspruebas y otras actividades de control para intentar buscar qué está mal en elsoftware. En la siguiente tabla se identifican las actividades a realizar, ladocumentación y cuales técnicas se aplican.

Actividades a realizar Documentación de salida Técnicas a utilizar• Planificar la

verificación yvalidación

• Ejecutar las tareasde verificación yvalidación

• Recoger y analizarlos datos de lasmétricas

• Planificar laspruebas

• Desarrollar lasespecificaciones delas pruebas

• Ejecutar las pruebas

• Plan de verificacióny validación

• Informes deevaluación

• Plan de pruebas• Especificación de

las pruebas• Informe resumen

de las pruebas• Software aprobado

• Técnicas de prueba decaja blanca (cobertura desentencias, cobertura dedecisión y de ramificación,cobertura de condición,cobertura dedecisión/condición,cobertura de condiciónmúltiple)

• Técnicas de prueba decaja negra (Partición deequivalencias, análisis devalores límites, gráficos decausa/efecto, conjetura deerror)


50

• Revisiones formales• Auditorias

Tabla 13: Proceso de verificación y validación

2.5.2 Proceso de gestión de la configuración

Este proceso involucra un conjunto de actividades desarrolladas paragestionar los cambios durante todo el ciclo de vida del software. Identifica laestructura de un sistema (qué rutinas, módulos, datos, archivos lo componen) enun momento dado a lo que se le denomina configuración del sistema. Su objetivoes el control de los cambios en el sistema, mantener su coherencia y surastreabilidad o trazabilidad, y poder realizar auditorias de control sobre laevolución de las configuraciones.

La gestión de la configuración realiza las siguientes funciones: Identificaciónde la configuración de un sistema o descripción documentada de lascaracterísticas reales del sistema en un determinado momento; control de laconfiguración, establece la configuración inicial o básica y controla los cambios enlos elementos de la misma; informes del estado de la configuración; auditorias dela configuración, revisiones independientes de la configuración para comprobarque los elementos de la configuración cumplen los requisitos de configuraciónestablecidos. En la siguiente tabla se identifican las actividades a realizar, y ladocumentación.

Actividades a realizar Documentación de salida• Planificar la gestión de la configuración• Realizar la identificación de la

configuración• Realizar el control de configuración• Realizar la información del estado de

la configuración

• Plan de gestión de configuración delsoftware

• Orden de cambio de ingeniería• Cambio de estado• Informe de estado

Tabla 14: Proceso de gestión de la configuración

2.5.3 Proceso de desarrollo de documentación

El proceso de desarrollo de documentación para el desarrollo y uso delsoftware es el conjunto de actividades que planifican, diseñan, implementan,editan, producen, distribuyen y mantienen los documentos necesarios para losdesarrolladores y los usuarios. En la siguiente tabla se identifican las actividades arealizar, y la documentación.


51

Actividades a realizar Documentación de salida• Planificar la documentación• Implementar la documentación• Producir y distribuir la documentación

• Plan de documentación

Tabla 15: Proceso de desarrollo de documentación

2.5.4 Proceso de formación

Incluye la planificación, desarrollo, validación e implementación de losprogramas de formación de desarrolladores, personal de soporte técnico y clienteso usuarios y la elaboración de los materiales de formación adecuados. Paraconseguir una utilización efectiva del sistema software, se debe proporcionar a losusuarios del sistema instrucciones, guía y ayuda para el entendimiento de lascapacidades del sistema y de sus limitaciones. Por ello es imprescindible laformación de los usuarios en el nuevo sistema.

El desarrollo de productos software de calidad depende en gran medida delos conocimientos de las personas y del personal especializado involucrados en elproyecto. Por ello, es esencial la formación de los desarrolladores y personal desoporte técnico. En la siguiente tabla se identifican las actividades a realizar, y ladocumentación.

Actividades a realizar Documentación de salida• Planificar el programa de formación• Desarrollar los materiales de formación• Validar el programa de formación• Implementar el programa de formación

• Plan de formación

Tabla 16: Proceso de desarrollo de formación


52

CAPITULO 3

CONCEPTOS DE CALIDAD YCALIDAD DEL SOFTWARE


53

INTRODUCCIÓN

El avance informático actual es muy alto comparado con lo se tenía en losaños 90, al hablar de desarrollo de software se hace más notable, en el hecho porejemplo de pasar de una programación de código línea a línea, a un método deprogramación gráfico orientado a objetos donde el desarrollo es mas rápido yatractivo para el cliente.

Más sin embargo con estas ventajas que se tiene con las nuevasherramientas de desarrollo de software se olvida la calidad del producto que esentregado, no es solamente una calidad gráfica, o la calidad de velocidad en larespuesta, hay que tener en cuenta otras cualidades, para buscar una integralidadal afirmar que el software es de calidad.

Los desarrolladores del software, opinan que el sus productos son losmejores del mercado, pero no se han preguntado que opina el cliente. El tener undocumento que explique los requerimientos para evaluar el software ayuda aldesarrollo, compra o auditoría de cualquier aplicación informática del mercado,teniendo en cuenta que hoy en día es muy importante para las empresas privadaso públicas la inversión en este tipo de producto, los cuales verifican la calidad a lahora de entrar a producción, donde se detectan las falencias, reportando allípérdidas.

Este capítulo presenta indicadores de calidad de un software; al momentode la entrega, basados en los estándares de calidad sugeridos la norma ISO/IEC9126; de la ISO (Organización Internacional de Normalización) y la IEC (ComisiónElectrotécnica Internacional).


54

3.1 LECCIÓN 1: DEFINICIÓN DE CALIDAD

Inicialmente la calidad hace referencia al proceso industrial donde W. E.Deming propuso la idea de calidad como conformidad a requisitos y confiabilidaden el funcionamiento. Posteriormente surgen otras definiciones de calidad como lade J. Juran que propone una definición breve: ‘Quality is fitness for use”; es decir,la calidad es la adecuación del producto al uso donde esta definición incluye lascaracterísticas del producto que permiten obtener la satisfacción del usuario y,además, supone la ausencia de deficiencias. Para P. Crossby el concepto deJuran se asume pero también destaca la prevención: “Cero defectos” o “Hacerlobien a la primera”. En la bibliografía son frecuentes las definiciones de calidadpero en su gran mayoría todas ellas se acercan al concepto expresado por Juran.

La definición oficial, y más completa, es la de la norma ISO 9000:2000 quedefine la calidad en general como: “Grado en el que un conjunto de característicasinherentes cumple con los requisitos”, donde los requisitos son las necesidades oexpectativas establecidas, generalmente implícitas u obligatorias y lascaracterísticas se refieren a cualquier tipo de rasgo diferenciador. También sedebe recordar que las necesidades pueden variar en el tiempo, por lo que hay queprever la revisión de la especificación.

Esta definición permite comprender que la consecución de la calidad puedetener tres orígenes:

3.1.1 La calidad realizada: Que es la calidad obtenida por la persona que realizael trabajo gracias a su habilidad en la ejecución de una tarea. Se potencia con lamejora de las habilidades personales y técnicas de los participantes en un procesodeterminado.

3.1.2 La calidad programada: Que es la calidad que se ha encomendadoconseguir a la persona reponsabIe de ejecutar el trabajo. Se potencia con laelaboración de una especificación que sirva de buena referencia a losparticipantes en un proceso. Esta aperece descrita en una especificación, en undocumento de diseño o en un plano constructivo.

3.1.3 La calidad necesaria: La que el cliente exige con mayor o menor grado deconcreción o, al menos, la que le gustaría recibir. Se potencia con una adecuadaobtención de información de la idea de calidad de los clientes y de su percepciónde la misma.

La gestión de la calidad pretenderá entonces, conseguir que estos tres círculoscoincidan entre sí.


55

3.2 LECCIÓN 2: SISTEMAS DE CALIDAD EN LA EMPRESA

La política de la calidad forma parte de la política general de la empresa,por eso es importante que la dirección o gerencia exprese dicha política demanera explícita al igual que lo hace para la política financiera, de personal, etc.Por lo tanto, la gestión de la calidad forma parte de las tareas de la dirección, ypara tener éxito, se debe contar con el compromiso y la participación de todos.Incluye la planificación estratégica, la asignación de recursos, las actividadessistemáticas, y evaluaciones entre otras. Actualmente, de forma general, se sueleapoyar en la creación de lo que se denomina sistema de calidad para laorganización.

Un sistema de gestión de calidad es un un sistema para establecer políticasy los objetivos con respecto a la calidad y para lograr dichos objetivos se debeaplicar a la dirección y control de una organización. Este sistema de calidad seadecúa a los objetivos fijados por la empresa en cuanto al tema. La dirección es laresponsable de fijar las políticas de calidad y las decisiones relativas a iniciar,desarrollar, implantar y actualizar el sistema de calidad.

Uno de los factores fundamentales del trabajo en este nivel consiste en fijarla estructura organizativa con líneas de jerarquía y de comunicación ligada alsistema de gestión de calidad. Para ser útil el sistema de calidad debe cumplir conlas siguientes características: Ser eficaz y comprendido por todos, dar confianzaen satisfacer las necesidades de los clientes y poner mayor énfasis en prevenirque en detectar y corregir.

Un sistema de calidad consta de dos partes, una escrita y otra práctica. Laparte escrita está en una serie de documentos en los cuales se describe elsistema, los procedimientos, entre otros, ajustándose a una norma habitualmentese usa la noma ISO 9001. Y la parte práctica que tiene dos vertientes principales,una que tiene en cuenta los aspectos físicos (locales, herramientas,computadores) y otra que toma los aspectos humanos como la formación delpersonal (tanto en técnicas de calidad corno en técnicas de reuniones,comunicación) y en creación y coordinación de equipos de trabajo.

El manual de calidad es el documento principal para establecer e implantarun sistema de calidad, en el se documentan todos los elementos, los requisitos ylos medios que adopte la empresa para su sistema de calidad se deben establecerpor escrito, ordenadamente, en forma de políticas y procedimientos. El manual decalidad debe describir adecuadamente el sistema de gestión de la calidad paraservir como referencia permanente al implantar o al aplicar el sistema.

El manual de calidad incluye las políticas de calidad que se han adoptado,la definición del sistema de calidad, la presentación de la estructura de laorganización y la referencia a los procedimientos aplicables. Según la norma ISO9OO4 y la norma UNE 66-907-91, se puede sugerir la siguiente estructura de unmanual de calidad:


56

3.2.1 Capítulos de introducción

• Índice• Declaración de la dirección de la empresa• Política de calidad y objetivos generales de la empresa respecto a la calidad• Objeto y campo de aplicación del manual de calidad• Terminología• Gestión del manual de calidad (procedimiento para cambios, aprobación, etc.)• Presentación de la empresa

3.2.2 Disposiciones para conseguir la calidad

En general en el orden del ciclo de vida. El manual de calidad se estableceprincipalmente para uso interno de la empresa aunque puede facilitar lasrelaciones cliente-proveedor, además es un elemento clave en el proceso decertificación del sistema de calidad de la empresa.

El manual de calidad se completa con procedimientos o instruccionesespecíficas para ciertas actividades o procesos que deben mencionarseexplícitamente en dicho manual. Para cada empresa suelen existir procedimientosparticulares, cuyo fundamento debe ser la buena práctica y la experiencia en eltrabajo diario y los códigos, las normas y las especificaciones a los que debenajustarse.

Para las organizaciones de desarrollo de software, se suelen incluir losprocedimientos (técnicas y metodologías) para realizar y documentar el análisis delos sistemas, para realizar y documentar el diseño de los sistemas o de sus basesde datos, entre otros. En general, indicarán la metodología a aplicar, algunosejemplos típicos de procedimientos relacionados con el desarrollo pueden ser elprocedimiento de especificación de requisitos del software, el procedimiento paralas pruebas del software, el procedimiento de estilo de codificación, etc.

Otros documentos importantes en el sistema de calidad son los que aportanevidencias sobre la aplicación de calidad, sobre todo el proceso de desarrollo, enellos se evidencia, los registros de datos sobre calidad, almacenamientos de datossobre las actividades relacionadas con la calidad o sobre la evaluación de losproductos. Normalmente suelen incluir datos de pruebas, datos sobre lasrevisiones e inspecciones, datos de costes de actividades. Estos se debenconservar incluso después de acabar el proyecto para analizar las tendencias dela calidad obtenida y corregir las causas de defectos.

Algunas de las características que debería tener la documentación encualquier caso son las siguientes: Tener como objetivo facilitar los medios para elbuen funcionamiento del sistema de calidad, También debe servir para dejarconstancia del nivel de calidad alcanzado, ser legible, estar fechada, limpia,identificable y archivada, e incluir todo tipo de documentos como especificaciones,y procedimientos.


57

3.3 LECCIÓN 3: NORMATIVIDAD DE CALIDAD

La normativa de calidad surge inicialmente en empresas de algunos de lossectores de seguridad crítica como el militar, nuclear, y aeroespacial. La normativanuclear ha inspirado muchas otras normas, sin embargo, La revolución normativapara todos los sectores se produjo con la llegada de la serie de normas ISO 9000,inicialmente con la norma de gestión y aseguramiento de la calidad ISO 9000, yposteriormente tres normas con recomendaciones para el aseguramiento externode la calidad, la ISO 9001, 9002 y 9003 dependiendo de qué parte del ciclo de lacalidad fuera el centro de actividad de la empresa y una norma ISO 9004 conrecomendaciones para la gestión interna de la calidad.

Sin embargo, la reciente revisión de la serie 9000 realizada en el año 2000,cambió la filosofía y la estructura de las normas 9000, ahora existe una únicanorma ISO 9001:2000 que abarca todos los aspectos necesarios de todas lasactividades del ciclo de vida. Las organizaciones que antes empleaban las normasISO 9002 y 9003, aplicarán la ISO 9001:2000 limitando su ámbito de aplicación. Elcambio de filosofía experimentado se basa en incrementar la importancia de lamejora continua y el ciclo PDCA (Plan-Do-Check-Act), así como una mayordefinición de los procesos y de la evaluación de la satisfacción de clientes yusuarios. La importancia de estas normas reside en que se emplean como basepara que las empresas se certifiquen en procesos y que transmita a sus clientes laconfianza en que trabaja con procedimientos que permiten asegurar la calidad ensus actividades.

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


58

En el caso del software que es un producto muy especial, fue necesariohacer una interpretación de la versión ISO 9001:1994 generando la guía ISO9000-3:1997 que es la “Guía para aplicar ISO 9001 al desarrollo, suministro ymantenimiento de software”. Con la llegada de la norma ISO 9001:2000, la guíaISO 9000-3 es aplicable y útil aunque requiere una actualización.

La guía contempla tres aspectos principales de disposiciones adaptadas ala terminología y características especiales del software como producto, el primeroes el marco de trabajo de la empresa (sistema de calidad, responsabilidad de ladirección y la realización de acciones correctivas), el segundo que muestra lasactividades del ciclo de vida (Revisión de contrato, especificación, planificación,planificación de la calidad, diseño, implementación, revisiones, pruebas,aceptación, replicación, entrega, instalación y mantenimiento), y el tercero dondeestán las actividades de apoyo (Gestión de configuración, control de documentos,métricas, convenciones y reglas, herramientas, formación, registros de calidad ycompras).

Desde el punto de vista práctico, la ISO 9001:2000 incluye las siguientesdisposiciones:

3.3.1 Responsabilidad de la dirección

Desde un ámbito general muestra el compromiso con la satisfacción delcliente, promoviendo una determinación eficaz de requisitos y de las necesidadesdel cliente, establece una política de calidad que debe llevar a una planificación dela calidad y de sus objetivos, a través de un sistema de gestión de calidad en elque deben existir revisiones formales de la gestión realizada.

3.3.2 Gestión de recursos

Para determinar y proporcionar lo necesario para la gestión de calidad,especialmente en el ámbito de los recursos humanos donde debe realizarse laadecuada política de asignación a tareas, determinar, realizar y evaluar el impactode las acciones de formación y cualificación, y de competencias profesionales. Nose deben olvidar otros recursos como la información, las infraestructurasnecesarias y el entorno de trabajo.

3.3.3 Gestión de los procesos

Con disposiciones para las actividades de gestión, los procesosrelacionados con el cliente, el diseño y el desarrollo de productos y servicios, lagestión de compras y proveedores, la producción y la operación de servicios, elcontrol de las no-conformidades de las entregas respecto de los requisitosestablecidos y los servicios post-entrega.


59

3.3.4 Medición, análisis y mejora

Contempla la medición del rendimiento del sistema, medición de procesos,medición de productos y/o servicios y el control de la propia medición y de losmedios de inspección y prueba. En cuanto a análisis de datos, se trata de obtenerlas conclusiones apropiadas para emprender acciones de mejora relacionadas concorreción de errores, prevención de problemas para el futuro y el establecimientode procesos de mejora continua.

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

Para hablar de la calidad en el software, se debe tener en cuenta que estees un producto con características particulares, por lo cual se hace necesarioadaptar la terminología creada y aplicada en los sectores industriales. Algunas deestas características del software son las siguientes:

El software se desarrolla, no se fabrica ya que todo el costo de producciónse centra en el diseño de la primera copia. El software es un producto lógico, elverdadero producto del software es el diseño de una serie de instrucciones para elcomputador, su existencia en papel o en soporte magnético no es más que unarepresentación en un código o lenguaje de las instrucciones.

El software no se degrada con el uso, ya que la naturaleza lógica delsoftware permite que permanezca inalterable por muy intensa que sea suutilización. Se puede degradar su representación magnética pero no su esencia.

La complejidad del software, la ausencia de controles adecuados hace queel software sea entregado muchas veces y conscientemente con defectos, inclusopúblicamente declarados. En el sector informático, incluso, se llega a cobrar unacuota de mantenimiento para reparar los defectos que el propio productor delsoftware ha entregado con el mismo.

Un porcentaje muy grande de la producción de software se hace aún amedida. En vez de emplear componentes existentes y ensamblarlos, aunque lasbibliotecas de funciones o componentes están ya cambiando en parte estasituación.

El software es extraordinariamente flexible, ya que se puede cambiar confacilidad reutilizando trozos de un producto para construir otro. Sin embargo, lafacilidad para cambiarlo es también un peligro que hay que controlar.

El diccionario estándar de ingeniería del software IEEE Std.6l0, indica quesoftware son “los programas de ordenador, los procedimientos y, posiblemente, ladocumentación asociada y los datos relativos a la operación del sistemainformático”. No se limita al código solamente y se debe tener en cuenta elsoftware en cualquier estado de evolución (diseños, especificaciones, datos deprueba, etc), si se quiere obtener calidad en el software. También conviene


60

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

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

La definición del estándar IEEE Std.610-1991, indica que calidad delsoftware es el grado con el que un sistema, componente o proceso cumple con losrequisitos especificados y las necesaidades expectativas del cliente o usuario.Esta definición es la que más se ajusta al concepto de concordancia del softwareproducido con los requisitos explícitamente establecidos, con los estándares dedesarrollo expresamente fijados y con los requisitos implícitos, no establecidosformalmente, que desea el usuario.

Los requisitos se reflejan en la especificación de requisitos de maneraexplícita, el documento constituye la culminación de la etapa de análisis dentro delproceso de desarrollo. Los requisitos pueden ser funcionales, cuando sedeterminan las funciones que debe realizar el software y no funcionales como elrendimiento, la seguridad, el tiempo de respuesta, la interfaz, etc. De igual forma,los estándares y las normas, determinan cómo se debe realizar el proceso dedesarrollo de software. Además, existen requisitos implícitos, no expresamentedeclarados, pero que el usuario del software desea obtener.

Para hacer el estudio de la calidad del software se debe conocer primerolos principales términos empleados en esta área, algunos de ellos son:

3.5.1 Gestión de la calidad del software (Software Quality Management)

Son las actividades coordinadas para dirigir y controlar una organización enlo relativo a la calidad. Esto se puede entender como el aspecto de la funcióngeneral de la gestión que detemina y aplica la política de calidad (objetivos ydirectrices generales de calidad de una empresa). Normalmente la gestión decalidad se aplica a nivel de empresa, por lo que incluye planificación estratégica,asignación de recursos, etc.

3.5.2 Aseguramiento de la calidad del software (Software QualityAssurance)

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


61

3.5.3 Control de la calidad del software (Software Quality Control)

Es la parte de la gestión de la calidad orientada al cumplimiento de losrequisitos de la calidad. Suele incluir las técnicas y actividades de carácteroperativo, utilizadas para satisfacer los requisitos relativos a la calidad, centradasen dos objetivos fundamentales, el de mantener bajo control un proceso y eliminarlas causas de defectos en las diferentes fases del ciclo de vida. En general, sonlas actividades para evaluar la calidad de los productos desarrollados. También,en el software, puede ser el “proceso de verificar el propio trabajo o el de uncompañero”.

3.5.4 Verificación y validación del software (Software Verication andValidation)

Que es una actividad ligada al control de la calidad en el ámbito delsoftware. La verificación hace refrencia a comprobar si los productos construidosen una fase del ciclo de vida satisfacen los requisitos establecidos en la faseanterior. Se suele decidir si el producto esta completo y es consistente. Aquí serealizan las actividades para comprobar si un producto software esta técnicamentebien construido y si funciona. Y la validación que se refiere a comprobar si elsoftware construido satisface los requisitos del usuario. Por lo tanto, son lasactividades de comprobación de que el producto software construido es el que sedeseaba construir, es decir, si el producto funciona como el usuario quiere yrealiza las funciones que se habían solicitado.


62

GLOSARIO DE TÉRMINOS

Automatización: Es el uso de sistemas o elementos computarizados yelectromecánicos para controlar maquinarias y/o procesos industrialessustituyendo a operadores humanos.

Ciclo de Vida: El ciclo de vida de software es la descripción de las distintasformas de desarrollo de un proyecto informático.

Ciclo de Vida Ágil: Es un marco de trabajo conceptual de la ingeniería desoftware que promueve iteraciones en el desarrollo a lo largo de todo el ciclo devida del proyecto. Existen muchos métodos de desarrollo ágil; la mayoría minimizariesgos desarrollando software en cortos lapsos de tiempo. El softwaredesarrollado en una unidad de tiempo es llamado una iteración, la cual debe durarde una a cuatro semanas. Cada iteración del ciclo de vida incluye: planificación,análisis de requerimientos, diseño, codificación, revisión y documentación.

Componente Software: Son todos aquellos recursos desarrollados para un finconcreto y que puede formar solo o junto con otros, un entorno funcional requeridopor cualquier proceso predefinido.

Estándar: Base o modelo en el que todo el mundo se ha puesto de acuerdo.

IEEE: Corresponde a las siglas de (Institute of Electrical and ElectronicsEngineers) en español Instituto de Ingenieros Eléctricos y Electrónicos, unaasociación técnico-profesional mundial dedicada a la estandarización, entre otrascosas.

ISO: (Internacional Standards Organization) Organización Internacional deestándares fundada en 1946, con sede principal en Ginebra, ISO establece o fijaestándares internacionales. Se ocupa de todos los campos, excepto la electricidady la electrónica, que se rigen por la Internacional Electrotechnical Comisión (IEC),también en Ginebra.

Modelo: Un modelo es una estructura conceptual que sugiere un marco de ideaspara un conjunto de descripciones que de otra manera no podrían sersistematizadas.

Proceso: El proceso de ingeniería de software se define como un conjunto deetapas parcialmente ordenadas con la intención de logra un objetivo, en este caso,la obtención de un producto de software de calidad.

Requerimientos: Características que se desea que posea un sistema o unsoftware.


63

Calidad: La calidad es herramienta básica para una propiedad inherente decualquier cosa que permite que esta sea comparada con cualquier otra de sumisma especie.

Calidad de Software: Características propias del software que se desea controlary asegurar, el software es un producto inmaterial que no se fabrica, tampoco sedegradan físicamente, sino que se desarrolla; El software puede tener errores,incidencias pero no son similares a lo que cualquier equipo de carácter físico.

ISO 9001: Es un conjunto de normas sobre la calidad y la gestión.

Gestión de Calidad de Software: Es un conjunto de actividades de la funcióngeneral de la Dirección que determina la calidad, los objetivos y lasresponsabilidades. Se basa en la determinación y aplicación de las políticas decalidad de la empresa.


64

FUENTES DOCUMENTALES

Bibliografía de referencia:

Beck, K.. .Extreme Programming Explained. Embrace Change., PearsonEducation, 1999. Traducido al español como: .Una explicación de la programaciónextrema. Aceptar el cambio., Addison Wesley, 2000.

CETTICO, Centro Transferencia tecnológica en Informática y Comuicaciones.,Enciclopedia de Informática y Computación, Ingeniería de software e Inteligenciaartificial. Universidad Politécnica de Madrid 1999.

De Domingo, J. y Arranz, A., Calidad y mejora continua, Ed Donostiarra. 1997.

Piatini, Mario y col. Analisis y Diseño de Aplicaciones Informáticas de Gestión, UnaPerspectiva de Ingeniería de Software, Alfaomega 2004. Páginas 109 – 164.

BRAUDE. Ingeniería de software, una perspectiva orientada a objetos. México.2003. Alfaomega grupo editor. S.A.

HUMPHREY, Watts S. Introducción al proceso de software personal. PearsonAddison wesley. 2001.

NORRIS. Ingeniería de software explicada. Grupo Noriega editores de Colombia.

PIATTINI, Mario. VILLALBA, Jose y otros. Mantenimiento del software: modelos,técnicas y métodos para la gestión del cambio. Editorial Alfaomega-Rama.

PRESSMAN, Roger S. Ingeniería del Software. Un enfoque práctico. Quintaedición. España. 2002. Editorial McGraw Hill.

SOMMERVILLE, Ian. Ingeniería de software. 6ª. Edición. Pearson AddisonWesley. 2001

Direcciones Electronicas (webgrafía)

http://www.pressman5.comhttp://www.wiley.com/college/braudehttp://www.comp.lancs.ac.uk/computing/resources/IanS/SE6/PDF/SEGlossary.pdfhttp://www.itver.edu.mx/comunidad/material/ing-software/unidad5.ppthttp://www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware.htmlhttp://www.sistemas.unam.mx/software.html


65

UNIDAD 2Nombre de la Unidad ESTÁNDARES, MÉTRICAS DE CALIDAD Y PRUEBAS

DEL SOFTWAREIntroducción En este capítulo se trata los temas que son el fundamento

de la calidad del software y su evaluación, entre ellasestán los modelos y estándares actuales de calidad, quedetallan las características mediante las cuales se hace laevaluación, las métricas de calidad y las métricas técnicasde calidad del software que son los indicadores, lasescalas de medición cualitativa o cuantitaiva y las pruebasdel software que se ejecutan para verificación de lacalidad del producto o proceso.

Justificación Esta unidad es quiza una de las más importantes para laevaluación del software, ya que se identifica en ella lostipos de evaluación estática y dinámica mediante el usode las métricas y las pruebas del software. Los estándaresson los que permiten referencias cuales características seevaluará y que métricas y pruebas se asocian a ellas.


- El estudiante conoce los estándares y modelos utilizadospara la evaluación de la calidad del software

- El estudiante reconoce las características internas,externas y de usabilidad dentro de los estándares

- El estudiante asocia cada una de las características conlas métricas y las pruebas a realizar en cada caso

- El estudiante define de acuerdo a las especificacionesdel cliente, las características, subcaracterísticas, métricasy pruebas a utilizar


CAPITULO 4: ESTANDARES Y MODELOS DECALIDAD DEL SOFTWARE

Denominación delecciones

Lección 1. La Calidad del Software


Lección 2. Calidad del Producto Software – NormaISO/IEC 9126


Lección 3. Calidad del Producto software – NormaISO/IEC 14598


Lección 4. Calidad del Producto Software – NormaISO/IEC 25000 (SquaRE)


Lección 5. Modelos de Mejora de Procesos de Software.


CAPITULO 5: MÉTRICAS DE CALIDAD DELSOFTWARE

Denominación de Lección 1. Conceptos Básicos de Métricas


66

leccionesDenominación delecciones

Lección 2. Métricas del Software


Lección 3. Métricas de Calidad del Software


Lección 4. Métricas Técnicas del Software


Lección 5. Estructura para las Métricas de Calidad delsoftware


CAPITULO 6: PRUEBAS DEL SOFTWARE


Lección 1. La Prueba del software


Lección 2. Técnicas de diseño de Casos de Prueba


Lección 3. Estrategias de Aplicación de Pruebas delSoftware


Lección 4. Pruebas de Software para Objetos


Lección 5. Pruebas de Software Basado en Componentes


67

UNIDAD 2

ESTÁNDARES,MÉTRICAS DE CALIDAD

Y PRUEBAS DELSOFTWARE


68

CAPITULO 4

ESTÁNDARES Y MODELOS DECALIDAD DEL SOFTWARE


69

INTRODUCCIÓN

La calidad es un concepto complejo, que se viene aplicando en el campo dela informática desde hace muchos años. En particular, la aplicación de la calidad alproducto software toma cuerpo con la aparición de los primeros modelos decalidad de producto y se fortalece con la propuesta de normas internacionales quecomienzan a ser utilizados como marco de referencia para el campo profesional yacadémico.

En el año de 1987 la oficina internacional para la estandarización (ISO) y laComisición Electrotécnica internacional (IEC), constituyeron un comité técnicoconjunto con la finalidad de proponer normas internacionales en el campo de lastecnologías de la información y los equipos.

En 1985 se inició el desarrollo la norma internacional ISO/IEC y fuepublicada en 1991 como “ISO/IEC 9126:1991: Tecnología de la Información –Evaluación del Producto Software – Características de la Calidad y Guía para suAplicación”. Utilizaron como base para la definición de las características, elconcepto de calidad que posteriormente aparecería en la norma ISO 8402 y queestá basada en las necesidades del usuario. Antes de la publicación de la normaISO/IEC 9126, los trabajos de McCall, Boehm y otros fueron adoptados ymejorados. Esta norma constituyó el primer esfuerzo internacional para unificar yuniformizar los términos de calidad referido al producto software y proponer unaestructura basada en características y subcaracterísticas de calidad.

En 1994, se determina la revisión de la norma ISO/IEC 9126 debido a quese estaban desarrollando normas internacionales en el área de evaluación de lacalidad de productos. Resultado de la revisión, se producen dos series de normas;ISO/IEC 9126 referida al modelo de calidad del producto software y la ISO/IEC14598 referida a la evaluación de la calidad del producto. La publicación completade ambas series, se iniciaron en julio de 1998 y concluyeron en abril de 2004,habiéndose elaborado 4 normas en las serie 9126 y 6 normas en la serie 14598.

Una nueva propuesta de calidad de producto se plantea en 1999 y seaprueba en el 2000. La propuesta se denomina proyecto SquaRE (Softwareproduct Quality REquirements) con la idea de proponer un nuevo marco dereferencia para el tema de calidad de producto software, pero esta vezorientándose a ver la calidad del producto como resultado de un proceso. La seriede normas internacionales tendrán la numeración 25000 y aún no esta completa.

Cada una de estas normas está dividida en características ysubcaracterísticas internas, externas y de usabilidad que hacen posible definir lasmétricas asociadas a cada una de estas y el tipo de pruebas que se deben llevar acabo en la evaluación de software.


70

4.1 LECCIÓN 1: LA CALIDAD DEL SOFTWARE

El software es un componente presente en una gran cantidad deactividades y su correcta operación es a menudo crítica para el éxito del negocioy/o la seguridad de las personas. El desarrollo o selección de productos softwarede gran calidad es, por tanto, de suma importancia. Una especificación yevaluación detallada de la calidad del producto software es un factor clave paraasegurar la calidad adecuada. Esto se puede lograr definiendo de maneraapropiada las características de la calidad y teniendo en cuenta el propósito deluso del producto software. Es importante que cada caracteristica relevante de lacalidad del producto software sea especificada y evaluada utilizando métricasvalidadas o de amplia aceptación.

En la norma ISO/IEC 14598 se define al modelo de calidad como unconjunto de características y la relación entre las mismas, que conforman la basepara especificar requerimientos de calidad y evaluar la calidad, en la siguientefigura se muestra un modelo de calidad de dos niveles para las características ysubcaracterísticas y en el tercer nivel presenta las métricas; estas últimas sepueden obtener de la medición de los diversos atributos que tiene el producto yque influyen en cada subcaracterística.

Figura 8: Esquema general de un modelo de calidad del software

Garvin presenta un enfoque interesante y muy influyente, con cinco visionesde la calidad: La visión trascendental que puede ser reconocida pero no definida,la visión del usuario como la adecuación al propósito del usuario, la visión delproductor como conformidad con la especificación, la visión del producto basadaen las características observables del producto, y la visión basada en el valor queel cliente esta dispuesto a pagar por ella.

El modelo ISO/IEC 9126 presenta el concepto de calidad en uso, lacalidad externa y la calidad interna que corresponden con la visión delusuario, del productor y del producto.


71

La siguiente figura representa el ciclo de vida de la calidad que muestra lainfluencia 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 dedesarrollo de software. En este gráfico también se aprecia que las necesidadesde calidad del usuario sobre el producto de software, contribuyen a especificar losrequerimientos de calidad externa y estos a su vez los requerimientos de calidadinterna. El cumplimiento de los requisitos de calidad interna se comprobarán enun proceso de verificación que permitirá medirlo, el cumpliemiento de requisitosde calidad externa se comprobarán en un proceso de validación que permitirámedirlo y finalmente la satisfacción de las necesidades de la calidad del productose comprobarán en un proceso de evaluación que permitirá medir la calidad enuso.


72

Figura 10: Calidad en el ciclo de vida del software

4.2 LECCIÓN 2: CALIDAD DEL PRODUCTO SOFTWARE – NORMA ISO/IEC9126

La norma ISO/IEC 9126 presentan dos modelos de calidad, el primeroreferido a la calidad interna y externa y el segundo modelo referido a la calidad enuso, a continuación se describe cada uno de ellos.

4.2.1 Calidad interna y externa

La norma ISO/IEC 9126 define la calidad interna como la la totalidad de lascaracterísticas del producto software desde una perspectiva interna. La calidadinterna es medida y evaluada en base a los requerimientos de calidad interna

La calidad externa se define como la totalidad de las características delproducto software desde una perspectiva externa. Es la calidad del softwarecuando es ejecutado, la cual es típicamente medida y evaluada mientras seprueba en un ambiente simulado, con datos simulados y usando métricasexternas. Durante las pruebas, muchas fallas serán descubiertas y eliminadas.Sin embargo algunas fallas todavía pueden permanecer después de las pruebas.Como es difícil corregir la arquitectura de software u otros aspectosfundamentales del diseño del software, el diseño fundamental permanece sincambios a través de las pruebas.

En la siguiente figura se representa el modelo de calidad interna o externa,se muestra un conjunto de seis características: funcionalidad, fiabilidad,usabilidad, eficiencia, facilidad de mantenimiento y portabilidad.


73

Figura 11: Modelo de calidad interna y externa del producto software

En la siguiente tabla se muestra las seis características y las definicionesde cada una de ellas.

Característica DefiniciónFuncionalidad Capacidad del producto software para proveer las funciones que

satisfacen las necesidades explícitas e implícitas cuando el software seutiliza bajo condiciones específicas.

Fiabilidad Capacidad del producto software para mantener un nivel especificado defuncionamiento cuando se está utilizando bajo condiciones específicadas

Usabilidad Capacidad del producto software de ser entendido, aprendido usado yatractivo al usuario, cuando es usado bajo las condiciones especificadas

Eficiencia Capacidad del producto software para proveer un desempeño apropiado,de acuerdo a la cantidad de recursos utilizados y bajo las condicionesplanteadas

Facilidad demantenimiento

Capacidad del producto software para ser modificado. Las modificacionespueden incluir correcciones, mejoras o adaptación del software acambios en el entorno, en requerimientos y especificaciones funcionales

Portabilidad Capacidad del producto software de ser trasladado de un entorno a otro

Tabla 17: Características de la calidad interna y externa ISO/IEC 9126.

4.2.2 Calidad en uso

La norma ISO/IEC 9126 define la calidad en uso como la perspectiva delusuario de la calidad del producto software cuando éste es usado en un ambienteespecífico y un contexto de uso específico. Éste mide la extensión para la cual los


74

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

Figura 12: Modelo de calidad del producto software para la calidad en uso.

La definición de cada una de las características de la calidad en uso semuestra en la siguiente tabla:

Carcaterística DefiniciónEfectividad La capacidad del producto software para permitir a los usuarios lograr las

metas especificadas con precisión y completitud en un contexto de usoespecífico

Productividad La capacidad del producto software para permitir a los usuarios emplearcantidades apropiadas de recursos en relación a la efectividad lograda enun contexto de uso específico

Integridad La capacidad del producto software para lograr niveles aceptables deriesgo de daño a las personas, negocio, software, propiedad o entorno enun contexto de uso específico

Satisfacción La capacidad del producto software para satisfacer a los usuarios en uncontexto de uso específico

Tabla 18: Características de la calidad en uso ISO/IEC 9126

Las métricas de calidad del producto se aplican a los diversos atributos delproducto y permiten determinar posteriormente los niveles de calidad del producto.Las métricas que se pueden aplicar de acuerdo a los atributos están definidas enlas 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 lacalidad en uso. En todos los casos, las normas señalan que las métricaspresentadas no pretenden ser exhaustivas y completas, ni limita la posibilidad deusar otras métricas de acuerdo a las necesidades del usuario.

Las métricas internas pueden ser aplicadas durante el diseño y lacodificación del producto software no ejecutable y proporciona a todos losinvolucrados el beneficio de conocer la calidad del producto duracte su


75

construcción y tomar decisiones sobre esa base para conseguir el producto con lacalidad esperada.

Las métricas externas pueden ser aplicadas durante la prueba y operacióndel producto software ejecutable y proporciona a todos los involucrados elbeneficio de conocer la calidad del producto software durante las pruebas uoperación y saber si cumple con la calidad esperada.

Las métricas de calidad en uso miden el nivel en que un producto softwarecumple con las necesidades específicas de los usuarios en un contexto de usodeterminado por los escenarios en los que el usuario realiza sus tareas.

4.3 LECCIÓN 3: CALIDAD DEL PRODUCTO SOFTWARE – NORMA ISO/IEC14598

El estandar ISO/IEC 14598 es actualmente usado como base metodológicapara la evaluación del producto software. Los productos de software son solo unaparte de la historia, también es necesario considerar mediciones en el procesoempleado para diseñar, desarrollar, probar, y controlar el producto. En esto juegaun papel importante la ISO/IEC 14598 que ofrece una visión general, explica larelación entre su serie y el modelo de calidad de la ISO/IEC 9126, define lostérminos técnicos utilizados, contiene requisitos generales para la especificación yevaluación de la calidad del software, y clarifica los conceptos generales. Ademásprovee un marco de trabajo para evaluar la calidad de todos los tipos de productossoftware y establece requisitos para los métodos de medición y evaluación de losproductos de software.

Es importante señalar que, la serie de normas ISO/IEC 14598 proporcionaun marco de trabajo para evaluar la calidad de todos los tipos de productos desoftware e indica los requisitos para los métodos de medición y para el proceso deevaluación. La norma ISO/IEC 14598 consta de seis partes que describen losrequisitos del proceso de evaluación en tres situaciones diferentes: Requisitospara desarrolladores (parte 3), Requisitos para compradores (parte 4), Requisitospara evaluadores (parte 5).


76

Figura 13: Norma ISO/IEC 14598

4.3.1 ISO/IEC 14598 – Parte 1: Visión General

Básicamente provee una visión general de las otras cinco partes y explica larelación entre la evaluación del producto software y el modelo de calidad definidoen la ISO/IEC 9126. Adicionalmente, hace la presentación del proceso deevaluación desglosado en los siguientes pasos: Establecer los requerimientos deevaluación, especificar la evaluación, planear la evaluación, Ejecutar laevaluación.

4.3.2 ISO/IEC 14598 – Parte 2: Planificación y Gestión

Esta parte contiene los requerimientos y las guías para las funciones desoporte tales como el planeamiento y gestión para la evaluación del producto delsoftware. Fundamentalmente, en esta parte, se planifican las mediciones y lasactividades de evaluación, específicamente se incluye: Preparación de laspolíticas, definición de objetivos organizacionales y de mejora, identificación de latecnología, asignación de responsabilidades, Identificación e implementación detécnicas de evaluación para software desarrollado y adquirido, entrenamiento entecnología, recopilación de datos y herramientas, comparación y administración demejoras dentro de la organización.

4.3.3 ISO/IEC 14598 – Parte 3. El Proceso para desarrolladores

Esta parte provee los requerimientos y las recomendaciones para laevaluación del producto software cuando la evaluación es conducida en paralelo


77

con el desarrollo y llevada a cabo por el desarrollador. Se enfoca en el uso deindicadores que pueden predecir la calidad final del producto midiendo losproductos intermedios que se desarrollan durante el ciclo de vida. Esta parte cubreel planeamiento y evaluación de mediciones internas y externas con el fin deasegurar de que la calidad del producto sea incorporada en la fase de desarrollo.Una vez identificadas las características fundamentales de calidad y el marco detrabajo, deben ser definidas las etapas siguientes:

4.3.3.1 Organización: Los aspectos organizacionales de desarrollo y de soportedeben 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 yel ciclo de vida de soporte deben ser establecidos y documentados durante el plande calidad o en otros documentos. Es de vital importancia verificar que elproductor y las medidas de control requeridas sean técnicamente factibles,razonables y alcanzables.

4.3.3.3 Especificaciones: Esta es la fase, el desarrollador realiza un mapeo delos requerimientos internos y externos de calidad, con relación a lasespecificaciones. Los requerimientos de mediciones resultantes de esta fasedeben ser un tipo de mapeo entre las especificaciones de requerimientos,requerimientos externos de calidad, requerimientos internos correspondientes decalidad y atributos especificados junto a sus escalas de medición y valoresobjetivos que contribuyan a la cuantificación de la calidad del software, todo estopuede enfocarse por proyecto o por producto.

4.3.3.4 Diseño y planeamiento: Los procedimientos requeridos para el análisis yrecopilación de datos necesitan ser definidos. De esta manera, el plan incluirá:Cronogramas, asignación de responsabilidades, uso de herramientas, bases dedatos y entrenamiento especializado requerido. La precisión de las mediciones ytécnicas estadísticas deben ser especificadas. En esta fase también deberáconsideerarse como los resultados de las mediciones impactarán en el desarrolloy los planes de contingencia y de mejora.

4.3.3.5 Montaje y pruebas: durante la etapa de montaje y pruebas, lasmediciones actuales son recolectadas, se realizan análisis apropiados y se tomanacciones necesarias. En cada fase del desarrollo debe procurarse lograr unmontaje primeramente enfocado a las características internas y externas decalidad que definan la calidad global del producto y que puedan ser validades porlos resultados de las pruebas y la experiencia del usuario.

Y como etapa final del proyecto, deberá ser conducida una revisión generalpara determinar la efectividad global del ejercicio de recolección, para identificarcostos versus costos, establecer la validez de las métricas usadas e identificarpuntos en los cuales podrían obtenerse beneficios para proyectos futuros. Elresultado de esta revisión podría retroalimentar directamente el lanzamiento defuturos productos.


78

4.3.4 ISO/IEC 14598 – Parte 4. El proceso para compradores

Esta parte provee los requerimientos y las recomendaciones para que laevaluación del producto software sea conducida en función a los compradores queplanean adquirir o re-usar un producto de software existente o pre-desarrollado.Los que adquieren el producto pueden comprar paquetes completos ya seadesarrollados según ciertas especificaciones o pre-desarrollados para un mercadomás general. Los compradores también podrían ser desarrolladores que deseanintegrar productos estándar en sus propios diseños de software, o dedesarrolladores buscando herramientas específicas de software. Al respecto,cuatro etapas son necesarias:

Establecimiento de los requerimientos: El alcance de la evaluación necesita serestablecido. Los requerimientos para la calidad delsoftware definidos en laISO/IEC 9126 pueden ser usados como punto de partida pero otros aspectoscomo el costo y el de cumplimiento a regulaciones deberán ser tambiénconsiderados. El tiempo de la evaluación necesita ser consistente con losobjetivos; enfoques muy tempranos podrían no proporcionar una figura adecuadade la situación mientras que enfoques muy tardíos podrían ser muy limitados en suuso.

4.3.4.1 Especificación de la Evaluación: Durante la redacción de lasespecificaciones, debe considerarse: Los requerimientos de calidad a serevaluados correlacionados con la calidad en uso y métricas externas conprioridades además de un umbral de aceptación definido, el alcance y lo quecubren los casos de prueba donde sean aplicables referencias a módulos deevaluación, los métodos de recolección de mediciones, información requerida ymétodos de análisis.

4.3.4.2 Diseño de la Evaluación: El tipo de evaluación depende del tipo desoftware que está siendo evaluado. Software bajo desarrollo puede ser abordadoen puntos discretos durante el desarrollo o cuando estécompleto. Un plan deevaluación necesita considerar: Necesidades de acceso a la documentación delproducto, herramientas de desarrollo y personal, requerimientos en costos yconocimientos, cronograma de evaluación y arreglos de contingencia, y criteriopara decisiones de evaluación, métodos y herramientas de reporte,procedimientos para la validación y estandarización sobre proyectos futuros.

4.3.4.3 Ejecución de la Evaluación: Aunque esta etapa podría ser simplementeun registro en un libro de seguimiento, podría tenerse la necesidad de incluir: Losresultados mismos y la trazabilidad del producto así como información deconfiguración, registros de análisis, resultados y decisiones, problemas,limitaciones en las mediciones y cualquier compromiso con relación a los objetivosoriginales, conclusiones sobre los resultados de la evaluación pero también sobrelos métodos empleados.


79

4.3.5 ISO/IEC 14598 - Parte 5: El Proceso para Evaluadores

Esta parte provee los requerimientos y recomendaciones para la evaluación delproducto software cuando la evaluación es conducida por evaluadoresindependientes. En esta parte tiene un rol importante los requerimientos deevaluación, las especificaciones de evaluación,el diseño de la evaluación, lasactividades de evaluación y el reporte de evaluación.Estas etapas son resumidasa continuación:

4.3.5.1 Requerimientos de Evaluación: Los requerimientos deberíanadicionalmente definir: La extensión del la cobertura (o el alcance), los objetivosde evaluación y métodos de reporte, las calificaciones e independencia requeridasde un evaluador.

4.3.5.2 Especificación de la Evaluación: Las especificaciones adicionalmentedeberían cubrir: Definición del alcance y formato en las métricas empleadasidentificando como deberán ser derivadas a partir de los requerimientos delproducto, la identificación de mediciones no determinísticas para asegurar queciertos niveles de frecuentabilidad y objetividad requeridos sean obtenidos, laidentificación de métodos de correlación con relación a los resultados de lasmediciones.

Se tienen identificadas tres sub-actividades con relación a la especificaciónde la evaluación: El análisis de la descripción del producto, la especificación de lasmediciones a ser realizadas, la verificación de la especificación resultante frente alos requerimientos de evaluación.

4.3.6 ISO/IEC 14598 - Parte 6: Documentación de los Módulos de Evaluación

Esta parte provee las guías para la documentación del módulo deevaluación. Estos módulos representan la especificación del modelo de calidad ylas correspondientes métricas internas y externas que serán aplicadas a unaevaluación en particular. Incluye métodos y técnicas de evaluación más lasmediciones actuales resultantes de su aplicación. En esta parte tambiénseconsidera la administración efectiva de complejidades inherentes a las cuestionesde medición.

Las actividades de medición coordinadas son una característica para unaevaluación efectiva y un plan necesita proveer un cronograma de evaluación queprovea al mismo tiempo información óptima cuando la evaluación sea conducidadurante el desarrollo. Los módulos de la evaluación son componentes claves de laISO/IEC 14598-6 y son usados para proveer un formato consistente y repetible dereporte.Dichos módulos proveen: Visibilidad de la información necesitada paracuadrar con requerimientos específicos de calidad, Documentación de lasinterfaces necesarias con herramientas de medición.


80

4.4 LECCIÓN 4: CALIDAD DEL PRODUCTO SOFTWARE – NORMA ISO/IEC25000 (SquaRE)

Desde el año 2000 se viene trabajando el proyecto SquaRE que pretendeestablecer un modelo para la especificación y evaluación de un producto software,lo que ha llevado a reordenar la actual distribución de normas internacionalesISO/IEC 9126 e ISO/IEC 14598 y considerando otras normas desarrolladas hastala fecha. En la siguiente figura se puede apreciar la nueva arquitectura de la seriede normas 25000.

Figura 14: Arquitectura de la serie de normas ISO/IEC 25000

ISO 25000:2005 (SQuaRE -Software Quality Requirements and Evaluation)es una nueva serie de normas que se basa en ISO 9126 y en ISO 14598(Evaluación del software). Uno de los principales objetivos de la serie SQuaRE esla coordinación y harmonización del contenido de ISO 9126 y de ISO 15939:2002(Measurement Information Model). ISO 15939 tiene un modelo de información queayuda a determinar que se debe especificar durante la planificación, performancey evaluación de la medición. Para su aplicación, cuenta con los siguientes pasos:Recopilar los datos, Preparación de los datos y Análisis de los datos.

La integración de ISO 9126 e ISO 15939 permiten plantear un proceso de 4pasos: El primero, la identificación de los requerimientos relacionados a la calidaddel producto, es decir, seleccionar la parte del modelo de calidad (ISO/IEC 9126-n)que resulta relevante para la evaluación de calidad, el segundo, la identificacióndel contexto de interpretación. Es decir, selección de los valores de referencia ydeterminación de los target especificados en un contexto determinado, tercero,uso de las medidas derivadas de la etapa de preparación de los datos, y el cuarto,comparación y análisis de los resultados obtenidos respecto de un conjunto devalores de referencia.


81

SQuaRE incluye un estándar de requerimientos de calidad. Está compuestopor 14 documentos agrupados en 5 tópicos: Administración de la Calidad – 2500n,Modelo de Calidad – 2501n, Medidas de Calidad – 2502n, Requerimientos deCalidad – 2503n y Evaluación de la Calidad – 2504n.

Administración de la Calidad: Abarca la Guía para SquaRE y Planificación yAdministración.

Modelo de Calidad: Describe el modelo de calidad interno / externo y la calidaden uso y presenta características y subcaracterísticas.

Medidas de Calidad: Medición de primitivas, Medidas para la calidad interna,Medidas para la calidad externa y Medidas para la calidad en uso.

Requerimientos de Calidad: Permite habilitar la calidad del software a serespecificado en términos de requerimientos de calidad durante todo el ciclo devida de un proyecto de software o adquisición, mantenimiento y operación.

Evaluación de la Calidad: Evaluación de la Calidad, Proceso paradesarrolladores, Proceso para compradores, Proceso para evaluadores yDocumentación del módulo de evaluación.

En la figura siguiente se puede apreciar el modelo de referencia SquaRE,de la cual hay una reestructuración de los contenidos, se alinea a otrosdocumentos existentes, y se amplian aspectos que las normas anteriores sólo seseñala a manera de información.

Figura 15: Modelo de referencia para la arquitectura Square


82

LECCIÓN 5: MODELOS DE MEJORA DE PROCESOS DE SOFTWARE

La mejora de proceso software es un mecanismo de mejora continua de lacalidad, el cual básicamente consiste en aplicar de forma consistente las prácticasque proporcionan buenos resultados y eliminar o cambiar aquellas prácticas quecausan problemas. Para aplicar la mejora de proceso software, es necesario tenerclaro tres aspectos fundamentales: Selección del modelo de mejora del proceso autilizar, Selección del modelo de proceso a utilizar como referencia, Selección delmétodo a utilizar en la etapa de evaluación.

A continuación se indican de forma breve cómo han ido surgiendo losdiferentes modelos de mejora continua del proceso software, así como losdiferentes métodos de evaluación en el mundo.

5.1 Estados Unidos

En noviembre de 1986, el Instituto de Ingeniería del Software (SoftwareEngineering Institute, SEI) de Pittsburgh, ante la demanda por parte delDepartamento 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. Enseptiembre de 1987, el SEI publicó el primer borrador del modelo de madurez delproceso software y un cuestionario asociado con respuestas del tipo “si” o “no” queno recogen diferentes niveles de cumplimiento sobre los aspectos tratados.

Este modelo y el cuestionario culminaron en agosto de 1991 en la versión1.0 del Modelo de Madurez de Capacidad para el Software (Capahility MaturityModel, CMM). Utilizando este modelo como base, el SEI comercializó dosmétodos para determinar la madurez del proceso software de una empresa:Evaluación del Proceso Software y Valoración de la Capacidad Software.

La versión 1.1 del CMM publicó en febrero de 1993 junto con laactualización del método SCE (v.2.0) para que estuviese alineado con la versión1.1 del CMM. Muchas empresas han modificado el método SPA para alinearlo conla versión 1.1 del CMM; una de estas empresas ha sido el Instituto para la Mejoradel Proceso Software que ha propuesto el método de Evaluación Enfocado en laAcción. En mayo de 1995, el SEI actualizó el SPA, denominándose método deEvaluación basada en el CMM para la Mejora Interna del Proceso v.1.0 (CMM-Based Appraisal for Internal Process Improvemnent, CBA IPI). Se generaronnuevas versiones más consistentes del CBA IPI y de SCE en abril de 1996 dondese utilizan aproximaciones comunes para interpretar el CMM y para recoger yanalizar los datos. Actualmente, se encuentra disponible el CMMI, que recogeaspectos tanto del CMM como de ISO/IEC 15504.


83

5.2 Unión Europea

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

5.3 ISO/IEC

Durante 1990-91, el DTI del Reino Unido patrocinó un estudio deinvestigación, denominado ImprovelT, para analizar los métodos de evaluación yvalorar la capacidad de ingeniería del software de los contratistas potenciales.Este estudio descubrió que existían numerosos métodos de evaluación queestaban en uso o bajo desarrollo. También identificó un apoyo muy extendido porparte de las empresas al desarrollo de un método común de dominio público y,preferiblemente, respaldado por un estándar internacional.

Así, en junio de 1991, el grupo de Estándares Internacionales para laIngeniería del Software aprobó un período de estudio con base de ImprovelT, parainvestigar la necesidad y las características de un estándar de evaluación delproceso software. El informe del estudio indicaba que existía un consensointernacional sobre la necesidad y los requisitos de un estándar de evaluación delproceso software. En junio de 1992 se estableció un nuevo grupo de trabajo paradesarrollar este estándar internacional que, en enero de 1993, lanzó el proyectodenominado Mejora del Proceso Software y Determinación de la Capacidad paradesarrollar un estándar internacional de evaluación y mejora del proceso software.El proyecto toma como base las mejores características de los siguientes métodosy/o modelos de evaluación: CMM, TRILLIUM, Software Technology Diagnostic(STD) y Bootstrap. El conjunto de los borradores de SPICE se publicaron comoinformes técnicos durante 1995; posteriormente le ha seguido un período deprueba que aún no ha finalizado. De hecho, se dice que actualmente se encuentraen fase de pruebas y sólo en el entorno de grandes empresas, sin existir todavíaexperimentación comercial con el método. Finalmente, en 1998 se convirtió en elestándar internacional ISO/IEC 15504 versión 3.3 de evaluación del procesosoftware.


84

Actualmente, las dos líneas, CMM e ISO 15504, han confluido en lo que seha denominado CMMI (capability Maturity Model integration). CMMI contemplaambas visiones mediante su representación continua (perspectiva ISO) [CMMI,2001a] y por etapas (perspectiva CMM) [CMMI, 2001b]. También se incluye unmétodo de evaluación denominado SCAMPI [SCAMPI, 2001].

Los principales modelos de mejora del proceso software son:

5.4 Modelo IDEAL

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

5.5 ISO/IEC TR 1550 Parte 7

Guía para utilización en la mejora del proceso [ISO, l998]. La mejora delproceso software se considera, igualmente, como un proceso continuo, donde unaempresa se mueve continuamente alrededor de un ciclo de mejora.

5.6 Modelo de mejora del proceso software desarrollado por ISPI (Institutefor Software Process Improvement)

A continuación, se describen brevemente cada una de las etapas delmodelo de mejora: Compromiso a la mejora del proceso software por parte de laAlta Dirección para que se involucre en el proyecto de mejora, Evaluación delproceso software para determinar cuál es el estado actual del proceso software dela compañía, es decir sus puntos fuertes y débiles, con objeto de determinar losprocesos que se van a mejorar, Infraestructura y planes para la mejora delproceso software para crear la estructura necesaria de mejora del proceso,Implantación de la mejora del proceso software para realizar las actividadesdefinidas previamente en el plan.

Los dos modelos de proceso utilizados habitualmente en la etapa deevaluación son el Modelo de Madurez de la Capacidad (CMM) y la parte 2 delestándar ISO 15504. Como se ha indicado anteriormente, el modelo de procesosse utiliza en la etapa de evaluación con objeto de conocer cómo está el propioproceso software de la empresa con respecto a dicho modelo.


85

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


86

CAPITULO 5

MÉTRICAS DE CALIDAD DELSOFTWARE


87

INTRODUCCIÓN

Los términos de métricas, medición, y medida en muchos de los casos han sidorelacionados con los instrumentos utilizados mediante un método específico alacto mecánico de tomar una medición mediante escalas cualitativas ocuantitativas que determinan los valores de esa medición.

En general es así, pero los tres conceptos son diferentes, y serán tratados en estecapítulo. Pero lo que no se puede admitir es que sea un acto mecánico ya que elproceso de medición involucra muchas actividades, inicia con la selección ydefinición de la característica que se quiere medir, posteriormente se definirá quemétricas es posible usar para la medición, luego se definirá la escala de tipocuantitativo o cualitativo y el método, y por último se procede a hacer al análisis decómo se hara la medición.

En este capítulo se tratará estos temas tan importantes para el proceso yprocedimiento de la evaluación de software, que se convertirán en la clave pararealizarla, ya que, de ella depende el éxito o fracaso de la evaluación.


88

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

La palabra métrica, es muy común asociarla con las palabras medición ymedida, aunque estas tres son distintas. La medición es el proceso por el cual losnúmeros o símbolos son asignados a atributos o entidades en el mundo real talcomo son descritos de acuerdo a reglas claramente definidas. La medidaproporciona una indicación cuantitativa de la extensión, cantidad, dimensiones,capacidad o tamaño de algunos atributos de un proceso o producto. Métrica sedefine como una medida cuantitativa del grado en que un sistema, componente oproceso posee un atributo dado o también una medida cuantitativa del grado enque el sistema, componente o proceso posee un atributo dado.

Un Indicador es la métrica o una combinación de métricas que proporcionanuna visión profunda del proceso del software, del proyecto software o del productoen sí. Un indicador proporciona una visión profunda que permite ajustar elproducto, el proyecto o el proceso. El objetivo principal de los indicadores deproceso es evaluar las condiciones de funcionamiento de un proceso y poder teneruna visión de la eficacia de un proceso existente. Durante un tiempo considerablese recopilan las métricas de todos los proyectos y se proporcionan indicadorespara obtener mejoras en el software.

Los métodos de medición o cálculo son unas secuencias lógicas deoperaciones y potenciales heurísticas, expresadas de forma genérica, que permitela realización de una descripción de actividad. El tipo de método de medición va adepender de la naturaleza de las operaciones utilizadas para cuantificar el atributo.Pueden distinguirse dos tipos: Subjetivo, cuando la cuantificación supone un juiciorealizado por un ser humano, y Objetivo, cuando la cuantificación está basada enmétodos numéricos.

Una escala es un conjunto de valores con propiedades definidas. Lasescalas pueden ser escalas numéricas (Continua o Discreta) o escala Categórica.Los tipos de escala pueden ser: Nominal, Ordinal, Intervalo, entre otras.

En este sentido la métrica es la correspondencia de un dominio real oempírico a un mundo formal, matemático. La medida incluye al valor numérico onominal asignado al atributo de un ente por medio de dicha correspondencia. Lasmétricas peden ser de tipo directo cuando no dependen de ninguna métrica deotro atributo e indirecta cuando se deriva de una o más métricas de otros atributos.

Algunos ejemplos de Métricas Directas son: Longitud del Texto del Cuerpode una Página (medido por cantidad de palabras), Cantidad de Enlaces RotosInternos (medidos por la presencia de errores del tipo 404), Cantidad de Imágenescon Texto Alternativo (medido por la presencia de la etiqueta ALT o con texto nonulo, en cada una de las imágenes vinculadas a las páginas de un sitio Web).

Algunos ejemplos de Métricas Indirectas son: Porcentaje de Enlaces Rotosde un Sitio, Porcentaje de Presencia de la propiedad ALT.


89

Ahora se estudirá brevemente el amplio campo de las métricas delsoftware, ya que es la técnica que junto a revisiones, pruebas y gestión deconfiguración constituye el conjunto principal de medios operativos para elaseguramiento de la calidad en el proyecto.

En general, para la evaluación de la calidad es más habitual centrarse enmedidas del producto que en medidas de procesos, aunque estas últimas puedenser útiles para medir ciertos aspectos como la fiabilidad, se mide el tiempo medioentre fallos de software a lo largo de algún período de prueba, etc. Para mejorarcualquier proceso se debe medir atributos del proceso, definir y desarrollar unjuego de métricas para esos atributos, y utilizar las métricas para encontrarindicadores para la estrategia de mejora.

Figura 16: Métricas del Proceso y Mejoras en el Proceso de Software

La eficacia de un proceso de software se mide a través de un juego demétricas según los resultados que provienen del proceso. Dentro de estosresultados se debe incluir: Medida de los errores detectados antes de la entregadel software, defectos detectados, productos de trabajo entregados, esfuerzohumano y tiempo consumido y ajuste con la planificación.

También se debe incluir métricas para medir las características de tareasespecíficas de la ingeniería del software, como la medida del tiempo y del esfuerzopara llevar a cabo actividades de protección, actividades genéricas de ingenieríade software.

Para una organización es importante estar a gusto con la recopilación y lautilización de métricas de proceso, de éstas se deriva la identificación de


90

indicadores llevando a un enfoque más riguroso denominado Mejora estadísticadel proceso de software (MEPS). Este enfoque utiliza el análisis de fallas delsoftware para recopilar información de errores y defectos. Para realizar un análisisde fallas se debe seguir los siguientes pasos: Categorizar por origen de todos loserrores y defectos, Registrar el costo de corregir cada error o el del defecto,Contar el número de errores y de defectos de cada categoría, calcular el costoglobal de errores y defectos de cada categoría, para posteriormente, desarrollarplanes para eliminar los errores y defectos más costosos.

Para determinar las principales causas que pueden ocasionar defectos enel software y con base en ello extraer los indicadores que permitan a unaorganización de software modificar su proceso para reducir la frecuencia deerrores y defectos se utiliza el diagrama de espina. En el diagrama de espina, lalínea central, representa el factor de calidad o el problema en consideración. Laslíneas diagonales conectadas a la línea central indican una causa potencial delproblema de calidad.

Figura 17: Análisis de Problemas y causas de calidad del software

Por ejemplo, en la siguiente tabla se muestra las causas y su origen defallas en un proyecto de software:

Origen de errores odefectos

Causa %

Lógica 20Manejo de datos 10.9

Especificación de requisitos

estándares 6.9Diseño Especificaciones 25.5

Interfaz de software 6.0Interfaz de Hardware 7.7Comprobación de errores 10.9

Código

Interfaz de usuario 11.7

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


91

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

Figura 18: Identificación de causas de errores o defectos en un software

Las métricas del Proyecto se utilizan para minimizar la planificación dedesarrollo, ya que realizan ajustes y minimizan los retrazos. Además se utilizanpara evaluar la calidad de los productos. A medida que mejora la calidad seminimizan los defectos. Las métricas del proyecto de software sugiere que losproyectos deben medir: Las entradas, la dimensión de los recursos que serequieren para realizar el trabajo, las salidas, medidas de las entradas o productoscreados durante el proceso de ingeniería de software, y resultados, medidas queindican la efectividad de las entregas.

5.2 LECCIÓN 2: MÉTRICAS DEL SOFTWARE

Las métricas del software se pueden categorizar en:

5.2.1 Medidas Directas: Dentro de estas se pueden incluir: el costo y el esfuerzoaplicado, Las líneas de código producidas (LCD), La velocidad reejecución, Eltamaño de la memoria y los defectos informados durante un periodo de tiempoestablecido.

5.2.2 Métricas Indirectas: Dentro de estas están la funcionalidad, La calidad, Lacomplejidad, La eficiencia, la Fiabilidad, La facilidad de uso y La facilidad demantenimiento.

5.2.3 Métricas orientadas al tamaño: Provienen de la normalización de lasmedidas de calidad y/o productividad considerando el tamaño del software que sehaya producido, los datos registrados se muestran en la siguiente tabla:


92

Proyecto LCD Esfuerzo Costo $ Páginas dedocumentación

Errores Defectos Personas

IRIS 18.200 24 200000 945 134 86 4

Tabla 20: Tabla de registro de datos de métricas orientadas al tamaño

Teniendo en cuenta los datos de la tabla anterior, se puede derivar otrasmétricas para comparar varios proyectos. Por ejemplo: Errores por KLDC (milesde líneas de código), Defectos por KLDC, Páginas de documentación por KLDC,Errores por persona/mes, LDC por persona/mes, Costo ($) por página dedocumentación

5.3.4 Métricas orientadas a la función: Las métricas del software orientadas ala función permiten la medida de la funcionalidad de la aplicación. Esta métrica fuepropuesta busca identificar los factores críticos que determinan el tamaño delsoftware y por consiguiente, estimar el esfuerzo y el costo para desarrollarlo. Deaquí nace la técnica de análisis de puntos de función, que mide una aplicación conbase en las funciones que éste realiza por solicitud del usuario final.

Los puntos de función se obtienen utilizando una función empírica basadoen medidas cuantitativas del dominio de información del software y valoracionessubjetivas de la complejidad del software. Los puntos de función se calculanutilizando la siguiente tabla:

Factor de ponderaciónParámetrosde medición

CuentaSimple Medio Complejo

Número deentradas deusuario

X 3 4 6 =

Número desalidas deusuario

X 4 5 7 =

Número depeticiones deusuario

X 3 4 6 =

Número dearchivos

X 7 10 15 =

Número deinterfacesexternas

X 5 7 10 =

Costo_total

Tabla 21: Tabla de cálculo de puntos de función

Se determinan 5 características del ámbito de la información y los cálculosaparecen en la posición apropiada en la tabla. Los valores del ámbito deinformación están definidos de la siguiente forma:


93

Caracteríatica DefiniciónNúmero de entradas de usuario Se cuenta cada entrada de usuario que proporcione

al software diferentes datos orientados a laaplicación

Número de salidas de usuario Se cuenta cada salida que proporciona al usuarioinformación orientada a la aplicación. En estecontexto las salidas se refieren a informes, pantallas,mensajes de error

Número de peticiones de usuario Una petición esta definida como una entradainteractiva que resulta de la generación de algún tipode respuesta en forma de salida interactiva. Secuenta cada petición por separado

Número de archivos Se cuenta cada archivo maestro lógicoNúmero de interfaces externas Se cuentan todas las interfaces legibles por la

máquina por ejemplo: archivos de datos, en cinta odiscos que son utilizados para transmitir informacióna otro sistema.

Tabla 22: Características y definición de puntos de función (a)

Cuando han sido recogidos los datos anteriores, se asocia el valor decomplejidad a cada cuenta. Las organizaciones que utilizan métodos de puntosde función desarrollan criterios para determinar si una entrada es denominadasimple, media o compleja. No obstante la determinación dela complejidad es algosubjetivo.

PF = Cuenta_total * [0.65 + 0.01* sumatoria (fi)]

PF Punto de funciónCuenta_total Es la suma de todas las entradas obtenidasfi Donde i=1 hasta 14. son los valores de ajuste de la complejidad basados en las

respuestas a las cuestiones señaladas de la siguiente tabla:

Evaluar cada factor de 0 a 5

0 1 2 3 4 5Noinfluencia

Incidental Moderado Medio Significativo Esencial

Fi :1 ¿Requiere el sistema copias de seguridad y de recuperación

fiable?2 ¿Se requiere comunicación de datos?3 ¿Existen funciones de procesamiento distribuido?4 ¿Es crítico el rendimiento?5 ¿Se jecutará el sistema en un entorno operativo existente y

fuertemente utilizado?6 ¿Requiere el sistema entrada de datos interactivo?7 ¿Requiere la entrada de datos interactiva que las transacciones de

entrada se lleven a cabo sobre múltiples pantallas u operaciones?8 ¿Se actualizan los archivos maestros de forma interactiva?


94

9 ¿Son complejas las entradas, las salidas, los archivos o laspeticiones?

10 ¿Es complejo el procesamiento interno?11 ¿Se ha diseñado el código para ser reutilizable?12 ¿Están incluidas en el diseño la conversión y la instalación?13 ¿Se ha diseñado el sistema para soportar múltiples instalaciones

en diferentes organizaciones?14 ¿Se ha diseñado la aplicación para facilitar los cambios y para ser

fácilmente utilizada por el usuario?

Tabla 23: Características y definición de puntos de función (b)

Una vez calculados los puntos de función se usan como medida de laproductividad, calidad y otros productos del software.

Productividad= PF/persona-mesCalidad= Errores/ PFCosto= Pesos/PFDocumentación= Páginas_documentadas/ PF

5.3 LECCION 3: MÉTRICAS DE CALIDAD DEL SOFTWARE

El objetivo de la Ingeniería de Software es desarrollar y producir software de altacalidad y para lograrlo es fundamental aplicar métodos y herramientas efectivosdentro del contexto de un proceso de desarrollo de software. Dentro de lasmedidas de calidad del software están:

5.3.1 Corrección: Es el grado en el que el software cumple su función, la medidamás común es: Defectos por KDLC (miles de líneas de código)

5.3.2 Facilidad de mantenimiento: es la facilidad con la que se puede corregirun programa si se encuentra un error. Se utiliza medidas indirectas como: Tiempomedio de cambio (TCM), que es el tiempo que tarda en: Analizar una petición,Diseñar una modificación, Implementar un cambio o Probar y realizar un cambio.

5.3.3 Integridad: mide la capacidad del software para resistir ataques. Se definecomo, Integridad= Sumatoria [(1-amenaza)*(1-seguridad)], para ello se debe teneren cuenta los siguientes atributos: Amenaza que es la probabilidad de que unataque ocurra en un tiempo determinado, y la seguridad que es la probabilidad deque se pueda repeler el ataque de un tipo determinado.

5.3.4 Facilidad de Uso: Mide la amigabilidad del software con el usuario final. Semide en función de: Habilidad intelectual o física para aprender el sistema, Eltiempo requerido para hacer uso eficiente del sistema, Aumento de laproductividad y la Valoración subjetiva de la disposición de los usuarios hacia elsistema.


95

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

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

Las métricas técnicas para el software proporcionan una manera sistemática devalorar la calidad basándose en un conjunto de reglas. También proporcionan alingeniero del software descubrir y corregir problemas potenciales antes de que seconviertan en defectos catastróficos.

5.4.1 Factores de calidad de McCall

McCall y Cavano definieron un juego de factores de calidad como losprimeros pasos hacia el desarrollo de métricas de a calidad del software. Estosfactores evalúan el software desde tres puntos de vista distintos: Operación delproducto, Revisión del producto y Transición del producto. A continuación semuestran los factores de calidad de McCall, las características asociadas y ladefinición de cada una de ellas:

1. Operaciones del producto - Características operativasCorrección: ¿Hace lo que sele pide?

El grado en que una aplicación satisface sus especificacionesy consigue los objetivos encomendados por el cliente.

Fiabilidad: ¿Lo hace deforma fiable todo el tiempo?

El grado que se puede esperar de una aplicación lleve a cabolas operaciones especificadas y con a precisión requerida.

Eficiencia: ¿Qué recursoshardware y softwarenecesito?

La cantidad de recursos hardware y software que necesitauna aplicación para realizar las operaciones con los tiemposde respuesta adecuados.

Integridad: ¿Puedo controlarsu uso?

El grado con que puede controlarse el acceso al software o alos datos a personal no autorizado.

Facilidad de uso: ¿Es fácil ycómodo demanejar?

El esfuerzo requerido para aprender el manejo de unaaplicación, trabajar con ella, introducir datos y conseguirresultados

2. Revisión del producto - Capacidad para soportar cambiosFacilidad de mantenimiento:¿Puedo localizar los fallos?

El esfuerzo requerido para localizar y reparar errores.

Fiexibilidad: ¿Puedo añadirnuevas opciones?

El esfuerzo requerido para modificar una aplicación enfuncionamiento.

Facilidad de prueba: ¿Puedoprobar todas las opciones?

El esfuerzo requerido para probar una aplicación de forma quecumpla con lo especificado en los requisitos.

3. Transición del producto - Adaptabilidad a nuevos entornosPortabilidad: ¿Podré usarloen otra máquina?

El esfuerzo requerido para transferir a aplicación a otrohardware o sistema operativo.

Reusabilidad: ¿Podré utilizaralguna parte del software en

Grado en que partes de una aplicación pueden utilizarse enotras aplicaciones


96

otra aplicación?Interoperabilidad: ¿Podrácomunicarse con otrasaplicaciones o sistemasinformáticos?

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

Tabla 24: Factores de calidad de McCall

5.4.2 Métricas para el esquema de puntuación

Las métricas pueden ir en forma de lista de comprobación para evaluar y puntuaratributos específicos del software. La puntución va en una escala del O (bajo) al10 (alto). Se emplean las siguientes métricas en el esquema de puntuación:

Facilidad de auditoría La facilidad con la que se puede comprobar el cumplimiento de losestándares.

Exactitud La exactitud de los cálculos y del control.Estandarización decomunicaciones

El grado de empleo de estándares de interfaces, protocolos yanchos de banda.

Complexión El grado con que se ha logrado la implementación total de unafunción.

Concisión Lo compacto que es el programa en términos de líneas de código.Consistencia El empleo de un diseño uniforme y de técnicas de documentación

a lo largo del proyecto de desarrollo del softwareEstandarización dedatos

El empleo de estructuras y tipos de datos estándares a lo largo delprograma.

Tolerancia al error El daño causado cuando un programa encuentra un error.Eficiencia de ejecución El rendimiento del funcionamiento de un programa.Capacidad deexpansión

El grado con que se pueden ampliar el diseño arquitectónico, dedatos o procedimental.

Generalidad La amplitud de aplicación potencial de los componentes delprograma.

Independencia delsoftware

El grado con que se desacopla el software del hardware dondeopera.

Instrumentación El grado con que el programa vigila su propio funcionamiento eidentifica los errores que ocurren.

Modularidad La independencia funcional de componentes de programa.Operatividad La facilidad de operación de programaSeguridad La disponibilidad de mecanismos que controlan o protegen los

programas y tos datos.Autodocumentación El grado en que el código fuente proporcionan documentación

significativaSimplicidad El grado de facilidad con que se puede entender un programa.Independencia delsistema software

El grado de independencia de programa respecto a lascaracterísticas del lenguaje de programación no estándar,características del sistema operativo y otras restricciones.

Trazabilidad La capacidad de seguir una representación del diseño o uncomponente real del programa hasta los requisitos

Formación El grado en que ayuda el software a manejar el sistema o losnuevos usuarios.

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


97

5.4.3 Métricas del modelo de Calidad FURPS

El modelo de MCCall ha servido de base para modelos de calidadposteriores, y este es el caso del modelo FURPS, producto del desarrollo deHewlett-Packard. En este modelo se desarrollan un conjunto de factores decalidad de software, bajo el acrónimo de FURPS.

F Functionality - funcionalidadR Usability – usabilidad – facilidad de usoR Realiability – confiabilidadP Performance – desempeñoS supportability-capacidad de soporte

La siguiente tabla, presenta la clasificación de los atributos de calidad quese incluyen en el modelo, junto con las características asociadas a cada uno deellos:

Factor de Calidad AtributosFuncionalidad • Características y capacidades del programa

• Generalidad de las funciones. Seguridad del sistema

Facilidad de uso • Factores humanos• Factores estéticos• Consistencia de la interfaz• Documentación

Confiabilidad • Frecuencia y severidad de las fallas• Exactitud de las salidas• Tiempo medio de fallos• Capacidad de recuperación ante fallas• Capacidad de predicción

Rendimiento • Velocidad del procesamiento• Tiempo de respuesta• Consumo de recursos• Rendimiento efectivo total• Eficacia

Capacidad de Soporte • Extensibilidad• Adaptabilidad• Capacidad de pruebas• Capacidad de confl9uración• Compatibilidad• Requisitos de instalación

Tabla 26: Métricas del modelo de Calidad FURPS

El modelo FURPS incluye, además de los factores de calidad y losatributos, restricciones de diseño y requerimientos de implementación, físicos y deinterfaz. Las restricciones de diseño especifican o restringen el diseño del sistema.Los requerimientos de implementación especifican o restringen la codíficacion oconstrucción de un sistema. Por su parte, los requerimientos de interfazespecifican el comportamiento de los elementos externos con los que el sistema


98

debe interactuar. Por último, los requerimientos físicos especifican ciertaspropiedades que el sistema debe poseer, en términos de materiales, forma, peso,tamaño.

5.4.4 Factores de calidad ISO 9126

El estándar ISO/IEC 9126 ha sido desarrollado en un intento de identificar losatributos clave de calidad para un producto de software. Este estándar es unasimplificación del Modelo de McCalI, e identifica seis características básicas decalidad que pueden estar presentes en cualquier producto de software. Elestándar provee una descomposición de las características en subcaracterísticas,que se muestran en la siguiente tabla:

Característica SubcaracterísticaFuncionalidad • Adecuación

• Exactitud• Interoperabilidad• Seguridad

Confiabilidad • Madurez• Tolerancia a fallas• Recuperabilad

Usabilidad • Entendibilidad• Capacidad de aprendizaje• Operabilidad

Eficiencia • Comportamiento en tiempo• Comportamiento de recursos

Mantenibilidad • Analizabilidad• Modificabilidad• Estabilidad• Capacidad de pruebas

Portabilidad • Adaptabilidad• Instalabilidad•.Reemplazabilidad

Tabla 27: Características y Subcaracterísticas modelo ISO/IEC 9126

Las métricas ISO / IEC 9126 no son necesariamente usados paramediciones directas, pero proveen una valiosa base para medidas indirectas, yuna excelente lista para determinar la calidad de un sistema.

5.5 LECCIÓN 5: ESTRUCTURA PARA LAS MÉTRICAS TÉCNICAS DELSOFTWARE

Es importante establecer una estructura fundamental y un conjunto deprincipios básicos para la medición de métricas técnicas para el software. Losprincipios básicos de la medición, sugeridos por Roche, pueden caracterizarsemediante cinco actividades:


99

Actividad DefiniciónFormulación Obtención de medidas y métricas del software apropiadas para la

representación de softwareColección Mecanismo empleado para acumular datos necesarios para obtener las

métricas formuladas.Análisis Cálculo de las métricas y aplicación de herramientas matemáticas.Interpretación Evaluación de los resultados de las métricas en un esfuerzo por

conseguir una visión interna de la calidad de la representación.Realimentación Recomendaciones obtenidas de a interpretación de métricas técnicas

transmiitidas al equipo software.

Tabla 28: Actividades y definición de Métricas Técnicas de Software

Los principios que se pueden asociar con la formulación de las métricastécnicas son los siguientes: Los objetivos de la medición que deben establecerseantes de empezar la recolección de datos, Todas las técnicas sobre métricasdeben definirse sin ambigüedades, Las métricas deberían obtenerse basándoseen una teoría válida para el dominio de aplicación, Hay que hacer las métricas amedida para acomodar mejor los productos y procesos específicos.

Roche sugiere los siguientes principios para la recolección y análisis dedatos: Siempre que sea posible, la recogida de datos y el análisis debeautomatizarse, Se deben aplicar técnicas estadísticas válidas para establecer lasrelaciones entre os atributos internos del producto y las características externas dela calidad, Se deben establecer directrices de interpretación y recomendacionespara todas las métricas.

La métrica obtenida y las medidas que conducen a ello deben tener lassiguientes características: Simples y fáciles de calcular, Empírica e intuitivamentepersuasivas, Consistentes y objetivas, Consistentes en el empleo de unidades ytamaños, Independiente del lenguaje de programación, Un mecanismo eficaz parala realimentación de calidad.

5.5.1 Métricas del Modelo de Análisis

En esta fase, las métricas técnicas proporcionan una visión interna a la calidad delmodelo de análisis. Estas métricas examinan el modelo de análisis con laintención de predecir el “tamaño” del sistema resultante; es probable que eltamaño y la complejidad del diseño estén directamente relacionados. Dentro delas métricas del modelo de análisis tenemos:

5.5.1.1 Métricas basadas en la Función: La métrica del punto de función seutiliza como medio para predecir el tamaño de un sistema obtenido a partir de unmodelo de análisis. Para visualizar esta métrica se utiliza un diagrama de flujo dedatos, el cual se evaluar para determinar las siguientes medidas clave que sonnecesarias para el cálculo de a métrica de punto de función: Número de entradas


100

del usuario, Número de salidas del usuario, Número de consultas del usuario,Número de archivos, Número de interfaces externas.

5.5.1.2 Métrica Bang

Puede aplicarse para desarrollar una indicación del tamaño del software aimplementar como consecuencia del modelo del análisis. Para calcular la métricabang, el desarrollador de software evalúa primero un conjunto de primitivas. Lasprimitivas se determinan evaluando el modelo de análisis y desarrollando cuentaspara los siguientes elementos de la tabla:

Primitivas funcionales (Pfu) Transformaciones que aparecen en el nivel inferior de undiagrama de flujo de datos.

Elementos de datos (ED) Los atributos de un objeto de datos, los elementos de datos nocompuestos y aparecen en el diccionario de datos.

Objetos (OB) Objetos de datosRelaciones (RE) Las conexiones entre objetos de datos.Estados (ES) El número de estados observables por el usuario en el

diagrama de transición de estados.Transiciones (TR El número de transacciones de estado en el diagrama de

transición de estado.Además, se determinan medidas adicionales para:Primitivas modificadas defunción manual (PMFu)

Funciones que caen fuera del limite del sistema y que debenmodificarse para acomodarse al nuevo sistema.

Elementos de datos deentrada (EDE)

Aquellos elementos de datos que se introducen en el sistema.

Elementos de datos desalida (EDS)

Aquellos elementos de datos que se sacan en el Sistema.

Elementos de datosretenidos (EDR)

Aquellos elementos de datos que son retenidos (almacenados)por el sistema.

Muestras (tokens) de datos(TCi)

Las muestras de datos que existen en el limite de la i-ésimaprimitiva funcional (evaluada para cada primitiva).

Conexiones de relación(Rei)

Las relaciones que conectan el i-ésimo objeto en el modelo dedatos con otros objetos.

Tabla 29: Métrica Bang

5.5.2 Métricas del Modelo de Diseño

Se concentran en las características de la arquitectura del programa, conénfasis en la estructura arquitectónica y en la eficiencia de los módulos. Estasmétricas son de caja negra en el sentido que no requieren ningún conocimientodel trabajo interno de un módulo en particular del sistema. Card y Glass definenlas siguientes tres medidas de complejidad:

La complejidad estructural, S(i), de un módulo i se define de a siguientemanera:S(i)=f2out(i) Donde fout(i) es la expansión del módulo i. La expansión indica elnúmero de módulos que son invocados directamente por el módulo i.


101

La complejidad del sistema, C(i), se define como la suma de lascomplejidades estructural y de datos C(i)= S(i) + D(i). La complejidad de datos,D(i), proporciona una indicación de la complejidad en la interfaz interna de unmódulo y se define como: D(i)=v(i)/[fout(i) + 1]. Donde v(i) es el número de variablesde entrada y salida que entran y salen del módulo i.

Fenton sugiere varias métricas de morfología simples que permitencomparar diferentes arquitecturas mediante un conjunto de dimensiones directas.Las métricas a aplicar son:

• Tamaño= n + a. Donde n es el número de nodos (módulos) y a es el número dearcos (líneas de control). Para la arquitectura mostrada se tiene tamaño=17+18=35.

• Profundidad= camino más largo desde el nodo raíz a un nodo hoja. Para elejemplo Profundidad= 4

• Amplitud=número máximo de nados de cualquier nivel de la arquitectura. Para elejemplo amplitud= 6

• Relación arco a nodo, r=a/n, mide la densidad de conectividad de la arquitecturay proporciona una indicación sencilla de acoplamiento de la arquitectura. Para elejemplo r=18/17= 1.06

5.5.3 Métricas del Codigo Fuente

Utiliza un conjunto de medidas primitivas que pueden obtenerse una vezque se han generado o estimado el código después de completar el diseño. Estasmedidas son:

n1: número de operadores diferentes que aparecen en el programa.N2: número de operandos diferentes que aparecen en el programa.N1: número total de veces que aparece el operador.N2: número total de veces que aparecen el operando.

Halstead utiliza medidas primitivas para desarrollar expresiones par lalongitud global del programa; volumen mínimo potencial para un algoritmo; elvolumen real (número de bits requeridos para especificar un programa); el niveldel programa (una medida de la complejidad del software); nivel del lenguaje (unaconstante para un lenguaje dado); y otras características tales como el esfuerzode desarrollo, tiempo de desarrollo e incluso el número esperado de fallos en elsoftware.

Halstead propone las siguientes métricas:

• Longitud N se puede estimar como: N = n1 log2 n1 + n2 log2 n2• Volumen de programa se define como: V = N n1 log2 (n1 + n2).


102

Tomando en cuenta que V variará con el lenguaje de programación yrepresenta el volumen de información (en bits) necesarios para especificar unprograma.

5.5.4 Métricas para Pruebas

Las métricas para pruebas se concentran en el proceso de prueba, no enlas características técnicas de as pruebas mismas. En general, los responsablesde las pruebas deben fiarse en las métricas de análisis, diseño y código para quesirvan de guía en el diseño y ejecución de los casos de prueba. El esfuerzo de laspruebas también se puede estimar utilizando métricas obtenidas de las medidasde Halstead. Usando la definición del volumen de un programa, y, y nivel deprograma, NP, el esfuerzo de la ciencia del software puede calcularse como:

NP = 1/[(n1/2) x (N2/n2)) (Ec. 1)e = V/NP (Ec. 2)

El porcentaje del esfuerzo global de pruebas a asignar a un módulo k sepuede estimar utilizando la siguiente relación:

Porcentaje de esfuerzo de pruebas (k) = e(k)/ Σe(i) (Ec. 3)

Donde e(k) se calcula para el módulo k utilizando las ecuaciones (Ec. 1) y(Ec. 2) la suma en el denominador de la ecuación (Ec. 3) es la suma del esfuerzode la ciencia del software a o largo de todos los módulos del sistema. A medidaque se van haciendo las pruebas, tres medidas diferentes proporcionan unaindicación de la compleción de las pruebas:

Medida deamplitud de laspruebas.

Proporciona una indicación de cuantos requisitos se han probado delnúmero total de ellos. Indica la compleción del plan de pruebas.

Profundidad delas pruebas

Medida del porcentaje de los caminos básicos independientes probadoscon relación al número total de estos caminos en el programa. Se puedecalcular una estimación razonablemente exacta del número de caminosbásicos sumando a complejidad ciclomática de todos los módulos delprograma.

Perfiles de fallos Se emplean para dar prioridad y categorizar los errores. La prioridad indicala severidad del problema. Las categorías de los fallos proporcionan unadescripción de un error, de manera que se puedan llevar a cabo análisisestadístco de errores.

Tabla 30: medidas de Compleción de pruebas

5.5.5 Métricas del Mantenimiento

Todas las métricas descritas pueden utilizarse para el desarrollo de nuevosoftware y para el mantenimiento del existente. El estándar IEEE 982.1-1988


103

sugiere el índice de madurez del software (IMS) que proporciona una indicación dela estabilidad de un producto software basada en los cambios que ocurren concada versión del producto. Con el IMS se determina a siguiente información:

MT= Número de módulos en la versiónActual Fc = Número de módulos en la versión actual que se han cambiadoFa= Número de módulos en a versión actual que se han añadidoFe= Número de módulos en la versión actual que se han eliminado

El índice de madurez del software se calcula de la siguiente manera;

IMS= [MT - (Fc + Fa + Fe)]I/MT

A medida que el IMS se aproxima a 1 el producto se empieza a estabilizar.El IMS puede emplearse también como métrica para la planificación de lasactividades de mantenimiento del software.


104

CAPITULO 6

PRUEBAS DEL SOFTWARE


105

INTRODUCCIÓN

Una de las características típicas del desarrollo de software basado en elciclo de vida es la realización de controles periódicos, norrnalmente coincidiendocon la terminación de cada una de las etapas, del producto o los documentos.Estos controles pretenden una evaluación de la calidad de los productosgenerados para poder detectar posibles defectos cuanto antes. Sin embargo, todosistema o aplicación, independientemente de estas revisiones, debe ser probadomediante su ejecución controlada antes de ser entregado al cliente. Estasejecuciones o ensayos de funcionamiento, posteriores a la terminación del códigodel software, se denominan habitualmente pruebas.

Cuando se desarrolla software, dentro del ciclo de vida se ha establecidoformalmente que la prueba es una actividad fundamental dentro de cada una delas etapas del proceso de desarrollo de software. A partir de la prueba se puededeterminar la calidad de los productos implementados.

Desde hace mucho tiempo, la prueba ha sido un tema muy importante en laingeniería de software, a partir de cual se han generado un gran número detrabajos. En este capítulo se presenta una revisión técnica sobre la prueba desoftware, abordándose fundamentalmente los enfoques de prueba propuestospara probar software construido bajo un enfoque funcional, orientado a objetos ybasado en componentes.

Las pruebas constituyen un método más para poder verificar y validar elsoftware cuando ya está en forma de código ejecutable. La verificación es elproceso de evaluación de un sistema o de uno de sus componentes paradeterminar si los productos satisfacen las condiciones impuestas al comienzo dedicha fase, y la validación hace referencia al proceso de evaluación de un sistemao de uno de sus componentes durante o al final del proceso de desarrollo paradeterminar si satisface los requisitos especificados. Así, validar una aplicaciónimplica comprobar si satisface los requisitos marcados por el usuario.


106

6.1 LECCIÓN 1: LA PRUEBA DEL SOFTWARE

Indiscutiblemente la prueba es una actividad fundamental en los procesosde desarrollo de software. La prueba de software permite al desarrolladordeterminar si el producto generado satisface las especificaciones que han sidoestablecidas en el diseño. Así mismo, una prueba de software permite detectar lapresencia de errores que pudieran generar salidas o comportamientosinapropiados durante su ejecución.

De acuerdo a la IEEE, el concepto de prueba se define como una actividaden la cual un sistema o componente es ejecutado bajo condiciones específicas, seobservan o almacenan los resultados y se realiza una evaluación de algún aspectodel sistema o componente. Para Myers, probar es el proceso de ejecutar unprograma con el fin de encontrar errores.

Cuando se habla de condiciones específicas, se puede suponer lapresencia de una especie de ambiente de operación de la prueba, para el cualdeben existir determinados valores para las entradas y las salidas, así comotambién ciertas condiciones que delimitan a dicho ambiente de operación,formalmente esto es conocido como Caso de Prueba.

El objetivo de las pruebas es la detección de errores o fallas y defectos enel software. Se trata de una actividad a posteriori, para la detección de problemasen el software, y la posterior rectificación. La mayoría de los estudios revelan quelos mejores programadores incluyen una cierta media de defectos por cada 1.000líneas de código. Los defectos no son siempre el resultado de la negligencia, sinoque en su aparición influyen múltiples factores como la mala comunicación entrelos 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 dela calidad del software. Las recomendaciones de G. J. Myers MYERS para laspruebas son las siguientes:

1. Cada caso de prueba debe definir el resultado de salida esperado. Esteresultado esperado es el que se compara con el realmente obtenido de laejecución en la prueba. Las discrepancias entre ambos se consideran síntomas deun posible defecto en el software.

2. El programador debe evitar probar sus propios programas porque deseademostrar que funcionan sin problemas. Lo ideal sería que probara el software elpeor enemigo de quien lo ha construido, ya que así se aseguraría una búsquedaimplacable de cualquier error cometido.

3. Se debe inspeccionar a conciencia el resultado de cada prueba para descubrirposibles síntomas de defectos. Lamentablemente es frecuente pasar por altosíntomas bastante claros. Esto invalida todo el esfuerzo realizado en laplanificación, diseño y ejecución de pruebas.


107

4. Al generar casos de prueba, se deben incluir datos de entrada válidos yesperados, asi como, datos no validos e inesperados.

5. Las pruebas deben centrarse en dos objetivos: Probar si el software no hace loque debe, y Probar si el software hace lo que no debe, es decir, si provoca efectossecundarios adversos.

6. Se deben evitar los casos no documentados ni diseñados con cuidado ya quesuele ser necesario probar una y otra vez el software hasta que queda libre dedefectos. No documentar o guardar los casos significa repetir constantemente eldiseño de casos de prueba.

7. No deben hacerse planes de prueba suponiendo que no hay defectos en losprogramas y dedicando pocos recursos a las pruebas. Hay que asumir quesiempre hay defectos y hay que detectarlos. Las estadísticas confirman cerca del40% del esfuerzo de desarrollo se consume en pruebas y depuración.

8. La experiencia parece indicar que donde hay un defecto hay otros, es decir, laprobabilidad de descubrir nuevos defectos en una parte del software esproporcional al número de defectos ya descubierto.

9. Las pruebas son una tarea más creativa que el desarrollo de software. Siemprese han considerado las pruebas como una tarea destructiva y rutinaria. No existentécnicas rutinarias para el diseño de pruebas y hay que recurrir al ingenio paraalcanzar un buen nivel de detección de defectos con los recursos disponibles.

La filosofía más adecuada para las pruebas consiste en planificarlas ydiseñarlas de forma sistemática para poder detectar el máximo número y variedadde defectos con el mínimo consumo de tiempo y esfuerzo. Un buen caso deprueba es aquel que tiene una gran probabilidad de encontrar un defecto nodescubierto aún, ya que el éxito de una prueba consiste en detectar un defecto noencontrado antes.

La prueba de software se realiza con el propósito de encontrar algo quedifiera a las especificaciones planteadas para el producto o bien, para detectar lapresencia de situaciones que pudieran generar resultados inapropiados. En lasiguiente tabla se muestran los objetivos, los principios, las características y losatributos principales que deben tener las pruebas:

La prueba es un proceso de ejecución de un programa con la intenciónde descubrir un error.Un buen caso de prueba es aquel que tiene alta probabilidad demostrar un error no descubierto hasta entonces.

Objetivos de laspruebas

Una prueba tiene éxito si se descubre un error.Hacer un seguimiento de las pruebas hasta los requisitos del clientePlantear y diseñar las pruebas antes de generar ningún código

Principios de lasPruebas

El 80% de todos los errores se centran en solo en el 20% de los


108

módulosEmpezar las pruebas en módulos individuales y avanzar hasta probarel sistema entero.No son posibles las pruebas exhaustivasDeben realizarse por un equipo independiente al equipo de desarrolloOperatividadObjetividadControlabilidadCapacidad de descomposiciónSimplicidadEstabilidad

Características de unsoftware fácil deprobar

Facilidad de comprensiónMás alta probabilidad de encontrar un error.No debe ser redundante

Atributos de unabuena prueba

No debería ser ni demasiado sencilla ni demasiado compleja

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

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

El objetivo de las técnicas de diseño de casos de prueba es el de conseguiruna confianza aceptable en que se detectarán los defectos existentes sin consumiruna cantidad excesiva de recursos. Toda la disciplina de pruebas debe moverseen un equilibrio entre la disponibilidad de recursos y la confianza que aportan loscasos para descubrir los defectos existentes.

La idea fundamental para el diseño de casos de prueba consiste en laellección de algunas posibilidades de funcionamiento del software que por suscaracterísticas, se consideren representativas del resto. Así si no se detectandefectos en el software al ejecutar dichos casos, se puede tener un cierto nivel deconfianza en que el programa no tiene defectos. La dificultad de esta idea essaber elegir los casos que se deben ejecutar. De hecho, una elección puramentealeatoria no proporciona demasiada confianza en que se puedan detectar todoslos defectos existentes.

6.2.1 Pruebas de caja blanca

Las pruebas de caja blanca enfocan su atención a los detallesprocedimentales del software, por ello la implementación de estas pruebasdepende fuertemente de la disponibilidad de código fuente. Este tipo de pruebas,permiten generar casos para ejercitar y validar los caminos de cada módulo, lascondiciones lógicas, los bucles y sus límites, así como también para lasestructuras de datos.

Las pruebas inician con la observación de que un programa difícilmentepuede considerarse como probado por completo si su código contiene partes quenunca han sido ejecutadas. Este método analiza la estructura lógica del programay, para cada alternativa que puede presentarse, los datos de prueba ideadosconducirán a ella. Se procura escoger los que verifiquen cada posibilidad en las


109

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

Figura 19: Prueba de Caja Blanca

En un programa complejo este método es impráctico, pero en un módulopequeño constituye un excelente medio de prueba y depuración. En una pruebaque se vale del método de la caja blanca, se tornan patentes las ventajas de undiseño de programa modular. Un buen criterio de prueba para proyectos extensosconsiste en aplicar los métodos a cada módulo pequeño conforme se escriba;luego se usan esos datos en las secciones más amplias del programa una vezterminadas.

Las pruebas de caja blanca también son conocidas como pruebas de cajade cristal o pruebas estructurales. Algunas de las pruebas más significativasdentro de este enfoque son mostradas en la siguiente tabla:

Prueba DefiniciónPrueba de caminos En este tipo de prueba se realiza un análisis sobre una representación

gráfica de un programa denominada grafo de control. En este grafo,los nodos representan bloques de instrucciones de un programa y losflujos de ejecución para dichas instrucciones se representan por mediode aristas. A partir de este grafo, se puede identificar un conjuntobásico de caminos de ejecución, sobre el cual se pueden realizarpruebas con el propósito de ejercitar el flujo de ejecución de loscaminos en una unidad.

Prueba de condiciones Basándose en un grafo de control, pueden generarse casos de pruebapara elementos individuales de expresiones lógicas. De esta forma sepretende probar cada condición con todas sus posibles alternativas.

Prueba de ciclos A partir del grafo de control, pueden generarse casos de prueba paralas iteraciones definidas en los programas con el propósito de verificarsi se realizan de forma correcta.

Prueba de definiciónde datos

Estas pruebas son realizadas con el objetivo de encontrar posiblescontradicciones o redundancias en la definición de los datos utilizadosen el software. Para ello se realiza un análisis del comportamiento decada uno de los datos o cada una de los flujos de ejecución.

Tabla 32: Pruebas de Caja Blanca


110

6.2.2 Pruebas de caja negra

Estas son conocidas como pruebas funcionales o pruebas decomportamiento, concentran la atención en generar casos de prueba que permitanejercitar los requisitos funcionales de un programa. A diferencia de las pruebas decaja blanca, que se basan en la lógica interna del software, este tipo de pruebasse concentran en su funcionalidad, por lo que mucho del trabajo se realizainteractuando con la interfaz del software. Los casos de prueba generados en esteenfoque, se diseñan a partir de valores entrada y salida. De esta forma, se puededeterminar la validez de una salida para un conjunto de entradas proporcionadas.

Los datos de prueba se escogerán atendiendo a las especificaciones delproblema, sin importar los detalles internos del programa, a fin de verificar que elprograma corra bien. Los criterios mínimos que guiarán al escoger los datos deprueba:

Valores Fáciles: El programa se depurará con datos de fácil comprobabilidad.

Valores típicos realistas: Se ensayará un programa con datos seleccionadospara que representen como se aplicará. Los Datos deben ser sencillos, de modoque los resultados sean verificables en forma manual.

Valores extremos o Valores ilegales: Cuando en un programa entra basura, susalida habrá de ser un mensaje de error adecuado. Es preferible que el programaofrezca indicación de errores en la entrada y que realice cálculos que sigan siendofactibles luego de desechar la entrada equivocada.

Figura 20: Prueba de Caja Negra

Con la aplicación de pruebas de caja negra se permite detectar errorescomo funciones incorrectas o ausentes, errores en estructuras de datos, erroresde rendimiento, errores de interfaz, así como errores de inicialización yterminación. Con la aplicación de esa técnica se obtiene un conjunto de pruebasque reduce el número de casos de pruebas y dicen algo sobre la presencia o


111

ausencia de errores. Algunas de las pruebas más conocidas en este contexto semuestran en la siguiente tabla:

Prueba DefiniciónPartición equivalente La idea de esta técnica, es en dividir los valores válidos y no válidos

para entradas y salidas en un número reducido de particiones deforma que, el comportamiento del software sea el mismo paracualquier valor contenido en una partición particular. El propósitoprincipal de una partición es reducir la cantidad de casos de pruebagenerados en el proceso.

Análisis de los valoreslímite

La generación de casos de prueba en esta técnica, se enfoca en losvalores limites, esto bajo la consideración de que existe una tendenciaa fallar precisamente cuando el software trabaja con valores extremosde la variable de entrada. Generalmente los valores establecidos paragenerar los casos de prueba son el mínimo, valores un poco arriba delmínimo, valor máximo y valores un poco arriba del máximo.

Pruebas según laexperiencia (errorguessing)

Este tipo de prueba la generación de casos se realiza a partir de laintuición y la experiencia. La idea básica es redactar una lista de lasposibles fallas o de las posibles situaciones en las cuales suele ocurriralgún problema y así desarrollar casos de prueba basados en lainformación contenida en estas listas.

Tablas de decisión Este tipo de prueba permite describir el comportamiento de unprograma a partir de un conjunto de acciones que este realiza cuandose opera bajo determinadas condiciones. En este enfoque, lascondiciones pueden ser interpretadas como entradas de un programay las acciones como las salidas producidas. Para ello se puedenutilizar conectores lógicos y (and), o (or) y no (not). Al involucraraspectos de lógica, se dice que este tipo de prueba se hace másrigurosa, que permite además transformar una especificación enlenguaje natural en una especificación más formal.

Tabla 33: Pruebas de Caja Negra

A continuación se presentan las distintas técnicas de diseño de casos de cajanegra:

6.2.2.1 Particiones o clases de equivalencia: Utiliza las cualidades que definenun buen caso de prueba de la siguiente manera: Cada caso debe cubrir el máximonúmero de entradas, Debe tratarse el dominio de valores de entrada dividido en unnúmero finito de clases de equivalencia donde la prueba de un valorrepresentativo de una clase permite suponer que el resultado obtenido será elmismo que el obtenido probando cualquier otro valor de la clase.

El método de diseño de casos consiste en la identificación de clases deequivalencia y la creación de los casos de prueba corespondientes. Paraidentificar las posibles clases de equivalencia de un programa a partir de suespecificación deben seguirse los siguientes pasos: primero, la identificación de Iacondiciones de entradas al programa, Segundo, a partir de ellas, se identificanclases de equivalencia que pueden ser de datos válidos o de datos no válidos oerróneos.


112

La identificación de las clases se realiza basándose en el principio deigualdad de tratamiento, donde todos los valores de la clase deben ser tratados dela misma manera por el programa. Existen algunas reglas que ayudan a identificarclases:

• Si se especifica un rango de valores para los datos de entrada (por ejemplo, “elnúmero estará comprendido entre 1 y 49”), se creará una clase válida (1>=número <= 49) y dos clases no válidas (número < 1 y número > 49).

• Si se especifica un número de valores (por ejemplo. “se pueden registrar de unoa tres propietarios de un piso’’), se creará una clase válida (1<= propietarios >=3) ydos no válidas (propietarios< 1 y propietarios>3).

• Una situación del tipo booleana (por ejemplo, “el primer carácter debe ser unaletra”), se identifican una clase válida (es una letra) y una no válida (no es unaletra).

• Si se específica un conjunto de valores admitidos (por ejemplo, “puedenregistrarse tres tipos de inmuebles: Casas, apartamentos y locales comerciales) yse sabe que eI programa trata de forma diferente cada uno de ellos, se identificauna clase válida por cada valor (en este caso son tres: Casas, apartamentos ylocales comerciales) y una no válida (cualquier otro caso: por ejemplo, lote ofinca).

• En cualquier caso, si se sospecha que ciertos elementos de una clase no setratan igual que el resto de la misma, debe dividirse en clases menores.

La aplicación de estas reglas para la derivación de clases de equivalenciapermite desarrolla los casos de prueba para cada elemento de datos del dominiode entrada.

El último paso del método es el uso de las clases de equivalencia paraidentificar los casos de prueba correspondientes. Este proceso consta de lassiguientes fases: Fase 1, la asignación de un número único a cada clase deequivalencia. Fase 2, hasta que todas las clases de equivalencia hayan sidocubiertas por casos de prueba, se tratará de escribir un caso que cubra tantasclases válidas, no incorporadas, como sea posible. Fase 3, hasta que todas lasclases de equivalencia no válidas hayan sido cubiertas por casos de prueba,escribir un caso para una única clase no válida sin cubrir.

6.2.2.2 Análisis de Valores Límite (AVL): Mediante la experiencia, se ha podidoconstatar que los casos de prueba que exploran las condiciones límite de unprograma producen un mejor resultado pura la detección de defectos, es decir, esmás probable que los defectos del software se acumulen en estas condiciones. Sepuede definir las condiciones límite como las situaciones que se hallandirectamente arriba, abajo y en los márgenes de las clases de equivalencia.


113

El análisis de valores límite es un técnica de diseño de casos quecomplementa a la de particiones de equivalencia. Aunque parezca que el AVL essimple de usar, su aplicación tiene múltiples matices que requieren un grancuidado a la hora de diseñar las pruebas. Las reglas para identificar clases son lassiguientes:

• Si una condición de entrada especifica un rango de valores (“-1.0 <= valor <=1.0”) se deben generar casos para los extremos del rango (-1.0 y +1.0) y casos noválidos para situaciones justo más allá de los extremos (-1.001 y +1.001, en elcaso que se admitan tres decimales).

• Si la condición de entrada especifica un número de valores (“el archivo deentrada tendrá de 1 a 255 registros”), hay que escribir casos para Ios númerosmáximo, mínimo, uno más del máximo y uno menos del mínimo de valores (0,1,255 y 256 registros).

• Usar la regla 1 para la condición de salida (“el descuento máximo aplicable encompra al contado será el 50%, el mínimo será el 6%”). Se escribirán casos paraintentar obtener descuentos de 5.99%, 6%, 50% y 50.01%.

• Usar la regla 2 para cada condición de salida (‘‘el programa puede mostrar de 1 a4 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 casosdeben concentrarse en el primero y en el último elemento.

Es recomendable utilizar el ingenio para considerar todos los aspectos ymatices, a veces sutiles, para la aplicación del AVL.

6.2.3 Conjetura de errores

Esta técnica consiste en enumerar una lista de errores posibles que puedencometer los desarrolladores o de situaciones propensas a ciertos errores. Despuésse generan casos de prueba en base a dicha lista que suelen corresponder condefectos que aparecen comúnmente y no con aspectos funcionales. No existendirectrices eficaces que puedan ayudar a generar este tipo de casos, lo único quese puede hacer es presentar algunos ejemplos que reflejan esta técnica. Algunosvalores a tener en cuenta para los casos especiales son los siguientes:

• El valor 0 es una situación propensa a error tanto en la salida como en laentrada.

• En situaciones en las que se introduce un número variable de valores, convienecentrarse en el caso de no introducir ningún valor y el de un solo valor. Tambiénpuede ser interesante el de todos los valores iguales.


114

• es recomendable suponer que el programador haya podido malinterpretar algoen la especificación.

• También interesa imaginar lo que el usuario puede introducir como entrada a unprograma. Se dice que se debe prever toda clase de acciones de un usuario comosi fuera a sabotear el programa.

6.2.4 Pruebas Aleatorias

En las pruebas aleatorias se simula la entrada habitual del programacreando datos para introducir en él que sigan la secuencia y la frecuencia con lasque podrían aparecer en la práctica diaria, de forma contínua, sin descanso. Estoimplica usar herramientas denominadas generadores de pruebas a las que sealimenta con una descripción de datos y secuencias de entradas posibles asícomo una estimación de probabilidad de ocurrir cada una de ellas en el uso real.

Si el proceso de generación de pruebas se ha realizado correctamente, secrearán todas las posibles entradas del programa en todas las combinacionesposibles, aunque no sea necesario hacer esto para una prueba adecuada.También se puede conseguir, indicando la distribución estadística que siguen, quela frecuencia de entrada para orientar correctamente nuestras pruebas haciaaquello que es más probable que suceda en la práctica real.

6.3 LECCIÓN 3: ESTRATEGIAS DE APLICACIÓN DE PRUEBAS DELSOFTWARE

Una estrategia de prueba integra las técnicas de diseño de casos de prueba en unconjunto de pasos bien planeados que dan como resultado la correctaconstrucción del software. Una estrategia de prueba de software proporciona unaguía para los desarrolladores del software, para la organización de control decalidad y para el cliente. Por tanto una estrategia de software debe incorporar laplanificación de la prueba, el diseño de casos de prueba, la ejecución de pruebasy la agrupación y evaluación de los datos resultantes.

6.3.1 Prueba de unidad

La prueba de unidad centra el proceso de verificación en la menor unidaddel diseño del software. Aquí se prueban los caminos de control importantes, conel fin de descubrir errores dentro del ámbito de un módulo. La complejidad relativade las pruebas y errores descubiertos se encuentra limitada por los lineamientosestablecidos por la prueba de software.

Se prueba la Interfaz del módulo para asegurar que la información fluye enforma adecuada hacia y desde la unidad del programa que está siendo probada.Se analizan las estructuras de datos para asegurar que los datos mantienen suintegridad temporal durante todos los pasos de ejecución del algoritmo. Se pruebalas condiciones límite para asegurar que el módulo funciona correctamente dentro


115

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

¿Es igual el número de parámetros de entrada al número deargumentos?¿Coinciden las características (atributos) de los parámetroscon los argumentos?¿Coinciden el sistema de unidades de los parámetros con el delos argumentos?¿Son correctos el número, atributos y el orden de losargumentos de las funciones incorporadas?¿Existen referencias o parámetros que no estén asociados conel punto de entrada actual?¿Entran sólo argumentos alterados?¿Son consistentes las definiciones de variables globales entremódulos?

lista de comprobaciones parala prueba de interfaces de unmódulo

¿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 sentenciasde Entrada/Salida?¿Coincide el tamaño del buffer con el tamaño del registro?¿Se abren los archivos antes de usarlos?¿Se tienen en cuenta las condiciones de fin de archivo?¿Se manejan errores de Entrada/Salida?

Cuando un módulo tengaoperaciones básicas deEntrada/Salida externa, sedeben llevar a cabo pruebasadicionales

¿Hay algún error textual en la información de salida?

Tabla 34: Lista de comprobaciones para la prueba de interfaces

Se deben diseñar casos de prueba para descubrir errores tales como:Tipificación impropia o inconsistente, Inicialización o valores implícitos erróneos,Nombres de variables incorrectos, Tipos de datos inconsistentes, Desbordamientoo errores en el direccionamiento de memoria.

Además se deben diseñar casos de prueba para detectar errores causadospor cálculos incorrectos o flujos de control inapropiados. Entre los errores máscomunes en los cálculos están: Procedencia aritmética incorrecta mal aplicada,Operaciones de modo mixto, Inicializaciones incorrectas, Falta de precisión,Representación incorrecta de una expresión.

Los casos de prueba deben descubrir errores como: Comparaciones entretipos de datos distintos, Operadores lógicos o de procedencia incorrecta,Terminación de ciclos inapropiada o inexistente, Falta de salida cuando seencuentra una iteración mal aplicada, Variables internas a un ciclo modificadas enforma inadecuada.


116

Entre los errores que se deben comprobar están los siguientes: Lacondición de error hace que intervenga el sistema antes que el mecanismo deerrores, Descripción ilegible del error, El error señalado no corresponde con elerror encontrado, La descripción del error no proporciona suficiente informaciónpara ayudar en la localización de la causa del error.

La prueba de los límites es la última etapa de la prueba de unidad y quizá lamás importante. El software falla en sus condiciones límite, o sea, quefrecuentemente aparece un error cuando se procesa el elemento n-ésimo de unarreglo n-dimensional, cuando se hace la i-ésima repetición de un ciclo de x pasoso cuando se llega a los valores máximo ó mínimo permitidos. Los casos de pruebaque ejerciten las estructuras de datos por debajo o encima de los mínimos ymáximos permitidos son apropiados para descubrir estos errores.

La estrategia de aplicación y la planificación de las pruebas pretendenintegrar el diseño de los casos de prueba en una serie de pasos bien coordinadosa través de la creación de distintos niveles de prueba, con diferentes objetivos.Además, permite la coordinación del personal de desarrollo, y del cliente, gracias ala definición de los papeles que deben desempeñar cada uno y la forma dellevarlos a cabo.

En general, la estrategia de pruebas es la siguiente: Las pruebascomienzan a nivel de módulo, una vez terminadas, progresan hacia la integracióndel sistema completo y su instalación, y culminan cuando el cliente acepta elproducto y se pasa a su explotación inmediata. Esta serie típica de etapas sedescribe con mayor detalle a continuación:

• Se comienza en la prueba de cada módulo, que normalmente la realiza el propiopersonal de desarrollo en su entorno.• Con el esquema del diseño del software, los módulos probados se integran paracomprobar sus interfaces en el trabajo conjunto.

• El software totalmente ensamblado se prueba como un conjunto para comprobarsi 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 sufuncionamiento conjunto.

• Por último, el producto final se pasa a la prueba de aceptación para que elusuario compruebe en su propio entorno de explotación si lo acepta como está ono.

6.3.2 Pruebas de integración

Las pruebas de integración están totalmente ligadas a la forma prevista deintegrar los distintos componentes del software hasta contar con el producto global


117

que debe entregarse. Así, las pruebas de integración implican una progresiónordenada de pruebas que parte desde los componentes y que culmina en elsistema completo. Su objetivo fundamental es la prueba de las interfaces entrecomponentes o módulos.

La prueba de Integración es una técnica sistemática para construir laestructura del programa mientras que al mismo tiempo, se llevan a cabo pruebaspara detectar errores asociados con la interacción. El objetivo es tomar losmódulos probados en unidad y estructurar un programa que esté de acuerdo conlo que dicta el diseño.

Una vez que los módulos funcionen por separado y hayan pasado la pruebade unidad es necesario realizar las pruebas para ver cómo funcionan juntos todoslos módulos. Normalmente aquí es donde pueden surgir los problemas en la uniónde los módulos. Los datos se pueden perder en una interfaz, un módulo puedetener un efecto adverso sobre otro módulo; las subfunciones, cuando secombinan, pueden no producir el objetivo principal deseado, las estructuras dedatos globales pueden presentar problemas.

Existen 2 tipos de integración, la primera es no incremental en donde seintenta elaborar software en módulos grandes, en otros casos un sólo módulo,pero en ellos es más difícil aislar los errores y cuando alguno de ellos es corregidoproduce otros errores. El segundo tipo de integración es incremental en donde sedesarrollan módulos pequeños y funcionales que hacen que los errores sean másfácil de aislar y corregir, es más probable que se puedan probar completamentelas interfaces y aplicar un enfoque de prueba sistemático.

6.3.2.1 Integración incremental ascendente: El proceso empieza combinandoprimero los módulos de más bajo nivel en grupos que realizan alguna subfunciónespecífica, donde se busca reducir el número de pasos de integración. Luego sedescribe para cada grupo un módulo impulsor o conductor, que es un módulo quepermite simular la llamada a los módulos, introducir los datos de prueba a travésde los parámetros de llamada y recoger los resultados a través de los de salida.Posteriormente, se prueba cada grupo empleando su impulsor y por último seeliminan los módulos impulsores de cada grupo y se sustituyen por los módulosdel nivel superior de la jerarquía.

6.3.2.2 Integración Incremental Descendente: La integración incrementaldescendente comienza con el módulo de control principal y va incorporandomódulos subordinados progresivamente. No existe un procedimiento general paradeterminar cuál de los módulos subordinados posibles es mejor incorporarprimero, es decir, no se puede dar una regla general que permita determinar lasecuencia óptima de incorporación de módulos. Hay que estudiar en cada casocuál es el mejor orden de incorporación para minimizar el esfuerzo o para lograruna mejor organización. La siguiente figura muestra la integración incrementaldescendente


118

Figura 21: Integración Incremental Descendente

Las etapas fundamentales de la integración descendente son las siguientes:

• El módulo raíz es el primero. Se escriben módulos ficticios para simular lapresencia de los subordinados ausentes que serán llamados por el módulo raíz.

• Una vez probado el módulo raíz se sustituye uno de los subordinados ficticios porel módulo correspondiente según el orden elegido. Se incorporan ficticios pararecoger las llamadas del último incorporado.

• Se ejecutan las correspondientes pruebas cada vez que se incorpora un módulonuevo.

• Al terminar cada prueba, se sustituye un ficticio por su correspondiente real.

6.3.2.3 Integración no incremental: En este tipo de integración cada módulorequiere de los siguientes elementos para ser probado:

• Un módulo impulsor, que transmite o impulsa los datos de prueba al módulo ymuestra los resultados de dichos casos de prueba.

• Uno o más módulos ficticios que simulan la función de cada módulo subordinadollamado por el módulo que se va a probar.

Después de probar cada módulo por separado, se ensamblan todos ellosde una sola vez para formar el programa completo y probarlo en conjunto. La


119

integración no incremental es el único caso en el que las pruebas de unidad y lasde integración están totalmente separadas.

6.3.3 Prueba del sistema

La prueba del sistema es el proceso de prueba de un sistema integrado dehardware y software para comprobar si cumple los requisitos especificados, esdecir: Cumplimiento de todos los requisitos funcionales, considerando el productosoftware fin al al completo, en un entorno de sistema, El funcionamiento yrendimiento en las interfaces hardware, software, de usuario y de operador,Adecuación de la documentación de usuario, Ejecución y rendimiento encondiciones límite y de sobrecarga.

Los casos para la prueba del sistema tienen tres fuentes principales para sudiseño: Casos basados en los requisitos gracias a técnicas de caja negraaplicadas a las especificaciones, Casos necesarios para probar el rendimiento delsistema y de su capacidad funcional (pruebas de volumen de datos, de límites deprocesamiento, etc.), Casos basados en el diseño de alto nivel aplicando técnicasde caja blanca aplicadas a los flujos de datos de alto nivel (por ejemplo, de losdiagramas de flujo de datos).

6.3.4 Prueba de aceptación

El objetivo de esta prueba es comprobar si el producto está listo para serimplantado para el uso operativo en el entorno del usuario. Si la prueba delsistema determinó la capacidad real del sistema y permitió a la organización dedesarrollo tener confianza en que estaba listo para su funcionamiento, la pruebade aceptación es la prueba planificacda y organizada formalmente para determinarsi se cumplen los requisitos de aceptación marcados por el cliente.

Las caracteristicas principales de esta prueba son las siguientes:Participación del usuario, se enfoca hacia la prueba de los requisitos de usuarioespecificados, es la fase final del proceso para crear una confianza en que elproducto es el apropiado para su uso en explotación.

Las recomendaciones generales que pueden darse para la prueba deaceptación son las siguientes: Debe contarse con criterios de aceptaciónpreviamente aprobados por el usuario, No hay que olvidar validar también ladocumentación y los procedimentos de uso, Las pruebas se deben realizar en elentorno en el que se utilizará el sistema.

Si se trata de un sistema contratado, la prueba se realiza bajo control de laorganización de desarrollo en el entorno real de trabajo ayudando al usuario(prueba alfa). En el caso de productos de interés general, se entregan versiones(versiones beta) a usuarios de confianza, sin control directo, que informarán de laopinión que les merece la aplicación.


120

6.3.5 Prueba de validación y verificación

Al conjunto de actividades que aseguran que el software implementacorrectamente una función específica se denomina Verificación. La Validación serefiere a un conjunto diferente de actividades que aseguran que el softwareconstruido se ajusta a los requisitos y necesidades del cliente.

La definición de Verificación y Validación envuelve lo que se conoce comocalidad del software, en donde los métodos de análisis, de diseño y deimplementación actúan para mejorar la calidad al proporcionar técnicas continuasy resultados predecibles. Las revisiones técnicas formales de inspección ayudan aasegurar la calidad la calidad de los productos, a lo largo del proceso la medición yel control se aplican sobre cada elemento de una configuración del software. Laprueba constituye un elemento importante para evaluar la calidad y de descubrirlos errores. Cabe mencionar que la prueba no se debe contemplar como una redde seguridad. La aplicación adecuada de los métodos y de las herramientas, lasrevisiones técnicas formales efectivas y una sólida gestión y medida, conducen ala calidad, que se confirma durante la prueba.

Es importante mencionar que la validación y verificación abarcan un ampliorango de la calidad del software que incluyen revisiones técnicas formales,auditorías de configuración y calidad, supervisión de rendimiento, simulación,estudio de viabilidad, revisión de la documentación, revisión de la base de datos,análisis de algoritmos, pruebas de desarrollo, prueba de calificación y prueba deinstalación.

La prueba de validación se logra cuando las expectativas razonables delcliente se cumplen, en donde incluyen la especificación de requisitos, documentosen donde se describen los atributos del software visibles para el usuario, estainformación forma la base del enfoque a la prueba de validación. El procedimientode prueba estará diseñado para asegurar que se satisfacen los requisitosfuncionales, que se alcanzan todos los requisitos de rendimiento, que ladocumentación es correcta y que se alcanzan otros requisitos tales comoportabilidad, compatibilidad, recuperación de errores, facilidad de mantenimiento,entre otros.

6.3.6 Prueba del sistema

La prueba del sistema tiene la finalidad de verificar que se hayan integradocorrectamente cada uno de los elementos del sistema. Comprende las siguientespruebas:

6.3.6.1 Prueba de Recuperación: La prueba de recuperación es una prueba quese hace al sistema forzando a que produzca fallas de software de muchasmaneras y verificando que la recuperación se lleve a cabo, ya sea


121

automáticamente o manual, tomando en cuenta los recursos que se requieranpara efectuar la recuperación.

6.3.6.2 Prueba de Seguridad: La prueba de seguridad intenta verificar laaplicación de los mecanismos de protección incorporados en el sistema. Durantela prueba el encargado de la prueba desempeña el papel de intruso tratando deviolar la seguridad del sistema, intentando obtener las claves de acceso porcualquier medio externo; debe bloquear el sistema, negando así el servicio a otraspersonas además de producir errores a propósito en el sistema; o debe curiosearlos datos públicos intentando encontrar una clave de acceso al sistema.

6.3.6.3 Prueba de Resistencia: La prueba de resistencia está diseñada paraenfrentar a los programas en situaciones anormales, es decir ejecutar el sistemaen forma que demande recursos en cantidad, frecuencia o volúmenes anormales.El encargado de la prueba debe intentar colapsar el sistema y para lograrlo sepuede tomar en consideración lo siguiente: Diseñar pruebas especiales quegeneren 10 o más interrupciones por segundo, Incrementar las frecuencias dedatos de entrada en un orden de magnitud con el fin de comprobar comoresponden las funciones de entrada, Ejecutar casos de prueba que requieran almáximo de memoria o de espacio en disco, Diseñar casos de prueba queproduzcan excesivas búsquedas de datos almacenados en disco.

6.3.7 Depuración

La depuración aparece como resultado de una prueba efectiva, es decir,cuando en un caso de prueba se encuentra un error, la depuración es el procesoque resulta en la eliminación de un error. Se debe tomar en cuenta que ladepuración no es una técnica de prueba, aunque siempre se da comoconsecuencia de la prueba. En la siguiente figura se muestra que el proceso dedepuración comienza en los casos de prueba, se evalúan los resultados y resultauna falta de correspondencia entre los esperados y los reales, el proceso dedepuración intenta hacer corresponder el sistema con una causa, llevando así a lacorrección del error.


122

Figura 22: Depuración de errores

La depuración tiene como objetivo principal encontrar y corregir la causa deun error en el software, existen 3 enfoques que se pueden proponer en ladepuración:

La categoría de depuración "eliminación de causas" se manifiesta medianteinducción o deducción. Los datos relacionados con la ocurrencia del error seorganizan para llegar a las posibles causas; se desarrolla una lista de las causas yse llevan a cabo las pruebas para eliminar cada una.

La categoría de depuración por "fuerza bruta" es la categoríaprobablemente la más común y la menos eficiente en el momento de aislar lacausa del error del software en donde se confía que en algún lugar de la grancantidad de información producida nos puede llevar finalmente al éxito, lo másfrecuente es que se desperdicie tiempo y esfuerzo.

La vuelta atrás es el enfoque más normal para la depuración, que se puedeusar con gran éxito en programas pequeños. Partiendo de donde se detecta elerror hacia atrás en el código fuente hasta llegar a la posición del error.

6.4 LECCIÓN 4: PRUEBA DE SOFTWARE PARA OBJETOS

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


123

del software orientado a objetos que generan problemas adicionales no cubiertospor las técnicas tradicionales de prueba.

La unidad básica para la prueba de software orientado a objetos es la clase.A pesar de ello, cuando se prueba al software orientado a objetos, no es posiblerealizar una prueba para una clase por sí misma, sino que hay que realizarla parauna instancia de ésta, es decir para un objeto.

Una característica importante del enfoque orientado a objetos es laencapsulación. Un objeto encapsula su estado y sus funciones asociadas. Laabstracción, concepto que define la capacidad de solo destacar las característicasesenciales de un objeto de tal forma que se puede separar su comportamientoesencial de su implementación, va estrechamente ligada con la encapsulación.

El ocultar todos los detalles del objeto que no contribuyen a suscaracterísticas esenciales, por ejemplo su estructura y la implementación de susmétodos, hace que parte de un objeto sea inaccesible para el mundo.Naturalmente, esto obstaculiza la eficiencia de las pruebas, ya que para realizarlasse requiere monitorear el estado de un objeto. Esto es difícil de realizar concaracterísticas como la encapsulación y la abstracción, pues la dificultad devisualizar el estado interno del objeto impide consultar información que podríarequerirse para el desarrollo de la prueba.

La herencia es otra de las características que han venido a facilitar en granmedida el desarrollo de sistemas orientados a objetos. Puede pensarse que estoapoya la prevención de fallas al construir software. Desgraciadamente, se hacomprobado que mediante esta práctica, se tienen muchas posibilidades decometer errores, porque generalmente los elementos heredados son sometidos aalgún tipo de refinamiento o redefinición y en algunos casos eliminación decomponentes. Todas estas situaciones hacen pensar que realizar una prueba alos métodos heredados debe ser una regla más que una excepción.

La herencia en cierta medida trae como consecuencia reuso, lo que generauna interrogante con respecto a la formulación de las pruebas: las subclases deuna clase que ya ha sido probada, deben de ser probadas nuevamente. Si larespuesta es sí, se habla de diferentes niveles de herencia lo que incrementa elnúmero de pruebas a realizar.

Otro aspecto que determina la dificultad de las pruebas que se realizan alsoftware orientado a objetos es el polimorfismo. Cada vez que se realiza unainstancia diferente de un objeto como producto del polimorfismo en los métodos,se requiere una prueba separada. Realizar una prueba separada para cada unade la formas de un método es una tarea difícil, la complejidad y el tiemporequerido crece considerablemente cuando se tienen que definir todos los posibleserrores y obstáculos que pueden presentarse.


124

En los sistemas orientados a objetos, el flujo de control se lleva a cabomediante el paso de mensajes entre objetos. Cuando un mensaje es enviado deun objeto u otro, la consecuencia es, generalmente, que el objeto receptor ejecutealguna operación para examinar o alterar su estado. El paso de mensajes es unpunto fundamental al realizar la prueba.

6.4.1 Métodos de prueba de software orientado a objetos.

Muchas de las generalidades de los métodos de prueba tradicionales hansido adaptadas considerando las características del modelo orientado a objetos,con el propósito de que puedan ser aplicables en este nuevo contexto.Actualmente, existen muy pocas investigaciones sobre el estudio de prueba desoftware orientado a objetos; ya que el área de prueba de software es bastantecompleja y dentro de este marco de objetos existe una carencia de métodosrobustos para garantizar la realización de las pruebas de forma eficaz. En estepanorama se presenta el estado actual en cuanto a prueba de software orientadoa objetos en términos del nivel de prueba.

6.4.1.1 Pruebas de unidad

En el software orientado a objetos la menor unidad a considerar pararealizar una prueba es la clase. La prueba de clases en el ámbito de softwareOrientado a Objetos es equivalente a la prueba de unidad realizada al softwaretradicional. Esta prueba está fundamentalmente dirigida a las operacionesencapsuladas por la clase, así como al estado y comportamiento del objeto que seimplementa en ella. El énfasis de la prueba de unidad es verificar que estapequeña unidad trabaje correctamente en forma aislada, antes de proceder aintegrarla en el sistema.

Los métodos contenidos en una clase pueden ser muchos y una operaciónen particular de ese conjunto, a consecuencia de la herencia, puede existir comoparte de varias clases diferentes. Por lo tanto el significado de prueba de unidadcambia en muchos sentidos y es importante diseñarla bajo ciertasconsideraciones.

Se han propuesto estrategias para llevar a cabo las pruebas de unidadconsiderando aspectos como el orden en que los métodos son sometidos a laprueba, el orden en que una jerarquía de clases puede ser probada, ejercitar elflujo de datos o bien el análisis del estado del objeto.

Los aspectos que deben considerarse para construir casos de prueba parauna clase deben verificar que esta proporcione los servicios que promete, queresponda correctamente a las condiciones esperadas y, más aún, ante lasinesperadas. Aspectos adicionales pueden el verificar si la clase contiene ypermite disponer de todas las funciones asociadas a ella o que cada método de laclase ejecute su responsabilidad especificada. Algunas de las técnicas máspopulares para realizar pruebas de unidad se muestran en la siguiente tabla:


125

Prueba DefiniciónPruebas estructurales Si se tiene la disponibilidad de código fuente, pueden realizarse

pruebas estructurales a las unidades sometidas a la prueba. Lasacciones de esta actividad pueden diseñarse con el propósito deejercitar todas las rutas del código, las condiciones establecidaso bien las ciclos definidos en el programa.

Prueba de valores limite Mediante esta técnica se prueba la unidad bajo situacionesinusuales o extremas, con el propósito verificar cómo sonmanejadas por el software. Para ello, los casos de pruebasuministrados son diseñados considerando valores frontera, esdecir los valores mínimo y máximo que la unidad puede aceptar,así como también aquellos valores cercanos a las fronterasidentificadas.

Prueba basada en estados Para esta técnica, se generarán casos de prueba para uncontexto en donde una clase se modela como una máquina deestados con secuencias de transiciones, con esto se pretendeanalizar el estado de los objetos de acuerdo a sucomportamiento. Una vez que se ha establecido un modelo deestados con base en los atributos del objeto, se consideran en laprueba los métodos necesarios para poder observar los cambiosde estado. La aplicación de esta técnica permite observar algunade las siguientes situaciones: se produce un cambio a un estadocorrecto, se produce cambio a un estado incorrecto, no haycambio de estado, se produce un estado indefinido correcto obién, se produce un estado indefinido incorrecto.

Prueba incremental La prueba incremental dirige su atención a las subclasesgeneradas como consecuencia de la herencia, siendo la clasepadre una clase previamente probada. Aunque existensituaciones en las que éste tipo de pruebas se descarta, sepueden identificar algunas en las que no estarían de más:cuando se han agregado o modificado propiedades y/o métodos,cuando existen propiedades y métodos que se han heredado yno se han alterado, pero que realizan algún tipo de interaccióncon elementos nuevos o modificados.

Tabla 35: Pruebas de Unidad de Software Orientado a Objetos

6.4.1.2 Pruebas de integración.

Cuando se aplican pruebas de integración al software orientado a objetos,se pretende demostrar que las unidades que ya han sido sometidas a un procesode prueba y funcionan correctamente, lo hacen de igual forma cuando interactúany se integran con otras unidades del sistema. Prácticamente, el trabajo de estaprueba se concentra en la interacción de métodos en diferentes unidades.

Existe una coincidencia en los dos enfoques para realizar este tipo depruebas: el basado en hilos y el basado en uso. En el primero, pretende que todaslas 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 locual un hilo de este conjunto se ejercita.En el enfoque basado en uso, se realizanpruebas para clases las cuales usan servicios de otras clases. En la siguientetabla se presentan algunos métodos para realizar pruebas de integración:


126

Prueba DefiniciónMétodo de Caminos deMensajes

Este método se concentra principalmente en probar aquelloscaminos que se generan por un evento de entrada y terminancon un evento de salida

El método de Overbek En este método se prueban las clases por pares, donde unahace el papel de cliente y otra el de servidor, estableciéndosepara estas dos conjuntos de pruebas. El primer conjunto, sonpruebas orientadas a verificar si los mensajes de entrada y desalida generados son correctos; es decir si se usa correctamentecualquier clase servidora y si todas las secuencias deoperaciones son correctas. En el segundo conjunto se verificaademás de lo anterior, si la clase cliente siempre satisface lasprecondiciones de la clase servidora, así como también sisatisface las salidas esperadas por la clase servidora.

El método de Kung Este método emplea una estrategia de ingeniería en reversasobre el código de las unidades con el propósito de generar undiagrama de relaciones entre objetos. A partir de este diagramase propone un orden para las pruebas que minimiza el uso decabos. El diagrama se convierte en un grafo acíclico, que puedecontener varios clusters de objetos y los ordenantopológicamente. Su método involucra las etapas de pruebas deunidad y de integración y puede usarse también para pruebas deregresión.

Tabla 36: Pruebas de Integración de Software Orientado a Objetos

6.4.1.3 Pruebas de sistema.

Las pruebas de unidad se concentran en verificar si las funcionalidadesdescritas en las especificaciones o en los requisitos iniciales corresponden a lasque se presentan en el producto final. En esta área, al igual que la de pruebas deintegración, se han generado pocos trabajos, por lo que se emplean muchos delos métodos tradicionales.

Prueba DefiniciónPrueba de función La prueba de función comúnmente es llevada a cabo por el

grupo de personas que desarrollaron el producto. Este enfoquese orienta a confirmar que la aplicación alcanza losrequerimientos y la funcionalidad especificadas por el usuario

Pruebas de aceptación En este tipo de pruebas, versiones que aún no han sidoliberadas en el mercado, son ofrecidas a ciertos grupos deusuarios con el propósito de que las utilicen. El propósito de éstoes que los usuarios reporten defectos que pudieran presentarse.

Prueba bajo stress Para realizar esta prueba, el sistema somete a condicionesextremas de trabajo, como pueden ser un alto volumen detransacciones o un gran número de usuarios. Aplicando esteenfoque, se puede verificar si el sistema se comporta como seespera aún ante este tipo de escenarios.

Tabla 37: Pruebas de Sistema de Software Orientado a Objetos


127

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

La construcción de software a partir de componentes es una prácticarelativamente nueva, por lo que no es extraño que sea escasa la existencia detrabajos generados al respecto. Puesto que el desarrollo basado en componentespresenta algunas similitudes con el enfoque orientado a objetos, para uncomponente pueden ser aplicables algunas de sus consideraciones, incluso enmateria de prueba. Aspectos como la herencia, encapsulación, polimorfismo, ligadinámica o mecanismos de comunicación, son comunes entre ambos modelos. Esevidente que para hacer las pruebas de componentes más robustas, seránecesario considerar las características propias del enfoque de componentes.

En la mayoría de los casos, los criterios de prueba de caja negra son losmás aplicados a los componentes, puesto que la disponibilidad del código fuentees nula en la mayoría de las veces. Debido a que un componente es una unidadconcreta, con una función bien definida, no basta realizar pruebas para suevaluación; de igual forma se requieren procesos de prueba para su selección ypara su integración.

Durante la etapa de construcción de un componente, el desarrollador puedeaplicar las técnicas de prueba de unidad y de integración tradicionales del modeloOrientado a Objetos, sin embargo en lo que respecta a la selección y evaluación,considerar el punto vista del usuario es un aspecto vital para la realización de laprueba. Finalmente en el marco de pruebas de integración, consideraciones comola arquitectura de la aplicación, el software intermediario y los modelos de loscomponentes, deben agregarse a los criterios de evaluación.

Con el propósito de organizar algunas de las estrategias de prueba decomponentes más comunes, en las siguientes secciones se presenta unadescripción de las mismas en los términos que se presentaron para el enfoqueorientado a objetos, de nivel unidad y nivel de integración.

6.5.1 Pruebas de unidad.

Aunque la realización de pruebas de unidad es una actividad que en algúnmomento es llevada a cabo por el desarrollador, existe un marco de trabajoadicional a considerar: el de la persona que se interesa en el componente con elfin de integrarlo en sus sistemas.

Actualmente son pocos los trabajos en materia de pruebas de unidad paracomponentes, dos sobresalientes en este ramo son el proyecto TrustedComponents y el Proyecto Kimera, aunque este último no esta dirigido totalmentea componentes, sino a la seguridad de las máquinas virtuales de Java cada vezque se carga una clase.

Trusted Components, es un proyecto de investigación paras asistir a laindustria de construcción de software mediante librerías probadas de


128

componentes. Las pruebas que se aplican a los componentes se construyen bajola combinación de varios enfoques como diseño por contrato, como pruebasmatemáticas, métricas, validación exhaustiva en proyectos prácticos y manejo decambios rigurosos.

6.5.2 Pruebas de integración.

Si las pruebas de nivel de unidad para componentes muestran severas carencias,en nivel de integración, al igual que en otros enfoques de desarrollo, las carenciasson aún más notables. Sin embargo, existen coincidencias en cuanto a lasproblemáticas comunes al integrar componentes:

6.5.2.1 El volumen y la lentitud: Cuando se utilizan componentes dentro de unsistema, no siempre se utilizan todas sus capacidades, lo que hace que ciertaparte del código no sea necesario. Este problema se agrava cuando se tienensistemas grandes, afectándose así su rendimiento.

6.5.2.2 Los mecanismos de comunicación utilizados: Se han presentadoalgunas contrariedades e inconsistencias al utilizar dentro de un mismo sistemavarios mecanismos de comunicación como eventos, mensajes o bien el paso deparámetros.


129

GLOSARIO DE TÉRMINOS

Arquitectura de software: Es un diseño global de una aplicación que incluye sudescomposición en partes.

Calidad: La calidad es herramienta básica para una propiedad inherente decualquier cosa que permite que esta sea comparada con cualquier otra de sumisma especie.

Calidad de Software: Características propias del software que se desea controlary asegurar, el software es un producto inmaterial que no se fabrica, tampoco sedegradan físicamente, sino que se desarrolla; El software puede tener errores,incidencias pero no son similares a lo que cualquier equipo de carácter físico.

Calidad externa: La magnitud de satisfacción de un producto con relación anecesidades establecidas cuando es usado bajo condiciones específicas.

Calidad interna: El total de atributos de un producto que determina su capacidadpara satisfacer necesidades establecidas cuando es usado bajo condicionesespecíficas.

Componente Software: Son todos aquellos recursos desarrollados para un finconcreto y que puede formar solo o junto con otros, un entorno funcional requeridopor cualquier proceso predefinido.

Documentación de pruebas del software: Documento que especifica todos losaspectos del proceso de pruebas para una aplicación.

Estándar: Base o modelo en el que todo el mundo se ha puesto de acuerdo.

Gestión de Calidad de Software: Es un conjunto de actividades de la funcióngeneral de la Dirección que determina la calidad, los objetivos y lasresponsabilidades. Se basa en la determinación y aplicación de las políticas decalidad de la empresa.

ISO: (Internacional Standards Organization) Organización Internacional deestándares fundada en 1946, con sede principal en Ginebra, ISO establece o fijaestándares internacionales. Se ocupa de todos los campos, excepto la electricidady la electrónica, que se rigen por la Internacional Electrotechnical Comisión (IEC),también en Ginebra.

ISO 9001: Es un conjunto de normas sobre la calidad y la gestión.

ISO/IEC 9126: Es un estándar internacional para la evaluación del software. Estásupervisado por el proyecto SQuaRE, ISO 25000:2005, el cuál sigue los mismos


130

conceptos. El estándar está dividido en cuatro partes las cuales dirigen,respectivamente, lo siguiente: modelo de calidad, métricas externas, métricasinternas y calidad en las métricas de uso.

ISO/IEC 14598: Norma para la evaluación del producto software. Esta normacomprende las siguientes seis partes que especifican el proceso a seguir paraevaluar software: ISO/IEC 14598-1 Visión general; ISO/IEC 14598-2 Planificacióny Gestión; SO/IEC 14598-3 Procedimiento para desarrolladores; ISO/IEC 14598-4Procedimiento para compradores; ISO/IEC 14598-5, Procedimiento paraevaluadores; ISO/IEC 14598-6 Documentación de los módulos de evaluación.

ISO/IEC 25000: Especificación de requerimientos de calidad del software yevaluación de la calidad del software, soportada por el proceso de medición decalidad del software.

Métrica: Una escala de medición y un método usado para la medición.

Modelo: Un modelo es una estructura conceptual que sugiere un marco de ideaspara un conjunto de descripciones que de otra manera no podrían sersistematizadas.

Proceso: El proceso de ingeniería de software se define como un conjunto deetapas parcialmente ordenadas con la intención de logra un objetivo, en este caso,la obtención de un producto de software de calidad.

Prueba: Actividad durante la cual los desarrolladores encuentran diferencias entreel sistema y sus modelos ejecutando el sistema (o partes de él) con conjuntos dedatos de entrada de prueba.

Prueba de Caja Blanca: Prueba que se enfoca en la estructura interna de uncomponente.

Prueba de Caja Negra: Prueba que se enfoca en el comportamiento deentrada/salida de un componente sin considerar su implementación.

Pruebas del sistema: Proceso de probar una aplicación completa (no sus partes).


131




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.


ISO/IEC 14598-1:1999. Information technology software product evaluation - part1: 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, June2001.

James M. Bieman and Linda M. Ott. Measuring functional cohesion. TechnicalReport CS-93-109, Fort Collins, CO, USA, 24 June 1993.

James A. McCall, Paul K. Richards, and Gene F. Walters. Factors in softwarequality, volume III: Preliminary handbook on software quality for an acquisitionmanager. Technical Report RADC-TR-77-369, vol. III, Hanscom AFB, MA 01731,1977.

MEYER, Bertrand. Construcción de software orientado a objetos. Segundaedición. Madrid. 1999. Prentice Hall.

Miller, E., Howden, W. E., Tutorial, Software Testing & Validation Techniques, 2aed., IEEE Computer Society Press, 1981.

Murine, G.E. , Integrating software quality metrics with software QA, QualityProgress vol.21, no.11; pp. 38-43; Nov. 1988.

Norman E. Fenton and Shari Lawrence Pfleeger. Software Metrics: A Rigorous &Practical Approach. Brooks/Cole, 2 edition, January 1998.

Piatini, Mario y col. Analisis y Diseño de Aplicaciones Informáticas de Gestión, UnaPerspectiva de Ingeniería de Software, Alfaomega 2004. Páginas 109 – 164.


132

PIATTINI, Mario. VILLALBA, Jose y otros. Mantenimiento del software: modelos,técnicas y métodos para la gestión del cambio. Editorial Alfaomega-Rama.



T.J. McCabe. A software complexity measure. IEEE Transactions on SoftwareEngineering, 2(4):308–320, 1976.


http://www.pressman5.comhttp://www.wiley.com/college/braudehttp://www.ilustrados.com/publicaciones/EpyVZFEVukfVKPBUot.phphttp://www.itver.edu.mx/comunidad/material/ing-software/unidad5.ppthttp://www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware.htmlhttp://www.sistemas.unam.mx/software.htmlhttp://www.ii.uam.es/~jlara/docencia/is1.2003/recursos.htmlhttp://www.bvs.sld.cu/revistas/aci/vol3_3_95/aci05395.htm Oscar M. FernándezCarrasco1, Delba García León2 y Alfa Beltrán Benavides3http://www.lcc.uma.es/~av/misConfs/Calidad%20de%20Componentes%20CR%20Junio%202004.ppt#345,2,Agendahttp://www.willydev.net/descargas/articulos/general/CalidadSoftware.pdfhttp://www.pcm.gob.pe/portal_ongei/banconormas1.asphttp://www.iso.orghttp://www.bulltek.com/Spanish_Site/ISO%209000%20INTRODUCCION/TL%209000%20Spanish/ISO9000-3_Spanish/iso9000-3_spanish.html


133

UNIDAD 3Nombre de la Unidad EVALUACIÓN DE SOFTWAREIntroducción La evaluación de software en la actualidad es uno de los

elementos que debe ser tenido en cuenta en el procesode construcción de un producto software, como también,en el producto terminado. La evaluación del productosoftware es la garantía que debe brindar el fabricante deque su producto cumple con las normas de calidadinternacionales para estos productos tan especiales.

Además la evaluación de productos software contribuye almejoramiento de los procesos en la empresa, ya que,permite la verificación y validaciós de todas y cada una delas características del producto no importando si se tratede una aplicación pequeña o compleja.

En este capítulo se tratará de identificar la metodologíatécnica para la evaluación de software, las metodologiasde evaluación de la arquitectura y algunas de lasaplicaciones de la evaluación de software.

Justificación Actualmente cada uno de los productos de software quesalen comercialmente al mercado deben garantizar almenos el cumplimiento de normas estándares de calidadque permitan a los usuarios determinar el grado deeficiencia, eficacia y confiabilidad de estos productos. Yuna de las funciones encomendadas a los ingenieros es lade evaluar los productos software y determinar cual deellos es el más apropiado para la organización o para unode los procesos dentro de ella.

Por lo tanto es importante que los futuros profesionalesadquieran el conocimiento y las habilidades para cumplircabalmente con sus funciones dentro de la organización.


- El estudiante conoce y aplica la norma de calidadISO/IEC 9126 para la evaluación de software- El estudiante esta en capacidad de relacionar losconceptos de evaluación, características, metricas,pruebas y llevarlos a la práctica- El estudiante conoce las diferentes metodoligias para laevaluación del proceso y producto software- El estudiante adquire nuevos conocimientos y puedetransferirlos aplicandolos a su entorno laboral llevándolosa la práctica


CAPÍTULO 7. METODOLOGÍA TÉCNICA PARA LAEVALUACIÓN DE SOFTWARE

Denominación de Lección 1. Modelos Tradicionales para la Evaluación de la


134

lecciones Calidad del softwareDenominación delecciones

Lección 2. Norma de Evaluación ISO/IEC 9126


Lección 3. Proceso de Evaluación de Software


Lección 4. Métricas Externas Basados en ISO/IEC 9126


Lección 5. Métricas Internas Basados en ISO/IEC 9126


CAPÍTULO 8: METODOLOGÍAS DE EVALUACIÓNPARA ARQUITECTURA DEL SOFTWARE


Lección 1. Evaluación de la Arquitectura del software


Lección 2. Técnicas de Evaluación de la arquitectura delsoftware


Lección 3. Métodos de Evaluación de la arquitectura desoftware


Lección 4. Métodos de Evaluación de Arquitectura de unAtributo Específico


Lección 5. Método de evaluación de la Arquitectura deSoftware MECABIT


CAPÍTULO 9: APLICACIONES DE LA EVALUACIÓN DESOFTWARE


Lección 1. Metodología para la Evaluación de la Calidaden Modelos UML


Lección 2. Implementación de la Metodología con SPEM yEPFC


Lección 3. Evaluación de Software Educativo Multimedia


Lección 4. Modelos de Evaluación de Software EducativoMultimedia


Lección 5. Plantillas de Evaluación de SoftwareMultimedia


135

UNIDAD 3

EVALUACIÓN DESOFTWARE


136

CAPITULO 7

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


137

INTRODUCCIÓN

La metodología para evaluación técnica de software considera una serie depasos que deben ser tenidos en cuenta cuando se trata de realizar este procesotan complejo, por eso es necesario que se conozcan y se haga el seguimientos deellos para realizar una buena evaluación del producto.

Dentro de los estándares de calidad más utilizados esta el estándar definidopor la ISO/IEC 9126 el cual toma en consideración la evaluación de lascaracterísticas internas, externas y de calidad en uso. A su vez cada una de lascaracterísticas se divide en subcaracterísticas que se pueden definir y a las cualesse les puede establecer unas métricas, pruebas y escalas de medición quepermitan establecer una valoración para el producto en la caracerística que hayasido elegida.

En este capítulo se tratará el tema de algunas de las metodologiasexistentes para la evaluación de software, dentro de ella se ha elegido la normaISO/IEC y de ella se hará el seguiemiento hasta llegar a definir las métricas queson la base para realizar el proceso de evaluación de software.


138

7.1 LECCIÓN 1: MODELOS TRADICIONALES DE EVALUACIÓN DE LACALIDAD DEL SOFTWARE

Cuando se trata de evaluar la calidad de un producto software hay quetener en cuenta que la calidad es un concepto muy complejo y que, además,depende mucho del punto de vista que se adopte. La evaluación se basa en ladescomposición del concepto genérico de calidad en propiedades más sencillasde medir y evaluar. Este tipo de descomposición recibe el nombre de modelo decalidad. Los modelos de calidad más conocidos y utilizados han sido los deBoehm y McCall.

El modelo de McCall se basa en descomponer el concepto de calidad entres usos o capacidades importantes para un producto software desde el punto devista del usuario: La capacidad de operación, la capacidad para ser modificado yla capacidad de transición o de adaptación a otros entornos.

Cada capacidad o uso se descompone en una serie de factores quedeterminan la calidad en cada una de las capacidades antes mencionadas. Por lotanto, existen una serie de factores que se puede evaluar más fácilmente que lascapacidades para tener una visión apropiada de la calidad. Estos factores sonconceptos de alto nivel de abstracción, a continuación se ofrecen las definicionesde estos factores:

Facilidad de uso: Grado de esfuerzo necesario para aprender a utilizar elsoftware, preparar la entrada de datos e interpretar la salida del mismo.

Integridad: Grado en que se puede controlar el acceso del personal al software oa los datos que utiliza.

Eficiencia: Necesidades de recursos hardware y software requeridos por elsoftware evaluado para realizar sus funciones.

Fiabilidad: Grado o probabilidad de que el software no falle al realizar susfunciones.

Corrección: Grado en que el software cumple sus especificaciones.

Flexibilidad: Facilidad o grado de esfuerzo necesario para modificar el softwareen funcionamiento.

Facilidad de Prueba: Esfuerzo necesario (o facilidad) para probar el software demodo que se tenga un cierto grado de confianza en que realiza adecuadamentesus funciones.

Facilidad de Manteniemiento: Facilidad o grado de esfuerzo para manteneroperativo el software mediante la corrección o depuración de los problemas quepuedan aparecer durante su funcionamiento.


139

Transportabilidad: Facilidad o grado de esfuerzo necesario para transportar omigrar el software de un entorno de operación a otro.

Capacidad de reutilización: Capacidad o grado de esfuerzo para que el softwareo alguna de sus partes puedan ser utilizadas en otros desarrollos de software.

Capacidad de Interoperación: Capacidad o grado de esfuerzo necesario paraque el software o un sistema puedan operar conjuntamente con otros sistemas oaplicaciones de software.

Cada factor deteminante de la calidad se descompone, a su vez, en unaserie de criterios o propiedades que determinan su calidad, Los factores sesuponen conceptos de alto nivel que, como la propiedad genérica de la calidad,son demasiado abstractos para ser significativos o poder ser medidos o evaluadosdirectamente. Por lo tanto, existen una serie de criterios de calidad de más bajonivel osea más detallados. Estas propiedades elementales o criterios sonpropiedades internas del software, que no dependen en su apreciación de quiénesté observándolas y que los desarrolladores de software consideran que influyenen la calidad, algunos de estos son:

Facilidad de Operación: Propiedades del software que determinan la facilidad delas operaciones y de los procedimientos relativos a la explotación del software.

Facilidad de Comunicación: Propiedades del software que proporciona1 eficaciay facilidad en las comunicaciones.

Facilidad de Formación o Aprendizaje: Propiedades del software queproporcionan al usuario información de operaciones reales o que facilitan lafamiliarización inicial con el producto.

Control de Accesos: Propiedades del software que proporcionan facilidades parael control de accesos al software y a los datos que maneja.

Facilidad de Auditoria: Propiedades del software que proporcionan facilidadespara realizar auditoria del software, de los datos empleados o de los resultadosobtenidos.

Efieciencia de ejecución: Propiedades del software que proporcionan unconsumo mínimo de recursos de procesamiento al realizar sus operaciones.

Eficiencia de Almacenamiento: Propiedades del software que proporcionan unasnecesidades mínimas de memoria para su operación.

Exactitud o Precisión: Propiedades del software que proporcionan el grado deprecisión requerido para los resultados que hay que obtener.


140

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

Tolerancis a Fallos: Propiedades que proporcionan la continuidad delfuncionamiento bajo condiciones no habituales.

Modularidad: Propiedades del software que proporcionan una estructura demódulos adecuadamente independientes.

Simplicidad: Propiedades del software que proporcionan la implantación defuncioncs de la manera más comprensible posible.

Compleción: Propiedades del software que proporcionan la implantación total detodas las funciones requeridas.

Rastreabilidad o facilidad de Traza: Propiedades del software que proporcionanuna taza o pista reconocible desde los requisitos hasta su implantación en relacióna un desarrollo específico y a un determinado entorno de operaciones.

Autodescripción: Propiedades del software que proporcionan explicacionessobre el desarrollo de cada función.

Capacidad de Expansión: Propiedades del software que proporcionan facilidadespara añadir nuevas capacidades funcionales o datos al sistema.

Generalidad: Propiedades del software que proporcionan amplitud a las funcionesrealizadas.

Instrumentación: Propiedades de] software que proporcionan la posibilidad deobservar el comportamiento del software durante su ejecución.

Independencia entre Sistema y Software: Propiedades del software quedeterminan su dependencia de su entorno lógico de trabajo.

Independencia del Hardware: Propiedades del software que determinan sudependencia de su entorno físico de trabajo (CPU, dispositivos, etc.).

Normalización o Compatibilidad de Comunicaciones: Propiedades delsoftware que favorecen una fácil intercomunicación del sistema con otros.

Normalización o Compatibilidad de Datos: Propiedades del software quedeterminan la posibilidad de utilización común de datos con otros sistemas.

Este tipo de modelos de evaluación de la calidad han gozado de una granaceptación en el mundo del software. Esto ha motivado que se hayan intentadoestablecer como estándares por parte de diversos organismos. Así, la norma IEEE1061 propone un modelo de medición muy parecido al de McCall denominado


141

modelo factor/criterio/métrica, y la norma ISO 9126 establece un modelo propio decalidad cuya base es similar al de McCaIl.

En los años ochenta, cambió el enfoque de los modelos de evaluación de lacalidad, ya que se impulsó la creación de modelos particulares para cada empresao para cada proyecto en vez de utilizar un mismo modelo para todos los casos, seimplantó así, de forma efectiva, el concepto de calidad relativa. En el caso de Gilb,se propone la creación de una especificación de requisitos de calidad para cadaproyecto, que deben escribir conjuntamente el usuario y el analista. Se tratafundamentalmente de determinar una lista de las características que definen lacalidad de la aplicación. Dichas características pueden ser totalmente originales,aunque lo más normal es que se inspiren o se tomen directamente de alguno delos modelos tradicionales. Las distintas características se pueden medir mediantevarias subcaracterísticas o métricas detalladas. Para cada una de éstas se debenespecificar los siguientes conceptos:

• Nombre y definición de la característica.• Escala o unidades de medición.• Recogida de datos o prueba.• El peor valor aceptable.• El valor previsto.• El valor óptimo.• El valor del sistema actual.• Comentarios.

En algunos casos, este enfoque de Gilb se ha asociado indirectamente a lafilosofía QFD (Quality Function Deplovrnent: Despliegue de la función de lacalidad) que se aplica en el ámbito de la gestión de la calidad industrial, aunqueexisten trabajos específicos de aplicación de QFD al software. Por otra parte, elenfoque de GiIb ha inspirado trabajos posteriores como el del proyectoCOQUAMO (Constructive Quality Model: Modelo Constructivo de la Calidad) quepropone una herramienta automatizada que ayuda a determinar (medianteplantillas) el modelo de calidad más apropiado para un proyecto.

Otro enfoque relativista de medición de la calidad del software es elrepresentado por el paradigma GQM (Goal-Question-Metric: Objetivo-Pregunta-Métrica) propuesto por Basili y Rombach. Aunque se trata de un enfoque generalde la medición, se trata de un método muy apropiado para evaluar la calidad delsoftware en cada proyecto. La idea consiste en que toda actividad de medicióndebe estar precedida por la identificación de un objetivo a lograr, que lleva aplantearse una serie de interrogantes sobre aspectos más puntuales de la calidad,esto llevará, a su vez, a disponer de una serie de métricas que nos permitanresponderlas. Aunque inicialmente puede parecer poco práctico el uso del modeloGQM, la reflexión que implica su construcción es valiosa ya que permite aclarar elconcepto de calidad que se persigue en el proyecto.


142

Por último, se debe decir que existe un enfoque más primitivo de medir lacalidad que se basa en considerarla equivalente a la ausencia de “defectos”,entendidos éstos como fallos, defectos o errores conocidos. La ventaja de estamanera de medir es que los datos sobre defectos se pueden obtener fácilmentesólo con mantener un sistema de registro de la información generada en elproyecto a partir de los datos aportados por las técnicas de detección de defectos.Los informes de las revisiones donde se indican los defectos encontrados, losresultados de las pruebas del software, las peticiones de cambios que debegestionar la gestión de la configuración, etc. Es muy habitual obtener medidas querelacionan el número de “defectos” con el tamaño del software. Así, por ejemplo,una propuesta típica de recolección de datos incluye:

• N° de problemas informados.• N° de problemas evaluados.• N° de problemas reales.• N° de problemas abiertos, pendientes de resolución.• N° de problemas cerrados.• Tiempo que permanece un problema abierto.• Tiempo que permanece un problema hasta ser evaluado.• Distribución de problemas por fase del desarrollo, por prioridad, por categoría(grave, leve, estético), etc.

Este enfoque de medición está inspirado en el control estadístico deprocesos aplicado en la industria convencional de fabricación. Uno de los casosmás conocidos de aplicación de este enfoque es el del programa de mediciónaplicado por Grady en Hewlett-Packard. El problema principal de este enfoque esque la existencia de un defecto no siempre acarrea un problema de calidad en elsoftware y, por lo tanto, resulta menos riguroso que otros modelos. Sin embargo,cuenta con la ventaja de que, en una empresa mínimarnente organizada, larecogida de datos resulta barata y relativamente sencilla.

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

Esta norma Internacional fue publicada en 1992, la cual es usada para laevaluación de la calidad de software, llamado “Information technology-Softwareproduct evaluation-Quality characteristics and guidelines for their use”; o tambiénconocido como ISO 9126 (o ISO/IEC 9126). Este estándar describe 6características generales: Fucionalidad, Confiabilidad, Usabilidad, Eficiencia,Mantenibilidad, y Portabilidad.

La norma ISO/IEC 9126 permite especificar y evaluar la calidad del softwaredesde diferentes criterios asociados con adquisición, requerimientos, desarrollo,uso, evaluación, soporte, mantenimiento, aseguramiento de la calidad y auditoriade software. Los modelos de calidad para el software se describen así:


143

Calidad interna y externa: Especifica 6 características para calidad interna yexterna, las cuales, están subdivididas. Estas divisiones se manifiestanexternamente cuando el software es usado como parte de un sistema Informático,y son el resultado de atributos internos de software.

Calidad en uso: Calidad en uso es el efecto combinado para el usuario final delas 6 características de la calidad interna y externa del software. Especifica 4características para la calidad en uso.

Al unir la calidad interna y externa con la calidad en uso se define unmodelo de evaluación mas completo, se puede pensar que la usabilidad delmodelo 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 lafuncionabilidad del software y la calidad en uso se puede asumir como la formaque lo asimila o maneja el usuario final. Si se unen los dos modelos, se puededefinir que los seis indicadores del primer modelo tienen sus atributos y el modelode calidad en uso sus 4 indicadores pasarían hacer sus atributos, mirándolográficamente quedaría asi:

Figura 23: Norma de Evaluación ISO/IEC 9126

Se establecen categorías para las cualidades de la calidad externa e internay 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 variosindicadores; estas se pueden medir por métrica interna o externa.


144

Figura 24: Evaluación Interna, externa y Calidad de Uso ISO/IEC 9126

Las definiciones se dan para cada característica y subcaracterística decalidad del software que influye en la calidad. Para cada característica ysubcaracterística, la capacidad del software es determinada por un conjunto deatributos internos que pueden ser medidos. Las características y subcaracterísticas se pueden medir externamente por la capacidad del sistema quecontiene el software.

7.2.1 Funcionalidad

Funcionalidad es la capacidad del software de cumplir y proveer lasfunciones para satisfacer las necesidades explícitas e implícitas cuando esutilizado en condiciones específicas. A continuación se muestra la característicade Funcionalidad y las subcaracterísticas que cubre:


145

Figura 25: Característica de Funcionalidad

La funcionalidad se divide en 5 criterios:

Adecuación: La capacidad del software para proveer un adecuado conjunto defunciones que cumplan las tareas y objetivos especificados por el usuario.

Exactitud: La capacidad del software para hacer procesos y entregar losresultados solicitados con precisión o de forma esperada.

Interoperabilidad: La capacidad del software de interactuar con uno o mássistemas específicos.

Seguridad: La capacidad del software para proteger la información y los datos demanera que los usuarios o los sistemas no autorizados no puedan acceder a ellospara realizar operaciones, y la capacidad de aceptar el acceso a los datos de losusuarios o sistemas autorizados

Conformidad de la funcionalidad: La capacidad del software de de cumplir losestándares referentes a la funcionalidad.

7.2.2 Confiabilidad

La confiabilidad es la capacidad del software para asegurar un nivel defuncionamiento adecuado cuando es utilizando en condiciones especificas. En estecaso al confiabilidad se amplia a sostener un nivel especificado de funcionamiento yno una función requerida.


146

Figura 26: Característica de Confiabilidad

La confiabilidad se divide en 4 criterios:

Madurez: La capacidad que tiene el software para evitar fallas cuando encuentraerrores. Ejemplo, la forma como el software advierte al usuario cuando realizaoperaciones en la unidad de diskett vacia, o cuando no encuentra espaciosuficiente el disco duro donde esta almacenando los datos.

Tolerancia a errores: La capacidad que tiene el software para mantener un nivelde funcionamiento en caso de errores.

Recuperabilidad: La capacidad que tiene el software para restablecer sufuncionamiento adecuado y recuperar los datos afectados en el caso de una falla.

Conformidad de la fiabilidad: La capacidad del software de cumplir a losestándares o normas relacionadas a la fiabilidad.

7.2.3 Usabilidad

La usabilidad es la capacidad del software de ser entendido, aprendido, yusado en forma fácil y atractiva. Algunos criterios de funcionalidad, fiabilidad yeficiencia afectan la usabilidad, pero para los propósitos de la ISO/IEC 9126 ellosno clasifican como usabilidad. La usabilidad esta determinada por los usuariosfinales y los usuarios indirectos del software, dirigidos a todos los ambientes, a lapreparación del uso y el resultado obtenido.


147

Figura 27: Característica de Usabilidad

La usabilidad se divide en 5 criterios:

Entendimiento: La capacidad que tiene el software para permitir al usuarioentender si es adecuado, y de una manera fácil como ser utilizado para las tareasy las condiciones particulares de la aplicación. En este criterio se debe tener encuenta la documentación y de las ayudas que el software entrega.

Aprendizaje: La forma como el software permite al usuario aprender su uso.También es importante considerar la documentación.

Operabilidad: La manera como el software permite al usuario operarlo ycontrolarlo.

Atracción: La presentación del software debe ser atractiva al usuario. Esto serefiere a las cualidades del software para hacer más agradable al usuario,ejemplo, el diseño gráfico.

Conformidad de uso: La capacidad del software de cumplir los estándares onormas relacionadas a su usabilidad.

7.2.4 Eficiencia

La eficiencia del software es la forma del desempeño adecuado, de acuerdoa al número recursos utilizados según las condiciones planteadas. Se debe teneren cuenta otros aspectos como la configuración de hardware, el sistema operativo,entre otros.


148

Figura 28: Característica de Eficiencia


Comportamiento de tiempos: Los tiempos adecuados de respuesta yprocesamiento, el rendimiento cuando realiza su función en condicionesespecificas. Ejemplo, ejecutar el procedimiento mas complejo del software yesperar su tiempo de respuesta, realizar la misma función pero con mas cantidadde registros.

Utilización de recursos: La capacidad del software para utilizar cantidades ytipos adecuados de recursos cuando este funciona bajo requerimientos ocondiciones establecidas. Ejemplo, los recursos humanos, el hardware,dispositivos externos.

Conformidad de eficiencia: La capacidad que tiene el software para cumplir conlos estándares o convenciones relacionados a la eficiencia.

7.2.5 Capacidad de mantenimiento

La capacidad de mantenimiento es la cualidad que tiene el software paraser modificado. Incluyendo correcciones o mejoras del software, a cambios en elentorno, y especificaciones de requerimientos funcionales.


149

Figura 29: Característica de Mantenimiento

El mantenimiento se divide en 5 criterios:

Capacidad de ser analizado: La forma como el software permite diagnósticos dedeficiencias o causas de fallas, o la identificación de partes modificadas.

Cambiabilidad: La capacidad del software para que la implementación de unamodificación se pueda realizar, incluye también codificación, diseño ydocumentación de cambios.

Estabilidad: La forma como el software evita efectos inesperados paramodificaciones del mismo.

Facilidad de prueba: La forma como el software permite realizar pruebas a lasmodificaciones sin poner el riesgo los datos.

Conformidad de facilidad de mantenimiento: La capacidad que tiene elsoftware para cumplir con los estándares de facilidad de mantenimiento.

7.2.6 Portabilidad

La capacidad que tiene el software para ser trasladado de un entorno a otro.


150

Figura 30: Característica de Portabilidad


Adaptabilidad: Es como el software se adapta a diferentes entornosespecificados (hardware o sistemas operativos) sin que implique reaccionesnegativas ante el cambio. Incluye la escalabilidad de capacidad interna (Ejemplo:Campos en pantalla, tablas, volúmenes de transacciones, formatos de reporte,etc.).

Facilidad de instalación: La facilidad del software para ser instalado en unentorno especifico o por el usuario final.

Coexistencia: La capacidad que tiene el software para coexistir con otro o variossoftware, la forma de compartir recursos comunes con otro software o dispositivo.

Reemplazabilidad: La capacidad que tiene el software para ser remplazado porotro software del mismo tipo, y para el mismo objetivo. Ejemplo, la remplazabilidadde una nueva versión es importante para el usuario, la propiedad de poder migrarlos datos a otro software de diferente proveedor.

Conformidad de portabilidad: La capacidad que tiene el software para cumplircon los estándares relacionados a la portabilidad.

7.2.7 Calidad en uso

Calidad en uso es la calidad del software que el usuario final refleja, laforma como el usuario final logra realizar los procesos con satisfacción, eficienciay exactitud. La calidad en uso debe asegurar la prueba o revisión de todas lasopciones que el usuario trabaja diariamente y los procesos que realizaesporádicamente relacionados con el mismo software.


151

Figura 31: Característica de Calidad en Uso


Eficacia: La capacidad del software para permitir a los usuarios finales realizar losprocesos con exactitud e integridad.

Productividad: La forma como el software permite a los usuarios emplearcantidades apropiadas de recursos, en relación a la eficacia lograda en uncontexto específico de uso. Para una empresa es muy importante que el softwareno afecte al productividad del empleado

Seguridad: Se refiere al que el Software no tenga niveles de riesgo para cuasardaño a las personas, instituciones, software, propiedad intelectual o entorno. Losriesgos son normalmente el resultado de deficiencias en la funcionalidad(Incluyendo seguridad), fiabilidad, usabilidad o facilidad de mantenimiento.

Satisfacción: La satisfacción es la respuesta del usuario a la interacción con elsoftware, e incluye las actitudes hacia el uso del mismo. A continuación sedescribe un cuadro donde podemos resumir las características y cada uno de susatributos, este cuadro le ayudara a visualizar elporceso de evaluacion.

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

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


152

7.3.1 Estado del Software

Que se refiere al conocimiento del el estado del software, estableciendo sise trata de un desarrollo sin terminar o un producto terminado para la entrega alcliente.

7.3.2 Identificar el tipo de software

Donde se debe especificar el tipo de software a evaluar, si es un sistemaoperativo, software de seguridad, software de ofimática, lenguaje deprogramación, base de datos, aplicativo a la medida, entre otros.

7.3.3 Perfiles de Evaluadores

Teniendo como marco conceptual al estándar ISO/IEC9126, se considerantres perfiles de usuario, a un alto nivel de abstracción para desarrollo de software,usuarios finales, desarrolladores, y gerentes. El estándar afirma que la relativaimportancia de las características de calidad varía dependiendo del punto de vistaconsiderado y de la crítica de los componentes del software a evaluar.

La visión del usuario final, concierne al interés de los mismos en usar elsoftware, como así también su performance, su eficiencia, su facilidad de uso,entre otros aspectos. Los usuarios finales no están interesados en característicasinternas o de desarrollo del software.

La visión de calidad del desarrollador debe considerar no sólo losrequerimientos del software para la visión del usuario sino también la calidad paralos desarrollos intermedios resultantes de las actividades de la fase de desarrollo.Se debe tener en cuenta que los desarrolladores están preocupados encaracterísticas de calidad del software como mantenibilidad y portabilidad.

La visión de calidad del gerente es una visión integradora, que incorporarrequerimientos de negocio a las características individuales. Ejemplo, un gerenteesta interesado en el equilibrio entre la mejora del software y los costos y tiemposestablecidos.

7.3.4 Especificar los Objetivos

Se debe conocer los objetivos tanto generales como específicos del software.

7.3.5 Aplicar el modelo de calidad

Donde se debe elaborar un instrumento o formato donde aplique el modelode calidad externo e interno y calidad de uso. Si existe un comité o conjunto depersonas encargadas de la evaluación, el instrumento debe ser aprobado por losparticipantes.


153

7.3.6 Criterios de la evaluación

Donde se tiene en cuenta los criterios de evaluación que parten de los 7indicadores principales los cuales fueron especificacdos en la lección anterior. Loscriterios para evaluar el software se dividen en dos grandes bloques: uno dedicadoa criterios que son aplicables a cualquier tipo de software, y otro conjuntocompuesto por criterios adaptables al grupo de software evaluados. En este casose definen los criterios de la evaluación según el tipo de software, para el cualdebe conformar un equipo evaluador, este ejercicio ayuda a definir que opcionesse deben evaluar con más detalle y valor.

tipos de software ejemplos orden del criterio deevaluación

evaluadores

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

1. Seguridad2. Tiempo de respuesta3. Exactitud de lainformación4. Recuperabilidad

personal de sistemas,contador o financiero,auxiliar, digitador

administrativos recursos humanos,administración dedocumentos,hospitalarios, etc

1. Tiempo de respuesta2. Seguridad3. Exactitud de lainformación4. Recuperabilidad

personal de sistemas,administrativo,auxiliar, digitador

educativos materiasacadémicas,enciclopedias,tutores, manuales

1. Facilidad decomprensión2. calidad grafica3. portabilidad

personal de sistemas,docente, alumno

a la medida producción, radioterapia, control demaquinas, etc

Los criterios o indicadoresestán sujetos a laactividad específica delsoftware

personal de sistemas,personal queconozcael procesomanual o automático,cliente

Tabla 38: Tabla de criterios a tener en cuenta al evaluar un software

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


154

7.3.8 Establecer criterios: La persona que participa en el proceso de evaluacióndebe tener criterios con respecto al indicador que se esta analizando, Esimportante tener en cuenta que el criterio debe ajustar al tipo de software que seva a evaluar.

7.3.9 Tomar medidas: Para la medición, las métricas seleccionadas se aplican alsoftware. Los resultados son valores expresados en las escalas de las métricas,definidos previamente.

7.3.10 Resultados: Los resultados del proceso de evaluación genera un cuadrode resultados por cada uno de losprincipales indicadores y el total final deresultado.

7.3.11 Documentación: El proceso de evaluación se documenta, indicando lafecha, empresa, los cargos, nombres y apellidos, dependencia de las personasque participan en el proceso de evaluación, especificando las etapas en las queparticiparon.

7.3.12 Seguimiento: Donde si el resultado de la evaluación tiene observaciones oindicadores de calidad bajos, y el personal que lo evalúa permite realizar lacorrección, se programa otra evaluación donde se verifique que el proceso mejora,el tiempo que se estime debe influir en los criterios de la aproxima evaluación.

A partir de cada una de las características, y subcaracterísticas de la normaISO/IEC 9126, se ha incluído las preguntas generales para cada una de ellas, lasiguiente tabla muestra las características, la pregunta planteada para ella, lassubcaracterísticas y los cuestionamientos para cada una de ellas:

CARACTERISTICA PREGUNTA SUBCARATERISTICA PREGUNTAADECUACIÓN ¿Tiene el conjunto de

funciones apropiadaspara las tareasespecificadas?

EXACTITUD ¿Hace lo que fueacordado en formaesperada y correcta?

INTEROPERABILIDAD ¿Interactúa con otrossistemas especificados?

FUNCIONALIDAD ¿Las funciones yPropiedadessatisfacenlas necesidadesExplícitas eimplícitas;esto es, el qué?

CONFORMIDAD ¿Está de acuerdo con lasleyes o normas yestándares, u otrasprescripciones?

MADUREZ ¿Con qué frecuenciapresenta fallas pordefectos o errores?

CONFIABILIDAD ¿Puede mantenerelnivel derendimiento,bajo ciertascondiciones

TOLERANCIA AERRORES

¿Si suceden fallas, comose comporta en cuanto ala performancia


155

especificada?y por cierto tiempo?

RECUPERABILIDAD ¿Es capaz de recuperardatos en caso de fallas?

ENTENDIMIENTO ¿Es fácil de entender yreconocer la estructura yla lógica y suaplicabilidad?

APRENDIZAJE ¿Es fácil de aprender ausar?

OPERABILIDAD ¿Es fácil de operar ycontrolar?

USABILIDAD ¿El software, esfácil de usar y deaprender?

ATRACCIÓN ¿Es atractivo el diseñodel software?

COMPORTAMIENTODE TIEMPOS

¿Cuál es el tiempo derespuesta y performanciaen la ejecución de lafunción?

EFICIENCIA ¿Es rápido yminimalista encuanto a uso derecursos, bajociertascondiciones?

UTILIZACION DERECURSOS

¿Cuántos recursos usa ydurante cuánto tiempo?

CAPACIDAD DE SERANALIZADO

¿Es fácil diagnosticar unafalla o identificar partes amodificar?

CAMBIALIDAD ¿Es fácil de modificar yadaptar?

ESTABILIDAD ¿Hay riesgos o efectosinesperados cuando serealizan cambios?

CAPACIDAD DEMANTENIMIENTO

¿Es fácil demodificar y testear?

FACILIDAD DEPRUEBA

¿Son fáciles de validarlas modificaciones?

ADAPTABILIDAD ¿Es fácil de adaptar aotros entornos con loprovisto?

FACILIDAD DEINSTALACION

¿Es fácil de instalar en elambiente especificado?

REMPLAZABILIDAD ¿Es fácil de usarlo enlugar de otro softwarepara ese ambiente?

PORTABILIDAD ¿Es fácil detransferir de unambiente a otro?

COEXISTENCIA ¿Comparte sin dificultarecursos con otrosoftware o dispositivo?

EFICACIA ¿La eficaz el softwarecuando el usuario finalrealiza los procesos?

CALIDAD EN USO ¿Muestra elusuario finalaceptación yseguridad delsoftware?

PRODUCTIVIDAD ¿Muestra el usuario finalrendimiento en sus tareascotidianas del procesoespecífico?

SEGURIDAD ¿El software tiene nivelesde Riesgo que causandaño al usuario final?


156

Tabla 39: Características y Subcaraterísticas ISO/IEC 91267.4 LECCIÓN 4: MÉTRICAS EXTERNAS BASADOS EN ISO/IEC 9126

Además de los cuestionarios generales, se presenta cada característica, lasub característica, y las métricas a evaluar, estas métricas pueden ser la basepara elaborar cuestionarios teniendo en cuenta la norma ISO/IEC 9126, parapoder realizar el análisis de las métricas externas de acuerdo a las caractrísticaspropias del software a evaluar y a las características y subcaracteríaticasseleccionadas para la evaluación, en la siguiente tabla se muestra las métricasexternas para evaluación de software.

característica sub característica nombre métricaFuncionalidad Idoneidad Adecuación funcional

Integridad funcional de aplicaciónCobertura de aplicación funcionalEstabilidad de la especificación funcional(volatilidad)

Precisión Precisión a la expectativaPrecisión de cómputoPrecisión

Interoperabilidad Intercambiabilidad de datos (formato de basede datos))Intercambiabilidad de datos (intento delusuario de éxito basado en el intercambio)

Seguridad Acceso auditabilidadAcceso controlabilidadDatos de prevención de la corrupción

Funcionalidad deCumplimiento

Cumplimiento funcional

Interfaz estándar de cumplimientoConfiabilidad Madurez latente estimada de densidad de fallos

Falta de densidad en contra de casos depruebaFalta de resoluciónError de la densidadError de la eliminaciónTiempo medio entre fallosPrueba de cobertura (cobertura de lasoperaciones especificadas escenario deprueba)Prueba de madurez

Tolerancia a Fallos Evitar desgloseEvitar la faltaEvitar el funcionamiento incorrecto

Recuperación DisponibilidadTiempo medio de inactividadTiempo medio de recuperaciónReinicioRestaurabilidadRestaurar la eficacia

Fiabilidad deCumplimiento

Confiabilidad de cumplimiento


157

Usabilidad Comprensibilidad Integridad de la DescripciónIntegridad de accesoIntegridad de acceso en usoDemostración de la eficaciaFunciones evidentesFunción comprensibilidadComprender la entrada y salida

Aprendizaje Facilidad de función de aprendizajeFacilidad de aprendizaje para realizar unatarea en usoEficacia de la documentación del usuario y / osistema de ayudaEficacia de la documentación del usuario y / oayudar a los sistemas en usoAyuda de accesibilidadAyuda de frecuencia

Operabilidad Coherencia operacional en el usoCorrección de erroresCorrección de errores en el usoDisponibilidad predeterminada del valor deusoMensaje comprensibilidad en usoNo necesita explicación en mensajes de errorRecuperación de error operativo en usoTiempo entre las operaciones de un errorhumano en usoCapacidad de deshacer (corrección de errordel usuario)PersonalizaciónOperación de reducción de procedimientoAccesibilidad física

Atractivo Atractivo de interacciónPersonalización de interfaz de aspecto

Cumplimiento deUsabilidad

Usabilidad de cumplimiento

Eficiencia Tiempo deComportamiento

Tiempo de respuesta

Tiempo de respuesta (tiempo medio derespuesta)RendimientoRendimiento (cantidad promedio derendimiento)Rendimiento (peor ratio de rendimiento decaso)Tiempo de respuestaTiempo de vuelta (media para el tiempo deentrega)Tiempo de vuelta (peor caso cociente deltiempo de entrega)Tiempo de espera

Utilización de Recursos Dispositivos Entrada/ Salida de utilizaciónEntrada / Salida límites de cargaEntrada/Salida errores relacionadosEntrada/Salida radio de cumplimiento


158

Tiempo de espera de E / S de la utilización delos dispositivosMáxima utilización de la memoriaMedia de ocurrencia de errores de memoriaRelación entre el error de memoria / horaMáxima utilización de la transmisiónMedios de comunicación la utilización deldispositivo de equilibrioMedia de ocurrencia de errores detransmisiónMedia de error de transmisión por tiempoUtilización de la capacidad de transmisión

Cumplimiento deEficiencia

Eficiencia de Cumplimiento

Mantenimiento Analizabilidad Pistas de capacidad de auditoriaApoyar la función de diagnósticoFalta capacidad de análisisFalta de eficiencia de análisisEstado de capacidad de supervisión

Modificación Cambiar la eficiencia del cicloCambiar la implementación mientrastranscurre el tiempoModificación de la complejidadParametrizado modificableCambio del software de capacidad de control

Estabilidad Cambio de porcentaje de éxitoModificación de la localización delimpacto(Error emergentes después delcambio)

Comprobabilidad Disponibilidad de una función de pruebaVuelva a probar la eficienciaPrueba de reinicio

Cumplimiento deMantenimiento

Cumplimiento de mantenimiento

Portabilidad Adaptabilidad Capacidad de adaptación de las estructurasde datosHardware adaptabilidad ambientalOrganización de adaptación al medioambienteTrasladar la facilidad de usoSistema de adaptación de software del medioambiente

Instalación Facilidad de instalaciónFacilidad de instalación, Reintentar

Co-existencia Disponible co-existenciaSustituir Uso continuo de los datos

Función de la inclusiónApoyo a los usuarios la coherencia funcional

CumplimientoPortabilidad

Cumplimiento de portabilidad

Tabla 40: Métricas Externas ISO/IEC 9126


159

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

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

característica sub característica nombre métricaFuncionalidad IDONEIDAD Adecuación funcional

Integridad funcional de aplicaciónCobertura de aplicación funcionalEstabilidad de la especificación funcional(volatilidad)

PRECISIÓN Precisión de cómputoPrecisión

INTEROPERABILIDAD Intercambiabilidad de datos (formato debase de datos)Coherencia de interfaz (protocolo)

SEGURIDAD Acceso auditabilidadAcceso controlabilidadDatos de prevención de la corrupciónCifrado de datos

FUNCIONALIDAD DECUMPLIMIENTO

Cumplimiento funcional

Entre sistemas estándar de cumplimientoConfiabilidad MADUREZ Detección de fallas

Eliminación de fallosPrueba de adecuación

TOLERANCIA A FALLOS Evitar fallasEvitar el funcionamiento incorrecto

RECUPERACIÓN RestauraciónRestauración efectiva

FIABILIDAD DECUMPLIMIENTO

Confiabilidad de cumplimiento

Usabilidad COMPRENSIBILIDAD Integridad de la DescripciónDemostración de la capacidadFunciones evidentesFunción de la comprensibilidad

APRENDIZAJE Integridad de la documentación del usuarioy / o sistema de ayuda

OPERABILIDAD Entrada, asegurar su validezUsuario, cancela la operaciónUsuario, deshacer la operaciónPersonalización


160

Accesibilidad físicaEstado de operación capacidad devigilanciaConsistencia operacionalClaridad en los mensajesInterfaz claridad en los elementosRecuperación de errores operacional

ATRACTIVO Atractivo de interacciónAparición de personalización

CUMPLIMIENTO DEUSABILIDAD

Usabilidad de cumplimiento

Eficiencia TIEMPO DECOMPORTAMIENTO

Tiempo de respuesta

Rendimiento de tiempoTiempo por turno

UTILIZACIÓN DERECURSOS

Utilización de Entradas y Salidas

Utilización de mensaje de Entrada y SalidaUtilización de memoriaUtilización de memoria de mensajes densosTransmisión de Utilización

CUMPLIMIENTO DEEFICIENCIA

Eficiencia de Cumplimiento

Mantenimiento ANALIZABILIDAD Actividad de grabaciónPreparación de la función de diagnóstico

MODIFICACIÓN Cambio de RegistrosESTABILIDAD Impacto del cambio

Modificación de la localización del impactoCOMPROBABILIDAD Integridad de los incorporados en las

pruebas de funciónAutonomía de la capacidad de pruebaPrueba de observabilidad de progreso

CUMPLIMIENTO DEMANTENIMIENTO

Cumplimiento de mantenimiento

Portabilidad ADAPTABILIDAD Capacidad de adaptación de las estructurasde datosHardware adaptabilidad ambientalOrganización de adaptación al medioambienteTrasladar la facilidad de usoSistema de adaptación de software delmedio ambiente

INSTALACIÓN Facilidad de instalación, vuelva a intentarEsfuerzo de instalaciónFlexibilidad de instalación

CO-EXISTENCIA Disponible co-existenciaSUSTITUIR Uso continuo de los datos

Función de la inclusión


161

CUMPLIMIENTOPORTABILIDAD

Cumplimiento de portabilidad

Tabla 41: Métricas Internas ISO/IEC 9126


162

CAPITULO 8

METODOLOGIAS DEEVALUACIÓN DE LAARQUITECTURA DEL

SOFTWARE


163

INTRODUCCIÓN

La Arquitectura de Software es una práctica joven tiene sus orígenes en ladécada de 1960, pero solo hasta los años 90, Dewayne Perry y Alexander Wolf, laexponen en el sentido que hoy se conoce. A partir de ese momento la Arquitecturade Software comenzó a tener auge vertiginoso tanto en la academia como en laindustria, desarrollándose los de estilos arquitectónicos, los ADL (Leguajes deDescripción Arquitectónica), que aunque poco difundidos, han dado al traste con lacreación de diferentes tipos de arquitecturas como las basadas en componentes.

La Arquitectura de Software se convierte en un factor importante en cuantoa lograr en ella una alta calidad la importancia radica en que la arquitectura es elcorazón de todo sistema informático y determina cuáles serán los niveles decalidad asociados al sistema.

No sirve de nada un sistema que no cumple con los atributos de calidad quese especificaron en los requerimientos no funcionales de los clientes. Por lo quediseñar una correcta arquitectura va a determinar el éxito o fracaso de un sistemade software, en la medida que esta cumpla o no con sus objetivos. Debido a esto,para reducir los riesgos, y como buena práctica de ingeniería, es recomendablerealizar evaluaciones a la arquitectura del software.

En este capítulo se explica el procedimiento para realizar la evaluación deuna arquitectura, destacando algunos métodos de evaluación existentes, al finalse hará el estudio de una propuesta denominada MECABIC o Método deEvaluación de la Calidad de Arquitecturas Basadas en la Integración deComponentes, cuyo objetivo principal es evaluar y analizar la calidad de este tipode Arquitectura de Software.

Aquí se hará la revisión de los diferentes métodos de la evaluación dearquitecturas de software, para analizar e identificar potencialidades de losdiferentes métodos o procedimientos y hacer el estudio de las característicascomparativas de cada una de ellas.

Se realizará un estudio del estado del arte de la evaluación de arquitecturasde software. Para introducirse en el tema se tratan aspectos como los principalesproblemas que causa la arquitectura en un proyecto, también se define que es laevaluación de arquitecturas, sus características, objetivos que persigue. Se haceademás un análisis de cuándo y por qué una determinada arquitectura debe serevaluada y los beneficios que reporta.


164

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

La evaluación de software es como un estudio de factibilidad que pretendedetectar posibles riesgos, y buscar recomendaciones para contenerlos, teniendoen cuenta que la evaluación se realiza antes de la implementación de la solución.El objetivo de evaluar una arquitectura es saber si puede habilitar losrequerimientos, atributos de calidad y restricciones para asegurar que el sistemaconstruido cumple con las necesidades de las personas que están relacionadascon el sistema.

La evaluación de una arquitectura de software es una tarea donde sepretende medir propiedades del sistema en base a especificaciones abstractas,como por ejemplo los diseños arquitectónicos. Las mediciones que se realizansobre una arquitectura de software pueden tener distintos objetivos de tipocualitativo, cuantitativo, o máximos y mínimos teóricos.

La medición cualitativa se aplica para la comparación entre arquitecturascandidatas y tiene relación con la intención de saber la opción que se adaptamejor a cierto atributo de calidad. La medición cuantitativa busca la obtención devalores que permitan tomar decisiones en cuanto a los atributos de calidad de unaarquitectura de software, el esquema general es la comparación con márgenesestablecidos, como lo son los requerimientos de desempeño, para establecer elgrado de cumplimiento de una arquitectura candidata, o tomar decisiones sobreella. La medición de máximo y mínimo teórico contempla los valores teóricos paraefectos de la comparación de la medición con los atributos de calidadespecificados, el conocimiento de los valores máximos o mínimos permite elestablecimiento claro del grado de cumplimiento de los atributos de calidad.

El propósito de realizar evaluaciones a la arquitectura, es para identificar yanalizar riesgos potenciales en su estructura y sus propiedades, que afecten alsoftware resultante, verificar que los requerimientos no funcionales esténpresentes en la arquitectura, así como determinar el grado de stisfacción de losatributos de calidad. Un atributo de calidad es una característica de calidad queafecta a un elemento, donde el término “característica” se refiere a aspectos nofuncionales y el termino “elemento” a componente.

La evaluación de la arquitectura puede realizarse en cualquier momento,pero se propone dos etapas distintas para realizarlas: La evaluación temprana quepuede realizarse sin necesidad de que la arquitectura esté completamenteespecificada para efectuar la evaluación, abarca las fases tempranas de diseño ydel desarrollo, y la evaluación tarde que se hace cuando la arquitectura ya estaestablecida y la implementación se ha completado.

Generalmente las evaluaciones a la arquitectura se hacen por miembros delequipo de desarrollo, arquitecto, diseñador, entre otros. Otro actor interesado por


165

los resultados de una evaluación es el cliente, ya que dependiendo de losresultados puede tomar decisiones de continuar o no con el proyecto.

Las ténicas de evaluación de arquitecturas se clasifican en técnicas cualitativas ytécnicas cuantitativas. Las técnicas cualitativas basadas en preguntas sobre laarquitectura (cuestionarios: abiertas y tempranas, checklist: específico del dominiode la aplicación, y escenarios: específicas del sistema, para arquitecturaavanzada), y las cuantitativas que utiliza métricas como acoplamiento, cohesividaden los módulos, profundidad en herencias, modificabilidad.

Generalmente las técnicas de evaluación cualitativas son utilizadas cuandola arquitectura está en construcción, mientras que las técnicas de evaluacióncuantitativas se usan cuando la arquitectura ya ha sido implantada.

Figura 32: Clasificación de las Técnicas de Evaluación.

Las evaluaciones pueden ser planeadas o no planeadas: Las planeadasque 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 presentancuando la arquitectura contiene varios defectos que han sido detectados en lasetapas tardías del desarrollo.

La arquitectura puede ser evaluada teniendo en cuenta la clasificación delos atributos de calidad, donde se hace la clasificación en dos categorías:

Observables vía ejecución que son aquellos atributos que se determinan delcomportamiento del sistema en tiempo de ejecución. La descripción de algunos deestos atributos se presenta en la siguiente tabla:

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


166

Funcionalidad Habilidad del sistema para realizar el trabajo para el cual fueconcebido.

Desempeño Es el grado en el cual un sistema o componente cumple con susfunciones designadas, dentro de ciertas restricciones dadas, comovelocidad, exactitud o uso de memoria

Confiabilidad Es la medida de la habilidad de un sistema a mantenerse operativo alo largo del tiempo

Seguridad externa Ausencia de consecuencias catastróficas en el ambiente. Es la medidade ausencia de errores que generan pérdidas de información

Seguridad interna Es la medida de la habilidad del sistema para resistir a intentos de usono autorizados y negación del servicio, mientras se sirve a usuarioslegítimos

Tabla 42: Descripción de atributos de calidad observables vía ejecución

No observables vía ejecución: aquellos atributos que se establecen duranteel desarrollo del sistema. La descripción de algunos de estos atributos se presentaen la siguiente tabla.

Atributo de calidad DescripciónConfigurabilidad Posibilidad que se otorga a un usuario experto a realizar ciertos

cambios al sistemaIntegrabilidad Es la medida en que trabajan correctamente componentes del sistema

que fueron desarrollados separadamente al ser integrados.Integridad Es la ausencia de alteraciones inapropiadas de la informaciónInteroperabilidad Es la medida de la habilidad de que un grupo de partes del sistema

trabajen con otro sistemaModificabilidad Es la habilidad de realizar cambios futuros al sistemaMantenibilidad Es la capacidad de someter a un sistema a reparaciones y evoluciónPortabilidad Es la habilidad del sistema para ser ejecutado en diferentes ambientes

de computación. Estos ambientes pueden ser hardware, software ouna combinación de los dos

Reusabilidad Es la capacidad de diseñar un sistema de forma tal que su estructurao parte de sus componentes puedan ser reutilizados en futurasaplicaciones

Escalabilidad Es el grado con el que se pueden ampliar el diseño arquitectónico, dedatos o procedimental

Capacidad de

Prueba

Es la medida de la facilidad con la que el software, al ser sometido auna serie de pruebas, puede demostrar sus fallas

Tabla 43: Descripción de atributos de calidad no observables vía ejecución

8.2 LECCIÓN 2: TÉCNICAS DE EVALUACIÓN DE ARQUITECTURAS DESOFTWARE

Las técnicas utilizadas para la evaluación de atributos de calidad requierengrandes esfuerzos del ingeniero de software para crear especificaciones ypredicciones. Estas técnicas requieren información del sistema a desarrollar queno está disponible durante el diseño arquitectónico, sino al principio del diseñodetallado del sistema.


167

Las técnicas existentes en la actualidad para evaluar arquitecturas permitenhacer una evaluación cuantitativa sobre los atributos de calidad a nivelarquitectónico, pero se tienen pocos medios para predecir el máximo (o mínimo)teórico para las arquitecturas de software. Debido al costo de realizar este tipo deevaluación, en muchos casos los arquitectos de software evalúancualitativamente, para decidir entre las alternativas de diseño. Se han propuestodiferentes técnicas de evaluación de arquitecturas de software, algunas son:Evaluación basada en escenarios, Evaluación basada en simulación, Evaluaciónbasada en modelos matemáticos y Evaluación basada en experiencia.

8.2.1 Evaluación basada en escenarios

Un escenario es una breve descripción de la interacción de alguno de losinvolucrados en el desarrollo del sistema con éste. Por ejemplo, un usuario hará ladescripción en términos de la ejecución de una tarea; un encargado demantenimiento hará referencia a cambios que deban realizarse sobre el sistema;un desarrollador se enfocará en el uso de la arquitectura para efectos de suconstrucción o predicción de su desempeño.

Un escenario consta de tres partes: El estímulo, que es la parte delescenario que explica o escribe lo que el involucrado en el desarrollo hace parainiciar la interacción con el sistema, incluye la ejecución de tareas, cambios en elsistema, ejecución de pruebas, configuración, etc. El contexto, que describe quésucede en el sistema al momento del estímulo. Y la respuesta que describe através de la arquitectura, cómo debería responder el sistema ante el estímulo.Este último elemento es el que permite establecer cuál es el atributo de calidadasociado.

Los escenarios permiten concretar y entender atributos de calidad. Kazmany Carriere coinciden en la importancia del uso de los escenarios, no sólo paraefectos de la evaluación de arquitecturas de software. Actualmente las técnicasbasadas en escenarios cuentan con dos instrumentos de evaluación relevantes, asaber: 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 presentalos atributos de calidad de un sistema de software, refinados hasta elestablecimiento de escenarios que especifican con suficiente detalle el nivel deprioridad de cada uno. La intención del uso del Utility Tree es la identificación delos atributos de calidad más importantes para un proyecto particular. No existe unconjunto preestablecido de atributos, sino que son definidos por los involucradosen el desarrollo del sistema al momento de la construcción del árbol.

El Utility Tree contiene como nodo raíz la utilidad general del sistema. Losatributos de calidad asociados al mismo conforman el segundo nivel del árbol, loscuales se refinan hasta la obtención de un escenario lo suficientemente concretopara ser analizado y otorgarle prioridad a cada atributo considerado. Cada atributo


168

de calidad perteneciente al árbol contiene una serie de escenarios relacionados, yuna escala de importancia y dificultad asociada, que será útil para efectos de laevaluación de la arquitectura.

8.2.1.2 Perfiles (Profiles): Un perfil o profile es un conjunto de escenarios,generalmente con alguna importancia relativa asociada a cada uno de ellos. El usode perfiles permite hacer especificaciones más precisas del requerimiento para unatributo de calidad. Los perfiles tienen asociados dos formas de especificación:

Los perfiles completos que definen los escenarios importantes como partedel perfil. Esto permite al ingeniero de software realizar un análisis de laarquitectura para el atributo de calidad estudiado de una manera completa, puestoque incluye todos los posibles casos. Su uso se reduce a sistemas relativamentepequeños y sólo es posible predecir conjuntos de escenarios completos paraalgunos atributos de calidad.

Los perfiles seleccionados que se asemejan a la selección de muestrassobre una población en los experimentos estadísticos. Se toma un conjunto deescenarios de forma aleatoria, de acuerdo a algunos requerimientos. Laaleatoriedad no es totalmente cierta por limitaciones prácticas, por lo que se fuerzala realización de una selección estructurada de elementos para el conjunto demuestra. Si bien es informal, permite hacer proposiciones científicamente válidas.

Para la definición de un perfil, es necesario seguir tres pasos: definición delas categorías del escenario, selección y definición de los escenarios para lacategoría y asignación del “peso” a los escenarios. La definición de categorías deescenarios divide la población de escenarios en poblaciones más pequeñas, quecubren aspectos particulares del sistema. La selección y definición de escenariospara cada categoría selecciona un conjunto de escenarios representativo para lasubpoblación. Luego, en la asignación del peso a los escenarios, dependiendo delperfil, el peso de un escenario tiene diferentes significados. Se definen escalasque de alguna forma sean cuantificables y puedan ser convertidas a pesosrelativos.

Cada atributo de calidad tiene un perfil asociado. Algunos perfiles puedenser usados para evaluar más de un atributo de calidad. Han sido seleccionadoscinco atributos de calidad que son considerados de mayor relevancia para unaperspectiva general de ingeniería de software, ellos son: desempeño(performance), mantenibilidad (maintainability), confiabilidad (reliability), seguridadexterna (safety) y seguridad interna (security).

La efectividad de la técnica es altamente dependiente de larepresentatividad de los escenarios. Existe la evaluación de funcionalidad basadaen escenarios, y es utilizada en el diseño orientado a objetos para especificarcomportamiento del sistema. La diferencia entre este tipo de evaluación y laevaluación arquitectónica basada en escenarios radica en que la última utiliza losescenarios para evaluar atributos de calidad, en lugar de verificar o describir


169

funcionalidad, además de que se usan otros escenarios para definir otros atributosde calidad. La siguiente tabla muestra para cada atributo de calidad, el perfilasociado, la forma en que se definen las categorías, el significado de los “pesos” yposibles métricas de evaluación.

Atributo Perfil Categorías Pesos MétricasMantenibilidad

Perfil demantenimiento(Maintainanceprofile)

Se organizanalrededor de lasinterfaces del sistema(sistema operativo,interfaces con elusuario, interfacescon otros sistemas).Los escenarios decambio describenmodificaciones en losrequerimientos

Indican laprobabilidad deocurrencia delcambio deescenario enun período detiempo

- Impacto en términode líneas de códigoque tienen quecambiarse- Se requiere unestimado de líneas decódigo de loscomponentesarquitectónicos.

Desempeño Perfil de uso(Usage profile)

Descompone losescenarios de usobasado en los tiposde usuario y/ointerfaces del sistema

Representan lafrecuenciarelativadel escenario

- Funcionalidad decomponentes- Comportamiento delsistema enrespuesta a losescenarios deuso en el perfil- Promedio y peorcaso de latencia porsincronización ysobrecarga en elsistema

Confiabilidad

Perfil de uso(Usage profile)

Confiabilidad de loscomponentes, generala confiabilidad de losescenarios de uso

Indica larobustezdel sistema

- Datos estimados deconfiabilidad delcomponente- Datos históricos deconfiabilidad delcomponente

SeguridadInterna

Perfil deseguridad(Securityprofile)Perfil de uso(usage profile)

Basada en todas lasinterfaces delsistema

Indica laprobabilidad defallas

Depende del aspectode seguridad a serevaluado. Porejemplo, ladisponibilidad puedeevaluarse en términosdel número de vecesque se ejecutanoperaciones deseguridad.

SeguridadExterna

Perfil de peligro(Hazard profile)

Se organizan deacuerdo adocumentosde certificación(puntos deinteracción delsistema con elmundo real, ocomponentes críticosdel sistema)

Indican laprobabilidad defalla uocurrencia deconsecuenciasdesastrosas.

Bosch (2000) noestablece ejemplos


170

Tabla 44: Perfiles, categorias, Pesos, y Métricas Asociados a atributos de Calidad

La evaluación basada en escenarios puede ser empleada para comparardos arquitecturas y para la evaluación absoluta de una arquitectura. La diferenciaestá en que la evaluación absoluta requiere mayor cantidad de datos estimados ycuantitativos necesarios para la evaluación.

La técnica se puede descompones en dos etapas: El análisis de impacto,que toma como entrada el perfil y la arquitectura de software, para cada escenariodel perfil, se evalúa el impacto de la arquitectura y se obtienen los resultados. Laetapa de predicción de resultados, donde los resultados serán usados parapronosticar el valor del atributo de calidad estudiado de acuerdo a las métricasexistentes.

8.2.2 Evaluación basada en simulación

La evaluación basada en simulación utiliza una implementación de alto nivelde la arquitectura de software. El enfoque básico consiste en la implementación decomponentes de la arquitectura y la implementación del contexto del sistemadonde se supone va a ejecutarse. La finalidad es evaluar el comportamiento de laarquitectura bajo diversas circunstancias. Una vez disponibles estasimplementaciones, pueden usarse los perfiles respectivos para evaluar losatributos de calidad. El proceso de evaluación basada en simulación sigue lospasos mostrados en la siguiente tabla:

Pasos DefiniciónDefinición e implementación delcontexto

Consiste en identificar las interfaces de la arquitecturade software con su contexto, y decidir cómo serásimulado el comportamiento del contexto en talesinterfaces.

Implementación de loscomponentes arquitectónicos

La descripción del diseño arquitectónico debe definir lasinterfaces y las conexiones de los componentes, por loque estas partes pueden ser tomadas directamente dela descripción de diseño.

Implementación de loscomponentes arquitectónicos

La descripción del diseño arquitectónico debe definir lasinterfaces y las conexiones de los componentes, por loque estas partes pueden ser tomadas directamente dela descripción de diseño.

Implementación del perfil Dependiendo del atributo de calidad que el arquitecto desoftware intenta evaluar usando simulación, el perfilasociado necesitará ser implementado en el sistema. Elarquitecto de software debe ser capaz de activarescenarios individuales, así como también ejecutar unperfil completo usando selección aleatoria, basado enlos pesos normalizados de los mismos.

Simulación del sistema e inicio delperfil

El arquitecto de software ejecutará la simulación yactivará escenarios de forma manual o automática, yobtendrá resultados de acuerdo al atributo de calidadque está siendo evaluado.


171

Predicción de atributos de calidad Dependiendo del tipo de simulación y del atributo decalidad evaluado, se puede disponer de cantidadesexcesivas de datos, que requieren ser condensados.Esto permite hacer conclusiones acerca delcomportamiento del sistema.

Tabla 45: Pasos para la Evaluación Basada en Simulación

En el ámbito de las simulaciones, se encuentra la técnica deimplementación de prototipos. Esta técnica implementa una parte de laarquitectura de software y la ejecuta en el contexto del sistema. Es utilizada paraevaluar requerimientos de calidad operacional, como desempeño y confiabilidad.

8.2.3 Evaluación basada en modelos matemáticos

La evaluación basada en modelos matemáticos se utiliza para evaluaratributos de calidad operacionales. Permite una evaluación estática de losmodelos de diseño arquitectónico, y se presentan como alternativa a la simulación,dado que evalúan el mismo tipo de atributos. Ambos enfoques pueden sercombinados, utilizando los resultados de uno como entrada para el otro. Elproceso de evaluación basada en modelos matemáticos sigue los pasosmostrados en la siguiente tabla:

Pasos DefiniciónSelección y adaptación del modelomatemático

Existen varios modelos matemáticos para medir susatributos de calidad, los cuales tienden a ser muyelaborados y detallados, así como también requieren decierto tipo de datos y análisis. Parte de estos datosrequeridos no están disponibles a nivel de arquitectura,y la técnica requiere mucho esfuerzo para la evaluaciónarquitectónica, por lo cual se debe adaptar el modelo.

Representación de la arquitecturaen términos del modelo

El modelo matemático seleccionado y adaptado noasume necesariamente que el sistema que intentamodelar consiste de componentes y conexiones. Por lotanto, la arquitectura necesita ser representada entérminos del modelo.

Estimación de los datos de entradarequeridos

El modelo matemático aún cuando ha sido adaptado,requiere datos de entrada que no están incluidos en ladefinición básica de la arquitectura. Es necesarioestimar y deducir estos datos de la especificación derequerimientos y de la arquitectura diseñada.

Predicción de atributos de calidad Una vez que la arquitectura es expresada en términosdel modelo y se encuentran disponibles todos los datosde entrada requeridos, el arquitecto está en capacidadde calcular la predicción resultante del atributo decalidad evaluado.

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


172

Entre los instrumentos que se cuentan para las técnicas de evaluación dearquitecturas de software basada en modelos matemáticos, se encuentran lasCadenas de Markov y los denominados “Reliability Block Diagrams”.

8.2.4 Evaluación basada en experiencia

En muchas ocasiones los arquitectos e ingenieros de software otorganvaliosas ideas que resultan de utilidad para evitar decisiones erradas de diseño.Aunque todas estas experiencias se basan en factores subjetivos como la intuicióny la experiencia. Sin embargo, la mayoría de ellas puede ser justificada por unalínea lógica de razonamiento, y pueden ser la base de otros enfoques deevaluación.

Existen dos tipos de evaluación basada en experiencia: la evaluacióninformal, que es realizada por los arquitectos de software durante el proceso dediseño, y la realizada por equipos externos de evaluación de arquitecturas. Lasiguiente tabla muestra los instrumentos utilizados por las diferentes técnicas deevaluación.

Técnica de Evaluación Instrumento de EvaluaciónBasada en Escenarios - Profiles

- Utility TreeBasada en Simulación - Lenguajes de Descripción

Arquitectónica (ADL)- Modelos de colas

Basada en ModelosMatemáticos

- Cadenas de Markov- Reliability Block Diagrams

Basada en Experiencia - Intuición y experiencia- Tradición- Proyectos similares

Tabla 47: Instrumentos asociados a las distintas técnicas de evaluación dearquitecturas de software

8.3 LECCIÓN 3: MÉTODOS DE EVALUACIÓN DE ARQUITECTURAS DESOFTWARE

Los métodos de análisis de arquitecturas de software hace que el procesosea repetible, y ayuda a garantizar que las respuestas correctas con relación a laarquitectura pueden hacerse durante las fases tempranas de diseño. Es en estepunto donde los problemas encontrados pueden ser solucionados de una formarelativamente poco costosa. Un método de evaluación sirve de guía a losinvolucrados en el desarrollo del sistema, en la búsqueda de conflictos que puedepresentar una arquitectura, y sus soluciones.


173

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

8.3.1 Software Architecture Analysis Method (SAAM)

El Método de Análisis de Arquitecturas de Software denominado SAAM, esel primero que fue ampliamente promulgado y documentado. El método fueoriginalmente creado para el análisis de la modificabilidad de una arquitectura,pero en la práctica ha demostrado ser muy útil para evaluar de forma rápidadistintos atributos de calidad, tales como modificabilidad, portabilidad,escalabilidad e integrabilidad.

El método de evaluación SAAM, se enfoca en la enumeración de unconjunto de escenarios que representan los cambios probables a los que estarásometido el sistema en el futuro. Como entrada principal, es necesaria algunaforma de descripción de la arquitectura a ser evaluada. Las salidas de laevaluación del método SAAM son las siguientes:

- Una proyección sobre la arquitectura de los escenarios que representan loscambios posibles ante los que puede estar expuesto el sistema

- Entendimiento de la funcionalidad del sistema, e incluso una comparación demúltiples arquitecturas con respecto al nivel de funcionalidad que cada unasoporta sin modificación

Si se evalúa una sola arquitectura se obtienen los lugares en los que lamisma puede fallar, en términos de los requerimientos de modificabilidad. Para elcaso en el que se cuenta con varias arquitecturas candidatas, el método produceuna escala relativa que permite observar qué opción satisface mejor losrequerimientos de calidad con la menor cantidad de modificaciones. Los pasosque contempla el método de evaluación SAAM se muestran en la siguiente tabla:

1. Desarrollo de escenarios Un escenario es una breve descripción de usos anticipadosodeseados del sistema. De igual forma, estos pueden incluircambios a los que puede estar expuesto el sistema en el futuro.

2. Descripción de laarquitectura

La arquitectura se descibe haciendo uso de alguna notaciónarquitectónica que sea común a todas las partes involucradas enel análisis. Deben incluirse los componentes de datos yconexiones relevantes, así como la descripción delcomportamiento general del sistema.

3. Clasificación y asignaciónde prioridad de losescenarios

La clasificación de los escenarios puede hacerse en dos clases:

Un escenario directo, que es el que puede satisfacerse sin lanecesidad de modificaciones en la arquitectura.

Un escenario indirecto, que es aquel que requiere modificaciones


174

en la arquitectura para poder satisfacerse.

Los escenarios indirectos son de especial interés para SAAM,pues son los que permiten medir el grado en el que unaarquitectura puede ajustarse a los cambios de evolución que sonimportantes para los involucrados en el desarrollo.

4. Evaluación individual delos escenarios indirectos

Para cada escenario indirecto, se listan los cambios necesariossobre la arquitectura, y se calcula su costo. Una modificaciónsobre la arquitectura significa que debe introducirse un nuevocomponente o conector, o que alguno de los existentes requierecambios en su especificación.

5. Evaluación de lainteracción entre escenarios

Cuando dos o más escenarios indirectos proponen cambios sobreun mismo componente, se dice que interactúan sobre esecomponente. Es necesario evaluar este hecho, puesto que lainteracción de componentes semánticamente no relacionadosrevela que los componentes de la arquitectura efectúan funcionessemánticamente distintas. De forma similar, puede verificarse si laarquitectura se encuentra documentada a un nivel correcto dedescomposición estructural.

6. Creación de la evaluaciónglobal

Debe asignársele un peso a cada escenario, en términos de suimportancia relativa al éxito del sistema. Esta asignación de pesosuele hacerse con base en las metas del negocio que cadaescenario soporta. En el caso de la evaluación de múltiplesarquitecturas, la asignación de pesos puede ser utilizada para ladeterminación de una escala general.

Tabla 48: Pasos contemplados por el método de evaluación SAAM

8.3.2 Architecture Trade-off Analysis Method (ATAM)

El Método de Análisis de Acuerdos de Arquitectura denominado ATAM, estáinspirado en tres áreas distintas: los estilos arquitectónicos, el análisis de atributosde calidad y el método de evaluación SAAM. El método ATAM revela la forma enque una arquitectura específica satisface ciertos atributos de calidad, y provee unavisión de cómo los atributos de calidad interactúan con otros; osea, los tipos deacuerdos que se establecen entre ellos.

El método se concentra en la identificación de los estilos arquitectónicos oenfoques arquitectónicos utilizados. Estos elementos representan los mediosempleados por la arquitectura para alcanzar los atributos de calidad, así comotambién permiten describir la forma en la que el sistema puede crecer, respondera cambios, e integrarse con otros sistemas. El método de evaluación ATAMcomprende nueve pasos, agrupados en cuatro fases. La siguiente tabla presentalas fases y sus pasos enumerados, junto con su descripción.

Fase 1: Presentación1. Presentación del ATAM El líder de evaluación describe el método a los participantes,

trata de establecer las expectativas y responde las preguntaspropuestas.

2. Presentación de las metasdel negocio

Se realiza la descripción de las metas del negocio quemotivan el esfuerzo, y aclara que se persiguen objetivos detipo arquitectónico.


175

3. Presentación de laarquitectura

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

Fase 2: Investigación y análisis4. Identificación de los enfoquesarquitectónicos

Estos elementos son detectados, pero no analizados.

5. Generación del Utility Tree Se elicitan los atributos de calidad que engloban la “utilidad”del sistema (desempeño, disponibilidad, seguridad,modificabilidad, usabilidad, etc.), especificados en forma deescenarios. Se anotan los estímulos y respuestas, así comose establece la prioridad entre ellos.

6. Análisis de los enfoquesarquitectónicos

Con base en los resultados del establecimiento de prioridadesdel paso anterior, se analizan los elementos del paso 4.

En este paso se identifican riesgos arquitectónicos, puntos desensibilidad y puntos de balance.

Fase 3: Pruebas7. Lluvia de ideas yestablecimiento de prioridad deescenarios.

Con la colaboración de todos los involucrados, secomplementa el conjunto de escenarios.

8. Análisis de los enfoquesarquitectónicos

Este paso repite las actividades del paso 6, haciendo uso delos resultados del paso 7. Los escenarios son consideradoscomo casos de prueba para confirmar el análisis realizadohasta el momento.

Fase 4: Reporte9. Presentación de losresultados

Basado en la información recolectada a lo largo de laevaluación del ATAM, se presentan los hallazgos a losparticipantes.

Tabla 49: Pasos del método de evaluación ATAM

8.3.3 Active Reviews for Intermediate Designs (ARID)

El método ARID es conveniente para realizar la evaluación de diseñosparciales en las etapas tempranas del desarrollo. En ocasiones, es necesariosaber si un diseño propuesto es conveniente, desde el punto de vista de otraspartes de la arquitectura. ARID es un híbrido entre Active Design Review (ADR) yArchitecture Trade-Off Method (ATAM). ADR es utilizado para la evaluación dediseños detallados de unidades del software como los componentes o módulos.Las preguntas giran en torno a la calidad y completitud de la documentación y lasuficiencia, el ajuste y la conveniencia de los servicios que provee el diseñopropuesto.

Tanto ADR como ATAM proveen características útiles para el problema dela evaluación de diseños preliminares. En el caso de ADR, los involucradosreciben documentación detallada y completan cuestionarios, cada uno porseparado. En el caso de ATAM, está orientado a la evaluación de toda unaarquitectura.

Ante la necesidad de evaluación en las fases tempranas del diseño, sepropone la utilización de las características que proveen tanto ADR como ATAM


176

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

Fase 1: Actividades Previas1. Identificación de losencargados dela revisión

Los encargados de la revisión son los ingenieros de softwareque se espera que usen el diseño, y todos los involucrados enel diseño. En este punto, converge el concepto de encargadode revisión de ADR e involucrado del ATAM.

2. Preparar el informe deDiseño

El diseñador prepara un informe que explica el diseño. Seincluyen ejemplos del uso del mismo para la resolución deproblemas reales. Esto permite al facilitador anticipar el tipo depreguntas posibles, así como identificar áreas en las que lapresentación puede ser mejorada.

3. Preparar los escenariosbase

El diseñador y el facilitador preparan un conjunto deescenarios base. De forma similar a los escenarios del ATAMy el SAAM, se diseñan para ilustrar el concepto de escenario,que pueden o no ser utilizados para efectos de la evaluación.

4. Preparar los materiales Se reproducen los materiales preparados para serpresentados en la segunda fase. Se establece la reunión, y losinvolucrados son invitados.

Fase 2: Revisión5. Presentación del ARID Se explica los pasos del ARID a los participantes.6. Presentación del diseño El líder del equipo de diseño realiza una presentación, con

ejemplos incluidos. Se propone evitar preguntas queconciernen a la implementación o argumentación, así comoalternativas de diseño. El objetivo es verificar que el diseño esconveniente.

7. Lluvia de ideas yestablecimiento deprioridad de escenarios

Se establece una sesión para la lluvia de ideas sobre losescenarios y el establecimiento de prioridad de escenarios.Los involucrados proponen escenarios a ser usados en eldiseño para resolver problemas que esperan encontrar.Luego, los escenarios son sometidos a votación, y se utilizanlos que resultan ganadores para hacer pruebas sobre eldiseño.

8. Aplicación de losescenarios

Comenzando con el escenario que contó con más votos, elfacilitador solicita pseudo-código que utiliza el diseño paraproveer el servicio, y el diseñador no debe ayudar en estatarea. Este paso continúa hasta que ocurra alguno de lossiguientes eventos:

- Se agota el tiempo destinado a la revisión- Se han estudiado los escenarios de más alta prioridad- El grupo se siente satisfecho con la conclusión alcanzada.

Puede suceder que el diseño presentado sea conveniente,con la exitosa aplicación de los escenarios, o por el contrario,no conveniente, cuando el grupo encuentra problemas odeficiencias.

9. Resumen Al final, el facilitador recuenta la lista de puntos tratados, pideopiniones de los participantes sobre la eficiencia del ejercicio


177

de revisión, y agradece por su participación.

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

8.3.4 Modelo de Negociación WinWin

El modelo WinWin provee un marco de referencia general para identificar yresolver conflictos de requerimientos. El modelo utiliza la teoría “W”, que pretendeque todo involucrado salga ganador. De esta forma, asiste a los involucrados en eldesarrollo a identificar y negociar distintos aspectos, reconciliando conflictos entrelas opciones de ganancias para todos.

Aunque el modelo propone la resolución de posibles conflictos, no siemprees posible llegar a un acuerdo. En este sentido, el método CBAM provee mediospara establecer los balances necesarios, y un marco de referencia para ladiscusión que puede llevar a una posible solución del problema.

8.3.5 Cost-Benefit Analysis Method (CBAM)

El método de análisis de costos y beneficios denominado (CBAM), es unmarco de referencia que no toma decisiones por los involucrados en el desarrollodel sistema. Uno de los elementos que introduce el método son las llamadasestrategias arquitectónicas, que consisten en posibles opciones para la resoluciónde conflictos entre atributos de calidad presentes en una arquitectura.

El método CBAM abarca los siguientes aspectos: Selección de escenarios,Evaluación de los beneficios de los atributos de calidad, Cuantificación de losbeneficios de las estrategias arquitectónicas, Cuantificación de los costos de lasestrategias arquitectónicas y las implicaciones de calendario, Cálculo del nivel dedeseabilidad y la Toma de decisiones. La siguiente tabla muestra los pasospertenecientes al marco de referencia para evaluación de arquitecturas desoftware para este método:

1. Selección de escenarios Cada involucrado en el desarrollo identifica sus condicionesde ganancia. Este paso provee las bases para la identificaciónde las características ideales del sistema esperadas por losinvolucrados.

2. Identificación de losconflictos entre atributos decalidad

La lista de condiciones de ganancia es revisada con laintención de identificar conflictos entre atributos de calidad.Los conflictos son categorizados en directos o potenciales.

3. Exploración de las opcionesen busca de la resolución deconflictos

Con base en los conflictos detectados en el paso anterior, losinvolucrados pueden generar opciones de resolución deconflictos, o estrategias arquitectónicas.

4. Medición de los beneficiosde los atributos de calidad

Para ayudar en el proceso de toma de decisiones, losinvolucrados en el desarrollo deben calcular tanto los costoscomo los beneficios de las estrategias arquitectónicaselaboradas en el paso


178

anterior. Para esto, se calcula una escala de atributos decalidad, donde se asigna un puntaje a cada atributo.

5. Cuantificación de losbeneficios

Las escalas establecidas son utilizadas para la evaluación delas estrategias arquitectónicas planteadas en el paso 3. Elresultado de la evaluación permite observar el beneficio decada uno de los cambios arquitectónicos propuestos.

6. Cuantificación de costos eimplicaciones de calendario

En este paso se calculan los costos e implicaciones decalendario que aplican para cada una de las estrategiasarquitectónicas propuestas en el paso 3. No se propone unmodelo específico para la realización de la estimación decostos y tiempo.

7. Cálculo del nivel deDeseabilidad

Este paso contempla una métrica especial, que se reflejacomo el cociente entre los beneficios y los costos obtenidos.Las estrategias arquitectónicas que resulten con valoresmayores se proponen como las más recomendables.

8. Alcanzar un acuerdo La recomendación general es la documentación del proceso.La acumulación de evidencia permite el establecimiento de unposible consenso, a la hora de la toma de decisiones sobre laarquitectura de un sistema de software.

Tabla 51: Pasos del método de evaluación CBAM

8.3.6 Método Diseño y Uso de Arquitecturas de Software propuesto porBosch

Bosch plantea, en su método de diseño de arquitecturas de software, que elproceso de evaluación debe ser visto como una actividad iterativa, que forma partedel proceso de diseño, también iterativo. Una vez que la arquitectura es evaluada,pasa a una fase de transformación, asumiendo que no satisface todos losrequerimientos. Luego, la arquitectura transformada es evaluada de nuevo. Elproceso de evaluación propuesto por Bosch se divide en dos etapas, que sonpresentadas en la siguiente tabla:

Etapa I1. Selección de atributos decalidad

Deben seleccionarse aquellos atributos que se considerancruciales para el éxito del sistema, y cuya satisfacciónresulte poco clara a nivel de arquitectura. Resulta necesarioporque es poco factible y poco útil evaluar todos losatributos de calidad, dado que requiere una gran cantidadde tiempo.

2. Definición de los perfiles Para cada atributo de calidad seleccionado, se definen losperfiles respectivos para efectos de la evaluación.

3. Selección de una técnica deevaluación

Para la evaluación de los atributos de calidad dependientesdel diseño de la arquitectura se recomienda utilizar laevaluación basada en escenarios, así como también losmodelos basados en métricas o modelos matemáticos.Los atributos de calidad operacionales (observables víaejecución) pueden evaluarse con técnicas de simulación omodelos matemáticos. La selección de la técnica, y laimplementación concreta de ésta depende del objetivo yexactitud de la evaluación.

Etapa II4. Ejecución de la evaluación Para cada atributo de calidad, las técnicas arrojan valores


179

cuantitativos.5. Obtención de resultados Los resultados se resumen en una tabla que contiene el

nivel requerido, el nivel predicho, y un indicador, que puedetener diversos significados: si el atributo se satisface o no, sinecesita ser negociado con el cliente, o existencia de algunarelación negativa con otro atributo de calidad. El arquitectopuede decidir acerca de la realización de transformacionessobre la arquitectura actual, y efectuar una nuevaevaluación. Una vez que concluye el proceso de evaluación,con los resultados obtenidos es posible decidir entre lacontinuación, renegociación o cancelación del proyecto.

Tabla 52: Etapas contempladas por el método de evaluación de arquitecturaspropuesto por Bosch

8.3.7 Método de Comparación de Arquitecturas Basada en el ModeloISO/IEC 9126 Adaptado para Arquitecturas de Software

Losavio proponen un método para evaluar y comparar arquitecturas desoftware candidatas, que hace uso del modelo de especificación de atributos ecalidad adaptado del modelo ISO/IEC 9126. Para la evaluación se plantea laespecificación de los atributos de calidad haciendo uso de un modelo basado enestándares internacionales ISO/IEC 9126 que ofrecen una vista amplia y global delos atributos de calidad, tanto a usuarios como arquitectos del sistema, paraefectos de la evaluación. El método contempla siete actividades que sonmostradas y descritas en la siguiente tabla:

Actividades

1. Analizar los requerimientos funcionales y no funcionales principales del sistema, paraestablecer las metas de calidad

2. Utilizar el modelo de calidad ISO/IEC 9126 adaptado para arquitecturas de software. Algunasmétricas pueden definirse con mayor nivel de detalle

3. Presentar las arquitecturas candidatas iniciales

4. Construir la tabla comparativa para las arquitecturas candidatas

5. Establecer prioridades para las subcaracterísticas de calidad tomando en cuenta losrequerimientos de calidad del sistema

6. Analizar los resultados obtenidos y resumidos en la tabla, de acuerdo con las prioridadesestablecidas

Tabla 53: Actividades del Método de Comparación de Arquitecturas Basado en elModelo ISO/IEC 9126 Adaptado para Arquitecturas de Software de Losavio

8.4 LECCIÓN 4: MÉTODOS DE EVALUACIÓN DE ARQUITECTURA DE UNATRIBUTO ESPECÍFICO


180

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

8.4.1 Architecture Level Modifiability Analysis ALMA

Este método es el resultado de los trabajo de investigación de Brengtsson yLassing, el atributo de calidad que analiza este método es la facilidad demodificación, este atributo se refiere a la capacidad de un sistema para serajustado debido a cambios en los requerimientos, o en el entorno, así como laadición de nuevas funcionalidades.

ALMA es un método de evaluación orientado a metas, que se apoya en eluso de escenarios de cambio, los cuales escriben los eventos posibles queprovocarían cambios al sistema, y como se llevarían a cabo estos. El mismoconsta de cinco pasos como se muestran en la siguiente figura:

Figura 33: Método de evaluación de arquitecturas ALMA

8.4.2 Performance Assessment of Software Architecture PASA

PASA es el resultado del trabajo de Williams y Smith, el mismo utilizadiversas técnicas de evaluación, tales como la aplicación de estilos


181

arquitectónicos, anti-patrones, guías de diseño y modelos. El atributo de calidadque analiza este método es el desempeño, se interesa en saber qué tanto tiempole toma al sistema software responder cuando una o varios eventos ocurren, asícomo determinar el número de eventos procesados en un intervalo de tiempodado.

Este método también se basa en escenarios y puede aplicarse de formatemprana o tardía. Los escenarios generados en este método sirven como puntode partida para la construcción de modelos de desempeño. Uno de los requisitos oprecondiciones es que la arquitectura debe estar previamente documentada y encaso de que no esté completa se debe extraer el resto de la información a losmiembros del equipo.

Figura 34: Método de evaluación de arquitecturas PASA

8.4.3 Scenario based Architecture Level Usability Analysis SALUTA

Es el primer método desarrollado para evaluar arquitecturas desde laperspectiva de la facilidad del uso del sistema, siendo el resultado de los estudiosde Folmer y Gurp. Este método hace uso de marcos de referencia que expresanlas relaciones que existen entre facilidad de uso y Arquitectura de Software.Dichos marcos de referencias incluyen un conjunto integrado de soluciones dediseño como patrones de diseños u propiedades que tienen un efecto positivosobre la facilidad de uso en un sistema software.

SALUTA analiza cuatro atributos que están directamente relacionados conla facilidad de uso de un sistema de software: Facilidad de aprendizaje, Eficiencia


182

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

Figura 35: Método de evaluación de arquitecturas SALUTA

8.4.4 Survivable Network Analysis SNA

Es un método desarrollado por el CERT (Computer Emergency ResponseTeam) que forma parte del SEI (Software Engineering Institute). Este métodoayuda a identificar la capacidad de supervivencia en un sistema, analizando suarquitectura. La supervivencia es la capacidad que tiene un sistema paracompletar su misión a tiempo, ante la presencia de ataques, fallas o accidentes.Para evaluar esta supervivencia SNA utiliza tres propiedades claves: Resistencia,Reconocimiento y Recuperación.

Este procedimiento puede ser realizado después de la especificación de laarquitectura, durante la implementación de esta, o posteriormente. SNA se basaen la técnica de escenarios de uso, e identifica dos tipos de escenarios:Escenarios normales, que se componen de una serie de pasos donde los usuariosinvocan servicios y obtienen acceso a activos, tales como bases de datos,Escenarios de intrusión, en los que se representan diferentes tipos de ataques alsistema. En la siguiente tabla se muestra cada uno de los pasos del método:


183

Figura 36: Método de evaluación de arquitecturas SNA

La siguiente tabla muestra una tabla comparativa de cada uno de los métodos deevaluación de arquitectura mencionados anteriormente:

ALMA PASA SALUTA SNAMeta Predecir el costo

de mantenimiento,evaluar riesgos,comparación entrearquitecturas

Analizar laarquitectura conrespecto a losobjetivos dedesempeño de unsistema

Predecir lafacilidad de usode un sistemaanalizando laarquitectura

Identificar lacapacidad desupervivencia deun sistema antepresencia deataques, fallas oaccidentes

Atributo decalidad

Facilidad demodificación

desempeño Facilidad de uso supervivencia

Técnica deevaluación

Escenarios decambio

escenarios Escenarios deuso

Escenarios deuso normales yescenarios deintrusión

entradas Especificación dela arquitectura,requerimientos nofuncionales

Especificación dela arquitectura

Especificación dela arquitectura,requerimientosno funcionalesrelacionados conla facilidad deuso

Especificación dela arquitectura


184

salidas Dependiendo de lameta deevaluación segeneran losresultados

Hallazgosencontrados, pasosespecíficos aseguir yrecomendaciones

Grado defacilidad de usoque soporta laarquitecturaevaluada

Modificacionesrecomendadasde la arquitecturay mapa desupervivencia

Personasinvolucradas

Arquitecto yequipo dedesarrollo

Arquitecto, equipode desarrollo yadministradores delproyecto

Arquitecto,ingenieros derequerimientos oingenierosresponsables porla facilidad deuso

Arquitecto,diseñadorprincipal,propietarios delsistema, usuarios

Duración No especificado 7 días No especificado No especificadoValidacióndel método

Sistemas decontrol embebido,sistemas médicos,telecomunicaciones, sistemasadministrativos

Sistemas basadosen la web,aplicacionesfinancieras, ysistemas en tiemporeal

Algunos casos deestudio queincluyenprincipalmentesistemas web

Sistemascomerciales y degobierno

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

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

MECABIT es uno de los métodos para evaluar Arquitecturas de SoftwareBasadas en Componentes con el objetivo de que sea aplicado en ArquitecturasOrientadas a Servicios. Este análisis se realiza desde el punto de vista, que bajociertas y determinadas situaciones o condiciones, se puede ver un servicio comoun componente.

El MECABIC está inspirado en ATAM, al método se le incluyeron enalgunos de sus pasos un enfoque de integración de elementos de diseño,inspirado en la construcción de partes arquitectónicas adoptado por el ArchitectureBased Design (ABD). Además se propone un árbol de utilidad inicial basado en elmodelo de calidad ISO/IEC 9126 instanciado para Arquitectura de Softwarepropuesto por Losavio. La adopción de este modelo por parte del MECABICpermite concentrarse en características que dependen exclusivamente de laarquitectura, y al ser un estándar facilita la correspondencia con características decalidad consideradas por los métodos estudiados. Los escenarios incluidos eneste árbol son específicos para aplicaciones basadas en componentes.

En el método MECABIC participan tres grupos de trabajo: Los arquitectos,el evaluador y los relacionados. Para la especificación de la calidad se hace usode un árbol de utilidad, el cual tiene como nodo raíz la “bondad” o “utilidad” delsistema. En el segundo nivel del árbol se encuentran los atributos de calidad. Lashojas del árbol de utilidad son escenarios, los cuales representan mecanismosmediante los cuales extensas declaraciones de cualidades son hechas específicasy posibles de evaluar. La generación del árbol de calidad incluye un paso quepermite establecer prioridades. Para el análisis de la arquitectura se utiliza la


185

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

Equipo Definición Fases en lasque participan

Arquitectos Responsables de generar y documentar una Arquitecturade Software para el sistema estudiado.

Todas

Evaluador Integrado por personas expertas en asuntos de calidadquienes guiarán el proceso de evaluación de laarquitectura

Todas

Relacionados Son las personas involucradas de alguna manera con elsistema: programadores, usuarios, gerentes, entre otros.

Fases 1, 3 y4.

Tabla 55: Grupos de Trabajo en el Método MECABIT.

8.5.1 Fases del Método

El método consta de cuatro fases, la de presentación, la de investigación yanálisis, la de prueba y la presentación de resultados. A continuación se describecada una de las fases:

8.5.1.1 Fase1 – Presentación: En esta fase se da a conocer el método entretodos los grupos, el sistema y su organización, y finalmente se presenta cuál es laarquitectura que debe ser evaluada. En esta fase se realiza una presentación delmétodo MECABIC para que los participantes comprendan en qué punto de laaplicación del método se encuentran en cada momento.También se da a conocerla arquitectura inicial a evaluar y qué características de calidad se esperan lograr.

8.5.1.2 Fase2 – Investigación y Análisis: En esta fase se determina de quémanera se va estudiar la arquitectura, se pide a las personas que estánrelacionadas con el sistema, ya sea un desarrollador, usuario o gerente, queexpresen de una manera precisa que escenarios de calidad se desean y seanaliza si la arquitectura es apropiada o se requieren modificaciones para que losea. En esta fase sólo participan el grupo evaluador y grupo de arquitectos. Enesta fase se identifican elementos de diseño que ayuden a analizar la arquitectura,se especifican los requerimientos planteados durante el paso 2 y se analiza cómoresponden los elementos de diseño considerados a los requerimientos.

8.1.1.3 Fase3 - Prueba: Consiste en la revisión de la segunda fase y en ellaparticipan todos los grupos.

8.1.1.4 Fase4 – Presentación de Resultados: En la última fase se lleva a cabo apresentación de los resultados. En esta fase participan todos los grupos. Fase deGeneración de la arquitectura final y reporte. En este momento se cuenta ya conun análisis de todas las decisiones que se han producido hasta el momento. Si no


186

hay conflictos y se puede concluir que existe una arquitectura adecuada para losrequerimientos de calidad de las personas involucradas en la evaluación, entoncesse puede pasar al paso 10 directamente. Si por el contrario en algún elemento dediseño existen decisiones en las que resulte favorecido algún requerimiento,entonces los usuarios y desarrolladores son los que tienen que determinar oacordar cuáles requerimientos favorecer.

En la siguiente tabla se muestra el método MECABIT, con cada una de las fases yel detalle de los pasos que se deben dar para la aplicación del método:

Fase 1: Fase de presentación1. Presentación del método. En el primer paso el director de evaluación presenta el método

ante los participantes con el proyecto. Se explica el proceso quedebe cumplir cada participante del proyecto, se respondenpreguntas y se establecen las expectativas y el contexto sobrelas actividades o tareas restantes. La finalidad es que todas laspersonas involucradas en el sistema comprendan la secuenciade los pasos a seguir, los instrumentos utilizados en cada pasoy las salidas del método. Se pide a las personas que comentensus expectativas o que hagan preguntas particulares acerca delo que esperan de la aplicación del método.

2. Presentación de lasdirectrices del negocio.

Cada persona que posee una responsabilidad sobre laevaluación, necesitan comprender el contexto del sistema y losaspectos primarios del contexto del negocio que motivan sudesarrollo. Se explica a las personas el contexto del sistema ylos requerimientos del negocio dentro del cual va a funcionar elsistema. Algunos tópicos que debería contener estapresentación son: las funcionalidades más importantes delsistema, los objetivos del negocio y el contexto relacionado conel proyecto, el grupo dirigente de los desarrolladores y usuarios,las directrices arquitectónicas, restricciones técnicas,gerenciales, económicas y políticas y obertura de la evaluacióny límites del sistema.

3. Presentación de laarquitectura.

El arquitecto o grupo de representantes explican a las personascomo desarrollador, usuario o gerente, cuál es la arquitecturaevaluada. Debe contener una clara diferenciación estructural, lacual deberá mostrar claramente las relaciones entrecomponentes de la arquitectura y las diferentes granularidadesinvolucradas. El arquitecto cubre restricciones técnicas y losalcances arquitectónicos usados para alcanzar losrequerimientos. El arquitecto debe transmitir lo esencial y deesta manera abreviada la información de la arquitectura querequiere el equipo.

Fase2: Investigación y Análisis4. Identificación deelementos de diseño.

Contemplan alternativas de diseño de la arquitectura, queposteriormente serán analizadas para ver cómo responden a losrequerimientos de calidad. La arquitectura debe ser evaluadacompletamente desde el sistema con sus componentes demayor granularidad, hasta el mínimo nivel de granularidad quecorresponde a los componentes. Se propone identificarelementos de diseño dentro de una arquitectura basada encomponentes, como un componente, y el conjunto decomponentes con los cuales interactúa, un conjunto deasociaciones que sea de interés sobre alguna característica de


187

calidad particular o conjunto de decisiones que tenga influenciaconsiderable sobre otros elementos de diseño. Para identificarun elemento de diseño se considera los servicios ofrecidos porlos componentes disponibles y las diferentes opciones paradefinir los servicios de los componentes desarrollados para elsistema. La manera de documentar los elementos de diseñodepende de la importancia que pueda tener dentro de laevaluación, del conjunto de decisiones o adaptaciones arealizar, y del conocimiento de las personas que estánrelacionadas con el sistema y estén en la evaluación.

5. Generación del árbol deutilidad.

El árbol de utilidad inicial especifico a partir del cual seleccionanun conjunto de escenarios de interés, está basado en el modelode calidad ISO/IEC 9126-1 para arquitecturas de software. Seasume que al aplicar el método, las funcionalidades presentesen el sistema son las que necesitan los usuarios, y no se incluyeescenarios de aptitud (subcaracterística de funcionalidad).Posteriormente, se consideran escenarios no contemplados enel árbol inicial de utilidad. En este paso el grupo evaluadorpresenta los diferentes escenarios a considerar al resto de losparticipantes y se decide cuáles son los que serán incluidos enel árbol de utilidad. Este paso brinda la posibilidad de verificar sies necesario incluir en el árbol de utilidad algún otro escenario.La selección del resto de los escenarios puede realizarse porvotación como propone originalmente el ATAM. Luego seorganizan los escenarios de calidad introducidos nocontemplados en la tabla de generación del árbol de utilidadinicial por características de calidad. Posteriormente, se procedea priorizarlos, es decir, ordenar los escenarios ya que de estamanera se puede tener una orientación para tomar decisionesarquitectónicas, y personas pueden determinar de lo queesperan del sistema, y obtener una idea sobre en qué medidava a ser satisfecho.

Posteriormente se procede a asignar un orden a los escenariosde calidad de un sistema utilizando dos criterios: Evaluar elriesgo de no considerar el escenario donde se responde laspreguntas: ¿qué pasa si este escenario no se cumple?,¿cuántas personas se ven afectadas?, ¿es posible compensarel no responder a este escenario?), Evaluar el esfuerzonecesario para lograr cumplir con el escenario (se determinaque cambios o integraciones de nuevos componentes se debenrealizar para satisfacer el escenario).

Finalmente, se construye el árbol de utilidad con las salidas delpaso anterior. La prioridad del escenario define en este métodocomo un par (X, Y) en el cual X define el esfuerzo de satisfacerel escenario, y la Y indica los riesgos que se corren al excluirlosdel árbol de utilidad. Los posibles valores para X e Y son A(Alto), B (Bajo) y M (Medio).

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

Se analizan los elementos de diseño identificados en el paso 4 ode nuevos elementos de diseño que puedan ser identificados,para determinar cómo influyen sobre la realización de losescenarios de calidad presentes en el árbol de utilidad generadoen el paso 5.


188

Los componentes proveen un conjunto de puertos que se debenir extendiendo para proporcionar nuevos servicios, los cuales asu vez pueden ser ofrecidos para que otros componentes losextiendan. Se debe evaluar un conjunto de opciones queindiquen una manera de definir una relación entre puertos, deacuerdo a algún criterio de calidad. Los escenarios de calidaddeben ser aplicados a la arquitectura que ha sido generada. Elequipo de evaluación se orienta con las preguntas de análisispropuestas por el método para determinar decisiones sobre laarquitectura. Se debe preguntar si las decisiones tomadaspermiten alcanzar los escenarios de calidad planteados. Si larespuesta es negativa se deben reconsiderar cualquiera de lasdecisiones que han sido hechas. Las decisiones identificadasanteriormente, pueden relacionarse con determinadoselementos de diseño. Se deben estudiar los riesgos queintroduce la decisión en particular, o si ésta contribuye a algúnriesgo ya determinado. También se pueden documentardecisiones que no han sido tomadas o asuntos no resueltos quea juicio del equipo de evaluación pueden ser resueltos en unfuturo estudiando con más detalle el elemento de diseñoconsiderado.

Fase3: prueba7. Revisión del árbol deutilidad.

Se propone utilizar escenarios de calidad para representar losintereses de todos los grupos de la evaluación y confirmar quese han evaluado los requerimientos deseados de calidad. Elequipo de evaluación puede facilitar la elaboración deescenarios haciendo uso del conjunto de pasos propuestos en elpaso 6. Los escenarios del árbol de utilidad que no hayan sidoconsiderados, son colocados por las personas comodesarrolladores y usuarios en el paquete de tormenta de ideas,lo que les da la oportunidad de revisar escenarios pocoatendidos. Los escenarios generados se comparan con la listainicialmente considerada en el árbol de utilidad. En caso de quela consideración y priorización coincida, entonces se puededecir los escenarios evaluados son adecuados para el grupo deinteresados en el sistema. Cuando no se logra un acuerdo entrelos dos grupos de desarrolladores y usuarios posiblemente nose representaron adecuadamente los intereses de losinvolucrados. Los desarrolladores deben analizar también losescenarios que ya han sido evaluados, para verificar que hayanrecibido la importancia adecuada.

Una vez que el nuevo escenario ha sido considerado se puedenpresentar tres casos: El escenario duplica un escenario yaconsiderado en el árbol de utilidad, El escenario pasa a ser unahoja de una rama ya existente, No existe rama para el escenariodebido a que no había sido considerado previamente. Losprimeros dos casos sugieren que la arquitectura de software hasido creada de acuerdo con las expectativas de los usuarios,mientras que en el tercer caso, se ha fallado al considerar algúnaspecto de calidad importante y puede existir un riesgo adocumentar.

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

El equipo evaluador debe estudiar de qué manera los elementosde diseño analizados en el paso 6, promueven los escenariospropuestos por el nuevo grupo de usuarios y desarrolladores. En


189

caso que no promuevan las características de calidad deseadas,deben ser reconsiderados.

Fase4: Presentación de los resultados9. Generación de losacuerdos.

Se decide cuál será la arquitectura adoptada por el sistema.Para ello se debe buscar un consenso en cuanto a las opcionesque existan, en caso de que no se haya identificado algunanotablemente mejor. Si existen requerimientos de calidad queno han sido logrados se debe brindar la posibilidad de replantearlos requerimientos de calidad que no hayan podido seralcanzados, para aprovechar posibles ventajas de laarquitectura. Esta es una negociación crítica, ya que de fallar,implicaría la necesidad de replantear la arquitectura, y de teneréxito hay que cuidar que los requerimientos de calidad noresueltos sean equivalentes, para que los usuarios ydesarrolladores estén contentos con el sistema. Finalmente, sedocumentan todos aquellos requerimientos de calidad para loscuales no es posible encontrar una solución, justificando lasrazones.

10. Presentación de losresultados.

Se presenta un resumen de la aplicación del método, de formaoral y/o escrita. Se deben incluir entonces, los siguientesdocumentos a partir de los cuales se inició la evaluación:

a) Contexto del negocio.b) Requerimientos de Calidad.c) Restricciones.d) Arquitectura producida.e) Análisis de elementos de diseño identificados.f) Conjunto de escenarios negociados.g) Conjunto de preguntas para evaluación de atributos.h) Árbol de Utilidad.i) No-riesgos documentado.j) Puntos sensibles y de negociación.

Tabla 56: Fases Contempladas en el Método de evaluación de ArquitecturasMECABIT.

La generación del árbol de utilidades, descrito en el punto 5 de la fase 2,acerca de la Investigación y Análisis, del método es tomada de acuerdo a la normaISO/IEC 9126 y adaptada para la evaluación de la arquitectura de software. Acontinuación se muestra el árbol de utilidad aplicado para el método MECABIT.

Característica Sub-característica EscenarioEl sistema posee componentes capaces de leerdatos provenientes de otros sistemas.

Interoperabilidad

El sistema posee componentes capaces de producirdatos para otro sistema.Los resultados ofrecidos por los componentessistema son exactos.

Precisión

La comunicación entre los componentes no altera laexactitud de los datos

Funcionalidad

Seguridad El sistema detecta la actuación de un intruso e


190

impide acceso a los componentes que manejeninformación sensibleEl sistema asegura que los componentes no pierdandatos ante un ataque (interno o externo).Los componentes respetan un estándar defiabilidad.

Obediencia(Compliance)

La comunicación entre los componentes no viola losestándares de fiabilidad.

Madurez Los componentes del sistema manejan entradas dedatos de datos incorrectas.

Tolerancia a fallas Todas las operaciones ejecutadas por loscomponentes se realizan correctamente bajocondiciones adversas.Los componentes del sistema no fallan bajo ciertascondiciones especificadas.

Fiabilidad

Capacidad derestablecimiento orecuperación Ante problemas con el ambiente un subconjunto

determinado de los componentes puede continuarprestando sus servicios.

Tiempo decomportamiento

El sistema debe recibir los servicios de suscomponentes en el transcurso de un tiempoindicado.Los componentes pueden compartir recursosadecuadamente.

Eficiencia

Recursos utilizados

El sistema controla que ningún componente sequede sin recursos cuando los necesita.Es posible verificar el estado de los componentesdel sistema.El sistema brinda facilidad para adaptar uncomponente.

Mantenibilidad Habilidad de cambio,estabilidad, prueba

El sistema debe facilitar la sustitución/adaptación deun componente.

Adaptabilidad El sistema debe continuar funcionandocorrectamente aun cuando los servicios de loscomponentes provistos por el ambiente varíen.

Capacidad deInstalación

Los componentes pueden instalarse fácilmente entodos los ambientes donde debe funcionar.

Portabilidad

Co-existencia Los componentes manejan adecuadamenterecursos compartidos del sistema.

Tabla 57: Subconjunto del Árbol de Utilidad Iinicial Propuesto por el MétodoMECABIT

A continuación también se presenta una tabla de preguntas sobre loselementos de revisión del diseño identificados en el punto 8 de la fase 3, delmétodo MECABIT.

Característica Sub-característica Preguntas de análisisPrecisión ¿Puede la comunicación entre los

componentes introducir imprecisiones en losservicios ofrecidos por los componentes?

Funcionalidad

Interoperabilidad ¿Dónde se encuentran los componentes quepermiten al sistema interactuar con otrossistemas?


191

Madurez ¿Existen decisiones para minimizar el manejoincorrecto de datos en la comunicación entrecomponentes?

Fiabilidad

Tolerancia a fallas ¿Cómo se detecta el funcionamientoincorrecto de un componente?

Eficiencia Tiempo decomportamiento

¿Cómo es la relación entre el número decomponentes de las diferentes partes de laarquitectura?¿Cómo se verifica el funcionamiento correctode un componente?¿Cómo se verifica el estado de unacomunicación entre componentes?

Mantenibilidad Habilidad de cambio,estabilidad, prueba

¿Cómo se facilita el reemplazo de uncomponente?

Capacidad deInstalación

¿Existe un mecanismo para determinar sitodos los componentes del sistema seencuentran correctamente instalados?

Portabilidad

Co-existencia ¿Existe alguna manera de identificar lasreglas para interactuar con componentes desistemas externos a la arquitectura?

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


192

CAPITULO 3

APLICACIONES DE EVALUACIÓNDEL SOFTWARE


193

INTRODUCCIÓN

La industria de software cada vez esta más consolidada y ofrece unsinnúmero de productos que pretenden satisfacer las necesidades endiversos campos, y por eso es necesario que se tome en consideración lasdiversas metodologías de evaluación que están surgiendo, ya que cada unade ella pretende evaluar productos software específicos.

Actualmente el campo de la evaluación de software ha adquirido mayormadurez y debe responder a la medición de calidad de cada uno de losproductos y del proceso de construcción, es por eso que en este capítulo setratan dos aplicaciones la primera esta relacionada conla evaluación delproceso y es la aplicación de la evaluación a los diseños UML y la segundaaplicada a uno de los productos que adquiere una importacia significativaaplicada al campo educativo, son los productos software que de algunamanera complementan o suplen la educación presencial.

A continuación se describirá algunos de los metodos para realizar laevaluación UML y los modelos más reconocidos para la evaluación de losproductos software educativos multimedia.


194

9.1 LECCIÓN 1: METODOLOGÍA PARA LA EVALUACIÓN DE LACALIDAD EN LOS MODELOS UML

El campo de la calidad de las especificaciones y más concretamente,en la calidad de los modelos UML, es relativamente nuevo y solo desde 1998 secontemplan propuestas sobre la calidad en el modelado con UML, este tema esde suma actualidad y relevancia, pero carece todavía de suficiente madurez. Poreso, se ha elaborado en esta lección un seguimiento a una de las metodologías deevaluación de la calidad en los modelos UML, enmarcada dentro del proyectodenominado EVVE “Entorno para la Verificación y Validación deEspecificaciones software”.

A partir de los principales estándares, normas y metodologías existentesen la actualidad relacionados con la evaluación del software, se ha elaborado l am e t o d o l o g í a E V V E , analizando las características clave de cada uno deellos y seleccionando, adaptando e integrando los aspectos más relevantes.

Las principales características de la metodologIa EVVE, se puedenresumir en los siguientes principios básicos: Está formada por un conjuntoestructurado de procesos, Está orientada a la relación con el cliente y a laexternalización de la evaluación de calidad, Está pensada para ser unametodologIa fácilmente adaptable, y Está soportada por un conjunto de técnicas yherramientas.

La metodología EVVE proporciona un marco de trabajo donde seidentifica claramente el qué, cuándo, y el quién, de cada una de las fases yactividades de los procesos, así como la secuencia de pasos que se debeseguir a la hora de llevar a cabo la evaluación. Además, está orientada a larelación con el cliente de manera que el cliente se encuentra involucrado en latoma de decisiones. La metodología contempla el modo de trabajoexternalizado, de manera que para realizar la evaluación no sea necesarioencontrarse en las instalaciones del cliente, sino que se pueda planificar,diseñar y realizar la evaluación externamente, poniéndose en contacto con elcliente en los momentos puntuales en los que sea necesario.

La metodología de evaluación EVVE, puede ser adaptada a las distintasnecesidades del cliente, existiendo unos catálogos de técnicas de evaluaciónque determinan el nivel y profundidad con el que se desea realizar laevaluación, las métricas de calidad que se obtendrán y las herramientas deevaluación que se utilizarán.

La metodología EVVE define un marco de trabajo que permite determinarlos procesos para llevar a cabo la evaluación de los modelos UML del software.La metodología, en un principio estaba pensada para trabajar con diagramasde casos de uso, diagramas de clases, y diagramas de transición de estados. La


195

metodología de evaluación EVVE se puede aplicar a cualquier modelo de análisisy diseño, siempre que esté especificado bajo la notación UML. Además puedeser utilizada independientemente del modelo de ciclo de vida de desarrolloseguido 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 aaplicar la metodología de evaluación.

9.1.1 Personas, Grupos y Roles

A continuación se detallan los roles y grupos identificados a lo largo delproceso de evaluación, así como las principales tareas y responsabilidades decada uno de ellos. En la siguiente figura se observa los roles involucrados en elproceso de evaluación según la metodología EVVE, así como la relación queexiste entre ellos:

Figura 37: Roles y relaciones en el proceso de evaluación.

Tal y como se aprecia en la figura, la comunicación entre las empresas(cliente y evaluadora) es realizada a través del patrocinador y del evaluador jefe.Éstos a su vez serán los que se comuniquen directamente con sus equiposinternos. A continuación se muestra en una tabla los roles y grupos involucradosen la metodología EVVE.

Roles y Grupos DescripciónEmpresa cliente Representa a la organización que ha expresado su

intención y/o necesidad de contratar los servicios deevaluación de la calidad de los modelos UML.

Patrocinador de laevaluación

El patrocinador de la evaluación es el representantede la empresa cliente que se pone en contacto con laempresa evaluadora para expresar la necesidad deevaluación de la calidad de sus modelos UML. En algunos


196

casos, el patrocinador de la evaluación podrá disponer deun equipo de trabajo interno formado por personal propiode la empresa.

Equipo de la empresa cliente Sirve de apoyo al patrocinador de la evaluación. Suprincipal responsabilidad consiste en analizar losresultados reportados por la empresa evaluadora paradetectar defectos o inconsistencias. La existencia de esteequipo no es necesaria siempre, depende de laenvergadura del proyecto a evaluar.

Empresa evaluadora Representa la organización que ha sido contratada parallevar a cabo el proceso de evaluación. La empresaevaluadora necesitará disponer de un evaluador jefe y uno ovarios evaluadores que formaran el equipo de trabajo quellevará a cabo el proceso de evaluación.

Evaluador jefe Es el representante de la empresa evaluadora y líder delequipo de evaluación, cuyo objetivo es asegurar elcorrecto desarrollo del proceso de evaluación. Este roldebe ser ocupado por un profesional con conocimientos enel análisis y diseño con UML y con experiencia en lapráctica de las principales normas y estándares sobreevaluación del producto y procesos software.

Evaluador Está encargado de realizar las actividades y tareaspropias del proceso de evaluación. Este rol deberáser ocupado por una persona con conocimientos demodelado UML y de la metodología de evaluación.Las principales responsabilidades son, realizar lasactividades de evaluación asignadas por el evaluador jefe yrecoger información del propio proceso de evaluación.

Equipo de evaluación Representa el equipo de la empresa evaluadora, formadopor el evaluador jefe y un conjunto de uno o variosevaluadores de calidad (según los requisitos del proyecto).Su principal objetivo es cumplir con los requisitos deevaluación acordados con el patrocinador dentro de lostiempos planificados.

T a b l a 59 : T a b l a d e Personas, Grupos y Roles

9.1.2 Catálogo de elementos

Los elementos pueden ser de entrada y/o salida para las actividades delproceso de evaluación, siendo algunos de ellos entregables finales del proyectode evaluación. En la siguiente tabla se detallan todos los elementos(documentos, informes, catálogos, artefactos, etc.) que se identifican a lolargo de las actividades de evaluación.

Elemento DetalleInformación de contacto Documento donde la empresa evaluadora recoge los datos

de contacto de la empresa cliente. Como mínimo debepresentar la siguiente información: Nombre de la empresa,la dirección, el teléfono/Fax, Página Web, Persona decontacto, Email de contacto.

Contrato de evaluación Este documento representa el primer entregable del


197

proyecto de evaluación y será generado como resultado dela planif icación. En él se recogen las condiciones bajolas que se realizará el proyecto de evaluación. Estádividido en dos partes:1. Propuesta técnica de evaluación: contiene aspectostécnicos del contrato de evaluación tales como el objetivode la evaluación, el plan de trabajo, el equipo de trabajo, elcalendario y el esfuerzo necesario.2. Propuesta económica de evaluación: contieneaspectos económicos del contrato de evaluación talescomo el precio, el modo de facturación, las cláusulas, lascondiciones generales, etc.

Modelo de calidad genérico Es un documento propiedad de la empresa evaluadoray contiene el conjunto de características, subcaracterísticasy atributos de calidad que se pueden evaluar para cadaartefacto software. Las características ysubcaracterísticas de calidad se encuentran detalladas enla norma ISO 25010.

Modelo de calidad específico Es un documento que solo contiene el conjunto decaracterísticas, subcaracterísticas y atributos de calidadque la empresa cliente ha seleccionado para el proyectode evaluación. Este documento es público y estáintegrado dentro de la especificación de la evaluación querepresenta el tercer entregable del proceso de evaluación.

Catálogo de herramientas deevaluación

Es un documento propiedad de la empresa evaluadora yque permite identificar las herramientas necesarias y sumodo de utilización, en función de las técnicas deevaluación que se vayan a utilizar para evaluar losmodelos UML.

Plan de evaluación Este documento público para ambas partes, y representael segundo entregable del proyecto de evaluación. Unaprimera versión se desarrolla previamente al inicio delproyecto de evaluación, incluida en la propuesta técnicadel contrato de evaluación. Esta primera versión esrefinada por ambas partes tras la aceptación del contrato,generándose así la versión definitiva del plan deevaluación, que guiará todos los procesos y actividadesrealizados durante el proyecto. Este documento esgenerado como resultado de la planificación del procesode evaluación y está sujeta a cambios durante todo elproyecto de evaluación.

Conjunto de artefactos a evaluar Entendiendo por artefactos los modelos UML que laempresa cliente quiere validar, y toda la documentaciónne c e s a r i a para comprender correctamente lanaturaleza y contenido de dichos modelos. Esresponsabilidad del patrocinador que los artefactos aevaluar estén disponibles en las fechas planificadas,asi como es responsabilidad del evaluador jefe asegurarque los artefactos entregados para ser evaluados cumplencon los requisitos impuestos por las técnicas yherramientas que se van a utilizar en el proceso deevaluación.

Especificación de la evaluación Este documento representa el tercer entregable delproyecto de evaluación y como tal es público paraambas empresas. La especificación de la evaluaciónserá generada como resultado de la especificación del


198

proceso de evaluación donde se recoje el conjunto deartefactos a analizar, el modelo de calidad específico quese va a analizar, qué técnicas se van a utilizar, qué métricasse esperan obtener, qué herramientas se van a manejar,entre otros. En definitiva un conjunto de características aevaluar por cada uno de los modelos UML, las técnicas yherramientas que se utilizarán y el listado de métricas eindicadores que se esperan obtener. Estaespecificación posteriormente se incluye dentro delinforme final de evaluación, conforme lo establece lanorma ISO/IEC 14598.

Informe de evaluación Este d oc u m en t o representa el cuarto entregable delproyecto de evaluación y como tal es público para ambasempresas. El informe de evaluación se genera comoresultado de la fase de conclusión y estará formado porun documento con todos los resultados obtenidosmediante las técnicas de evaluación, las conclusionesobtenidas del análisis de dichos resultados y un conjuntode recomendaciones y acciones futuras para la mejora delos modelos UML, además de la especificación de laevaluación. Una característica importante del informe es laretroalimentación que se produce posteriormente a lapresentación de los resultados y en cuyo caso laempresa cliente reporta a la empresa evaluadoramediante el documento petición de modificación.

Petición de modificación Este artefacto representa el quinto entregable delproceso de evaluación y como tal es público paraambas empresas. Este documento se genera comoresultado de la fase de conclusión y representa eldocumento mediante el cual la empresa cliente,manifiesta sus opiniones y posibles cambios respecto a losresultados presentados en el informe de evaluación. Laempresa evaluadora recibirá el documento queevaluará, revisará y actualizará el informe deevaluación de acuerdo a los cambios sugeridos. Elinforme modificado será nuevamente entregado a laempresa cliente. El resultado de esta petición no es másque un refinamiento del informe de evaluación así como lamejora del proceso de evaluación.

Información interna deevaluación

Además durante la evaluación se genera documentaciónrelacionada con el propio proceso. Esta informaciónprincipalmente son informes del proceso de gestión ymonitorización, informes de métricas de la propiaevaluación, informes de cambios y ajustes realizadosdurante la evaluación, informes de defectos yadaptaciones realizadas en la infraestructura deevaluación, entre otros. Posteriormente esta informacióne s utilizada por los procesos Gestión de la Evaluación yGestión de la Infraestructura para realizar una mejoracontinua del proceso de evaluación.

Tabla 60: Catálogo de Elementos


199

9.1.3 Procesos de la metodología de evaluación

La metodología de evaluación EVVE se encuentra compuesta por tres procesosprincipales: Proceso de gestión de la evaluación, Proceso de evaluación yProceso de gestión de la infraestructura.

9.1.3.1 Proceso de evaluación: Este proceso representa el esqueleto de lametodología de evaluación ya que contiene las fases de planificación,especificación, ejecución y conclusión del proyecto de evaluación. El proceso deevaluación se descompone en cuatro fases que son mostradas en la siguientetabla:

Fase DescripciónFase 1: Planificación El objetivo de esta fase es la elaboración del contrato y

la obtención de un plan de evaluación de los modelosUML. Esta fase está formada por cuatro actividades:Contratación, Arranque del proyecto, Planificación detallada yConsolidación del plan.

Fase 2: Especificación El objetivo de esta fase es definir el alcance de laevaluación, determinando el conjunto de características quese van a evaluar para cada uno de los modelos UML(artefactos), las técnicas y herramientas que se van autilizar para realizar la evaluación, los niveles de evaluación(bajo, medio o alto) que se van a aplicar a cadaartefacto y el listado de indicadores y métricas que seesperan obtener. Esta fase está formada por cuatroactividades: Obtención y análisis de artefactos a evaluar,Selección del modelo de calidad y las técnicas, Planificacióninterna de la evaluación, Verificación de la especificación.

Fase 3: Ejecución El objetivo de la fase de ejecución es la aplicación de lastécnicas de evaluación y el lanzamiento de lasherramientas (utilizando como entrada los artefactos aevaluar) para obtener los resultados iniciales (métricas demás bajo nivel) sobre la calidad de los modelos UML. Unavez obtenidos los resultados iniciales, es necesarioasegurar su veracidad (pueden existir defectos en losresultados) y realizar su almacenamiento de una maneraunificada que permita su posterior explotación. Esta fase estáformada por tres actividades: Aplicación de técnicas deevaluación, Análisis de la ejecución, Unificación deresultados.

Fase 4: Conclusión El objetivo de la fase de conclusión es la elaboración delinforme de evaluación y la presentación de los resultadostanto al patrocinador como al resto de personas involucradasdentro de la empresa cliente. Esta fase está formada por tresactividades: Elaboración del informe de evaluación,Presentación de resultados, Corrección del informe yfinalización de la evaluación.

Tabla 61: Fases del Proceso de Evaluación


200

9.1.3.2 Proceso de gestión de la evaluación: Es el proceso de soporte alproceso de evaluación, que permite controlar, evaluar y mejorar el propio procesode evaluación. Este proceso está formado únicamente por una fase, denominadade igual manera que el proceso. Esta fase a su vez se descompone en tresactividades bien diferenciadas: Monitorización, Documentación, Ajuste yEvolución.

9.1.3.3 Proceso de gestión de la infraestructura: Es el proceso de soporteal proceso de evaluación, que permite gestionar todo lo relacionado con lainfraestructura necesaria para llevar a cabo el proceso de evaluación (técnicasy herramientas de evaluación). Este proceso está formado únicamente por unafase, denominada de igual manera que el proceso. Esta fase a su vez sedescompone en tres actividades bien diferenciadas: Especificación de lainfraestructura, Mantenimiento de la infraestructura, Adaptación y transferencia dela infraestructura.

9.2 LECCIÓN 2: IMPLEMENTACIÓN DE LA METODOLOGÍA CON SPEM YEPFC

SPEM 2.0 (Software & System Process Engineering Metamodel) es unmetamodelo de OMG considerado como el estándar de facto en la industriapara la representación de modelos de procesos de ingeniería del software eingeniería de sistemas. Por otro lado, dentro de la plataforma abierta Eclipse, seha desarrollado un editor de SPEM 2 llamado EPFC (Eclipse ProcessFramework Composer), que permite definir, gestionar y reutilizar un repositoriode fragmentos de métodos y procesos. De modo que con EPFC se puedencrear implementaciones en formato SPEM 2 de cualquier método, proceso ometodología de ingeniería del software.

La idea central de SPEM 2 para representar procesos está basada en treselementos básicos: rol, producto de trabajo y tarea.

- Las tareas representan el esfuerzo a hacer.

- Los roles representan quién lo hace.

- Los productos de trabajo representan las entradas que se utilizan enlas 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 yEPFC para la implementación práctica de la metodología EVVE, frente a otrasalternativas son las que se describen a continuación:


201

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

- La creación, revisión, reutilización, adaptación y generación dedocumentación para las metodologías suele ser un proceso puramentemanual.

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

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

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

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

- EPFC permite publicar la documentación de los procesos ymetodologías modelados en formato para la web.

- EPFC reduce el coste de reutilización de contenidos de métodoen una organización.

9.2.2 Diagrama de actividad generado por EPFC

A continuación, se presenta el flujo de trabajo generado por EPFC paralas tareas que se realizan en la actividad Obtención y Análisis de Artefactos aEvaluar, actividad que pertenece a la fase 2 (Especificación) del proceso deevaluación especificado anteriormente.

Tal y como se puede ver en la siguiente figura, esta actividad estácompuesta por 3 tareas las cuales se deben realizar en orden secuencial.Además para cada una de las tareas se muestra en el margen superior izquierdola abreviatura del rol implicado en su realización.

EPFC permite la generación automática de este tipo de diagramas apartir de la información de la metodología introducida en el sistema.Además, desde este tipo de diagramas, EPFC facilita la navegación directaa cada uno de los componentes de la metodología (roles, tareas, productosde trabajo) identificando la trazabilidad bidireccional entre todos estos elementos.


202

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

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

Una de las aplicaciones más estudiadas en la actualidad es la Evaluacióndel Software Educativo Multimedia. Las características que debe cumplir un buensoftware multimedia formativo atienden a diversos aspectos funcionales, técnicosy pedagógicos, que se enuncian a continuación en la siguiente tabla:

Característica DescripciónFacilidad de uso e instalación Hace referencia a que los programas puedan ser realmente

utilizados por la mayoría de las personas, y para ello se hacenecesario que sean agradables, fáciles de usar yautoexplicativos, de manera que los usuarios puedanutilizarlos inmediatamente sin tener que realizar la lectura delos manuales, ni largas tareas previas de configuración. Encada momento el usuario debe conocer el lugar del programadonde se encuentra y tener la posibilidad de moverse segúnsus preferencias: retroceder, avanzar, y un sistema de ayudaonline solucione las dudas que puedan surgir. Además lainstalación del programa deberá ser sencilla, rápida ytransparente. También se debe tener en cuenta la existencia


203

de una utilidad para desintalar para cuando se quiera quitar elprograma.

Versatilidad (adaptación adiversos contextos)

Hace referencia a la funcionalidad, es decir, que seanfácilmente integrables con otros medios didácticos en losdiferentes contextos formativos, pudiéndose adaptar adiversos entornos, estrategias didácticas, y usuarios. Paralograr esta versatilidad debe tener unas características quepermitan su adaptación a los distintos contextos. Por ejemploque sean programables (que permitan la modificación deparámetros como grado de dificultad, tiempo para lasrespuestas, número de usuarios simultáneos, idioma), quesean abiertos (permitiendo la modificación de los contenidosde las bases de datos), que incluyan un sistema de evaluacióny seguimiento o control (informes de las actividades realizadaspor los estudiantes: temas, nivel de dificultad, tiempo invertido,errores, itinerarios seguidos para resolver los problemas), quepermitan continuar los trabajos empezados con anterioridad, yque promuevan el uso de otros materiales (fichas,diccionarios) y la realización de actividades complementarias(individuales y en grupo colaborativo).

Calidad del entornoaudiovisual

El atractivo de un programa depende en gran manera de suentorno comunicativo. Algunos de los aspectos que másdeben cuidarse son: el diseño general claro y atractivo de laspantallas (sin exceso de texto y que resalte los hechosnotables), la calidad técnica y estética en sus elementos(títulos, menús, ventanas, iconos, botones, espacios de texto-imagen, formularios, barras de navegación, barras de estado,elementos hipertextuales, fondo), elementos multimedia(gráficos, fotografías, animaciones, vídeos, voz, música), estiloy lenguaje, tipografía, color, composición, entre otros, laadecuada integración de medios.

La calidad en los contenidos(bases de datos)

Además de las consideraciones pedagógicas sobre laselección y estructuración de los contenidos según lascaracterísticas de los usuarios, se debe tener en cuenta: Lainformación que se presenta es correcta y actual, los textos notienen fallas, no hay discriminaciones, la presentación ydocumentación.

Navegación e interacción Los sistemas de navegación y la forma de gestionar lasinteracciones con los usuarios determinan su facilidad de usoy amigabilidad, por eso se debe tener en cuenta los siguientesaspectos: Mapa de navegación, Sistema de navegación, lavelocidad entre el usuario y el programa es adecuada, el usodel teclado, el análisis de respuestas, La gestión de preguntas,respuestas y acciones, la ejecución del programa.

Originalidad y uso detecnología avanzada

Los programas deben presentar entornos originales, biendiferenciados de otros materiales didácticos, y que utilicen lascrecientes potencialidades del computador y de lastecnologías multimedia e hipertexto en general, donde elcomputador resulte potenciador del proceso de aprendizaje,favorezca la asociación de ideas y la creatividad, permita lapráctica de nuevas técnicas, la reducción del tiempo y delesfuerzo necesarios para aprender y facilite aprendizajes máscompletos y significativos.

Capacidad de motivación Para motivar al estudiante, las actividades de los programasdeben despertar y mantener la curiosidad y el interés de losusuarios hacia la temática de su contenido, sin provocar


204

ansiedad y evitando que los elementos lúdicos interfierennegativamente en los aprendizajes. También conviene queatraigan a los profesores y les animen a utilizarlos.

Adecuación a los usuarios y asu ritmo de trabajo

Los programas deben tener en cuenta la audiencia de losestudiantes a los que van dirigidos y los progresos que vayanrealizando. Cada sujeto construye sus conocimientos sobre losesquemas cognitivos que ya posee, y utilizando determinadastécnicas. Esta adecuación se manifestará en tres ámbitosprincipales: Los contenidos deben ser significativos para losestudiantes y estar relacionados con situaciones y problemasde su interés, actividades de tipo de interacción, duración,elementos motivacionales, mensajes de corrección de erroresy de ayuda, niveles de dificultad, itinerarios, progresión yprofundidad de los contenidos según los aprendizajesrealizados, Y el entorno de comunicación.

Potencialidad de los recursosdidácticos

Los programas multimedia utilizan potentes recursosdidácticos para facilitar los aprendizajes de sus usuarios. Entreestos recursos se pueden destacar: Proponer diversos tiposde actividades que permitan diversas formas de utilización yde acercamiento al conocimiento, utilizar organizadoresprevios al introducir los temas, síntesis, resúmenes yesquemas, emplear diversos códigos comunicativos, incluirpreguntas para orientar la relación de los nuevosconocimientos con los conocimientos anteriores de losestudiantes, tutorización las acciones de los estudiantes,orientando su actividad, prestando ayuda cuando lo necesitany suministrando refuerzos.

Fomento de la iniciativa y elautoaprendizaje

Las actividades de los programas educativos deben potenciarel desarrollo de la iniciativa y el aprendizaje autónomo de losusuarios, proporcionando herramientas cognitivas para que losestudiantes hagan el máximo uso de su potencial deaprendizaje, puedan decidir las tareas a realizar, la forma dellevarlas a cabo, el nivel de profundidad de los temas y puedanautocontrolar su trabajo. Además estimularán el desarrollo dehabilidades metacognitivas y estrategias de aprendizaje en losusuarios, que les permitirán planificar, regular y evaluar supropia actividad de aprendizaje, provocando la reflexión sobresu conocimiento y sobre los métodos que utilizan al pensar.

Enfoque pedagógico actual El aprendizaje es un proceso activo en el que el sujeto tieneque realizar una serie de actividades para asimilar loscontenidos informativos que recibe. Las actividades de losprogramas deben estar en consonancia con las tendenciaspedagógicas actuales, para que su uso en las aulas y demásentornos educativos provoque un cambio metodológico eneste sentido. Por lo tanto los programas evitarán la simplememorización y presentarán entornos heurísticos centrados enlos estudiantes que tengan en cuenta las teoríasconstructivistas y los principios del aprendizajesignificativo donde además de comprender los contenidospuedan investigar y buscar nuevas relaciones.

La documentación Los programas deberán tener una información acerca de suscaracterísticas, forma de uso y posibilidades didácticas. Estadocumentación debe tener una presentación agradable, contextos bien legibles y adecuados a sus destinatarios, y resultarútil, clara, suficiente y sencilla. Se distingue tres partes: Ficharesumen (con las características básicas del programa), El


205

manual del usuario (Presenta el programa, informa sobre suinstalación y explica sus objetivos, contenidos, destinatarios,modelo de aprendizaje que propone, sus opciones yfuncionalidades), la guía didáctica (con sugerencias didácticasy ejemplos de utilización que propone estrategias de uso yindicaciones para su integración curricular).

Esfuerzo cognitivo Las actividades de los programas, contextualizadas a partir delos conocimientos previos e intereses de los estudiantes,deben facilitar aprendizajes significativos y transferibles a otrassituaciones mediante una continua actividad mental enconsonancia con la naturaleza de los aprendizajes que sepretenden. Así desarrollarán las capacidades y las estructurasmentales de los estudiantes y sus formas de representacióndel conocimiento (categorías, secuencias, redes conceptuales,representaciones visuales) mediante el ejercicio de actividadescognitivas del varios tipos (control psicomotriz, memorizar,comprender, comparar, relacionar, calcular, analizar, sintetizar,razonamiento, pensamiento divergente, imaginar, resolverproblemas, expresión, crear, experimentar, explorar, reflexiónmetacognitivareflexión sobre su conocimiento y los métodosque utilizan al pensar y aprender).

Tabla 62: Características de los Productos de Software Educativo Multimedia

9.4 LECCIÓN 4: MODELOS DE EVALUACIÓN DE SOFTWARE EDUCATIVOMULTIMEDIA

Existe una diversidad de herramientas y modelos para la evaluación de productosde software multimea educativos, dentro de ellos se han elegido algunos que sonlos más representativos y de los cuales se describirá la metodología de aplicación.Cada modelo tiene unas características específicas que diferencian y a la vezcomplementan a los otros modelos. A continuación se hará una descripción de losmodelos seleccionados, las características y componentes que deben serevaluados.

9.4.1 Modelo de evaluación de materiales educativos computarizados deGalvis

Uno de los modelos más conocidos para la evaluación de productoseducativos computarizados (MEC) es planteado por Galvis, que propone unmodelo que será descrito por sus componentes y criterios. Este autor establece laevaluación como actividad necesaria para la elaboración de información requeridaen la toma de decisiones, siendo aplicable a cualquier sistema. Para la evaluaciónsistemática de los MEC, se establecen criterios relevantes y consistentes,Además de la creación de instrumentos de evaluación válidos y confiables segúnlas fuentes de información apropiadas al respecto. Los MEC se desarrollan parasatisfacer necesidades educativas que no pueden ser abordadas por otros mediosde enseñanza, y por consiguiente, debe ser de calidad y viables de utilizar porparte de los usuarios a quienes va dirigido.


206

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

ASPECTOS VARIABLES CRITERIOSFunción educativa del tipo de MEC Aborda la necesidad educativaGeneralesFunción administrativa Suministra información útil para el

docenteObjetivos del material El nivel de dificultad es adecuado a la

necesidad educativaContenido Es claro, conciso y actualizado.

Enseñanza

Estrategias de Instrucción Estas son coherentes y suficientespara lograr los objetivos previstos.

Opinión y actitud del estudiante. Es positiva frente al programa.AprendizajeRealimentación de sudesempeño

Se ofrece en forma oportuna,amigable y adecuada.

Tabla 63: Partes de la calidad educacional del MEC

ASPECTOS VARIABLES INDICADORESGenerales Funciones según el usuario

Características de: interfaz,programa, programación.

Fácil de utilizar. Amigable. Claridad deinstrucciones. Legibles. Biendocumentada

Estructura de la información Son eficientes y adecuadas a los datosdel programa

Técnicos

Recursos computacionales Los suministrados por el equipo sonutilizados al máximo

Tabla 64: Calidad computacional del MEC y sus elementos

VARIABLES CRITERIOSRequerimientos de Hardware Los diversos equipos se pueden conseguir en el mercadoRequerimientos de Software Los diversos softwares que amerita son fáciles de usarRequerimientos de personal El personal técnico de orientación al usuario es localizable.Requerimientos financieros Estos son accesibles a los aprendices del programa.

Tabla 65: Elementos considerados en la viabilidad del recurso informático

En cuanto a los tipos de evaluaciones de los recursos educativos computarizados,este autor propone la Valoración comprensiva del MEC por expertos y la Pruebacon estudiantes. En la siguiente tabla se muestra las variables, indicadores ycriterios de valoración considerados en esta prueba.

VARIABLES INDICADORES CRITERIOS PARA VALORAR

Relevancia ypertinencia

Contenido, objetivos.Tipo de software educativo.

El programa satisface una necesidadeducativa que no puede ser lograda con otrosmedios existentes


207

Viabilidad Requerimientoscomputacionales.Requerimientos físicos.Costos

El software educativo es viable de utilizar porlos usuarios a quien se dirige considerandosus recursos disponibles. Los costos deadquisición y mantenimiento permiten laaccesibilidad del MEC por los aprendices.

Interactividad Participación que exige delusuario.

El MEC emplea al máximo la capacidad deinteracción que suministra el computador.

Calidad comotipo deaplicación

Funciones educativas queasume el MEC.

El tipo o combinaciones de MEC requeridossegún la necesidad educativa son un buenprototipo de estos.

Tabla 66: Elementos Considerados en la Valoración Comprensiva del MEC

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

VARIABLES INDICADORESObjetivos El nivel de complejidad es adecuado para el uso de softwareContenido Es coherente, suficiente y actualizado en relación a los objetivosDesarrollo delcontenido

El estudiante siempre esta informado sobre su ubicación dentro delcontenido.

Herramientas Estas son: adecuadas, sencillas de usar y facilitan la exploración.Retroinformación Su orientación es suficiente y adecuada a la actuación del aprendiz.

Tabla 67: Algunos elementos de la valoración por experto en contenido del MEC

VARIABLES INDICADORESObjetivos Definidos claramente.Motivación Se mantiene el interés por el logro de los objetivos.Metodología Se sustenta en una didáctica adecuada al contenido a enseñar.

Las pantallas no se encuentran sobrecargadas de información.Interfaz de salidaEl vocabulario o terminología es apropiada para el nivel cultural delusuario.

Tabla 68: Elementos considerados en la valoración por experto en metodología

Posteriormente es necesario comprobar que para los usuarios reales(docentes y estudiantes) representa un apoyo para el logro de sus objetivos. Estalabor se lleva a cabo con las pruebas: piloto (realizada a una muestrarepresentativa de la población a la que se dirige el software) y de campo (se aplicaa toda la población). Adicionalmente, se propone la encuesta final del MEC para


208

recabar información sobre sus aspectos didácticos, lo que permitirá hacer losajustes y recomendaciones necesarias para su uso en el proceso de enseñanza-aprendizaje.

El aporte de Galvis al modelo de evaluación de software educativo loconstituye el tratamiento sistémico de la valoración de los materiales educativoscomputarizados, por cuanto establece diversos tipos de pruebas (juicio deexpertos en contenido, metodología e informática; pruebas piloto y de campo,encuestas a los usuarios) son realizadas por diferentes fuentes de información(informantes). Además especifica las variables, indicadores y criterios deevaluación que responden a la calidad educativa y computacional del recursoinformático. En los instrumentos de evaluación resalta la consideración de losproblemas del material, su localización y posible solución, junto con sus aspectospositivos, negativos y sugerencias de uso en el proceso de enseñanza-aprendizajereal.

9.4.2 Lista de control para la evaluación de software educativo de Bostock

Otro de los autores que propone una lista de Control para la Evaluación deSoftware Educativo es Bostock, la cual ha sido reestructurada y actualizada. Lassiguientes tablas presentan las variables, características más importantes y losindicadores de los aspectos técnicos y pedagógicos.

En referencia a los aspectos técnicos más importantes se muestran lassiguientes categorías: Protección del programa, Calidad y disposición de laspantallas e Interactividad. Al evaluar el software se debe considerar los casos enque el formato del programa tenga daños, o requiera de otro software adicionalpara su funcionamiento, casos donde se hace necesario disponer de otras copiasdel mismo y disponer de elementos de hardware adicionales para la operatividadde la aplicación.

Los aspectos pedagógicos abarcan desde los objetivos hasta laadaptabilidad del software. Esta última categoría define el rol del docente durantela aplicación del software en función de lo que le permita realizar el programafrente a sus estudiantes. La evidencia de progreso del estudiante, muestra lasformas como la aplicación puede llevar a cabo este seguimiento, que junto a larealimentación, establecen un posible tratamiento frente a respuestas incorrectasdel aprendiz.

VARIABLES CARACTERÍSTICAS Y/O INDICADORESEquipos necesarios y materiales de apoyo del Software:¿Se dispone de información sobre la capacidad de memoria y losperiféricos requeridos? ¿Hay un manual sobre la instalación y la puestaen marcha del programa? ¿Especifica las características mínimasnecesarias para su correcta operación?Asistencia técnica: ¿La ofrece? ¿Te ayuda a recuperar fallas?

Requerimientostécnicos

Protección del programa: ¿Posee un mecanismo de seguridad que nopermite la copia no autorizada del programa? ¿Tiene el usuario un


209

respaldo disponible? ¿Reemplazan los CDs defectuosos? ¿Lainformación se limita a un número determinado de estaciones detrabajo? ¿Se debe mantener el CD o el Internet conectado para poderacceder al material?Validación: ¿El programa fue validado por especialistas? ¿Puede elusuario obtener una versión de prueba?Organización de la Pantalla: Se refiere al uso del espacio y la forma enque la información se despliega en la pantalla.Texto en la pantalla: ¿La presentación del texto le permite al usuarioleerlo de forma sistemática? ¿Están las palabras importantes de lospárrafos enfatizadas? ¿El fondo de la pantalla permite leer sin problemasel texto? ¿Hay un cambio en la página cuando se presenta nuevainformación? ¿El espaciado entre las palabras y las líneas es óptimo?Gráficos: ¿Se encuentran bien posicionados? ¿Son las imágenesambiguas? ¿Hay acceso a una ilustración cada vez que sea necesario?Color: ¿Se usa el color para captar la atención hacia puntosimportantes? ¿Hay suficiente contraste de color entre el fondo, losgráficos y el texto? ¿Hay colores específicos para ciertos tipos demensajes?Sonido: ¿Puede el usuario controlar el sonido? ¿Se usaapropiadamente el sonido para captar la atención?Calidad y disposición de las pantallas: ¿Hay variedad? ¿La transiciónes adecuada? ¿Se pueden sobreponer? ¿Es posible controlar lavelocidad de transición? ¿Se utilizan señales para atraer la atenciónhacia partes importantes?Interactividad: Definida para un software educativo como, si reaccionade una manera que sea variada y adaptable según las respuestas desus diferentes usuarios y si le permite a este último afectar la manera enla cual el software procedePuede el usuario: ¿Obtener ayuda? ¿Detener el programa y salir avoluntad? ¿Ver el objetivo alcanzado hasta el momento y los que faltan?¿Controlar la velocidad de la presentación? ¿Controlar la cantidad deinformación?

Diseño de laInterfase

Respecto al programa, después de elecciones del usuario:¿Puede mostrar diferentes mensajes? ¿Puede seleccionar diferentesalternativas dependiendo de la dificultad? ¿Puede proveer unaretroalimentación diferenciada adaptada? ¿Puede tomar en cuenta lasdiferentes formas de trabajar? ¿Puede ayudar al usuario? ¿Le da pistaso acepta respuestas aproximadas?

Tabla 69: Aspectos técnicos de la evaluación de software de Bostock

VARIABLES CARACTERÍSTICAS Y/O INDICADORESEstructura interna delsoftware

¿Es la división de los módulos la apropiada? ¿Están los objetivos decada modulo explicados apropiadamente? ¿Los diferentesprocedimientos tienen coherencia hacia una idea principal?

Legibilidad Determina si es agradable para leerlo.Texto: ¿Se usa un vocabulario adecuado al nivel de educación delusuario? ¿Las oraciones están estructuradas con coherencia?Gráficos: ¿Complementan y se identifican con el texto? ¿Son detamaño apropiado? ¿Su complejidad esta adecuada al nivel deeducación del aprendiz?

Analizador derespuestas

Consiste en todas las operaciones que se utilizan para lidiar con lasrespuestas en un lenguaje común. Su calidad depende de laextensión y la variedad de las respuestas que es capaz de


210

interpretar. ¿Hay varias maneras de expresar los mismos resultadosnuméricos? ¿Se especifica la unidad requerida? ¿Acepta que larespuesta numérica en unidades se exprese de distintas maneras?¿Permite el uso de respuestas aproximadas o equivalentessemánticos?

Contenido ¿Es preciso, progresivo y actualizado? ¿Contiene introducciones alos temas, o relaciones con los temas anteriores? ¿Se le daimportancia a los puntos esenciales? ¿Las simulacionescorresponden con el ambiente real? ¿Contiene ejemplosapropiados?

Retroalimentación Es la información dada al usuario sobre la validez de sus respuestas¿Es apropiada al nivel educativo del aprendiz? ¿Puede variardependiendo de la respuesta? ¿Especifica que respuesta fue laincorrecta, por qué fue incorrecta y cuál sería la correcta?

Evidencia del progresodel usuario

¿Puede el usuario evaluar los resultados de una sesión de uso?¿Puede el aprendiz llevar un registro de la experiencia deaprendizaje realizada? ¿Puede el usuario conocer los objetivosalcanzados? ¿Puede el estudiante acceder a una lista de futurasactividades sugeridas?

Adaptabilidad ¿Puede el instructor modificar la documentación y/o los ejemplos?¿Puede el docente cambiar objetivos? ¿Se puede usar el programaen diferentes intervalos de tiempo eficazmente? ¿Puede el instructormodificar la libertad y por lo tanto el progreso del aprendizaje delusuario?

Tabla 70: Aspectos pedagógicos de la evaluación de software de Bostock

Esta lista de control de evaluación de software educativo aporta unavariedad de preguntas que orientan al evaluador en el proceso. Otro elementoimportante lo constituye la protección del programa, factor que se debe considerarcuando se presentan fallas en la aplicación. El instrumento integra explicacionesde algunas variables, aspecto que puede canalizar las dudas del evaluador y lohace bastante concreto y práctico. Por otra parte, ofrece resultados cualitativos yaque no especifica una valoración cuantitativa de los ítems.

9.4.3 Metodología de evaluación de software educativo de Cataldi

Otra de las autoras que propone un modelo de evaluación es Cataldi, quienestablece la importancia de la evaluación del software educativo por el crecimientorápido de la cantidad de éstos en el mercado. Los docentes tienen la necesidad deevaluarlos para determinar su grado de adecuación a su propio entorno, mientrasque los estudiantes requieren saber cómo pueden mejorar sus aprendizajesmediante una aplicación específica. En general, el desarrollo de instrumentos deevaluación y el hecho de utilizarlos con un programa en particular y un grupo deusuarios específico no aporta resultados generalizables a todas las áreas de uso,pero ofrece orientaciones en su selección para los docentes.

Cataldi propone una metodología de evaluación de software educativo entres momentos de su ciclo de vida. Una evaluación interna realizada por el equipode desarrolladores del programa durante la creación de prototipos. Otra externa,


211

aplicada al producto final por los docentes; y la evaluación contextualizadaefectuada en un contexto parecido a aquel para el cual fue elaborado el software,que brinda información sobre las reacciones de los usuarios de la eficacia de laaplicación.

El software educativo integra dos aspectos fundamentales a evaluar: eltécnico y el pedagógico que conlleva a establecer la calidad técnica y educativa.La calidad educativa de estas aplicaciones se refiere a la potenciación dehabilidades cognitivas y de adquisición de conocimientos a partir del uso delsoftware en particular. La siguiente tabla muestra los aspectos pedagógicos,didácticos y los técnicos

ASPECTOS CRITERIOSFacilidad de UsoUtilidadGrado de adaptación a otros niveles de usuariosClaridad de contenidosNivel de actualizaciónInterfase de navegaciónNivel de Motivación¿Es adecuado para la comprensión del tema?

Pedagógicos ydidácticos

¿Es adecuado para el aprendizaje del tema?¿Hay documentación y ayudas?Técnicos¿Son adecuados los recursos que necesita?

Tabla 71: Esquema de evaluación del producto final

La autora sostien que el software educativo debe reunir algunascaracterísticas de acuerdo a las necesidades de aplicación y los objetivoseducativos a lograr, y también debe responder a la calidad y pertinencia, así seestablece en la siguiente tabla el criterio de usabilidad y varios subcriterios,valorados según tres niveles: muy bueno (valorado con 3 puntos), bueno (2puntos) y malo (1 punto).

CRITERIO UTILIDAD SUBCRITERIOS VALORACIÓNUtilidad externa Velocidad de aprendizaje; facilidad de uso; nivel

de adicción.Muy bueno, bueno ymalo.

Utilidad interna Nivel de legibilidad; grado de comprensión; usode menús, gráficos e imágenes; mensajes deerrores e información; ayudas online; definiciónde adecuación de la interfase

Muy bueno, bueno ymalo.

Tabla 72: Criterios y Subcriterios para Evaluación de la Calidad del SoftwareEducativo

A partir de la revisión de la información presentada en las tablas anteriores,junto al cuestionario de evaluación del producto final, se presenta la siguiente tablaque indica las características de las variables según los criterios de calidadprevistos.


212

CATEGORÍAS DIMENSIONES ALGUNAS CARACTERÍSTICASTécnica Interfase La interfase es amigable y de fácil manejo.

El diseño general de la pantalla es adecuado.La secuenciación de las pantallas se rige por criterios.El uso de ventanas, botones, colores, tipos de letras esadecuado.El uso de iconos es correcto.La utilización de teclas rápidas es útil.

Contenidos Su selección es adecuada y actualizada.El programa se puede adaptar a otros niveles deusuarios.Su estructura le permite al usuario conocer hacia dondeva en los aprendizajes.Se le facilita la comprensión del tema al aprendiz.

Pedagógica

Condicionesrelativasal usuario

Despierta su interés.Prefiere que el programa sea tutorial.Le gustaría sonidos en los videosEl programa le permite ver cosas que no se hubieseimaginado.

Tabla 73: Características de las variables según criterios de calidad

En cuanto a la evaluación contextualizada del software educativo, se deberealizar experiencias para establecer las diferencias en cuanto al logro deaprendizajes significativos entre un software elaborado con la metodologíaextendida en los aspectos pedagógicos y otro de idéntica funcionalidad perodesarrollado con una metodología tradicional.

9.4.4 Instrumento de evaluación de recursos multimedia de Soto y Gómez

Soto y Gómez, proponen un instrumento de evaluación de recursosmultimedia para la atención a la diversidad, denominado “EVALÚA”, que es unabase de datos sobre software educativo que pretende ser un instrumento de apoyoa los docentes en la labor de evaluación y selección de recursos informáticos, conel propósito de favorecer la integración de las TIC en el sistema educativo.

La ficha de evaluación del software contiene las siguientes partes: Datos delprograma (datos descriptivos de la aplicación), Aspectos curriculares (relativos alcurrículum, destinatarios y la descripción educativa), Aspectos pedagógicos(motivación, contenidos, interactividad y las capacidades que desarrolla), Aspectostécnicos-estéticos (el entorno audiovisual, navegación y calidad de contenidos),Observaciones y valoración global. Los aspectos pedagógicos y técnicos-estéticosson valorados en una escala cuantitativa de 1 a 5 puntos, uno es muy bajo y 5muy alto. A continuación se muestra la siguiente tabla, donde se presentanalgunas características de este instrumento.

ASPECTOS VARIABLES CARACTERÍSTICA O INDICADORESIdentificación delprograma

Título de la aplicación.Datos del autor o empresa.

Datos delprograma

Requerimientos Información sobre el procesador mínimo.


213

técnicos Espacio que ocupa en disco.Configuración de colores y área de pantalla.

Tipo de adquisicióndel software.

La aplicación es gratuita.

Tipo de dificultad queaborda

Un icono la indica: auditiva, visual, motorica

Destinatarios Edad recomendadaUbicación en elcurrículum

Etapa educativa. Ciclo dentro de la etapa.Área/ámbito.

Contenidoscurriculares

Se presenta en orden de importancia

Curriculares

Descripcióneducativadel programa

Objetivos, niveles de dificultad, opciones deimpresión, informes de evaluación

Capacidad demotivación

Es motivante si: elementos del mismo (colores,animaciones, sonidos) atraen la curiosidad delaprendiz.; las actividades atraen al docente y lesanima a usarlo con sus estudiantes.Los contenidos son significativos para el usuario yse relación con situaciones y problemas de suinterés.

Adecuación a loscontenidos

Presenta niveles de dificultad acorde con losestudiantes.La velocidad entre el usuario y el programa(animaciones, lectura de datos) es adecuada.

Interactividad

Se tutoriza la acción del aprendiz, orientando suactividad, prestando ayuda efectiva oportunamente yofrece refuerzos positivos.

Pedagógicos

Capacidades quedesarrolla

Según los niveles cognoscitivos de Bloom:conocimientos, comprensión, análisis, creatividad,resolución de problemas.Diseño general claro y atractivo de las pantallas, sinexceso de texto y que resalte a simple vista loshechos notables.Calidad técnica y estética de: títulos, menús,ventanas, iconos, botones, gráficos, animaciones,videos, voz.

Entorno audiovisual

Adecuada integración de medias al servicio delaprendizaje sin redundancias.Facilidad de uso y amigabilidad del software.Mapa de navegación bien estructurado, de accesofácil y rápido a los distintos elementos del programa.

Navegación

Sistema de navegación transparente que permita alaprendiz ejercer el control efectivo sobre elprograma.Información presentada científicamente correcta yactualizada.

Técnico-estético

Calidad de loscontenidos

Si no hay discriminaciones, los contenidos ymensajes no son negativos o tendenciosos.

Observaciones Aspectos relevantes Ventajas y desventajas Recomendaciones para suusoDatos de utilidad acerca de suinstalación, manejo yfuncionamiento.

Valoración global Puntuación deaspectos

Se ilustra con número de estrellas.


214

Pedagógicos ytécnicos-estéticos.

Tabla 74: Algunas características de la ficha de evaluación de software

Este instrumento de evaluación aporta una forma sencilla para la valoraciónde software educativos, integrando aspectos cualitativos con cuantitativos, utilizasímbolos para la valoración global y para identificar el tipo de dificultad queaborda. En los aspectos pedagógicos resalta el establecimiento de niveles dedificultad de acuerdo a los usuarios, además de precisar las capacidades quedesarrolla el programa. Desde el punto de vista técnico-estético esta integraciónresulta muy favorable, permitiendo que específicamente el entorno audiovisual,presente tanto un diseño claro en las pantallas como atractivo en suscomponentes.

9.5 LECCIÓN 5: PLANTILLAS DE EVALUACIÓN DE SOFTWAREMULTIMEDIA

Al seleccionar un programa para utilizarlo en una determinada situacióneducativa hay que considerar dos aspectos fundamentales: sus características ysu adecuación al contexto en el que se quiere utilizar. Para conocer lascaracterísticas de un programa, el profesor debe leer el manual e interactuar conél con el propósito de determinar sus objetivos, los contenidos, el planteamientodidáctico, el tipo de actividades que presenta, la calidad técnica, es decir, deberárealizar una evaluación del programa.

Para facilitar esta evaluación objetiva de las características de un programa,se propone una ficha de catalogación y evaluación que permitirá recoger losrasgos principales del programa y algunas valoraciones sobre sus aspectostécnicos, pedagógicos y funcionales.

FICHA DE CATALOGACIÓN Y EVALUACIÓN MULTIMEDIATítulo del programa

(+ versión, idiomas)

Autores

(+ e-mail)

Editorial

(+ año, lugar, web)Temática

(área, materia)


215

Objetivos

.

.

.

Contenidos que se tratan

(hechos, conceptos, procedimientos, actitudes)

.

.

.

Destinatarios

(características, etapa educativa)(subrayar uno o varios de cada apartado)

TIPOLOGÍA: EJERCITACIÓN-TUTORIAL-BASE DE DATOS-LIBRO-SIMULADOR-JUEGO-CONSTRUCTOR-HERRAMIENTA

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

ENFOQUE PEDAGÓGICO: CONDUCTISTA - COGNITIVISTA - CONSTRUCTIVISTA -NINGUNO

DOCUMENTACIÓN: MANUAL - GUÍA DIDÁCTICA - MANUAL ON-LINE - GUÍA DIDÁCTICAON-LINE - OTROS –NINGUNABreve descripción

.

.

.

Requisitos técnicos

(hardware y software)Valores que potencia o presentaASPECTOS FUNCIONALES. UTILIDAD

valorar EXCELENTE, ALTA, CORRECTA o BAJA- Eficacia (puede facilitar el logro de los objetivos que pretende)


216

- Facilidad de uso e instalación (entorno amable)

- Versatilidad (ajustable, modificable, niveles de dificultad, evaluación, informes)ASPECTOS TÉCNICOS Y ESTÉTICOS- Calidad del entorno audiovisual (pantallas)

- Calidad en los contenidos (texto,audiovisual...)

- Navegación e interacción

- Originalidad y uso de tecnología avanzadaASPECTOS PEDAGÓGICOSEsfuerzo cognitivo que exigen sus actividades:

marcar uno o varios• CONTROL PSICOMOTRIZ• MEMORIZACIÓN /EVOCACIÓN• COMPRENSIÓN / INTERPRETACIÓN• COMPARACIÓN / RELACIÓN (orden, clases...)• ANÁLISIS / SÍNTESIS• CÁLCULO• RAZONAMIENTO (deductivo, inductivo, crítico)

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

• REFLEXIÓN METACOGNITIVA

OBSERVACIONESVentajas que comporta respecto a otros medios

.

Problemas e inconvenientes

.

A destacar...

. IMPRESIÓN PERSONAL. me ha gustado: si no lo recomendaría: si noNOMBRE DE LA PERSONA EVALUADORA Y FECHA:

Tabla 75: Ficha de Catalogación y Evaluación

9.5.1 Aspectos a considerar en la selección de producto multimedia


217

Para cada situación educativa concreta puede aconsejar, la utilización dedeterminados programas educativos multimedia como generadores de actividadesde aprendizaje para los estudiantes y, por otra parte, un mismo programa puedeconvenir utilizarlo de manera distinta en contextos educativos diferentes. Comonorma general conviene utilizar un determinado programa cuando su empleoaporte más ventajas que la aplicación de otros medios didácticos alternativos. Yen cuanto a la forma de utilización, nuevamente será la que proporcione másventajas. La utilización de los medios debe venir condicionada por los siguientesfactores:

Las características del material: Hardware necesario, calidad técnica, facilidadde uso, objetivos y contenidos, actividades, planteamiento pedagógico...

La adecuación del material a las circunstancias: Que caracterizan la situacióneducativa donde se piensan aplicar: objetivos, características de los estudiantes,contexto, entre otros.

El coste: Costo del material o el esfuerzo que hay que realizar para poderdisponer de él. También hay que considerar la posibilidad de utilizar otros mediosalternativos que puedan realizar la misma función pero de manera más eficiente.

9.5.2 Diseño de actividades con soporte multimedia

Para diseñar actividades formativas con soporte multimedia hay que tener encuenta diversos aspectos:

Las características del contexto educativo: Marco general, características.

Las características de los estudiantes: Edad, capacidades, conocimientos yhabilidades previas, experiencias, actitudes, intereses, entorno sociocultural.

Los objetivos educativos que se persiguen: Con la realización de la actividad ysu importancia dentro del marco del programa de la materia.

Los contenidos: que se tratarán.

La selección de los materiales didácticos: Se considerarán las característicasde los materiales, adecuación a la situación educativa (estudiantes, objetivos) y elcosto de los diversos materiales al alcance.

La función que tendrá el material: Según las características del material y segúnla manera en que se utilice, un mismo programa puede realizar diversasfunciones: Motivación del estudiante; Fuente de información y transmisión decontenidos; Entrenamiento, ejercitación, práctica, adquisición de habilidades deprocedimiento, memorizar; Instruir (conducir aprendizajes); Introducción yactualización de conocimientos previos; Núcleo central de un tema; Repaso,


218

refuerzo; Recuperación; Ampliación, perfeccionamiento; Entorno para laexploración (libre o guiada), descubrimiento; Entorno para experimentar, Investigar(explorar el conocimiento); Evaluación; Medio de expresión personal (escrita, oral,gráfica); Medio de comunicación; Instrumento para el proceso de datos;Entretenimiento

El entorno en el que se utilizará: Espacio, en el aula normal, en la biblioteca osala de estudio, en el aula informática, en la empresa, en casa; Tiempo,escolar/laboral, extraescolar, en casa; Otras características y condicionantes.

La organización de la actividad: Se considerará especialmente: Agrupamiento,individual, parejas, grupo pequeño, grupo grande; Ámbito de aplicación, todos losestudiantes, sólo algunos estudiantes (refuerzo, recuperación, ampliación deconocimientos), sólo el profesor.

La metodología: La manera en la que se va a utilizar el programa: Papel delprograma (Información que facilitará al estudiante, Tareas que propondrá, Modoen que deberán realizarse); Papel de los estudiantes (Tareas que realizarán losestudiantes; Nivel de autonomía en el uso del programa, si es libre, semidirigido,dirigido, siguiendo las instrucciones específicas del profesor; Interacciones decada estudiante (Con el programa, Con otros compañeros: consultas, opiniones,comentarios, Con el profesor: consultas, orientaciones, ayudas, Con otrosmateriales fuentes de información); Técnicas de aprendizaje que se utilizarán (Repetitivas (memorizando), Elaborativas (relacionando la nueva información con laanterior): subrayar, resumir, esquematizar, elaborar diagramas y mapasconceptuales, Exploratorias: explorar, experimentar, Regulativas (analizando yreflexionando sobre los propios procesos cognitivos, metacognición)); Papel delprofesor (Información inicial a los estudiantes (objetivos, trabajo a realizar,materiales y metodología, fuentes de información), Orientación y seguimiento delos trabajos (dinamización, asesoramiento y orientación); Técnicas de enseñanzaque se utilizarán ( Motivación, Ejercicios de memorización, Prácticas para laadquisición de habilidades de procedimiento, Enseñanza directiva, Exploraciónguiada, Experimentación guiada, Descubrimiento personal, Expresión personal,Comunicación interpersonal, Metacognición.

Empleo de materiales complementarios. ¿Cuáles?, cómo?

El sistema de evaluación que se seguirá para determinar en que medida losestudiantes han logrado los aprendizajes previstos y la funcionalidad de lasestrategias didácticas utilizadas.

DISEÑO DE ACTIVIDADES CON SOPORTE MULTIMEDIA

Contexto educativo

.


219

Estudiantes

(edad, capacidades, conocimientos...)

Objetivos que se persiguen

.

.

.

Contenidos que se tratan

(hechos, conceptos, procedimientos, actitudes)

.

.

.

Programa multimedia

(subrayar uno o varios de cada apartado)

FUNCIÓN QUE REALIZARÁ: ENTRENAR - INSTRUIR - INFORMAR - MOTIVAR -EXPERIMENTAR -

EXPRESARSE - COMUNICARSE - ENTRETENER - EVALUAR - PROCESAR DATOS

ENTORNO DE USO:CLASE-AULA INFORMÁTICA-OTRAS SALAS-USO EXTRAESCOLAR-CASA

ORGANIZACIÓN: TODOS LOS ESTUDIANTES-ALGUNOS-SÓLO PROFESOR

USO INDIVIDUAL - PAREJAS - GRUPO - - - TODOS A LA VEZ - SUCESIVAMENTE

El programa

(información que facilitará, tareas que propondrá)

.

.

El estudiante

(tareas, autonomía, interacciones, técnicas de aprendizaje)

.


220

.

El profesor

(información inicial, seguimiento, técnicas de enseñanza)

.

.

Sistema de evaluación

.

Tabla 76: Ficha de Diseño de actividades

9.5.3 Aspectos a considerar en la evaluación contextual

La evaluación contextual considera la forma en la que un determinadoprograma, independientemente de su calidad técnica y pedagógica, ha sidoutilizado en un contexto educativo concreto, valorando su eficacia y eficiencia.Como en definitiva durante la sesión de trabajo con el programa los estudianteshan realizado unas actividades cognitivas, se trata de valorar en que medida hansido las más idóneas para lograr los objetivos previstos y de que manera se podíahaber organizado mejor la sesión.

La evaluación contextual tiene en cuenta los objetivos educativos que sepretendían y el grado en el que se han logrado, los contenidos tratados, el empleode la infraestructura disponible, las características de los estudiantes y laestrategia didáctica utilizada por el profesor.

Los objetivos educativos y los resultados obtenidos: A partir de laconsideración de los objetivos educativos previstos y los contenidos que se hantratado se evalúan los aprendizajes realizados por los estudiantes para determinarel grado en el que se han conseguido. Este estudio constituye la parte másimportante de la evaluación contextual. Si se han conseguido los objetivosprevistos queda demostrado que la utilización del programa ha sido correcta; encaso contrario, habrá que revisar con más detalle los demás elementos: laadecuación del programa a los estudiantes, el aprovechamiento de lainfraestructura y la metodología que se ha empleado.

Los contenidos tratados: Su grado de profundidad y extensión. ¿Ha sidosuficiente?

Los recursos utilizados: Al evaluar los recursos empleados se pretendedeterminar el aprovechamiento que se ha hecho de los medios materialesdisponibles y considerar la posibilidad de utilizarlos de otra forma más eficiente.


221

Los alumnos: Aquí deben considerarse las características de los estudiantes:edad, conocimientos y habilidades previas, experiencias anteriores, capacidades,estilos cognitivos e intereses, a fin de determinar el grado de adecuación de lasactividades del programa a las circunstancias de los alumnos. También seconsiderarán aspectos como la motivación de los estudiantes durante la sesión ysu opinión sobre las actividades realizadas.

La organización y la metodología didáctica: La metodología didáctica utilizadapor el profesor constituye el principal elemento determinante del éxito de laintervención didáctica, por lo tanto se considerarán: las actividades previasrealizadas sobre la materia del programa, la motivación que ha realizado elprofesor antes de la sesión, la distribución de los estudiantes, la autonomía que seles ha dado para interactuar con el programa, las sugerencias y seguimiento queha realizado durante la sesión, las actividades posteriores, etc.

Instrumentos para la evaluación contextual: La evaluación de la eficacia y laeficiencia de un programa debe realizarse a partir de la observación de suutilización por parte de los estudiantes y de los profesores y mediante la recogidade informaciones de diverso tipo: Informes ( características de los estudiantes);Informes(aprendizajes realizados y objetivos previstos); Observación e informacióndel profesorado (utilización de los recursos disponibles, características delmaterial, metodología utilizada); Valoraciones de los estudiantes sobre supercepción de los aprendizajes realizados, utilidad del programa y nivel desatisfacción; Valoraciones de los profesores sobre los aprendizajes realizados porlos estudiantes, utilidad del programa y nivel de satisfacción.


222



Allen, R. y Garlan, D. (1997). A Formal Basis for Architectural Connection. ACMTrans. on Software Engineering and Methodology.

A. Cechich, M. Piattini and A. Vallecillo (Eds.). Component-Based SoftwareQuality: Methods and Techniques, LNCS 2693, Springer-Verlag, 2003.

Bosch, J. (1996). Language Support for Component Communication in LayOM. EnMühlhäuser, M. (ed.), Special Issues in Object-Oriented Programming. WorkshopReader of ECOOP’96, págs. 131–138. Dpunkt Verlag.


CALERO, C. y Otros,CALERO, CORAL / MORAGA, Ma ANGELES / PIATTINIVELTHUIS, 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, Eclipse – An open development Platform, EclipseFoundation,2007.

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.


ISO/IEC 9126-1:2001. Software engineering product quality part 1: Quality model.International Standard ISO/IEC 9126-1, International Standard Organization, June2001.

ISO, ISO/IEC 25000 Software and system engineering – Software productQuality Requirements and Evaluation (SQuaRE) –Guide to SQuaRE, ISO, 2005.

James A. McCall, Paul K. Richards, and Gene F. Walters. Factors in software


223

quality, volume III: Preliminary handbook on software quality for an acquisitionmanager. Technical Report RADC-TR-77-369, vol. III, Hanscom AFB, MA 01731,1977.

Miller, E., Howden, W. E., Tutorial, Software Testing & Validation Techniques, 2aed., 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 softwareengineering. In Proc. of the 27th Euromicro Conference, Warsaw, Poland,September 2001. IEEE CS Press.


Richards Adrion, W., Branstad M.A., Cherniavsky, J.C., Validation, Verification andTesting of Computer Software, Computing Surveys, Vol. 14, No 2, pp. 159-192,Junio 1982.

Rodríguez Nuria, Martínez William.Planificación y evaluación de ProyectosInformáticos. Editorial Universidad Estatal a Distancia, San José, Costarrica. 2006.



http://www.pressman5.comhttp://www.wiley.com/college/braudehttp://www.itver.edu.mx/comunidad/material/ing-software/unidad5.ppthttp://www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware.htmlhttp://www.monografias.com/trabajos5/inso/inso.shtmlhttp://www.sistemas.unam.mx/software.htmlhttp://www.willydev.net/descargas/articulos/general/CalidadSoftware.pdfhttp://www.lcc.uma.es/~av/Docencia/Doctorado/tema1.pdfhttp://www.iso.orghttp://www.bulltek.com/Spanish_Site/ISO%209000%20INTRODUCCION/TL%209000%20Spanish/ISO9000-3_Spanish/iso9000-3_spanish.htmlhttp://www.gestiopolis.com/canales2/gerencia/1/modcalidad.htm

modulo evaluacion software 2010

Documents