Metricas del producto para el Software

50 %
50 %
Information about Metricas del producto para el Software
Education

Published on February 22, 2014

Author: walct2

Source: slideshare.net

Description

RESUMEN: En los tiempos actuales, gracias a los avances de la Informática, el software se utiliza en casi todos los campos de la actividad humana: la industria, el comercio, las finanzas, el gobierno, la salud, la educación, las artes. Existe una creciente preocupación por lograr que los productos software cumplan con ciertos criterios de calidad. Para ello, se avanza en la definición e implementación de estándares que fijan los atributos deseables del software de calidad, a la vez que surgen modelos y metodologías para la evaluación de la calidad. Para lograr este objetivo, los ingenieros de software deben emplear métodos efectivos junto con herramientas modernas dentro del contexto de un proceso maduro de desarrollo del software.

Sistemas de Información II – Año 2014 Medidas del producto para el Software Walter C. Tejerina1 (1)Sistemas de Información II, Facultad de Ingeniería, Universidad Nacional de Jujuy walterct87@gmail.com RESUMEN: En los tiempos actuales, gracias a los avances de la Informática, el software se utiliza en casi todos los campos de la actividad humana: la industria, el comercio, las finanzas, el gobierno, la salud, la educación, las artes. Existe una creciente preocupación por lograr que los productos software cumplan con ciertos criterios de calidad. Para ello, se avanza en la definición e implementación de estándares que fijan los atributos deseables del software de calidad, a la vez que surgen modelos y metodologías para la evaluación de la calidad. Para lograr este objetivo, los ingenieros de software deben emplear métodos efectivos junto con herramientas modernas dentro del contexto de un proceso maduro de desarrollo del software. 1  INTRODUCCION Las métricas del software permiten medir de forma cuantitativa la calidad de sus atributos internos del producto, esto permite al ingeniero evaluar la calidad antes de su construcción. Es importante establecer ¿qué es la calidad del software?, ¿Quién lo hace?, ¿Por qué es importante?, ¿Cuáles son los pasos? Para determinar la calidad, ¿Cuál es el producto obtenido?, ¿Cómo estar seguro de hacerlo correctamente?. Todas estas interrogantes se determinarán a lo largo del desarrollo del presente informe. Aspectos a considerar tales como hacer una distinción entre medida, métrica e indicador, qué factores de calidad se toman. 1.1 Calidad del software Es el cumplimiento de los requisitos de funcionalidad y desempeño explícitamente establecidos, los estándares de desarrollo explícitamente documentados y las características implícitas que se esperan de todo software desarrollado profesionalmente. La calidad del software es una compleja mezcla de factores que variarán a través de diferentes aplicaciones y según los clientes que las pidan [1]. Con esta definición se destacan tres puntos importantes:   Los requisitos del software son la base de las medidas de calidad. La falta de concordancia con estos requisitos es una falta de calidad. Los estándares especificados definen un conjunto de criterios de desarrollo que guían la ingeniería del software. Si no se siguen los criterios, el resultado será, casi seguramente, la falta de calidad. A menudo se soslaya un conjunto de requisitos implícitos. Si el software cumple con sus requisitos explícitos pero no con los implícitos, la calidad del software estará en duda. . 1.1.1 Factores de Calidad de McCall Estos factores se dividen en dos grupos muy importantes:   Los que se miden directamente. Los que solo se miden indirectamente. McCall, Richards y Walters propusieron unos factores los cuales se concentran en tres aspectos importantes de un producto de software: sus características operativas, su capacidad para experimentar cambios y su capacidad para adaptarse a nuevos entornos. En la siguiente figura se observan los factores que afectan la calidad del software.

