Modelo en espiral: el modelo para la gestión de riesgos en el de­sa­rro­llo de software

El de­sa­rro­llo de un nuevo software presenta grandes retos para todas las partes im­pli­ca­das. Cuanto más compleja sea la apli­ca­ción que se desea de­sa­rro­llar, más difícil resultará organizar de forma clara el proceso de de­sa­rro­llo y co­n­tro­lar­lo dentro de su co­m­ple­ji­dad. Por esta razón, no­r­ma­l­me­n­te nos apoyamos en planes es­pe­cia­l­me­n­te diseñados paso a paso, de­no­mi­na­dos también modelos de pro­ce­di­mie­n­to. Estos dividen el proceso de de­sa­rro­llo completo en varias fases aba­r­ca­bles de­te­r­mi­na­das por el tiempo y el contenido. Uno de los modelos más conocidos, es­pe­cia­l­me­n­te dirigido a la reducción de riesgos, es el de­no­mi­na­do modelo en espiral, del año 1986.

Barry W. Boehm presentó su enfoque para el de­sa­rro­llo de apli­ca­cio­nes complejas en 1986 y en 1988 el ingeniero de software americano publicó su modelo en la pu­bli­ca­ción A Spiral Model of Software De­ve­lo­p­me­nt and En­ha­n­ce­me­nt también en un contexto más general. En esta pu­bli­ca­ción, describía el modelo en espiral como una posible al­te­r­na­ti­va al modelo es­ta­ble­ci­do hasta entonces, el modelo en cascada, que al mismo tiempo servía como base empírica. A di­fe­re­n­cia del modelo en cascada, en el modelo en espiral no se parte de la base de que las tareas del de­sa­rro­llo del software se organizan de forma lineal, sino que se entienden como tareas ite­ra­ti­vas. Las fases no se realizan de forma única paso a paso, sino varias veces en forma de espiral. Mediante esta re­pe­ti­ción cíclica, el proyecto se va acercando al objetivo de forma re­la­ti­va­me­n­te lenta, pero se minimiza de forma decisiva el riesgo de fracaso del proceso de de­sa­rro­llo gracias a los controles regulares.

Los problemas en el proceso de de­sa­rro­llo pueden tener efectos muy diversos sobre el proyecto general. En cualquier caso, se debe contar con aumentos de costes, gastos adi­cio­na­les y retrasos en el la­n­za­mie­n­to; factores que, es­pe­cia­l­me­n­te para empresas pequeñas, pueden suponer un problema exi­s­te­n­cial. Con su enfoque in­cre­me­n­tal e iterativo, que también contempla el análisis de riesgos periódico mediante diseños de prototipo, análisis o si­mu­la­cio­nes, el modelo en espiral evita estos es­ce­na­rios o al menos suaviza sus co­n­se­cue­n­cias negativas. El proyecto de software tra­n­s­cu­rre de forma continua hasta finalizar el ciclo del modelo en espiral, que pri­n­ci­pa­l­me­n­te abarca los cuatro pasos que aparecen a co­n­ti­nua­ción.

Un ciclo típico del modelo espiral comienza con la va­lo­ra­ción de qué objetivos deben vi­n­cu­lar­se a cada uno de los pasos del de­sa­rro­llo de software. Se puede tratar, por ejemplo, de la mejora del re­n­di­mie­n­to o de la am­plia­ción de la fu­n­cio­na­li­dad. Al mismo tiempo, es el momento de definir las al­te­r­na­ti­vas para la im­ple­me­n­ta­ción (por ejemplo, diseño A vs. diseño B) y de­te­r­mi­nar las co­n­di­cio­nes generales como los costes o la inversión de tiempo.

En el siguiente paso, es hora de evaluar las al­te­r­na­ti­vas, momento en el que los objetivos y las co­n­di­cio­nes generales serán valores de re­fe­re­n­cia decisivos. En esta fase del ciclo del de­sa­rro­llo en espiral, deberán ide­n­ti­fi­car­se los ámbitos de in­se­gu­ri­dad que presenten un riesgo si­g­ni­fi­ca­ti­vo para el progreso del proyecto de software. Después debe seguir la ela­bo­ra­ción de las es­tra­te­gias que presenten menos riesgo y que sean más rentables, para lo cual se podrán utilizar métodos como el modelo de pro­to­ti­pos, si­mu­la­cio­nes, estudios co­m­pa­ra­ti­vos, modelos de análisis y encuestas a usuarios.

