Las metodologías tradicionales

Imponen una disciplina de trabajo sobre el proceso de desarrollo del software,

para ello,
se hace énfasis en la planificación total de todo el trabajo a realizar y una vez
que está todo detallado,
comienza el ciclo de desarrollo del producto software. Se centran
especialmente en el control del proceso, mediante una rigurosa definición de
roles, actividades, artefactos, herramientas y notaciones para el modelado y la
documentación detallada.
Además, las metodologías tradicionales no se adaptan adecuadamente a los
cambios, por lo que no son métodos adecuados cuando se trabaja en un
entorno,
donde los requisitos no pueden predecirse o bien pueden variar.

Existen muchos tipos de metodologías tradicionales, entre ellas tienen algunas

variaciones, pero para no entrar en tanto detalle, decidimos mostrar algunas de
las más usadas.
Waterfall (Cascada)
En la Ingeniería de software el desarrollo en cascada, también llamado
secuencial o ciclo de vida de un programa (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.

ESPIRAL
El desarrollo o modelo en espiral es un enfoque de desarrollo de software que
puede ser considerado como una respuesta a los inconvenientes del desarrollo
en cascada. El modelo en espiral describe el ciclo de vida de un software por
medio de espirales, que se repiten hasta que se puede entregar el producto
terminado.
El desarrollo en espiral también se conoce como desarrollo o modelo
incremental. El producto se trabaja continuamente y las mejoras a menudo
tienen lugar en pasos muy pequeños.
Una característica clave del desarrollo en espiral es la minimización de los
riesgos en el desarrollo de software, lo que podría resultar en un aumento de
los costes totales, más esfuerzo y un lanzamiento retardado. Estos riesgos son
contrarrestados por el enfoque incremental, haciendo primero prototipos, que
luego pasan al menos una vez, por las fases de desarrollo de software.
El desarrollo en espiral es genérico y puede combinarse con otros métodos de
desarrollo clásicos y ágiles, por lo que también se denomina modelo o
desarrollo de segundo orden.
El modelo en espiral esta compartida en varias actividades estructurales,
también llamadas regiones de tareas. Existen seis regiones:
Comunicación con el cliente: esta es una tarea requerida para establecer
comunicación entre el desarrollador y el cliente
Planificación: esta tarea es necesaria aplicarla para poder definir los recursos,
el tiempo y otras informaciones relacionadas con el proyecto, es decir, son
todos los requerimientos.
Análisis de riesgos: esta es una de las tareas principales por lo que se aplica
el modelo en espiral, es requerida para evaluar los riesgos técnicos y otras
informaciones relacionadas con el proyecto.
Ingeniería: esta es una tarea necesaria ya que se requiere construir una o más
representaciones de la aplicación.
Evaluación el cliente: esta también es una tarea principal, necesaria para
adquirir la reacción del cliente según la evaluación de las representaciones del
software creadas durante la etapa de ingeniería y la de implementación creada
durante la etapa de instalación
Construcción y entrega: esta tarea es requerida en el modelo espiral porque
se necesita construir, probar, instalar y proporcionar soporte al usuario.
RAD (Desarrollo rápido de Aplicaciones)
Planificación de requerimientos: durante esta etapa inicial, los diseñadores,
desarrolladores y usuarios llegan a un acuerdo aproximado sobre el alcance
del proyecto y los requisitos de la aplicación, para que puedan comenzar las
etapas futuras con creación de prototipos.
Diseño con el usuario: los comentarios de los usuarios se recopilan con gran
énfasis en la determinación de la arquitectura del sistema. Esto permite crear
modelos y prototipos iniciales. Este paso se repite tantas veces como sea
necesario a medida que el proyecto evoluciona.
Construcción: una vez que ha comenzado el diseño básico del usuario y del
sistema, la fase de construcción es donde se lleva a cabo la mayor parte de la
codificación, las pruebas y la integración reales de la aplicación. Junto con el
diseño del usuario, la fase de construcción rápida se repite tantas veces como
sea necesario, a medida que se requieran nuevos componentes o se realicen
modificaciones para satisfacer las necesidades del proyecto.
Transicción: la etapa final de Transicción (o Cutover) le permite al equipo de
desarrollo tiempo para mover los componentes a un entorno de producción en
vivo, donde se pueden llevar a cabo todas las pruebas necesarias o la
capacitación del equipo.
Métrica V3

https://sites.google.com/site/aessl13g314/practica-2/1-2-descripcion-de-la-metodologia

https://www.youtube.com/watch?v=BfQUKChuMTc

Proceso Unificado de Desarrollo (RUP)

https://es.wikipedia.org/wiki/Proceso_unificado