Dos mundos para la estimación de proyectos de software

A primera vista, parece que hay dos mundos para la estimación de proyectos de software, cuál, por simplicidad, Llamaré a los mundos "caótico" y "controlado". El mundo caótico se caracteriza por la mayoría de las organizaciones cuyos proyectos con frecuencia se exceden en tiempo y presupuesto., o que fallan por completo. El mundo controlado tiene una población mucho más pequeña de organizaciones ejemplares cuyos proyectos se afirma que se entregan a tiempo y presupuesto de forma rutinaria.. La pregunta interesante es por qué las organizaciones en el mundo caótico simplemente no aprenden y copian el comportamiento de aquellos en el mundo controlado y se ahorran mucho dinero..
Este artículo explora los dos mundos y pretende explicar las diferencias que son en parte intrínsecas y hasta cierto punto inevitables., y en parte debido a una mezcla de culturas, proceso y factores tecnicos, varios de los cuales se pueden superar con suficiente esfuerzo y perseverancia.
primero, la evidencia de los dos mundos.

El mundo caótico

Ha habido varias encuestas, cubriendo el resultado de miles de proyectos de software, principalmente en los EE. UU. y el Reino Unido y principalmente de proyectos del dominio del software de aplicaciones comerciales, en el sector público o privado. Estrictamente hablando, deberíamos referirnos a 'proyectos de sistemas intensivos en software', ya que para muchos de estos proyectos, la entrega del software es solo una parte de un proyecto que debe entregar un sistema de hardware/software y, a menudo, también un cambio organizacional. Yo uso 'proyectos de software' por simplicidad. Los resultados varían pero indican que entre 10% – 30% de los proyectos de software fracasan por completo, es decir. se detienen antes de entregar algo útil. otro mas o menos 50% excedido en tiempo y/o presupuesto por al menos 10%. Esto deja solo 20% – 40% de proyectos entregados en tiempo y presupuesto.

sin embargo, estas cifras no reflejan el hecho de que muchos proyectos ofrecen menos funcionalidad o valor comercial de lo que se planeó originalmente. Más, una proporción desconocida de los proyectos que terminaron "a tiempo y dentro del presupuesto" bien puede haber sido sobreestimada en primer lugar, por lo que podría haberse entregado más rápido y a menor costo. Abdel-Hamid observó que la Ley de Parkinson se aplica a los proyectos de software como cualquier otra actividad., es decir. el trabajo se expande para llenar el tiempo disponible para su terminación.

El costo de estos excesos y fallas es enorme. Un análisis bien documentado de 105 proyectos de software contratados completados durante los diez años hasta 2007 entre los clientes del sector público del Reino Unido y los proveedores externos tuvo un valor total de £ 29,5 mil millones. De estos, 30% fueron despedidos, 57% promedio de sobrecostos experimentados 30.5% (por un total de £ 9 mil millones de sobrecostos), mientras que 33% sufrió grandes retrasos. Un punto importante a tener en cuenta es que todos estos proyectos fueron realizados por proveedores externos que operan en todo el mundo y afirmarían en su comercialización ser de "clase mundial".. Más, el margen de beneficio de los proveedores en los contratos casi siempre estaba por encima 10%, que van hasta 25%.

Las mismas razones para estas fallas y excesos se citan repetidamente, volviendo al menos 30 años como se describe en el libro Crash! Se dividen en dos grupos principales.

1. Falta de compromiso de la alta dirección y de participación de los usuarios, resultando en objetivos poco claros, lo que conduce a conflictos entre las partes interesadas, y requisitos poco claros y cambiantes.
2. Mala gestión de proyectos (por ejemplo. en la gestión del progreso y los cambios), inexperiencia del personal, especialmente cuando se trata de nueva tecnología, y rotación de personal.

Si bien el costo de las fallas y los excesos puede verse fuertemente ponderado por las cancelaciones en el hardware, el costo de emplear personal adicional, beneficios perdidos, etc., las causas se deben casi invariablemente a problemas con la especificación y el desarrollo del software.

En todos los diversos análisis de por qué los proyectos de software fallan o se exceden, es poco común ver "estimaciones deficientes" enumeradas como una de las causas. Esto no es sorprendente para los proyectos que fallan.. Una mala estimación parece una causa poco probable de abandonar un proyecto. Lo más probable es que se detuviera porque las prioridades cambiaron desde que comenzó y ya no entregará nada útil, o ha durado tanto tiempo más allá del presupuesto original que la gerencia decide reducir sus pérdidas. Pero si, decir, 57% de todos los proyectos de software superados por un promedio de más 30%, uno debe preguntarse '¿hay algo sistemáticamente mal con el proceso de estimación en estos entornos??’

