Calidad

MODELOS DE DESARROLLO DE SOFTWARE:

Modelo "CMMI"

CMMI significa "Capability Maturity Model Integration" o en español "Modelo de Integración de la Madurez y Capacidad" y es un modelo de desarrollo de software enfocado al proceso de los mismos, este modelo maneja 6 conceptos principales, los cuales son:

• Procesos: Se define como un método para producir algo, el cual toma en cuenta las Técnicas, los Materiales, las Herramientas y las Personas que intervienen en su ejecución.
• Área de Proceso: Son un conjunto de actividades agrupadas para facilitar el camino de la mejora y establecen la capacidad de proceso de la empresa.
• Capacidad: Es una cualidad que permite el buen desarrollo de una actividad y suele aplicarse a los procesos, con la relación de que a mayor capacidad de un proceso, más predecible será su resultado.
• Madurez: Puede definirse como el alcance de la plenitud y es algo que se adquiere con la experiencia al evolucionar los procesos para bien.
• Organización: Como bien su nombre lo dice, es la estructura de la empresa desarrolladora, que toma en cuenta a la empresa en sí, la Unidad de Negocio, el Centro de Trabajo y el Proyecto.
• Modelo: Es un esquema teórico de una situación real que se desarrolla para facilitar la comprensión y estudio de ésta

El CMMI es un modelo que enseña el camino para alcanzar un nivel de Madurez de la organización o un nivel de capacidad en un área de proceso, por lo tanto este modelo dice Qué es lo que se tiene que hacer, mas no el Cómo hacerlo.

La estructura del modelo CMMI se divide en 2 tipos, el escalonado y el continuo, cada uno de ellos dividiendose en 6 niveles:

Estructura Escalonada (Evaluación de Madurez):

Nivel 0: Proceso incompleto y no aplicable.

Nivel 1 (Inicial): Proceso impredecible, poco controlado y reactivo.

Nivel 2 (Gestionado): Proceso aplicable en proyectos y frecuentemente reactivo.

Nivel 3 (Definido): Proceso aplicable a toda la organización y que reacciona anticipadamente.

Nivel 4 (Gestionado cuantitativamente): El proceso es predecible y controlado cuantitativamente.

Nivel 5 (Optimización): Enfoque en la mejora del proceso.

Estructura Continua (Evaluación de Capacidad):

Nivel 0: Incompleto

Nivel 1: Realizado, proceso informal e impredecible.

Nivel 2: Gestionado, sistema de gestión de proyectos presente, comportamiento predecible.

Nivel 3: Definido, procesos de ingeniería y de gestión definidos e integrados

Nivel 4: Gestionado cuantitativamente, productos y procesos controlados cuantitativamente.

Nivel 5: En optimización, la mejora de procesos está institucionalizada.

Clasificación de Áreas de Proceso:

• Ingeniería.
• Gestión de Proyecto.
• Gestión de Proceso.
• Soporte.

Cada una de estas áreas tiene diferentes funciones dependiendo del nivel en el que se encuentren, además de que también se conforman de:

• Meta u Objetivo General
• Meta u Objetivo Específico

El objetivo general es el propósito principal del proyecto y los objetivos específicos son aquellos que al cumplirse llevan a la realización del objetivo general. Estos objetivos facilitan la institucionalización del proceso, es decir, cuando se sigue de una forma rutinaria como parte de la organización y para esto es necesario seguir los pasos de Compromiso, Habilidades, Implantación y Verificación.

Gestión de Proyecto: Cubren las actividades relacionadas con la planificación, seguimiento y control del proyecto. Está conformado por los siguientes apartados:

• Planificación de Proyectos.
• Seguimiento y Control de Proyectos.
• Gestión Integrada de Proyectos.
• Desarrollo de Equipos Integrado.
• Gestión de Riesgos.
• Gestión de Proyectos Cuantitativa.
• Gestión de Acuerdos con Proveedores.

Ingeniería: Da soporte a las actividades del ciclo de vida de desarrollo del producto. Está conformado por:

• Desarrollo de Requisitos.
• Gestión de Requisitos.
• Solución Técnica.
• Integración del Producto.
• Verificación.
• Validación.

Soporte: Proporciona los procesos esenciales para soportar el desarrollo y mantenimiento del producto, formado por:

