Desarrollo en espiral
De Wikipedia, la enciclopedia libre
El Desarrollo en Espiral es un modelo de ciclo de vida desarrollado por Barry Boehm en 1985, utilizado generalmente en la Ingeniería de software. Las actividades de este modelo son una espiral, cada bucle es una actividad. Las actividades no están fijadas a prioridad, sino que las siguientes se eligen en función del análisis de riesgo, comenzando por el bucle interior.
Tabla de contenidos |
[editar] Tareas
Para cada actividad habrá cuatro tareas:
[editar] Determinar o fijar objetivos
- Fijar también los productos definidos a obtener: requerimientos, especificación, manual de usuario.
- Fijar las restricciones.
- Identificación de riesgos del proyecto y estrategias alternativas para evitarlos.
- Hay una cosa que solo se hace una vez: planificación inicial o previa.
[editar] Análisis del riesgo
- Se estudian todos los riesgos potenciales y se seleccionan una o varias alternativas propuestas para reducir o eliminar los riesgos.
[editar] Desarrollar, verificar y validar (probar)
- Tareas de la actividad propia y de prueba.
- Análisis de alternativas e identificación resolución de riesgos.
- Dependiendo del resultado de la evaluación de los riesgos, se elige un modelo para el desarrollo, el que puede ser cualquiera de los otros existentes, como formal, evolutivo, cascada, etc. Así si por ejemplo si los riesgos en la interfaz de usuario son dominantes, un modelo de desarrollo apropiado podría ser la construcción de prototipos evolutivos. Si lo riesgos de protección son la principal consideración, un desarrollo basado en transformaciones formales podría ser el más apropiado.
[editar] Planificar
- Revisamos todo lo hecho, evaluándolo, y con ello decidimos si continuamos con las fases siguientes y planificamos la próxima actividad.
[editar] Mecanismos de control
- La dimensión radial mide el coste.
- La dimensión angular mide el grado de avance del proyecto.
[editar] Ventajas
El análisis del riesgo se hace de forma explícita y clara. Une los mejores elementos de los restantes modelos.
- Reduce riesgos del proyecto
- Incorpora objetivos de calidad
- Integra el desarrollo con el mantenimiento, etc.
Además es posible tener en cuenta mejoras y nuevos requerimientos sin romper con la metodología, ya que este ciclo de vida no es rígido ni estático.
[editar] Desventajas
- Genera mucho tiempo en el desarrollo del sistema
- Modelo costoso
- Requiere experiencia en la identificación de riesgos
[editar] Inconvenientes
Genera mucho trabajo adicional, y eso causa muchos problemas sobre todo si la compañía que esta produciendo el software es floja y holgazan. Cuando un sistema falla se pierde tiempo y coste dentro de la empresa. Exige una cierta habilidad en los analistas (es bastante difícil). El IEEE lo pone como modelo no operativo en sus clasificaciones de MCV
[editar] Véase también
 |
El contenido de esta página es un esbozo sobre programación. Ampliándolo ayudarás a mejorar Wikipedia. Puedes ayudarte con las wikipedias en otras lenguas. |
