Mtricas de Calidad de Software

Integrantes: Betzabeth Pereira Farid Ayaach Henry Quintero Ismael Granadillo Jomar Bustamante

Deniciones

Calidad Realizada

Calidad Programada

Calidad Necesaria

Deniciones
Medida Proporciona una indicacin cuantitativa de la cantidad, dimensiones o tamao de algunos atributos de un producto. Medicin Acto de determinar una medida. Mtrica Es una medida del grado en que un sistema, componente o proceso posee un atributo dado.

Mtricas de Software
Las mtricas del Software comprenden un amplio rango de actividades diversas, estas son algunas: Aseguramiento y control de calidad Modelos de abilidad Modelos y evaluacin de ejecucin Modelos y medidas de productividad

Mtricas de Software

mejorar

aplicar

proveer

Proceso de recopilacin de mtricas de Software

Medidas

Mtricas

Indicadores

Clasicacin de las mtricas de Software

Segn los criterios:
de complejidad de calidad de competencia de desempeo estilizadas
Mtricas que denen la medicin de la complejidad: volumen, tamao, anidaciones, y conguracin. Mtricas que denen la calidad del software: exactitud, estructuracin o modularidad, pruebas, mantenimiento. Mtricas que intentan valorar o medir las actividades de productividad de los programadores con respecto a su certeza, rapidez, eciencia y competencia Mtricas que miden la conducta de mdulos y sistemas de un software, bajo la supervisin del SO o hardware. Mtricas de experimentacin y de preferencia: estilo de cdigo, convenciones, limitaciones, etc.

Clasicacin de las mtricas de Software

Segn el contexto en que se aplican:
Mtricas de proceso Se recopilan de todos los proyectos, y durante un largo periodo de tiempo Caracterizados por: Control y ejecucin del proyecto. Medicin de tiempos de las fases. Mtricas de proyecto Permiten evaluar el estado del proyecto. Permiten seguir la pista de los riesgos. Mtricas de producto Se centran en las caractersticas del software y no en como fue producido. Tambin son productos los artefactos, documentos, modelos, y componentes que conforman el software. Se miden cosas como el tamao, la calidad, la totalidad, la volatilidad, y el esfuerzo.

Mtricas de Calidad
Principal objetivo de los ingenieros de software es producir sistemas, aplicaciones o productos de alta calidad. Para las evaluaciones que se quieran obtener es necesario la utilizacin de medidas tcnicas, que evalan la calidad de manera objetiva.

Mtricas de Calidad - Modelos conocidos

Modelo de MCCALL (1977)
Describe la calidad como un concepto elaborado mediante relaciones jerrquicas entre factores de calidad, en base a criterios Los factores de calidad se concentran en tres aspectos importantes de un producto de software: caractersticas operativas, capacidad de cambios y adaptabilidad a nuevos entornos. Identica una serie de criterios, tales como rastreabilidad, simplicidad, capacidad de expansin, etc. Las mtricas desarrolladas estn relacionadas con los factores de calidad y la relacin que se establece se mide en funcin del grado de cumplimiento de los criterios.

Mtricas de Calidad - Modelos conocidos

Modelo de MCCALL (1977)
Factor Correctitud Criterio Rastreabilidad Completitud Consistencia Consistencia Exactitud Tolerancia a fallas Eciencia de ejecucin Eciencia de almacenamiento Control de acceso Auditora de acceso Operabilidad Entrenamiento Comunicacin Modularidad Similitud de comunicacin Similitud de datos. Factor Mantenibilidad Capacidad de Prueba Criterio Simplicidad Concrecin Simplicidad Instrumentacin Auto-descriptividad Modularidad Auto-descriptividad Capacidad de expansin Generalidad Modularidad Auto-descriptividad Independencia del sistema Independencia de mquina Auto-descriptividad Generalidad Modularidad Independencia del sistema Independencia de mquina

Conabilidad

Eciencia Integridad Usabilidad

Flexibilidad

Portabilidad

Interoperabilidad

Reusabilidad

Criterios asociados a los factores de calidad

Mtricas de Calidad - Modelos conocidos

Modelo de FURPS (1987)
Modelo desarrollado por Hewlett-Packard (HP) en 1987, desarrollando un conjunto de factores de calidad de software y sus respectivos atributos. Funcionalidad (Functionality), usabilidad (Usability), conabilidad (Reliability), desempeo (Performance) y capacidad de soporte (Supportability). Basado en el modelo de MCCALL. Se utilizan para establecer mtricas de la calidad para todas las actividades del proceso de desarrollo de un software, inclusive de un sistema de informacin.