• Medición y Análisis.
• Gestión de Configuración.
• Aseguramiento de Calidad de Proceso y Producto.
• Análisis y Resolución de Decisiones.
• Análisis y Resolución Causal.
• Entorno Organizativo para la Integración.

Gestión de Procesos: Contiene las prácticas relacionadas con la implementación de un programa de mejora de procesos, conformado por:

• Enfoque en el Proceso Organizativo.
• Definición del Proceso Organizativo.
• Formación Organizativa.
• Rendimiento del Proceso Organizativo.
• Innovación y Despliegue Organizativo.

Con la aplicación de todos estos aspectos del modelo CMMI, se espera un buen nivel de calidad en el desarrollo del software en aspectos como la organización, la productividad, el cumplimiento de requisitos, etc.

Modelo PSP/TSP:

El modelo conocido como PSP/TSP es uno que se encuentra dividido en dos partes, inicialmente se aplica el PSP (Personal Software Process) y posteriormente el TSP (Team Software Process).

El PSP es un proceso que como su nombre lo dice está diseñado a nivel personal, y que se aplica a tareas estructuradas

El objetivo de este proceso es:

• Planear y monitorear el trabajo.
• Administrar la calidad de los productos que se producen.
• Medir y mejorar el desempeño.

Todas estas acciones se realizan a un nivel personal, donde el individuo se toma a sí mismo como sujeto de estudio y lleva a cabo estas acciones, buscando su mejora y el desarrollo de disciplina.

Una vez que cada individuo lleva a cabo el PSP, se prosigue ahora con el TSP, el cual como su nombre indica, es un proceso de desarrollo para equipos basados en CMMI. El propósito de este modelo es obtener:

• Predecibilidad de costo y tiempo.
• Mejora de productividad y ciclos de desarrollo.
• Mejora de calidad de productos.

En suma lo que busca lograr este conjunto de procesos es la resolución de problemas de negocio, esto primero haciendo que cada individuo mejore su forma de trabajar y de analizar su desempeño para después juntarse con otros y trabajar en un equipo con el objetivo de cumplir con un desarrollo de manera eficaz y eficiente.

Proceso de Mejora Continua.

El llamado proceso de mejora continua proviene de la época de la segunda guerra mundial, más específicamente de japón, donde este término es conocido como "Kaizen", "Kai" que significa "Cambio" y "Zen" que significa "Bueno". Esto fue debido a que al término de la 2da guerra mundial la situación de Japón era muy difícil y crearon el llamado JUSE (Unión Japonesa de Científicos e Ingenieros) con el cual crearon metodologías para mejorar el proceso empresarial.

El proceso de mejora continua hace uso del llamado "Círculo de Deming", el cual está constituido por 4 pasos que forman un ciclo, haciendo que una vez es terminado el último, se vuelve a empezar el ciclo con el primer paso. Estos pasos son:

• Planear: Se establece una meta, se analiza un problema y se define el plan de acción.
• Hacer: Se ejecuta el plan de acción y se registra.
• Verificar: Se analiza el resultado obtenido.
• Actuar: Una vez se tienen los resultados, se decide si es necesaria alguna modificación para mejorar.

Cuando el círculo de Deming se aplica al proceso de mejora continua, lo que se obtiene es un ciclo en el que una empresa una vez que lleva a cabo un proyecto, es capaz de analizar los resultados que obtuvo de éste y ver si fueron favorables o no, una vez que se determina esto, se procede a discutir si se puede realizar alguna modificación a la forma en que se ejecutó el proyecto para mejorarlo y una vez hecho esto, se reinicia el ciclo con el mismo proyecto o uno nuevo, pero ya aplicando las modificaciones que se discutieron con anterioridad. De esta forma el ciclo provoca que continuamente se estén revisando y analizando los procesos que lleva a cabo el equipo o la empresa y así modificarlos constantemente en busca de un mejor desempeño, dando lugar así a la mejora continua.

Fuentes:

http://www.alconet.com.ar/ISO/menu.html

http://www.aec.es/c/document_library/get_file?p_l_id=32315&folderId=210056&name=DLFE-6053.pdf

http://www.kernel.com.mx/documentos/psp_tsp.pdf