Sistemas de Información II – Año 2014 2 Figura 1. Factores de calidad de McCall 1.1.2 9126 Factores de calidad del estándar ISO Se desarrolló un intento por identificar los atributos de calidad para el software de computadora. El estándar identifica 6 puntos:  Funcionalidad  Confiabilidad  Facilidad de uso  Eficiencia  Facilidad de mantenimiento  Portabilidad MARCO CONCEPTUAL PARA METRICAS DEL PRODUCTO El peligro de tratar de encontrar medidas que caractericen tantos atributos diferentes es que inevitablemente las medidas tienen que satisfacer objetivos que entran en conflicto entre sí. Esto se opone a la teoría de que cada medición debe ser representativa. Muchas personas argumentan que la medición del producto realizada durante las primeras etapas del proceso de software proporciona a los ingenieros un mecanismo consistente y objetivo para evaluar la calidad. 2.1 Principios de medición Roche sugiere un proceso de medición al que caracterizan cinco actividades:    1.2 Métricas, medición e indicadores La medición es un elemento clave en cualquier proceso de ingeniería. Las medidas se emplean para comprender mejor los atributos de los modelos que se crean y evaluar la calidad de los productos de la ingeniería. Por las características inherentes al software, sus medidas y métricas son indirectas y, por lo tanto, expuestas al debate. Una medida proporciona una indicación cuantitativa de la extensión, cantidad, dimensión capacidad o tamaño de algún atributo de un producto o proceso [2]. Una métrica es una evaluación del grado en que un sistema, componente o proceso posee un atributo determinado (extensión, cantidad, dimensiones, capacidad o tamaño). Un ingeniero de software recopila medidas y desarrolla métricas para obtener los indicadores. Un indicador es una métrica o combinación de métricas que proporcionan conocimientos. Estos conocimientos le permiten al jefe de proyecto o a los ingenieros de software ajustar el proceso, el proyecto o el producto para que las cosas mejoren. LAS   Formulación. Derivación de medidas y métricas apropiadas para la representación del software que se considera. Recolección. Mecanismo con que se acumulan los datos necesarios para derivar las métricas formuladas. Análisis. Cálculo de las métricas y la aplicación de herramientas matemáticas. Interpretación. Evaluación de las métricas en un esfuerzo por conocer mejor la calidad de la representación. Retroalimentación. Recomendaciones derivadas de la interpretación de las métricas del producto transmitidas al equipo del software. Existen principios que son representativos de muchos otros que podrían proponerse para caracterizar y validar las métricas:    Una métrica debe tener propiedades matemáticas deseables. Cuando una métrica representa una característica de software que aumenta cuando se presentan rasgos positivos o que disminuye al encontrar rasgos indeseables, el valor de la métrica debe aumentar o disminuir en el mismo sentido. Cada métrica debe validarse empíricamente en una amplia variedad de contextos antes de publicarse o aplicarse a la toma de decisiones.