Mtricas de Calidad - Modelos conocidos

Modelo de FURPS (1987)
Factor Funcionalidad Criterio Caractersticas y capacidades del programa Generalidad de las funciones Seguridad del sistema Factores humanos Factores estticos Consistencia de la interfaz Documentacin Frecuencia y severidad de las fallas Exactitud de las salidas Tiempo medio de fallos Capacidad de recuperacin ante fallas Capacidad de prediccin Factor Rendimiento Criterio Velocidad del procesamiento Tiempo de respuesta Consumo de recursos Rendimiento efectivo total Ecacia Extensibilidad Adaptabilidad Capacidad de pruebas Capacidad de conguracin Compatibilidad Requisitos de instalacin

Facilidad de Uso

Capacidad de Soporte

Conabilidad

Criterios asociados a los factores de calidad

Mtricas de Calidad - Modelos conocidos

Modelo de DROMEY (1996)
Resalta el hecho de que la calidad del producto es altamente determinada por los componentes del mismo (incluyendo documentos de requerimientos, guas de usuarios, diseos, y cdigo), Sugiere el uso de cuatro categoras que implican propiedades de calidad, que son: correctitud, internas, contextuales y descriptivas.
Factor Correctitud Internas Criterio Funcionalidad Conabilidad Mantenibilidad Eciencia Conabilidad Mantenibilidad Reusabilidad Portabilidad Conabilidad Mantenibilidad Reusabilidad Portabilidad Usabilidad
Criterios asociados a los factores de calidad

Contextuales

Descriptivas

Mtricas de Calidad - Modelos conocidos

Normas ISO 9000 ISO/IEC 9126

Mtricas de Calidad - Modelos conocidos

MOSCA (Modelo Sistmico de Calidad)
Consta de 4 niveles: dimensiones, categoras, caractersticas y las mtricas. En base de tres ramas: el producto, el proceso y la humana. Contiene un total de 715 mtricas.

Mtricas de Calidad - Modelos conocidos

MOSCA MOSCA (Modelo Sistmico de Calidad)
Ejemplo de agrupacin de mtricas

Mtricas de Calidad - Modelos conocidos

MOSCA MOSCA (Modelo Sistmico de Calidad)
Ejemplo de mtricas

Mtricas de Calidad - Modelos conocidos

Ejemplo

Una organizacin lleva a cabo un proyecto de desarrollo de un software X.

El responsable del proyecto necesita saber si la productividad es adecuada.

Conocer el nivel de productividad de los programadores del proyecto en comparacin con lo habitual en otros proyectos en la organizacin.

Mtricas de Calidad - Modelos conocidos

Ejemplo
Las mtricas a utilizar podran ser:

Directas LCF: lneas de cdigo fuente escritas. HPD: horas-programador diarias. CHP: coste por horaprogramador, en unidades monetarias.

Indirectas HPT: horas-programador totales. LCFH: lneas de cdigo fuente por hora de programador. CTP: coste total actual del proyecto, en unidades monetarias. CLCF: coste por lnea de cdigo fuente.

Indicadores PROD: productividad de los programadores.

Mtricas de Calidad - Modelos conocidos

Ejemplo
La forma de obtenerlas viene dada por:

Directas LCF = Contar las lneas de cdigo. HPD = Contar cada da las horas dedicadas por los programadores al proyecto. CHP = Consultar el plan de proyecto.

Indirectas HPT = HPD LCFH = LCF/HPT CTP = CHP*HPT CLCF = LCF/CTP

Indicadores PROD: Establecer criterios o rangos de valores.

Software Libre y Calidad

La calidad se ha convertido en uno de los elementos diferenciadores en el mbito mundial entre las compaas desarrolladoras de sistemas de software. La bsqueda de la calidad de los sistemas ha propiciado la creacin de modelos, frameworks y metodologas para evaluar y asegurar su calidad. El Software Libre tambin ha tenido un impulso que ha despertado un inters particular en sus herramientas y modelos de negocios, pero sobre todo en sus procesos de desarrollo. Pero, cmo se relacionan estos dos conceptos (calidad y Software Libre)?

Software Libre y Calidad

