Asignatura:

Ingeniería del software II.

Alumna:
Loren Daniela Chavarría.

Catedrático:
Ing. Augusto Guardiola Ponce.

Investigación:
Metodologías de desarrollo del software.

Fecha:
20/07/2022
 Introducción.

A continuación le doy a conocer una pequeña información sobre lo que son las metodologías
de desarrollo del software. Algunos datos muy importantes sobre ellas que nos van a hacer de
mucha importancia conocer y estudiar más a fondo.

Se le explica un poco más detalladamente a continuación.

 OBJETIVOS

Conocer la importancia de cada una de las metodologías.

Saber y conocer cuáles son sus ventajas y desventajas.

Darnos cuenta de cada una de las etapas y pasos para llevar a cabo dicha
metodología.
 METODOLOGIAS DE DESARROLLO DE SOFTWARE

1. METODOLOGIA CASCADA
¿Qué Es?

El desarrollo en cascada (en inglés, waterfall model) es un procedimiento lineal que se caracteriza por
dividir los procesos de desarrollo en sucesivas fases de proyecto. Al contrario que en los modelos
iterativos, cada una de estas fases se ejecuta tan solo una vez. Los resultados de cada una de las
fases sirven como hipótesis de partida para la siguiente. El waterfall model se utiliza, especialmente,
en el desarrollo de software.

¿Cómo Funciona?
El desarrollo del modelo se atribuye al teórico de la informática Winston W. Royce. Sin embargo, Royce no es
el inventor de este modelo. Muy al contrario, en su ensayo de 1970 titulado Managing the Development of
Large software Systems el teórico presenta una reflexión crítica acerca de los procedimientos lineales. A
modo de alternativa, Royce presenta un modelo iterativo incremental en el que cada una de las fases se basa
en la anterior y verifica los resultados de esta.

Royce propone un modelo compuesto por siete fases que se ha de ejecutar en diversas vueltas (iteraciones):

1. Requisitos de sistema
2. Requisitos de software
3. Análisis
4. Diseño
5. Implementación
6. Prueba
7. Servicio

El procedimiento popularmente conocido como waterfall model se basa en las fases definidas por
Royce, pero solo prevé una iteración.

En el ensayo publicado por Royce, el término no aparece en ningún momento.

El modelo en cascada de cinco niveles, basado en las propuestas de Winston W. Royce, divide los procesos
de desarrollo en las siguientes fases de proyecto: análisis, diseño, implementación, verificación y
mantenimiento. El gráfico incluye una de las ampliaciones del modelo planteadas por Royce: la verificación de
los resultados de cada una de las fases tomando en consideración las exigencias y especificaciones
formuladas en el paso anterior.

Las fases del desarrollo en cascada

En este modelo, las diferentes fases de un proceso de desarrollo se suceden una detrás de otra como en una
cascada. Cada una de las fases concluye con un resultado provisional (hito) como, por ejemplo, un catálogo
de requisitos en forma de pliego de condiciones, la especificación de una arquitectura de software o una
aplicación a nivel alfa o beta.
Análisis
Todo proyecto de software comienza con una fase de análisis que incluye un estudio de viabilidad y una
definición de los requisitos. En el estudio de viabilidad se evalúan los costes, la rentabilidad y la factibilidad
del proyecto de software. El estudio de viabilidad da como resultado un pliego de condiciones (una
descripción general de los requisitos), un plan y una estimación financiera del proyecto, así como una
propuesta para el cliente, si fuera necesario.

A continuación, se realiza una definición detallada de los requisitos, incluyendo un análisis de la situación de

salida y un concepto. Mientras que los análisis de salida se encargan de describir la problemática en sí, el
concepto ha de definir qué funciones y características debe ofrecer el producto de software para cumplir con
las correspondientes exigencias. La definición de los requisitos da como resultado un pliego de condiciones,
una descripción detallada de cómo se han de cumplir los requisitos del proyecto, así como un plan para la
prueba de aceptación, entre otros.

