Dentro del MCS proponemos el uso de 5 indicadores básicos que pueden usarse para dar seguimiento a los proyectos de construcción de software, así como también servir de guía para la mejora de los procesos que se utilizan para su construcción.

1. Cantidad de defectos

La cantidad de defectos detectada en un producto de software puede usarse como indicador tanto de la calidad del producto como la calidad del proceso (desarrollo y verificación). Es importante medir la cantidad de defectos relacionados a categorías de severidad, ya que no es lo mismo 100 defectos críticos para el negocio, que 100 detalles de interfaz de usuario a mejorar.

Categorías de Severidad de defectos:

1. Crítico: el defecto impide que el sistema o la mayor parte de él funcione.
2. Mayor: el defecto impide que una función importante del sistema funcione y/o corrompe los datos en la base de datos.
3. Medio: El defecto impide que una función importante del sistema funcione, no se afectan los datos de la base de datos y hay una solución alternativa.
4. Menor: El defecto no afecta la funcionalidad si bien afecta al usuario de alguna manera.

Por otro lado, es interesante identificar la etapa de desarrollo de software en la cual es encontrado el defecto, para esto sugerimos medir la cantidad de defectos detectados por grado de severidad:

• Durante desarrollo.

• Durante período de estabilización.

• Después de la estabilización.

La cantidad de defectos es un indicador que refleja la calidad de los productos de software y la calidad de las pruebas durante el desarrollo. En esta etapa pocos defectos por unidad pueden indicar una buena calidad del producto o una mala calidad de las pruebas. Muchos defectos por unidad indefectiblemente son un indicador de mala calidad del producto. Una unidad con un número de defectos mucho mayor de lo usual en cierto contexto organizacional debe ser tomado como una señal de alerta de un problema en requerimientos, diseño o implementación de esa unidad.

Durante el período de estabilización la cantidad de defectos es un indicador de la calidad del software puesto en producción. Después de la estabilización es un indicador de la calidad del software puesto en producción y de la calidad de las tareas de mantenimiento.

La evolución de estos indicadores permite evaluar si la organización está mejorando la calidad de los productos que pone en producción (o no).

2. Duración del proyecto

Medir la duración del proyecto real vs. la planificada puede ser un buen indicador para saber el grado de cumplimiento que se tiene con el proyecto respecto de las fechas comprometidas. Este indicador requiere definir fecha de comienzo y de fin del proyecto y de cada "compromiso" que el equipo asume y quire medir su grado de cumplimiento (en relación al cumplimiento de la fecha acordada).

Conviene distinguir de forma diferenciada la fase de Conceptualizacion, el eventual período intermedio entre el fin de la Conceptualización y el comienzo efectivo del resto del proyecto, el inicio de la puesta en producción y el fin de la estabilización de la solución.

Las fechas que deben quedar claras son:

• Fechas de Inicio y Fin de Conceptualización.

• Fechas de Inicio y Fin del proyecto de desarrollo.

• Fechas de Inicio y Fin de la puesta en producción.

• Fechas de Inicio y Fin de la estabilización.

Estos datos resultan esenciales para generar historia de la capacidad de cierta organización. Estos datos permiten estimar nuevos proyectos a partir de resultados obtenidos por la propia organización y que la involucran como un todo.

A partir de estos datos es posible construir indicadores de la confiabilidad de las estimaciones, como ser duración estimada/duración real.

3. Costo y recursos

Medir el uso de recursos y el costo del proyecto es otro indicador importante a tener en cuenta. Factores importantes a tener en cuenta para incluir en este indicador son:

1. Recursos Humanos

   • Internos
     1. Informáticos
     2. No informáticos
   • Externos

   1. Informáticos

   2. No informáticos

2. Servicios

3. Otros

Consideraciones importantes:

• Los recursos humanos se pueden cuantificar en horas/persona.
• Los otros recursos se pueden cuantificar en alguna moneda estable.

Debe quedar claro cuáles fases del proyecto están consideradas y cuáles no (Conceptualización, fases del proyecto de desarrollo, Implantar y estabilizar la solución).

