El documento introduce conceptos clave sobre métricas técnicas de software, incluyendo factores de calidad como los definidos por McCall, ISO 9126 y FURPS. Explica que las métricas miden atributos internos del software como modularidad y dependencia funcional para indicar la calidad.

1. M é tricas Técnicas del Software

2. Introducción Se aplica las métricas para valorar la calidad de los productos de ingeniería o los sistemas que se construyen. Proporcionan una manera sistemática de valorar la calidad basándose en un conjunto de reglas claramente definidas. Se aplican a todo el ciclo de vida permitiendo descubrir y corregir problemas potenciales.

3. Calidad del Software Los requisitos del Software son la base de las medidas de calidad. La falta de concordancia con los requisitos es una falta de calidad. Unos estándares específicos definen un conjunto de criterios de desarrollo que guían la manera en que se hace la ingeniería del Software. Si no se siguen los criterios , habrá seguramente poca calidad. Existe un conjunto de requisitos implícitos que ha menudo no se nombran. Si el software cumple con sus requisitos explícitos pero falla en los implícitos , la calidad del software no será fiable.

4. Factores de calidad de McCall Los factores que afectan la calidad se pueden categorizar en: Factores que se pueden medir directamente, como por ejemplo los defectos por punto de función. Factores que se pueden medir sólo indirectamente, como por ejemplo la facilidad de uso o mantenimiento. En todos los casos debe aparecer la medición. Debe ser posible comparar el software (documentos, programas, datos) con una referencia y llegar a una conclusión sobre la calidad.

5. Factores de calidad McCall y colegas (1997) Revisión del Producto Transición del producto Operación del producto Corrección Fiabilidad Usabilidad Integridad Eficiencia Facilidad de mantenimiento Flexibilidad Facilidad de prueba Portabilidad Reusabilidad Interoperatividad

6. Operación del Producto Corrección : Hasta donde satisface un programa su especificación y logra los objetivos del cliente. Fiabilidad: Hasta dónde se puede esperar que un programa lleve a cabo de su función con la exactitud requerida. Eficiencia: La cantidad de recursos informáticos y de código necesarios para que un programa realice su función.

7. Integridad: Hasta dónde se puede controlar el acceso al software o a los datos por personas no autorizadas. Usabilidad (facilidad de manejo):El esfuerzo necesario para aprender a operar los datos de entrada e interpretar las salidas de un programa.

8. Revisión del producto Facilidad de mantenimiento: El esfuerzo necesario para localizar y arreglar un error en un programa. Flexibilidad: El esfuerzo necesario para modificar un programa operativo. Facilidad de prueba: El esfuerzo necesario para probar un programa para asegurarse de que realiza su función pretendida.

9. Transición del producto Portabilidad: El esfuerzo necesario para transferir el programa de un entorno de sistema hardware y/o software a otro entorno diferente. Reusabilidad ( capacidad de reutilización): Hasta donde se puede volver a emplear un programa ( o partes de un programa) en otras aplicaciones. Interoperatividad: El esfuerzo necesario para acoplar un sistema con otro.

10. Es difícil desarrollar medidas directas de los factores de calidad señalados anteriormente, por consiguiente se definen un conjunto de métricas para desarrollar expresiones que utilicen los factores de acuerdo a la siguiente relación: F q = c 1 x m 1 + c 2 x m 2 +….+c n x m n F q es factor de calidad C n son coeficientes de regresión M n son las métricas que afectan al factor calidad

11. Lamentablemente muchas de las métricas definidas por McCall solamente pueden medirse de manera subjetiva. Las métricas se acomodan en una lista de comprobación que se emplea para puntuar atributos específicos del software. El esquema de puntuación que se propone es una escala del 0 (bajo) al 10 (alto)

12. Métrica para el esquema de puntuación: Facilidad de auditoría: la facilidad con la que se puede comprobar el cumplimiento de los estándares. Exactitud : la exactitud de lo cálculos y el control. Estandarización de comunicaciones : el grado de empleo de estándares de interfaces, protocolos y anchos de banda. Complección: el grado con que se ha logrado la implementación total de una función. Concisión : Lo compacto que es el programa en términos de líneas de código

13. Consistencia: El empleo de un diseño uniforme y de técnicas de documentación a lo largo del proyecto de desarrollo del software. Estandarización de datos: El empleo de estructuras y tipos de datos estándares a lo largo del programa. Tolerancia al error : el daño causado cuando un programa encuentra un error. Eficiencia de ejecución: El rendimiento del funcionamiento de un programa. Capacidad de expansión: El grado con que se pueden ampliar el diseño arquitectónico, de datos o procedimental. Generalidad: la amplitud de aplicación potencial de los componentes del programa. Independencia del hardware: El grado con que se desacopla el software del hardware donde opera.

14. Instrumentación: El grado con el que el programa vigila su propio funcionamiento e identifica los errores que ocurren. Modularidad : La independencia funcional de componentes de programa. Operatividad: La facilidad de operación de un programa. Seguridad: La disponibilidad de mecanismos que controlan o protegen los programas y los datos. Autodocumentación : El grado en que el código fuente proporciona documentación significativa. Simplicidad: El grado de facilidad con que se puede entender un programa.

15. Independencia del sistema de software: El grado de independencia de programa respecto a las características del lenguaje de programación no estándar , características del sistema operativo y otras restricciones del entorno. Trazabilidad : La capacidad de seguir una representación del diseño o un componente real del programa hasta los requisitos. Formación : El grado en que ayuda el software a manejar el sistema a los nuevos usuarios.

