Metodologa

Cascada

INCREMENTAL

Espiral

Modelo Evolutivo

Ganar Ganar

Proceso Unificado

Emergente o XP ( extreme programing )

gil o Scrum

Ingenieria Web

Basado en componentes

Concepto y Caractersticas

Tambin conocido como modelo clsico, modelo tradicional o

modelo lineal secuencial. l mtodo de la cascada es
considerado como el enfoque clsico para el ciclo de vida del
desarrollo de sistemas, se puede decir que es un mtodo puro
que implica un desarrollo rgido. Esta es una secuencia de
actividades que consisten en el anlisis de requerimientos, l
diseo ,la implementacin, la integracin y las pruebas. Su
caracterstica principal consiste en que no se puede avanzar
de etapa si no se ha terminado la enterior.

CONCEPTO: El modelo incremental fue propuesto por Harlan Mills

en el ao 1980. Surgi el enfoque incremental de desarrollocomo
una forma de reducir la repeticin del trabajo en el proceso de
desarrollo y dar oportunidad de retrasar la toma de decisiones en los
requisitos hasta adquirirexperiencia con el sistema. Este modelo se
conoce tambin bajo las siguientes denominaciones:
Mtodo de las comparaciones limitadas sucesivas.
Ciencia de salir del paso.
Mtodo de atacar el problema por ramas.
El modelo incremental combina elementos del modelo en cascada
con la filosofa interactiva de construccin de prototipos. Se basa en
la filosofa de construir incrementando las funcionalidades del
programa. Este modelo aplica secuencias lineales de forma
escalonada mientras progresa el tiempo en el calendario. Cada
secuencia lineal produce un incremento del software.
Caractersticas:
Se evitan proyectos largos y se entrega "algo de valor" a los
usuarios con cierta frecuencia.
El usuario se involucra mas.
Dificil de evaluar el costo total.
Dificil de aplicar a los sistemas transaccionales que tienden a ser
integrados y a operar como un todo.
Requiere gestores experimentados.
Los errores en los requisitos se detectan tarde.
El resultado puede ser positivo.

es un modelo de proceso de software evolutivo donde se

conjuga la naturaleza de construccin de prototipos con los
aspectos controlados y sistemticos del MODELO LINEAL y
SECUENCIAL. Proporciona el potencial para el desarrollo
rpido de versiones incrementales del software que no se
basa en fases claramente definidas y separadas para crear un
sistema.

Es el modelo cuyas etapas consisten en expandir incrementos de

un producto de software operacional donde la direccin de la
evolucin la dicta la experiencia con el sistema . El cliente recibe
pequeos incrementos del sistema a medida que van siendo
desarrollados : distribucin incremental .
El cliente recibe pequeos incrementos del sistema a medida que
van siendo desarrollados : distribucin incremental .
CARACTERISTICAS
Gestionan bien la naturaleza evolutiva del software
Son iterativos: construyen versiones de software
cada vez ms completas
ES INTERACTIVO
-Con cada incremento se entrega al cliente un producto
operacional , que puede evaluarlo
PERSONAL
- Permite variar el personal asignado a cada interaccin
GESTION RIESGOS TECNICOS
- Por ejemplo disponibilidad de hardware especifico

En los modelos clsicos surge en la comunicacin con los

clientes para determinar los requisitos, en este modelo se
basa en la negociacin entre el cliente y el desarrollador, se
negocia coste frente a funcionalidades, rendimiento, calidad, o
simplemente el gestor del proyecto le pregunta al cliente qu
necesita y l proporciona la informacin para continuar.
Esto se refiere que a la obtencin de requisitos requieren de
una negociacin, que tiene xito
cuando ambas partes ganan.

es un mtodo iterativo de diseo de software que describe

cmo desarrollar software de forma eficaz, utilizando tcnicas
probadas en la industria.
El Proceso Unificado de Desarrollo de Software o
simplemente Proceso Unificado es un marco de desarrollo de
software que se caracteriza por estar dirigido por casos de
uso, centrado en la arquitectura, enfocado en el riesgo, y por
ser iterativo e incremental.
El nombre Proceso
Unificado se usa para describir el proceso genrico que
incluye aquellos elementos que son comunes a la mayora de
los refinamientos existentes. Es una metodologa orientada a
conducir el proceso de desarrollo de software en sus aspectos
tcnicos; los flujos y productos de trabajo de UP no incluyen la
administracin del proyecto.

