CALIDAD DE UN PROYECTO DE SOFTWARE

CALIDAD DE UN PROYECTO DE SOFTWARE ARÉVALO RINCÓN FREDY MAURICIO 20152878019 AVILA CARDENAS JORGE ALEXANDER 20152878017 CASTRO UMAÑA SEGUNDO OVIDIO 20152878022 RINCON ROJAS DAGOBERTO 20152878020 TRABAJO INVESTIGATIVO 04 DOCENTE: JUAN CARLOS GUEVARA BOLAÑOS UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD TECNOLÓGICA BOGOTÁ D.C SEPTIEMBRE DE 2015

TABLA DE CONTENIDO INTRODUCCION 5 1. CALIDAD DEL SOFTWARE 6 1.1 Definición 7 1.2 Definición Calidad del Software 7 1.3 Importancia de la Calidad 8 1.4 Características 8 1.5 Factores Críticos de Éxito 10 1.5.1 Planificación Estratégica de las TI 11 1.5.2 Compromiso Ejecutivo 11 1.5.3 Gestión de Proyecto 12 1.5.4 Habilidades en TI 12 1.5.5 Habilidades en Procesos de Negocios 12 1.5.6 Entrenamiento en ERP 12 1.5.7 Aprendizaje 12 1.5.8 Predisposición para el Cambio 13 1.6 Modelo Modificado 13 2 MODELOS DE CALIDAD 14 2.1 El modelo en Cascada. 14 2.2 El modelo de Desarrollo Evolutivo (Espiral) 15 2.3 El Modelo de Desarrollo Basado en Componentes 17 2.4 Modelo Scrum 19 3 NORMAS DE CALIDAD 20 3.1 La Norma ISO 9000 20 3.1.1 Descripción 20 3.1.2 Criterios 22 3.2.1 ISO/IEC 15504 23 3.2.2 Descripción 23 3.2.3 Criterios 23 3.3 ISO /IEC9126 24 2

3.3.1 Descripción 24 3.3.2 Criterios 27 3.4. ISO/IEC 12207 28 3.4.1 Descripción 28 3.4.2 Criterios 28 4. CALIDAD DE MODELOS CONCEPTUALES 30 4.1 Métricas para Modelos Conceptuales Tradicionales 31 4.1.1 Métricas De Kesh 33 4.1.2 Métricas De Moody 33 4.1.3 Métricas De Piattini 34 4.2 Métricas para Modelos Orientados a Objetos 35 4.2.1 Métricas de Abreu y Melo, Métricas Mood (Metrics for Object Oriented Design) 36 4.2.2 Métricas de Chindamber y Kemerer 38 4.2.3 Métricas de Lorenz y Kidd 41 5. CALIDAD DE PRODUCTO DE SOFTWARE 44 5.1 Norma ISO/IEC 9126 44 5.2 Norma ISO/IEC 25000 (SQueRE) 46 5.3 Modelo Macall 49 (CALERO, EDICIÓN 2010)5.4 Modelo de BOEHM 51 6. CALIDAD DEL PROCESO DE SOFTWARE 54 6.1 El modelo CMMI (Capability Maturity Model Integration). 55 6.1.1 Alinear las Actividades de Análisis de la Medición 56 6.2 El Modelo ISO/ IEC 15504 56 7. CALIDAD DE INTERFAZ DE SOFTWARE 58 7.1 NORMA ISO 14915-3:2002 58 7.1.1 NORMA IEC TR 61997 CDV 59 7.1.2 Interfaz de Hardware 59 7.2 Modelo de Tareas 59 7.2.1 El Modelo de Dominio 60 8. SOFTWARE PARA ESTIMAR CALIDAD 61 8.1 PMD 61 8.2 Check Style. 61 3

8.3 Google CodePro Analytix. 63 8.4 Kiuwan 64 9. CUADRO COMPARATIVO HERRAMIENTAS DE SOFTWARE 65 CONCLUSIONES 66 BIBLIOGRAFÍA 67 4

INTRODUCCION La elaboración de un software con calidad con lleva la utilización de metodologías o procedimientos estándares para el análisis, diseño, programación y pruebas del software que permitan igualar la filosofía de trabajo, en áreas de lograr una mayor confiabilidad, mantenibilidad y facilidad, a la vez que eleve la productividad, tanto para la labor de desarrollo como para el control de la calidad del mismo. El software es un producto inmaterial que no se fabrica, tampoco se degradan físicamente, sino que se desarrolla. 5

1. CALIDAD DEL SOFTWARE La calidad del software es una preocupación a la que se dedican muchos esfuerzos. Sin embargo, el software casi nunca es perfecto. Todo proyecto tiene como objetivo producir software de la mejor calidad posible, que cumpla, y si puede supere las expectativas de los usuarios. Calidad del software: Obtención de un software con calidad implica la utilización de metodologías o procedimientos estándares para el análisis, diseño, programación y prueba del software que permitan uniformar la filosofía de trabajo, en aras de lograr una mayor confiabilidad, mantenibilidad y facilidad de prueba, a la vez que eleven la productividad, tanto para la labor de desarrollo como para el control de la calidad del software. 6

1.1 Definición Propiedad o conjunto e propiedades inherentes a una persona o cosa que permiten diferenciarla con respecto a las restantes de su especie, como de mejor o peor calidad. Calidad se puede definir como "una característica o atributo de una cosa". De esta forma se podría decir que la calidad de los productos puede medirse como una comparación de sus características y atributos. Una de las formas de realizar una medida de calidad es observar las diferencias ocurridas en la producción dos productos iguales. La producción de artículos de cualquier especie no asegura que dos de ellos sean totalmente iguales. Uno de los principales objetivos de dar calidad a los productos es minimizar las diferencias entre unidades producidas. Estas diferencias tienen diversos orígenes y, por tanto, distintas y amplias formas de corregirlos, dependiendo de la naturaleza del producto. Lo primordial es tener en cuenta el concepto de brindar calidad a lo que se está realizando. 1.2 Definición Calidad del Software Es la concordancia con los requerimientos funcionales y de rendimiento explícitamente establecidos, con los estándares de desarrollo explícitamente documentados y con las características implícitas que se esperan de todo software desarrollado profesionalmente. Conjunto de cualidades que lo caracterizan y que determinan su utilidad y existencia. La calidad es sinónimo de eficiencia, flexibilidad, corrección, confiabilidad, mantenibilidad, portabilidad, usabilidad, seguridad e integridad. La calidad del software es medible y varía de un sistema o programa a otro. Un software hecho para ejecutarse una sola vez no requiere el mismo nivel de calidad mientras que un software para ser explotado durante un largo tiempo necesita ser confiable, mantenible y flexible para disminuir los costos. La calidad del software puede medirse después de elaborado el producto. Pero esto puede resultar muy costoso si se detectan problemas deriva de imperfecciones en el diseño, por lo que es imprescindible tener en cuenta tanto la obtención de la calidad como su control durante todas las etapas del ciclo de vida del software. 7

1.3 Importancia de la Calidad La importancia de la calidad de software radica en varios aspectos como ser: La competencia que existe entre empresas por desarrollar el mejor producto. La complejidad de los problemas que son solucionados por software ha aumentado de forma considerable. El mantenimiento es más difícil de realizar debido a complejidad del software. Los presupuestos que se tienen para realizar los proyectos de software son una limitante para implementar la calidad. Pero al margen de estos elementos se debe tener en cuenta que cada software controla algún proceso dentro de las empresas, y por ende todo tipo de recursos, tanto económicos, físicos y humanos. Es por eso que los controles de calidad que se realizan durante todo el proyecto de desarrollo de software nos permite encontrar los errores en los sistemas antes que estos se vuelvan defectos (producto entregado), que puede desencadenar perdidas de recursos valiosos de las empresas. 1.4 Características Corrección Capacidad de los productos de SW para realizar con exactitud sus tareas, tal y como se definen en las especificaciones. La corrección es la cualidad principal. Si un sistema no hace lo que se supone que debe hacer, poco importan el resto de consideraciones que hagamos sobre él. Los métodos que aseguran la corrección son usualmente condicionales. Es necesaria una solución multinivel, en la que cada nivel confía en la corrección de los inferiores: Hardware ----> Sistema Operativo- ---> Compilador ----> Sistema de Aplicación. Robustez Capacidad de reaccionar apropiadamente ante condiciones excepcionales Caracteriza lo que sucede fuera de la especificación. La robustez es por naturaleza una noción más difusa que la corrección. El papel del requisito de robustez es asegurar que el sistema no causará eventos catastróficos; debería producir mensajes de error apropiados, terminar su ejecución limpiamente en lo posible. 8

Extensibilidad Facilidad de adaptar los productos de sw a los cambios de especificación. El problema de extensibilidad es un problema de escala. Para programas pequeños realizar cambios no es normalmente una tarea difícil; pero a medida que el software crece comienza a ser cada vez más difícil de adaptar. La extensibilidad es necesaria porque en la base de todo software encontramos algún fenómeno humano y de ahí su volatilidad. Simplicidad del diseño, una arquitectura simple siempre será más fácil de adaptar a los cambios que una compleja. Descentralización, cuanto más autónomos sean los módulos, más alta es la probabilidad de que un cambio afecte a un solo módulo, o a un número pequeño de módulos, en lugar de provocar una reacción en cadena de cambios en el sistema completo. Reutilización Capacidad de los elementos de SW de servir para la construcción de muchas aplicaciones diferentes La necesidad de la reutilización surge de la observación de que los sistemas software a menudo siguen patrones similares; debería ser posible explotar esta similitud y evitar reinventar soluciones a problemas que ya han sido encontradas con anterioridad. Compatibilidad Facilidad de combinar unos elementos de sw con otros. La compatibilidad es importante debido a que los sistemas software no se desarrollan en el vacío: necesitan interactuar con otros. Eficiencia Capacidad de un sistema de sw para exigir la menor cantidad posible de recursos. Casi sinónimo de eficiencia es la palabra rendimiento. Portabilidad (Transportabilidad) Facilidad de transferir los productos de sw a diferentes entornos de hw y sw. Facilidad de Uso 9