16. FURPS (Funcionality, Usability, Reliability, Performance, Supportability) Hewlett Packard ha desarrollado un conjunto de factores de calidad del software al que se le ha dado el acrónimo de FURPS: funcionalidad, facilidad de empleo, fiabilidad, rendimiento y capacidad de soporte. Los factores de calidad son cinco y se definen de acuerdo al siguiente conjunto de atributos: Funcionalidad. Se valora evaluando el conjunto de características y capacidades del programa, la generalidad de las funciones entregadas y la seguridad del sistema global. Facilidad de uso . Se valora considerando factores humanos, la estetica, consistencia y documentación general.

17. Fiabilidad . Se evalúa midiendo la frecuencia y gravedad de los fallos, la exactitud de las salidas, el tiempo medio entre fallos, la capacidad de recuperación de un fallo y la capacidad de predicción del programa. Rendimiento . Se mide por la velocidad de procesamiento, el tiempo de respuesta, consumo de recursos, rendimiento efectivo total y eficacia. Capacidad de soporte . Combina la capacidad de ampliar el programa (extensibilidad), adaptabilidad y servicios, así como la capacidad de hacer pruebas, compatibilidad, capacidad de configuración, la facilidad de instalación de un sistema y la facilidad con que se pueden localizar los problemas

18. Factores de Calidad ISO 9126 El estándar identifica seis atributos clave de calidad: Funcionalidad : El grado en que el software satisface las necesidades indicadas por los siguientes subatributos: idoneidad, corrección, interoperatividad,conformidad y seguridad. Confiabilidad: Cantidad de tiempo que el software está disponible para su uso. Estaá referido por los siguientes subatributos: madurez, tolerancia a fallos y facilidad de recuperación.

19. Usabilidad: Grado en que el software es fácil de usar. Viene reflejado por los siguientes subatributos: facilidad de comprensión, facilidad de aprendizaje y operatividad. Eficiencia : Grado en que el software hace óptimo el uso de los recursos del sistema. Viene reflejado por los siguientes subatributos: tiempo de uso y recursos utilizados. Facilidad de mantenimiento: La facilidad con que una modificación puede ser realizada. Está indicada por los siguientes subatributos: facilidad de análisis , facilidad de cambio, estabilidad y facilidad de prueba. Portabilidad: La facilidad con que el software puede ser llevado de un entorno a otro. Está referido por los siguientes subatributos: facilidad de instalación, facilidad de ajuste, facilidad de adaptación al cambio

20. Paradoja de Jacob Bronkowski “ Año tras año ingeniamos instrumentos más exactos con los que observar la naturaleza con mas exactitud. Y cuando miramos las observaciones estamos desconcertados de ver que todavís son confusas y tenemos la sensación de que son tan inciertas como siempre”

21. Estructura para las métricas del Software La medición asigna números o símbolos a atributos de entidades en el mundo real. Para conseguirlo es necesario un modelo de medición que comprenda un conjunto consistente de reglas. Existe la necesidad de medir y controlar la complejidad del software, es bastante difícil obtener un solo valor para representar una "métrica de calidad", sin embargo es posible desarrollar medidas de diferentes atributos internos del programa como ser: modularidad efectiva, independencia funcional y otros atributos. Estas métricas y medidas obtenidas pueden utilizarse como indicadores independientes de la calidad de los modelos de análisis y diseño.

22. Los principios básicos de la medición, sugeridos por Roche, pueden caracterizarse mediante cinco actividades: Formulación. Obtención de medidas y métricas del software apropiadas para la representación del software en cuestión. Colección. Mecanismo empleado para acumular datos necesarios para obtener 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 los resultados de las métricas en un esfuerzo por conseguir una visión interna de la calidad de la representación. Realimentación. Recomendaciones obtenidas de la interpretación de métricas técnicas transmitidas al equipo software.

23. Ejiogu define un conjunto de atributos que deberían acompañar a las métricas efectivas del software. La métrica obtenida y las medidas que conducen a ello deberían ser: Simple y fácil de calcular. Empírica e intuitivamente persuasiva. Consistente y objetiva. Consistente en el empleo de unidades y tamaños. Independiente del lenguaje de programación. Un eficaz mecanismo para la realimentación de calidad.

24. La experiencia indica que una métrica técnica se usa únicamente si es intuitiva y fácil de calcular. Si se requiere docenas de contadores y se han de utilizar complejos cálculos, la métrica no será ampliamente utilizada.

25. Métricas del Modelo de Análisis En esta fase es deseable que las métricas técnicas proporcionen una visión interna a la calidad del modelo de análisis. Estas métricas examinan el modelo de análisis con la intención de predecir el "tamaño" del sistema resultante; es probable que el tamaño y la complejidad del diseño estén directamente relacionadas.

26. Métricas basadas en la Función La métrica del punto de función (PF) se puede utilizar como medio para predecir el tamaño de un sistema obtenido a partir de un modelo de análisis. Para visualizar esta métrica se utiliza un diagrama de flujo de datos, el cual se evaluar para determinar las siguientes medidas clave que son necesarias para el cálculo de la métrica de punto de función: Número de entradas del usuario Número de salidas del usuario Número de consultas del usuario Número de archivos Número de interfaces externas

27. La cuenta total debe ajustarse utilizando la siguiente ecuación: PF = cuenta-total x (0,65 + 0,01 x  Fi) Donde cuenta-total es la suma de todas las entradas PF obtenidas de la figura 9.2 y Fi (i=1 a 14) son los "valores de ajuste de complejidad".

