De acuerdo al CHAOS Report 2012 el 43% de los proyectos son “Challenged” (fuera de tiempo, presupuesto, o alcance) y el 18% son cancelados. Y casi ninguno de estos fracasos es analizado. El no analizar estos errores impide que aprendamos, para no volver a cometerlos.
El transporte aéreo tiene una tasa de 0.05 muertes por cada mil millones de kilómetros recorridos. Es una industria que ha mejorado continuamente en la seguridad. El día de hoy es más segura que hace 20 años. Y la razón principal es que el 100% de los accidentes o averías importantes son analizados y convertidos a estándares de seguridad obligatorios. No sucede así en la industria del software.
En su blog, Bertrand Meyer hace reflexiones contundentes sobre la diferencia entre las dos industrias. A pesar de que existen foros y sitios web que recopilan errores existen muy pocos analizados a profundidad, ejemplo de estos son: el caso de estudio de Nancy Leveson sobre la Therac-25 y el análisis de Gilles Kahn sobre el accidente del Arian 5. Estos análisis son la excepción. Ambos casos han contribuido a un mejor entendimiento de la industria del software.
No existe una receta única para el éxito en los proyectos de software, generalizando, no existe una receta única para el éxito, como menciona Kough (2011), “después de una vida en los negocios no puedo dar una receta del éxito, Lo que puedo hacer es hablar acerca de cómo perder. Y garantizo que cualquiera que siga esta fórmula será un perdedor seguro“. El detectar las causas de los fallos y evitarlas asegura en consecuencia mejores resultados.
Patrick Eha (2012) hace referencia a la pérdida de 440 millones de dólares por un error en un sistema automático de trading en Nueva York. Pero en ningún lugar se menciona cuales fueron las causas. El análisis sistemático de estos errores podría detectar causas clave: capacidad de los desarrolladores, métodos de calidad poco estrictos, procesos de seguridad deficientes.
Existen muchas maneras de contribuir a la mejora de la industria del software, la investigación sobre temas de avanzada es una de ellas; Meyer(2009) enfatiza que la manera práctica, de baja tecnología es “ aprobar una ley que obligue a analizar de manera profesional cualquier fallo en un proyecto de software”.
De inicio hay varias restricciones que deben ser consideradas: la iniciativa privada es renuente a hacer públicas sus fallas, por cuidar el prestigio de su empresa. La hipótesis es que una ley general a nivel nacional o estatal que requiera que analicen los proyectos de software implica cabildeo legislativo y una gran cantidad de recursos. Pero de inicio, los proyectos finalizados que tengan como fuente de financiamiento en México son públicos por la propia Ley Federal de Transparencia o sus equivalentes en los estados de la República. Estos proyectos pueden ser un inicio. Este sería el enfoque top down.
Planeamos hacerlo de otra manera. El desarrollo de casos de negocio basado en proyectos reales de software, así como la recopilación de artículos y bibliografía existentes sobre proyectos fallidos de software y la construcción de un observatorio de estos proyectos fallidos pueden contribuir para el conocimiento real.
Casi cuarenta años después de la publicación del Mythical Man Month de Frederick Brooks seguimos fallando de la misma manera. Existen varias fuentes de información relacionadas con proyectos fallidos de software: libros, artículos, algunos análisis profundos de fallos en la industria del software en proyectos costosos o críticos a nivel mundial. Pero está información no está disponible para la industria del software de manera directa. Ello hace necesaria un mecanismo para la promoción de los aprendizajes obtenidos del análisis de proyectos fallidos.
Un mecanismo para ello, puede ser la Gestión del Conocimiento puede proveer la base para que está información esté consolidada en un solo lugar y la creación de un Observatorio de Proyectos de Software Fallidos. Siendo una buena idea en el contexto Mundial, el propio contexto de México y Latino América, donde existe una gran cantidad de PYMES que desarrollan software y que cometen errores en su propio contexto requiere un análisis profundo de fallos de software en este nivel. Así pues el alcance se reduce y es más real.
Referencias:
