Medida de productividad

En otras industrias además de la industria del software, La medición de la productividad es una actividad normal que impulsa el éxito de una empresa.. Veamos, por ejemplo, una empresa de pintura unipersonal. Para un pintor, Sería lógico medir su productividad en horas de esfuerzo por metro cuadrado. Probablemente quiera diferenciar la medida en algunas categorías.,como herramientas usadas (por ejemplo. rodillo / cepillo / spray / etc.) y las características del objeto de pintura (por ejemplo. pared / escalera / puerta / etc.). Cuando el pintor crea una base de datos con cifras de productividad, puede cotizar fácilmente para nuevos trabajos de pintura, simplemente midiendo la superficie de la pintura en metros cuadrados, multiplicar con la tasa de productividad adecuada y multiplicar el resultado con la tasa de horas que pide. Si hay un (internacional) Base de datos disponible con las tasas de productividad de los trabajos de pintura realizados por otras empresas de la industria., el pintor entiende cómo se desempeña en promedio frente a la industria y en caso de que ya no sea el mejor de su clase, entiende que para conseguir nuevos trabajos de pintura tiene que seguir mejorando su productividad (ya que reducir la tarifa horaria no suele ser una buena idea).

El puede hacer todo esto, pero solo cuando:

  • El usa un unidad de medida estándar, por ejemplo. metro cuadrado. Solo usando estándares, las tasas de productividad se pueden comparar (comparado) y utilizado para estimando;
  • El usa un forma estándar de registrar las horas de esfuerzo. Por ejemplo, ¿Está incluida o excluida la pausa para el almuerzo?, es el momento de hablar con el cliente para comprender sus requisitos incluidos / excluidos?
  • Él usa metrocategorías significativas que diferencian la productividad. Para un pintor, Puede que no importe demasiado si el objeto de pintura (digamos una pared) está en una villa o en una casa de pescadores. El tipo de casa puede no ser una categoría significativa. sin embargo, la herramienta que utiliza es probablemente un factor de productividad principal.

Ahora, echemos un vistazo a la industria del software.

La industria del software y la medición de la productividad

Desafortunadamente, la cosa (y software) La industria todavía es bastante inmadura en lo que respecta al uso de estándares y en lo que respecta a la productividad. (actuación) medición, evaluación comparativa y mejora continua. La industria se salió con la suya durante mucho tiempo, porque:

  • Es dificil de medir salida (el software no es una cosa física, no se puede tocar ni medir con instrumentos de medición convencionales).
  • Los proyectos de software se parecen más a una R&Proyecto D que fabricar un producto. R&D es increíblemente difícil de medir. Es relativamente fácil medir las entradas, pero los resultados son difíciles de medir e impredecibles por naturaleza.

Ahora, lentamente, la industria se está volviendo cada vez más transparente y las organizaciones de clientes piden cada vez más a los proveedores potenciales que cuantifiquen su desempeño basándose en datos históricos. De esta manera, es posible seleccionar el mejor proveedor para el trabajo. Tenga en cuenta que la mejor opción no suele ser la opción menos costosa (a menudo resulta en fallas en el proyecto…o incluso desastres).

Estándares

Si bien puede parecer fácil implementar un proceso de medición de la productividad en una organización, La realidad muestra que es más difícil de lo que uno puede pensar.. En principio, como el pintor, es suficiente para medir entradas (normalmente horas de esfuerzo) y salidas (Unidades de medida, UoM) por proyecto de software, mientras usar categorías significativas para diferenciar los proyectos, como la tecnología (Java / .Net / Oracle / Etc.), Tipo de proyecto (nuevo desarrollo / mejora) y / o implementación (Implementación / modificación de paquetes / software a medida).

Para poder construir métricas de productividad significativas y comparables, es fundamental que (internacional) se utilizan estándares. Deben tomarse varias decisiones:

Entradas de medida

Algunas decisiones que hay que tomar:

  • Horas de esfuerzo dentro / fuera del alcance de medición, por ejemplo
    • Diseño técnico, codificación, prueba de unidad, prueba de sistemas, otras pruebas de proveedores, sobrecarga en alcance;
    • Diseño funcional, prueba de aceptación de soporte, actividades de implementación fuera del alcance.
  • Horas extraordinarias dentro / fuera del alcance de la medición;
  • Horas de viaje, horas de reunión, Horas generales dentro / fuera del alcance;
  • En caso de paquetes, Portales / CMS u otro software configurable, puede ser necesario tener actividades de registro de esfuerzo separadas para la personalización, configuración de parámetros y software personalizado que no forman parte del paquete.

Poder analizar la productividad de un proveedor, departamento o equipo, el sistema de registro de esfuerzo debe implementarse de manera estándar. Si se elige que las horas de diseño funcional están fuera del alcance, Todos los proyectos deben registrar su esfuerzo de diseño funcional por separado de las otras horas de esfuerzo.. Se recomienda encarecidamente elaborar una estructura de desglose del trabajo estándar (WBS)’ por tipo de proyecto e implementar esta WBS en el sistema de registro de esfuerzos. Todo aquel que registre horas de esfuerzo debe ser consciente de la importancia de reservar correctamente su esfuerzo en el sistema.

Medición de salidas, métodos que deben evitarse