Nace entonces la necesidad de estimar la calidad de este tipo de herramientas. En el 2006 surge el Software Quality Observatory for Open Source Software (SQO-OSS). SQO-OSS desarroll un conjunto de herramientas de evaluacin de software con las que se podr analizar y comparar la calidad del cdigo de fuente y probar su idoneidad para su despliegue empresarial. El coste total del proyecto se estima en unos 2.470 millones de euros. Estas herramientas slo estimarn la calidad del producto.

Modelo de QSOS
Uno de los modelos que permite la cuanticacin y calicacin de software Open Source es el Method for Qualication and Selection of Open Source Software (QSOS). Est orientado exclusivamente al producto de software. Ms informacin en http://www.qsos.org/

Metodologa del Modelo QSOS

Es un proceso que consiste en 4 pasos que pueden ser renados. A saber:

Pasos de la Metodologa
1. Denicin: Constitucin y enriquecimiento de los marcos de referencia que sern utilizados en los pasos siguientes. 2. Evaluacin: Evaluacin del software hecho de acuerdo a 3 ejes de criterios: cobertura funcional, riesgos del usuario y riesgos del proveedor de servicios (independientemente de cada usuario particular/ contexto de uso). 3. Calicacin: Carga de los criterios divididos en 3 ejes, modelando el contexto (requerimientos de usuario y/o estrategia escogida por el proveedor de servicios). 4. Seleccin: Aplicacin del ltro congurado en el paso anterior a los datos encontrados en los dos primeros pasos, de manera de realizar consultas, comparaciones y seleccin de productos.

Paso 1 : Denicin
El objetivo de este paso es denir varios elementos de la tipologa a ser utilizada por los 3 pasos que siguen. Los marcos de referencia son: 1. Familia de Software. Este aspecto responde la pregunta Qu tipo de software estamos analizando?. 2. Tipos de Licencia. Clasicacin de las licencias ms comunes de Software Libre y de cdigo abierto. 3. Tipos de comunidades. Clasicacin de las comunidades que pueden desarrollar Software Libre u Open Source.

Paso 2 : Evaluacin
Este paso tiene como objetivo la coleccin de informacin por parte de las comunidades de cdigo abierto. Esta evaluacin comprende la elaboracin de la tarjeta de identicacin del software, as como la elaboracin de la hoja de evaluacin del software. La tarjeta de identicacin del software contiene datos y hechos acerca del software, es utilizada como base para el proceso de evaluacin. Contiene elementos como nombre, fechas de creacin, tipo de software autores, descripcin general, los servicios que presenta, aspectos tcnicos y funcionales, entre otros. Por otra parte la hoja de evaluacin, contempla la identicacin, descripcin y anlisis en detalle de cada versin que se presenta del software.

Paso 2 : Evaluacin
La tarjeta de identicacin cubre lo siguiente: Informacin general. Nombre del software Referencia, fecha de creacin, fecha de elaboracin de esta tarjeta Autor Tipo de software Entre otros Sntesis y comentarios generales. Servicios existentes. Documentacin Entre otros

Aspectos tcnicos y funcionales. Tecnologas de implementacin Funcionalidades detalladas

Paso 2 : Evaluacin
La hoja de evaluacin cubre lo siguiente: Riesgos desde la perspectiva del usuario a los que est expuesto cuando escoge una solucin de Software Libre u Open Puntaje que va del 0 al 2 y que son establecidos Source. durante el paso de Calicacin dependiendo de los requerimientos del usuario. Riesgos desde la perspectiva de un proveedor de servicios que utilice dicha Cobertura funcional determinada por la solucin de software. denicin establecida en el paso de Denicin.

Paso 3 : Calicacin
El objetivo de este paso es denir los ltros que traduzcan las necesidades y restricciones relacionadas con la seleccin del software de cdigo abierto en un contexto especico. Para ello se denen niveles de ltros sobre el software en base: Tenemos cuatro tipos de ltros:

Filtros sobre la tarjeta de identicacin. Filtros sobre las funcionalidades. Filtros sobre los riesgos desde la perspectiva del usuario. Filtros sobre los riesgos desde la perspectiva del proveedor de servicios.