http://www.manufacturainteligente.com/kaizen/

Factores Internos y Externos de la Calidad de Software

Cómo se ha visto anteriormente, la calidad de software es algo que depende de una serie de métricas cuyo propósito es evaluar si el software cumple con características particulares de cada métrica, esto con el objetivo de garantizar la calidad del mismo.

Algo que debe de tenerse en cuenta, es que una métrica como bien su nombre lo dice, es una medida de algo, sin embargo estas no se aplican al software directamente, sino que se aplican a través de los anteriormente mencionados "factores de calidad", estos pueden ser de tipo interno (la estructura de funcionamiento del software) o de tipo externo (lo que "ve" el usuario). Estos factores son los siguientes:

Exactitud:

Este es probablemente el factor más importante de calidad de un software, pues se refiere a la función que tiene el mismo y si la cumple o no, es decir que si por ejemplo la función de un software es comprimir archivos en un formato en particular, éste tendrá exactitud si cumple específicamente con eso que es su función o propósito, si este factor falla, fácilmente puede hacer que todos los demás factores se vuelvan completamente inútiles puesto que el software simple y sencillamente no cumpliría con su función o propósito.

Una formula o métrica para calcular la exactitud puede ser la siguiente:

Número de Requerimientos - Requerimientos Cumplidos

Con esta fórmula se evalúa cuántos de los requerimientos que se tienen para un software fueron cumplidos, si el resultado es cero, quiere decir que el nivel de exactitud es optimo, pues cumple con lo que se requiere de él y si el resultado es mayor de cero, en nivel de exactitud iría disminuyendo al no cumplir con todos sus requerimientos.

Robustez:

La robustez es el segundo factor más importante en la calidad de un software, esto es debido a que la robustez es la capacidad de un software de reaccionar a situaciones anormales.

Como podría esperarse, la exactitud se enfoca en que el software cumpla su función, sin embargo para que suceda esto el usuario debe de interactuar de manera correcta con éste, pero esto no siempre va a suceder así debido a los errores humanos, un ejemplo sencillo es una calculadora, una calculadora esperaría que el usuario introduzca operaciones matemáticas lógicas y que tengan sentido, normalmente esto provocaría que si el usuario intenta introducir una operación con errores matemáticos (por ejemplo una división entre cero) o de sintaxis, el software de la calculadora fallara y se estropeara debido a que se está enfrentando a una situación para la cual no fue diseñada. Sin embargo la robustez del software se encarga de esto al actuar como un "margen de error", haciendo que si el software se encuentra con situaciones anormales despliegue automáticamente un mensaje de error al usuario indicándole la situación en cuestión, registrando así esa situación anormal en el software y evitando que se estropee.

Una fórmula que podría utilizarse para medir la robustez de un software sería la siguiente:

Número de errores / Número de veces que reacciona bien

Esta formula nos dice que entre más veces el software reaccione de manera adecuada ante los errores que se presenten, el nivel de robustez es mayor, en este caso cuando el resultado sea lo más cercano posible a 1.

Eficiencia:

La eficiencia es una parte importante de la calidad de un software, y puede definirse como la cantidad de recursos utilizados por éste para cumplir con su función. Un programa puede cumplir con su función, pero esto no sería de mucha ayuda si para hacerlo necesita consumir una cantidad enorme de recursos de la computadora y además tarda en dar un resultado. Es debido a esto que la eficiencia de un software es importante, puesto que si el nivel es alto permite que cumpla su función de una manera rápida y sin consumir demasiados recursos. Normalmente esto se toma como un aspecto secundario dado que se le da una mayor prioridad a que sea eficaz, es decir que cumpla su función (exactitud) y es a causa de esto que constantemente uno podría por ejemplo encontrarse con programas cuyos requerimientos mínimos se cumplen o se sobrepasan, pero que a la hora de la ejecución, el desempeño es pobre y consume más recursos de los que aparentaba, provocando un desperdicio innecesario de recursos y de tiempo.

Una forma de medir la eficiencia de un software es la siguiente:

Resultados / Recursos

Con esta formula se da a entender que entre más resultados se puedan obtener con menos recursos, el nivel de eficiencia será mayor, es decir que el nivel de eficiencia aumenta cuando el resultado es mayor a 1 y disminuye cuando es menor a 1.

