Get best of the week

Cambiar los requisitos del proyecto es un problema clave de desarrollo de software


Pasos para desarrollar un gran programa informático para la entrega al cliente La

ilustración anterior es de un artículo de1970del Dr. Winston Royce, "Gestión del desarrollo de grandes sistemas de software". Se cree que esta es la primera descripción de un modelo en cascada en ingeniería de software. Los diagramas del Dr. Royce se han extendido por cientos de libros de texto y artículos. Pero a menudo olvidan el hecho de que el inventor de la cascada escribió de inmediato: "Esta implementación particular es arriesgada y conlleva un fracaso".

Desarrollamos software para satisfacer las necesidades de cualquier cliente, usuario o mercado. La tarea de la ingeniería de software como un campo de la informática es hacer que este desarrollo sea predecible y rentable.

Han pasado más de 50 años desde el primerConferencias de ingeniería de software IFIP , y durante este tiempo, se han propuesto muchas técnicas, procesos y modelos diferentes para ayudar a los desarrolladores a lograr este proceso predecible y rentable. Pero incluso después de medio siglo, tenemos los mismos problemas de siempre: retraso, resultados insatisfactorios y fracaso total de los proyectos.

Tome el contrato del gobierno en el que trabajé hace muchos años. Este es, sin duda, el proyecto más exitoso en el que he trabajado, al menos desde el punto de vista de los indicadores normales de gestión del proyecto: se completó antes de lo previsto, dentro del presupuesto y pasó la prueba de aceptación mensual en solo tres días.

Hubo algunas restricciones inusuales para este proyecto. El contrato fue nominado y pagado en moneda extranjera con un precio fijo absolutamente fijo. El contrato no preveía ningún proceso de gestión de cambios. La prueba de aceptación en realidad se presentó como parte del contrato en forma de una serie de pruebas observables "hacer esto y aquello": se aprobaron las pruebas de aprobación (sí / no) con muy poco espacio para disputas. Debido a los términos del contrato, todo el riesgo de cualquier cambio en los requisitos o tipos de cambio recae en mi empresa.

El proceso fue una cascada clásica absolutamente sólida, y avanzamos con confianza por las etapas hasta que se completó, instaló el sistema final y se aprobó y aceptó la prueba de aceptación.

Después de lo cual trabajé con el sistema durante otros 18 meses, modificándolo hasta que realmente satisface las necesidades de los clientes. El hecho es que durante el año entre la firma del contrato y la entrega del software, los formularios de informes cambiaron, algunos componentes de la plataforma de hardware fueron reemplazados por productos nuevos y más avanzados, y se hicieron modificaciones a las regulaciones a las que el sistema debería responder.

Los requisitos están cambiando. Todos los proyectos de desarrollo de software encontrarán en algún momento este difícil problema.

Por lo tanto, todos los procesos de desarrollo de software pueden considerarse varias soluciones a este problema fundamental. El proceso inicial (e ingenuo) de la cascada simplemente asumió que podría comenzar aprobando firmemente los requisitos que deben cumplirse.

Se cree que la primera descripción de la cascada fue dada por el Dr. Winston Royce en "Gestión del desarrollo de grandes sistemas de software" . Las ilustraciones en cientos de trabajos de ingeniería de software, libros de texto y artículos son diagramas reconocibles que él creó. Pero a menudo se olvida que en el artículo original, Royce también dice: "[Esta] implementación [en el diagrama] es arriesgada y conlleva un fracaso".

Proceso de alineación con el entorno


La observación de Royce, de que cada desarrollo pasa por ciertas etapas, desde la definición de los requisitos y la solución propuesta, hasta la creación de software y luego probar que cumple con estos requisitos, fue buena. De hecho, cada programador está familiarizado con esto, incluso desde las primeras tareas escolares en informática. Pero si sus requisitos cambian a lo largo del proyecto, se le garantiza que no podrá satisfacer al cliente, incluso si satisface por completo los requisitos iniciales.

De hecho, solo hay una respuesta: debe encontrar una manera de asegurarse de que el ciclo de requisitos-desarrollo-entrega coincida con la velocidad a la que cambian los requisitos. En el caso de mi proyecto gubernamental, lo hicimos artificialmente: en ausencia de cambios significativos, fue fácil construir el producto de acuerdo con las especificaciones y pasar las pruebas de aceptación.

