M

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 calidadMcCall y colegas (1997)
Facilidad de mantenimiento Flexibilidad Facilidad
de prueba
Portabilidad Reusabilidad Interoperatividad
Revisión del Producto
Transición del producto
Operación del producto
Corrección Fiabilidad Usabilidad Integridad
Eficiencia
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
• Fq c1 x m1 c2 x m2 .cn x mn
• Fq es factor de calidad
• Cn son coeficientes de regresión
• Mn 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ónEl 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 (i1
  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
•  

      Factor de ponderación Factor de ponderación Factor de ponderación    
Parámetro de medición Cuenta   Simple Media Compl.    
Número de entradas del usuario 3 X 3 4 6 9
Número de salidas del usuario 2 X 4 5 7 8
Número de consultas del usuario 2 X 3 4 6 6
Número de archivos 1 X 7 10 15 7
Número de interfaces externas 4 X 5 7 10 20
Cuenta total 50
Fig. 9.2 Cálculo de puntos de función Fig. 9.2 Cálculo de puntos de función Fig. 9.2 Cálculo de puntos de función Fig. 9.2 Cálculo de puntos de función Fig. 9.2 Cálculo de puntos de función Fig. 9.2 Cálculo de puntos de función Fig. 9.2 Cálculo de puntos de función Fig. 9.2 Cálculo de puntos de funció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)f2out(i). Donde fout(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)/fout(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
Métricas a aplicar

• 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 171835.
• Profundidad camino más largo desde el nodo raíz
  a un nodo hoja. Para el ejemplo Profundidad 4
• Amplitudnúmero máximo de nodos de cualquier
  nivel de la arquitectura. Para el ejemplo
  amplitud 6

38

• Relación arco a nodo, ra/n, mide la densidad de
  conectividad de la arquitectura y proporciona una
  indicación sencilla de acoplamiento de la
  arquitectura. Para el ejemplo r18/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

• n1 número de operadores diferentes que aparecen
  en le programa.
• n2 número de operandos diferentes que aparecen
  en el programa.
• N1 número total de veces que aparece el
  operador.
• N2 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 n1log2n1
  n2log2n2.
• Volumen de programa se define como V N
  n1log2(n1 n2). 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
  SUBROUTINE SORT(X,N) SUBROUTINE SORT(X,N) SUBROUTINE SORT(X,N)
  DIMENSION X(N) DIMENSION X(N) DIMENSION X(N)
  IF (N .LT. 2) RETURN IF (N .LT. 2) RETURN IF (N .LT. 2) RETURN
  DO 20 I2, N DO 20 I2, N DO 20 I2, N
    DO 10 J1, I DO 10 J1, I
    IF (X(I) .GE. X(J)) GO TO 10 IF (X(I) .GE. X(J)) GO TO 10
      SAVE X(I)
      X(I) X(J)
      X(J) SAVE
10 CONTINUE CONTINUE CONTINUE
20 CONTINUE CONTINUE CONTINUE
  RETURN RETURN RETURN
  END END END
44
  Operador Cuenta
1 Fin de sentencia 7
2 Subíndices de arreglos 6
3 5
4 IF() 2
5 DO 2
6 , 2
7 Fin de programa 1
8 .LT. 1
9 .GE. 1
10 GO TO 10 1
Total Total 28
De esta tabla se desprenden los valores de n110
y N128.
45
  Operando Cuenta
1 X 6
2 I 5
3 J 4
4 N 2
5 2 2
6 SAVE 2
7 1 1
Total Total 22
De esta tabla se desprenden los valores de n27 y
N222.
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
Sommervillecap.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
Producto de software
Medidas de Control
Medidas de predicción
Decisiones administrativas
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
Número de parámetros del procedimiento
Mantenibilidad
Complejidad ciclomática
Fiabilidad
Tamaño del programa en líneas de código
Portabilidad
Número de mensajes de error
Usabilidad
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
Técnicas de estimaciones de costos

• 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

73
Técnicas de estimaciones de costos

• 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.

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ñoB 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
Complejidad del proyecto Fórmula Descripción
Simple PM 2.4 (KDSI)1.05 x M Aplicaciones bien comprendidas desarrolladas por equipos pequeños
Moderada PM 3.0 (KDSI)1.12 x M Proyectos más complejos donde los miembros del equipo tienen experiencia limitada en sistemas relacionados
Incrustada PM 3.6 (KDSI)1.20 x M Proyectos complejos donde el software es parte de un complejo fuertemente acoplado de hardware, software, reglas y procedimientos operacionales.
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
Experiencia y capacidad de los desarrolladores Muy Baja Baja Nominal Alta Muy Alta
Madurez y capacidad CASE Muy Baja Baja Nominal Alta Muy Alta
PROD (NOP/mes) 4 7 13 25 50
85
El nivel de Diseño Inicial

• Las estimaciones se basan en fórmula estándar
  para modelos algorítmicos
• Esfuerzo A x TamañoB 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ñoB x M PMm donde
• M PERS x RCPX x RUSE x PDIF x FCIL x SCED.
• PMm es un factor que se utiliza cunado un
  porcentaje importante del código se genera de
  forma automática.
• PMm (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 ( AASU0.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
Precedentes 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
Flexibilidad 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
Resolución de la arquitectura/riesgo 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.
93
Cohesión del equipo 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 .
Madurez del Proceso 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.
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
Valor del Exponente 1.17
Tamaño del Sistema (incluyendo factores para reutilización y los requerimientos de volatilidad) 128.000 DSI
Estimación inicial de COCOMO sin conductores de costo 730 personas-mes
Fiabilidad Muy alta , multiplicador 1.39
Complejidad Muy alta, multiplicador 1.3
Restricciones de memoria Alta, multiplicador 1.21
Utilización de herramientas Baja, multiplicador 1.12
Calendarización Acelerada, multiplicador 1.29
Estimación ajustada de COCOMO 2306 personas-mes
99
Fiabilidad Muy baja, multiplicador 0.75
Complejidad Muy baja, multiplicador 0.75
Restricciones de memoria Ninguna, multiplicador 1
Utilización de herramientas Muy alta, multiplicador 0.72
Calendarización Normal, multiplicador 1
Estimación ajustada de COCOMO 295 personas-mes
En los ejemplos se consideraron valores extremos
para ver como influye en la estimación
100
Modelos algorítmicos de costos en la planeación
del proyecto
A. Utilizar el hardware existente, sistema de
desarrollo y equipo de desarrollo
D.Personal más experimentado
B. Actualización del Procesador y de la
memoria Los costos de hardware se incrementan ,
la experiencia decrece
C.Sólo actualización de la memoria Los costos de
hardware se incrementan

• Nuevo sistema de desarrollo
• Los costos de hardware se incrementan . La
  experiencia decrece

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.330.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.330.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.