Cápsula 9. Medición de Software

Transcripción

1 INTRODUCCIÓN "Lo que no se puede medir, no se puede controlar; lo que no se puede controlar no se puede gestionar; lo que no se puede gestionar, no se puede mejorar" (Peter Drucker) No se puede predecir lo que no se puede medir (Norman Fenton) Las métricas son un buen medio para entender, monitorizar, controlar, predecir y probar el desarrollo software y los proyectos de mantenimiento (Briand et al., 1996) En general, la medición persigue tres objetivos fundamentales (Fenton y Pfleeger, 1997): entender qué ocurre durante el desarrollo y el mantenimiento controlar qué es lo que ocurre en nuestros proyectos mejorar nuestros procesos y nuestros productos 1

2 INTRODUCCIÓN Las métricas pueden ser utilizadas para que los profesionales e investigadores puedan tomar las mejores decisiones. (Pfleeger, 1997). MÉTRICAS COMO MEDIO PARA ASEGURAR LA CALIDAD EN LOS PRODUCTOS / PROCESOS / PROYECTOS SOFTWARE 2

3 ONTOLOGÍA DE LA MEDICIÓN Una ontología ha de comprenderse como un entendimiento común y compartido de un dominio La medición de software es una disciplina relativamente joven, y no existe consenso general sobre la definición exacta de los conceptos y terminología que maneja. 3

4 ONTOLOGÍA DE LA MEDICIÓN 4

5 ONTOLOGÍA DE LA MEDICIÓN Sub-Ontología Caracterización y Objetivos de la Medición Software: Glosario de Conceptos 5

6 ONTOLOGÍA DE LA MEDICIÓN Sub-Ontología Caracterización y Objetivos de la Medición Software: Tabla de Interrelaciones 6

7 ONTOLOGÍA DE LA MEDICIÓN Concepto: MÉTRICA Definición. Una forma de medir y una escala, definidas para realizar mediciones de uno o varios atributos Relaciones: Una métrica está definida para uno o más atributos Una métrica puede expresarse en una unidad (sólo para métricas cuya escala sea de tipo intervalo o ratio) Ejemplos líneas de código para el tamaño de un módulo en C o de un programa en Python. 7

8 ONTOLOGÍA DE LA MEDICIÓN Concepto. MEDIDA Definición. Resultado de una medición. Relaciones Una medida es el resultado de una medición Ejemplos líneas de código, 200 páginas, 50 clases. 5 meses desde el comienzo al fin del proyecto. 0,5 fallos por cada líneas de código. 8

9 ONTOLOGÍA DE LA MEDICIÓN 9

10 10

11 ONTOLOGÍA DE LA MEDICIÓN ESCALAS NOMINAL. Escala más básica, que sitúa a las entidades en diferentes categorías asignando al atributo un nombre. Cuando un producto se rotula de acuerdo al cumplimiento de las especificaciones de diseño como "conforme y no conforme". o "crítico, grave, y menor". No se obtienen valores numéricos y no se puede realizar un orden de las observaciones con sentido. ORDINAL. Los atributos pueden ser ordenados en rangos, entre los mismos no es significativa. pero la distancia Suponga que a los clientes se les hace unas preguntas para valorar la calidad del producto. Los clientes valoran la calidad de acuerdo a las siguientes respuestas: 1 (excelente), 2 (bueno), 3 (regular), 3 (malo) 4 (pésimo). Estos datos son ordinales. Note que una valoración de 1 no indica que el servicio es dos veces mejor que cuando se da una valoración de 2. Sin embargo podemos decir que la valoración de 1 es preferiblemente mejor que 2, y así en los demás casos. 11

12 ONTOLOGÍA DE LA MEDICIÓN ESCALAS INTERVALO. Como la ordinal pero la distancia entre los atributos sí tiene sentido. Si se mide la temperatura en grados celsius, la distancia entre 30º y 40º es la misma que entre 60º y 70º. Sin embargo, hay que tener en cuenta que en esta escala el cero es arbitrario; por tanto no se puede decir que 50º es el doble de temperatura que 25º (aunque el valor si es el doble). RATIO. El mas útil en medición del software, ya que preserva el orden, el tamaño de los intervalos y también los ratios entre las entidades. Tiene un punto fijo de referencia: el cero (comienzo de la escala) y se incrementa en pasos iguales. Con estos valores de la escala se pueden hacer operaciones matemáticas de +, -, *, / 12

13 ONTOLOGÍA DE LA MEDICIÓN Todo proceso de medición tiene como objetivo fundamental satisfacer necesidades de medición detectadas en la empresa en la que se lleva a cabo. A partir de esta necesidad se identifican entidades y atributos a ser medidos. Luego se definen las métricas necesarias (unidad en la que se expresa, escala a la que pertenece, atributo o atributos para los que se define) Primero se definen métricas directas, luego indirectas, y finalmente criterios de decisión para satisfacer las necesidades de información planteadas inicialmente. 13

14 ESTÁNDARES Área Clave Medición y Análisis de CMMI 14

15 ESTÁNDARES Practical Software Measurement (PSM) (McGarry et al., 2002) se basa en la experiencia obtenida de organizaciones para saber cuál es la mejor manera de implementar un programa de medida software con garantías de éxito. 15

16 ESTÁNDARES ISO/IEC Este estándar internacional (2002) establece las actividades y tareas necesarias para identificar, definir, seleccionar, aplicar y mejorar de manera exitosa la medición de software dentro de un proyecto general o de la estructura de medición de una empresa. 16

17 ESTÁNDARES ISO/IEC