28. Para el ejemplo descrito en la figura 9.2 se asume que la  Fi es 46 (un producto moderadamente complejo), por consiguiente: PF = 50 x (0,65 + 0,01 x 46) = 56 Fig. 9.2 Cálculo de puntos de función 50 Cuenta total 20 = 10 7 5 X 4 Número de interfaces externas 7 = 15 10 7 X 1 Número de archivos 6 = 6 4 3 X 2 Número de consultas del usuario 8 = 7 5 4 X 2 Número de salidas del usuario 9 = 6 4 3 X 3 Número de entradas del usuario Compl. Media Simple Cuenta Parámetro de medición Factor de ponderación

29. Basándose en el valor previsto del PF obtenido del modelo de análisis, el equipo del proyecto puede estimar el tamaño global de implementación de las funciones de interacción. Asuma que los datos de los que se dispone indican que un PF supone 60 líneas de código (se utilizará un lenguaje orientado a objetos) y que en un esfuerzo de un mes-persona se producen 12 PF. Estos datos históricos proporcionan al gestor del proyecto una importante información de planificación basada en el modelo de análisis en lugar de estimaciones preliminares

30. Otras M étricas para el Modelo de Análisis La Métrica Bang [De Marco] Puede aplicarse para desarrollar una indicación del tamaño del software a implementar como consecuencia del modelo del análisis. Métricas de la calidad de la especificación: Davis y colegas 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

31. Métricas del modelo de Diseño La gran ironía de las métricas de diseño para el software es que las mismas están disponibles, pero la gran mayoría de los desarrolladores de software continúan sin saber que existen. No son perfectas y continúa el debate sobre su eficacia y como deberían aplicarse. Algunos expertos señalan que es necesario mayor experimentación hasta que se puedan emplear adecuadamente. Sin embargo el diseño sin medición es una alternativa inaceptable.

32. Métricas de diseño de alto nivel Se concentran en las características de la arquitectura del programa , con énfasis en la estructura arquitectónica y en la eficiencia de los módulos. Estas métricas son de caja negra en el sentido que no requieren ningún conocimiento del trabajo interno de un módulo en particular del sistema.

33. Card y Glass definen las siguientes tres medidas de complejidad La complejidad estructural, S(i), de un módulo i se define de la siguiente manera: S(i)=f 2 out (i). Donde f out (i) es la expansión del módulo i.La expansión indica el número de módulos que son invocados directamente por el módulo i.

34. La complejidad de datos, D(i), proporciona una indicación de la complejidad en la interfaz interna de un módulo i y se define como: D(i)=v(i)/[f out (i) + 1]. Donde v(i) es el número de variables de entrada y salida que entran y salen del módulo i.

35. La complejidad del sistema, C(i), se define como la suma de las complejidades estructural y de datos : C(i)= S(i) + D(i) A medida que crecen los valores de complejidad , la complejidad arquitectónica o global del sistema también aumenta. Esto lleva a una mayor probabilidad de que aumente el esfuerzo necesario para la integración y las pruebas.

36. Fenton sugiere varias métricas de morfología simples que permiten comparar diferentes arquitecturas mediante un conjunto de dimensiones directas.

37. Tamaño= n + a . Donde n es el número de nodos (módulos) y a es el número de arcos (líneas de control). Para la arquitectura mostrada se tiene tamaño= 17+18=35. Profundidad= camino más largo desde el nodo raíz a un nodo hoja. Para el ejemplo Profundidad= 4 Amplitud=número máximo de nodos de cualquier nivel de la arquitectura. Para el ejemplo amplitud= 6 Métricas a aplicar

38. Relación arco a nodo, r=a/n, mide la densidad de conectividad de la arquitectura y proporciona una indicación sencilla de acoplamiento de la arquitectura. Para el ejemplo r=18/17= 1.06

39. Métricas del Código Fuente La teoría de la ciencia del software propuesta por Halstead es probablemente la medida de complejidad mejor conocida y minuciosamente estudiada. La ciencia del software propuso la primera ley analítica y cuantitativa para el software de computadora. Utiliza un conjunto de medidas primitivas que pueden obtenerse una vez que se han generado o estimado el código después de completar el diseño.

40. Estas medidas son: n 1: número de operadores diferentes que aparecen en le programa. n 2 : número de operandos diferentes que aparecen en el programa. N 1 : número total de veces que aparece el operador. N 2 : número total de veces que aparecen el operando.

41. Halstead utiliza medidas primitivas para desarrollar expresiones par 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 el esfuerzo de desarrollo,,tiempo de desarrollo e incluso el número esperado de fallos en el software.

42. Halstead propone las siguientes métricas: Longitud N se puede estimar como: N = n 1 log 2 n 1 + n 2 log 2 n 2 . Volumen de programa se define como: V = N n 1 log 2 (n 1 + n 2 ). Tomando 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.

43. Ejemplo: Programa de ordenación por intercambio END RETURN CONTINUE 20 CONTINUE 10 X(J) = SAVE X(I) = X(J) SAVE = X(I) IF (X(I) .GE. X(J)) GO TO 10 DO 10 J=1, I DO 20 I=2, N IF (N .LT. 2) RETURN DIMENSION X(N) SUBROUTINE SORT(X,N)

44. De esta tabla se desprenden los valores de n 1 =10 y N 1 =28. 28 Total 1 GO TO 10 10 1 .GE. 9 1 .LT. 8 1 Fin de programa 7 2 , 6 2 DO 5 2 IF() 4 5 = 3 6 Subíndices de arreglos 2 7 Fin de sentencia 1 Cuenta Operador