Paso 4 : Seleccin
Este paso tiene como objetivo identicar el La seleccin estricta se basa en la eliminacin software que contenga y satisfaga los del software tan pronto como el software no requerimientos de usuario, o de manera ms cumpla con lo formulado en el paso de general permita la comparacin de software de Calicacin. Este mtodo es muy restrictivo y una misma familia. Puede ser de dos modos: un puede no seleccionar software alguno. modo estricto (seleccin estricta), y otro un La seleccin holgada se basa en darle poco ms holgado (seleccin holgada). puntuacin nuevamente al software dependiendo de lo obtenido en el paso de Evaluacin. Al nal se escoge el software con ms (o menos) puntos.

Paso 4 : Seleccin
As luce una plantilla de una hoja de evaluacin de QSOS:

Paso 4 : Seleccin
As luce una hoja de evaluacin de QSOS:

Mtricas usadas por QSOS

Bsicamente la metodologa busca dar indicadores familia determinada de software. sobre la funcionalidad que presta un software Las mtricas generales se describen en la determinado y los riesgos que podra corre un Generic Section de la hoja de evaluacin y se usuario y/o un proveedor de servicios con dicho encuentran justo debajo de la tarjeta de identicacin. Este tipo de mtrica comprende software.
aspectos como madurez, actividad en el desarrollo, portabilidad, entre otras.

Para obtener esos indicadores QSOS utiliza dos tipos de mtricas: Mtricas generales: que se aplican a todo tipo de Software Libre u Open Source. Mtricas especcas: que se aplican a una

Las mtricas especicas se describen justo despus de la Generic Section. Comprenden aspectos inherentes a las caractersticas del tipo de software. Por ejemplo, para la familia de software de RDBMS se contempla el soporte de SQL, el soporte de constraints sobre las tablas, entre otros.

Mtricas usadas por QSOS

Durabilidad intrnseca (sustentabilidad)
Madurez
Edad Estabilidad Historia, problemas conocidos Probabilidad de forks, fuentes del forking

Liderazgo de desarrollo
Equipo de desarrollo (tamao) Estilo de gerencia (dictatorial, un poco dspota, consejo de arquitectos)

Actividad
Desarrolladores (nmero total de desarrolladores, cargos bien /mal denidos e identicados) Actividad en solucin de problemas Actividad en el desarrollo de funcionalidades Actividad en nuevos lanzamientos

Adopcin
Popularidad (relacionada con: pblico en general, expertos, ...) Referencias (si se emplea en alguna solucin conocida) Comunidad de contribuyentes (nivel de actividad) Libros disponibles

Mtricas usadas por QSOS

Solucin industrializada
Independencia del desarrollo (si el software es desarrollado por una nica compaa) Servicios
Entrenamiento Soporte Consultora

Aseguramiento de la calidad
Aseguramiento de la calidad (utilizando algn mtodo o modelo reconocido) Herramientas (feedback u alguna otra herramienta que monitoree el progreso)

Empaquetamiento (paquete ocial, ofrecido por la comunidad, no disponible)

Fuente Debian FreeBSD HP-UX MacOSX Mandriva

Documentacin (no disponible, disponible /actualizada, disponible/no actualizada)

Mtricas usadas por QSOS

Explotabilidad
Facilidad de uso, ergonoma (si requiere de conocimientos tcnicos: bajo, medio o alto) Administracin / Monitoreo (si proporciona herramientas de administracin/monitoreo)

Estrategia
Licencia
Permisividad (slo si el usuario quiere hacerse dueo del cdigo) Proteccin respecto a forks propietarios

Adaptabilidad tcnica (inherente al cdigo fuente)

Modularidad (software: monoltico, modularidad de primer nivel, completamente modular) Modicacin del cdigo (compilacin: difcil y a mano, posible y a mano,) Extensin del cdigo (requiere re-compilacin, uso y manejo de plugins)

Propietario de los copyrights (si es un individual, una comunidad o una empresa) Modicacin del cdigo fuente (imposible, uso de repositorios, )

Roadmap (pblicado, no publicado) Patrocinante Independencia estratgica

Caso de Estudio : QSOS

Supongamos una empresa que est evaluando la En un primer paso, la herramienta solicita al posibilidad de incluir alguna de tres aplicaciones usuario que especique la familia de software a de software conocidas de bases de datos evaluar. relacionales: MaxDB, MySQL y PostgreSQL en una aplicacin web propia. Para ello utiliz una herramienta web disponible en el website de QSOS que permite aplicar los dos ltimos pasos de la metodologa sobre unas hojas de evaluacin previamente denidas y que estn disponibles en el website. Dicha herramienta se denomina O3S.