Facilidad con la cual personas de diferentes formaciones y aptitudes pueden aprender a usar los productos de sw y aplicarlos a la resolución de problemas. Cubre la facilidad de instalación, operación y supervisión. Funcionalidad Conjunto de posibilidades que proporciona un sistema. Oportunidad Capacidad de un sistema de sw de ser lanzado cuando los usuarios lo desean, o antes. 1.5 Factores Críticos de Éxito El ERP son las letras que identifican el concepto Enterprice resourse Planning, que traducido al español quiere decir: Planificación de Recursos Empresariales, y corresponde a un sistema integral de gestión empresarial que está diseñado para modelar y automatizar la mayoría de procesos. Planificación estratégica de las tecnologías de información. Compromiso ejecutivo. Gestión de proyectos. Habilidades en tecnologías de información. Habilidades en procesos de Negocios Entrenamiento en ERP Aprendizaje. Predisposición para el cambio. Las 4 dimensiones del éxito de implementación ERP, además de ser consecuencia de los factores críticos antecedentes (FCE), se relacionan de forma tal que las tres primeras (calidad del sistema, calidad de información y calidad de servicio) impactan en una cuarta dimensión denominada beneficios netos. 10

1.5.1 Planificación Estratégica de las TI Ayuda a asegurar que las metas de desarrollo de las TI estén alineadas con las necesidades de la organización. La claridad de las metas y objetivos del proyecto es un FCE. Antes de partir con el proyecto, los gestores deben preguntarse si existe una visión clara y objetivos cuantificados a alcanzar. EN caso contrario, sin una conexión estratégica el ERP hará lo que los técnicos creen que debe hacer, lo cual no es necesariamente lo mejor para la empresa. 1.5.2 Compromiso Ejecutivo Está referido a la buena disposición de la alta dirección con el principal responsable de TI y a la asignación de los recursos requeridos para el buen fin de la implementación. Es un factor recurrente en la implantación a gran escala de nuevos procesos y de TI. La implementación de un ERP debe ser para el director general equivalente a construir una planta. Es este ejecutivo quien debe considerar la alienación entre la implementación y la visión estratégica, asegurándose que todo el equipo de dirección lo entienda. Si la alta dirección no empuja activamente el proyecto de implementación del ERP hay pocas esperanzas de su éxito. 11

1.5.3 Gestión de Proyecto Involucra el uso de habilidades y conocimiento para planear, coordinar y controlar las complejas y diversas actividades que componen un proyecto. Se trata de habilidades funcionales (entender cómo funciona la organización), técnicas (entender cómo opera la tecnología ERP) e interpersonales. 1.5.4 Habilidades en TI Son necesarias para configurar y mantener sistemas de información que apoyen a la organización, su carencia es un impedimento para integrar TI modernas. La importancia de estas habilidades se manifiesta en relación a las necesidades de integración de sistemas, adaptación del software ERP, pruebas de software, corrección de fallas, migración de datos, estandarización y adecuación entre software y hardware. 1.5.5 Habilidades en Procesos de Negocios Representan las destrezas para entender cómo opera el negocio y para predecir el impacto de una decisión o acción en particular en el resto de la empresa. Los problemas surgen cuando no se piensa en los procesos de negocios como un todo y se separan por secciones dentro de las empresas. Para alcanzar las ventajas que otorga un ERP se debe hacer durante su implementación una análisis de de los actuales procesos de negocios, con el fin de identificar las potenciales posibilidades de re diseño y no solo diseñar un sistema que realice técnicamente mejor un mal proceso. 1.5.6 Entrenamiento en ERP Es el proceso de enseñanza a los diversos grupos de usuarios a utilizar el ERP en sus actividades diarias. La carencia de entrenamiento es fuente de problemas en la implementación. 1.5.7 Aprendizaje El aprendizaje organizacional es una fuente de ventaja competitiva sostenible y el conocimiento adquirido a través de él juega a los efectos de rendimiento de la empresa. Específicamente, las competencias de aprendizaje para identificar las técnicas de mejoramiento continuo, son antecedentes de mejora del rendimiento de la empresa luego de la implementación de un ERP. 12

1.5.8 Predisposición para el Cambio La implementación de un ERP implica cambios a gran escala que pueden ser resistidos por los empleados de la organización. La resistencia al cambio no es solo un gran impedimento para el proyecto de implementación, sino que imposibilita alcanzar los beneficios esperados cuando el sistema está en operación. Debido a lo anterior, desarrollar estrategias para sobrepasar la resistencia a los cambios en la operación es un factor clave para una implementación exitosa. 1.6 Modelo Modificado Calidad del sistema Esta dimensión se centra en las características del sistema de procesamiento de información en sí mismo. Las características que se asocian son productividad, portabilidad, fiabilidad y facilidad de uso. Calidad de Información Se centra en las características de la información que produce el sistema, fundamentalmente en forma de informes o reportes. La evaluación de la calidad se asocia a que sea utilizable, concisa, comprensible, pertinente, esté disponible y en formato correcto. Calidad de Servicio Captura la calidad del servicio que la función SI otorga a la organización. Los factores que miden son tangibilidad, fiabilidad, capacidad de respuesta y seguridad. Beneficios Netos Mide los efectos positivos del sistema de información para un contexto determinado (en este caso la organización). 13

2 MODELOS DE CALIDAD Un modelo para el desarrollo de software es una representación abstracta de un proceso. Cada modelo representa un proceso desde una perspectiva particular y así proporcione información parcial sobre el proceso. Éstos modelos generales no son descripciones definitivas de los procesos del software más bien son abstracciones de los procesos que se pueden utilizar para el desarrollo del software. Puede pensarse en ellos como marcos de trabajo del proceso y que pueden ser adaptados para crear procesos más específicos. 2.1 El modelo en Cascada. Considera las actividades fundamentales del proceso especificación, desarrollo, validación y evolución. Los representa como fases separadas del proceso, tales como la especificación de requerimientos, el diseño del software, la implementación, las pruebas etcétera. 14

Según Royce (1970), el modelo de cascada se derivó de procesos de sistemas más generales. Éste modelo se muestra en la figura 2.22 y sus principales etapas se transforman en actividades fundamentales del desarrollo: Análisis y definición de requerimientos. Los servicios restricciones y metas del sistema se definen a partir de las consultas con los usuarios. Entonces, se definen en detalle y sirven de manera específica al sistema. Diseño del sistema y del software. El proceso de diseño del sistema divide los requerimientos en sistemas ya sea hardware Soto. Establece una arquitectura completa del sistema, el diseño del software identifique describe los elementos abstractos que son fundamentales para el software y sus relaciones. Implementaciones prueba de unidades. Durante esta etapa el diseño del software se lleva a cabo como un conjunto de unidades de programas, la prueba de unidades implica verificar que cada una cumpla con su función específica. Integración y prueba del sistema. Los programas o las unidades individuales de programas se integran y se prueban como un sistema completo para así asegurar que se cumplan los requerimientos del software, después se entrega al cliente. Funcionamiento y mantenimiento. En esta fase el sistema se instala y se pone en funcionamiento práctico el mantenimiento implica corregir errores no descubiertos en las etapas anteriores del ciclo de vida, mejorar la implementación de las unidades del sistema y resaltar los servicios del sistema una vez que se descubren en nuevos requerimientos. 2.2 El modelo de Desarrollo Evolutivo (Espiral) El modelo en espiral que Boehm propuso es un modelo de proceso de software evolutivo que conjuga la naturaleza iterativa de la construcción de prototipos con los aspectos controlados y sistemáticos del modelo en cascada. Cuando se aplica este modelo en espiral, el software se desarrolla en una serie de entregas evolutivas. Cada una de las actividades del marco de trabajo representa un segmento de la ruta en espiral. Este modelo se basa en la idea de desarrollar una implementación inicial, exponiéndola a los comentarios del usuario y refinándola a través de las diferentes versiones que se generan hasta que se desarrolle un sistema adecuado. 15

Las actividades de especificación, desarrollo y validación se entrelazan en vez de separarse, con una rápida retroalimentación entre estas. Existen dos tipos de desarrollo evolutivo: Desarrollo exploratorio, en este caso el objetivo del proceso es trabajar con el cliente para explorar sus requerimientos y entregar un sistema final. El desarrollo empieza con las partes del sistema que se comprenden mejor. El sistema evoluciona agregando nuevos atributos propuestos por el cliente. Prototipos desechables, el objetivo de este proceso de desarrollo evolutivo es comprender los requerimientos del cliente para así desarrollar una definición mejorada de los requerimientos para el sistema. El prototipo se centra en experimentar los requerimientos del cliente que no se comprenden del todo. Haciendo referencia a la producción del software, un enfoque evolutivo suele ser más efectivo que el enfoque en cascada, ya que satisface las necesidades inmediatas de los clientes. La ventaja de un software que se basa en un enfoque evolutivo es que las especificaciones se pueden desarrollar de forma creciente. Tan pronto como los usuarios desarrollen un mejor entendimiento de su problema, esto se puede reflejar en el software. Sin embargo, desde la perspectiva de ingeniería y de gestión, el enfoque evolutivo tiene dos problemas: 16