Al finalizar el análisis de riesgos, se prosigue con el de­sa­rro­llo real del software, así que esta fase siempre está ca­ra­c­te­ri­za­da por los riesgos relativos restantes. Si el proceso de de­sa­rro­llo está dominado por riesgos de re­n­di­mie­n­to o de interfaz de usuario, o riesgos del control interno de la interfaz, se ofrece primero una es­tra­te­gia de de­sa­rro­llo evolutiva, donde se es­pe­ci­fi­ca el proyecto con más precisión y se optimizan los pro­to­ti­pos. El código real se escribe y se prueba varias veces hasta alcanzar el resultado deseado, que puede servir entonces como base de bajo riesgo para otros pasos de de­sa­rro­llo.

Una vez concluido un ciclo ya se empieza a pla­ni­fi­car el siguiente ciclo. Por una parte, en forma de avance normal del proyecto, si los objetivos de un ciclo se han podido cumplir y se debe definir el siguiente objetivo. Por otra parte, también se puede tratar de encontrar so­lu­cio­nes, en caso de que la etapa de de­sa­rro­llo anterior haya fracasado. En este caso, la es­tra­te­gia seguida hasta entonces se puede sustituir, por ejemplo, con las al­te­r­na­ti­vas definidas an­te­rio­r­me­n­te o con una nueva al­te­r­na­ti­va. De esta forma, se puede intentar conseguir de nuevo el objetivo marcado.

El de­sa­rro­llo de software siguiendo el modelo en espiral es muy popular, sobre todo en proyectos grandes y complejos, en los que el control del pre­su­pue­s­to para pro­mo­to­res y empresas de de­sa­rro­llo tiene especial im­po­r­ta­n­cia. En este caso, todas las partes im­pli­ca­das se be­ne­fi­cian del papel central del análisis de riesgo, que re­pre­se­n­ta la mayor ventaja del de­sa­rro­llo en espiral en co­m­pa­ra­ción con otros modelos de pro­ce­di­mie­n­to. La va­lo­ra­ción periódica de los riesgos resulta es­pe­cia­l­me­n­te ventajosa cuando se aplican entornos técnicos modernos que presentan, por norma general, un potencial de riesgo especial debido a la carencia de valores empíricos.

Asimismo, la es­tru­c­tu­ra cíclica también es una de las ventajas del modelo; los co­n­fli­c­tos entre diseño y exi­ge­n­cias técnicas que se yu­x­ta­po­nen en el software se descartan casi por completo con los controles pe­rió­di­cos. Además, gracias al progreso en espiral, siempre es posible obtener y tener en cuenta el feedback. De esta forma, se pueden integrar a los pro­mo­to­res y a los usuarios en el proceso de de­sa­rro­llo desde el principio. Sin embargo, un requisito im­pre­s­ci­n­di­ble para poder disfrutar de estas ventajas es gestionar el proyecto activa y la­bo­rio­sa­me­n­te, co­n­tro­la­n­do y do­cu­me­n­ta­n­do los ciclos in­di­vi­dua­les de forma continua y minuciosa.

Una prueba de que los numerosos pequeños pasos en los que se divide el de­sa­rro­llo software según el modelo en espiral no siempre ofrecen ventajas es que, a pesar de los variados test, no es poco habitual que algunas partes inaca­ba­das del programa se abran paso hasta el sistema pro­du­c­ti­vo. En co­n­se­cue­n­cia, siempre existe el riesgo de que el producto final presente posibles errores o puntos débiles co­n­ce­p­tua­les. Además, en ocasiones se pueden dar retrasos en el de­sa­rro­llo si en el tra­n­s­cu­r­so de un ciclo o en la pla­ni­fi­ca­ción del siguiente se deben tomar de­ci­sio­nes im­po­r­ta­n­tes que afecten al pro­ce­di­mie­n­to posterior.

A co­n­ti­nua­ción, se presentan las ventajas e in­co­n­ve­nie­n­tes del modelo espiral en forma de tabla:

Por favor, ten en cuenta el aviso legal relativo a este artículo.