Sistemas de Información II – Año 2014 2.2 Métricas del modelo de análisis En esta fase se obtendrán los requisitos y se establecerá el fundamento para el diseño. Y es por eso que se desea una visión interna a la calidad del modelo de análisis. Sin embargo hay pocas métricas de análisis y especificación, se sabe que es posible adaptar métricas obtenidas para la aplicación de un proyecto, en donde las métricas examinan el modelo de análisis con el fin de predecir el tamaño del sistema resultante, en donde resulte probable que el tamaño y la complejidad del diseño estén directamente relacionados. Es por eso que se verán en las siguientes secciones las métricas de puntos de función y de calidad de especificación [3]. 2.2.1 Puntos de función El Punto Función es “un método para medir el tamaño y la complejidad software basándose en la cantidad de funcionalidad”, o una herramienta para “medir el tamaño funcional del software”. Permite a los clientes disponer de un método común para estimar el trabajo de sus proveedores. Normalmente, además el método del cálculo del punto función es conocido por el proveedor. Y en cualquier caso se evitan las estimaciones “ad hoc” para cada desarrollo / proveedor. Se consigue así tener unas “tablas estándar” de estimación de los trabajos, y métricas derivadas, como el número de horas de desarrolladores por Puntos Función, Número total de horas por Puntos Función, Coste por Puntos Función, etc. Pero una de las dificultades de implantar el punto función es que hay muchos métodos, y “familias”, para calcular los Puntos Función. Y que algunos son más ligeros y otros enormemente más pesados. Con el objetivo de hacer más llevadera la tarea de seleccionar un método para el cálculo del punto función, dos de los métodos más prácticos y ligeros para implantar la estimación con punto función son los siguientes:  FP Lite: Este método es una derivación del método el IFPUG (International Function Point Users Group), ya que el método tradicional del IFPUG es bastante complejo de implantar. El FP Lite lo que hace es reducir y simplificar las fases del IFPUG.  Puntos Casos de Uso (Use Case Points): Se basa en casos de uso. Y es de gran aplicabilidad al mundo real. El método es del 93, y de manera similar al FP Lite, simplifica y reduce considerablemente los pasos necesarios para estimar. Ambos métodos permiten definir un conjunto de tablas estándar, por las que todos los proveedores deben guiarse a la hora de realizar una estimación. El FP Lite trabaja con requisitos más tradicionales, y el Puntos Casos de Uso con casos de uso como entrada. Ambos son ligeros, y existen experiencias reales de su implantación [4]. 2.2.2 Métricas de la calidad de la especificación Propuesta por Pressman, mide la calidad del análisis y de los requisitos capturados. A pesar de medir factores cualitativos, propone métricas como por ejemplo el número de requisitos donde los revisores han interpretado lo mismo. Al medir características de la especificación es posible obtener un conocimiento cuantitativo de la especificidad y el grado de avance proponen una lista de características que pueden emplearse para valorar la calidad del modelo de análisis y la correspondiente especificación de requisitos: especificidad (ausencia de ambigüedad), compleción, corrección, comprensión, capacidad de verificación, consistencia interna y externa, capacidad de logro, concisión, trazabilidad, capacidad de modificación, exactitud y capacidad de reutilización. Además, los autores apuntan que las especificaciones de alta calidad deben estar almacenadas electrónicamente, ser ejecutables o al menos interpretables, anotadas por importancia y estabilidad relativas, con su versión correspondiente, organizadas, con referencias cruzadas y especificadas al nivel correcto de detalle. 2.3 Métricas del modelo de diseño Las métricas de diseño para el software, como otras métricas del software, no son perfectas. Continúa el debate sobre la eficacia y cómo deberían aplicarse. Muchos expertos argumentan que se necesita más experimentación hasta que se puedan emplear las métricas de diseño. Y sin embargo, el diseño sin medición es una alternativa inaceptable. 2.3.1 Métricas del diseño arquitectónico Consideradas métricas de caja negra ya que no requieren ningún conocimiento del funcionamiento interno de un componente de software en particular. Se centran en la arquitectura del programa y la eficiencia de los módulos. Son de caja negra en el sentido que no