El proceso no es visible. Esto significa que los administradores tienen que hacer entregas regulares para medir el progreso del producto. Si los sistemas se desarrollan rápidamente, no es rentable producir documentos que reflejen cada versión del sistema. A menudo los sistemas tienen una estructura deficiente. Esto hace referencia que los cambios continuos tienden a corromper la estructura del software. Incorporar cambios en él se convierte cada vez más en una tarea difícil y costosa. Para sistemas pequeños y de tamaño medio (hasta 500,000 líneas de código), el enfoque evolutivo de desarrollo es el mejor. Los problemas del desarrollo evolutivo se hacen particularmente agudos para sistemas grandes y complejos con un período de vida largo, donde diferentes equipos desarrollan distintas partes del sistema. Es difícil establecer una arquitectura del sistema usando este enfoque, ya que hace difícil integrar las contribuciones de los equipos. Para sistemas grandes se recomienda un proceso mixto es decir que incorpore las mejores características del modelo en cascada y del desarrollo evolutivo. Esto implica desarrollar un prototipo desechable, utilizando un enfoque evolutivo para resolver incertidumbres en la especificación del sistema. Puede entonces no implementarse utilizando un enfoque más estructurado. 2.3 El Modelo de Desarrollo Basado en Componentes En la mayoría de los proyectos de desarrollo de software existe la reutilización. Por lo general esto sucede informalmente cuando las personas conocen diseños o códigos similares al requerido. Los buscan, los modifican según lo creen necesario y los incorporan en un nuevo sistema. El enfoque evolutivo, la reutilización es indispensable para el desarrollo más ágil de un sistema. Esta reutilización es independiente del proceso de desarrollo que se utilice. Sin embargo, en los últimos años ha surgido un enfoque de desarrollo de software denominado " ingeniería de software basada en componentes", el cual se basa en la reutilización. Este enfoque se basa en la reutilización y se compone de una gran base de componentes de software que son reutilizables. Aunque la etapa de especificación de requerimientos y la revalidación son comparables con otros procesos, las etapas intermedias en el proceso orientado a la reutilización son diferentes. Estas etapas son: Análisis de componentes. En esta se buscan los componentes para implementar los con base en su especificación. Por lo general, no existe una concordancia exacta y los componentes que se utilizan sólo proporcionan parte de la funcionalidad requerida. 17

Modificación de requerimientos. En esta etapa los requerimientos se analizan utilizando información acerca de los componentes que se han descubierto. Entonces dichos componentes se modifican para reflejar los componentes disponibles, la actividad de análisis de componentes se puede llevar a cabo para buscar soluciones alternativas. Diseño del sistema con reutilización. En esta fase los diseñadores tienen en cuenta los componentes que se reutiliza y que se organizan el marco de trabajo para que los satisfaga. Si dichos componentes no están disponibles se puede diseñar nuevos software. Desarrollo e integración. El software que no se puede adquirir externamente se desarrolla y se integra a los componentes. En este modelo, la integración del sistema es parte del proceso de desarrollo, más que una actividad separada. El modelo de desarrollo de software basado en componentes creado por Boehm (1988), tiene la ventaja de reducir la cantidad de software que se debe desarrollar y por ende reduce los costos y los riesgos. También permite una entrega más rápida del software. Sin embargo, los compromisos a los requerimientos son inevitables y esto da lugar a un sistema que no cumpla con las necesidades reales de los usuarios. Pressman (2006), detecto que: El software de computadoras moderno se caracteriza por el cambio continuo, los tiempos de entrega son muy reducidos y una necesidad intensa de satisfacer al cliente/usuario. En muchos casos, el tiempo de llegada al mercado es el requisito de gestión más importante. Si se pierde una ventana del mercado, el mismo proyecto de software puede perder su significado. 18

2.4 Modelo Scrum Scrum es un marco de trabajo para la gestión y desarrollo de software basada en un proceso iterativo e incremental utilizado comúnmente en entornos basados en el desarrollo ágil de software. Aunque Scrum estaba enfocado a la gestión de procesos de desarrollo de software, puede ser utilizado en equipos de mantenimiento de software, o en una aproximación de gestión de programas: Scrum de Scrums. SCRUM es un modelo de referencia que define un conjunto de prácticas y roles, y que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto. Los roles principales en Scrum son el ScrumMaster, que mantiene los procesos y trabaja de forma similar al director de proyecto, el ProductOwner, que representa a los stakeholders (interesados externos o internos), y el Team que incluye a los desarrolladores. 19

3 NORMAS DE CALIDAD 3.1 La Norma ISO 9000 Elaborada por la Organización internacional para la estandarización (ISO), determina los requisitos para un Sistema de Gestión de Calidad (SGC), que pueden utilizarse para su aplicación interna por las organizaciones, sin importar si el producto o servicio lo brinda una organización pública o empresa privada, cualquiera que sea su tamaño, para su certificación o con fines contractuales. Dependiendo del país, puede denominarse la misma norma "ISO 9001" de diferente forma agregándose la denominación del organismo que la representan dentro del país: UNE-EN-ISO 9001:2008 (España), IRAM-ISO 9001:2008, etc., acompañada del año de la última actualización de la norma. ISO 9001: Contiene los requisitos del modelo de gestión. 3.1.1 Descripción Estructura de ISO 9001:2008 Capítulo 1 al 3: Guías y descripciones generales. Capítulo 4 Sistema de gestión: contiene los requisitos generales y los requisitos para gestionar la documentación. Capítulo 5 Responsabilidades de la Dirección: contiene los requisitos que debe cumplir la dirección de la organización, tales como definir la política, asegurar que las responsabilidades y autoridades están definidas, aprobar objetivos, el compromiso de la dirección con la calidad, etc. Capítulo 6 Gestión de los recursos: la Norma distingue 3 tipos de recursos sobre los cuales se debe actuar: RRHH, infraestructura, y ambiente de trabajo. Aquí se contienen los requisitos exigidos en su gestión. Capítulo 7 Realización del producto/servicio: aquí están contenidos los requisitos puramente de lo que se produce o brinda como servicio (la norma 20

incluye servicio cuando denomina "producto"), desde la atención al cliente, hasta la entrega del producto o el servicio. Capítulo 8 Medición, análisis y mejora: aquí se sitúan los requisitos para los procesos que recopilan información, la analizan, y que actúan en consecuencia. El objetivo es mejorar continuamente la capacidad de la organización para suministrar productos y/o servicios que cumplan con los requisitos. El objetivo declarado en la Norma, es que la organización busque sin descanso la satisfacción del cliente a través del cumplimiento de los requisitos. ISO 9001:2008 tiene muchas semejanzas con el famoso PDCA : acrónimo de Plan, Do, Check, Act (Planificar, Hacer, Verificar, Actuar). La norma está estructurada en cuatro grandes bloques, completamente lógicos, y esto significa que con el modelo de sistema de gestión de calidad basado en ISO se puede desarrollar en cualquier actividad, sin importar si el producto o servicio lo brinda una organización pública o privada, cualquiera que sea su tamaño. La ISO 9000:2000 (Norma obsoleta) se va a presentar con una estructura válida para diseñar e implantar cualquier sistema de gestión, no sólo el de calidad, e incluso, para integrar diferentes versiones. La nueva ISO 9001:2015 Desde junio del 2012 se inició la revisión de la versión actual de la norma; ciertamente la intención es hacer una renovación más grande mayor. Se busca que con el uso y certificación de esta norma las empresas sean más competitivas para el año 2020. Según el INLAC la norma cambiará en un 30%, respecto a la versión 2008; teniendo una estructura de alto nivel, incorporando dos nuevos requisitos quedando su estructura de la siguiente manera: 1 1. Alcance 2. Referencias Normativas 3. Términos y Definiciones 4. Contexto de la Organización 5. Liderazgo 6. Planificación 7. Soporte 8. Operación 9. Evaluación del Desempeño 10. Mejora 21