45. De esta tabla se desprenden los valores de n 2 =7 y N 2 =22. 22 Total 1 1 7 2 SAVE 6 2 2 5 2 N 4 4 J 3 5 I 2 6 X 1 Cuenta Operando

46. M é tricas para las Pruebas La mayoría de las métricas para pruebas se concentran en el proceso de prueba, no en las características técnicas de las pruebas mismas. En general, los responsables de las pruebas deben fiarse en las métricas de análisis, diseño y código para que sirvan de guía en el diseño y ejecución de los casos de prueba. El esfuerzo de las pruebas también se puede estimar utilizando métricas obtenidas de las medidas de Halstead. Usando la definición del volumen de un programa, V, y nivel de programa, NP, el esfuerzo de la ciencia del software puede calcularse como: NP = 1/[(n1/2) x (N2/n2)] (Ec. 9.1) e = V/NP (Ec. 9.2)

47. El porcentaje del esfuerzo global de pruebas a asignar a un módulo k se puede estimar utilizando la siguiente relación: Porcentaje de esfuerzo de pruebas(k) = e(k)/  e(i) (Ec. 9.3) Donde e(k) se calcula para el módulo k utilizando las ecuaciones (Ec. 9.1) y (Ec. 9.2), la suma en el denominador de la ecuación (Ec. 9.3) es la suma del esfuerzo de la ciencia del software a lo largo de todos los módulos del sistema.

48. A medida que se van haciendo las pruebas, tres medidas diferentes proporcionan una indicación de la compleción de las pruebas: Medida de amplitud de las pruebas. Proporciona una indicación de cuantos requisitos se han probado del numero total de ellos. Indica la compleción del plan de pruebas. Profundidad de las pruebas. Medida del porcentaje de los caminos básicos independientes probados con relación al número total de estos caminos en el programa. Se puede calcular una estimación razonablemente exacta del número de caminos básicos sumando la complejidad ciclomática de todos los módulos del programa. Perfiles de fallos. Se emplean para dar prioridad y categorizar los errores. La prioridad indica la severidad del problema. Las categorías de los fallos proporcionan una descripción de un error, de manera que se puedan llevar a cabo análisis estadístico de errores.

49. MÉTRICAS DEL MANTENIMIENTO Todas las métricas descritas pueden utilizarse para el desarrollo de nuevo software y para el mantenimiento del existente. El estándar IEEE 982.1-1988 sugiere el í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. Con el IMS se determina la siguiente información: MT= Número de módulos en la versión actualFc= Número de módulos en la versión actual que se han cambiado Fa= Número de módulos en la versión actual que se han añadido Fe= Número de módulos en la versión actual que se han eliminado

50. El índice de madurez del software se calcula de la siguiente manera: IMS= [MT - (Fc + Fa + Fe)]/MT A medida que el IMS se aproxima a 1 el producto se empieza a estabilizar. El IMS puede emplearse también como métrica para la planificación de las actividades de mantenimiento del software.

51. Medición y métricas de Software [Sommerville]cap.24 La medición del software se refiere a derivar a un valor numérico para algún atributo de un producto de software o un proceso de software. Comparando estos valores entre ellos y con los estándares aplicados en la organización, es posible sacar conclusiones de la calidad del software o de los procesos del software. Sin embargo , aún es poco común la utilización de medidas y métricas sistemáticas de software. La reticencia al uso es debido a que los beneficios noson claros.

52. Por otra parte no existen estándares para las métricas y, por lo tanto existe ayuda limitada para la recolección y análisis de datos. Las métricas son de control o de predicción: Control: por lo general se asocian con los procesos del software. Ejemplo, el esfuerzo y el tiempo promedio requerido para reparar los defectos reportados. Predicción : se asocian con los productos del software. Ejemplo, la complejidad ciclomática de un módulo, la longitud promedio de los indicadores en un programa y el número de atributos y operaciones asociadas con los objetos de un diseño.

53. Toma de decisiones administrativas Proceso de Software Medidas de Control Decisiones administrativas Producto de software Medidas de predicción Ambas métricas influyen en la toma de decisiones administrativas

54. Métricas para predecir la calidad A menudo es imposible medir los atributos de calidad del software en forma directa. Los atributos como la complejidad , la mantenibilidad y la comprensión se ven afectados por diversos factores y no existen métricas directas para ellos. Más bien es necesario medir un atributo interno del software ( como el tamaño) y suponer que existe una relación entre lo que se puede medir y lo que se quiere saber. De forma ideal , existe una relación clara válida entre los atributos de software internos y externos.

55. Relación entre los atributos externos e internos Mantenibilidad Fiabilidad Portabilidad Usabilidad Número de parámetros del procedimiento Complejidad ciclomática Tamaño del programa en líneas de código Número de mensajes de error Extensión del manual de usuario No dice qué relación es

56. Métricas del producto Se refiere a las características del software. En general las organizaciones construyen sus bases de datos históricas para relacionar las mediciones obtenidas. Se dividen en dos clases: Métricas dinámicas recolectadas por las mediciones hechas en un programa en ejecución. Las métricas estáticas recolectadas por las mediciones hechas en las representaciones del sistema como el diseño, el programa o la documentación.

57. Estas diferentes métricas están relacionadas con diversos atributos de calidad. Las métricas dinámicas ayudan a a valorar la eficiencia y la fiabilidad de un programa mientras que las métricas estáticas ayudan a valorar la complejidad, la comprensión y la mantenibilidad de un sistema de software. Las métricas estáticas , por otro lado, tienen una relación indirecta con los atributos de calidad. Las métricas específicas relevantes dependen del proyecto, de las metas del equipo de administración de la calidad y del tipo de software a desarrollar.