Sistemas de Información II – Año 2014 requieren ningún conocimiento del trabajo interno de un módulo en particular del sistema. Card y Glass definen tres medidas de la complejidad del diseño del software: complejidad estructural, complejidad de datos y complejidad del sistema. La complejidad de datos D(i) proporciona una indicación de la complejidad en la interfaz interna de un módulo i. La complejidad del sistema C(i) se define como la suma de las complejidades estructural y de datos. 2.3.2 Métricas del diseño a nivel de componentes Las métricas de diseño a nivel de componentes se concentran en las características internas de los componentes del software e incluyen medidas de las “3Cs” -la cohesión, acoplamiento y complejidad del módulo-. Estas tres medidas pueden ayudar al desarrollador de software a juzgar la calidad de un diseño a nivel de los componentes. Las métricas presentadas en esta sección son de caja blanca en el sentido de que requieren conocimiento del trabajo interno del módulo en cuestión. Las métricas de diseño de los componentes se pueden aplicar una vez que se ha desarrollado un diseño procedimental. También se pueden retrasar hasta tener disponible el código fuente [2]. 2.3.2.1 Métricas de cohesión Bieman y Ott definen una colección de métricas que proporcionan una indicación de la cohesión de un módulo. Las métricas se definen con cinco conceptos y medidas: Porción de datos: es un recorrido hacia atrás por un módulo que busca valores de datos que afectan el estado del módulo cuando comienza el recorrido. Muestras de datos: las variables detenidas para un módulo se definen como muestras de datos para el módulo. Señales de unión: este conjunto de muestras de datos cae en una o más porciones de datos. Señales de superunión: estas muestras de daos son comunes a todas las porciones de datos de un módulo. Capacidad de unión: la capacidad de unión relativa de una señal de unión es directamente proporcional al número de porciones de datos que une. Cohesión funcional fuerte: un procedimiento sin señales de superunión tiene 0 (cero) cohesión funcional fuerte, es decir que no hay muestras de datos que contribuyen a todas las salidas. Cohesión funcional débil: un procedimiento sin señales de unión tiene 0 (cero) cohesión funcional débil, es decir que no hay muestras de datos que contribuyen a todas las salidas. Adhesividad: un procedimiento sin señales de unión tiene 0 (cero) adhesividad, es decir que no hay muestras de datos que contribuyen a más de una salida. 2.3.2.2 Métricas de acoplamiento El acoplamiento de módulo proporciona una indicación de la conectividad de un módulo con otros módulos, datos globales y el entorno exterior. Se ha propuesto una métrica para el acoplamiento del módulo que combina el acoplamiento de flujo de datos y de control, acoplamiento global y acoplamiento de entorno. Las medidas necesarias para calcular el acoplamiento de módulo se definen en términos de cada uno de los tres tipos de acoplamiento apuntados anteriormente. Para el acoplamiento de flujo de datos y de control: Di = número de parámetros de datos de entrada Ci = número de parámetros de control de entrada Do = número de parámetros de datos de salida Co = número de parámetros de control de salida Para el acoplamiento global: Gd = número de variables globales usadas como datos Gc = número de variables globales usadas como control Para el acoplamiento de entorno: W = número de módulos llamados (expansión) R = número de módulos que llaman al módulo en cuestión Usando estas medidas, se define un indicador de acoplamiento de módulo M de la siguiente manera: M=K/m Donde K = L es una constante de proporcionalidad y m = Di + a x Ci + Do + b x Co + Gd + c x Gc + W + R

