La productividad de programación (también llamada productividad de software o productividad de desarrollo ) describe el grado de capacidad de los programadores individuales o de los equipos de desarrollo para crear y desarrollar sistemas de software. La productividad se refiere tradicionalmente a la relación entre la cantidad de software producido y el costo invertido en él. Aquí la delicadeza radica en encontrar una forma razonable de definir la cantidad de software.
La productividad es un tema importante que se investiga en disciplinas tan diversas como la fabricación, la psicología organizacional, la ingeniería industrial, la gestión estratégica, las finanzas, la contabilidad, el marketing y la economía. Los niveles de análisis incluyen el individual, el grupal, el divisional, el organizacional y el nacional. [1] Debido a esta diversidad, no existe una definición clara de productividad y sus factores influyentes, aunque se han realizado investigaciones durante más de un siglo. Al igual que en la ingeniería de software, esta falta de acuerdo común sobre lo que realmente constituye la productividad se percibe como un obstáculo importante para una discusión fundamentada de la productividad. [2] Las siguientes definiciones describen el mejor consenso sobre la terminología. [3]
Si bien no existe una definición comúnmente aceptada de productividad, parece haber consenso en que la productividad describe la relación entre producción e insumos:
Productividad = Salida / Entrada
Sin embargo, en las distintas disciplinas se pueden encontrar diferentes nociones y, en particular, diferentes unidades de medida para los insumos y los productos. 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 los productos y los insumos.
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 contextos posibles son: [3]
Mientras que los procesos de producción clásicos se consideran una métrica directa de la 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 complicada. ¿Cómo medimos la productividad de los autores, científicos o ingenieros? Debido a la creciente importancia del trabajo del conocimiento (en oposició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. Se acepta comúnmente que la naturaleza del trabajo del conocimiento difiere fundamentalmente del trabajo manual y, por lo tanto, se deben tener en cuenta factores además de la simple relación producto/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 disciplinas han podido establecer medios ampliamente aplicables y aceptados para la medición de la productividad. [1] Lo mismo se aplica al área más específica de la productividad de la programación.
La rentabilidad y el rendimiento están estrechamente relacionados y, de hecho, a menudo se confunden. Sin embargo, como la rentabilidad suele definirse como la relación entre los ingresos y los costes
Rentabilidad = Ingresos / Costos
Tiene un alcance más amplio que el desempeño, es decir, el número de factores que influyen en la rentabilidad es mayor que el número de factores que influyen en la productividad. En particular, la rentabilidad puede cambiar sin que se produzca ningún cambio en la productividad, por ejemplo, debido a condiciones externas como la inflación de costos o precios. Además de eso, la interdependencia entre productividad y rentabilidad suele ser tardía, es decir, las ganancias en productividad rara vez se reflejan en ganancias de rentabilidad inmediatas; es más probable que las ganancias en rentabilidad se realicen en el largo plazo.
El término rendimiento 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 ello, instrumentos de control del rendimiento bien conocidos, como el Cuadro de Mando Integral, incluyen la productividad como un factor central, pero no único. Otros factores relevantes son, por ejemplo, la percepción que los clientes o las partes interesadas tienen de la empresa.
Eficiencia y eficacia son términos que generan más confusión, ya que a menudo se confunden y, además, eficiencia suele confundirse con productividad. La diferencia entre eficiencia y eficacia suele explicarse de manera informal como eficiencia es hacer las cosas bien y eficacia es hacer las cosas correctas . Si bien existen muchas otras definiciones, [3] existe cierto consenso en que la eficiencia se refiere a la utilización de los recursos e influye principalmente en el insumo requerido para el índice de productividad. La eficacia, por otro lado, influye principalmente en el resultado del índice de productividad, ya que generalmente tiene consecuencias directas para el cliente. La eficacia puede definirse como "la capacidad de alcanzar un resultado deseado".
En general, se supone que la eficiencia se puede cuantificar, por ejemplo, mediante tasas de utilización, considerablemente más fácilmente que la eficacia.
Tangen afirma: "Las mejoras en la calidad, aparte del hecho de que los productos sin defectos se suman a 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 fabricación, no analiza explícitamente el papel de la calidad de la producción en la relación de productividad. [6] Los trabajos más recientes de disciplinas no relacionadas con la fabricación se centran más en el conocimiento, el trabajo de oficina o de cuello blanco 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: "La productividad del trabajo del conocimiento debe apuntar, por tanto, en primer lugar a la obtención de la calidad, y no a la calidad mínima, sino a la óptima, si no a la máxima. Sólo entonces se puede preguntar: "¿Cuál es el volumen, la cantidad de trabajo?"" [5]
Saari captura la importancia de la calidad con su fórmula extendida para la productividad: [8]
Productividad total = (calidad y cantidad de salida)/(calidad y cantidad de entrada)
Sin embargo, parece que estos esfuerzos por incluir la calidad en la determinación de la productividad aún no han dado lugar a un concepto operacionalizable. Actualmente no está claro cómo cuantificar los términos vagos “calidad y cantidad de productos” y “calidad y cantidad de insumos”, y mucho menos calcular la relación.
En el desarrollo de software las cosas son más complicadas que en la producción de bienes. El desarrollo de software es un proceso de ingeniería.
Boehm fue uno de los primeros investigadores que abordó sistemáticamente el campo de la productividad del software. Su modelo de estimación de costes COCOMO -actualmente COCOMO II [10] - es un conocimiento estándar de la ingeniería de software. En este modelo, define un conjunto de factores que influyen en la productividad, como la fiabilidad requerida o la capacidad de los analistas. Estos factores han sido ampliamente reutilizados en otros enfoques de productividad similares. El resto del modelo se basa en puntos de función y, finalmente, en líneas de código fuente (LOC). Las limitaciones de LOC como medida de productividad son bien conocidas.
Jones es autor de una serie de libros sobre productividad de software. Además de varias consideraciones teóricas, su principal contribución es la provisión e integración sistemática de una gran cantidad de datos relevantes para los análisis de productividad. En al menos dos de sus libros, [11] [12] proporciona una serie de factores de productividad, pero también señala que para cada proyecto influye un conjunto diferente de factores. Estos factores pueden formar una base para las evaluaciones de productividad y para la comparación con los promedios industriales.
Esta es una de esas listas:
Los 20 factores cuyos impactos cuantificados en los proyectos de software se han determinado a partir de datos históricos son los siguientes:
- Lenguaje de programación utilizado
- Tamaño del programa
- La experiencia de los programadores y el personal de diseño
- La novedad de los requisitos
- La complejidad del programa y sus datos.
- El uso de métodos de programación estructurada
- Clase de programa o método de distribución
- Tipo de programa del área de aplicación
- Herramientas y condiciones ambientales
- Mejorar programas o sistemas existentes
- Mantenimiento de programas o sistemas existentes
- Reutilización de módulos existentes y diseños estándar
- Generadores de programas
- Lenguas de cuarta generación
- Separación geográfica de las ubicaciones de desarrollo
- Potenciales defectos y métodos de eliminación
- Documentación existente
- Creación de prototipos antes de comenzar el desarrollo principal
- Equipos de proyecto y estructuras organizativas
- Moral y remuneración del personal [12]
Los puntos de función fueron propuestos en 1977 por Albrecht como una mejor medida del tamaño del software que el LOC, ya que se basa en la especificación del software y, por lo tanto, tiene como objetivo medir el tamaño de su funcionalidad en lugar del código en sí. La razón es que el tamaño del código no solo depende del tamaño de la funcionalidad, sino también de la capacidad del programador: los mejores programadores producirán menos código para la misma funcionalidad. Los puntos de función han sufrido varios rediseños a lo largo de los años, principalmente impulsados por el International Function Point User Group (IFPUG). Este grupo es grande y cuenta con más de 1200 empresas como miembros, lo que demuestra la fuerte aceptación de esta medida. Sin embargo, en muchos dominios aún carece de aplicación práctica porque a menudo se concibe como aplicable solo a los sistemas de información empresarial.
Varios investigadores propusieron la ingeniería de software basada en el valor o impulsada por la economía como un paradigma importante en la investigación futura de la 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 el valor 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] atrajo la atención de un público más amplio sobre la importancia de los factores relacionados con las personas. Recopilaron experiencias de muchos proyectos de software con buenas y malas prácticas de gestión que influyen en la productividad del equipo. Ellos y otros demostraron que estos son los temas decisivos en la ingeniería de software, pero solo fueron capaces de describirlos anecdóticamente.
Probablemente exista una gran cantidad de factores que influyen en la productividad de programación de individuos y equipos. Por ejemplo, el proceso de desarrollo de software utilizado probablemente influya en la eficacia y eficiencia de un equipo.
Las personalidades de los programadores de software influyen en los estilos de codificación utilizados, lo que, a su vez, influye en la productividad de los programadores. [15]
En 2007, el cómic xkcd popularizó el concepto de pico Ballmer , en el que un programador, con la cantidad justa de embriaguez , alcanza un alto estado de productividad. El pico Ballmer debe su nombre al exdirector ejecutivo de Microsoft, Steve Ballmer , [16] y es probable que sea un juego de palabras con la serie Balmer de líneas espectrales de hidrógeno que lleva el nombre de Johann Balmer . [17]