Metodología de desarrollo de software

Índice general

1 Metodología de desarrollo de software 1

1.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Metodologías de desarrollo de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Enfoques de desarrollo de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4.1 Modelo en cascada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4.2 Prototipado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4.3 Incremental . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4.4 Espiral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4.5 Rapid Application Development (RAD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.6 Otros enfoques de desarrollo de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5 Referencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Desarrollo en cascada 7
2.1 Fases del modelo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1 Análisis de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.2 Diseño del Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.3 Diseño del Programa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.4 Codificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.5 Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.6 Verificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.7 Mantenimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Variantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Ventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4 Desventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5 Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.6 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.7 Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 Modelo de prototipos 11

i
ii ÍNDICE GENERAL

3.1 Etapas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Ventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3 Inconvenientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.5 Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4 Desarrollo iterativo y creciente 13

4.1 Concepto de desarrollo iterativo y creciente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2 Ciclo de vida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.1 Consideraciones sobre el momento de aplicación . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.2 Etapa de inicialización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.3 Etapa de iteración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3 Caso práctico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.4 Características . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.5 Ventajas del desarrollo incremental . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.6 Ventajas del desarrollo iterativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.7 Debilidades de este modelo de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.8 Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.9 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5 Desarrollo en espiral 18
5.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.2 Ciclos o Iteraciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.2.1 Tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.3 Mecanismos de control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.4 Variaciones del Modelo En Espiral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.5 Ventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.6 Desventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.7 Inconvenientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.8 Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.9 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.10 Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.11 Texto e imágenes de origen, colaboradores y licencias . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.11.1 Texto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.11.2 Imágenes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.11.3 Licencia de contenido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Capítulo 1

Metodología de desarrollo de software

Metodología de desarrollo de software en ingeniería de software es un marco de trabajo usado para estructurar, plani-
ficar y controlar el proceso de desarrollo en sistemas de información.[1]

Tres patrones básicos en las metodologías de desarrollo de software.

1.1 Introducción
Una metodología de desarrollo de software se refiere a un framework que es usado para estructurar, planear y controlar
el proceso de desarrollo en sistemas de información.
A lo largo del tiempo, una gran cantidad de métodos han sido desarrollados diferenciándose por su fortaleza y debilidad.
El framework para metodología de desarrollo de software consiste en:

• Una filosofía de desarrollo de programas de computacion con el enfoque del proceso de desarrollo de software

1
2 CAPÍTULO 1. METODOLOGÍA DE DESARROLLO DE SOFTWARE

• Herramientas, modelos y métodos para asistir al proceso de desarrollo de software

Estos frameworks son a menudo vinculados a algún tipo de organización, que además desarrolla, apoya el uso y promueve
la metodología. La metodología es a menudo documentada en algún tipo de documentación formal.

1.2 Historia
El desarrollo de los sistemas tradicionales de ciclo de vida se originó en la década de 1960 para desarrollar a gran escala
funcional de sistemas de negocio en una época de grandes conglomerados empresariales. La idea principal era continuar
el desarrollo de los sistemas de información en una muy deliberada, estructurada y metódica, reiterando cada una de las
etapas del ciclo de vida. Los sistemas de información en torno a las actividades resueltas pesadas para el procesamiento
de datos y rutinas de cálculo.
Metodologías de Desarrollo de Software tiene como objetivo presentar un conjunto de técnicas tradicionales y modernas
de modelado de sistemas que permitan desarrollar software de calidad, incluyendo heurísticas de construcción y criterios
de comparación de modelos de sistemas.
Para tal fin se describen, fundamentalmente, herramientas de Análisis y Diseño Orientado a Objetos (UML), sus dia-
gramas, especificación, y criterios de aplicación de las mismas. Como complemento se describirán las metodologías de
desarrollo de software que utilizan dichas herramientas, ciclos de vida asociados y discusión sobre el proceso de desarrollo
de software más adecuado para las diferentes aplicaciones ejemplos que se presentarán. Principalmente, se presentará el
Proceso Unificado el cual utiliza un ciclo de vida iterativo e incremental.

• Kendall y Kendall

I. Identificación del problema, oportunidades y objetivos. II. Determinación de los requerimientos de información. III.
Análisis de las necesidades del sistema. IV. Diseño del sistema recomendado. V. Desarrollo y documentación del software.
VI. Pruebas y mantenimiento del sistema. VII. Implantación y evaluación del sistema.

• James Senn

I. Ciclo de vida y desarrollo del sistema. II. Desarrollo por análisis estructurado III. Prototipo del sistema.

• Llorens Fabregas

I. Requerimientos. II. Análisis/Diseño. III. Construcción. IV. Pruebas. V. Producción y mantenimiento.

• Jonas Montilva

I. Definir el proyecto. II. Análisis del contexto. III. Definición de los requerimientos. IV. Diseño preliminar. V. Diseño
detallado.

• Roger Pressman

I. Análisis de los requerimientos del Software. II. Diseño. III. Generación de código. IV. Pruebas. V. Mantenimiento;

1.3 Metodologías de desarrollo de software

1970
1.4. ENFOQUES DE DESARROLLO DE SOFTWARE 3

• Programación estructurada sol desde 1969

• Programación estructurada Jackson desde 1975

1980

• Structured Systems Analysis and Design Methodology (SSADM) desde 1980

• Structured Analysis and Design Technique (SADT) desde 1980

• Ingeniería de la información (IE/IEM) desde 1981

1990

• Rapid application development (RAD) desde 1991.

• Programación orientada a objetos (OOP) a lo largo de la década de los 90’s

• Virtual finite state machine (VFSM) desde 1990s

• Dynamic Systems Development Method desarrollado en UK desde 1995.

• Scrum (desarrollo), en la última parte de los 90’s

• Rational Unified Process (RUP) desde 1999.

• Extreme Programming(XP) desde 1999

Nuevo milenio

• Enterprise Unified Process (EUP) extensiones RUP desde 2002

• Constructionist design methodology (CDM) desde 2004 por Kristinn R. Thórisson

• Agile Unified Process (AUP) desde 2005 por Scott Ambler

1.4 Enfoques de desarrollo de software

Cada metodología de desarrollo de software tiene más o menos su propio enfoque para el desarrollo de software. Estos
son los enfoques más generales, que se desarrollan en varias metodologías específicas. Estos enfoques son los siguientes:[1]

• Modelo en cascada: Framework lineal.

• Prototipado: Framework iterativo.

• Incremental: Combinación de framework lineal e iterativo.

• Espiral: Combinación de framework lineal e iterativo.

• RAD: Rapid Application Development, framework iterativo.

4 CAPÍTULO 1. METODOLOGÍA DE DESARROLLO DE SOFTWARE

1.4.1 Modelo en cascada

Es un proceso secuencial de desarrollo en el que los pasos de desarrollo son vistos hacia abajo (como en una cascada de
agua) a través de las fases de análisis de las necesidades, el diseño, implantación, pruebas (validación), la integración,
y mantenimiento. La primera descripción formal del modelo de cascada se cita a menudo a un artículo publicado por
Winston Royce W.[2] en 1970, aunque Royce no utiliza el término “cascada” de este artículo.
Los principios básicos del modelo de cascada son los siguientes:[1]

• El proyecto está dividido en fases secuenciales, con cierta superposición y splashback aceptable entre fases.

• Se hace hincapié en la planificación, los horarios, fechas, presupuestos y ejecución de todo un sistema de una sola
vez.

• Un estricto control se mantiene durante la vida del proyecto a través de la utilización de una amplia documentación
escrita, así como a través de comentarios y aprobación / signoff por el usuario y la tecnología de la información de
gestión al final de la mayoría de las fases antes de comenzar la próxima fase.

1.4.2 Prototipado

El prototipado permite desarrollar modelos de aplicaciones de software que permiten ver la funcionalidad básica de la
misma, sin necesariamente incluir toda la lógica o características del modelo terminado. El prototipado permite al cliente
evaluar en forma temprana el producto, e interactuar con los diseñadores y desarrolladores para saber si se está cumpliendo
con las expectativas y las funcionalidades acordadas.Los Prototipos no poseen la funcionalidad total del sistema pero si
condensa la idea principal del mismo, Paso a Paso crece su funcionalidad, y maneja un alto grado de participación del
usuario.

1.4.3 Incremental

Provee una estrategia para controlar la complejidad y los riesgos, desarrollando una parte del producto software reservando
el resto de aspectos para el futuro.
Los principios básicos son:

• Una serie de mini-Cascadas se llevan a cabo, donde todas las fases de la cascada modelo de desarrollo se han
completado para una pequeña parte de los sistemas, antes de proceder a la próxima incremental.

• Se definen los requisitos antes de proceder con lo evolutivo, se realiza un mini-Cascada de desarrollo de cada uno
de los incrementos del sistema.

• El concepto inicial de software, análisis de las necesidades, y el diseño de la arquitectura y colectiva básicas se
definen utilizando el enfoque de cascada, seguida por iterativo de prototipos, que culmina en la instalación del
prototipo final.

1.4.4 Espiral

Los principios básicos son:

• La atención se centra en la evaluación y reducción del riesgo del proyecto dividiendo el proyecto en segmentos más
pequeños y proporcionar más facilidad de cambio durante el proceso de desarrollo, así como ofrecer la oportunidad
de evaluar los riesgos y con un peso de la consideración de la continuación del proyecto durante todo el ciclo de
vida.
1.4. ENFOQUES DE DESARROLLO DE SOFTWARE 5

• Cada viaje alrededor de la espiral atraviesa cuatro cuadrantes básicos: (1) determinar objetivos, alternativas, y
desencadenantes de la iteración; (2) Evaluar alternativas; Identificar y resolver los riesgos; (3) desarrollar y verificar
los resultados de la iteración, y (4) plan de la próxima iteración.[3]

• Cada ciclo comienza con la identificación de los interesados y sus condiciones de ganancia, y termina con la revisión
y examinación.[3]

1.4.5 Rapid Application Development (RAD)

El desarrollo rápido de aplicaciones (RAD) es una metodología de desarrollo de software, que implica el desarrollo
iterativo y la construcción de prototipos. El desarrollo rápido de aplicaciones es un término originalmente utilizado para
describir un proceso de desarrollo de software introducido por James Martin en 1991.
Principios básicos:

• Objetivo clave es para un rápido desarrollo y entrega de una alta calidad en un sistema de relativamente bajo coste
de inversión.

• Intenta reducir el riesgos inherente del proyecto partiéndolo en segmentos más pequeños y proporcionar más faci-
lidad de cambio durante el proceso de desarrollo.

• Orientación dedicada a producir sistemas de alta calidad con rapidez, principalmente mediante el uso de iteración
por prototipos (en cualquier etapa de desarrollo), promueve la participación de los usuarios y el uso de herramien-
tas de desarrollo computarizadas. Estas herramientas pueden incluir constructores de Interfaz gráfica de usuario
(GUI), Computer Aided Software Engineering (CASE) las herramientas, los sistemas de gestión de bases de datos
(DBMS), lenguajes de programación de cuarta generación, generadores de código, y técnicas orientada a objetos.

• Hace especial hincapié en el cumplimiento de la necesidad comercial, mientras que la ingeniería tecnológica o la
excelencia es de menor importancia.

• Control de proyecto implica el desarrollo de prioridades y la definición de los plazos de entrega. Si el proyecto
empieza a aplazarse, se hace hincapié en la reducción de requisitos para el ajuste, no en el aumento de la fecha
límite.

• En general incluye Joint application development (JAD), donde los usuarios están intensamente participando en el
diseño del sistema, ya sea a través de la creación de consenso estructurado en talleres, o por vía electrónica.

• La participación activa de los usuarios es imprescindible.

• Iterativamente realiza la producción de software, en lugar de enfocarse en un prototipo.

• Produce la documentación necesaria para facilitar el futuro desarrollo y mantenimiento.

1.4.6 Otros enfoques de desarrollo de software

• Metodologías de desarrollo Orientado a objetos, Diseño orientado a objetos (OOD) de Grady Booch, también
conocido como Análisis y Diseño Orientado a Objetos (OOAD). El modelo incluye seis diagramas: de clase, objeto,
estado de transición, la interacción, módulo, y el proceso.

• Top-down programming, evolucionado en la década de 1970 por el investigador de IBM Harlan Mills (y Niklaus
Wirth) en Desarrollo Estructurado.

• Proceso Unificado, es una metodología de desarrollo de software, basado en UML. Organiza el desarrollo de soft-
ware en cuatro fases, cada una de ellas con la ejecución de una o más iteraciones de desarrollo de software: creación,
elaboración, construcción, y las directrices. Hay una serie de herramientas y productos diseñados para facilitar la
aplicación. Una de las versiones más populares es la de Rational Unified Process.
6 CAPÍTULO 1. METODOLOGÍA DE DESARROLLO DE SOFTWARE

1.5 Referencia
[1] SELECTING A DEVELOPMENT APPROACH. Revalidated: March 27, 2008. Retrieved 27 Oct 2008.

[2] Wasserfallmodell > Entstehungskontext, Markus Rerych, Institut für Gestaltungs- und Wirkungsforschung, TU-Wien. Accessed
on line November 28, 2007.

[3] (Boehm, 2000)

Capítulo 2

Desarrollo en cascada

En Ingeniería de software el desarrollo en cascada, también llamado modelo en cascada (denominado así por la posición
de las fases en el desarrollo de esta, que parecen caer en cascada “por gravedad” hacia las siguientes fases), es el enfoque
metodológico que ordena rigurosamente las etapas del proceso para el desarrollo de software, de tal forma que el inicio
de cada etapa debe esperar a la finalización de la etapa anterior.[1] Al final de cada etapa, el modelo está diseñado para
llevar a cabo una revisión final, que se encarga de determinar si el proyecto está listo para avanzar a la siguiente fase. Este
modelo fue el primero en originarse y es la base de todos los demás modelos de ciclo de vida.
La versión original fue propuesta por Winston W. Royce en 1970 y posteriormente revisada por Barry Boehm en 1980 e
Ian Sommerville en 1985.[2]
Un ejemplo de una metodología de desarrollo en cascada es:

1. Análisis de requisitos.

2. Diseño del Sistema.

3. Diseño del Programa.

4. Codificación.

5. Pruebas.

6. Verificación.

7. Mantenimiento.

De esta forma, cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al rediseño y nueva
programación del código afectado, aumentando los costos del desarrollo. La palabra cascada sugiere, mediante la metáfora
de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases más avanzadas de un proyecto.
Si bien ha sido ampliamente criticado desde el ámbito académico y la industria[cita requerida] , sigue siendo el paradigma más
seguido al día de hoy[cita requerida] .

2.1 Fases del modelo.

2.1.1 Análisis de requisitos

En esta fase se analizan las necesidades de los usuarios finales del software para determinar qué objetivos
debe cubrir. De esta fase surge una memoria llamada SRD (documento de especificación de requisitos), que
contiene la especificación completa de lo que debe hacer el sistema sin entrar en detalles internos.

7
8 CAPÍTULO 2. DESARROLLO EN CASCADA

Requisitos

Diseño

Implementación

Verificación

Maintenimiento

El “modelo cascada” sin modificar. El progreso fluye de arriba hacía abajo, como una cascada.

Es importante señalar que en esta etapa se debe consensuar todo lo que se requiere del sistema y será
aquello lo que seguirá en las siguientes etapas, no pudiéndose requerir nuevos resultados a mitad del proceso
de elaboración del software de una manera.

2.1.2 Diseño del Sistema

Descompone y organiza el sistema en elementos que puedan elaborarse por separado, aprovechando las
ventajas del desarrollo en equipo. Como resultado surge el SDD (Documento de Diseño del Software), que
contiene la descripción de la estructura relacional global del sistema y la especificación de lo que debe hacer
cada una de sus partes, así como la manera en que se combinan unas con otras.

Es conveniente distinguir entre diseño de alto nivel o arquitectónico y diseño detallado. El primero de ellos
tiene como objetivo definir la estructura de la solución (una vez que la fase de análisis ha descrito el problema)
identificando grandes módulos (conjuntos de funciones que van a estar asociadas) y sus relaciones. Con ello
se define la arquitectura de la solución elegida. El segundo define los algoritmos empleados y la organización
del código para comenzar la implementación.

2.1.3 Diseño del Programa

Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de los requerimientos del
usuario así como también los análisis necesarios para saber qué herramientas usar en la etapa de Codificación
2.2. VARIANTES 9

2.1.4 Codificación
Es la fase en donde se implementa el código fuente, haciendo uso de prototipos así como de pruebas y ensayos
para corregir errores.
Dependiendo del lenguaje de programación y su versión se crean las bibliotecas y componentes reutilizables
dentro del mismo proyecto para hacer que la programación sea un proceso mucho más rápido.

2.1.5 Pruebas
Los elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona co-
rrectamente y que cumple con los requisitos, antes de ser entregado al usuario final.

2.1.6 Verificación
Es la fase en donde el usuario final ejecuta el sistema, para ello el o los programadores ya realizaron exhaus-
tivas pruebas para comprobar que el sistema no falle.
En la creación de desarrollo de cascada se implementa los códigos de investigación y pruebas del mismo.

2.1.7 Mantenimiento
Una de las etapas más críticas, ya que se destina un 75 % de los recursos, es el mantenimiento del Software
ya que al utilizarlo como usuario final puede ser que no cumpla con todas nuestras expectativas.

2.2 Variantes
Existen variantes de este modelo; especialmente destacamos la que hace uso de prototipos y en la que se
establece un ciclo antes de llegar a la fase de mantenimiento, verificando que el sistema final este libre de
fallos.
Otros ejemplos de variantes del modelo en cascada son el modelo en cascada con fases solapadas, cascada
con subproyectos, y cascada con reducción de riesgos.[3]

2.3 Ventajas
Realiza un buen funcionamiento en equipos débiles y productos maduros, por lo que se requiere de menos
capital y herramientas para hacerlo funcionar de manera óptima.
Es un modelo fácil de implementar y entender.
Está orientado a documentos.
Es un modelo conocido y utilizado con frecuencia.
Promueve una metodología de trabajo efectiva: Definir antes que diseñar, diseñar antes que codificar.[4]

2.4 Desventajas
En la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea una mala implementación del
modelo, lo cual hace que lo lleve al fracaso.
El proceso de creación del software tarda mucho tiempo ya que debe pasar por el proceso de prueba y hasta
que el software no esté completo no se opera. Esto es la base para que funcione bien.
10 CAPÍTULO 2. DESARROLLO EN CASCADA

Cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al rediseño y nueva
programación del código afectado, aumentando los costos del desarrollo.
Una etapa determinada del proyecto no se puede llevar a cabo a menos de que se haya culminado la etapa
anterior.

2.5 Véase también

• Ingeniería de software

• Desarrollo en espiral
• Modelos de desarrollo de software: Cascada vs V

2.6 Referencias
[1] S. Pressman, Roger. Ingeniería del Software: Un enfoque práctico, 3.ª Edición, Pag. 26-30.

[2] Cataldi, Z., Lage, F., Pessacq, R. y García Martínez, R. Ingeniería de software educativo.

[3] , Patricia Arieta Melgarejo, Modelos del ciclo de vida de software.

[4] , Ruby Casallas, Andrés Yie, Ingeniería de Software: Ciclos de Vida y Metodologías.

2.7 Enlaces externos

• Ciclo de vida del software
Capítulo 3

Modelo de prototipos

El Modelo de prototipos, en Ingeniería de software, pertenece a los modelos de desarrollo evolutivo. El prototipo debe
ser construido en poco tiempo, usando los programas adecuados y no se debe utilizar muchos recursos.
El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles para el cliente
o el usuario final. Este diseño conduce a la construcción de un prototipo, el cual es evaluado por el cliente para una
retroalimentación; gracias a ésta se refinan los requisitos del software que se desarrollará. La interacción ocurre cuando el
prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda
mejor lo que se debe hacer y el cliente vea resultados a corto plazo.

3.1 Etapas
• Plan rápido.
• Modelado, diseño rápido
• Construcción del Prototipo
• Desarrollo, entrega y retroalimentación
• Comunicación
• Entrega del desarrollo final

3.2 Ventajas
• Este modelo es útil cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos
detallados de entrada, procesamiento o salida.
• También ofrece un mejor enfoque cuando el responsable del desarrollo del software está inseguro de la eficacia de
un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humano-
máquina
• Se puede reutilizar el codigo

La construcción de prototipos se puede utilizar como un modelo del proceso independiente, se emplea más comúnmente
como una técnica susceptible de implementarse dentro del contexto de cualquiera de los modelos del proceso expuestos.
Sin importar la forma en que éste se aplique, el paradigma de construcción de prototipos ayuda al desarrollado de software
y al cliente a entender de mejor manera cuál será el resultado de la construcción cuando los requisitos estén satisfechos.
De esta manera, este ciclo de vida en particular, involucra al cliente más profundamente para adquirir el producto.

11
12 CAPÍTULO 3. MODELO DE PROTOTIPOS

3.3 Inconvenientes
• El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema final. A causa de la inten-
ción de crear un prototipo de forma rápida, se suelen desatender aspectos importantes, tales como la calidad y el
mantenimiento a largo plazo, lo que obliga en la mayor parte de los casos a reconstruirlo una vez que el prototipo
ha cumplido su función. Es frecuente que el usuario se muestre reaccion a ello y pida que sobre ese prototipo
se construya el sistema final, lo que lo convertiría en un prototipo evolutivo, pero partiendo de un estado poco
recomendado.

• En aras de desarrollar rápidamente el prototipo, el desarrollador suele tomar algunas decisiones de implementación
poco convenientes (por ejemplo, elegir un lenguaje de programación incorrecto porque proporcione un desarro-
llo más rápido). Con el paso del tiempo, el desarrollador puede olvidarse de la razón que le llevó a tomar tales
decisiones, con lo que se corre el riesgo de que dichas elecciones pasen a formar parte del sistema final...

3.4 Conclusiones
A pesar de que tal vez surjan problemas, la construcción de prototipos puede ser un paradigma efectivo para la ingeniería
del software. La clave es definir las reglas del juego desde el principio; es decir, el cliente y el desarrollador se deben poner
de acuerdo en:

• Que el prototipo se construya y sirva como un mecanismo para la definición de requisitos.

• Que el prototipo se descarte, al menos en parte.

• Que después se desarrolle el software real con un enfoque hacia la calidad.

3.5 Véase también

• Ingeniería de software

• Ingenierías del software

Capítulo 4

Desarrollo iterativo y creciente

Desarrollo iterativo y creciente (o incremental) es un proceso de desarrollo de software creado en respuesta a las debi-
lidades del modelo tradicional de cascada.
Básicamente este modelo de desarrollo, que no es más que un conjunto de tareas agrupadas en pequeñas etapas repetitivas
(iteraciones),[1] es uno de los más utilizados en los últimos tiempos ya que, como se relaciona con novedosas estrategias
de desarrollo de software y una programación extrema, es empleado en metodologías diversas.
El modelo consta de diversas etapas de desarrollo en cada incremento, las cuales inician con el análisis y finalizan con la
instauración y aprobación del sistema.[2]

4.1 Concepto de desarrollo iterativo y creciente

Se planifica un proyecto en distintos bloques temporales que se le denominan iteración. En una iteración se repite un
determinado proceso de trabajo que brinda un resultado más completo para un producto final, de forma que quien lo
utilice reciba beneficios de este proyecto de manera creciente.
Para llegar a lograr esto, cada requerimiento debe tener un completo desarrollo en una única iteración que debe de incluir
pruebas y una documentación para que el equipo pueda cumplir con todos los objetivos que sean necesarios y esté listo
para ser dado al cliente. Así se evita tener arriesgadas actividades en el proyecto finalizado.
Lo que se busca es que en cada iteración los componentes logren evolucionar el producto dependiendo de los completados
de las iteraciones antecesoras, agregando más opciones de requisitos y logrando así un mejoramiento mucho más completo.
Una manera muy primordial para dirigir al proceso iterativo incremental es la de priorizar los objetivos y requerimientos
en función del valor que ofrece el cliente.[3]
Para apoyar el desarrollo de proyectos por medio de este modelo se han creado frameworks (entornos de trabajo), de los
cuales los dos más famosos son el Rational Unified Process y el Dynamic Systems Development Method. El desarrollo
incremental e iterativo es también una parte esencial de un tipo de programación conocido como Extreme Programming
y los demás frameworks de desarrollo rápido de software.

4.2 Ciclo de vida

La idea principal detrás de mejoramiento iterativo es desarrollar un sistema de programas de manera incremental, per-
mitiéndole al desarrollador sacar ventaja de lo que se ha aprendido a lo largo del desarrollo anterior, incrementando,
versiones entregables del sistema. El aprendizaje viene de dos vertientes: el desarrollo del sistema, y su uso (mientras sea
posible). Los pasos claves en el proceso son comenzar con una implementación simple de los requerimientos del sistema,
e iterativamente mejorar la secuencia evolutiva de versiones hasta que el sistema completo esté implementado. En cada

13
14 CAPÍTULO 4. DESARROLLO ITERATIVO Y CRECIENTE

iteración, se realizan cambios en el diseño y se agregan nuevas funcionalidades y capacidades al sistema.

Básicamente este modelo se basa en dos premisas:

• Los usuarios nunca saben bien que es lo que necesitan para satisfacer sus necesidades.
• En el desarrollo, los procesos tienden a cambiar.[4]

El proceso en sí mismo consiste de:

• Etapa de inicialización
• Etapa de iteración
• Lista de control de proyecto

4.2.1 Consideraciones sobre el momento de aplicación

Para integrar la usabilidad en un proceso de desarrollo, no es suficiente con asignar técnicas de usabilidad a actividades de
desarrollo, puesto que no todas las técnicas de usabilidad son aplicables en cualquier momento de un desarrollo iterativo.
Por ejemplo, las técnicas para desarrollar el concepto del producto están concebidas para su aplicación en los primeros
esfuerzos del desarrollo, cuando las necesidades se identifican y el esquema general del sistema se establece. Aunque es
aconsejable aplicarlas también más tarde, para refinar el concepto, su principal esfuerzo de aplicación esta en las tareas
iniciales de desarrollo.[5]

4.2.2 Etapa de inicialización

Se crea una versión del sistema. La meta de esta etapa es crear un producto con el que el usuario pueda interactuar, y por
ende retroalimentar el proceso. Debe ofrecer una muestra de los aspectos claves del problema y proveer una solución lo
suficientemente simple para ser comprendida e implementada fácilmente. Para guiar el proceso de iteración se crea una
lista de control de proyecto, que contiene un historial de todas las tareas que necesitan ser realizadas. Incluye cosas como
nuevas funcionalidades para ser implementadas, y areas de rediseño de la solución ya existente. Esta lista de control se
revisa periódica y constantemente como resultado de la fase de análisis.

4.2.3 Etapa de iteración

Esta etapa involucra el rediseño e implementación de una tarea de la lista de control de proyecto, y el análisis de la
versión más reciente del sistema. La meta del diseño e implementación de cualquier iteración es ser simple, directa y
modular, para poder soportar el rediseño de la etapa o como una tarea añadida a la lista de control de proyecto. El código
puede, en ciertos casos, representar la mayor fuente de documentación del sistema. El análisis de una iteración se basa
en la retroalimentación del usuario y en el análisis de las funcionalidades disponibles del programa. Involucra el análisis
de la estructura, modularidad, usabilidad, confiabilidad, eficiencia y eficacia (alcanzar las metas). La lista de control del
proyecto se modifica bajo la luz de los resultados del análisis.
Las guías primarias que guían la implementación y el análisis incluyen:

• Cualquier dificultad en el diseño, codificación y prueba de una modificación debería apuntar a la necesidad de
rediseñar o recodificar.
• Las modificaciones deben ajustarse fácilmente a los módulos fáciles de encontrar y a los aislados. Si no es así,
entonces se requiere algún grado de rediseño.
• Las modificaciones a las tablas deben ser especialmente fáciles de realizar. Si dicha modificación no ocurre rápi-
damente, se debe aplicar algo de rediseño.
4.3. CASO PRÁCTICO 15

• Las modificaciones deben ser más fáciles de hacer conforme avanzan las iteraciones. Si no es así, hay un problema
primordial usualmente encontrado en un diseño débil o en la proliferación excesiva de parches al sistema.
• Los parches normalmente deben permanecer solo por una o dos iteraciones. Se hacen necesarios para evitar el
rediseño durante una fase de implementación.
• La implementación existente debe ser analizada frecuentemente para determinar qué tal se ajusta a las metas del
proyecto.
• Las facilidades para analizar el programa deben ser utilizadas cada vez para ayudar en el análisis de implementa-
ciones parciales.
• La opinión del usuario debe ser solicitada y analizada para indicar deficiencias en la implementación referida por
él.

4.3 Caso práctico

La mejora iterativa fue exitosamente aplicada al desarrollo de una familia extensa de compiladores para una familia
de lenguajes de programación en una gama de arquitecturas de hardware. Un conjunto de 17 versiones del sistema se
desarrollaron en un lugar, generando 17 mil líneas de código fuente de lenguaje de alto nivel (6500 de código ejecutable). El
sistema posteriormente fue desarrollado en dos sitios diferentes, llegando a dos versiones diferentes del lenguaje base: una
versión esencialmente se enfocaba en aplicaciones matemáticas, añadiendo números reales y varias funciones matemáticas,
y la otra se centró en añadir capacidades para escribir del compilador. Cada iteración fue analizada del punto de vista
de los usuarios (las capacidades del lenguaje fueron determinadas en parte por las necesidades del usuario) y el punto de
vista del desarrollador (el diseño del compilador evolucionó para ser más fácilmente modificable, por ejemplo, para añadir
nuevos tipos de datos). Mediciones tales como acoplamiento y modularización fueron seguidas sobre múltiples versiones.

4.4 Características
Usando análisis y mediciones como guías para el proceso de mejora es una diferencia mayor entre las mejoras iterativas
y el desarrollo rápido de aplicaciones, principalmente por dos razones:

• Provee de soporte para determinar la efectividad de los procesos y de la calidad del producto.
• Permite estudiar y después mejorar y ajustar el proceso para el ambiente en particular.

Estas mediciones y actividades de análisis pueden ser añadidas a los métodos de desarrollo rápido existentes.
De hecho, el contexto de iteraciones múltiples conlleva ventajas en el uso de mediciones. Las medidas a veces son difí-
ciles de comprender en lo absoluto, aunque en los cambios relativos en las medidas a través de la evolución del sistema
puede ser muy informativo porque proveen una base de comparación. Por ejemplo, un vector de medidas m1, m2,...,
mn puede ser definido para caracterizar varios aspectos del producto en cierto punto, como pueden ser el esfuerzo total
realizado, los cambios, los defectos, los atributos lógico, físico y dinámico, consideraciones del entorno, etcétera. Así
el observador puede decir como las características del producto como el tamaño, la complejidad, el acoplamiento y la
cohesión incrementan o disminuyen en el tiempo. También puede monitorearse el cambio relativo de varios aspectos de
un producto o pueden proveer los límites de las medidas para apuntar a problemas potenciales y anomalías.

4.5 Ventajas del desarrollo incremental

• En este modelo los usuarios no tienen que esperar hasta que el sistema completo se entregue para hacer uso de él.
El primer incremento cumple los requerimientos más importantes de tal forma que pueden utilizar el software al
instante.
16 CAPÍTULO 4. DESARROLLO ITERATIVO Y CRECIENTE

• Los usuarios pueden utilizar los incrementos iniciales como prototipos y obtener experiencia sobre los requeri-
mientos de los incrementos posteriores del sistema.
• Existe muy pocas probabilidades de riesgo en el sistema. Aunque se pueden encontrar problemas en algunos in-
crementos, lo normal es que el sistema se entregue sin inconvenientes al usuario.
• Ya que los sistemas de más alta prioridad se entregan primero, y los incrementos posteriores se integran entre
ellos, es muy poco probable que los sistemas más importantes sean a los que se les hagan más pruebas. Esto quiere
decir que es menos probable que los usuarios encuentren fallas de funcionamiento del software en las partes más
importantes del sistema.[6]

4.6 Ventajas del desarrollo iterativo

• En el desarrollo de este modelo se da la retroalimentación muy temprano a los usuarios.
• Permite separar la complejidad del proyecto, gracias a su desarrollo por parte de cada iteración o bloque.
• El producto es consistente y puntual en el desarrollo.
• Los productos desarrollados con este modelo tienen una menor probabilidad de fallar.
• Se obtiene un aprendizaje en cada iteración que es aplicado en el desarrollo del producto y aumenta las experiencias
para próximos proyectos.[7]

4.7 Debilidades de este modelo de desarrollo

• La entrega temprana de los proyectos produce la creación de sistemas demasiados simples que a veces se ven un
poco monótonos a los ojos del personal que lo recibe.[6]

• La mayoría de los incrementos se harán en base de las necesidades de los usuarios. Los incrementos en si ya son
estipulados desde antes de la entrega del proyecto, sin embargo hay que ver cómo se maneja el producto para
ver si necesita otros cambios además de los estipulados antes de la entrega del proyecto. Este problema no se ve
frecuentemente ya que la mayoría de las veces los incrementos estipulados suplen satisfactoriamente al usuario.[6]

• Los incrementos no deben constar de muchas líneas de código ya que la idea de los incrementos es agregar accesorios
al programa principal (o funcional), para que este tenga una y mil formas de desenvolverse en su tarea; llenar los
incrementos de muchas líneas de código provocaría que se perdiera la objetividad o base de lo que se trata el
desarrollo incremental.[6]

• Requiere de un cliente involucrado durante todo el curso del proyecto. Hay clientes que simplemente no estarán
dispuestos a invertir el tiempo necesario.

• El trato con el cliente debe basarse en principios éticos y colaboración mutua, más que trabajar cada parte inde-
pendientemente, defendiendo sólo su propio beneficio.[8]

• La entrega de un programa que es parcial pero funcional puede hacer vulnerable al programa debido a la falta
de robustez en su sistema, provocando que agentes ajenos puedan interferir con el correcto funcionamiento del
programa en sí.[6]

• Infunde responsabilidad en el equipo de desarrollo al trabajar directamente con el cliente, requiriendo de profesio-
nales sobre el promedio.

• Sufre fuertes penalizaciones en proyectos en los cuales los requerimientos están previamente definidos, o para
proyectos “todo/nada” en los cuales se requiere que se completen en un 100% el producto para ser implementado
(por ejemplo, licitaciones) otro punto muy importante es asegurarnos de que el trabajo se pueda cumplir tomando
en cuenta los costos que podamos usar en nuestros propios recursos.
4.8. VÉASE TAMBIÉN 17

4.8 Véase también

• Scrum
• Iteración

• Desarrollo en cascada
• Ingeniería de software

• Desarrollo de software

4.9 Referencias
[1] |Proceso de Desarrollo Iterativo| http://fernandosoriano.com.ar/?p=13

[2] |Desarrollo de software. Ciclo de vida iterativo incremental| https://jummp.wordpress.com/2011/03/31/desarrollo-de-software-ciclo-de-vida-iterati

[3] |Desarrollo iterativo e incremental| http://www.proyectosagiles.org/desarrollo-iterativo-incremental

[4] |Modelo Iterativo| http://procesosoftware.wikispaces.com/Modelo+Iterativo

[5] Constantine, L. L., Lockwood, L. A. D.: Software for Use: A Practical Guide to the Models and Methods of Usage - Centred
Design. Addison - Wesley ( 1999)

[6] Ian Sommerville (2005). «Entrega Incremental». Ingeniería del Software, Séptima edición edición... España: Pearson.

[7] |Proceso de Desarrollo Iterativo| http://fernandosoriano.com.ar/?p=13

[8] |Desarrollo iterativo e incremental| http://www.proyectosagiles.org/desarrollo-iterativo-incremental

Capítulo 5

Desarrollo en espiral

El desarrollo en espiral es un modelo de ciclo de vida del software definido por primera vez por Barry Boehm en 1986,[1]
utilizado generalmente en la Ingeniería de software. Las actividades de este modelo se conforman en una espiral, en la
que cada bucle o iteración representa un conjunto de actividades. Las actividades no están fijadas a ninguna prioridad,
sino que las siguientes se eligen en función del análisis de riesgo, comenzando por el bucle interior.

5.1 Introducción
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 los 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.
Boehm, autor de diversos artículos de ingeniería del software; modelos de estimación de esfuerzo y tiempo que se consume
en hacer productos software; y Modelos de Ciclo de Vida; ideó y promulgó un modelo desde un enfoque distinto al
tradicional en Cascada: El Modelo Evolutivo Espiral. Su Modelo de Ciclo de Vida en Espiral tiene en cuenta fuertemente el
riesgo que aparece a la hora de desarrollar software. Para ello, se comienza mirando las posibles alternativas de desarrollo,
se opta por la de riesgo más asumible y se hace un ciclo de la espiral. Si el cliente quiere seguir haciendo mejoras en el
software, se vuelve a evaluar las distintas nuevas alternativas y riesgos y se realiza otra vuelta de la espiral, así hasta que
llegue un momento en el que el producto software desarrollado sea aceptado y no necesite seguir mejorándose con otro
nuevo ciclo.
Este modelo fue propuesto por Boehm en 1986 en su artículo “A Spiral Model of Software Development and Enhancement”.[1]
En 1988, Boehm publicó un artículo similar[2] destinado a una audiencia más amplía. Básicamente consiste en una serie
de ciclos que se repiten en forma de espiral, comenzando desde el centro. Se suele interpretar como que dentro de cada
ciclo de la espiral se sigue un Modelo Cascada, pero no necesariamente debe ser así. El Espiral puede verse como un
modelo evolutivo que conjuga la naturaleza iterativa del modelo MCP con los aspectos controlados y sistemáticos del
Modelo Cascada, con el agregado de gestión de riesgo.

5.2 Ciclos o Iteraciones

En cada vuelta o iteración hay que tener en cuenta:

• Los Objetivos: qué necesidad debe cubrir el producto.

18
5.2. CICLOS O ITERACIONES 19

• Alternativas: las diferentes formas de conseguir los objetivos de forma exitosa, desde diferentes puntos de vista
como pueden ser:

1. Características: experiencia del personal, requisitos a cumplir, etc.

2. Formas de gestión del sistema.

3. Riesgo asumido con cada alternativa.

• Desarrollar y Verificar: Programar y probar el software.

Si el resultado no es el adecuado o se necesita implementar mejoras o funcionalidades:

• Se planificaran los siguientes pasos y se comienza un nuevo ciclo de la espiral. La espiral tiene una forma de caracola
y se dice que mantiene dos dimensiones, la radial y la angular:

1. Angular: Indica el avance del proyecto del software dentro de un ciclo.

2. Radial: Indica el aumento del coste del proyecto, ya que con cada nueva iteración se pasa más tiempo desarrollando.

Este sistema es muy utilizado en proyectos grandes y complejos como puede ser, por ejemplo, la creación de un Sistema
Operativo.
Al ser un modelo de Ciclo de Vida orientado a la gestión de riesgo se dice que uno de los aspectos fundamentales de su éxito
radica en que el equipo que lo aplique tenga la necesaria experiencia y habilidad para detectar y catalogar correctamente
los riesgos.

5.2.1 Tareas

Para cada ciclo habrá cuatro actividades:

1. Determinar Objetivos.

2. Análisis del riesgo.

3. Desarrollar y probar.

4. 'Planificación.'

Determinar o fijar objetivos

• Fijar también los productos definidos a obtener: requisitos, 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.
20 CAPÍTULO 5. DESARROLLO EN ESPIRAL

Determinar objetivos Análisis del riesgo

Planificación Desarrollar y probar

Modelo en espiral(Boehm, 1986).

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.

Análisis del riesgo

• Se lleva a cabo el estudio de las causas de las posibles amenazas y probables eventos no deseados y los daños y
consecuencias que éstas puedan producir. Se evalúan alternativas. Se debe tener un prototipo antes de comenzar a
desarrollar y probar.

En resumen, es para tener en cuenta de los riesgos de cada uno de los ambitos

5.3 Mecanismos de control

• La dimensión radial mide el coste.

• La dimensión angular mide el grado de avance del proyecto.

5.4 Variaciones del Modelo En Espiral

5.5. VENTAJAS 21

Modelo en Espiral Típico de seis regiones

El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora, a diferencia del modelo
de proceso clásico que termina cuando se entrega el software.
Las 6 regiones que componen este modelo son las siguientes:

• Comunicación con el cliente - Tareas necesarias para plantear la comunicación entre el desarrollador y el cliente.

• Planificación - Tareas inherentes a la definición de recursos, el tiempo y otras informaciones relacionadas con el
proyecto. Son todos los requerimientos.

• Análisis de riesgos – Tareas para evaluar riesgos técnicos y otras informaciones relacionadas con el proyecto.

• Ingeniería - Tareas para construir una o más representaciones de la aplicación.

• Construcción y adaptación - Tareas requeridas para construir, probar, instalar y proporcionar soporte a los usuarios.

• Evaluación del cliente - Tareas requeridas para obtener la reacción del cliente según la evaluación de las represen-
taciones del software creadas durante la etapa de ingeniería e implementación durante la etapa de instalación.[3]

Modelo en espiral WIN WIN

El modelo Win-Win es una adaptación del modelo espiral que se enfatiza en la participación del cliente en el proceso
de desarrollo de un producto de software. En un caso ideal, el desarrollador simplemente pregunta al cliente lo que se
requiere y el cliente proporciona suficiente información y detalles para proceder. Sin embargo esto no suele ocurrir en la
mayoría de los casos y es necesario que se establezcan negociaciones significativas entre ambas partes para equilibrar la
funcionalidad y rendimiento con los costos y tiempo de salida al mercado del producto. El modelo Win-Win deriva su
nombre del objetivo de estas negociaciones, es decir, “ganar-ganar”. El cliente recibe el producto que satisface la mayoría
de sus necesidades, y el desarrollador trabaja para alcanzar presupuestos y fechas de entrega. Para lograr este objetivo, se
realizan varias actividades de negociación al principio de cada paso alrededor de la espiral.[4]

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

5.6 Desventajas
• Genera mucho tiempo en el desarrollo del sistema

• Modelo costoso

• Requiere experiencia en la identificación de riesgos

22 CAPÍTULO 5. DESARROLLO EN ESPIRAL

5.7 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.[5]

5.8 Véase también

• Ingeniería de Software

• Desarrollo de Software
• Modelo en Cascada o Secuencial

• Modelo Iterativo Incremental

• Modelo por Prototipos

• Modelo de Desarrollo Rápido

5.9 Referencias
[1] Boehm B, A Spiral Model of Software Development and Enhancement, ACM SIGSOFT Software Engineering Notes, ACM,
11(4):14-24, Agosto 1986.

[2] Boehm B, “A Spiral Model of Software Development and Enhancement", IEEE Computer, IEEE, 21(5):61-72, May 1988

[3] http://modeloespiral.blogspot.com/2009/08/modelo-tipico-de-seis-regiones.html

[4] http://www.hanantek.com/win-win

[5] Developing a Software Project Life Cycle Process (IEEE 1074), 30 de marzo de 2006.

5.10 Enlaces externos

• A Spiral Model of Software Development and Enhancement. artículo original de Barry Boehm en el que proponía
el modelo de desarrollo en espiral (en inglés)
5.11. TEXTO E IMÁGENES DE ORIGEN, COLABORADORES Y LICENCIAS 23

5.11 Texto e imágenes de origen, colaboradores y licencias

5.11.1 Texto
• Metodología de desarrollo de software Fuente: https://es.wikipedia.org/wiki/Metodolog%C3%ADa_de_desarrollo_de_software?oldid=82704078
Colaboradores: Miguelcrux, CEM-bot, IrwinSantos, JAnDbot, SITOMON, Technopat, Muro Bot, Greek, LastCyborg, Leonpolanco, Frei sein,
UA31, LucienBOT, Arjuno3, Mdd, Luckas-bot, Wikiniel, Jkbw, Promeme, EmausBot, Okashii, WikitanvirBot, Rezabot, KLBot2, Adrian-
Maire, MaKiNeoH, Addbot, Mcarlevaro, Gear Pyromancer y Anónimos: 55
• Desarrollo en cascada Fuente: https://es.wikipedia.org/wiki/Desarrollo_en_cascada?oldid=81297653 Colaboradores: Ejmeza, Ejrrjs, Richy,
FAR, Edub, Yrithinnd, Orgullobot~eswiki, Penyaskito, Unf, Alhen, Superzerocool, Yrbot, Vitamine, Icvav, GermanX, JRGL, Kepler Oort,
Axxgreazz, CEM-bot, Osepu, Fsd141, Thijs!bot, Jonpagecr, Mahadeva, Isha, Ppedrodom, Infovoro, TXiKiBoT, Humberto, Decorrea, Pólux,
VolkovBot, WarddrBOT, Technopat, Jose figueredo, Matdrodes, DJ Nietzsche, SieBot, Irtusb, Greek, Jossue130987, Feperozpo, Nicop, UA31,
AVBOT, SpBot, Diegusjaimes, Bethan 182, MelancholieBot, Luckas Blade, Tremal Naik, Arjuno3, Luckas-bot, Nallimbot, Roinpa, Markos-
zarrate, Barteik, Gacpro, ArthurBot, SuperBraulio13, Jkbw, Torrente, Jesua3005, PatruBOT, Tarawa1943, GrouchoBot, EmausBot, Africanus,
Grillitus, Almogo, Alexandermark, WikitanvirBot, Lcsrns, MerlIwBot, Ayaita, Renciw, Adribeex, Harpagornis, Bolivarista, Rotlink, Legobot,
Melgar22, Bordierrez, Jedijor14, Julianromera y Anónimos: 202
• Modelo de prototipos Fuente: https://es.wikipedia.org/wiki/Modelo_de_prototipos?oldid=82746329 Colaboradores: Taichi, Rakela, BOTi-
jo, Filipo, Alfredobi, Rosarinagazo, Hanjin, Netito777, Scap2000, Pólux, Alexhd, Jose figueredo, Matdrodes, Racso, Manwë, Javierito92,
David.rgh, Caucas, Diegusjaimes, Jkbw, PatruBOT, Foundling, Alexandermark, Adribeex y Anónimos: 57
• Desarrollo iterativo y creciente Fuente: https://es.wikipedia.org/wiki/Desarrollo_iterativo_y_creciente?oldid=81974918 Colaboradores: Van-
basten 23, Yrbot, Varano, Martingala, CEM-bot, Osepu, Isha, Corvocativo, LeinaD natipaC, Redjhawk, Technopat, Jose figueredo, BlackBeast,
Muro Bot, Botito777, UA31, Diegusjaimes, Bloomy, DixonDBot, Foundling, Grillitus, Davidarturo21, MerlIwBot, AvicBot, Addbot, Farnhey,
Nathy2893, Dominic1593, LinkYanela, Elnico2787, Gustavosanais y Anónimos: 28
• Desarrollo en espiral Fuente: https://es.wikipedia.org/wiki/Desarrollo_en_espiral?oldid=82806089 Colaboradores: PACO, Vanbasten 23,
Sanbec, Dodo, Rikaaii, Cookie, Murphy era un optimista, Msxgopr, Cinabrium, Balderai, Kordas, Taragui, Pezezin~eswiki, Airunp, Rembia-
po pohyiete (bot), Orgullobot~eswiki, RobotQuistnix, LarA, Caiserbot, Yrbot, Oscar ., BOTijo, Martingala, GermanX, The Photographer,
Galle, Siabef, Tamorlan, CEM-bot, Meltryth, Ignacio Icke, Rafa sanz, GuiXu, Retama, Osepu, EcLiB, Thijs!bot, Escarbot, RoyFocker, Isha,
Kved, Yamaneko, Infovoro, Muro de Aguas, Netito777, Xsm34, Pólux, Javierxar, VolkovBot, Technopat, Jose figueredo, Matdrodes, Shooke,
Muro Bot, Bucho, Jmvgpartner, SieBot, PaintBot, Gospelepsog, Cumanacr, Leonpolanco, Caucas, SergioN, AVBOT, Adelpine, Diegusjai-
mes, Kmilovc, Xqbot, Jkbw, Botarel, Ereguero, ErikvanB, Jorge c2010, Savh, Grillitus, Bpk, MerlIwBot, Thehelpfulbot, Ginés90, Adribeex,
Johnbot, MarioCar88, Legobot, Nito18, Thawk101, Jarould y Anónimos: 138

5.11.2 Imágenes
• Archivo:Commons-emblem-question_book_orange.svg Fuente: https://upload.wikimedia.org/wikipedia/commons/1/1f/Commons-emblem-question_
book_orange.svg Licencia: CC BY-SA 3.0 Colaboradores: <a href='//commons.wikimedia.org/wiki/File:Commons-emblem-issue.svg' class='image'><img
alt='Commons-emblem-issue.svg' src='https://upload.wikimedia.org/wikipedia/commons/thumb/b/bc/Commons-emblem-issue.svg/25px-Commons-emblem-issue.
svg.png' width='25' height='25' srcset='https://upload.wikimedia.org/wikipedia/commons/thumb/b/bc/Commons-emblem-issue.svg/38px-Commons-emblem-issue.
svg.png 1.5x, https://upload.wikimedia.org/wikipedia/commons/thumb/b/bc/Commons-emblem-issue.svg/50px-Commons-emblem-issue.svg.
png 2x' data-file-width='48' data-file-height='48' /></a> + <a href='//commons.wikimedia.org/wiki/File:Question_book.svg' class='image'><img
alt='Question book.svg' src='https://upload.wikimedia.org/wikipedia/commons/thumb/9/97/Question_book.svg/25px-Question_book.svg.png'
width='25' height='20' srcset='https://upload.wikimedia.org/wikipedia/commons/thumb/9/97/Question_book.svg/38px-Question_book.svg.png
1.5x, https://upload.wikimedia.org/wikipedia/commons/thumb/9/97/Question_book.svg/50px-Question_book.svg.png 2x' data-file-width='252'
data-file-height='199' /></a> Artista original: GNOME icon artists, Jorge 2701
• Archivo:El_modelo_de_desarrollo_en_cascada.svg Fuente: https://upload.wikimedia.org/wikipedia/commons/2/2e/El_modelo_de_desarrollo_
en_cascada.svg Licencia: CC BY 3.0 Colaboradores: http://en.wikipedia.org/wiki/File:Waterfall_model_%281%29.svg Artista original: Pauls-
mith99
• Archivo:ModeloEspiral.svg Fuente: https://upload.wikimedia.org/wikipedia/commons/3/39/ModeloEspiral.svg Licencia: Public domain Co-
laboradores: ? Artista original: Chabacano
• Archivo:Software_development_methodologies.jpg Fuente: https://upload.wikimedia.org/wikipedia/commons/6/6a/Software_development_
methodologies.jpg Licencia: CC BY-SA 3.0 Colaboradores: Own work by uploader, based on Selecting a development approach at cms.hhs.gov.
Artista original: Marcel Douwe Dekker

5.11.3 Licencia de contenido

• Creative Commons Attribution-Share Alike 3.0