El mundo controlado

De vez en cuando vislumbramos este otro mundo cuando una organización publica resultados que muestran sus éxitos en la estimación de proyectos de software.. El ejemplar que usaré es Renault., el fabricante de vehículos francés, que ha publicado su progreso en la estimación de proyectos de software exitosos, más recientemente en 2014.

Un automóvil familiar promedio moderno tiene aproximadamente 50 Unidades de control electrónico (ecus), pequeños procesadores que forman una red distribuida para monitorear y/o controlar casi todas las funciones, por ejemplo. motor, luces, aire acondicionado, presiones de neumáticos, navegación, información del conductor, etc. Las ECU y su software integrado se compran principalmente a proveedores de componentes con sus sensores asociados., sujeto a las especificaciones emitidas por Renault.
Renault ha estado recopilando datos sobre los costos y el rendimiento de sus proveedores de software de ECU durante algunos años.. El proceso por el cual se contrata para adquirir ECU se describe brevemente:

• Departamentos de software de Renault, especializado por área funcional del vehículo (por ejemplo. tren motriz), desarrollar especificaciones para software de ECU nuevo o mejorado y almacenarlas en la herramienta Matlab Simulink;
• Una herramienta desarrollada por Renault calcula automáticamente un tamaño funcional de cada especificación (o el aumento de tamaño si una mejora) utilizando la norma ISO CÓSMICO método;
• Las mediciones pasadas y las relaciones establecidas estadísticamente se utilizan para predecir el esfuerzo que necesitará el proveedor para desarrollar el software. (ver figura. 1) y su tamaño de memoria (Higo. 2);
• Esta información es utilizada por el Departamento de Compras para negociar el precio de la ECU. Más, la información de que dispone Renault está lo suficientemente consolidada como para que pueda utilizarse para negociar cambios de precios anuales del mismo modo que los fabricantes de automóviles negocian periódicamente los precios de otros materiales como el acero, pinturas, etc, y otros componentes. (Higo. 3);
• Los tamaños funcionales de COSMIC también se utilizan para monitorear el rendimiento del departamento de software interno., ya que Renault ha establecido una relación especificación-tamaño/nivel de personal para su trabajo.

Renault afirma que al final de un nuevo desarrollo de software, la diferencia entre el esfuerzo inicialmente estimado a partir de la correlación establecida y el valor real “tiene que ser inferior al 5%” (ver figura. 4).

Higo. 1 Esfuerzo vs tamaño COSMIC para software ECU

Higo. 2 Uso de memoria frente al tamaño de COSMIC

Higo. 3 Negociación departamento de compras

Higo. 4 Control de precisión de las estimaciones de costes

Diferencias entre los mundos caótico y controlado de la estimación de proyectos de software

En el siguiente, ya que se requieren estimaciones del proyecto de vida completa sea cual sea el enfoque de gestión del proyecto, Usaré un modelo en cascada de las fases del proyecto por conveniencia. Las diferencias al usar un modelo iterativo o ágil se mencionarán a medida que surjan. También debemos asumir que en las comparaciones de los mundos Caótico y Controlado, Las organizaciones en ambos mundos tienen procesos razonablemente repetibles y usan tecnología con la que están razonablemente familiarizadas., es decir. Ignoraremos entornos donde la inmadurez del proceso y los riesgos asociados con el uso de nuevas tecnologías dejan pocas posibilidades de desarrollar métodos de estimación precisos..

Diferentes condiciones para la estimación. En un sentido, es injusto establecer una comparación entre los dos mundos, ya que existen algunas diferencias intrínsecas entre ellos.

La primera y más obvia diferencia es que en el mundo Caótico, por lo general, se necesita una estimación de costos de vida completa para un proyecto de aplicación comercial al principio de su vida, antes de que se conozcan en detalle los requisitos, para informar el análisis de costo/beneficio del software.

A diferencia de, Las estimaciones para completar los proyectos en el mundo controlado de Renault no se realizan hasta que el diseño del software está completamente especificado., es decir. no son realmente estimaciones de toda la vida. En esta etapa, las estimaciones también se pueden hacer a un bajo nivel de descomposición (Bloques de Simulink en el caso de Renault) antes de agregar al costo de todo el ECU.