Por último, la primera fase del waterfall model incluye un análisis de la definición de los requisitos en el que
los problemas complejos se dividen en pequeñas tareas secundarias y se elaboran las correspondientes
estrategias de resolución.
Diseño
La fase de diseño sirve para formular una solución específica en base a las exigencias, tareas y estrategias
definidas en la fase anterior. En esta fase, los desarrolladores de software se encargan de diseñar
la arquitectura de software, así como un plan de diseño detallado del mismo, centrándose en componentes
concretos, como interfaces, entornos de trabajo o bibliotecas. La fase de diseño da como resultado un
borrador preliminar con el plan de diseño del software, así como planes de prueba para los diferentes
componentes.
Implementación
La arquitectura de software concebida en la fase de diseño se ejecuta en la fase de implementación, en la
que se incluye la programación del software, la búsqueda de errores y las pruebas unitarias. En la fase de
implementación, el proyecto de software se traduce al correspondiente lenguaje de programación. Los
diversos componentes se desarrollan por separado, se comprueban a través de las pruebas unitarias y se
integran poco a poco en el producto final. La fase de implementación da como resultado un producto de
software que se comprueba por primera vez como producto final en la siguiente fase (prueba alfa).
Prueba
La fase de prueba incluye la integración del software en el entorno seleccionado. Por norma general, los
productos de software se envían en primer lugar a los usuarios finales seleccionados en versión
beta (pruebas beta). Las pruebas de aceptación desarrolladas en la fase de análisis permiten determinar si el
software cumple con las exigencias definidas con anterioridad. Aquellos productos de software que superan
con éxito las pruebas beta están listos para su lanzamiento.
 Ventajas Desventajas

✔ Una estructura sencilla gracias a unas fases de proyecto ✘ Por norma general, los proyectos más complejos o de varios
claramente diferenciadas. niveles no permiten su división en fases de proyecto claramente
diferenciadas.

✔ Buena documentación del proceso de desarrollo a través de ✘ Poco margen para realizar ajustes a lo largo del proyecto debido a
unos hitos bien definidos. un cambio en las exigencias.

✔ Los costes y la carga de trabajo se pueden estimar al comenzar ✘El usuario final no se integra en el proceso de producción hasta
el proyecto. que no termina la programación.

✔ Aquellos proyectos que se estructuran en base al modelo en ✘En ocasiones, los fallos solo se detectan una vez finalizado el
cascada se pueden representar cronológicamente de forma proceso de desarrollo.
sencilla.
 2. Metodología prototipo

Etapas para la elaboración del modelo de prototipo

Un modelo de construcción de prototipos comienza con la definición de un problema y sus efectos, para poder desarrollar el
prototipo que lo resuelva. Las etapas para la elaboración del modelo de prototipo son:

1. Requisitos de desarrollo

Se realiza un análisis para poder establecer cuáles son los requisitos del programa. Se trata de un diseño básico del prototipo
donde se traza de forma inicial los requisitos necesarios para su desarrollo.

2. Modelaje y desarrollo del código

En esta fase se construye el prototipo inicial según los requisitos establecidos. En esta fase de diseño y construcción se debe
priorizar el tiempo de desarrollo y hacer un uso óptimo de los recursos para reducir su coste.

3. Evaluación

Una vez desarrollado el prototipo es necesario comprobar su funcionamiento, evaluando su funcionalidad y verificando que
cumple realmente con los requisitos iniciales.

4. Modificación

Tras evaluar el prototipo se deben corregir los errores encontrados y aplicar las mejoras necesarias para que esté listo para
ser probado por los usuarios.

5. Documentación

Todo el diseño y desarrollo debe ser documentado para disponer de información precisa y clara del proceso. Es muy
importante el registro de cada paso o acción del desarrollo del prototipo pues es una guía útil a la hora de afrontar el diseño
del producto final.

6. Pruebas

Finalmente, el prototipo debe ser probado por los usuarios para poder recibir el feedback  necesario y así evaluar su utilidad y
rendimiento. Gracias a esta retroalimentación ofrecida por el prototipo se podrá desarrollar un software  de mayor calidad que
resuelva los problemas de los usuarios.

 
 Tipos de modelo de prototipos

Existen diferentes tipos de modelo de prototipos que se utilizan dependiendo del tipo de producto a desarrollar o el objetivo
que se persigue en el desarrollo.

