METODOLOGÍA ESPIRAL
En el proceso de desarrollo de software, un sistema informático está compuesto por hardware y software. El buen funcionamiento del hardware es, en principio, comparable a la de cualquier otro equipo de cómputo existente.
Respecto al software, su construcción y resultados han sido en el pasado cuestionados debido a los problemas asociados a ellos:
* Los programas "se caen" con cierta frecuencia.
* Los costes del software son difíciles de prever y normalmente superan las estimaciones propuestas con anterioridad.
* La modificación del software es una tarea difícil y costosa.
En el desarrollo de software, se establece algunas particularidades como los modelos de ciclo de vida del software, uno de estos modelos es el llamado "El Modelo Evolutivo Espiral" cuyo autor es Barry Boehm (1988), este tipo de modelo permite tener en cuenta el riesgo que aparece al momento de desarrollar software, se comienza analizando las diferentes alternativas de procesos en el diseño del software, se selecciona el riesgo más asumible y se hace un ciclo de la espiral. Si el usuario requiere hacer avances en el software, se evalúa las diferentes alternativas y riesgos y se realiza un nuevo giro a la espiral, así hasta que llegue un momento en el que el software diseñado sea aceptado y no necesite mejorarse con un nuevo ciclo.
PROCESO DE DESARROLLO DE SOFTWARE
El desarrollo de un software en sí es complejo, es usualmente no viable conseguir un 100% de confiabilidad de un programa por pequeño que sea. Existe una gran combinación de factores que imposibilitan realizar una verificación minuciosa de todas las posibles situaciones de ejecución que se puedan presentar. Poniendo como ejemplo la creación de un sistema operativo, esto es una tarea que requiere proyecto, gestión, numerosos recursos y todo un equipo disciplinado de trabajo.
Un desarrollo de software es imperceptible y por lo general muy abstracto, esto pone trabas en la definición del producto y sus requisitos, más que nada cuando no se tiene precedentes definidos de un desarrollo de software similar. Esta situación va hacer que los requisitos sean difíciles de consolidar con anterioridad. Es por esto que ahora los cambios en los requisitos son inevitables, no sólo después de entregado el producto sino también durante el proceso de desarrollo.
Sea cual fuere el proceso utilizado y aplicado al desarrollo del software, casi siempre libremente de este proceso, se debe aplicar un modelo de ciclo de vida. Según varias fuentes consultadas se estima que, del total de proyectos software grandes emprendidos, un 28% fracasan, un 46% caen en severas modificaciones que lo retrasan y un 26% son totalmente exitosos.
Cuando un proyecto de desarrollo de software "fracasa" (28% estadísticamente), muy rara vez es causado por fallas técnicas, principalmente el origen de los fallos y fracasos es la falta de aplicación de una buena metodología o procesos de desarrollo. Una fuerte tendencia, desde hace pocos años, es mejorar las metodologías y procesos, o crear nuevas e incentivar a los profesionales de la informática en su aplicación adecuada, normalmente utilizan sus conocimientos especializados con modelos, paradigmas y procesos obsoletos que ya fueron diseñados.
DEFINICIÓN DE UN MODELO PARA EL DESARROLLO DE SOFTWARE
Un modelo para el desarrollo de software es una perspectiva de las actividades que ocurren durante el diseño y el desarrollo del software, se pretende determinar el orden de las etapas implicadas en el sistema y los criterios de transición asociadas entre estas etapas. Un modelo de ciclo de vida del software:
*Describe las etapas primordiales del desarrollo de software.
*Define las etapas primarias esperadas para ser aplicadas durante esas etapas. Ayuda a administrar el progreso del desarrollo, y
*Provee un espacio de trabajo para la definición de un detallado proceso de desarrollo de software.
Así, los modelos por una parte proveen una guía a los ingenieros de software con el fin de establecer las diversas actividades técnicas en el proyecto, por otra parte suministran un marco para la administración del desarrollo y el mantenimiento del software, en el sentido en que permiten estimar recursos, definir puntos de control intermedios, monitorear el avance, etc.
ALTERNATIVAS DE MODELOS PARA EL DESARROLLO DE SOFTWARE MODELO ESPIRAL
El modelo espiral en el desarrollo del software es un modelo meta del ciclo de vida del software donde el esfuerzo del desarrollo es iterativo, tan pronto culmina un esfuerzo del desarrollo por ahí mismo comienza otro; además en cada ejecución del desarrollo se sigue cuatro pasos principales:
1. Determinar o fijar los objetivos.
En este paso se definen los objetivos específicos para posteriormente identifica las limitaciones del proceso y del sistema de software, además se diseña una planificación detallada de gestión y se identifican los riesgos.
2. Análisis del riesgo.
En este paso se efectúa un análisis detallado para cada uno de los riesgos identificados del proyecto, se definen los pasos a seguir para reducir los riesgos y luego del análisis de estos riesgos se planean estrategias alternativas.
3. Desarrollar, verificar y validar.
En este tercer paso, después del análisis de riesgo, se eligen un paradigma para el desarrollo del sistema de software y se lo desarrolla.
4. Planificar.
En este último paso es donde el proyecto se revisa y se toma la decisión si se debe continuar con un ciclo posterior al de la espiral. Si se decide continuar, se desarrollan los planes para la siguiente fase del proyecto.
Con cada iteración alrededor de la espiral, se crean sucesivas versiones del software, cada vez más completas y, al final, el sistema de software ya queda totalmente funcional.
La diferencia principal entre el modelo espiral y los modelos anteriores (ej.: cascada, evolutivo, incremental, etc.) es la evaluación del riesgo. El riesgo es todo lo que pueda salir mal en un proyecto de desarrollo de software. Por ejemplo, si queremos utilizar un lenguaje de programación para desarrollar un sistema operativo, un riesgo posible es que los compiladores utilizables no produzcan un código objeto eficiente. Los riesgos originan problemas en el proyecto, como el exceso de los costos. Es así que, la disminución de los riesgos es una actividad muy importante.
Un modelo espiral comienza con la determinación de los objetivos tanto funcionales como de rendimiento. Después se enumeran algunas formas posibles de alcanzar estos objetivos identificando las fuentes de riesgos posibles. Luego continuamos con el siguiente paso que es resolver estos riesgos y llevar a cabo las actividades de desarrollo, para finalizar con la planificación del siguiente ciclo de la espiral.
CARACTERÍSTICAS DEL MODELO EN ESPIRAL PARA EL DESARROLLO DE SOFTWARE
Es considerado como un modelo evolutivo ya que combina el modelo clásico con el diseño de prototipos.
Contiene una nueva etapa que es el análisis de riesgos, no incluida anteriormente. Este modelo es el indicado para desarrollar software con diferentes versiones actualizadas como se hace con los programas modernos de PC´s.
La ingeniería puede desarrollarse a través del ciclo de vida clásico o el de construcción de prototipos.
Este es el enfoque más realista actualmente.
El modelo en espiral esta compartida en varias actividades estructurales, también llamadas regiones de tareas. Existen seis regiones de tareas que son:
Comunicación con el cliente: esta es una tarea requerida para establecer comunicación entre el desarrollador y el cliente.
Planificación: esta tarea es necesaria aplicarla para pode definir los recursos, el tiempo y otras informaciones relacionadas con el proyecto, es decir, son todos los requerimientos.
Análisis de riesgos: esta es una de las tareas principales por lo que se aplica el modelo en espiral, es requerida para evaluar los riesgos técnicos y otras informaciones relacionadas con el proyecto.
Ingeniería: esta es una tarea necesaria ya que se requiere construir una o más representaciones de la aplicación.
Construcción y adaptación: esta tarea es requerida en el modelo espiral porque se necesita construir, probar, instalar y proporcionar soporte al usuario.
Evaluación el cliente: esta también es una tarea principal, necesaria para adquirir la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería y la de implementación creada durante la etapa de instalación.
VENTAJAS DEL MODELO ESPIRAL
No requiere una definición completa de los requerimientos del software a desarrollar para comenzar su funcionalidad.
En la terminación de un producto desde el final de la primera iteración es muy factible aprobar los requisitos.
Sufrir retrasos corre un riesgo menor, por que se comprueban los conflictos presentados tempranamente y existe la forma de poder corregirlos a tiempo.
DESVENTAJAS DEL MODELO ESPIRAL
*Existe complicación cuando se evalúa los riesgos.
*Se requiere la participación continua por parte del cliente.
*Se pierde tiempo al volver producir inicialmente una especificación completa de los requerimientos cuando se modifica o mejora el software.
ACOPLAMIENTOS DEL MODELO ESPIRAL
Los nuevos requerimientos del sistema se definen en todo los detalles posibles, esto implica generalmente el entrevistarse con un número determinado de usuarios que representarán a todos los usuarios tanto externos como internos y otros aspectos del sistema existente.
Un prototipo preliminar se crea para el desarrollo del nuevo software partiendo de un diseño hecho del sistema que se construyó del prototipo inicial. Esto es generalmente un sistema scaled-down, y representa una aproximación de las características del producto final.
Un segundo diseño de software es desarrollado por un procedimiento cuádruple: Evaluación del primer prototipo en términos de sus fuerzas, debilidades, y riesgos;
Definir los requisitos del segundo prototipo;
Planeando y desarrollando el segundo prototipo; Construyendo y probando el segundo prototipo.
En la opción del cliente, el proyecto completado puede ser abortado si el riesgo se juzga demasiado grande. Los factores de riesgo pudieron implicar los excesos de coste del desarrollo, cálculo erróneo del fusionar los costes, o cualquier otro factor que podría, en el juicio del cliente, dar lugar a un producto final menos que satisfactorio.
El diseño existente se evalúa de manera semejante al igual que el diseño anterior, y, en caso de necesidad, otro prototipo se desarrolla de él según el procedimiento cuádruple expuesto anteriormente.
Se iteran los pasos precedentes hasta que el cliente está satisfecho sabiendo que el diseño mejorado representa el producto final deseado. Además, se construye el sistema final, basado en el diseño mejorado. El sistema final se evalúa y se prueba con todas las de ley. El mantenimiento general se realiza sobre una base continua para prevenir fallas en grande y para reducir al mínimo el tiempo perdido.