Claramente, uno esperaría que las estimaciones de Renault fueran mucho más precisas que las realizadas en las primeras etapas de un proyecto típico de aplicación comercial.. Una vez dicho esto, entonces es legítimo preguntarse por qué las estimaciones se hicieron tan temprano en la vida de un proyecto, cuando aun hay tanta incertidumbre, se aceptan como fijos, de modo que con frecuencia se experimentan excesos. Más, los costos continuos de mantenimiento y soporte que contribuyen al caso comercial a menudo resultan ser mucho más altos de lo previsto en esta etapa inicial.

Diferencias culturales. Un estudio de las prácticas de estimación de Jorgensen nos dice mucho sobre la cultura del mundo caótico.. Su investigación encontró que la "estimación de expertos" es la estrategia dominante para estimar el esfuerzo del proyecto de desarrollo de vida completa.. Definió la estimación experta como “el trabajo realizado por una persona reconocida como experta en la tarea, y que una parte significativa del proceso de estimación se basa en un proceso de razonamiento no explícito y no recuperable, es decir. 'intuición''. Aunque esta investigación fue publicada en 2004, Jorgensen me dijo recientemente que no conocía datos publicados que alteraran esta opinión de que la estimación de expertos aún domina la estimación del esfuerzo del proyecto..

A diferencia de, mi observación informal es que las organizaciones en el mundo controlado que publican datos que indican una alta precisión para las estimaciones de proyectos son en su mayoría empresas de fabricación de alta tecnología, a menudo produce software crítico para la seguridad o de misión crítica. Estos proyectos requieren una gran atención a la calidad., por lo que comienzan con el beneficio de una mentalidad de ingeniería 'real', confiar en los datos en lugar de solo en el juicio.

Estas diferencias culturales afectan la precisión de la estimación del proyecto.. daniel kahneman, un psicólogo que ganó el 2002 Premio Nobel de economía describe dos formas de pensar humano, intuitivo y racional. La mayor parte del tiempo pensamos intuitivamente.; se requiere verdadera disciplina para pensar en el modo racional. Su hallazgo más importante relacionado con la estimación es que el pensamiento intuitivo casi siempre es optimista y tiende a ignorar las estadísticas y la experiencia pasada. (por ejemplo. creyendo 'esta vez lo haremos bien'). Recomienda que las decisiones predictivas finales se dejen en fórmulas, y preferiblemente simples con pocas variables.

Aplicar esta recomendación a una estimación de costos de un proyecto basada en el pensamiento intuitivo, por ejemplo. por analogia, sugiere que si el medio ambiente tiene el historial citado anteriormente para los proyectos del sector público del Reino Unido, entonces el caso de negocios debe considerar la 30% riesgo de fracaso total, y cualquier estimación de costo intuitiva debe incrementarse automáticamente en 15% – 20% con el correspondiente aumento de la incertidumbre.

Kahneman tiene otras recomendaciones que son importantes para estimar cuando faltan datos concretos, por ejemplo. el uso de procesos como Delphi de banda ancha (o 'Planning Poker' en el mundo ágil), en lugar de depender de la experiencia de un individuo.

Comprender los roles de los diversos actores involucrados en la estimación. La responsabilidad de un estimador es producir una cifra de esfuerzo del proyecto basada en los mejores datos disponibles., con una declaración apropiada del rango de incertidumbre de la estimación. Eso es todo.

El trabajo del gerente es comprender las suposiciones del estimador., evaluar el riesgo y la incertidumbre, y finalmente decidir sobre el presupuesto del proyecto. Si la mentalidad del gerente es confiar en el estimador e ignorar el riesgo (por ejemplo. con la actitud del manager de Dilbert de 'solo dame un número') el proyecto está condenado a perder su presupuesto.

Más, cuando un cliente emite un ITT para adquirir software de un proveedor externo, el cliente debe comprender otros factores que afectan la forma en que un proveedor llega a sus estimaciones y precios de oferta.

Los proveedores de sistemas de software subcontratados dependen de estimaciones confiables para su supervivencia, y señalamos anteriormente que normalmente tienen un buen historial de rentabilidad.. Por lo tanto, normalmente se toman muy en serio la recopilación de métricas de software y su uso para estimar, mucho más de lo que lo hace un departamento de TI interno típico o la función de TI retenida por un cliente que administra sus proveedores de TI subcontratados.

