Reporte sobre los artículos: Gestionando el desarrollo de grandes sistemas de software por Dr W. Royce y Modelo Espiral para el desarrollo y mejora de software por Dr B. Boehm Ing. Alison Munoz Capote 25 de septiembre de 2019 1 Introducción A partir del análisis de los modelos en Cascada y Espiral, los cuales se utilizan para el desarrollo de grandes sistemas de sofwatre, el presente trabajo pretende abordar la problematica existente en cada momento por lo cual se realizaron las propuestas. También se explica cómo cada modelo soluciona dichos problemas y posteriormente se elabora una matriz descriptiva para cada caso. El modelo en cascada El modelo de desarrollo en cascada fue propuesto a principio de la década de los 70, en pleno apogeo de la crisis de software. En esa época, el desarrollo de programas para computadoras se concentraba solo en dos actividades: análisis y codificación, sin importar que tan complejo o grande fuera el programa. Este modelo funcionaba hasta cierto punto, mientras que el programa fuera para el uso de los propios desarrolladores. En caso de que el programara fuera complejo, o de un tamaño considerable y para clientes que no participaran en el proceso de desarrollo, aplicar solo estas dos actividades implicada invertir demasiado tiempo, esfuerzo, recursos, y sin dudas, eran proyectos destinados al fracaso ya que el desarrollo se volvía insostenible. Es importante destacar, de que la experiencia del Dr Royce, era fundamentalmente en proyectos espaciales, ya que trabajaba en la división espacial de TRW Inc. en el momento que propuso el modelo. En función de resolver el problema que generaba este modelo, Royce plantea la incorporación de 5 actividades más en el proceso de desarrollo. Dos antes del análisis, que serían los requerimientos de sistema y los requerimientos del software (lo cual se podría englobar en análisis de requerimientos). Después del análsis, vendría el diseño del sistema seguido de la implementación. Posteriormente, y como últimas dos actividades vendrían las pruebas y las operaciones (mantenimiento). Royce se percató de que este primer modelo presentaba un problema con altos riesgos: durante el período de pruebas, se podrían arrojar fallos en cuanto a funcionamiento del sistema (elaboración del software de la manera correcta). Estos fallos, en casos de ser de gran magnitud, pueden implicar realizar cambios considerables tanto en el diseño como en los requisitos del software. Cambios de esta magnitud en una de las actividades finales, podría afectar de manera desiciva el exito del proyecto, por el esfuerzo, tiempo y recursos que serían necesarios para resolver los fallos detectados. Para eviar este riesgo, Roy propone 5 criterios: 1. Primero el diseño Esta etapa iría antes del análsis. El propósito que persigue es realizar el diseño de un prototypo de software (con sus modos de procesamiento de datos) bien documentado, que incluya todas las etapas del desarrollo. Una de las restricciones es que esta etapa debe comenzar únicamente con los diseñadores. El objetivo fundamental es que cada trabajador de proyecto, sin importar la fase en la que se encuentre, tuviera una idea general del sistema. 2 2. Documentar el diseño Considerado el criterio más importante. Se enfoca de la suma importancia de documentar tanto y tan detallada como sea posible, en cada una de las etapas del desarrollo. Hace énfasis de que el éxito del proyecto, depende en gran medida de su documentación, ya que esta permite en cada etapa, una plena comprensión del sistema que se está desarrollando y del estado en el que se encuentra, sin necesidad de terceros y sin los riesgos de los malos entendidos del lenguaje natural. 3. Repetirlo dos veces La idea es simular, a partir del diseño preliminar, cada una de las etapas del software realizando un prototipo o primera versión del proyecto. Se establece el uso de un tercio del tiempo total estimado para el proyecto. Este prototipo permitirá corregir los aspectos más criticos detectados y utilizar esta información en cada una de las actividades correspondientes. 4. Planear, controlar y monitorear las pruebas Se condidera la etapa crítica debido a que detecta, en términos de funcionales, el éxito del proyecto ya que todo problema que se detecte en esta etapa, tiene un margen bien reducido de solución. Los criterios antes mencionados, se establencen con el propósito de que las pruebas muestren un resultado exitoso para el proyecto disminuyendo así los riesgos de esta etapa. Es por ello que se pretende que se hagan con exigencia y de forma municiosa. 5. Involucrar al cliente Una de las novedades del modelo en cascada, y sobre todo para esta época, era la propuesta de que el cliente estuviera involucrado en distintas etapas del desarrollo con el objetivo de, dentro de los límites, ir valindando parcialmente los resultados del producto. Téngase en cuenta que en el contecto donde se propuso este modelo, los mayores conocedores del dominio del problema, eran los clientes. El modelo en espiral El modelo en espiral, el cual fue publicado por primera vez en 1986 como alternativa a los modelos de la época, predominando fundamentalmente el Modelo en Cascada. Boehm, realiza un análisis de los grupos de modelos usados en el desarrollo de software para ese entonces, e indentifica los principales problemas de cada uno, los cuales se muestran a continuación. 1. Modelo codifica-corrige Fue el primer modelo de desarrollo de software, en el cual se manifiestan los siguientes problemas: 3 a) El código se volvía rápidamente pobre en su estructura después de un número de correcciones. b) El usuario no participaba en el desarrollo lo que probocaba que no se desarrollara el software correcto o que los cambios a realizar se volvieran inviables. c) Era muy costoso realizar correcciones porque existia una insuficiente preparación para las pruebas y/o modificaciones. 2. Modelo en Cascada Fue el modelo propuesto, fundamentalmente para resolver los problemas planteados por el modelo codifica-corrige(fue descrito anteriormente). Las principales dificultades que presenta son: a) Énfasis en la elaboración detallada y completa de la documentación como criterios de finalización en fases tempranas del proyecto (por eso es considerado un modelo rígido). b) El principio anterior es poco aplicable a sistemas de software altamente interactivos con el usuario-final durante el proceso de desarrollo. c) Elaboración de documentación con poca comprensión de las interfaces de usuario y/o de las funciones de soporte para la toma de desiciones, probocando el diseño y desarrollo de código inservible. 3. Modelo de desarrollo evolutivo En este modelo las etapas están definidas a partir de la expansión de los incrementos de un producto de software operativo. Se utiliza fundamentalmente cuando el usuario no sabe describir exactamente el tipo de producto que necesita. Los problemas que presenta son los siguientes: a) Ausencia de planificación y código deficiente en estructura y de alto costo en cambios. En este aspecto, este modelo se considera una versión modificada del modelo codifica-corrige. b) Es basado en la mítica suposición que el sistema operativo del usuario será lo suficiente flexible las rutas sin planear de este modelo. c) Prioriza la flexibilidad para el cambio en el código por encima de las consideraciones arquitectónicas y de uso a largo alcance. 4. Modelo de transformación Se propone con el propósito de resolver el problema del código de spaguettis provocado por los modelos anteriores incluyendo el modelo en cascada. Asume la existencia de la capacidad para convertir una especificación formal en un producto de software en el programa de manera que satisfaga la especificación. Aunque resuelve en alguna medida estos problemas, genera también los siguientes: a) Las capacidades de transformación automaticas, solo se encuentran en pequeños productos en áreas muy limitadas. b) El modelo de transformación presenta los mismos problemas del modelo de desarrollo evolutivo respecto a la suposición mítica de sistemas flexibles al cambio sin planificación. 4 El modelo en espiral pretende abordar y resolver cada una de estos problemas, mostrándose como un modelo ajustable a cada uno de los anteriores y teniendo como base el refinamiento de varios modelos basados en el modelo en cascada. Es un modelo orientado al riesgo, donde cada uno de los ciclos de la espiral aborda cada una de las etapas establecidas en el modelo en cascada. Cada ciclo construye un prototipo del producto que aumenta en tamaño y en complejidad ya que es progresivo. El ciclo comienza identificando los siguientes aspectos: Objetivos de la porción del producto a elaborar. Alternativas de implementación en esta porción. Las restricciones impuestas por las alternativas planteadas (permite la evaluación de riesgos). Este enfoque de objetivos-alternativas-restricciones-evaluación de riesgos y posterior planificación para la siguiente fase, permiten al modelo tal flexibilidad que podría de esta forma ajustarse a cualquier enfoque de desarrollo de software. Matriz descriptiva Cascada Espiral Análisis Problema Solución Código pobre en su estruc- Crear fase previa de diseño. tura después de un número de correcciones. Elaboración de software in- Crear fase previa de requecorrecto o cambios difíciles rimientos. de realizar. Insuficiente preparación pa- Planificación y preparación ra las pruebas y/o modifica- para las pruebas en primeciones. ras etapas. Incorporación de 5 pasos adicionales al modelo en vista a disminuir al máximo los riesgos en la etapa final del proyecto. Sistemas rígidos orientados Ciclos incrementales con a la documentación elaboración de objetivos para cada uno y desarrollo de prototipos. Sistemas flexibles orienta- Gestión de alternativas y dos al código riesgos en cada ciclo. 5