Medir las salidas es algo más difícil que medir las entradas, debido a la naturaleza intangible del software. Muchas organizaciones miden las líneas de código fuente entregadas (slocs) del producto de software entregado después de la finalización y utilice métricas de productividad como horas de esfuerzo por 1000 slocs. Esto parece un buen camino a seguir, pero de hecho hay muchas razones por las que esta no es una práctica recomendada:

  • No hay (ISO u otro) estándar para líneas de código fuente. El resultado es que diferentes herramientas de conteo automático de códigos producen (muy) diferentes resultados para el mismo código.
  • No está claro si más código es "bueno’ o malo'. Las líneas de código fuente no son de valor para la organización del cliente. La funcionalidad es valiosa. Los clientes nunca dicen:”Por favor dame 100000 líneas de código fuente”. No, es la funcionalidad en términos de características que requieren. Más funcionalidad es mejor y cuesta más, más slocs tal vez no sea mejor.
  • Diferentes lenguajes de programación (y mezclas de estos) dar como resultado líneas de código fuente muy diferentes.

Gurú estadounidense de métricas de software’ Capers Jones escribió en un artículo "Orígenes de defectos de software y métodos de eliminación (2013) que las mediciones de sloc son tan inexactas, que usar slocs en la medición de software es de hecho "Negligencia profesional".

Otras medidas de tamaño que se utilizan a menudo en la industria, pero también son no recomendado para usar en la medición de la productividad:

  • Puntos de historia (SP) en proyectos ágiles: Una medida muy subjetiva que solo tiene valor dentro de un equipo. Comparación con otros equipos, departamentos y organizaciones no es posible. Tenga en cuenta que los SP son útiles para planificar sprints y realizar un seguimiento de la velocidad de un equipo, pero para la medición de la productividad, los SP son casi inútiles.
  • Puntos de casos de uso (UCP): Solo aplicable cuando la documentación consta de casos de uso. UCP también es un método muy subjetivo, especialmente cuando se trata de establecer el Factor de Complejidad Técnica y el Factor Ambiental. también, no hay una forma estándar de escribir casos de uso, ver, por ejemplo, cinco posibles niveles de granularidad como se describe aquí.
  • Puntos de complejidad: Método subjetivo y no estandarizado para medir la complejidad de una aplicación.
  • Puntos IBRA: Método no estandarizado para medir las reglas comerciales en una aplicación. Cuando se aplica de acuerdo con el manual, el resultado es cero para todas las aplicaciones.
  • Puntos de función rápida (FFPA) (por Gartner): Un método de medición implementado por Gartner que no se puede comparar con los métodos de análisis de puntos funcionales estandarizados ISO. FFPA se percibe como un método comercial que carece de una base teórica y es en parte subjetivo. El método no ha demostrado ser más rápido que el método estimado de Nesma y no ha demostrado ser más preciso.. Desafortunadamente, a menudo se lleva a un nivel gerencial superior sin el apoyo de los especialistas que tienen que trabajar con él..

Salida de medición – métodos muy recomendados

Es un práctica muy recomendada usar un Norma ISO / IEC para la medición del tamaño funcional en la medición de la productividad de proyectos de software. Hay cinco métodos de medición de tamaño funcional que cumplen con el estándar ISO / IEC:

  • Puntos de función NESMA (ISO / IEC 24570);
  • IFPUG puntos de función (ISO / IEC 20926);
  • CÓSMICO puntos de función (ISO / IEC 19761);
  • Mark II puntos de función (ISO / IEC 20968);
  • FiSMA puntos de función (ISO / IEC 29881).

Las ventajas de usar uno de estos métodos de medición del tamaño funcional para la medición de la productividad son:

  • Objetivo, repetible, verifiable, forma defendible de determinar el tamaño del software;
  • Una relación clara entre el tamaño funcional y el esfuerzo necesario para realizar la aplicación, esto ha sido estudiado y verificado muchas veces;
  • La medida es clara tanto para las organizaciones de clientes como para las organizaciones de proveedores.. Más funcionalidad significa más valor, se necesita más esfuerzo y un precio más alto;
  • El tamaño funcional es independiente de la solución técnica y / o los requisitos no funcionales. Una aplicación de 500 Los puntos de función NESMA realizados en Java son tan grandes como un sitio web de Wordpress de 500 FP. Esto permite la comparación y la evaluación comparativa sobre dominios técnicos y el uso de datos históricos del proyecto. (cuando se clasifica correctamente) en la estimación de nuevos proyectos de software.

Categorías útiles para la recopilación de datos

Para poder comparar y comparar su productividad, es importante utilizar categorías estándar para recopilar datos de sus proyectos. Nesma recomienda encarecidamente utilizar las definiciones y categorías que el Grupo de estándares internacionales de evaluación comparativa de software (ISBSG) está utilizando en sus actividades de recopilación de datos.

Grupo de estándares internacionales de evaluación comparativa de software (ISBSG) es una "sin fines de lucro’ organización que recopila datos de la industria del software y que crece, mantiene y explota dos repositorios: ‘Nuevos desarrollos y mejoras’ y mantenimiento & Apoyo'. ISBSG solo puede hacer esto cuando los datos se recopilan de manera estándar. Los "Cuestionarios de recopilación de datos’ se puede descargar desde el Sitio de ISBSG y mostrar ya muchas definiciones y categorías. También son útiles los glosarios que se proporcionan con los repositorios..

Implementar la medición de la productividad del software

Entonces, como el pintor del ejemplo anterior, es posible medir la productividad de proyectos de software. Consulte esta página para ver algunos ejemplos..

Para implementar con éxito la medición de la productividad del software, se recomienda encarecidamente utilizar el documento "Bases of Measurements’ que aparece en la lista de publicaciones.