58. Medición del proceso cap. 25 Son datos cuantitativos de los procesos del software. Se utilizan para evaluar si la eficiencia de un proceso ha mejorado. Por ejemplo se puede medir el esfuerzo y tiempo dedicado a las pruebas. Las mejoras efectivas para los procesos de prueba reducen el esfuerzo , el tiempo de prueba o ambos.

59. Se pueden recolectar tres clases de métricas del proceso: El tiempo requerido para completar un proceso particular: Tiempo total dedicado al proceso, el tiempo de calendario, el tiempo invertido en el proceso por ingenieros particulares, etc. Los recursos requeridos para un proceso en particular: Los recursos pueden ser el esfuerzo total en personas-días, los costos de viajes, los recursos de cómputo,etc.

60. El número de ocurrencias de un evento en particular: Ejemplos de eventos que se pueden supervisar son el número de defectos descubiertos durante la inspección del código, el número de peticiones de cambios en los requerimientos, el número promedio de líneas de código modificadas en respuesta a un cambio de requerimientos, etc.

61. Estimaci ó n del Costo del Software Cap. 23 La estimación y calendarización del proyecto se llevan a cabo de forma conjunta. Sin embargo se debe contar con estimaciones previas para ver los efectos sobre la calendarización y éstas se actualizan de forma regular. Permite la utilización efectiva de los recursos y una adecuada planeación.

62. Parámetros involucrados en el costo total de un proyecto: Costos de hardware y software , incluyendo mantenimiento. Costos de viajes y capacitación Costos de esfuerzo ( pago a los ingenieros de Software) Para muchos proyectos , el costo dominante es el costo de esfuerzo.

63. Costos de esfuerzo: Costos de proveer, calentar e iluminar las oficinas. Costos del personal de apoyo como contadores , secretarias, limpiadores y técnicos. Costos de las redes y las comunicaciones. Costos de los recursos centralizados como bibliotecas, los recursos recreativos,etc. Costos de seguridad social y de beneficio de empleados como las pensiones y seguros de salud.

64. Factores que afectan la asignación de precios al software. Oportunidad de mercado: penetración de mercado con cotización de bajos costos al inicio. Incertidumbre: Si no hay seguridad en el costo estimado, por alguna contingencia puede incrementar su precio por encima del beneficio normal. Términos contractuales: Reducir el costo a partir de asumir restricciones como por ejemplo entrega del código fuente y que el desarrollador lo pueda reutilizar en otros proyectos.

65. Volatilidad de los requerimientos: Si es probable que los requerimientos cambien, podría reducirse los precios para ganar un contrato. Después del contrato se cargan precios altos a los cambios de requerimientos. Salud Financiera: Cuando los desarrolladores tienen dificultades financieras podrían bajar sus costos para ganar contratos. Esto es mejor que quedar fuera del negocio o quebrar

66. Productividad Cuando se produce soluciones con diferentes atributos, no tiene sentido comparar tasas de productividad, sin embargo las estimaciones son necesarias para las estimaciones del proyecto y para valorar si los procesos o las mejoras tecnológicas son efectivas. Por lo general estas estimaciones se basan en medir algunos atributos del software y dividir el resultado entre el esfuerzo total requerido para el desarrollo.

67. Medidas utilizadas: Relacionadas con el Tamaño: se relacionan con el tamaño de alguna salida de una actividad. La medida más común son las líneas de código fuente entregadas. También se utiliza el número de instrucciones de código objeto entregado o el número de páginas de la documentación del sistema

68. Medidas utilizadas: Relacionadas con la función: se relacionan con la funcionalidad total del software entregado. La productividad se expresa en términos de la cantidad de funcionalidad útil producida en un tiempo dado. Ejemplos de esta medidas son puntos de función y puntos de objetos .

69. (Un paréntesis ) Puntos de objetos : el número de puntos de objeto en un programa es una estimación de peso ( no son clases de objetos que se producen cuan se considera orientación objeto para el desarrollo del software): El número de pantallas independientes que se despliegan. Las pantallas sencillas cuentan como 1 punto de objeto, las moderadamente complejas cuentan como 2 y las muy complejas cuentan como 3 puntos de objeto. El número de informes que se producen, simples son 2 puntos de objeto, moderadamente complejos son 5 puntos de objeto y para informes que son difíciles de producir 8 puntos de objetos. El número de módulos 3GL que deben desarrollarse para complementar el código 4GL. Cada módulo 3GL cuenta como 10 puntos objetos

70. T écnicas de Estimación No existe una forma simple de hacer una estimaci ón precisa del esfuerzo requerido para desarrollar un sistema de software. Por lo general, las estimaciones de los costos del proyecto se cumplen por su propia naturaleza. A pesar de las dificultades e impresiones las organizaciones requieren hacer esfuerzos de software y estimaciones de costos.

71. Técnicas de estimaciones de costos Modelado del algoritmo de costos: Se desarrolla un modelo utilizando información histórica de costos que relaciona alguna métrica de software( por lo general su tamaño) con el costo del proyecto. Se hace una estimación de ésa métrica y el modelo predice el esfuerzo requerido. Opinión de expertos: Se consultan varios expertos en las técnicas de desarrollo de software propuestas y en el dominio de la aplicación. Cada uno de ellos estima el costo del proyecto. Estas estimaciones se comparan y discuten. El proceso de estimación se itera hasta que se acuerda una estimación.

