Productividad de la programación

Si bien no existe una definición de productividad comúnmente aceptada, parece haber consenso en que la productividad describe la relación entre la producción y los insumos:

Productividad = Producción / Insumos

Sin embargo, en las distintas disciplinas se pueden encontrar diferentes nociones y, en particular, diferentes unidades de medida para la entrada y la salida. La industria manufacturera suele utilizar una relación directa entre el número de unidades producidas y el número de unidades consumidas. ^{[ 4 ]} Las industrias no manufactureras suelen utilizar horas-hombre o unidades similares para permitir la comparación entre la salida y la entrada.

Un acuerdo básico es que el significado de productividad y los medios para medirla varían según el contexto que se esté evaluando. En una empresa manufacturera, los posibles contextos son: ^{[ 3 ]}

• la máquina individual o el sistema de fabricación;
• la función de fabricación, por ejemplo el ensamblaje;
• el proceso de fabricación de un solo producto o grupo de productos relacionados;
• la fábrica; y
• todo el sistema de fábricas de la empresa

Mientras se consideran los procesos de producción clásicos, una métrica directa de productividad es simple: cuántas unidades de un producto de calidad específica se producen con qué costos. Para el trabajo intelectual, la productividad es mucho más compleja. ¿Cómo medimos la productividad de autores, científicos o ingenieros? Debido a la creciente importancia del trabajo del conocimiento (en contraposición al trabajo manual), ^{[ 5 ]} muchos investigadores intentaron desarrollar medios de medición de la productividad que se puedan aplicar en un contexto no manufacturero. Existe un consenso general en que la naturaleza del trabajo del conocimiento difiere fundamentalmente del trabajo manual y, por lo tanto, es necesario tener en cuenta factores además de la simple relación producción/insumo, por ejemplo, calidad, puntualidad, autonomía, éxito del proyecto, satisfacción del cliente e innovación. Sin embargo, las comunidades de investigación en ninguna de las dos disciplinas han podido establecer aún medios de medición de la productividad ampliamente aplicables y aceptados. ^{[ 1 ]} Lo mismo ocurre con el área más específica de la productividad en programación.

La rentabilidad y el rendimiento están estrechamente vinculados y, de hecho, a menudo se confunden. Sin embargo, dado que la rentabilidad se define generalmente como la relación entre los ingresos y los costos

Rentabilidad = Ingresos / Costos

Su alcance es mayor que el del desempeño; es decir, el número de factores que influyen en la rentabilidad es mayor que el de los factores que influyen en la productividad. En particular, la rentabilidad puede variar sin que cambie la productividad, por ejemplo, debido a condiciones externas como la inflación de costos o precios. Además, la interdependencia entre productividad y rentabilidad suele ser diferida; es decir, las mejoras en la productividad rara vez se reflejan en una rentabilidad inmediata, sino que es más probable que se materialicen a largo plazo.

El término desempeño es incluso más amplio que productividad y rentabilidad, y abarca una gran cantidad de factores que influyen en el éxito de una empresa. Por lo tanto, instrumentos de control de desempeño reconocidos, como el Cuadro de Mando Integral, incluyen la productividad como un factor fundamental, aunque no exclusivo. Otros factores relevantes son, por ejemplo, la percepción que tienen los clientes o las partes interesadas sobre la empresa.

Eficiencia y eficacia son términos que generan confusión, ya que a menudo se confunden y, además, la eficiencia suele confundirse con la productividad. La diferencia entre eficiencia y eficacia se suele explicar informalmente como: eficiencia es hacer las cosas bien y eficacia es hacer las cosas correctas . Si bien existen numerosas definiciones, ^{[ 3 ]} hay cierto consenso en que la eficiencia se refiere a la utilización de los recursos e influye principalmente en el insumo requerido del índice de productividad. La eficacia, por otro lado, influye principalmente en el resultado del índice de productividad, ya que suele tener consecuencias directas para el cliente. La eficacia puede definirse como "la capacidad de alcanzar un resultado deseado".

En general, se asume que la eficiencia se puede cuantificar, por ejemplo, mediante tasas de utilización, con mucha más facilidad que la efectividad.

Tangen afirma: «Las mejoras en la calidad, aparte del hecho de que los productos sin defectos aumentan los niveles de producción, no deberían incluirse en el concepto de productividad». ^{[ 3 ]} Sin embargo, la mayor parte de la literatura clásica en disciplinas no relacionadas con el software, especialmente en el área de manufactura, no analiza explícitamente el papel de la calidad de la producción en el índice de productividad. ^{[ 6 ]} Trabajos más recientes de disciplinas no manufactureras se centran más en el conocimiento, el trabajo de oficina o el trabajo administrativo y, por lo tanto, analizan cada vez más el papel de la calidad con respecto a la calidad. ^{[ 5 ] [ 1 ] [ 7 ] [ 8 ] [ 9 ]}