Caso de Estudio : QSOS

Luego, aparece una tabla donde el usuario podr especicar los pesos que le asigna a cada aspecto del software (de acuerdo con la familia elegida en el paso anterior). Estos pesos sern utilizados para calcular el puntaje nal y ver qu software se ajusta ms a las necesidades del usuario.

Caso de Estudio : QSOS

El tercer paso consiste en elegir si se quiere mostrar los resultados va web, en un documento QSOS XML o en un documento de OpenOfce.org.

Caso de Estudio : QSOS

Es posible ver un grco de radar (en los resultados) donde se pueden establecer comparaciones entre el software elegido.

MySQL Server 5.0 PostgreSQL 8.0 Max DB 7.6

Caso de Estudio : QSOS

La empresa seleccion MaxDB ya que ofrece ms caractersticas avanzadas y facilita la modicacin del cdigo.

MySQL Server 5.0 PostgreSQL 8.0 Max DB 7.6

Caso de Estudio : MOSCA

Dos empresas estn desarrollando una aplicacin El primero enfocado al producto y dirigido a web cada una. Quieren conocer qu tan bueno tres grupos de evaluacin: el Lder del Proyecto, es su software. Para ello buscaron ayuda del LISI. Desarrolladores-Analistas y Usuarios. El segundo tipo de cuestionario est enfocado al proceso de desarrollo y va dirigido a dos grupos de evaluacin: el Lder del Proyecto y los Desarrolladores-Analistas.

Se aplicaron dos tipos de cuestionarios.

Caso de Estudio : MOSCA

Los datos de las dos empresas fueron analizados En primer lugar, se analizan los datos referentes tomando en cuenta: al producto. Las categoras seleccionadas (aparte de Funcionalidad) por ambas empresas fueron: Mantenibilidad y Usabilidad. Se debe recordar que segn el algoritmo del modelo MOSCA, la empresa debe seleccionar exactamente 2 categoras que identiquen a su producto de software.

Las categoras del producto seleccionadas por la empresa junto con el evaluador Las categoras del proceso Las caractersticas del producto y del proceso.

Caso de Estudio : MOSCA

La Empresa A seleccion la categora usabilidad, ya que el sitio Web debe ser un producto atractivo, entendible y fcil de utilizar para los usuarios del mismo. Lo ms importante de esta aplicacin es su front-end, por lo cual el mismo debe cumplir los requerimientos de la categora Usabilidad. La otra categora seleccionada fue mantenibilidad, ya que el producto debe ser actualizado constantemente y por ello debe tener la capacidad de ser modicado sin ningn problema. La Empresa B seleccion la categora usabilidad, ya que su producto est destinado a diferentes tipos de usuarios y la dicultad en el uso del mismo debe ser mnima. Adems, esta aplicacin debe ser atractiva, ya que el xito de la misma, depender del grado de satisfaccin de los usuarios. La otra categora seleccionada fue mantenibilidad, ya que el producto de software est en constante desarrollo y debe ser capaz de aceptar cualquier tipo de modicaciones.

Caso de Estudio : MOSCA

Porcentajes de satisfaccin de los productos frente a la caracterstica USABILIDAD.

Caso de Estudio : MOSCA

Porcentajes de satisfaccin de los productos frente a la caracterstica FUNCIONALIDAD.

Caso de Estudio : MOSCA

Porcentajes de satisfaccin de los productos frente a la caracterstica MANTENIBILIDAD.

Fuentes Consultadas
http://prof.usb.ve/lmendoza/Documentos/PS-6116/Guia%20Arquitectura%20v.2.pdf http://books.google.co.ve/books?id=DR74RkJlBTMC&printsec=frontcover&dq=la+calidad+del+software+y+s u+medida&ei=CYzGSdG8LJjSzATF_ZjaDQ#PPA12,M1 http://www.monograas.com/trabajos55/proceso-de-desarrollo-software/proceso-dedesarrollo-software2.shtml http://www.ub.edu.ar/catedras/ingenieria/ing_software/ubftecwwwdfd/calidadsw/criterios.htm http://eisc.univalle.edu.co/materias/Material_Desarrollo_Software/Metricas4.pdf http://www.ejournal.unam.mx/cys/vol08-03/CYS08304.pdf . Anna Grimn. http://www.qsos.org