Est centrada en en potenciar las relaciones interpersonales

como clave para el xito. Se basa en realimentacin continua
entre el cliente y el equipo de desarrollo, comunicacin fluda
entre todos los participantes y simplicidad en las soluciones
implementadas

Scrum es una metodologa gil y flexible para gestionar el

desarrollo de software, cuyo principal objetivo es maximizar
el retorno de la inversin para su empresa y minimizar los
riesgos. Se basa en construir primero la funcionalidad de
mayor valor para el cliente y en los principios de inspeccin
continua, adaptacin, auto-gestin e innovacin.

La ingeniera web es la aplicacin de metodologas

sistemticas, disciplinadas y cuantificables al desarrollo
eficiente, operacin y evolucin de aplicaciones de alta calidad
en la www.

El modelo de desarrollo basado en componentes

incorpora muchas de las caractersticas del modelo
espiral. Es evolutivo por naturaleza y exige un enfoque
interactivo para la creacin del software. Sin embargo,
el modelo de desarrollo basado en componentes
configura aplicaciones desde componentes preparados
de software (clases).
El modelo de desarrollo basado en componentes
conduce ala reutilizacin del software, y la reutilizacin
proporciona beneficios a los ingenieros de software.

Domnguez Garca Carlo

Ramos Gmez Jorge

Etapas

Anlisis
Diseo

Implementacin
Pruebas
Mantenimiento

el proceso se divide en 4 partes:

Anlisis
Diseo
Cdigo
Prueba Producto

-Planeacin
-Anlisis de riesgo
-Ingeniera
-Evaluacin

Especificacion inicial
del producto
Evaluacion(version del software)

Desarrollo
Implementacion,uso y
Re-especificacion

Se consideran cuatro ciclos, compuesto cada uno de cuatro

actividades:
-Elaborar los
objetivos, restricciones y alternativas del proceso y producto del
sistema y subsistema
-Evaluar las alternativas con respecto a los objetivos y
restricciones.
-Identificar y resolver las fuentes principales de riesgo en el
proceso y el producto.
-Elaborar la definicin del producto y proceso.

Fase de Inicio en UP
Fase de Elaboracin en
UP
Fase de Construccin en UP
Fase de
Transicin en UP

Fase I: Exploracin
Fase II: Planificacin de la entrega
III: Iteraciones
Produccin
Mantenimiento
proyecto

Fase
Fase IV:
Fase V:
Fase VI: Muerte del

Planificacin de la Iteracin
Ejecucin de la Iteracin
Adaptacin

Inspeccion y

Anlisis de requisitos
Conceptual
Navegacional

Diseo
Diseo
Diseo de
Presentacin

Reutilizacin del Software

Simplificacin de Pruebas
Mantenimiento del Sistema
Mayor Calidad

Domnguez Garca Carlo Alejandro

Ramos Gmez Jorge Ivn
Descripcin de cada etapa

El anlisis de requerimientos consiste en reunir las necesidades del cliente para poder implementarlas en un siste
Diseo: describe la estructura interna del producto y suele representarse con diagramas y texto.
Implementacin: en esta etapa se desarrolla el sistema tomando en cuenta el anlisis y el diseo previamente rea
Prueba: es la etapa en donde se evalua el sistema y se detectan errores.
Mantenimiento: la etapa de cierre del mtodo, ya que es la que llega al usuario final para que cumpla con todas las

Anlisis: La primera etapa en la produccin de un sistema de software esdecidir exactamente que ha de hacer el
etapatambin se conoce como etapa de requisitos o especificacionesy por esta circunstancia muchos tratadistas s
laetapa en otras dos.
Anlisis y definicin del problema(requisitos)
Especificacin de requisitos(especificaciones)
Diseo: El diseo se considera como un actividad y consiste en lasolucin de negocios para el usuario y se exp
casosde uso. El diseo es la solucin del equipo de proyecto delnegocio y consiste de las siguientes tar
Identificar los usuarios y sus roles
Obtener datos de los usuarios
Evaluar la informacin
Documentar los escenarios de uso
Validar con los usuarios
Validar contra la arquitectura de la empresa
Cdigo: El diseo debe traducirse en una forma legible para la mquina.Se implementa el cdigo fuente. Dependie
deprogramacin y su versin se crean las libreras y componentesreutilizables dentro del mismo proyecto para
laprogramacin sea un proceso mucha ms rpido.
Pruebas: Durante la prueba de Sistemas, el Sistema se emplea demanera experimental para asegurarse de que
notenga fallas, es decir, que funciona de acuerdo con lasespecificaciones y en la forma en que los usuarios esperan
alimentan como entradas conjunto de datos deprueba para su procesamiento y despus se examinan losre
Producto: En la parte final de la etapa nos encontramos con la etapaproducto el cual nos da a conocer que e
quedesarrollamos gracias al mtodo incremental, a sido terminado yahora es un producto listo para ser usado,
laprueba de errores.