Los principales tipos de modelo de prototipos son:

 Modelo de prototipos rápido

 Evolutionary prototyping

 Incremental prototyping

 Modelo de prototipos horizontal

 Modelo de prototipos vertical

 3. Modelo Incremental
El modelo incremental de gestión de proyectos tiene como objetivo un crecimiento progresivo de la
funcionalidad. Es decir, el producto va evolucionando con cada una de las entregas previstas hasta que se
amolda a lo requerido por el cliente o destinatario.

Este enfoque, que se usó inicialmente para proyectos de software aunque más tarde se aplicó a otros
sectores, establece entregas parciales mediante un calendario de plazos. En cada una de ellas, el producto
debe mostrar una evolución con respecto a la fecha anterior; nunca puede ser igual.

Una de las claves para que esto se haga efectivo es la evaluación de las etapas. Los responsables del
proyecto deben analizar si los resultados parciales son los esperados y si, sobre todo, apuntan al objetivo
principal. De no ser así, deberán intervenir en él e implementar las soluciones que la situación requiera.

¿Cómo saber cuando un modelo de gestión es incremental?

La principal diferencia del modelo incremental con los modelos tradicionales es que las tareas están divididas
en iteraciones, es decir, pequeños lapsos en los cuales se trabaja para conseguir objetivos específicos. Con
los modelos tradicionales no pasaba esto; era necesario esperar hasta el final del proceso.

Sin embargo, no se trata de iteraciones independientes. Por el contrario, están  vinculadas de forma que cada
una suponga un avance con respecto a la anterior. Otras características esenciales de este modelo son:

 Los incrementos son pequeños.

 Permite una fácil administración de las tareas en cada iteración.
 La inversión se materializa a corto plazo.
 Es un modelo propicio a cambios o modificaciones.
 Se adapta a las necesidades que surjan.

Para que esto sea posible, se debe tener en cuenta que las iteraciones no pueden ser demasiado rígidas y
que no existan tareas simultáneas. El modelo incremental exige un encadenamiento progresivo de cada
tarea. Scrum y Kanban son las herramientas más conocidas que emplean este modelo de gestión.

¿Cuáles son las fases del modelo incremental de gestión?

El modelo de gestión incremental no es un modelo necesariamente rígido, es decir, que puede adaptarse a
las características de cualquier tipo de proyecto, existen al menos 7 fases que debemos tener en cuenta a la
hora de implementarlo:

1. Requerimientos: son los objetivos centrales y específicos que persigue el proyecto.

2. Definición de las tareas y las iteraciones: teniendo en cuenta lo que se busca, el siguiente paso es
hacer una lista de tareas y agruparlas en las iteraciones que tendrá el proyecto. Esta agrupación no
puede ser aleatoria. Cada una debe perseguir objetivos específicos que la definan como tal.
3. Diseño de los incrementos: establecidas las iteraciones, es preciso definir cuál será la evolución del
producto en cada una de ellas. Cada iteración debe superar a la que le ha precedido. Esto es lo que
se denomina incremento.
4. Desarrollo del incremento: posteriormente se realizan las tareas previstas y se desarrollan los
incrementos establecidos en la etapa anterior.
5. Validación de incrementos: al término de cada iteración, los responsables de la gestión del proyecto
deben dar por buenos los incrementos que cada una de ellas ha arrojado. Si no son los esperados o
si ha habido algún retroceso, es necesario volver la vista atrás y buscar las causas de ello.
6. Integración de incrementos: una vez son validados, los incrementos dan forma a lo que se denomina
línea incremental o evolución del proyecto en su conjunto. Cada incremento ha contribuido al
resultado final.
7. Entrega del producto: cuando el producto en su conjunto ha sido validado y se confirma su
correspondencia con los objetivos iniciales, se procede a su entrega final.
 4. Modelo Espiral
El modelo de desarrollo en Espiral es una combinación entre el modelo waterfall y un modelo por iteraciones.

El proceso pasa por distintas etapas, desde la de conceptualización, siguiendo el desarrollo, luego una fase
de mejoras, para finalizar con el mantenimiento.

Dentro de cada etapa, tendremos una serie de fases que transcurren desde la planificación, pasando por el
análisis de riesgos, el desarrollo y finalizando en la evaluación de lo realizado. Se incorpora también una fase
de enlace entre etapas, para facilitar la transición entre las mismas.