en un proveedor, la estimación de costos basada en la información de requisitos contenida en el ITT del cliente es convertida por su equipo de ventas en un precio para ganar. En este proceso, tendrán en cuenta muchos factores obvios, como el presupuesto previsto del cliente, la probable competencia, flujo de caja futuro, rentabilidad deseada, etc.

También se consideran otros dos factores menos apreciados pero importantes. primero, a medida que avanza el proyecto, el cliente inevitablemente pensará en requisitos nuevos o modificados que se pueden cobrar más allá del precio de oferta. Segundo, el ganador del proyecto de desarrollo inicial está mejor posicionado para ganar el mantenimiento continuo y el trabajo de soporte durante la vida útil del sistema. Tanto estas actividades adicionales como las continuas pueden ser mucho más rentables que el trabajo de desarrollo inicial.. Como consecuencia, un proveedor puede ofertar bajo por el desarrollo inicial para asegurar una victoria.

Desafortunadamente, cuando comenzó la primera gran ola de subcontratación de TI del sector público del Reino Unido hace más de veinte años, la mayor parte de la experiencia en métricas y estimaciones de software se subcontrató a los proveedores bajo contratos a largo plazo. Esto ha llevado a una grave "asimetría de información" entre los clientes y sus proveedores y es casi seguro que es una de las principales causas del alto nivel de exceso de presupuesto de los proyectos de TI del sector público del Reino Unido..

Para un fabricante de automóviles, la compra es una de sus funciones más importantes. En el caso de la contratación de TI del sector público del Reino Unido, efectivamente, el guardabosques entregó su experiencia en métricas a los cazadores furtivos.

Otra causa de los sobrecostos de los proyectos puede surgir en la forma en que se gestionan las reservas para contingencias.. Estos deben estar en manos de un gerente a nivel de cartera de proyectos y entregados a los gerentes de proyectos según sea necesario., en lugar de asignarse a proyectos individuales desde el principio. primero, el conocimiento de la contingencia incluida en una estimación brinda tranquilidad al gerente del proyecto y la Ley de Parkinson asegura que se utilizará. Lo mismo ocurre con una relación subcontratada, donde Kahneman cita "una reserva presupuestaria es para los contratistas como la carne roja para los leones; lo devoran'.

Técnicas de estimación. Gran parte de la estimación de proyectos de software en el mundo controlado, como lo ejemplifica Renault, intenta responder a la pregunta dominante basada en los costos de "¿qué tan grande es?’ haciendo estimaciones basadas en la experiencia de recuentos de líneas de código fuente (SLOCK). El conocido método de estimación COCOMO II y la mayoría de las herramientas de estimación disponibles en el mercado se han calibrado utilizando tamaños de SLOC como entrada.. A pesar de los muchos, Desventajas a menudo publicitadas de los tamaños SLOC, Por lo general, se afirma que la precisión de la estimación basada en el juicio de expertos a partir de diseños detallados es precisa dentro de 10% a nivel de componente.

En el mundo caótico, si se necesita más que la intuición o el juicio de expertos para las estimaciones cuando solo existen requisitos generales, lo más común es estimar primero el tamaño de los requisitos mediante el análisis de puntos de función (FPA). Luego, el tamaño se convierte en esfuerzo utilizando puntos de referencia de productividad derivados de proyectos similares anteriores.. La idea original de FPA de Albrecht a fines de la década de 1970 de proponer una medida del tamaño de un sistema de software en función de sus requisitos funcionales fue una brillante pieza de pensamiento lateral.. Pero este método, ahora desarrollado y respaldado por la organización IFPUG, esta mostrando su edad.

los método cósmico utilizado por Renault fue diseñado por un grupo internacional de expertos en métricas de software para ser aplicable a los negocios, software de tiempo real e infraestructura, basado en principios fundamentales de ingeniería de software. Las variaciones del método para producir tamaños aproximados están disponibles para medir los requisitos antes de que se conozcan con suficiente detalle para una medición precisa., y el método ha sido o está siendo automatizado por varios medios. (La medición automatizada es crítica para Renault; el conteo manual sería demasiado lento para su proceso de desarrollo.) El método es ideal para medir requisitos en cualquier nivel de agregación en desarrollos ágiles, por ejemplo. Historias de usuarios. iteraciones, lanzamientos, etc., y para los componentes de sistemas distribuidos.