18 ESTÁNDARES MEDICIÓN EN ISO/IEC Es el estándar para los procesos de ciclo de vida del software. Este estándar se concibió para aquellos interesados en adquisición de software, así como desarrolladores y proveedores. El estándar indica una serie de procesos desde la recopilación de requisitos hasta la culminación del software. 18

19 ESTÁNDARES MEDICIÓN EN ISO/IEC El propósito del Proceso de medición es recolectar y analizar los datos relacionados con los productos desarrollados y procesos implementados al interior de la organización y sus proyectos, para apoyar la gestión efectiva de los procesos y demostrar objetivamente la calidad de los productos. 19

20 DEFINICIÓN DE MÉTRICAS Basili y Weiss (1984) y Rombach (1990). Autores y refinadores de GQM (Goal-Question- Metric), un paradigma para desarrollar y mantener un programa de métricas. Proporciona una manera útil para definir mediciones tanto del proceso como de los resultados de un proyecto. GQM se puede aplicar a todo el ciclo de vida del producto, procesos, y recursos y se pude alinear fácilmente con el ambiente organizacional. Tiene como principio básico que la medición debe ser realizada, siempre, orientada a un objetivo. Objetivo Objetivo Perseguido Preguntas Pregunta 1 Pregunta N Métricas M1... Mn M1... Mn 20

21 DEFINICIÓN DE MÉTRICAS Proceso GQM (aporte de van Soligen y Berghout, 1999) 21

22 MÉTRICAS DE SOFTWARE PROCESO DE RECOPILACIÓN DE MÉTRICAS 22

23 MÉTRICAS DE SOFTWARE Clasificación de las métricas de software según criterios: 23

24 MÉTRICAS DE SOFTWARE Según el contexto: Proceso: Se recopilan de todos los proyectos, y durante un largo periodo de tiempo Caracterizadas por: Control y ejecución del proyecto. Medición de tiempos de las fases. Proyecto: Permiten evaluar el estado del proyecto. Permiten seguir la pista de los riesgos. Producto: Se centran en las características del software y no en cómo se fabricó. También son productos los artefactos, documentos, modelos y componentes que conforman el software. Se miden cosas como el tamaño, la calidad, la totalidad, la volatilidad y el esfuerzo. 24

25 EJEMPLO. Supongamos una organización que lleva a cabo un proyecto de desarrollo de un software X. En un determinado momento el responsable del proyecto necesita saber si la productividad es adecuada, es decir: La necesidad de información es conocer el nivel de productividad de los programadores del proyecto en comparación con lo habitual en otros proyectos en la organización. Las métricas a utilizar podrían ser: Directas: LCF (líneas de código fuente escritas). El método de medición es contar las líneas utilizando como instrumento una herramienta CASE. HPD (horas-programador diarias). El método de medición es que el responsable del proyecto anota cada día las horas dedicadas por los programadores al proyecto. CHP (coste por hora-programador, en unidades monetarias). El método de medición es consultar el plan del proyecto, donde se tuvo que indicar este valor, previa consulta a un responsable de personal. 25

26 EJEMPLO Indirectas: HPT (horas-programador totales). La función de cálculo es una sumatoria de las HPD de cada día: HPT = HPD [Métrica indirecta definida con base en sólo 1 métrica directa]. LCFH (líneas de código fuente por hora de programador). La función de cálculo es una simple división: LCFH = LCF / HPD [Métrica indirecta definida con base en 2 métricas directas]. CTP (coste total actual del proyecto, en unidades monetarias). La función de cálculo establece que el CTP es el producto del coste unitario de cada hora por el total de horas empleadas: CTP = CHP * HPT [Métrica indirecta definida con base en 2 métricas, una directa y otra indirecta]. CLCF (coste por línea de código fuente). La función de cálculo establece que el CLCF es el resultado de dividir el coste total actual del proyecto -en unidades monetarias- entre la cantidad de líneas de código fuente escritas: CLCF = CTP/ LCF. [Métrica indirecta definida con base en 2 métricas, una indirecta y otra directa]. 26

27 EJEMPLO Indicadores: PROD (productividad de los programadores). El modelo de análisis utiliza los valores de las métricas LCF, HPT, LCFH y CTP para establecer un valor cualitativo de la productividad de los programadores en este proyecto. El modelo se basa en extraer de una base histórica de proyectos de la organización los valores medios de LCF, HPT, LCFH (LCFHvm valor medio de líneas de código fuente por hora de programador) y CTP del subconjunto de proyectos similares (aquellos que tienen LCF entre el 80% y el 120%). Y la organización establece el siguiente criterio de decisión: LCFH / LCFHvm < 0.70 se interpreta como PROD= muy baja <= LCFH / LCFHvm < 0.90 se interpreta como PROD= baja <= LCFH / LCFHvm < 1.10 se interpreta como PROD= normal <= LCFH / LCFHvm < 1.30 se interpreta como PROD= alta <= LCFH / LCFHvm se interpreta como PROD= muy alta. De modo que cuando se calcule el valor para el indicador (a partir de las métricas mencionadas) se podrá evaluar y entregar un concepto sobre la situación que dicho indicador pretende reflejar. 27

28 OTROS QUE SE PUEDEN UTILIZAR Número de defectos generados por desarrollador por hora Número de cambios a los requisitos Número de versiones con correcciones (patch) realizadas después de lanzar el producto Horas disponibles y ejecutadas por programador por semana Defectos descubiertos durante las pruebas Número de defectos introducidos al realizar una modificación FIN DEL DOCUMENTO 28