Funcionalidad:

La funcionalidad se refiere a la "simpleza" que tiene el software al momento que el usuario interactua con él, es decir a la capacidad del software de hacer que el usuario entienda como funciona y no se pierda. Normalmente para lograr esto, lo que se hace es "limitar" la extensión o cantidad de posibilidades que ofrece un software, esto es debido a que si las posibilidades son demasiadas el usuario corre riesgo de verse abrumado por tantas opciones y funciones, provocando que se pierda y no entienda bien cómo funciona el software, mientras que si las posibilidades son demasiado bajas se corre con el riesgo de que el software se vea muy limitado en sus capacidades y que no pueda cumplir con todas sus funciones de manera satisfactoria. Un ejemplo de esto puede ser facebook, el cual en sus constantes actualizaciones y cambios ha llegado a un punto donde ofrece tantas posibilidades a los usuarios que estos se ven abrumados por ellas y pierden la habilidad de manejar el sitio de manera fluida y sencilla.

Medir la funcionalidad es algo un tanto más complicado que los demás factores, debido a que en este se debe buscar un equilibrio y no irse a algún extremo, por lo que la fórmula podría ser la siguiente:

Número de funciones + Número de posibles errores

Con esta fórmula se da a entender que entre más funciones se tienen, mayor cantidad de errores o complicaciones pueden surgir, pero como debe mantenerse un equilibrio lo ideal es que el número de funciones sea únicamente el necesario para cumplir con los requerimientos.

Fácil de Usar:

Este es un factor que está estrechamente relacionado con el anterior (funcionalidad). Como bien su nombre lo dice, este factor se enfoca en que el software pueda ser tomando por cualquier usuario y éste pueda rápidamente entenderlo y utilizarlo, para lograr esto se deben de tomar en cuenta aspectos como la interfaz gráfica, tutoriales que expliquen el software, simplicidad del programa, etc. Sin embargo un detalle que se debe tener en cuenta es que no se debe de hacer que un software sea excesivamente fácil de utilizar debido a que esto provocaría que estuviera limitado en las posibilidades que ofrece, además de que si alguien con conocimientos avanzados utiliza un software así, rápidamente sentiría que es demasiado simple y limitado por lo que al igual que con la funcionalidad se debe de mantener un equilibrio en este apartado.

La forma de medir este factor puede ser la siguiente:

Nivel de conocimiento del usuario * Tiempo que tarda en entender el programa

Con esta fórmula se da a entender que entre menor sea el resultado, más fácil de usar es el programa, pero el detalle que debe de tenerse en cuenta es que entre mayor nivel de conocimiento tenga un usuario, menos tiempo tardará en entender el programa, por lo que deben también tomarse en cuenta a los usuarios con menor nivel de conocimiento.

Reutilización:

La reutilización puede definirse como la capacidad que tiene un software de utilizar sus elementos en la construcción de otro, esto es debido a que un software en sus partes más fundamentales, puede compartir estructuras con otros ya existentes y gracias a esto los ya existentes pueden ser utilizados en la construcción del nuevo, evitando así que se tenga que volver a desarrollar algo que ya se había hecho antes y permitiendo así acelerar el proceso de desarrollo del software.

Un ejemplo de la reutilización pueden ser las librerías de Java, dado que estas librerías son códigos hechos anteriormente que cumplen con alguna función en particular y que al utilizarlas en la construcción de un software se acelera el proceso al ya no tener que volver a programar una función que éste requiera.

La forma de medir la reutilización puede ser la siguiente:

Cantidad utilizada del software original / Tamaño original del software

Con esta fórmula se expresa que entre más se haya utilizado un software en la construcción de otro, su nivel de reutilización es mayor, en este caso cuando el resultado sea lo más cercano a 1.

Compatibilidad:

La compatibilidad de un software es su capacidad de poder interactuar correctamente con otros para cumplir alguna función determinada. Normalmente un mismo software va a ser utilizado en diferentes plataformas y va a tener que interactuar con diversos programas, la compatibilidad se encarga de garantizar que éste software pueda interactuar de manera correcta con todos ellos y que así pueda cumplir lo requerido, el ejemplo más sencillo de esto vendría siendo el sistema operativo que un programa de pide para poder instalarlo.