Planeacin : determinacin de los objetivos, alternativas y restricciones

Anlisis de riesgo : anlisis de alternativas e identificacin/resolucin de riesgos
Ingeniera : desarrollo del producto hasta "el siguiente nivel".
Evaluacin : valoracin por parte del cliente de los resultados obtenidos.

Definicion del problema y especificacion inicial en base a los requisitos definidos

software en base a un proceso con enfasis en la rapidez de la liberacion
en ambiente de explotacion , monitores de los nuevos requerimientos
nuevos requerimientos

Desa
Implantacion y u
Re-definicion del problema en

Ciclo 0. Grupos de aplicacin. Se determina la viabilidad de un grupo apropiado de aplicaciones

Ciclo 1. Objetivos del ciclo de vida de la ap
desarrollan los objetivos del ciclo de vida, incluyendo prototipos, planes y especificaciones de aplicaciones individua
la existencia de al menos una arquitectura viable para cada aplicacin.
Ciclo
del ciclo de vida de la aplicacin. Se establece una arquitectura del ciclo de vida detallado, se verifica la viabilidad
no existen riesgos mayores en satisfacer los planes y especificaciones.
Ciclo 3. Capacidad de operacin inicial. Alcanzar una capacidad operacional inicial para cada
proyecto en el ciclo de vida del software.

Fase de Inicio en UP: En esta fase corresponde definir el negocio. Es la etapa donde se define la factibilidad d
realizar, se representa el modelo de negocio, visin y metas del proyecto, se identifican actores, conceptos de dom
usuario. Adicionalmente se complementa con la definicin de la arquitectura preliminar, y estimaciones (imprecisas
de plazos y costos. Tambin se define la viabilidad del proyecto.
Fase de Elaboracin en UP: En la fase de elaboracin se obtiene la visin refinada del proyecto
implementacin iterativa del ncleo central de la aplicacin, la resolucin de los riesgos ms altos, la identificaci
requisitos y nuevos alcances, y estimaciones ms ajustadas. A esta altura existe la posibilidad de detener el p
complejidad tcnica.
Fase de Construccin en UP
construccin es la implementacin iterativa del resto de los requisitos de menor riesgo y elementos ms sencillos.
hasta convertirse en un producto listo, incluyendo todos los requisitos (100%), para entregarse al Cliente. Al final
sistema contiene todos los casos de uso que el cliente y la direccin del proyecto han acordado. La mayora de lo
que no se desarrollaron en la fase anterior se desarrollan en iteraciones, en grupos de requisitos o casos de uso du
Fase de
UP: Es el periodo donde el producto es completamente entregado al cliente para ser testeado y desplegado (

I.- Exploracin: En esta fase, los clientes plantean a grandes rasgos las historias de usuario que so
para la primera entrega del producto. Al mismo tiempo el equipo de desarrollo se familiariza con las h
tecnologas y prcticas que se utilizarn en el proyecto.
II.- Planificacin: En esta fase el cliente establece la prioridad de cada historia de us
correspondientemente, los programadores realizan una estimacin del esfuerzo necesario de cada un
toman acuerdos sobre el contenido de la primera entrega y se determina un cronograma en conjunto
III.- Iteraciones: El Plan de Entrega est compuesto por iteraciones de no m
semanas. En la primera iteracin se puede intentar establecer una arquitectura del sistema que pued
durante el resto del proyecto.
IV.- Produccin: La fase de p
requiere de pruebas adicionales y revisiones de rendimiento antes de que el sistema sea trasladado
cliente. Al mismo tiempo, se deben tomar decisiones sobre la inclusin de nuevas caractersticas a
actual, debido a cambios durante esta fase.
V.- Manten
Mientras la primera versin se encuentra en produccin, el proyecto XP debe mantener el siste
funcionamiento al mismo tiempo que desarrolla nuevas iteraciones. Para realizar esto se requiere d
soporte para el cliente.
Muerte del proyecto: Es cuando el cliente no tiene ms historias para ser incluidas en el sistema.
que se satisfagan las necesidades del cliente en otros aspectos como rendimiento y confiabilidad de
genera la documentacin final del sistema y no se realizan ms cambios en la arquitectura. La muert
tambin ocurre cuando el sistema no genera los beneficios esperados por el cliente o cuando no hay
para mantenerlo.

Planificacin de la iteracin: Tiene dos partes:

Seleccin de requisitos (4 horas mximo). El cliente presenta al equipo la lista de requisitos priorizada
o proyecto. El equipo pregunta al cliente las dudas que surgen y selecciona los requisitos ms priorita
compromete a completar en la iteracin, de manera que puedan ser entregados si el cliente lo solicita
Planificacin de la iteracin (4 horas mximo). El equipo elabora la lista de tareas de la iteracin nece
desarrollar los requisitos a que se ha comprometido. La estimacin de esfuerzo se hace de manera co
miembros del equipo se autoasignan las tareas.
Ejecucin de la iteracin: Cada da el equipo realiza una reunin de sincronizacin (15 minutos m
miembro del equipo inspecciona el trabajo que el resto est realizando (dependencias entre tareas, pr
el objetivo de la iteracin, obstculos que pueden impedir este objetivo) para poder hacer l
Durante la iteracin el Facilitador (Scrum Master) se encarga de que el equipo pueda cumplir con su c
de que no se merme su productividad.
Elimina los obstculos que el equipo no puede resolver por s mismo.
Protege al equipo de interrupciones externas que puedan afectar su compromiso o su productividad.
Inspeccin y adaptacin: E
la iteracin se realiza la reunin de revisin de la iteracin. Tiene dos partes:
Demostracin (4 horas mximo). El equipo presenta al cliente los requisitos completados en la iteraci
de incremento de producto preparado para ser entregado con el mnimo esfuerzo. En funcin de los re
mostrados y de los cambios que haya habido en el contexto del proyecto, el cliente realiza las adapta
necesarias de manera objetiva, ya desde la primera iteracin, replanificando el proyecto.
Retrospectiva (4 horas mximo). El equipo analiza cmo ha sido su manera de trabajar y cules son lo
que podran impedirle progresar adecuadamente, mejorando de manera continua su productividad. El
encargar de ir eliminando los obstculos identificados.

 Anlisis de Requisitos: Fija los requisitos funcionales de la aplicacin Web para reflejarlos en un
casos de uso.

Diseo Conceptual: Materializado en un modelo de dominio, considerando los requisitos re

casos de uso.

Diseo Navegacional: Lo podemos subdividir en :

Modelo del Espacio de Navegacional.
Modelo de la Estructura de navegacin: Muestra la forma denavegar ante el espacio de na

Diseo de Presentacin: Representa las vistas del interfaz del usuario mediante modelos e
interaccin UML.

Reutilizacin del software. Nos lleva a alcanzar un mayor nivel de reutilizacin de softw
Simplifica las pruebas. Permite que las pruebas sean ejecutadas probando cada uno de los compo
de probar el conjunto completo de componentes ensamblados.
Simplifica el mantenimiento del sistema. Cuando existe un dbil acoplamiento entre compo
desarrollador es libre de actualizar y/o agregar componentes segn sea necesario, sin afectar otras
sistema.
Mayor calidad. Dado que un componente puede ser construido y luego mejorado continuamente po
organizacin, la calidad de una aplicacin basada en componentes mejorar con el paso del ti

Caracterstica del software/aplicar

Realiza un buen funcionamiento en equipos dbiles y productos

maduros, por lo que se requiere de menos capital y herramientas para
hacerlo funcionar de manera ptima.

es para aplicarse a sistemas no transaccionales que no tengan

tendencia a ser integrados ni funcionar como un todo

Debido a su elevada complejidad no se aconseja utilizarlo en pequeos

sistemas y genera mucho tiempo en el desarrollo del sistema. Es
recomendado para sistemas grandes.

Diseado para software que este libre a cambios , e incluso hasta accesible a
ser completamente reemplazado por uno nuevo con la finalidad de satisfacer
nuevas necesidades

Se establecen las reglas para definir el proceso de desarrollo del

proyecto, tomando en cuenta todas las partes implicadas, lo que permite
utilizarlo tanto en proyectos pequeos, como mayores.

Est dirigido por casos de uso.

Est centrado en la arquitectura (es decir, en una solucin de conjunto).
Tiene un ciclo de vida iterativo incremental.
Es una metodologa
orientada a conducir el proceso de desarrollo de software en sus
aspectos tcnicos; los flujos y productos de trabajo de UP no incluyen la
administracin del proyecto.

Es recomendable para desarrollar pequeos sistemas ya que

termina siendo mas eficiente

Sirve para software que requiera funcionar mientras se

desarrolla ya que al termino de cada iteracin el cliente puede
usarlo y conforme a ello ir mejorando el producto, reduciendo
riesgos y evitando prdidas.

Es funcional para cualquier desarrollo de paginas web ya que tiene

demasiadas variaciones y por lo mismo se pueden usar diversas
herramientas para llevarlo a cabo aunque solo suple necesidades de
comunicacin

Se enfoca en reutilizar un software ya existente. Por lo que

puede ser implementado para mejorar algn sistema.

Caracterstica del cliente/aplicar

Es un modelo fcil de implementar y de entender, por lo que el

cliente no necesita de mucho tiempo para comprenderlo pero
ya debe tener muy claras sus ideas y qu es lo que necesita.

Es dirigida para cuando existe poco personal,aplicado para

clientes que puedan congeniar con versiones incompletas de
un sw y que tengan la base economica para satisfacer el
aumento de costo debido a las pruebas

Como el software evoluciona a medida que progresa el

proceso, el desarrollador y el cliente comprenden y reaccionan
mejor ante riesgos en cada uno de los nivele evolutivos. Es
recomendable para clientes que dediquen tiempo al desarrollo
de su sistema.

Se recomienda a clientes que se involucran al desarrollo de su

sistema

En los modelos clsicos surge en la comunicacin con los

clientes para determinar los requisitos, en este modelo se
basa en la negociacin entre el cliente y el desarrollador, se
negocia coste frente a funcionalidades, rendimiento, calidad, o
simplemente el gestor del proyecto le pregunta al cliente qu
necesita y l proporciona la informacin para continuar.

Dirigido a personas que tienen amplio conocimiento sobre los

detalles de la empresa y el tema de ing de softwarecon
respecto a las etapas de cada proceso.

Est dirigido a clientes con tiempo para poder

establecer que es lo que necesita y estar en contacto
con el equipo de desarrollo para lograr los objetivos
planteados

Alta capacidad de reaccin ante los cambios de

requerimientos generados por necesidades del cliente
o evoluciones del mercado. La metodologa est
diseada para adaptarse a los cambios de
requerimientos que conllevan los proyectos complejos.
Por lo que el cliente debe estar en contacto constante
con el sistema que solicita.

Funcional para clientes que no interactuen con sus propios

clientes, ya que est metodologa est enfocada a uso
mediante pginas web.

Clientes que ya tengan sus componentes listos y quieran

adquirir alguna mejora para ellos.

Tiempo de Desarrollo

El proceso de creacin 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.

El proceso de creacion del software es tardado porque los

errores en requisitos se detectan tarde.

Genera mucho tiempo en el desarrollo del sistema, porque se

va desarrllando de manera evolutiva puede ir cambiando
constante mente.

Es del tipo rpido porque busca satisfacer las necesidades del

cliente lo ms pornto posible ademas que hace modificaciones
durante el desarrollo

Se genera mucho tiempo de desarrollo del software ya que se

requiere planificar cada ciclo aparte de que es costoso.

Relativamente lento ya que se busca conocer a detalle cada

proceso para continuar con este mtodo.

Est recomendado para sistemas a corto plazo, por lo

que no requiere mucho tiempo de desarrollo.

Debido a que trata de reducir los riesgos al mnimo y

puede haber cambios mientras se lleva a cabo el
tiempo de desarrollo es largo.

Dependiendo de la cantidad de servicios y productos que se

requieran incluir, por lo que un tiempo de desarrollo depende
del cliente.

Genera mucho tiempo de desarrollo y es costoso aparte de

que requiere mucha experiencia.