Un ejemplo de un problema que se puede evitar utilizando el método COSMIC surgió en un importante fondo de pensiones europeo que había utilizado el método IFPUG FPA para dimensionar como base para estimar. La escala FPA ofrece solo una gama estrecha de tamaños para transacciones; el método COSMIC mide en una escala de razón sin límite superior. Se investigó un proyecto para descubrir cómo se había subestimado gravemente. Algunas transacciones que obtuvieron el máximo IFPUG de 6 o 7 Los FP se volvieron a medir utilizando el método COSMIC y se encontró que estaban por encima 60 FP CÓSMICOS. Las transacciones con tamaño superior 40 Los FP de COSMIC representaron casi 80% del exceso de presupuesto.

¿Qué se puede hacer para cerrar la brecha de estimación del mundo caótico al mundo controlado??

Se recomienda encarecidamente el consejo de Jorgensen sobre cómo sacar el máximo partido de la estimación del juicio de expertos y se deben tener en cuenta las observaciones de Kahneman sobre la previsión basada en el juicio intuitivo.. Pero si el mundo caótico es cerrar la brecha, debe hacer más que confiar en la estimación intuitiva. Debe recopilar datos duros sobre el rendimiento de los proyectos terminados y desarrollar métodos de estimación sencillos utilizando métodos modernos de medición de requisitos.. Si compra a un proveedor externo, los clientes deben aprender cómo los proveedores determinan sus precios de oferta.

Incluso con estos pasos, Queda el problema intrínseco en el mundo caótico de que a menudo se requieren estimaciones y los presupuestos deben establecerse temprano en la vida de un sistema de software antes de conocer los requisitos en detalle.. En esta etapa, una estimación debe tener inevitablemente un rango muy amplio de incertidumbre.. Entonces, ¿qué se puede hacer para mitigar los efectos de este desafío??

La respuesta es un proceso que fue desarrollado 15 hace años por el Gobierno del Estado de Victoria en Australia, pero nunca se ha aplicado ampliamente.
En esquema simplificado, cuando un cliente emite un ITT con una declaración inicial de requisitos, se pide a los proveedores que calculen el tamaño total final y que ofrezcan un precio fijo por unidad de tamaño funcional. El precio de oferta total es entonces el producto de estos dos factores. Cuando se adjudica un contrato y a medida que evolucionan los requisitos, el precio unitario permanece fijo, pero el precio total variará en proporción al tamaño de los requisitos. El tamaño real es monitoreado por un Scope Manager independiente, un 'supervisor de cantidad' de software. Por lo tanto, el cliente corre el riesgo de variar el tamaño de los requisitos.; el proveedor corre el riesgo de ofertar el precio unitario correcto basado en su conocimiento de las necesidades del cliente y de sus propias capacidades. Con este proceso, las asimetrías de información y riesgo entre el cliente y el proveedor se reducen considerablemente.

El proceso australiano se ha perfeccionado en Finlandia, donde se lo conoce como "Alcance del Norte".. Se está aplicando o probando en varios países.. Los defensores del método afirman que los sobrecostos pueden reducirse dentro de 10%.

Pero los mayores beneficios reclamados son reducciones muy sustanciales en los costos unitarios de software y mejoras en la velocidad de entrega de proyectos de software.. La capacidad de medir los requisitos juega aquí un papel más amplio de lo que podría imaginarse., es decir, como un factor de control de calidad. Si los requisitos no son lo suficientemente precisos como para poder medirlos, el software ciertamente no se puede construir y probar de manera confiable! Se verá que tanto el proceso de Renault para administrar el suministro de software integrado para sus ECU como el proceso de Northern Scope se basan en el precio de la unidad de software como una característica clave..

La métrica de tamaño de punto de función también se puede usar para medir de manera efectiva la calidad del software que se entrega., las herramientas están disponibles para que el mundo caótico cierre en gran medida la brecha con el mundo controlado en la estimación de proyectos de software. Pero no hay balas de plata., no hay respuestas rápidas y listas. Una mentalidad de ingeniería y la disposición a invertir en la recopilación y el análisis de datos de rendimiento reales son esenciales..

Sobre el Autor

Charles Symons es fundador y ex presidente de la Consorcio internacional de medición de software común. Puede contactarlo en cr.symons@btinternet.com. Esta publicación apareció anteriormente en el 2015 boletín de invierno del Sociedad de Análisis de Costos y Pronósticos.

Una publicación de blog representa la opinión personal del autor.
y puede no coincidir necesariamente con las políticas oficiales de Nesma.