FACULTAD DE INGENIERÍA Y ARQUITECTURA

ESCUELA PROFESIONAL DE INGENIERÍA DE

SISTEMAS E INFORMÁTICA

“Metodologías de desarrollo de software”

CICLO: VI

CURSO: INGENIERIA DE SOFTWARE

INTEGRANTES:

DOCENTE:

LIMA – PERÚ
2018
 1. MODELO CASCADA

Si alguna vez has incursionado en el mundo del Desarrollo de Software, de seguro te

has topado en algún momento con el modelo de cascada. De no ser así, cabe destacar
que en este modelo cada etapa representa una unidad de desarrollo con un pequeño
descanso en el medio. Por lo tanto, cada siguiente etapa inicia tan pronto como la
anterior haya culminado, y esos descansos son usados para confirmaciones del lado del
cliente.
Adicionalmente, este es considerado como el método tradicional de explicar el proceso
de desarrollo de software en ingeniería de software, por lo que actualmente es visto como
anticuado. Sin embargo, aún sigue siendo aplicado a proyectos con metas claras y
requisitos que demandan hasta 100 horas de desarrollo, sobre todo considerando que
este enfoque permite a los negocios deshacerse del papeleo innecesario, reuniones
regulares que consumen mucho tiempo y retrasos en sus procesos de negocio.
Es por esto que esta es una gran opción para pequeños proyectos donde todos los
aspectos del proceso de desarrollo de software se conocen de antemano, pero una mala
solución para proyectos complicados, ya que se trata de un modelo bastante inflexible.
También conocido como modelo clásico, modelo tradicional o modelo lineal secuencial. Él
método de la cascada es considerado como el enfoque clásico para el ciclo de vida del desarrollo
de sistemas, se puede decir que es un método puro que implica un desarrollo rígido. Está es una
secuencia de actividades(o etapas) que consisten en el análisis de requerimientos, él diseño, la
implementación, la integración y las pruebas.
 El análisis de requerimientos consiste en reunir las necesidades del producto y casi
siempre su salida es texto.
 El diseño describe la estructura interna del producto y suele representarse con
diagramas y texto.
 La implementación significa programación. Producto de esta etapa es el código en
cualquier nivel, incluido el producido por sistemas de generación automática.
 La integración es el proceso de integración es el proceso de ensamblar las partes para
completar el producto.
Es caracterizado por ordenar de manera rigurosa las etapas del ciclo de vida de software, dado
que el comienzo de cada etapa debe esperar a la finalización de la inmediata anterior. Cuando
la revisión determina que el proyecto no está listo para pasar a la siguiente etapa, permanece en
la etapa actual hasta que esté preparado. Y debido a que el proceso está planeado es más fácil
determinar costos y los plazos. Esté modelo puede ser visto como un modelo con forma de
cascada de agua con varios saltos, en la que cada salto representa cada una de las fases del
ciclo de vida.

La metodología en cascada es esencialmente:

 El inicio y el alcance del proyecto
 La planificación del proyecto (calendario, recursos necesarios, costo)
 Definición de las necesidades del negocio y el análisis en detalle dela solución
 La creación de la solución
 Prueba que la solución funciona. La entrega de la solución a su público objetivo
 Cierre del proyecto.
Ventajas:
1. Permite la departamentalización y control de gestión.
2. El horario se establece con los plazos normalmente adecuados para cada etapa de
desarrollo.
3. Este proceso conduce a entregar el proyecto a tiempo.
4. Es sencilla y facilita la gestión de proyectos.
5. Permite tener bajo control el proyecto.
6. Limita la cantidad de interacción entre equipos que se produce durante el desarrollo.
Criticas:
No refleja realmente el proceso de desarrollo del software. Ya que la mayoría de los que
desarrollan proyectos no cumple con este lineamiento.
Se tarda mucho tiempo en pasar por todo el ciclo
La aplicación de la metodología en cascada se orienta mejor al desarrollo de proyectos de corto
plazo, de poca innovación y proyectos definitivos y detallados.
Metodología pueden confundir al equipo profesional en las etapas tempranas del proyecto.
No es frecuente que el cliente o usuario final explicite clara y completamente los requisitos.

2. MODELO ESPIRAL

Mientras que la metodología de la cascada ofrece una estructura ordenada para el

desarrollo de software, las demandas de tiempo reducido al mercado hacen que sus
pasos en serie sean inapropiados.
El siguiente paso evolutivo desde la cascada es donde se realizan los diversos pasos
para múltiples entregas o traspasos. La última evolución de la caída del agua es la
espiral, aprovechando el hecho de que los proyectos de desarrollo funcionan mejor
cuando son incrementales e iterativos.
La metodología espiral refleja la relación de tareas con prototipos rápidos, mayor
paralelismo y concurrencia en las actividades de diseño y construcción. El método en
espiral debe todavía ser planificado metódicamente, con las tareas y entregables
identificados para cada paso en la espiral.
Funcionamiento del Modelo

