lunes, 13 de octubre de 2014

¿Cómo debería ser mi tesis de Doctorado de patrones de falla en proyectos de software?

Bertran Meyer menciona que hay muchos material de proyectos fallidos de software y a pesar de ello la industria no ha mejorado. El Viejo me mando con una simple búsqueda de Amazon, que es cierto loa existencia de varios libros que hablan acerca de fracasos en la industria del Software. 

Basado en esta idea realicé tres experimentos sencillos:


  1. Buscar en Google. Lo primero que encontré es esta presentación de Yourdon. Yourdon, padre del análisis estructurado, que luego evolucionó a un análisis orientado a objetos realizó una presentación en el JaSST de Japón en 2007, conferencia especializada en software testing. El nombre de sus presentación hace alusión a su libro “La marcha de la muerte (The death march)”. Dentro de su presentación habla de varios libros que tratan el tema de proyectos de software fallidos. A continuación una breve relación solamente de los que se refieren a proyectos fallidos de software: 1) “La marcha de la muerte” de Yourdon, 2) Software Sytems Falilure an Succes y Assessment and Control of Software risks, 3) Software Project Dynamics de Abdel-Hamid y Madrick, 4) Critical Chain de Goldratt and Demystifying the Black Art de McConell, 5) The Mythical Man Month the Brooks, 6) Software Project Survival Guide también de McConell.
  1. Buscar en Amazon.Lo primero que encontré fue: 1) In search of stupidity: over twenty years of high tech marketing disasters de Chapman, 2) Software runaways: monumental software disasters, 3) Why software gets in trouble (quality software book 2) de Weinberg.Lo que no existe son proyectos de software documentado en detalle, que permitan un análisis de causa raíz que se convierta en un estándar de la industria. Meyer, señala dos casos conocidos. En Amazon, me encontre algo fabuloso: “The Technical and Social History of Software Engineering”, donde en el índice, donde vienen 21 casos documentados, probablemente los únicos existentes, que permitirían identificar el porque de los proyectos fallidos de software. http://www.amazon.com/Technical-Social-History-Software-Engineering/dp/0321903420/ref=pd_ybh_1?tag=donations09-20(insertar imagen).
  1. Al final, busque en Google Scholar. Encontré estos libros: 1) http://mitpress.mit.edu/books/software-development-failures y este artículo muy interesante: Why software fails en la IEEE. Y eso solo buscando, y preguntando a profesionales de la industria.


Persiste entonces la pregunta de Linda Levine y de Bertrand Meyer, “¿Por qué persisten los problemas en desarrollo de software y adquisiciones a pesar del hecho de que han existido desde hace mucho tiempo soluciones a estos problemas?”.

“Einsteing dijo, “locura es siempre hacer lo mismo buscando resultados diferentes”. Lo que propone este anteproyecto de Doctorado puede ser resumido en dos sectores, con una plataforma común. PYMES a través del desarrollo de casos de negocio y su publicación en un observatorio de software, promoción de los materiales y prácticas que han hecho mejorar la industria, en el observatorio y una iniciativa de ley para que los proyectos que tengan que ver con TI y Sw sean públicos y analizados con el objeto de promover mejores prácticas. Si logramos esto contribuiremos a una mejor industria de software, con una solución baja en tecnología. Más social, más humana.

Próximo post:
  1. Ver tres programas de MayDay de Nationa Geographic sobre accidentes en la industria aérea, documentar el patrón de análisis y establecerle como base.

No hay comentarios:

Publicar un comentario