72. Estimación por analogía: Esta técnica es aplicable cuando otros proyectos en el mismo dominio de aplicación se han completado. Se estima el costo de un nuevo proyecto por analogía con estos proyectos completados. Ley de Parkinson: Establece que el trabajo se extiende para llenar el tiempo disponible. El costo se determina por los recursos disponibles más que por los objetivos logrados. Si el software se tiene que entregar en 12 meses y se dispone de cinco personas, el esfuerzo requerido se estima en 60 personas-mes Técnicas de estimaciones de costos

73. Asignar precios para ganar: El costo del software se estima independientemente de lo que el cliente esté dispuesto a pagar por el proyecto. El esfuerzo estimado depende del presupuesto del cliente y no de la funcionalidad del software. Cada técnica de estimación tiene sus propias debilidades y fortalezas. Para proyectos grandes se deben aplicar varias técnicas de estimaciones de costos y comparar sus resultados. Estas técnicas de estimación son aplicables cuando existe un documento de requerimientos para el sistema. Técnicas de estimaciones de costos

74. Modelado algorítmico de costos Se construye analizando los costos y atributos de los proyectos realizados. Se utiliza una fórmula matemática para predecir los costos basados en estimaciones del tamaño del proyecto, número de programadores y otros factores de los procesos y productos. Kitchenham (1990) describe 13 modelos algoritmos de costos desarrollados a partir de observaciones empíricas.

75. Forma mas general para expresar una estimación algorítmica de costos: Esfuerzo = A x Tamaño B x M A es un factor constante que depende de las prácticas organizacionales locales y del tipo de software que se desarrolla. Tamaño es una valoración del tamaño del código del software o una estimación de la funcionalidad expresada en puntos de función o de objetos. El valor del exponente B por lo general se encuentra entre 1 y 1.5 y refleja el esfuerzo requerido para proyectos grandes . M es un multiplicador generado al combinar diferentes procesos , atributos del producto y del desarrollo

76. Dificultades comunes: Es difícil estimar Tamaño en una primera etapa de un proyecto donde solamente esta disponible la especificación. Las estimaciones de los factores B y M son subjetivas. Varía de una persona a otra según su experiencia y conocimiento.

77. Modelo COCOMO Modelo empírico Se obtuvo recolectando datos de varios proyectos de software grandes, y después analizando esos datos para descubrir fórmulas que se ajustarán mejor a las observaciones. Esta bien documentado, es de dominio público y lo apoyan herramientas comerciales. Se ha utilizado y evaluado ampliamente. Ha evolucionado del COCOMO 81( 1981) al COCOMO 2 (1995)

78. COCOMO Básico Proyectos complejos donde el software es parte de un complejo fuertemente acoplado de hardware, software, reglas y procedimientos operacionales. PM = 3.6 (KDSI) 1.20 x M Incrustada Proyectos más complejos donde los miembros del equipo tienen experiencia limitada en sistemas relacionados PM = 3.0 (KDSI) 1.12 x M Moderada Aplicaciones bien comprendidas desarrolladas por equipos pequeños PM = 2.4 (KDSI) 1.05 x M Simple Descripción Fórmula Complejidad del proyecto

79. El COCOMO 81 , primera versión del modelo COCOMO , fue un modelo de tres niveles donde éstos reflejaban el detalle del análisis de la estimación del costo. El primer nivel básico provee una estimación inicial burda. El segundo nivel la modifica utilizando varios multiplicadores del proyecto y del proceso, y El nivel más detallado produce estimaciones para las diferentes fases del proyecto

80. Evolución COCOMO COCOMO 81 supone que el software se desarrolla acorde a un proceso en cascada y que la mayoría del software se construye desde cero. Lo anterior hoy no es válido pues existe creación de software a partir de el ensamblado de componentes reutilizables vinculándolos a través de script (secuencia de comandos). Los modelos de procesos mas comúnmente utilizados hoy son el de prototipos y el incremental. Se utiliza la reingeniería para crear nuevos procesos La utilización de mejores herramientas como las CASE hacen mas dinámico el proceso de construcción. Todo lo anterior hace evolucionar al COCOMO 81 al actual modelo COCOMO 2

81. COCOMO 2 Considera diferentes enfoques para el desarrollo del software. Los niveles del modelo no reflejan simplemente estimaciones detallas con complejidad creciente. Los niveles se asocian a las actividades del proceso por lo que las estimaciones iniciales se llevan cabo al inicio del proceso y las estimaciones detalladas se llevan a cabo después del que se definió la arquitectura del sistema.

82. Niveles del COCOMO 2 Nivel de construcción de prototipo inicial: Las estimaciones de tamaño se basan en puntos de objeto y se utiliza un fórmula sencilla tamaño/productividad para estimar el esfuerzo requerido. Nivel de diseño inicial: Corresponde a la terminación de requerimientos del sistema con algún diseño inicial.. Las estimaciones se basan en puntos de función que se convierten a número de líneas de código fuente. Nivel postarquitectónico: Una vez que se diseña la arquitectura del sistema se hace una estimación razonablemente precisa del tamaño del software. En este nivel se utiliza un conjunto mas grande de multiplicadores que reflejan la capacidad del personal, el producto y las características del proyecto.

83. Nivel de construcción de prototipo inicial Permite la estimación del esfuerzo requerido en construcción de prototipos y para proyectos donde el software se desarrolla utilizando componentes existentes. Se basa en una estimación de los puntos de objetos de peso, la cual se divide en una cifra estándar de productividad estimada. La productividad del programador depende de la experiencia y capacidad del desarrollador y las características de las herramientas CASE. La reutilización es común , por lo que el número de puntos de objeto utilizados en la estimación del tiempo se ajusta para tomar en cuenta el porcentaje de reutilización que se espera.

84. Formula PM = ( NOP x (1 - %reutilización/100)) / PROD PM es el esfuerzo en personas-mes NOP es el número de puntos de objeto y PROD es la productividad Productividad de los Puntos de objeto 50 Muy Alta Muy Alta 25 13 7 4 PROD (NOP/mes) Alta Nominal Baja Muy Baja Madurez y capacidad CASE Alta Nominal Baja Muy Baja Experiencia y capacidad de los desarrolladores

85. El nivel de Diseño Inicial Las estimaciones se basan en fórmula estándar para modelos algorítmicos: Esfuerzo = A x Tamaño B x M A según Boehm (experimentación) es de 2.5 para las estimaciones hechas a este nivel. Tamaño se expresa en KSLOC, es decir, el número de miles de líneas de código fuente. KSLOC se calcula estimando el número de puntos de función en el software y convirtiendolo éste a KSLOC utilizando la tabla estándar que relacionan el tamaño del software a puntos de función para diferentes lenguajes de programación

86. El exponente B refleja el esfuerzo creciente requerido al incrementarse el tamaño del proyecto. Puede variar de 1.1 a 1.24 dependiendo de la novedad del proyecto, la flexibilidad del desarrollo , los procesos utilizados de resolución de riesgos, la cohesión del equipo de desarrollo y en nivel de madurez. M se basa en un conjunto de simplificado de 7 conductores de proyectos y procesos en los que se incluye la fiabilidad y complejidad del producto ( RCPX ), la reutilización requerida (RUSE), la dificultad de la plataforma ( PDIF ), la capacidad del personal ( PERS ), la experiencia del personal ( PREX ), la calendarización ( SCED ) y los recursos de apoyo ( FCIL ). Estos pueden estimarse en una escala de 1 a 6, 1 corresponde a un valor muy bajo y 6 a valores muy altos.

87. Formula del esfuerzo según los multiplicadores señalados: P = A x Tamaño B x M + PM m donde M = PERS x RCPX x RUSE x PDIF x FCIL x SCED. PM m es un factor que se utiliza cunado un porcentaje importante del código se genera de forma automática. PM m = (ASLOC x (AT / 100)) / ATPROD ASLOC número de líneas generadas automáticamente de código fuente. ATPROD es el nivel de productividad para este tipo de producción de código. AT porcentaje del código total del sistema que se genera automáticamente

88. El nivel postarquitect ó nico Las estimaciones se basan en la misma fórmula básica que se utiliza en las estimaciones iniciales del diseño. La estimación del tamaño para el software es mas precisa utilizando 17 atributos en lugar de 7 para refinar el cálculo del esfuerzo inicial. La estimación del número total de líneas de código fuente se ajusta para tomar en cuenta dos factores importantes del proyecto:

89. La volatilidad de los requerimientos: Se realiza un estimación de la revisión, que puede ser requerida para acomodar cambios en los requerimientos del sistema. Se expresa como el número de líneas de código fuente que se deben modificar y este número se suma a la estimación inicial del tamaño. Amplitud de la posible reutilización: Una reutilización amplia significa que se deben modificar el número de líneas de código fuente que realmente se desarrollarán. El costo no es lineal pues debido al esfuerzo inicial requerido para descubrir y seleccionar los componentes y debido al esfuerzo requerido para modificar y comprender los componentes reutilizables y sus interfaces.

90. Efecto de la reutilización en COCOMO 2 Se ajusta el tamaño del esfuerzo de acuerdo con la siguiente fórmula: ESLOC = ASLOC x ( AA+SU+0.4DM+ 0.3IM + 0,3CM)/100 ESLOC es el número equivalente de líneas de código nuevo. ASLOC es el número de líneas de código reutilizable que deben definirse. DM es el % de modificación del diseño CM es el % de código que se modifica IM es el % del esfuerzo original requerido para integrar el software reutilizado. SU es un factor que se basa en el costo de comprensión del software que varía desde 50 para código complejo no estructurado hasta 10 para código orientado al objeto bien escrito AA es un factor que refleja los costos de valoración inicial de la posible reutilización del software. Va desde 0 a 8. Depende de la cantidad de pruebas y evaluaciones requeridas.

91. Estimación del Exponente de la fórmula del Esfuerzo (B) Considera 5 factores de escala valorados desde muy bajo hasta extraalto(5 a0). Los valores resultantes se suman , se dividen entre 100 y al resultado se le suma 1.01 par dar ese exponente

92. Factores de escala utilizados en el cálculo del exponente del COCOMO 2 Refleja la amplitud del análisis de riesgo que se lleva a cabo . Muy bajo significa poco análisis; Extraalto significa un análisis de riesgo completo y detallado. Resolución de la arquitectura/riesgo Refleja el grado de flexibilidad en el proceso de desarrollo. Muy bajo significa que se utiliza un proceso prescrito; Extraalto significa que el cliente establece sólo metas generales Flexibilidad Refleja la experiencia previa de la organización con este tipo de proyectos. Muy bajo significa sin experiencia previa; Extraalto significa que la organización está completamente familiarizada con este dominio de aplicación Precedentes