En definitiva, el equipo de desarrollo en este modelo de desarrollo en espiral comienza con un pequeño
conjunto de requisitos y pasa por cada fase de desarrollo para ese conjunto de requisitos. El equipo de
desarrollo agrega la funcionalidad para el requerimiento adicional en espirales cada vez mayores, hasta que
la aplicación está lista para la fase de producción.

Aquí tenéis una representación gráfica del modelo :

Planificación

Incluye la estimación del coste, el calendario y los recursos para la iteración.

Implica también la comprensión de los requisitos del sistema para la comunicación continua entre el analista
de requerimientos y el cliente.

Análisis del riesgo

La identificación de los riesgos potenciales se realiza mientras se planifica y finaliza la estrategia de

mitigación de riesgos.

Ingeniería

Incluye la codificación, pruebas y el despliegue del software.

Evaluación

Evaluación del software por parte del cliente.

Además, incluye la identificación y el seguimiento de riesgos tales como los retrasos en los plazos y los
sobrecostes.

¿Cuándo deberías usar el desarrollo en Espiral?

El uso del método en espiral, como cualquier otra aproximación al desarrollo de software, tiene escenarios en
los que se devuelve mejor. Luego, cada caso puede tener sus excepciones, cada organización por su propia
estructura puede beneficiar el rendimiento de unas sobre otras, así que esto debéis tomarlo como un
escenario generalista, pero que debe ser estudiado en profundidad caso por caso.

Aparentemente los beneficios del uso del modelo en espiral son más destacados en un entorno donde:

 El proyecto es grande.

 Se quiere que las liberaciones de software sean frecuentes.

 Aplica la creación de un prototipo.

 Es primordial un control de riesgos y costos.

 En proyectos catalogados de riesgo medio-alto y alto.

 Los requisitos son poco claros y complejos.

 Hay un alto grado de cambios y estos pueden aparecer en cualquier momento.

 El compromiso de proyecto a largo plazo está comprometido, bien sea por razones económicas u otras.

Ventajas del modelo en Espiral

A groso modo, las ventajas que se pueden observar en el uso de un modelo de desarrollo en espiral, son las
siguientes:
  La funcionalidad adicional o los cambios se pueden hacer en una etapa posterior.

 La estimación del coste se hace fácil, ya que la construcción del prototipo se hace en pequeños
fragmentos.

 El desarrollo continuo o repetido ayuda en la gestión de riesgos.

 El desarrollo es rápido y las características se añaden de forma sistemática.

 Siempre hay espacio para atender los comentarios de los clientes.

Desventajas del modelo en Espiral

En la parte negativa, podemos decir que el modelo en Espiral nos presenta los siguientes retos a los que
tendremos que hacer frente si nos decimos a emplear esta aproximación en nuestros proyectos:

 Riesgo de no cumplir con la planificación o el presupuesto.

 Funciona mejor para proyectos grandes, aunque en estos también requiera de una estricta evaluación
de riesgos.

 Para su buen funcionamiento, el protocolo del modelo en espiral debe ser seguido estrictamente.

 Se genera más documentación al tener fases intermedias.

 No es aconsejable para proyectos pequeños, la ratio coste beneficio no es rentable.

Desarrollo rápido de aplicaciones (RAD) para principiantes

Conforme su equipo se amplíe, es posible que quiera cambiar su enfoque del desarrollo de software. Por
suerte, la industria de TI ya está trabajando para satisfacer las demandas de crear una solución más rápida y
potente que también tenga poco o nada de código, sea rentable y ágil por naturaleza. Una solución que
puede ayudarle a satisfacer sus demandas, además de ser cada vez más popular, es el desarrollo rápido de
aplicaciones (RAD).

¿Qué es el desarrollo rápido de aplicaciones o RAD?