Estos datos resultan esenciales para generar historia de la capacidad de cierta organización. Permiten estimar nuevos proyectos a partir de resultados obtenidos por la propia organización y que la involucran como un todo.

A partir de estos datos es posible construir indicadores de la confiabilidad de las estimaciones, como ser el costo estimado/costo real. Los costos reales permiten evaluar el retorno real de la inversión del proyecto respecto al retorno estimado. Esto es un insumo para evaluar la calidad del proceso de selección de proyectos.

4. Tamaño

El tamaño del producto se puede medir de distintas formas:

• Puntos de Función

• Líneas de código

• Componentes

• Historias de Usuario implementadas

Otra forma de medir el tamaño es por analogía con otro producto conocido. Por ejemplo dado el producto conocido A, se sabe que el proyecto nuevo tiene un tamaño xA siendo x un coeficiente entre 0 y 10.

La información del tamaño de los productos de proyectos pasados sirve de base para estimaciones futuras y para obtener otros indicadores.

5. Satisfacción de los involucrados

Satisfacción de los diferentes involucrados, entre los que cabe distinguir las categorías siguientes:

1. Sponsor de Negocio: quien “paga” por el proyecto o quien dispone que se asignen recursos para que el proyecto se haga. Tiene un objetivo de negocio que lograr y es él quien ante un conflicto en los requerimientos planteados por otros interesados tiene la última palabra.

2. Responsable del proyecto (puede ser el Gerente de Proyecto u otro rol responsable).

3. Participantes Informáticos.

   • Desarrollo

   • Mantenimiento

   • Operación

   • Soporte

4. Participantes No Informáticos

5. Usuarios del producto

   • Internos

     • Análisis por diferentes unidades organizacionales/categorías

   • Externos

     • Análisis por diferentes unidades organizacionales/categorías

6. Afectados o Interesados del proyecto

7. • Internos

   • • Análisis por diferentes unidades organizacionales/categorías

   • Externos

   • • Análisis por diferentes unidades organizacionales/categorías

La evaluación de la satisfacción de los Interesados del proyecto resulta delicada. Una cosa es el indicador en sí mismo y otra es la evaluación que se pueda hacer de él en el contexto en el que surge.

La satisfacción del Sponsor de Negocio y Responsable del Proyecto son muy fáciles de obtener. Las otras involucran a varias personas, por lo que no resultan tan fáciles. Una manera poco costosa consiste en realizar encuestas con soporte informático las que garantizan que sean anónimas. Una forma simple de evaluarla consiste en el grado de acuerdo o desacuerdo con cinco niveles de una escala de Likert. También se debe dar la posibilidad de realizar comentarios adicionales abiertos para cada aspecto de interés.

En la evaluación de satisfacción los aspectos a evaluar son:

  a) resultado global del proyecto (todos)

  b) duración (Patrocinador y responsable del proyecto).

  c) costo o recursos asignados (Patrocinador y responsable del proyecto).

  d) calidad del resultado obtenido (todos).

  e) grado de uso del producto del proyecto (todos).

  f) logro de los objetivos de negocio que perseguía el proyecto (Patrocinador, responsable del proyecto y otros gerentes).

  g) funcionamiento de los equipos de trabajo y del proyecto en su conjunto (todos los participantes en el proyecto).

Se debe elegir de forma adecuada el momento en el que se va a realizar la evaluación. Cuando el proyecto está entrando en la fase de producción gran parte de los involucrados están enfocados en esa puesta en producción lo que podría afectar negativamente la calidad de la evaluación. Puede resultar conveniente realizar la evaluación un tiempo después, cuando el sistema ya se encuentre estabilizado y haya pasado el pico de la carga de trabajo. Hay que tener en cuenta que si se realiza demasiado tarde los equipos ya se pueden haber desarmado y con las consiguientes complicaciones. También aspectos relevantes pueden caer en el olvido. Por otra parte la evaluación del logro de los objetivos del proyecto puede requerir un tiempo adicional.