MEDICIONES DE SOFTWARE

Presentación del tema: "MEDICIONES DE SOFTWARE"— Transcripción de la presentación:

1 MEDICIONES DE SOFTWARE
Puntos de Función

2 OBJETIVOS DE LA PRESENTACIÓN
Que el participante conozca las métricas para estimar el tamaño de un proyecto Que el participante conozca como a partir de estimaciones basadas en el tamaño se pueden calcular las Líneas de Código y otras estimaciones para el desarrollo de un software. Que el participante pueda a partir de la sustitución de la fórmulas de estimación hacer sus propias mediciones sobre: PF (Puntos de Función) TLDC (Total de Líneas de Código) Esfuerzo (E), Tiempo Planeación

3 CONTENIDO DE LA PRESENTACIÓN
Un panorama general de lo que es la medida sus características y dominio Métricas Orientadas al Tamaño Puntos de Función Derivación de otras métricas de estimación: TLCD y su valor de normalización Estimación del Esfuerzo Estimación de la Planificación

4 ¿Q U É E S UNA M E D I D A?

5 ¿QUÉ ES UNA MEDIDA? 1 2 3 4 5 Una Medida es un indicador cuantitativo de extensión, cantidad, dimensión, capacidad o tamaño de un proceso o producto . Las Medidas sirven para recoger datos métricos que nos proporcionen indicadores para analizar y determinar la calidad, la productividad y el tamaño en el desarrollo de un software. 1 2 3 4 5

6 ATRIBUTOS DE LAS MEDIDAS
En los proyectos: Ofrecen Visibilidad del Estado. Permite ver el progreso y avance del proyecto. Seguir pistas de riesgos potenciales Detectar áreas problemáticas del proceso Ajustar flujos de tareas o actividades Evaluar las habilidades del grupo de trabajo

7 ATRIBUTOS DE LAS MEDIDAS
Mejora la Moral del Grupo de trabajo. Al ser detectados los problemas crónicos les permite una mejor visión y entendimiento de lo que esta pasando, para poder solucionarlos. Define Expectativas más Realistas. Permite al desarrollador el conocimiento del alcance del proyecto y permite una mejor comunicación con el cliente sobre las necesidades y prestaciones del producto y de los avances y la terminación. Mejora el Proceso a Largo Plazo. Permite la comparación con proyectos anteriores y posteriores, y la operatividad de los métodos de medición que puedan ser adaptados por los desarrolladores y la organización.

8 En los procesos: En el software:
ATRIBUTOS DE LAS MEDIDAS En los procesos: Organización de Ingeniería de Software Visión detallada de la eficacia de un proyecto Evaluación de la funcionalidad de los gestores En el software: Permite una evaluación de los modelos de análisis y diseño Proporciona indicadores de complejidad de procedimientos en el diseño y código fuente Ayuda a la realización de pruebas más efectivas en el diseño

9 TRES CLAVES PARA DETERMINAR LAS MEDIDAS
Detectar la necesidad de lo que se quiere medir. ¿Cómo voy a mejorar proyectos y productos? DEFINIR OBJETIVO HACER PREGUNTAS ESTABLECER MÉTRICAS Hacer preguntas de qué tipos de problemas voy a resolver con relación al objetivo. Definir las métricas que se ajusten a esas preguntas para cumplir los objetivos

10 LAS MEDIDAS REQUIEREN DE CONOCIMIENTOS Y HABILIDADES ESPECIALIZADAS
Planificación de software y métodos de estimación Métodos de ingeniería y gestión de proyectos Estadística y análisis multivariante

11 LAS MEDIDAS REQUIEREN DE CONOCIMIENTOS Y HABILIDADES ESPECIALIZADAS
Métodos de control de calidad Diseño de informes Métodos estándares de comprobación Principios de contabilidad

12 ENTORNO DE MEDICIÓN DEL SOFTWARE
PRODUCTO Mercado Competitivo Organización (Solución de Negocio) Características del Cliente PROCESO PERSONAS TECNOLOGIA Entorno de Desarrollo Sistemas de Información

13 ? + + + = + + + = DOMINIO DE LAS MÉTRICAS DE SOFTWARE SOFTWARE
PROYECTO PROCESO ? ESFUERZO Pero, ¿Cómo determinamos y comparamos el esfuerzo entre dos grupos si no conocemos el tamaño? + + + = + + + =

14 Métricas Orientadas al Tamaño

15 MÉTRICAS ORIENTADAS AL TAMAÑO (Directa)
Se derivan de la normalización de las medidas de calidad y productividad con base al tamaño del software desarrollado con anterioridad Nombre del proyecto No. de líneas de de código (LDC) Esfuerzo (persona-mes) Costo Errores durante el desarrollo Errores en el uso del producto Personas participantes Ciclo de Vida de un Proyecto