El artículo original de Royce realmente reconoció el problema de los cambios en el proceso de desarrollo. Su artículo describe un modelo iterativo en el que los cambios inesperados y las decisiones de diseño inoperantes devuelven el proceso a la etapa de desarrollo.


Este proceso no se limita a pasos sucesivos. Ilustración de un artículo de Winston Royce

Realismo en el desarrollo de software.


Una vez que aceptamos que el desarrollo de software siempre es inherente a la incertidumbre de que los requisitos nunca permanecen sin cambios con el tiempo, podemos comenzar a desarrollar formas de hacer frente a los cambios inevitables.

Comience por aceptar que el cambio es inevitable .

Cualquier proyecto, sin importar cuán bien planificado, será al menos ligeramente diferente de lo que se había previsto originalmente. El proceso de desarrollo debe aceptar esto y estar listo para la acción.

Como consecuencia de esto, el software nunca termina, sino que solo se abandona .

Nos gusta celebrar un momento especial, claramente definido, cuando el proyecto de desarrollo se "completa". Sin embargo, la realidad es que cualquier punto fijo en el tiempo cuando decimos "todo está hecho" es simplemente una línea divisoria artificial. Las nuevas funciones, las funciones revisadas y las correcciones de errores comenzarán a llegar desde el momento en que se entrega el producto "terminado" (de hecho, en el momento en que se lanza el software, los cambios seguirán siendo necesarios, lo que representa una deuda técnica y requisitos diferidos). Estos cambios continuarán mientras se utilice el producto de software.

Esto significa que ningún producto de software es absolutamente satisfactorio.. El desarrollo de software real es similar a disparar a un objetivo en movimiento: todas las variaciones aleatorias del objetivo, el movimiento del objetivo, el viento y la vibración garantizan: aunque puede estar cerca de dar en el blanco, nunca alcanzará la perfección.

Cambio de proceso para adaptarse al entorno.


Con esta visión, el desarrollo de software puede parecer bastante deprimente, incluso sombrío. Todo suena como si los conceptos de desarrollo predecible y rentable fueran un sueño imposible.

No, no se trata de eso. Nuestra tesis es que podemos convertirnos en desarrolladores muy efectivos si tenemos en cuenta las realidades.

La primera realidad: aunque la perfección en sí misma es inalcanzable, el éxito pragmático es completamente posible. El movimiento LEAN startup lo ha convertido en un objetivo común para las startups MVP, un "producto mínimo viable". Debemos extender esta idea a todos los desarrollos y reconocer que cada producto es de hecho MVP, nuestra mejor solución aproximada para una comprensión actual del problema.

La segunda realidad es que realmente no podemos detener los cambios en los requisitos, por lo que debemos trabajar en tales condiciones. Esto se ha entendido durante mucho tiempo en el desarrollo real: la regla de Parnassus prevé dividir el sistema en módulos para aumentar la flexibilidad del sistema en caso de cambios. Al mismo tiempo, se han hecho intentos repetidos para describir los procesos de desarrollo de software con aproximaciones sucesivas, es decir, procesos de desarrollo incrementales (a esto le llamé la metodología Once and Future).

¿Tan pronto como lo reconozcamos? Si necesitamos un desarrollo gradual, tan pronto como nos liberemos del concepto de una solución ideal, podemos aceptar los cambios con cierta tranquilidad.

La tercera y última realidad es que cualquier horario es solo horario. Entramos en el proyecto de desarrollo, sin poder decir exactamente cuál será el producto final. Debido a esto, ninguna predicción temprana del tiempo de finalización puede ser precisa, y todas las versiones finales serán temporales.

El desarrollo ágil viene al rescate


Fuera del reconocimiento de estos hechos, surgió el Manifiesto Ágil. El lanzamiento regular de software de trabajo es parte de este reconocimiento: un proyecto verdaderamente flexible lanza regularmente implementaciones de trabajo, pero no finales. Una estrecha relación con el usuario final asegura que cuando los cambios en los requisitos se hagan evidentes, puedan integrarse en el plan de trabajo.

Idealmente, en un proyecto flexible en una etapa muy temprana ya existe una implementación funcional, y el progreso sistemático notable gradualmente conduce al lanzamiento de un producto satisfactorio. Recuerde la metáfora del tiro al blanco: a medida que avanzamos, nos estamos acercando cada vez más a la manzana. Por lo tanto, podemos estar seguros de que con el tiempo el producto estará al menos cerca de la meta.


More articles:


All Articles