La ingeniería busca satisfacer unas necesidades de acuerdo a un presupuesto, en un plazo determinado y con una calidad objetivo. El “triángulo de gestión” establece que la calidad se deriva de las siguientes restricciones: alcance, plazos y presupuesto. De esta forma, si se desea mantener la calidad constante, un cambio en una restricción implica cambios en las otras, por ejemplo, si se desea reducir el coste habrá que reducir el alcance o aumentar los plazos.

Sin embargo, la “Ley de Brooks”, corrige el triángulo de gestión en los proyectos de software. 

El ingeniero de software debe ser consciente del impacto económico que sus decisiones tienen sobre el producto software protegiendo en todo momento la inversión.

Existen algunas métricas que ayudan a medir el valor, como el KPI, Key Performance Indicator. Estas métricas proporcionan una cantidad importante y valorable de información que ayuda en la toma de decisiones.  Un KPI es una cuantificación de un desafío importante de negocio, un valor numérico en el que subyace la importancia de la conexión entre este y los retos de negocio.

La naturaleza intangible del producto software hace que no sea necesario la provisión de materias primas para su construcción. Los costes del producto software es prácticamente la suma del coste del tiempo de trabajo que los diferentes técnicos han invertido durante su construcción. Además del coste del tiempo puede añadirse al cálculo la amortización de hardware (estaciones de trabajo, servidores, etc.) y el precio de las licencias de herramientas utilizadas por los técnicos (Sistemas de control de versiones, plataformas de integración continua, etc.), aunque estos costes suelen ser despreciables en comparación del coste del tiempo del trabajo en proyectos de cierta envergadura.

En los 80s y 90s se popularizó un modelo de gestión de costes denominado COCOMO. El Modelo Constructivo de Costos (COCOMO, por su acrónimo del inglés) es un modelo matemático de base empírica, derivado de la experiencia, utilizado para estimación de costes. Incluye tres submodelos, cada uno ofrece un nivel de detalle y aproximación, cada vez mayor, a medida que avanza el proceso de desarrollo del software: básico, intermedio y detallado. Este modelo fue desarrollado por Barry W. Boehm a finales de los años 70 y comienzos de los 80, en su libro "Software Engineering Economics". La utilización del número de líneas de código como uno de los parámetros, así como la complejidad de los cálculos, ha hecho disminuir su influencia. Actualmente apenas es utilizado, en su lugar se utiliza el “juicio del experto” o los costes reales derivados de la construcción de otro producto software de naturaleza similar como principal criterio a la hora de estimar el coste. El “juicio del experto” no hace referencia necesariamente a una persona, es habitual que la valoración sea realizada por el equipo técnico de desarrollo.

El esfuerzo de desarrollo puede ser medido con “puntos función” o con “puntos historia”:

• Los Puntos Función son una métrica que pretende establecer el tamaño en función de la complejidad de los requisitos. Es habitualmente utilizada en la visión predictiva. Es necesario requisitos muy detallados para poder extraer todos los parámetros necesarios para calcular los “puntos función” (existe una fórmula predefinida).

• Los Puntos Historia son una métrica para establecer el “tamaño” de una Historia de Usuario (HU) en función del esfuerzo. Una HU de dos Puntos Historia se estima que requerirá el doble de esfuerzo que una HU de un único Punto Historia. Los Puntos Historia se obtienen a partir de la propia experiencia del equipo de desarrollo. La estimación de los puntos de historia es realizada por el propio equipo durante el planning meeting, habitualmente a través de una liturgia conocida como “planning poker”.

La deuda es el coste futuro, el esfuerzo pospuesto. En 1992, Ward Cunningham, firmante del Manifiesto Ágil, introdujo la metáfora de la deuda técnica para explicar a roles no técnicos la importancia de la recodificación sistemática de código heredado. El término deuda técnica surge de una analogía entre un desarrollo de software y la petición de un crédito financiero. De igual forma que un crédito permite obtener liquidez a corto plazo a costa del pago de futuros intereses, las carencias introducidas durante el desarrollo del software proporcionan un beneficio a corto plazo (la entrega a tiempo de una versión del software) pero en un futuro requerirán gastar el tiempo inicialmente ahorrado sumado a un esfuerzo extra (los intereses), es decir, dichas carencias generarán una deuda técnica con los mismos aspectos negativos que los intereses del crédito financiero solicitado.

La refactorización es la modificación en el código del producto que no implica cambio funcional alguno. El objetivo de estas refactorizaciones no es entregar más valor al cliente, sino hacer el software más fácil de mantener y evolucionar reduciendo de esta forma la “deuda técnica” que suele acumularse con el aumento de líneas de código. Las refactorizaciones del producto software pretenden el último término abaratar los costes de evolución y mantenimiento reduciendo los futuros “intereses”. 

La deuda no es negativa en sí misma, la deuda permite financiar el desarrollo entregando valor “cuanto antes”. Sin embargo, la premura por realizar ciertos desarrollos puede llevar a los programadores a desplegar en producción código de baja calidad, código difícil de entender cuya evolución y mantenimiento requiere de mucho esfuerzo. Esta deuda comenzará a resultar problemática cuando sea necesario modificar el código, por ejemplo, si se desea cambiar la funcionalidad ofrecida por el software, es en ese momento cuando la deuda comenzará a cobrarse intereses. 

El riesgo es la posibilidad de ser expuesto a una circunstancia adversa o no deseada. En la visión predictiva es fundamental la gestión activa del riesgo. Es imprescindible identificar los riesgos, analizarlos y definir el plan de acción en cada caso. El análisis del riesgo suele basarse en una matriz donde medir la gravedad del impacto y la probabilidad de que el riesgo se materialice. El plan de riesgos y la matriz impacto/probabilidad suelen documentarse en una hoja de cálculo.

En la visión adaptativa la gestión del riesgo no requiere la generación de tantos artefactos. La propia naturaleza del método de construcción implica la mitigación o reducción de riesgo. La visión adaptativa es segura “por definición”. Las iteraciones cortas y las entregas incrementales del producto permiten detectar y corregir de forma temprana si el producto no satisface las necesidades del cliente. La construcción basada en pruebas automatizadas reduce los errores en el software. Las metodologías ágiles se fundamentan, no en la construcción rápida, sino en la construcción “segura”, minimizando los riesgos.

La matriz Valor vs Coste es un elemento básico de la priorización de productos, es simple y eficaz. Es suficiente con estimar para cada nueva funcionalidad a incorporar al producto software su valor (impacto) y su coste (esfuerzo). De este modo cada funcionalidad queda representada por un punto en el diagrama valor vs coste. Es sencillo evaluar qué funcionalidades deben incorporarse al producto y cuales deben descartarse. Aquellas funcionalidades que aporten mucho valor con poco coste deben desarrollarse. Por el contrario, aquellas funcionalidades que no aporten valor y que impliquen un gran esfuerzo de desarrollo no deben desarrollarse.

Tanto la ley de brooks, como la matriz valor vs coste, son reglas heurísticas, han sido deducidas a partir de percepciones y experiencias obtenidos en la realización de múltiples proyectos. Estas leyes, reglas y técnicas no surgieron de un modelo científico, sino de la intuición. La formulación de estas “leyes” suponen el fundamento cualitativo para las metodologías y prácticas utilizadas en la ingeniería del software.