Una formula para medir la compatibilidad sería:

No. Sistemas capaces de comunicarse / No. de cambios requeridos para poder combinarse

Con esta fórmula se dice que entre menos cambios requiera un software para interactuar correctamente con otros, mayor es su nivel de compatibilidad.

Puntualidad:

Este factor no es estrictamente designado al software, sino a todo el proceso de su desarrollo, puesto que la puntualidad como bien su nombre lo indica es la capacidad de entregar el software en el tiempo requerido. Cuando un software se desarrolla, debe de cumplir con los requerimientos del cliente y uno de ellos suele ser una fecha de entrega del software, esta fecha indica el tiempo que se tiene para desarrollarlo y el nivel de puntualidad dependerá del cumplimiento de esta fecha de entrega.

Para medir la puntualidad se utiliza la siguiente fórmula:

Tiempo en el que se entregó - Tiempo indicado

Si el resultado es negativo, entonces el software fue entregado antes de la fecha límite, lo cual podría decirse que es bueno. Si el resultado es 0, el software fue entregado exactamente en el tiempo indicado, lo cual también es bueno, y si el resultado es positivo, el software fue entregado después de tiempo, lo cual es malo.

Calidad de Software

La calidad de software es un término cada vez más conocido e importante entre las empresas desarrolladoras del mismo, debido principalmente a que el nivel de calidad que ofrezcan sus productos (software) va a impactar directamente en el éxito de éste.

Como se mostró anteriormente, la calidad es un concepto un tanto complejo, pero que haciendo uso de la norma ISO 9001, se definía a la calidad como "El grado en el que un conjunto de características cumple con lo requerido". Tomando esto como base, se puede decir que al hablar de calidad de software nos referimos al grado en el que un software en particular cumple con lo requerido, sin embargo ¿qué es lo requerido?

Para responder a esta pregunta, se han creado un gran número de las llamadas "Métricas", que en esencia son una serie de mediciones y criterios orientados en este caso al software, cuyo propósito es establecer una normalización a seguir en el desarrollo de los proyectos de software buscando asegurar la calidad de este. Existen métricas de diversos tipos y son clasificadas en base a los criterios utilizados y al contexto en el que se aplican.

Métricas en base a los criterios utilizados:

- Criterios de Complejidad: Métricas que definen la medición de la complejidad: volumen, tamaño, anidaciones y configuración.

- Criterios de Calidad: Métricas que definen la calidad del software: exactitud, estructuración o modularidad, pruebas, mantenimiento.

- Criterios de Competencia: Métricas que intentan valorar o medir las actividades de productividad de los programadores con respecto a su certeza, rapidez, eficiencia y competencia.

- Criterios de Desempeño: Métricas que miden la conducta de módulos y sistemas de un software, bajo la supervisión del Sistema Operativo o hardware.

- Criterios de estilización: Métricas de experimentación y de preferencia: estilo de código, convenciones, limitaciones, etc.

Las métricas clasificadas en base al contexto en el que se aplican son utilizadas cuando se evalúa un proyecto en sus diversas partes, y dentro de esta clasificación se encuentran 3 principales tipos:

- Metricas de Proceso:

     Como su nombre lo indica, son métricas enfocadas al desarrollo del proyecto de manera general, y suelen estar caracterizadas por el control y ejecución del mismo, además de la medición de tiempo de sus fases.

- Metricas de Proyecto:

    Este tipo de métricas están orientadas a la evaluación de un proyecto en su totalidad, abarcado apartados como su viabilidad, riesgos, requerimientos, tiempo de desarrollo, etc., además de que también evalúan el estado actual del mismo.

- Métricas de Producto:

     Estas métricas están enfocadas a evaluar las características del software producido, ignorando el cómo fue desarrollado, en este tipo de métricas se le suele dar importancia al tamaño, la volatilidad, la calidad, el esfuerzo y la totalidad.

Como puede observarse, las métricas son capaces de llegar a un alto nivel de complejidad dependiendo de cómo estén diseñadas, sin embargo con el paso del tiempo se han desarrollado diversos modelos enfocados a la calidad de software, actualmente existen 4 principales modelos, cada uno de ellos con sus métricas particulares y con un mismo fin: el aseguramiento de la calidad del software, esos modelos son los siguientes:

