miércoles, 14 de octubre de 2015


Metodología Espiral
Yeferson Cardenas
Elieth Picon

La Ingeniería de software, se vale y establece a partir de una serie de modelos que establecen y muestran las distintas etapas y estados por lo que pasa un producto software, desde su concepción inicial, pasando por su desarrollo, puesta en marcha y posterior mantenimiento, hasta la retirada del producto. A estos modelos se les denomina «modelos de ciclo de vida del software». El primer modelo concebido fue el de Royce, más comúnmente conocido como desarrollo en cascada o desarrollo lineal secuencial. Este modelo establece que las diversas actividades que se van realizando al desarrollar un producto software se suceden de forma lineal.

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.
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.

Ventajas

• Reduce riesgos del proyecto
• Incorpora objetivos de calidad
• Integra el desarrollo con el mantenimiento.
Desventajas

• Genera mucho tiempo en el desarrollo del sistema
• Modelo costoso
• Requiere experiencia en la identificación de riesgos
Inconvenientes

Planificar un proyecto con esta metodología es a menudo imposible, debido a la incertidumbre en el número de iteraciones que serán necesarias. En este contexto la evaluación de riesgos es de la mayor importancia y, para grandes proyectos, dicha evaluación requiere la intervención de profesionales de gran experiencia.
El IEEE clasifica al desarrollo en espiral como modelo no operativo en sus clasificaciones de MCV.
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. 



No hay comentarios:

Publicar un comentario