16 LCD COMO VALOR DE NORMALIZACIÓN
MÉTRICAS ORIENTADAS AL TAMAÑO LCD COMO VALOR DE NORMALIZACIÓN Las líneas de código (LCD) es un valor de normalización que permite hacer comparaciones entre distintos proyectos Errores / Miles de LCD Defectos / Miles de LCD Costo / Miles de LCD Páginas de Documentación / Miles de LCD Esfuerzo / Miles de LCD Errores / Esfuerzo Costo / Páginas de documentación Otros elementos

17 Software Desarrollado con anterioridad (experiencia)
MÉTRICAS ORIENTADAS AL TAMAÑO Software Desarrollado con anterioridad (experiencia) Errores x Miles de LCD Miles de Lineas Código, utilizadas como clave de entrada

18 MÉTRICAS ORIENTADAS AL TAMAÑO
A Favor y en Contra La mayoría de los modelos de estimación de software utilizan las LCD como clave de entrada Existe un amplio conjunto de datos y literatura que utilizan la LDC En base a las LCD se pueden hacer fácilmente otras estimaciones Las LCD son dependientes del lenguaje de programación. Perjudican a los programas más cortos No incorpora fácilmente lenguajes procedimentales Requiere un nivel de detalle difícil de alcanzar

19 Las propuestas de medidas deben ser aceptadas por los jefes
MÉTRICAS ORIENTADAS AL TAMAÑO Las propuestas de medidas deben ser aceptadas por los jefes Puntos de Función Puntos de Función Medida z Medida x Medida a JEFE GRUPO DE TRABAJO

20 PUNTOS DE FUNCIÓN

21 PUNTOS DE FUNCIÓN (indirecta)
MÉTRICAS ORIENTADAS AL TAMAÑO PUNTOS DE FUNCIÓN (indirecta) ¿Qué son? Los Puntos de Función, llamados así por vez primera por Albertch, A.J, son métricas orientadas a la función como un valor de normalización Definición Los Puntos de Función, son una forma sintética o alternativa para medir el tamaño de un software. Utilización Los Puntos de Función, se utilizan en los primeros estadios del desarrollo de un software, independientemente de la metodología utilizada, que se determina a partir de las especificaciones de los requerimientos de la etapa de análisis que sirven de fundamento para la etapa de diseño.

22 Metodología de análisis de requerimiento
MÉTRICAS ORIENTADAS AL TAMAÑO ET APA DE AN ALIS IS Por lo tanto los Puntos de Función proporcionan una visión interna a la calidad de los modelos de análisis Para una buena estimación es necesario un buen análisis y compresión de cada una de las prestaciones del producto, mediante una gestión de los requerimientos: Metodología de análisis de requerimiento Método para crear modelos de sistemas Métodos de comunicación

23 Análisis de Requerimiento
MÉTRICAS ORIENTADAS AL TAMAÑO FASES DE REQUERIMIENTOS Concepto del Producto Análisis de Requerimiento Buena comunicación con el usuario Las especificaciones deben ser completas Reducir al mínimo las modificaciones en cuanto a los requerimientos y especificaciones posteriores Diseño Preliminar Diseño Detallado Código

24 Dominio de la Información y Evaluaciones de Complejidad
MÉTRICAS ORIENTADAS AL TAMAÑO COMO SE DETERMINAN LOS PUNTOS DE FUNCION Se deriva de una relación empírica de acuerdo a medidas que sí son contables de forma directa Dominio de la Información y Evaluaciones de Complejidad

25 CRACTERÍSTICAS DEL DOMINIO DE INFORMACIÓN
MÉTRICAS ORIENTADAS AL TAMAÑO CRACTERÍSTICAS DEL DOMINIO DE INFORMACIÓN Número de Entradas de Usuario: que proporciona diferentes datos orientados a la aplicación (no considera peticiones). Número de Salidas de Usuario: que proporciona información orientada a la aplicación (informes, pantallas, mensajes de error, etc.) Número de Peticiones de Usuario: que es una entrada interactiva que produce alguna respuesta del software inmediata en forma de salida interactiva Número de Archivos Lógicos: que pueden ser parte de una gran base de datos o archivos independientes. Número de Interfaces Externas: flujos legibles por la máquina (archivos de datos de cinta o de disco) que transfieren información desde o hacia otros sistemas.

26 Un Ejemplo Gráfico de Definición de las Características de Dominio
MÉTRICAS ORIENTADAS AL TAMAÑO Un Ejemplo Gráfico de Definición de las Características de Dominio

27 MÉTRICAS ORIENTADAS AL TAMAÑO
DEFINIR el Valor de Complejidad para cada uno de los dominios de información SIMPLE MEDIO COMPLEJO DEFINIR la fórmula para calcular los Puntos de Función con relación a la complejidad para cada dominio de información PFA = PF x [ 0, ,01 x S Fi ]

28 El total de los puntos de función sin ajustar
MÉTRICAS ORIENTADAS AL TAMAÑO Significados de los elementos de la fórmula MULTIPLICADOR Puntos de Función Ajustados (de acuerdo a las 5 características de dominio de la información) Es un multiplicador estandarizado de influencia cuyo intervalo es de 0,65 a 1,35 PFA = PF x [ 0, ,01 x S Fi ] Valores de ajuste de complejidad según la respuesta a 14 preguntas en una escala de 0 a 5 El total de los puntos de función sin ajustar