93. Refleja la madurez del proceso de la organización. El cálculo de este valor depende del Cuestionario de Madurez del CMM pero se puede alcanzar una estimación sustrayendo el nivel de madurez del proceso CMM de 5. Madurez del Proceso Refleja qué tan bien se conocen entre ellos los miembros del equipo de desarrollo y qué tan bien trabajan juntos. Muy bajo significa interacciones muy difíciles; Extraalto significa un equipo integrado y efectivo sin problemas de comunicación . Cohesión del equipo

94. Atributos que se utilizan para ajustar las estimaciones iniciales en el modelo postarquitect ónico (4) : Atributos del producto: RELY Fiabilidad requerida del sistema CPLX Complejidad de los módulos del sistema DOCU Amplitud de la documentación requerida DATA Tamaño de la base de datos utilizada RUSE Porcentaje requerido de componentes reutilizables Atributos de la computadora: TIME Restricciones del tiempo de ejecución PVOL Volatilidad de la plataforma de desarrollo STOR Restricciones de memoria.

95. Atributos que se utilizan para ajustar las estimaciones iniciales en el modelo postarquitect ónico (4) : Atributos personales: ACAP Capacidad de análisis del proyecto. PCON continuidad del personal PEXP Experiencia del programador en el dominio del proyecto PCAP Capacidad del programador AEXP Experiencia del analista en el dominio del proyecto LTEX Experiencia en el lenguaje y las herramientas Atributos del proyecto: TOOL Utilización de las herramientas de software SCED Comprensión de los tiempos de desarrollo SITE Amplitud del trabajo en sitios múltiples y calidad de las comunicaciones del sitio.

96. Ejemplo Una organización trabaja un proyecto en el que se tiene poca experiencia en el dominio. El cliente del proyecto no ha definido el proceso a utilizar y no proporciona suficiente tiempo en la calendarización del proyecto para que se haga un análisis de riesgos. Se tiene que formar un nuevo equipo de desarrollo para implementar este sistema. La organización ha puesto en proceso un programa de mejoramiento y ha obtenido en Nivel 2 del modelo CMM.

97. Posibles valores de los factores de escala utilizados en el cálculo del exponente son: Precedentes : Este es un proyecto nuevo para la organización valor Bajo (4) Flexibilidad de desarrollo: No se involucra el cliente valor Muy alto (1) Resolución de la arquitectura/riesgo: No se lleva a cabo un análisis de riesgos valor Muy Bajo (5) Cohesión del equipo: Creación de un nuevo equipo por lo que no existe información Valor Nominal (3) Madurez del Proceso: Algún control del proceso en el lugar Valor Nominal (3) La suma de estos valores es 16 por lo que el exponente toma un valor de 1.17

98. Si además se supone que los conductores de costos clave en el proyecto son RELY, CPLX,STOR,TOOL y SCED: 730 personas-mes Estimación inicial de COCOMO sin conductores de costo 128.000 DSI Tamaño del Sistema (incluyendo factores para reutilización y los requerimientos de volatilidad) 1.17 Valor del Exponente 2306 personas-mes Estimación ajustada de COCOMO Acelerada, multiplicador = 1.29 Calendarización Baja, multiplicador = 1.12 Utilización de herramientas Alta, multiplicador = 1.21 Restricciones de memoria Muy alta, multiplicador = 1.3 Complejidad Muy alta , multiplicador = 1.39 Fiabilidad

99. En los ejemplos se consideraron valores extremos para ver como influye en la estimación 295 personas-mes Estimación ajustada de COCOMO Normal, multiplicador = 1 Calendarización Muy alta, multiplicador = 0.72 Utilización de herramientas Ninguna, multiplicador = 1 Restricciones de memoria Muy baja, multiplicador = 0.75 Complejidad Muy baja, multiplicador = 0.75 Fiabilidad

100. Modelos algorítmicos de costos en la planeación del proyecto A. Utilizar el hardware existente, sistema de desarrollo y equipo de desarrollo B. Actualización del Procesador y de la memoria Los costos de hardware se incrementan , la experiencia decrece Nuevo sistema de desarrollo Los costos de hardware se incrementan . La experiencia decrece C.Sólo actualización de la memoria Los costos de hardware se incrementan D.Personal más experimentado F. Personal con experiencia en hardware

101. Costo del software SC se calcula: SC = Esfuerzo esyimado x RELY x TIME x STOR x TOOL x EXP x CP CP = costo promedio de una persona mes de esfuerzo

102. Duración y personal del proyecto La relación entre el número de personas que trabajan en un proyecto, el esfuerzo total requerido y el tiempo de desarrollo no es lineal. Formula para estimar el tiempo calendario requerido para completar un proyecto TDEV: TDVE = 3 x (PM) (0.33+0.2x(B-1.01)) PM es el cálculo del esfuerzo B es el exponente que refleja el esfuerzo creciente requerido al incrementarse el tamaño del proyecto Este cálculo predice la duración nominal del proyecto

103. La duración prevista del proyecto y la requerida por el plan del proyecto no son necesariamente lo mismo. La duración planeada es más corta o más larga que la duración prevista original. Sin embargo existe un límite obvio para los cambios de duración, el cual se predice en COCOMO 2 como: TDVE = 3 x (PM) (0.33+0.2x(B-1.01)) x SCEDpercentage/100 SCEDpercentage es el porcentaje de crecimiento o decrecimiento en la duración nominal.

104. Un crecimiento muy rápido del personal del proyecto a menudo está correlacionado con retrasos en la duración del proyecto. Si se reduce el tiempo de desarrollo , siendo un factor clave, el esfuerzo requerido para desarrollar el sistema crece exponencialmente.