Sistemas de Información II – Año 2014 Los valores de k, a, b y c deben derivarse empíricamente. A medida que M aumenta, el acoplamiento general del módulo disminuye. Para que la métrica suba a medida que aumenta el grado de acoplamiento se define una métrica revisada: C=1-M 2.3.3 Métricas del diseño orientado a objetos Las métricas orientadas a objetos se centran en métricas que se pueden aplicar a las características de encapsulamiento, ocultamiento de información, herencia y técnicas de abstracción de objetos que hagan única a esa clase. Se proponen una familia de medidas para desarrollos orientados a objetos:       Métodos ponderados por clase (MPC): Tamaño y complejidad Profundidad árbol de herencia (PAH): Tamaño Número de descendientes (NDD): Tamaño, acoplamiento y cohesión Acoplamiento entre clases (ACO): Acoplamiento Respuesta para una clase (RPC): Comunicación y complejidad Carencia de cohesión en los métodos (CCM): Cohesión interna. Estas métricas, en líneas generales, permiten averiguar cuán bien están definidas las clases y el sistema, lo cual tiene un impacto directo en la mantenibilidad del mismo, tanto por la comprensión de lo desarrollado como por la dificultad de modificarlo con éxito. 2.3.4 Métricas orientadas a clases La clase es la unidad fundamental de un sistema orientado a objetos. Por tanto las medidas y metricas de una clase individual seran invaluables para un ingeniero de software que debe valorar la calidad de diseño. La clase es el predecesor de las subclases que heredan sus atributos y operaciones Se basa en la idea de que el número de métodos y su complejidad es un indicador razonable de la cantidad de esfuerzo necesaria para implementar y comprobar una clase. Mide la complejidad de una clase asignándole una complejidad a cada método. Resulta ambigua dado que no ofrece ninguna definición asociada a la complejidad. 2.4 Métricas del modelo del código fuente La teoría de Halstead de la ciencia del software es «probablemente la mejor conocida y más minuciosamente estudiada de las medidas compuestas de la complejidad (software). La ciencia del software propone las primeras «leyes» analíticas para el software de computadora. La ciencia del software asigna leyes cuantitativas al desarrollo del software de computadora, usando un conjunto de medidas primitivas que pueden obtenerse una vez que se ha generado o estimado el código después de completar el diseño. Estas medidas se listan a continuación. Figura 2. Medidas de Diseño Halstead usa las medidas primitivas para desarrollar expresiones para la longitud global del programa; volumen mínimo potencial para un algoritmo; el volumen real (número de bits requeridos para especificar un programa); el nivel del programa (una medida de la complejidad del software); nivel del lenguaje (una constante para un lenguaje dado); y otras características tales como esfuerzo de desarrollo, tiempo de desarrollo e incluso el número esperado de fallos en el software. Halstead expone que la longitud N se puede estimar como: N = N1 + N2. Es una simple medida del tamaño de un programa. Cuanto más grande sea el tamaño de N, mayor será la dificultad para comprender el programa y mayor el esfuerzo para mantenerlo. El volumen de programa se puede definir como un “peso extra” al número de operadores y operandos únicos. Por ejemplo, si dos programas tienen la misma longitud N pero uno tiene mayor número de operadores y operandos únicos, que naturalmente

Sistemas de Información II – Año 2014 lo hacen más difícil de entender y mantener, este tendrá un mayor volumen Se calcula como El índice de madurez del software se calcula de la siguiente manera: V = N x log2(n) donde n = n1 + n2 IMS = [Mt – (Fa + Fc + Fd)] / Mt] Se debería tener en cuenta que V variará con el lenguaje de programación y representa el volumen de información (en bits) necesarios para especificar un programa. Teóricamente, debe existir un volumen mínimo para un algoritmo. Halstead define una relación de volumen L como la relación de volumen de la forma más compacta de un programa con respecto al volumen real del programa. Por tanto, L debe ser siempre menor de uno. En la métrica de Halstead también se define el esfuerzo, esta ofrece una medida del trabajo requerido para desarrollar un programa. Desde el punto de vista del mantenimiento, el esfuerzo se puede interpretar como una medida del trabajo requerido para comprender un software ya desarrollado. Se calcula como Donde: Mt es el número de módulos en la versión actual Fa es el número de módulos añadidos a la versión actual Fc es el número de módulos cambiados en la versión actual Fd es el número de módulos de la versión anterior que se eliminaron en la actual A medida que el IMS se acerca a 1,0 el producto comienza a estabilizarse 3 CONCLUSION E = V/L Donde L (lenguaje) indica si se está utilizando un lenguaje de alto o bajo nivel. Aumenta proporcionalmente con el volumen, pero decrece con la utilización de lenguajes de alto nivel. Por ejemplo, una simple llamada a un procedimiento podría tener un valor L de 1; en COBOL podría tener 0,1 y el ensamblador podría tener un L de 0,01[5]. 2.5 Métricas para mantenimiento Todas las métricas del software pueden usarse para el desarrollo de nuevo software y para el mantenimiento del existente. Sin embargo, se han propuesto métricas diseñadas explícitamente para actividades de mantenimiento. El estándar EEE 982.1-1988 sugiere un índice de madurez del software (IMS) que proporciona una indicación de la estabilidad de un producto software (basada en los cambios que ocurren con cada versión del producto). Se determina la siguiente información: Figura 3. Medidas para índice de madurez A lo largo de nuestra investigación vimos como las métricas proporcionan los conocimientos necesarios para crear modelos efectivos de análisis y diseño, un código sólido y pruebas exhaustivas. Estas métricas se enfocan al proceso de software en varios aspectos tales como métricas del producto, para el modelo de análisis, para el modelo de diseño, para el código fuente, para pruebas y para mantenimiento, las cuales permiten el control de calidad en cada uno de estos procesos. Otras como las métricas del modelo de análisis se concentran en la función, los datos y el comportamiento (los tres componentes del modelo de análisis). El punto de función proporciona medidas cuantitativas para evaluar el modelo de análisis. Las métricas del diseño consideran aspectos de alto nivel, del nivel de componentes y de diseño de interfaz. Las métricas de diseño de alto nivel consideran los aspectos arquitectónicos y estructurales del modelo de diseño. Las métricas de diseño de nivel de componentes proporcionan una indicación de la calidad del módulo estableciendo medidas indirectas de la cohesión, acoplamiento y complejidad.