29 PF = Cuenta Total x [ 0,65 + 0,01 x S Fi ]
MÉTRICAS ORIENTADAS AL TAMAÑO Sustitución gráfica de la fórmula de Puntos de Función PF = Cuenta Total x [ 0, ,01 x S Fi ]

30 Dominio de Información
MÉTRICAS ORIENTADAS AL TAMAÑO Resultado Gráfico de Puntos de Función 349,6 Dominio de Información PF ajustados Multiplicador estandarizado Valores de ajuste de complejidad

31 DERIVACIÓN DE OTRAS MÉTRICAS DE ESTIMACIÓN

32 ESTIMACIÓN DE LOS LDC A PARTIR DE LOS PF
MÉTRICAS ORIENTADAS AL TAMAÑO ESTIMACIÓN DE LOS LDC A PARTIR DE LOS PF PUNTOS DE FUNCIÓN TESIS: La cantidad de puntos de función proporcionada por el programa, puede ser estimada por la descomposición de los principales componentes de datos que usa el programa, relacionada con el total de LDC y con el esfuerzo de desarrollo necesario. LDC Lenguaje de Programación que se utiliza para implementar el software y la calidad del diseño.

33 MÉTRICAS ORIENTADAS AL TAMAÑO
Estimación de las LDC requerida para cada Punto de Función de acuerdo al número medio LDC de un lenguaje de programación determinado FÓRMULA: TLDC Número Medio de LDC de un Lenguaje de Programación “x” PF ajustados X = EJEMPLO: 24472 70 (Lenguaje de Programación ADA) 349,6 = X

34 = X Presentación Gráfica de la Estimación de las LDC 24,472 70 349,6
MÉTRICAS ORIENTADAS AL TAMAÑO Presentación Gráfica de la Estimación de las LDC = 24,472 70 X 349,6 349,6

35 ESTIMACIÓN DEL ESFUERZO
La Estimación del Esfuerzo nos determina el número de personas que hay que incorporar al proyecto Utilización de estimaciones a partir del tamaño Utilización de estimación a partir del tamaño en LDC Utilización de datos anteriores de las organizaciones Utilización del método algorítmico de aproximación (COCOMO)

36 = = a b E (LDC) 69 = hombre/mes 2,4 (24,472) FORMULA: 1,5 EJEMPLO: b
ESTIMACIÓN DEL ESFUERZO = a b b E (LDC) FORMULA: = 1,5 69 = hombre/mes 2,4 (24,472) EJEMPLO:

37 = = = c d (E) 2,5 (69) 69 / 12,5 12,5 meses ESTIMACIÓN DEL TIEMPO
b = c b (TDEV) Duración en Meses (E) FORMULA: = 0,38 EJEMPLO: 12,5 meses 2,5 (69) = 69 / 12,5 ´N° Medio de Empleados 5.5

38 ESTIMACIÓN DE LA PLANIFICACIÓN A PARTIR DE LOS PF
x = P (PF ajustados) FORMULA: 0,42 = EJEMPLO: 11,7 meses. ( 349,6)

39 C O N C L U S I O N E S Los errores / PF Defectos / PF $ / PF
Los PF se aplican a cualquier sistema de información A partir de los PF se pueden derivar métricas de calidad de software como las métricas de productividad línea base (ayudan a controlar los cambio en el dominio de un proyecto). Se puede calcular: Los errores / PF Defectos / PF $ / PF Ppductividad / PF Persona Mes / PF

40 Que a partir de los PF se puede calcular:
C O N C L U S I O N E S Que a partir de los PF se puede calcular: La planeación, El número de LDC dependientes de un leguaje de programación A parir de las LDC se puede calcular es esfuerzo, A partir de la LDC la duración o tiempo de desarrollo

41 C O N C L U S I O N E S A partir de los cálculos derivados de los Puntos de Función, ya es posible hacer comparaciones de productividad entre dos o más proyectos, dado que se conoce el tamaño A parir de los PF de deriva una extensión llamada Puntos de Característica para dimensionar funcionalidad y comportamiento para sistemas de ingeniería y empotrados (alta complejidad de algoritmos). Nos permite determinar los riesgos de un proyecto que están directamente relacionados proporcionalmente al tamaño.

42 BIBLIOGRAFÍA Básica: Desarrollo y Gestión de Proyectos Informáticos. Steve McConnell. Ed. McGraw Hill. Cap. 8, 26 y 31. Ingeniería de Software , un Enfoque Práctico. Roger S. Presmann. Ed. McGraw Hill. Ap. 4,5, 9, y 18. Estimación de Proyectos Software. Documentación de Planificación e Ingeniería del Sodtware. Facultad de Informática-UPM. Departamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software,

43 BIBLIOGRAFIA Complementaria: Análisis y Diseño de Sistemas de Información. J. SENN. Ed. McGraw Hill. Cap. 14. Programación Orientada a Objetos. Luis Joyanes Aguilar. McGraw Hill. Cap. 7.