1.- Modelo MCCALL (1977)

Este modelo describe la calidad como un concepto elaborado mediante relaciones jerárquicas entre los llamados "factores de calidad", cuyo cumplimiento se mide en función de la satisfacción de cada uno de los criterios que los conforman. Los factores de calidad y los criterios que maneja son los siguientes:

• Correctitud: Rastreabilidad, Completitud, Consistencia.
• Confiabilidad: Consistencia, Exactitud, Tolerancia a fallas.
• Eficiencia: Eficiencia de ejecución, Eficiencia de almacenamiento.
• Integridad: Control de acceso, Auditoría de acceso.
• Usabilidad: Operabilidad, Entrenamiento, Comunicación.
• Interoperabilidad: Modularidad, Similitud de comunicación, Similitud de datos.
• Mantenibilidad: Simplicidad, Concreción.
• Capacidad de Prueba: Simplicidad, Instrumentación, Auto-descriptividad, Modularidad.
• Flexibilidad: Auto-descriptividad, Capacidad de expansión, Generalidad, Modularidad.
• Portabilidad: Auto-descriptividad, Independencia del sistema, Independencia de máquina.
• Reusabilidad: Auto-descriptividad, Generalidad, Modularidad, Independencia del sistema, Independencia de máquina.

(Nota: Como puede verse en este modelo y en los siguientes, varios factores de calidad comparten criterios con el mismo nombre, sin embargo cada uno de ellos está enfocado a un aspecto diferente.)

2.- Modelo FURPS (1987)

Este es un modelo desarrollado por Hewlett-Packard y está basado en el modelo de MCCALL, por lo que se utiliza la misma idea de factores de calidad, pero ahora en vez de relacionarlos con criterios, se relacionan con atributos:

• Funcionalidad: 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 configuración, Compatibilidad, Requisitos de instalación.

3.- Modelo DROMEY (1996)

Este modelo fue desarrollado en 1996 y resalta el hecho de que la calidad del producto es altamente determinada por los componentes del mismo, debido a esto sugiere únicamente cuatro factores de calidad, los cuales son:

• Correctitud: Funcionalidad, Confiabilidad.
• Internas: Mantenibilidad, Eficiencia, Confiabilidad.
• Contextuales: Mantenibilidad, Reusabilidad, Portabilidad, Confiabilidad.
• Descriptivas: Mantenibilidad, Reusabilidad, Portabilidad, Usabilidad.

4.- Normas ISO 9000

Este es el modelo más conocido y utilizado actualmente debido al grado de aceptación que ha obtenido, se enfoca únicamente en 5 factores de calidad son sus respectivos atributos:

• Funcionalidad: Adaptabilidad, Exactitud, Interoperabilidad, Seguridad.
• Confiabilidad: Madurez, Tolerancia a fallas, Recuperabilidad.
• Usabilidad: Comprensibilidad, Aprendizaje, Operabilidad, Atractivo.
• Eficiencia: Comportamiento del tiempo, Uso de los recursos.
• Mantenimiento: Cambio, Análisis, Estabilidad, Prueba.
• Portabilidad: Adaptabilidad, Instalación, Coexistencia, Reemplazo.

Al analizar todos estos modelos de una manera detenida, se puede notar que comparten muchos apartados como la eficiencia, la portabilidad, la confiabilidad, etc. Gracias a esto se llega a una idea general de los criterios utilizados al medir la calidad de un software, que sería el que sea funcional, eficiente, confiable, portable, mantenible, accesible y flexible.


Fuentes:

Lemus Olalde, Cuauhtemoc. (2007). Calidad de Software: Modelos, Procesos, Arquitecturas. abril 14, 2015, de SETyS Sitio web: http://www.cimat.mx/Eventos/seminariodetecnologias/handout-CLemus.pdf

Fernández Peña, Juan Manuel. (2011). Calidad del Software. abril 14, 2015, de uv.mx Sitio web: http://www.uv.mx/personal/jfernandez/files/2010/07/8_Calidad.pdf

Pereira, Betzabeth. (2012). Métricas de Calidad de Software. abril 14, 2015, de ldc.usb.ve Sitio web: http://ldc.usb.ve/~abianc/materias/ci4712/metricas.pdf