Por qué falla el software Escena Imágenes Textos ideas fuerza 1 Por qué falla el software? Audio (locución) Nos gastamos miles de millones de dólares cada año en corregir errores en el software, completamente evitables Por ejemplo: La AdministraciónFederal de Aviación deee.uu.gastó USD $ 2.6 billones, tratando de mejorar su sistema de control de tráfico aéreo, sólo para finalizar el proyecto en 1994. Por qué los proyectos de software fracasan con tanta frecuencia?: Entre los factores más comunes: los Requisitos del sistema son mal definidos Música de fondo En la secuencia de imágenes que visualizará,se desea mostrar la importancia de la Ingeniería de Requisitos, para los diferentes roles que existen en un proyecto de desarrollo de software.
2 3 Cómo lo entendió el líder del proyecto. el cliente explica lo que desea. Cómo lo entendió el líder del proyecto. La primera actividad básica de todo proyecto de desarrollo, es aquella en que el cliente nos explica lo que desea, y lo que él piensa que necesita. El cliente comienza explicando que desea y necesita, un columpio de tres niveles atado a un árbol. Realizando una comparación con un proyecto de desarrollo de software, esta actividad corresponde a la etapa de Ingeniería de Requisitos, siendo la etapa más importante de este proceso, ya que si en esta etapa los requisitos han sido mal entendidos y mal definidos, lo que vendrá posteriormente será un producto de mala calidad, que no se ajusta a las necesidades del cliente, ni del usuario, y lo más importantes no se ajusta a las necesidades del negocio. El jefe de proyecto debe tener un claro entendimiento del alcance y los límites del proyecto. En esta figura se muestra el no entendimiento del dominio del problema, ni las necesidades del cliente. Por una parte el cliente explica que necesita un columpio de 3 niveles, y el jefe de proyecto entiende que necesita un columpio de un nivel.
Este mal entendimiento de las necesidades y del negocio, y del cliente, formulan una especificación de requisitos de software de mala calidad. 4 Cómo lo entendió el ingeniero de diseño? se diseñaron los modelos y objetos del softwarea. Si la especificación de requisitos de software fue mal definida, los modelos y objetos del software, creados por el ingeniero de diseño, estarán claramente alejados de la realidad. En esta imagen queda explicito el problema de una mala especificación de requisitos, la cual repercute directamente en el diseño de los modelos y objetos del software, así como también su arquitectura.
5 Cómo lo codificó el programador? Cómo programador codificó software. el el Dado que los objetos y modelos del software fueron mal creados, el programador lamentablemente codificará el software, según estos modelos. El programador del software, codificará de acuerdo a los modelos y objetos entregados por el Ingeniero de diseño, lo que obviamente se alejará del producto necesitado. 6 Cómo lo describió el ejecutivo de ventas?? el ejecutivo de ventas lo describe. La gente de ventas prometió el oro y el moro: pasa en muchas consultoras. Por un tema de comisiones, o de posicionamiento en el mercado, se ofrece una solución "inflada" que no corresponde con lo que podemos hacer. En esta imagen se quiere mostrar las incongruencias entre los distintos estamentos que participan del proceso. Los ejecutivos de ventas, generalmente venden un producto que jamás llegará a ser lo prometido.
7 Cómo fue documentado el proyecto Cómo el proyecto fue documentado Lamentablemente esto es una constante en todos los proyectos de desarrollo de software. La documentación se deja de lado para darle espacio a la codificación o pruebas. Esto generalmente sucede cuando los proyectos están atrasados, y esto sucede generalmente por haber llevado a cabo una pésima ingeniería de requisitos. 8 Cómo se facturó al cliente? El cómo se facturó al cliente Se elevan las expectativas al cliente, ofreciéndole un producto de primer nivel, y cobrándole por aquello. Generalmente, y por lo problemas descritos anteriormente, los proyectos comienzan a atrasarse, a no cumplir con los hitos y compromisos de entregas de productos, y toda esta diferencia en los presupuestos proyectados y reales, son de alguna forma traspasados al cliente.
9 El cómo soporte entrega la ayuda postventa. la mesa de ayuda entrega el soporte Una vez que los productos de software son entregados, estos carecen de un adecuado soporte, o mantención. Dado que en las etapas anteriores han sido consecuencias de su inmediata anterior, quienes están a cargo del soporte, difícilmente podrán dar un buen servicio, ya que a ese nivel, no hay nada que hacer para la mejora del producto. Dado que estas etapas son consecuencias de las inmediatamente anteriores, 10 Lo que el cliente realmente necesitaba El producto que finalmente se debería haber realizado, es muy distinto de lo que el cliente deseaba y que vimos en la primera imagen. Si comparamos la primera imagen con esta última, veremos que existe una notoria diferencia. Esto sucede muy a menudo en todo tipo de proyectos, y tiene que ver con que algunos jefes de proyecto, toman muy a ligera la Ingeniería de Requisitos, y no le otorgan el tiempo, las personas, y los recursos necesarios para su ejecución.
En estas secuencias de imágenes, queremos evidenciar la importancia de la Ingeniería de Requisitos, la cual es la guía para las etapas posteriores, y por ende para el proceso de desarrollo completo.