Sistemas de Información II – Año 2014 4 BIBLIOGRAFIA [1] Calidad en el Software. Mayela Delgado. Marzo. Disponible en: http://www.entornoempresarial.com/articulo/106/ calidad-en-el-software-i Fecha: 13 de febrero de 2014 [2] Pressman, R. S. (2006) “Ingeniería de Software. Un enfoque práctico”. MCGRAWHILL. México. 2006 [3] Métricas en el desarrollo del Software Heidi González Doria. Disponible en: http://catarina.udlap.mx/u_dl_a/tales/documentos/ lis/gonzalez_d_h/capitulo4.pdf Fecha: 13 de febrero de 2014 [4]Dos métodos prácticos para implantar la estimación con puntos de función. Javier Garzas. Disponible en: http://www.javiergarzas.com/2012/03/puntosfuncion.html Fecha: 13 de febrero de 2014 [5]Métricas del código fuente Ingeniería del software II. Yajaira Pallares Echavez. Disponible en: http://ingsoftware3.blogspot.com.ar/2013/01/metricas-delcodigo-fuente.html Fecha: 13 de febrero de 2014

Add a comment

Related presentations

Related pages

METRICAS DEL PRODUCTO PARA EL SOFTWARE | Sagfenix's Weblog

Fundamentos Ingeniería del Software. Informe Ejecutivo. Stalin Rojas Morocho. METRICAS DEL PRODUCTO PARA EL SOFTWARE. 1 Introducción. Las medidas y ...
Read more

METRICAS DEL PRODUCTO PARA EL SOFTWARE - Pensamiento ...

Metricas para el codigo fuente Metricas de Halstead Metricas de complejidad ... METRICAS DEL PRODUCTO PARA EL SOFTWARE; TECNICAS DE PRUEBA DE SOFTWARE;
Read more

Informe Ejecutivo - Techi Ruilova

Informe Ejecutivo María Esther Ruiloav Rojas 21 de abril de 2008 Métricas del Producto para el Software (Ingeniería de software Enfoque Práctico)
Read more

Métricas del Producto para el Software | Calidad ...

Calidad del Software es el cumplimiento de los requisitos de funcionalidad y desempeño explícitamente establecidos, de los estándares de desarrollo ...
Read more

MÉTRICAS DEL PRODUCTO PARA EL SOFTWARE « Techi Ruilova

Las métricas del software permiten medir de forma cuantitativa la calidad de sus atributos internos del producto, esto permite al ingeniero evaluar la ...
Read more

METRICAS DEL PRODUCTO DEL SOFTWARE by Mayra Negrete on Prezi

METRICAS DEL PRODUCTO DEL SOFTWARE ... Para ayudar a justificar el uso de nueva herramienta o de formación adicional RAZONES PARA MEDIR UN PRODUCTO DE ...
Read more

Ingenieria del Software: Métricas del Software

Puntos Objeto para estimar el tamaño del software, ... ajustando el modelo de tal forma que refleje fielmente el producto de software ... Metricas ...
Read more