En el modelo espiral, el software se desarrolla en una serie de versiones incrementales. Durante

las primeras iteracciones, la version incremental podría ser un modelo en papel o un prototipo.
Durante las últimas iteraciones, se producen versiones cada vez más completas del sistema
diseñado.

Regiones de Tareas del Modelo

El modelo en espiral se divide en un número de actividades de marco de trabajo, también

llamadas regiones de tareas. Generalmente, existen entre tres y seis regiones de tareas.

Comunicación con el cliente

Las tareas requeridas para establecer comunicación entre el desarrollador yel cliente.

Planificación

Las tareas requeridas para definir recursos, el tiempo y otra información relacionadas con el
proyecto.

Análisis de riesgos

Las tareas requeridas para evaluar riesgos técnicos y de gestión.

Ingeniería

Las tareas requeridas para construir una o más representaciones de la aplicación.

Construcción y acción

Las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario (por
ejemplo: documentación y práctica)

Evaluación del cliente

Las tareas requeridas para obtener la reacción del cliente según la evaluación de las
representaciones del software creadas durante la etapa de ingeniería e implementada durante la
etapa de instalación. Cada una de las regiones está compuestas por un conjunto de tareas del
trabajo, llamado conjunto de tareas, que se adaptan a las características del proyecto que va a
emprenderse. Para proyectos pequeños, el número de tareas de trabajo y su formalidad es bajo.
Para proyectos mayores y más críticos cada región de tareas contiene tareas de trabajo que se
definen para lograr un nivel más alto de formalidad. En todos los casos, se aplican las actividades
de protección.

Ventajas del Modelo

 Puede adaptarse y aplicarse a lo largo de la vida del software de computadora.
 Es un enfoque realista del desarrollo de sistemas y de software a gran escala.
 Como el software evoluciona, a medida que progresa el proceso el desarrollador y el
cliente comprende y reaccionan mejor ante riesgos en cada uno de los niveles evolutivos.
 Utiliza la construcción de prototipos como mecanismo de reducción de riesgos.
 Permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier
etapa de evolución del producto.
 Mantiene el enfoque sistemático de los pasos sugeridos por el ciclo de vida clásico, pero
lo incorpora al marco de trabajo iterativo que refleja de forma más realista el mundo real.
  Demanda una consideración directa de los riesgos técnicos en todas las etapas del
proyecto, y, si se aplica adecuadamente, debe reducir los riesgos antes de que se
conviertan en problemáticos.
Desventajas del Modelo

 Puede resultar difícil convencer a grandes clientes (particularmente en situaciones bajo

contrato) de que el enfoque evolutivo es controlable.
 Requiere una considerable habilidad para la evaluación del riesgo.
 No se ha utilizado tanto como los paradigmas lineales secuenciales o de construcción
de prototipos.

3. METODOLOGIA DE PROTOTIPO

Es un procedimiento de desarrollo especializado que permite a los desarrolladores la

posibilidad de poder solo hacer la muestra de la resolución para poder validar su esencia
funcional ante los clientes, y hacer los cambios que sean fundamentales antes de crear
la solución final auténtica. De hecho, la mejor parte de esta metodología es que tiende a
resolver un conjunto de problemas de diversificación que ocurren con el método de la
cascada.
Además de esto, la gran ventaja de optar por este enfoque es que da una idea clara
sobre el proceso funcional del software, reduce el riesgo de falla en una funcionalidad
de software y asiste bien en la recolección de requisitos y en el análisis general.
VENTAJAS
 Modificación del Sistema en Etapas tempranas de su desarrollo: El éxito del uso del
prototipo depende de qué tan pronto y con qué frecuencia se reciba la retroalimentación
del usuario para hacer cambios y adecuarlos a las necesidades actuales.
 Permite al desarrollador darse cuenta de lo que requiere el cliente.
 Permite que el desarrollador se dé cuenta cómo va avanzando en trabajo.
 Los cambios iníciales durante el desarrollo de un proyecto son menos costosos que si se
realizan en etapas tardías, como el prototipo puede cambiar varias veces la flexibilidad y
adaptabilidad son su esencia, la pauta del cambio la da la retroalimentación, la cual nos
permite conocer la opinión del usuario sobre cambios a la entrada o salida de un proceso,
que al evaluarla nos permite obtener los requerimientos y mejorar el sistema.
Desventajas
 Administración difícil: Dicha dificultad radica en manejar el prototipo como un proyecto
dentro del Ciclo de Desarrollo de Sistema sin perder de vista cuál era su propósito.
 Adoptarlo como el sistema final: Los usuarios y profesionales de sistemas pueden