El desarrollo rápido de aplicaciones, concebido en la década de 1970 pero presentado oficialmente por James
Martin en 1991, es una metodología que se centra en desarrollar aplicaciones rápidamente por medio de
iteraciones frecuentes y aprobaciones con comentarios continuos de los clientes. Al priorizar los lanzamientos
de prototipos ágiles y rápidos, RAD incide en la usabilidad del software, los comentarios de los usuarios y la
entrega rápida a través de una planificación a largo plazo y un único conjunto de requisitos iniciales para la
creación de elementos, como las aplicaciones personalizadas..
Los beneficios clave de la metodología RAD son:
 Reducción del tiempo de desarrollo y aceleración de la entrega.
 Mejora de la flexibilidad y la adaptabilidad.
 Mejor gestión de riesgos.
 Menos codificación manual y tiempos de prueba más cortos.
 Comentarios de los usuarios constantes, relevantes y en tiempo real.

Pasos del desarrollo rápido de aplicaciones

RAD cuenta con un conjunto definido de cuatro pasos necesarios para completar un proyecto. El objetivo de
RAD es reducir el tiempo de planificación y centrarse en la construcción y creación de un producto. Por tanto,
aunque se repitan algunos pasos, se obtiene un producto del que tanto su equipo como las partes interesadas
pueden estar orgullosos.
1. Definición de los requisitos del proyecto. En esta fase, todos los involucrados (usted, los desarrolladores, los
usuarios del software y las partes interesadas) definen, investigan y finalizan el alcance y los requisitos de su
proyecto, como los objetivos, las expectativas, los plazos y el presupuesto. Ya sea a través de un informe
inicial o creativo, las partes interesadas propondrán su visión y sus responsables de tomar decisiones de TI y
desarrolladores ayudarán a finalizar todos esos requisitos. Uno de los beneficios del método RAD es que,
aunque haya decidido sus requisitos, puede cambiar con facilidad en cualquier momento del ciclo de
desarrollo.
2. Creación de prototipos. A continuación, su equipo comienza a crear modelos y prototipos. El objetivo es
producir rápidamente un modelo de trabajo para presentarlo a la parte interesada. Los desarrolladores y
diseñadores trabajan juntos para garantizar que cumplen los objetivos y requisitos de la parte interesada.
Durante las primeras etapas de la creación de prototipos, los desarrolladores tienen la oportunidad de crear
soluciones alternativas que produzcan un producto funcional sin sacrificar la calidad. A medida que el equipo
crea un producto funcional, aquí es donde la experiencia del usuario, las pruebas y los comentarios juegan un
papel crucial.

Unos comentarios constantes ayudan a su equipo a trabajar dentro de un sistema en vivo en lugar de un
diseño abstracto. Al trabajar de manera constante en soluciones provisionales y errores, se pueden realizar
ajustes para garantizar que se cumplen los requisitos y en un modelo que funcione. Esto también significa
que los errores se encuentran y depuran en una fase más temprana del proceso, lo que ayuda a mantenerse
comprometido con la escala de tiempo de la parte interesada y garantiza que su proyecto esté mejor
estructurado para futuras adiciones de diseño.
3. Creación, pruebas e incorporación de comentarios. Con un prototipo funcional, ahora es el momento de
convertirlo en un modelo funcional. Los desarrolladores recopilan comentarios de los usuarios y crean el
producto. Asegúrese de implementar su software de creación de aplicaciones en el proceso para darle vida a
su idea. Con la codificación de aplicaciones, las pruebas del sistema y la integración de unidades, el prototipo
y los sistemas beta se convierten en un modelo funcional. Dado que los equipos usan herramientas de
desarrollo rápido de aplicaciones y de poco código, puede abordar rápidamente cualquier cambio.

El software y las aplicaciones se prueban minuciosamente y las partes interesadas pueden proponer cambios
o aportar nuevas ideas a medida que se detectan problemas. No debería haber muchos errores, ya que la
ventaja de RAD es que la mayoría de errores pueden verse en tiempo real durante de la fase de creación de
prototipos y ajustarse después de inmediato. Una vez que las partes interesadas estén satisfechas con su
producto, puede completarlo.
4. Finalización e implementación. La etapa final es hacer una versión optimizada del producto final que sea
estable y fácil de mantener para una mayor longevidad. Las características, funciones y estética se finalizan
con la parte interesada. Una vez que ha pasado a la producción, los usuarios pueden realizar pruebas o
formación a gran escala. Ahora, su producto está listo para presentarlo a la parte interesada.