Drucker subraya la importancia de la calidad para la evaluación de la productividad de los trabajadores del conocimiento: «Por lo tanto, la productividad del trabajo del conocimiento debe apuntar primero a obtener calidad, y no una calidad mínima, sino una calidad óptima, si no máxima. Solo entonces se puede preguntar: "¿Cuál es el volumen, la cantidad de trabajo?"» ^{[ 5 ]}

Saari capta la importancia de la calidad con su fórmula extendida para la productividad: ^{[ 8 ]}

Productividad total = (Calidad y cantidad de la producción) / (Calidad y cantidad de los insumos)

Sin embargo, parece que estos esfuerzos por incluir la calidad en la determinación de la productividad aún no han dado como resultado un concepto operacionalizable. Actualmente, sigue sin estar claro cómo cuantificar los términos vagos de "calidad y cantidad de la producción" y "calidad y cantidad de los insumos", y mucho menos cómo calcular la relación entre ambos.

Boehm was one of the first researchers that systematically approached the field of software productivity. His cost estimation model COCOMO - now COCOMO II^[10] - is standard software engineering knowledge. In this model, he defines a set of factors that influence productivity, such as the required reliability or the capability of the analysts. These factors have been widely reused in other similar productivity approaches. The rest of the model is based on function points and finally source lines of code (LOC). The limitations of LOC as a productivity measure are well-known.

Jones is the author of a series of books on software productivity. Besides several theoretical considerations his main contribution is the systematic provision and integration of a large amount of data relevant for productivity analyses. In at least two of his books,^[11][12] he gives a number of productivity factors but also points out that for each project a different set of factors are influential. These factors can form a basis for productivity assessments and for comparison with industrial averages.

This is one such list:

The 20 factors whose quantified impacts on software projects have been determined from historical data are the following:

• Programming language used
• Program size
• The experience of programmers and design personnel
• The novelty of requirements
• The complexity of the program and its data
• The use of structured programming methods
• Program class or the distribution method
• Program type of the application area
• Tools and environmental conditions
• Enhancing existing programs or systems
• Maintaining existing programs or systems
• Reusing existing modules and standard designs
• Program generators
• Fourth-generation languages
• Geographic separation of development locations
• Defect potentials and removal methods
• Existing documentation
• Prototyping before main development begins
• Project teams and organization structures
• Morale and compensation of staff^[12]

Los puntos de función fueron propuestos en 1977 por Albrecht como una medida de tamaño de software superior a las líneas de código (LOC). Se basan en la especificación del software y, por lo tanto, buscan medir el tamaño de su funcionalidad en lugar del código en sí. Esto se debe a que el tamaño del código no solo depende del tamaño de la funcionalidad, sino también de la habilidad del programador: los mejores programadores producen menos código para la misma funcionalidad. Los puntos de función han sufrido varios rediseños a lo largo de los años, impulsados ​​principalmente por el Grupo Internacional de Usuarios de Puntos de Función (IFPUG). Este grupo es grande, con más de 1200 empresas miembros, lo que demuestra la amplia aceptación de esta medida. Sin embargo, en muchos ámbitos aún carece de aplicación práctica, ya que a menudo se concibe como aplicable únicamente a sistemas de información empresarial.

Varios investigadores propusieron la ingeniería de software basada en valores o impulsada por la economía como un paradigma importante para la investigación futura en ingeniería de software. Boehm y Huang señalan que no solo es importante realizar un seguimiento de los costos en un proyecto de software, sino también del valor real ganado, es decir, el valor para el cliente. ^{[ 13 ]} Explican que es importante crear el caso de negocio del software y mantenerlo actualizado. En esencia, la ingeniería de software basada en valores se centra en el valor para el cliente, medido principalmente en unidades monetarias.

El famoso libro Peopleware: Productive Projects and Teams de De Marco y Lister ^{[ 14 ]} puso de relieve la importancia de los factores relacionados con las personas ante un público más amplio. Recopilaron experiencias de numerosos proyectos de software con buenas y malas prácticas de gestión que influyen en la productividad del equipo. Tanto ellos como otros autores demostraron que estos son aspectos decisivos en la ingeniería de software, pero hasta entonces solo habían podido describirlos de forma anecdótica.