considerar al prototipo como el sistema final cuando aún es incompleto e inadecuado.
 El desarrollador y el cliente tienen poca comunicación al inicio del proceso.
 Surgen cambios imprevistos que retrasan el progreso del prototipo.

4. DESARROLLO DE APLICACIONES (RAD)

Con el objetivo de otorgar resultados rápidos, se trata de un enfoque que está destinado
a proporcionar un excelente procesos de desarrollo con la ayuda de otros enfoques, pero
además, está diseñado para aumentar la viabilidad de todo el procedimiento de
desarrollo de software para resaltar la participación de un usuario activo.
Dicho esto, algunas de las ventajas a destacar de este tipo de desarrollo son las
siguientes:

Hace todo el proceso de desarrollo sin esfuerzo.

Asiste al cliente en la realización de revisiones rápidas.
Alienta la retroalimentación de los clientes para su mejora.
Objetivo
Desarrollar prototipos de la aplicación de forma veloz interactuando con el usuario
formando prototipos cada vez mas adecuados a la funcionalidad que se requiere.
Para ello utiliza principalmente software de generación automática de código,
requiriendo desarrolladores especializados en el software en cuestión para evitar en
mayor medida posible los problemas de código que estos programas generan, haciendo
el mantenimiento y pulido de la aplicación o sistema más laborioso, con la ventaja de
tener el software usable en menor tiempo.
Principios básicos
-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.
El método comprende el desarrollo iterativo, la construcción de prototipos y el uso de
utilidades de tipo case.
VENTAJAS
 Comprar puede ahorrar dinero en comparación con construir.
 Los entregables pueden ser fácilmente trasladados a otra plataforma.
 El desarrollo se realiza a un nivel de abstracción mayor.
 Visibilidad temprana.
 Mayor flexibilidad.
 Menor codificación manual.
 Mayor involucramiento de los usuarios.
 Posiblemente menos fallas.
 Posiblemente menor costo.
 Ciclos de desarrollo más pequeños.
 Interfaz gráfica estándar.
DESVENTAJAS
 Comprar puede ser más caro que construir.
 Costo de herramientas integradas y equipo necesario.
 Progreso más difícil de medir.
 Menos eficiente.
 Menor precisión científica.
 Riesgo de revertirse a las prácticas sin control de antaño.
 Más fallas (por síndrome de “codificar a lo bestia”).
 Prototipos pueden no escalar, un problema mayúsculo.
 Funciones reducidas (por “timeboxing”).
 Dependencia en componentes de terceros: funcionalidad de más o de menos,
problemas legales.
 5. METODOLOGÍA DE PROGRAMACION EXTREMA (XP)
Como metodología ágil de ingeniería de software, la metodología de programación
extrema se conoce actualmente como metodología de XP (eXtreme Programming). Esta
metodología, se utiliza principalmente para evitar el desarrollo de funciones que
actualmente no se necesitan, pero sobre todo para para atender proyectos complicados.
Sin embargo, sus métodos peculiares pueden tomar más tiempo, así como recursos
humanos en comparación con otros enfoques.
Son solo algunas de las metodologías de Desarrollo de Software que existen, pero lo
importante es que tengas en cuenta que al estar familiarizado con estos populares
enfoques podrás optimizar la eficiencia de tus proyectos utilizando un enfoque puro o
combinando algunos de ellos.
Dicho esto, si deseas saber más sobre Desarrollo de Software en México, Panamá y
Ecuador, así como otro países de la región de Latinoamérica, te invitamos a descargar
el material con el que podrás disfrutar de un recorrido por los aspectos más básicos de
esta solución.
Ventajas

 Programación organizada.
 Menor taza de errores.
 Satisfacción del programador.
 Solución de errores de programas
 Versiones nuevas
 Implementa una forma de trabajo donde se adapte fácilmente a las circunstancias

Desventajas

 Es recomendable emplearlo solo en proyectos a corto plazo

 Altas comisiones en caso de fallar
 Imposible prever todo antes de programar
 Demasiado costoso e innecesario

¿Qué metodología escoger?

Existen dos tipos principales de metodologías, las Ligeras y las Pesadas. Las primeras son
metodologías extremadamente prácticas que generalmente obvian gran parte de la
documentación y están mas preparadas para utilizarse en proyectos cuyos requisitos cambiarán
constantemente durante todo el proceso. Las segundas, son metodologías donde todo está
mucho más controlado y se genera muchísima documentación antes de proceder a implementar
el proyecto, con mucho mayor peso del análisis y el diseño sobre el proyecto. Estas últimas son
más indicadas para proyectos grandes o cuyo rendimiento y nivel de calidad son críticos para el
éxito de éste. Ejemplos de metodologías ligeras podrían ser eXtreme Programming (XP),
SCRUM y crystal, mientras que ejemplos de metodologías pesadas podrían ser Rational Unified
Process (RUP), ICONIX y Métrica 3.