3.1.2 Criterios 1. Control de calidad: Determina los puntos de medida (Hitos de control), para verificar las existencia del producto o entregables para el cliente Quién hace el control de calidad? Los analistas y desarrolladores del software El control de calidad es un producto técnico Contrato de desarrollo: Documento legal que hace parte integral del análisis de requisitos Análisis de requisitos Documento Diseño Generación de pruebas 2. Gestión de calidad Proceso mediante el cual se garantiza que las entregables lleguen a un punto y fecha determinados previamente. No es un proceso técnico, es administrativo Quién hace la gestión de calidad? La desarrolla el líder del proyecto (Management) Ejemplo:(UP) Satisfacción del cliente 3. Calidad total (mejora continua) Es un proceso que determina las condiciones para comprobar la satisfacción total del cliente en términos de: Requisitos: contrato de desarrollo(requisitos de software) Proceso: análisis y diseño Producto: terminación proceso: Documentos, código, pruebas Quién hace la calidad total? Los desarrolladores y los clientes Es un proceso de alta gerencia 1 1 (https://es.wikipedia.org/wiki/iso_9001, s.f.) 22

3.2.1 ISO/IEC 15504 El ISO/IEC 15504, también conocido como Software Process Improvement Capability Determination, abreviado SPICE, en español, «Determinación de la Capacidad de Mejora del Proceso de Software» es un modelo para la mejora, evaluación de los procesos de desarrollo, mantenimiento de sistemas de información y productos de software. 3.2.2 Descripción Tiene una arquitectura basada en dos dimensiones: de proceso y de capacidad de proceso. Define que todo modelo de evaluación de procesos debe definir: - la dimensión de procesos: el modelo de procesos de referencia (dimensión de las abscisas) - la dimensión de la capacidad: niveles de capacidad y atributos de los procesos. Los niveles de capacidad para todo modelo de evaluación de procesos pueden tener desde el 0 y al menos hasta el nivel 1 de los siguientes niveles de capacidad estándar: Nivel 0: Incompleto Nivel 1: Realizado Nivel 2: Gestionado Nivel 3: Establecido Nivel 4: Predecible Nivel 5: En optimización 3.2.3 Criterios Establece un marco y los requisitos para cualquier fase de evaluación de procesos y proporciona requisitos para los modelos de evaluación de estos. Proporciona también requisitos para cualquier modelo de evaluación de organizaciones. Proporciona guías para la definición de las competencias de un evaluador de procesos. Actualmente tiene 10 partes: de la 1 a la 7 completas y de la 8 a la 10 en fase de desarrollo. 23

Comprende: evaluación de procesos, mejora de procesos, determinación de capacidad. Proporciona, en su parte 5, un Modelo de evaluación de procesos para las fases de ciclo de vida del software definidos en el estándar ISO/TEC 12207 que define los procesos del ciclo de vida del desarrollo, mantenimiento y operación de los sistemas de software. Proporciona, en su parte 6, un Modelo de evaluación de procesos para las etapas de ciclo de vida del sistema, definidos en el estándar ISO/TEC 15288 que define los procesos del ciclo de vida del desarrollo, mantenimiento y operación de sistemas. Proporcionará, en su parte 8, un Modelo de evaluación de procesos para los procesos de servicios TIC que serán definidos en el estándar ISO/TEC 2000-4 que definirá los procesos contenidos en la norma ISO/IEC 20000-1. Equivalencia y compatibilidad con CMMI. ISO forma parte del panel elaborador del modelo CMMI Y SEI mantiene la compatibilidad y equivalencia de ésta última con 15504. Sin embargo CMMI-DEV aún no es un modelo conforme con esta norma (según lo requiere la norma ISO 15504 para todo modelo de evaluación de procesos). 3.3 ISO /IEC9126 ISO 9126 es un estándar internacional para la evaluación de la calidad del software. Está reemplazado por el proyecto SQuaRE, ISO 25000:2005, el cual sigue los mismos conceptos. 3.3.1 Descripción El estándar está dividido en cuatro partes las cuales dirigen, realidad, métricas externas, métricas internas y calidad en las métricas de uso y expendido. El modelo de calidad establecido en la primera parte del estándar, ISO 9126-1, clasifica la calidad del software en un conjunto estructurado de características y subcaracterísticas. Funcionalidad: Un conjunto de atributos que se relacionan con la existencia de un conjunto de funciones y sus propiedades específicas. Las funciones son aquellas que satisfacen las necesidades implícitas o explícitas. 24

Adecuación: Atributos del software relacionados con la presencia y aptitud de un conjunto de funciones para tareas especificadas. Exactitud: Atributos del software relacionados con la disposición de resultados o efectos correctos o acordados. Interoperabilidad: Atributos del software que se relacionan con su habilidad para la interacción con sistemas especificados. Seguridad: Atributos del software relacionados con su habilidad para prevenir acceso no autorizado ya sea accidental o deliberado, a programas y datos. Cumplimiento Funcional Fiabilidad: Un conjunto de atributos relacionados con la capacidad del software de mantener su nivel de prestación bajo condiciones establecidas durante un período establecido. Madurez: Atributos del software que se relacionan con la frecuencia de falla por fallas en el software. Recuperabilidad: Atributos del software que se relacionan con la capacidad para restablecer su nivel de desempeño y recuperar los datos directamente afectos en caso de falla y en el tiempo y esfuerzo relacionado para ello. Tolerancia a Fallos: Atributos del software que se relacionan con su habilidad para mantener un nivel especificado de desempeño en casos de fallas de software o de una infracción a su interfaz especificada. Cumplimiento de Fiabilidad: La capacidad del producto software para adherirse a normas, convenciones o legislación relacionadas con la fiabilidad. Usabilidad: Un conjunto de atributos relacionados con el esfuerzo necesario para su uso, y en la valoración individual de tal uso, por un establecido o implicado conjunto de usuarios. Aprendizaje: Atributos del software que se relacionan al esfuerzo de los usuarios para reconocer el concepto lógico y sus aplicaciones. Comprensión: Atributos del software que se relacionan al esfuerzo de los usuarios para reconocer el concepto lógico y sus aplicaciones. Operatividad: Atributos del software que se relacionan con el esfuerzo de los usuario para la operación y control del software. Atractividad Eficiencia: Conjunto de atributos relacionados con la relación entre el nivel de desempeño del software y la cantidad de recursos necesitados bajo condiciones establecidas. Comportamiento en el tiempo: Atributos del software que se relacionan con los tiempos de respuesta y procesamiento y en las tasas de rendimientos en desempeñar su función. Comportamiento de recursos: Usar las cantidades y tipos de recursos adecuados cuando el software lleva a cabo su función bajo condiciones determinadas. Mantenibilidad: Conjunto de atributos relacionados con la facilidad de extender, modificar o corregir errores en un sistema software. 25

Estabilidad - Atributos del software relacionados con el riesgo de efectos inesperados por modificaciones. Facilidad de análisis - Atributos del software relacionados con el esfuerzo necesario para el diagnóstico de deficiencias o causas de fallos, o identificaciones de partes a modificar. Facilidad de cambio - Atributos del software relacionados con el esfuerzo necesario para la modificación, corrección de falla, o cambio de ambiente. Facilidad de pruebas - Atributos del software relacionados con el esfuerzo necesario para validar el software modificado. Portabilidad: Conjunto de atributos relacionados con la capacidad de un sistema software para ser transferido desde una plataforma a otra. Capacidad de instalación - Atributos del software relacionados con el esfuerzo necesario para instalar el software en un ambiente especificado. Capacidad de reemplazamiento - Atributos del software relacionados con la oportunidad y esfuerzo de usar el software en lugar de otro software especificado en el ambiente de dicho software especificado. Adaptabilidad - Atributos del software relacionados con la oportunidad para su adaptación a diferentes ambientes especificados sin aplicar otras acciones o medios que los proporcionados para este propósito por el software considerado. Co-Existencia - Coexistir con otro software independiente, en un entorno común, compartiendo recursos comunes. La subcaracterística Conformidad no está listada arriba ya que se aplica a todas las características. Ejemplos son conformidad a la legislación referente a usabilidad y fiabilidad. Cada subcaracterística (como adaptabilidad) está dividida en atributos. Un atributo es una entidad la cual puede ser verificada o medida en el producto software. Los atributos no están definidos en el estándar, ya que varían entre diferentes productos software. Un producto software está definido en un sentido amplio como: los ejecutables, código fuente, descripciones de arquitectura, y así. Como resultado, la noción de usuario se amplía tanto a operadores como a programadores, los cuales son usuarios de componentes como son bibliotecas software. El estándar provee un entorno para que las organizaciones definan un modelo de calidad para el producto software. Haciendo esto así, sin embargo, se lleva a cada organización la tarea de especificar precisamente su propio modelo. Esto podría ser hecho, por ejemplo, especificando los objetivos para las métricas de calidad las cuales evalúan el grado de presencia de los atributos de calidad. Métricas internas son aquellas que no dependen de la ejecución del software (medidas estáticas). Métricas externas son aquellas aplicables al software en ejecución. 26

La calidad en las métricas de uso están sólo disponibles cuando el producto final es usado en condiciones reales. Idealmente, la calidad interna no necesariamente implica calidad externa y esta a su vez la calidad en el uso. Este estándar proviene desde el modelo establecido en 1977 por McCall y sus colegas, los cuales propusieron un modelo para especificar la calidad del software. El modelo de calidad McCall está organizado sobre tres tipos de Características de Calidad: Factores (especificar): Describen la visión externa del software, como es visto por los usuarios. Criterios (construir): Describen la visión interna del software, como es visto por el desarrollador. Métricas (controlar): Se definen y se usan para proveer una escala y método para la medida. ISO 9126 distingue entre fallo y no conformidad. Un fallo es el incumplimiento de los requisitos previos, mientras que la no conformidad es el incumplimiento de los requisitos especificados. Una distinción similar es la que se establece entre validación y verificación. 3.3.2 Criterios Características operacionales Corrección Es el grado en que un programa satisface sus especificaciones y consigue los objetivos pedidos por el cliente. Este factor tiene una pregunta asociada: Hace lo que quiero? Confiabilidad Es el grado en que se puede esperar que un programa lleve a cabo sus funciones esperadas con la precisión requerida. La pregunta asociada a este factor sería: Lo hace de forma fiable todo el tiempo? Eficiencia La cantidad de recursos de computadoras y de código requeridos por un programa para llevar a cabo sus funciones. La pregunta asociada a este factor sería: Se ejecutará en mi hardware lo mejor que pueda? Capacidad de Soportar cambios Facilidad de Mantenimiento Es el esfuerzo requerido para localizar y arreglar un error en un programa. La pregunta asociada a este factor sería: Puedo corregirlo? 27

Flexibilidad Es el esfuerzo requerido para modificar un programa operativo.la pregunta asociada a este factor sería: Puedo cambiarlo? Facilidad de Prueba Es el esfuerzo requerido para probar un programa de forma que se asegure que realiza su función requerida. La pregunta asociada a este factor sería: Puedo probarlo? Adaptabilidad de nuevos entornos Portabilidad Es el esfuerzo requerido para transferir el programa desde un hardware y/o un entorno de sistema de software a otro. Este factor tiene una pregunta asociada: Podré usarlo en otra máquina? Reusabilidad Es el grado en que un programa (o partes de este) se pueden reusar en otras aplicaciones. Este factor tiene una pregunta asociada: Podré reusar alguna parte del software? Facilidad de Interoperación Es el esfuerzo requerido para acoplar un sistema a otro. Este factor tiene una pregunta asociada: Podré hacerlo interactuar con otro sistema? 3.4. ISO/IEC 12207 Es el estándar para los procesos de ciclo de vida del software. 3.4.1 Descripción Su estructura del estándar ha sido concebida de manera que pueda ser adaptada a las necesidades de cualquiera que lo use. Para conseguirlo, el estándar se basa en dos principios fundamentales: Modularidad y responsabilidad. Con la modularidad se pretende conseguir procesos con un mínimo acoplamiento y una máxima cohesión. En cuanto a la responsabilidad, se busca establecer un responsable para cada proceso, facilitando la aplicación del estándar en proyectos en los que pueden existir distintas personas u organizaciones involucradas, no importando el uso que se le dé a este. 3.4.2 Criterios Los procesos se clasifican en tres tipos: Procesos principales, procesos de soporte y procesos de la organización. Los procesos de soporte y de organización deben 28

existir independientemente de la organización y del proyecto ejecutado. Los procesos principales se instancian de acuerdo con la situación particular 2. Procesos principales. Adquisición. Suministro. Desarrollo. Operación. Mantenimiento. Procesos de soporte. Documentación Gestión de la configuración. Aseguramiento de calidad. Verificación. Validación. Revisión conjunta. Auditoría. Resolución de problemas. Procesos de la organización. Gestión. Infraestructura. Mejora. Recursos Humanos. Modelos de calidad (Documentar 4 modelos) Nombre Descripción Criterios 2 (https://es.wikipedia.org/wiki/iso/iec_12207, s.f.) 29

4. CALIDAD DE MODELOS CONCEPTUALES Algunos autores definen modelo conceptual como sobre un dominio que un sistema de información necesita conocer para llevar a cabo las funciones requeridas. La influencia del modelo conceptual en el producto resultante, aunque sólo sea una fase inicial, es mucho mayor que la de otras fases del ciclo de vida, ya que la detección y corrección de errores en las primeras etapas de cualquier proceso, y en particular en el desarrollo del software, permite una mejora de la calidad y unos menores costes de no conformidad, la atención al modelado es clave para el éxito del proyecto. La rápida evolución de la tecnología informática, con sus impresionantes mejoras en prestaciones y rendimiento, no ha sido acompañada por una análoga evolución en el desarrollo de la industria del software; La ya conocida como crisis del software, por ello, los equipos de I+D de las empresas y numerosas universidades han dedicado sus esfuerzos a la investigación y desarrollo de nuevas formas de creación de software, dando lugar a modelos y metodologías. Estos modelos y metodologías, a pesar de mejorar la situación, no llegan a obtener resultados espectaculares, por lo que se abren camino nuevas ideas y modelos. De entre ellos empiezan a destacar los llamados modelos conceptuales, que permiten el enlace entre los requisitos de los usuarios y la solución software correspondiente y permiten modelar, además de los aspectos estáticos de los Sistemas Informáticos, algunos aspectos de su comportamiento. Los modelos conceptuales pueden clasificarse en dos grandes grupos: 30

4.1 Métricas para Modelos Conceptuales Tradicionales Los modelos conceptuales tradicionales, como el de Entidad-Relación desarrollado en 1976 por Chen, y modificado posteriormente por otros autores, todavía pueden describir fácilmente los requisitos de datos de un sistema de información con independencia de criterio de la gestión y organización de los datos. Por ello, otros autores, como Moody, Kesh, Piattini, etc, estudian la calidad definiendo marcos de referencia para estructurar y organizar los conceptos claves y las características en el modelado conceptual de los datos; en general estos marcos al definir solo propiedades deseables y carecer de medidas cuantitativas, no permiten medir eficazmente la calidad del producto obtenido; para evitar los sesgos en el proceso de evaluación de la calidad, Moody propuso en 1998 la necesidad de contar con medidas objetivas y cuantitativas para evaluar la calidad de los modelos conceptuales. El conjunto de métricas ha de proporcionar información sobre los aspectos de calidad que se propone medir y a quiénes van dirigidos, programadores, gestores y usuarios tiene diferentes puntos de vista de lo que significa calidad, por lo que el conjunto de métricas debería basarse en un modelo de calidad bien definido, como son: GQM (Goal Question Metrics) QMS (Quality Management System). Tanto GQM como QMS ayudan a construir un modelo de requerimientos de calidad a partir de factores como la facilidad de uso, la facilidad de mantenimiento o la capacidad de reutilización, estos modelos flexibles ayudan a clarificar qué aspectos de la calidad se consideran y porqué, algunas métricas para modelos tradicionales (con modificaciones en algunos casos) pueden ser utilizadas en sistemas OO, especialmente a nivel de métodos. Sin embargo para cuantificar aspectos específicos (herencia, polimorfismo) es necesario crear métricas dedicadas; las Métricas y sus mediciones, como correspondencias entre entidades del mundo real y números, han de validarse tanto teórica como experimentalmente Validación Teórica En una métrica debe haber claridad sobre los atributos del software que se va a medir y sobre el modo en que se va a realizar la medición; sólo de esta forma tendrá sentido y estará relacionada con lo que se quiere medir. Kitchenham [1995] describe una serie de propiedades que las métricas deben cumplir para ser válidas. 31

Métricas directas: son aquellas que no precisan ningún otro atributo o entidad (longitud, número de defectos, duración de un proceso) estas propiedades son: Para poder medir un atributo, debe permitir que distintas entidades sean distinguibles entre sí. La métrica debe cumplir la condición de representación. Cada unidad que contribuye en una métrica valida debe ser equivalente. Diferentes entidades pueden tener el mismo valor (dentro de loslímites en los errores de medición). Métricas indirectas: son aquellas que combinan varias métricas directas (por ejemplo, la densidad de defectos en un modulo es igual al número de defectos del módulo entre la longitud del modulo), las propiedades son: La métrica se debe basar en un modelo explícitamente definido de relaciones entre atributos (generalmente, relacionando atributos externos e internos). El modelo de medición tiene que ser dimensionalmente consistente. La métrica no debe mostrar ninguna discontinuidad inesperada. Las unidades y escalas de la métrica se han de usar correctamente La condición de representación, según está descrita por Fenton y Pfleeger [1997], asegura que la relación de medición M debe hacer corresponder entidades a números, así como relaciones empíricas a relaciones numéricas, de tal forma que las relaciones empíricas son preservadas por las relaciones numéricas, por ejemplo, A es mayor que B si y sólo si M(A) > M(B). Validación Experimental Los métodos empíricos corroboran la validez de las métricas, con métodos estadísticos y experimentales se evalúan la utilidad y la relevancia de la métricas, aunque en la bibliografía existen estudios en los que se validan métricas a través de técnicas estadísticas y experimentales, aún es necesario trabajar mucho más para obtener mejores guías e interpretaciones. La medición de las características de calidad del modelo conceptual es un área aún no consolidada y frecuentemente ignorada, hasta ahora la mayoría de los esfuerzos en la medición del software se han centrado en la medición de programas o del diseño avanzado. Esto corrobora el hecho de que comparado con el entendimiento generalizado del concepto de calidad en ingeniería del software, el concepto de calidad en el modelado conceptual no está claramente definido. 32

4.1.1 Métricas De Kesh Kesh publicó en 1995 el método que había desarrollado para el aseguramiento de la calidad del modelo Entidad-Relación; este método se basa en que la calidad en estos modelos de datos se determina por dos tipos de componentes: los ontológicos y los de comportamiento. El método se compone de tres pasos: Cálculo del valor de cada uno de los componentes ontológicos Cálculo de los valores de los componentes de comportamiento. Cálculo de la calidad del modelo. 4.1.2 Métricas De Moody Moody presentó un conjunto de métricas, algunas objetivas y otras subjetivas para evaluar algunos factores de calidad de los modelos de datos, para los diferentes factores de calidad estas métricas son: Moody propuso que investigadores y profesionales trabajen conjuntamente para demostrar la validez de estas métricas; este método no ha sido validado ni teórica ni prácticamente, no aporta herramientas, tiene medidas objetivas y estimaciones subjetivas, y solo tiene en cuenta algunos factores de calidad para modelos ER. 33

4.1.3 Métricas De Piattini Un grupo de investigadores coordinados por Piattini trabajó en la medida de la facilidad de mantenimiento de los modelos ER, evidentemente esta medida sólo puede hacerse cuando el producto está terminado o próximo a finalizar, ya que la facilidad de mantenimiento es un atributo externo de la calidad. Para evitar este inconveniente se predice la facilidad de mantenimiento mediante la medida de un atributo interno (la complejidad estructural del modelo ER), que influye fuertemente en el mantenimiento de la base de datos que se implementa, a su vez la complejidad estructural depende de sus elementos como entidades, relaciones, atributos. El conjunto de medidas propuestas es el siguiente: NE. Número total de entidades del modelo ER NA. Número total de atributos (simples, compuestos y multivaluados) en el modelo, tanto en las relaciones como en las entidades. NDA. Número total de atributos derivados en el modelo. NMVA. Número total de atributos multivaluados en el modelo. NCA. Número total de atributos compuestos en el modelo. NNR. Número total de relaciones comunes en el modelo. NM:NR. Número total de relaciones N:M en el modelo. NI:NR. Número total de relaciones 1:N y 1:1 en el modelo. NbinaryR. Número total de relaciones binarias en el modelo. 34

NN-AryR. Número total de relaciones n-arias. NIS_AR. Número total de relaciones NRefR. Número total de relaciones reflexivas. NRR. Número de relaciones redundantes. Estas métricas del modelo ER son objetivas y han sido validadas teóricamente en Genero et al., siguiendo el marco formal basado en la teoría de la medida, propuesto por Zuse, con el objetivo de evaluar qué tipo de escala caracteriza a cada métrica, además de empíricamente mediante un caso de estudio y dos experimentos controlados. Las métricas NNR, N1:NR, NBinaryR fueron caracterizadas por encima de la escala ordinal y NE, NA, NCA, NDA, NMVA, NN-AryR, NIS_AR, NRefR, NRR en la escala de ratio. Características de las principales propuestas sobre métricas para modelos conceptuales ER (Tradicionales) 4.2 Métricas para Modelos Orientados a Objetos Los modelos conceptuales orientados a objetos representan, además de los datos, el comportamiento y funcionalidad del sistema de información, mediante diagramas de clases, de actividad, de transición de estados, etc. Como siempre que se habla de calidad, hay que distinguir entre la calidad del producto y la calidad del proceso realizado para conseguirlo, en este caso, la calidad del producto se relaciona con las características del modelo conceptual y la calidad del proceso con la manera en que se desarrollan los modelos conceptuales. Algunos autores, identifican la calidad de los modelos con una lista de las propiedades ideales que deben tener los modelos de datos, estas listas pueden servir para mejorar la calidad de los modelos, pero, en general, no son estructuradas, las definiciones no son precisas, a veces solapándose entre sí, con objetivos no realistas, presuponen la existencia de diseño/implementación, he aquí 35

una de estas tablas donde se muestran algunas propiedades asociadas a la calidad según distintos autores: Autores Batini (1992) Reingruber M. y Gregori W. (1994) Boman (1997) Propiedad Compleción, corrección, minimalidad, expresividad, auto explicación, extensibilidad y normalidad. Corrección conceptual, compleción conceptual, corrección sintáctica, compleción sintáctica, conocimiento de la empresa. Facilidad de comprensión, corrección semántica, estabilidad, compleción conceptual. El hecho de construir software mediante el uso de esta metodología no garantiza de por sí la calidad; las métricas tradicionales no se adecuan bien a este tipo de software, por lo que se han definido métricas específicas. 4.2.1 Métricas de Abreu y Melo, Métricas Mood (Metrics for Object Oriented Design) Abreu y Melo presentaron las métricas MOOD (Metrics for Object Oriented Design) para medir algunos de los principales mecanismos de los modelos orientados a objetos (encapsulamiento, polimorfismo, herencia y paso de mensajes, etc.) para poder evaluar la productividad del desarrollo y la calidad del producto. Están encuadradas dentro de lo que se conoce como métricas a nivel de sistema, las métricas MOOD se definieron para aplicarlas a nivel de diagramas de clases y se pueden utilizar en la fase de diseño. Definiciones de las diferentes métricas son: MHF: El Method Hiding Factor (factor de ocultamiento de los métodos) se define como el cociente entre la suma de las invisibilidades de todos los métodos definidos en todas las clases y el número total de métodos definidos en el sistema. La invisibilidad de un método es el porcentaje total de clases desde las cuales el método es invisible. MHF: es el ratio entre el número de métodos privados y el número total de métodos, y sirve para medir la encapsulación; Abreu y Melo demostraron empíricamente que cuando se incrementa MHF, la densidad de defectos y el esfuerzo necesario para corregirlos deberían disminuir, para el cálculo de esta métrica no se consideran los métodos heredados. 36

AHF: El Attribute Hiding Factor (factor de ocultamiento de los atributos) se define como el cociente entre el número de invisibilidades de todos los atributos definidos en todas las clases y el número total de atributos definidos en el sistema. Se propone también como medida de encapsulación; idealmente el valor de esta métrica debería ser siempre del 100%, siendo necesario para ello ocultar todos los atributos, las pautas de diseño OO sugieren que no hay que emplear atributos públicos, ya que se considera que esto viola los principios de encapsulación al exponer la implementación de las clases. Para mejorar el rendimiento, a veces se evita el uso de métodos que acceden o modifican atributos accediendo a ellos directamente MIF: El Method Inheritance Factor (factor de herencia de los métodos) es el cociente entre el número de métodos heredados en todas las clases del sistema y el número total de métodos (heredados y locales) en todas las clases, se utiliza como una medida de la herencia, y por tanto, sirve como medida de la reusabilidad; también se propone como ayuda para evaluar la cantidad de recursos necesarios a la hora de probar; el empleo de la herencia se ve como un compromiso entre la facilidad de reutilización que proporciona, y la facilidad de comprensión y mantenimiento del sistema. AIF: El Attribute Inheritance Factor (factor de herencia de los atributos) está definido como el cociente entre el número de atributos heredados en todas las clases del sistema y el número total de atributos existentes (heredados y definidos localmente) en todas las clases; lo mismo que la anterior métrica expresa la capacidad de reutilización del sistema y por el contrario tenemos que demasiada reutilización de código a través de herencia hace que el sistema sea más difícil de entender y mantener. PF: El Polymorphism Factor (factor de polimorfismo) se define como el ratio entre el número actual de situaciones diferentes posibles de polimorfismo y el número máximo de posibles situaciones distintas de polimorfismos para cada clase; el factor PF es además, una medida indirecta de la asociación dinámica del sistema, el polimorfismo se debe a la herencia. Abreu indica que, en algunos casos, sobrecargando métodos se reduce la complejidad y por tanto se incrementa la facilidad de mantenimiento y la facilidad de comprensión del sistema. Diversos autores han demostrado que esta métrica no cumple todas las propiedades definidas para ser válida, ya que en un sistema sin herencia el valor de PF es indefinido, lo que exhibe una discontinuidad CF: Coupling Factor (factor de acoplamiento) se define como la proporción entre el máximo número posible de acoplamientos en el sistema y el número real de acoplamientos no imputables a la herencia, en otras palabras, indica la 37

comunicación entre clases; el acoplamiento se ve como una medida del incremento de la complejidad, reduciendo la encapsulación y el posible re uso; limita la facilidad de comprensión y de mantenimiento del sistema. CF puede ser una medida indirecta de los atributos con los cuales están relacionados la complejidad, falta de encapsulación, carencia de reutilización, facilidad de comprensión y poca facilidad de mantenimiento. Los autores han encontrado una correlación positiva: al incrementar el acoplamiento entre clases, se incrementa la densidad de defectos y la dificultad en el mantenimiento. En resumen, las métricas de Abreu y Melo se enfocan hacia las características de los diagramas de clase, son medidas objetivas y han sido validadas de forma teórica y parcialmente de forma empírica. 4.2.2 Métricas de Chindamber y Kemerer En 1994, Chindamber y Kemerer propusieron seis métricas para la complejidad del diseño OO, aunque no todas pueden aplicarse a nivel conceptual, y además han sido muy criticadas por su ambigüedad e imprecisión. Algunas de estas métricas están encuadradas dentro de los que se conoce como métricas a nivel de herencia, otras métricas a nivel de acoplamiento, otras a nivel de clases, el acoplamiento es el empleo de métodos o atributos definidos en una clase que son usados por otra; las clases tienen que interactuar unas con otras para formar sistemas, y esta interacción puede indicar su complejidad. Las métricas de herencia: DIT: La métrica Depth of Inheritance Tree (profundidad en árbol de herencia) se define como la profundidad del árbol de una clase (en los casos de herencia múltiple es la máxima longitud desde el nodo hasta la raíz del árbol), se basa en que cuanto más profunda está la clase en la jerarquía, mayor número de operaciones puede heredar. Se propuso como una medida de la complejidad de una clase, complejidad de diseño y reusabilidad potencial, el uso de la herencia se contempla como un compromiso, ya que: Altos niveles de herencia indican objetos complejos, los cuales pueden ser difíciles de probar y reutilizar. Bajos niveles en la herencia pueden señalar que el código está escrito en un estilo funcional, sin aprovechar el mecanismo de herencia proporcionado por la orientación a objetos. En general la herencia se utiliza poco, se ha encontrado una correlación positiva entre DIT y el número de problemas emitidos por el usuario, poniendo en duda el uso efectivo de la herencia, otros autores sugieren un umbral de 6 niveles como 38

indicador de un abuso en la herencia en distintos lenguajes de programación (C++, Smalltalk) sistemas construidos a partir de frameworks suelen presentar unos niveles de herencia altos, ya que las clases se construyen a partir de una jerarquía existente; en lenguajes como Java o Smalltalk, las clases siempre heredan de la clase Object, lo que añade uno al valor de DIT. NOC: La métrica Number Of Children (número de hijos) se define como el número de subclases inmediatas subordinadas a una clase, es decir, la cantidad de subclases que pertenecen a una clase, esta medida indica cuántas subclases van a heredar las operaciones de la clase padre, también es un indicador del nivel de re uso, la posibilidad de haber creado abstracciones erróneas, y es un indicador del nivel de pruebas requerido, aunque un mayor número de hijos representa una mayor reutilización de código, tiene sus inconvenientes: Mayor probabilidad de emplear incorrectamente la herencia creando abstracciones erróneas. Mayor dificultad para modificar una clase, pues esto afecta a todos los hijos que tienen dependencia con la clase base. Se requiere mayor número de recursos para probar. Es un potencial indicador de la influencia que una clase puede tener sobre el diseño del sistema. Si el diseño depende mucho de la reutilización a través de la herencia, quizás sea mejor dividir la funcionalidad en varias clases. Estas dos métricas (DIT y NOC) presentan medidas objetivas para la complejidad de las clases y han sido validadas teóricamente por los autores al corroborar que satisfacen los axiomas de Weyuker. La validación empírica fue realizada por Basil, que encontraron que la posibilidad de encontrar un fallo es directamente proporcional a DIT e inversamente al NOC. Las métricas que se consideran a nivel de acoplamiento son: CBO: Coupling Between Objects (acoplamiento entre objetos) de una clase se define como el número de clases a las cuales una clase está ligada, se da dependencia entre dos clases cuando una de ellas usa métodos o variables de la otra clase, las clases relacionadas por herencia no se tienen en cuenta, los autores proponen que esta métrica sea un indicador del esfuerzo necesario para el mantenimiento y las pruebas. También indican que cuanto más acoplamiento se da en una clase, más difícil será reutilizarla. Además las clases con excesivo acoplamiento dificultan la comprensión y hacen más difícil el mantenimiento, por lo que será necesario un mayor esfuerzo y unas pruebas rigurosas. 39

Las clases tendrían que ser lo más independientes posible y, aunque siempre se precisa una dependencia entre clases, cuando ésta es grande, la reutilización puede ser más cara que la reescritura. Al reducir el acoplamiento se reduce la complejidad, se mejora la modularidad y se promueve la encapsulación, las métricas que se consideran a nivel de clases identifican características dentro de las clases destacando diferentes aspectos de sus abstracciones y ayudando a descubrir clases que podrían necesitar ser rediseñadas. Algunas de estas son: RFC: Response For a Class (respuesta de una clase) es el cardinal del conjunto de todos los métodos que se pueden invocar como respuesta a un mensaje a un objeto de la clase o como respuesta a algún método en la clase, esto incluye a todos los métodos accesibles dentro de la jerarquía de la clase, en otras palabras, RFC cuenta las ocurrencias de llamadas a otras clases desde una clase particular. RFC = RS, donde RS es el conjunto respuesta para la clase, que se puede expresar como: RS = {M} Ui {Ri}, donde {Ri} es el conjunto de métodos llamados por el método i, y {M} es conjunto de todos los métodos en la clase. RFC: es una medida de la complejidad de una clase a través del número de métodos y de su comunicación con otras, pues incluye los métodos llamados desde fuera de la clase, es un indicador de los recursos necesarios para las pruebas y la depuración. Cuanto mayor es RFC, más complejidad tiene el sistema, ya que es posible invocar más métodos como respuesta a un mensaje; se ha señalado que la definición de esta métrica es ambigua y fuerza al usuario a interpretarla. WMC: Weighted Methods per Class-WMC (métodos ponderados por clase), mide la complejidad de una clase. Si todos los métodos se estiman igualmente complejos, entonces WMC es, simplemente, el número de métodos definidos en una clase. WMC = Σ ci Donde una clase Ci tiene los métodos M1,..., Mn con su complejidad respectiva c1,...,cn Los autores sugieren que WMC es una medida de la complejidad de una clase, clases con un gran número de métodos requieren más tiempo y esfuerzo para desarrollarlas y mantenerlas, ya que influirán en las subclases heredando todos sus métodos, además, estas clases tienden a ser específicas de la aplicación, con lo que se limita su posibilidad de reutilización. 40

Lorenz y Kidd plantean un umbral de 40 o 20, dependiendo de si las clases son o no de interfaz de usuario; en WMC se pueden apreciar los siguientes problemas: WMC mide presuntamente la complejidad, pero no ofrece ninguna definición asociada a la complejidad. WMC no se puede contemplar como un indicador del esfuerzo necesario para desarrollar una clase, ya que es fácil imaginar clases con pocos métodos complicados y clases con un gran número de métodos, pero muy simples. Así pues parece que solo se debería considerar esta métrica simplemente como una medida del tamaño de una clase. LCOM: Lack of Cohesion in Methods (falta de cohesión en los métodos) establece en qué medida los métodos hacen referencia a atributos; es una medida de la cohesión de una clase midiendo el número de atributos comunes usados por diferentes métodos, indicando la calidad de la abstracción hecha en la clase. Un valor alto de LCOM implica falta de cohesión, es decir, escasa similitud de los métodos. Esto quizás signifique que la clase está compuesta de elementos no relacionados, incrementándose la complejidad y la probabilidad de errores durante el desarrollo, es deseable una alta cohesión de los métodos dentro de una clase, ya que esta no se puede dividir fomentando la encapsulación. Se han destacado dos problemas con esta métrica: Dos clases pueden tener LCOM=0, mientras una tiene más variables comunes que otra. No existen guías para la interpretación de esta métrica. 4.2.3 Métricas de Lorenz y Kidd Lorenz y Kidd propusieron las métricas de diseño para medir las características estáticas de un producto software, se dividen en tres grupos: Métricas de tamaño Métricas de herencia Métricas de las características internas de las clases. De todas las propuestas, las que se pueden aplicar a un diseño de alto nivel son las siguientes. Métricas de tamaño PIM: La métrica Número de Métodos de Instancia Públicos es el número total de métodos públicos de instancias (los que están disponibles como servicios para otras clases), se considera que mide la cantidad de responsabilidad que tiene una clase. 41

NIM: Se define el Número de Métodos de Instancia como la suma de todos los métodos (públicos, protegidos y privados) de una clase, según los autores es una medida de la cantidad de colaboración utilizada. Métricas de tamaño NIV: El Número de Variables de Instancia se determina por el número total de variables (privadas y protegidas) a nivel de instancia que tiene una clase. NCM: El Número de Métodos de Clase es el número total de métodos a nivel de clase. NVV: El Número de Variables de Clase es el total de variables a nivel de clase que tiene una clase. Métricas de herencia NMO: El Número de Métodos Sobrecargados es el número total de métodos sobrecargados en una subclase. Se propuso para medir la calidad del uso de la herencia. NMI: El Número de Métodos Heredados se define como el número de métodos que hereda una clase. También mide la calidad del uso de la herencia. NMA: El Número de Métodos Añadidos es el número total de métodos que se definen en una subclase. Igual que las anteriores mide la calidad de uso de la herencia. SIX: El Índice de Especialización para una clase se define como el número de métodos sobrescritos multiplicado por el nivel de anidamiento en la jerarquía y dividido entre el número total de métodos. Nº de métodos redefinidos * Anidamiento en la jerarquía SIX = Nº total de métodos Mide el grado en que una subclase redefine el comportamiento de una superclase. Esta fórmula pondera más las redefiniciones que ocurren en niveles más profundos del árbol de herencia, ya que cuanto más especializada es una clase, menos probabilidad existe de que su comportamiento sea reemplazado. Métricas de características internas de una clase APPM: El Promedio de Parámetros por Método se define como el cociente entre el número total de parámetros por método y el número total de métodos, estas métricas están enfocadas a las características internas del diseño O.O. con medidas objetivas y una herramienta, la OOMetric, que sólo puede aplicarse a código escrito en C++ y Smalltalk, no se han validado teóricamente. Se han validado parcialmente de forma empírica. 42

43

5. CALIDAD DE PRODUCTO DE SOFTWARE El concepto de Calidad asociado al desarrollo software, está ligado al mismo desde sus orígenes. Desafortunadamente, se construyen proyectos y productos que no alcanzan los mínimos de calidad esperado, incluso los costes de no calidad, la deuda técnica, inducen a la no finalización con éxito de los mismos. Planificamos el desarrollo de productos en base a una metodología o un marco de trabajo, siguiendo un proceso definido y obviando actividades asociadas a la calidad. A menudo confundimos la calidad del proceso con la calidad del producto, lo que conlleva falsas expectativas en el desarrollo del software. Incluso en muchas organizaciones no existe una mentalización real por la calidad del producto, sino que prima la puesta en servicio sobre la calidad del mismo; y lo que es peor, no cuentan con un proceso de V&V (verificación y validación) definido y obviamente no implantado. La Calidad del Producto es una ventaja inherente, consubstancial, y connatural frente a la Competencia, un Producto no es sólo la implementación software, escrito en un determinado lenguaje de programación, de un conjunto de funcionalidades, claras y explicitas, que permiten establecer un proceso de negocio en nuestras Compañías, con el fin de crear valor. Todo aquel activo generado en la Cadena de Valor, en aras a la generación de un activo software, forma parte inherente del mismo. A este pool de assets lo denominamos producto. 5.1 Norma ISO/IEC 9126 Esta norma Internacional fue publicado en 1992, la cual es usada para la evaluación de la calidad de software, llamado Information technology ± Software product evaluation ± Quality characteristics and guidelines for their use ; o también conocido como ISO 9126 (o ISO/IEC 9126). Este estándar describe 6 características generales. y son definidas transcribiéndolas de su fuente original así: Funcionalidad, y que textualmente la define: A set of attributes that bear on the existence of a set of functions and their specified properties. The functions are those that satisfy stated or implied set of users Confiabilidad, y que textualmente la define: A set of attributes that bear on the capability of software to maintain its level of performance under stated conditions for a stated period of time Usabilidad, y que textualmente la define: ³A set of attributes that bear on the effort needed for use, and on the individual assessment of such use, by a stated or implied set of users. 44

Eficiencia, y que textualmente la define: ³A set of attributes that bear on the relationship between the level of performance of the software and the amount of resources used, under stated conditions Mantenibilidad, y que textualmente la define: ³A set of attributes that bear on the mffort needed to make specified modifications Portabilidad, y que textualmente la define: A set of attributes that bear on the ability of software to be transferred from one environment to another La ISO/IEC 9126 permite especificar y evaluar la calidad del software desde diferentes criterios asociados con adquisición, requerimientos, desarrollo, uso, evaluación, soporte, mantenimiento, aseguramiento de la calidad y auditoria de software. Los modelos de calidad para el software se describen así: Calidad interna y externa Especifica 6 características para calidad interna y externa, las cuales, están subdivididas. Estas divisiones se manifiestan externamente cuando el software es usado como parte de un sistema Informático, y son el resultado de atributos internos de software: Calidad en uso Calidad en uso es el efecto combinado para el usuario final de las 6 características de la calidad interna y externa del software. Especifica 4 características para la calidad en uso. Al unir la calidad interna y externa con la calidad en uso se define un modelo de evaluación más completo, se puede pensar que la usabilidad del modelo de calidad externa e interna pueda ser igual al modelo de calidad en uso, pero no, la 45

usabilidad es la forma como los profesionales interpretan o asimilan la funcionabilidad del software y la calidad en uso se puede asumir como la forma que lo asimila o maneja el usuario final. Si se unen los dos modelos, podríamos definir que los seis indicadores del primer modelo tienen sus atributos y el modelo de calidad en uso sus 4 indicadores pasarían hacer sus atributos, mirándolo gráficamente quedaría asi: La calidad del software se evalúa teniendo en cuenta la etapa del desarrollo, se deben fijar la metas de la calidad tanto para el software final como para desarrollos incompletos y tener en cuenta que es imposible que las metas y criterios sean iguales para un software pequeño y un gran software empresarial. 5.2 Norma ISO/IEC 25000 (SQueRE) ISO/IEC 25000, conocida como SQuaRE (System and Software Quality Requirements and Evaluation), es una familia de normas que tiene por objetivo la creación de un marco de trabajo común para evaluar la calidad del producto software. La familia ISO/IEC 25000 es el resultado de la evolución de otras normas anteriores, especialmente de las normas ISO/IEC 9126, que describe las particularidades de un modelo de calidad del producto software, e ISO/IEC 14598, que abordaba el proceso de evaluación de productos software. Esta familia de normas ISO/IEC 25000 se encuentra compuesta por cinco divisiones. 46

ISO/IEC 2500n División de Gestión de Calidad Las normas que forman este apartado definen todos los modelos, términos y definiciones comunes referenciados por todas las otras normas de la familia 25000. Actualmente esta división se encuentra formada por: - ISO/IEC 25000 - Guide to SQuaRE: contiene el modelo de la arquitectura de SQuaRE, la terminología de la familia, un resumen de las partes, los usuarios previstos y las partes asociadas, así como los modelos de referencia. - ISO/IEC 25001 - Planning and Management: establece los requisitos y orientaciones para gestionar la evaluación y especificación de los requisitos del producto software. ISO/IEC 2501n División de Modelo de Calidad Las normas de este apartado presentan modelos de calidad detallados incluyendo características para calidad interna, externa y en uso del producto software. Actualmente esta división se encuentra formada por: - ISO/IEC 25010 - System and software quality models: describe el modelo de calidad para el producto software y para la calidad en uso. Esta Norma presenta las características y subcaracterísticas de calidad frente a las cuales evaluar el producto software. - ISO/IEC 25012 - Data Quality model: define un modelo general para la calidad de los datos, aplicable a aquellos datos que se encuentran almacenados de manera estructurada y forman parte de un Sistema de Información. 47

ISO/IEC 2502n División de Medición de Calidad Estas normas incluyen un modelo de referencia de la medición de la calidad del producto, definiciones de medidas de calidad (interna, externa y en uso) y guías prácticas para su aplicación. Actualmente esta división se encuentra formada por: - ISO/IEC 25020 - Measurement reference model and guide: presenta una explicación introductoria y un modelo de referencia común a los elementos de medición de la calidad. También proporciona una guía para que los usuarios seleccionen o desarrollen y apliquen medidas propuestas por normas ISO. - ISO/IEC 25021 - Quality measure elements: define y especifica un conjunto recomendado de métricas base y derivadas que puedan ser usadas a lo largo de todo el ciclo de vida del desarrollo software. - ISO/IEC 25022 - Measurement of quality in use: define específicamente las métricas para realizar la medición de la calidad en uso del producto. - ISO/IEC 25023 - Measurement of system and software product quality: define específicamente las métricas para realizar la medición de la calidad de productos y sistemas software. - ISO/IEC 25024 - Measurement of data quality: define específicamente las métricas para realizar la medición de la calidad de datos. ISO/IEC 2503n División de Requisitos de Calidad Las normas que forman este apartado ayudan a especificar requisitos de calidad que pueden ser utilizados en el proceso de licitación de requisitos de calidad del producto software a desarrollar o como entrada del proceso de evaluación. Para ello, este apartado se compone de: - ISO/IEC 25030 - Quality requirements: provee de un conjunto de recomendaciones para realizar la especificación de los requisitos de calidad del producto software. ISO/IEC 2504n División de Evaluación de Calidad Este apartado incluye normas que proporcionan requisitos, recomendaciones y guías para llevar a cabo el proceso de evaluación del producto software. Esta división se encuentra formada por: - ISO/IEC 25040 - Evaluation reference model and guide: propone un modelo de referencia general para la evaluación, que considera las entradas al proceso de evaluación, las restricciones y los recursos necesarios para obtener las correspondientes salidas. - ISO/IEC 25041 - Evaluation guide for developers, acquirers and independent evaluators: describe los requisitos y recomendaciones para la implementación práctica de la evaluación del producto software desde el punto de vista de los desarrolladores, de los adquirentes y de los evaluadores independientes. 48

- ISO/IEC 25042 - Evaluation modules: define lo que la Norma considera un módulo de evaluación y la documentación, estructura y contenido que se debe utilizar a la hora de definir uno de estos módulos. - ISO/IEC 25045 - Evaluation module for recoverability: define un módulo para la evaluación de la subcaracterística Recuperabilidad (Recoverability). 5.3 Modelo Macall El modelo de McCall organiza los factores en tres ejes o puntos de vista desde los cuales el usuario puede contemplar la calidad de un producto, basándose en once factores de calidad organizados en torno a los tres ejes y a su vez cada factor se desglosa en otros criterios: Antes de comenzar a utilizar el modelo de McCall hay que seguir las siguientes pautas: Se aceptan los factores, criterios y métricas que propone el modelo. Se aceptan las relaciones entre factores y criterios, y entre criterios y métricas. Se selecciona un subconjunto de factores de calidad sobre los que aplicar los requisitos de calidad establecidos para el proyecto. Al comienzo del proyecto habrá que especificar los requisitos de calidad del producto software, para lo cual se seleccionarán los aspectos inherentes a la calidad deseada del producto, teniendo que considerarse para ello: Las características particulares del propio producto que se está diseñando: por ejemplo, su ciclo de vida que si se espera que sea largo implicará un mayor énfasis en la facilidad de mantenimiento y la flexibilidad, o bien si el sistema en desarrollo está destinado a un entorno donde el hardware evoluciona rápidamente implicará como requisito su portabilidad. La relación calidad-precio, que puede evaluarse a través del coste de cada factor de calidad frente al beneficio que proporciona. La siguiente tabla muestra la relación calidad-precio para cada factor considerado: 49

La determinación de las etapas del ciclo de vida donde es necesario evaluar cada factor de calidad para conocer en cuales se dejan sentir más los efectos de una calidad pobre con respecto a cada uno de los factores. Las propias interrelaciones entre los factores debido a que algunos factores pueden entrar en conflicto entre sí: por ejemplo, la eficiencia plantea conflictos prácticamente con todos los demás factores de calidad. La interacción entre los diversos factores a evaluar queda reflejada en la tabla I que indica la dependencia entre los factores de McCall. También habrá que establecer valores deseables para los criterios, para lo cual se emplearán datos históricos, el promedio en la industria y con ellos se concretarán los valores finales y otros intermedios o predictivos en cada período de medición durante el desarrollo, así como unos valores mínimos aceptables. La explicación para cualquier selección o decisión deberá ser adecuadamente documentada. En la fase de desarrollo será necesario implementar las métricas elegidas, analizar sus resultados y tomar medidas correctivas cuando los valores obtenidos estén por debajo de los mínimos aceptables. Una vez finalizado el proyecto será necesario contrastar las medidas predictivas utilizadas y comprobar si, en efecto, se pueden tomar como indicadores de los valores finales. 50

(CALERO, EDICIÓN 2010)5.4 Modelo de BOEHM Este modelo de calidad es el segundo más conocido y fue propuesto por Barry Boehm en el año de 1978 y es similar al modelo de McCall definiendo la calidad en términos de atributos cualitativos y métricas para realizar las medidas. La estructura jerárquica del modelo se presenta en la figura y plantea 3 niveles para las características: de alto nivel, de nivel intermedio y nivel primitivo. Cada una de estas características contribuye al nivel general de calidad. El modelo se centra en: - Sus características operativas. - Su capacidad para soportar los cambios. - Su adaptabilidad a nuevos entornos. - La evaluación del desempeño del hardware 51

Las características de algo nivel representan requerimientos generales de uso: Utilidad per-se, cuan (usable, confiable, eficiente) es el producto en sí mismo. Mantenimiento, cuan fácil es modificarlo, enterdelo y retestearlo. Utilidad general, si puede seguir usándose si se cambia el ambiente. Las características de nivel intermedio representan factores de calidad de Boehm: Portabilidad (Utilidad general) Fiabilidad (Utilidad per-se) Eficiencia (Utilidad per-se) Usabilidad (Utilidad per-se) Capacidad de prueba (Mantenibilidad) Comprensibilidad (Mantenibilidad) Flexibilidad (Mantenibilidad) El nivel más bajo corresponde a características asociadas a uno o dos criterios de calidad. Aunque parezcan similares, la diferencia está en que McCall focaliza en medidas precisas de alto nivel, mientras que Boehm presenta un rango más amplio de características primitivas. La mantenibilidad está más desarrollada en Boehm. 52

53