Sie sind auf Seite 1von 11

MODELO/ AÑO Y ETAPAS CARACTERISTICAS VENTAJAS DESVENTAJAS APLICACION

METODOLOGIA CREADO
R
Winston  Definición de  Se debe comprobar el  Realiza un buen  Un proyecto rara Es el enfoque
W. Royce requisitos. Software después de funcionamiento en vez sigue una metodológico que ordena
1970  Diseño del sistema unirlo y antes de equipos débiles y secuencia lineal, rigurosamente las etapas
y software operarlo. productos maduros, esto crea una mala del proceso para el
 Implementación y  Es el más utilizado por lo que se implementación del desarrollo de software,
prueba de  Deben desarrollarse requiere de menos modelo, lo cual de tal forma que el inicio
unidades todas las fases capital y hace que lo lleve al de cada etapa debe
 Integración y  Las fases continúan herramientas para fracaso. esperar a la finalización
prueba del hasta que los hacerlo funcionar  El proceso de de la etapa anterior.
sistema objetivos se han de manera óptima. creación
 Funcionamiento y cumplido  Es un modelo fácil del software tarda Al final de cada etapa, el
Cascada Mantenimiento. de implementar y mucho tiempo ya modelo está diseñado
entender. que hasta que para llevar a cabo una
 Está orientado a el software no esté revisión final, que se
documentos. completo no se encarga de determinar si
 Es un modelo opera. Esto es la el proyecto está listo para
conocido y utilizado base para que avanzar a la siguiente
con frecuencia. funcione bien. fase.
 Cualquier error de
diseño detectado en
la etapa de prueba
conduce
necesariamente al
rediseño y
programación del
código afectado,
aumentando los
costos del
desarrollo.
Barry Para cada ciclo:  Contiene una nueva  No requiere una  Existe Utiliza un enfoque
Boehm etapa que es el definición complicación evolutivo para la
1986  Determinar análisis de riesgos, no completa de los cuando se ingeniería de software,
objetivos incluida requerimientos evalúa los permitiendo al
 Análisis del anteriormente. del software a riesgos. desarrollador y al cliente
riesgo  Este modelo es el desarrollar para  Se requiere la entender y reaccionar a
 Desarrollar y indicado para comenzar su participación los riesgos en cada nivel
probar desarrollar software funcionalidad. continua por del modelo en espiral.
 Planificación con diferentes  En la parte del
versiones terminación de cliente. Utiliza la creación de
actualizadas como se un producto  Se pierde prototipos como un
hace con los desde el final de tiempo al volver mecanismo de reducción
programas modernos la primera producir de riesgo, pero, lo más
de PC´s. iteración es inicialmente importante permite a
Espiral  La ingeniería puede muy factible una quien lo desarrolla aplicar
desarrollarse a través aprobar los especificación el enfoque de creación de
del ciclo de vida requisitos. completa de los prototipos en cualquier
clásico o el de  Sufrir retrasos requerimientos etapa de la evolución de
construcción de corre un riesgo cuando se prototipos.
prototipos. menor, porque modifica o
 Este es el enfoque se comprueban mejora el
más realista los conflictos software.
actualmente. presentados
tempranamente
y existe la forma
de poder
corregirlos a
tiempo.
Gomaa  Planeación Este diseño conduce a  Este modelo es útil  Administración Consiste básicamente en
1984  Modelado la construcción de un cuando el cliente difícil: Dicha que en base a los
 Construcción del prototipo, el cual es conoce los dificultad radica en requerimientos y
Prototipo evaluado por el cliente objetivos generales manejar el necesidades que tiene el
 Desarrollo para una para el software,
prototipo como un cliente, se realiza de
 Entrega y retroalimentación; pero no identifica
gracias a ésta se refinan los requisitos proyecto dentro del forma rápida un
retroalimentación Ciclo de Desarrollo prototipo, este no vendrá
los requisitos del detallados de
 Comunicación de Sistema sin completo ni mucho
software que se entrada,
con cliente
desarrollará. La procesamiento o perder de vista cuál menos terminado, pero si
 Entrega del interacción ocurre salida. era su propósito. permitirá contar con las
desarrollo final cuando el prototipo se  También ofrece un  Adoptarlo como el bases necesarias para que
ajusta para satisfacer las mejor enfoque sistema final: Los cualquier programador
necesidades del cliente. cuando el usuarios y pueda seguir trabajando
Esto permite que al responsable del
Prototipos profesionales de en el hasta llegar al
mismo tiempo el desarrollo del
desarrollador entienda sistemas pueden código final.
software está
mejor lo que se debe inseguro de la considerar al
hacer y el cliente vea eficacia de un prototipo como el
resultados a corto plazo. algoritmo, de la sistema final
adaptabilidad de cuando aún es
un sistema incompleto e
operativo o de la inadecuado.
forma que debería  El desarrollador y el
tomar la cliente tienen poca
interacción
humano-máquina
comunicación al
 Se puede reutilizar
inicio del proceso.
el código.  Surgen cambios
imprevistos que
retrasan el progreso
del prototipo.
SAGE  Plan Operativo Es un modelo en el que el  Requiere poca  Estar sometido a El modelo de desarrollo
1956  Especificación software se muestra al sofisticación para una planificación de software por etapas es
de requisitos cliente en etapas los directivos y predefinida. similar al Modelo de
 Especificación refinadas sucesivamente. desarrolladores.  Trabaja con poca prototipos ya que se
funcional De esta manera se  Permite compresión sobre la muestra al cliente el
 Diseño desarrolla las capacidades modificaciones a arquitectura. software en diferentes
 Implementaci más importantes, medio camino.  Trabaja con poca estados sucesivos de
ón reduciendo su tiempo de Requiere poco identificación de los desarrollo, se diferencia
 Integración construcción del tiempo de gestión. requerimientos de en que las
 Validación y producto  Genera un sistema diseño. especificaciones no son
verificación altamente fiable y  Debe entregarse conocidas en detalle al
 Mantenimient con amplio una etapa para inicio del proyecto y por
o desarrollo. continuar con la tanto se van
 Permite una siguiente. desarrollando
Desarrollo por funcionalidad útil en  Este modelo no es simultáneamente con las
etapas manos del cliente viable sin una diferentes versiones del
sin tener la planificación código.
aplicación adecuada.
finalizada.
 Proporciona signos
tangibles de
progreso.
Mills  Requerimientos  El modelo  Mediante este  Cada fase de una Este modelo se centra en
1980  Definición de las incremental combina modelo se genera iteración es rígida y la entrega de un producto
tareas y las elementos del software operativo no se superponen operativo con cada
iteraciones modelo en cascada de forma rápida y con otras. incremento. Los primeros
 Diseño de los con la filosofía en etapas  Pueden surgir incrementos son
incrementos interactiva de tempranas del ciclo problemas referidos versiones incompletas del
 Desarrollo del construcción de de vida del a la arquitectura del producto final, pero
incremento prototipos. software. sistema porque no proporcionan al usuario
 Validación de  Se basa en la filosofía  Es un modelo más todos los requisitos la funcionalidad que
incrementos: de construir flexible, por lo que se han reunido, ya precisa y también una
 Integración de incrementando las se reduce el coste que se supone que plataforma para la
incrementos funcionalidades del en el cambio de todos ellos se han evaluación.
 Entrega del programa. alcance y requisitos. definido al inicio
producto  Este modelo aplica  Es más fácil probar y
secuencias lineales de depurar en una
Incremental forma escalonada iteración más
mientras progresa el pequeña.
tiempo en el  Es más fácil
calendario. Cada gestionar riesgos.
secuencia lineal  Cada iteración es un
produce un hito gestionado
incremento del fácilmente
software
James  Modelado de  El método  Comprar puede  Comprar puede ser Esta metodología
Martin Gestión comprende el ahorrar dinero en más caro que propone un proceso de
1980-  Modelado de desarrollo interactivo, comparación con construir. desarrollo de "software"
1990 Datos la construcción de construir.  Costo de que permite que se creen
 Modelado de prototipos y el uso de  Los entregables herramientas sistemas de
Proceso utilidades CASE pueden ser integradas y equipo computadoras utilizables
 Generación de (Computer Aided fácilmente necesario. en un periodo de tiempo
aplicaciones Software trasladados a otra  Progreso más difícil entre 60 a 90 días. RAD es
 Pruebas de Engineering). plataforma. de medir. un ciclo de desarrollo
entrega  Tradicionalmente, el  El desarrollo se  Menos eficiente. diseñado para crear
desarrollo rápido de realiza a un nivel de  Menor precisión aplicaciones de
aplicaciones tiende a abstracción mayor. científica. computadoras de alta
englobar también la  Visibilidad  Riesgo de revertirse calidad de las que
usabilidad, utilidad y temprana. a las prácticas sin acontecen en
la rapidez de  Mayor flexibilidad. control de antaño. corporaciones grandes.
RAD ejecución.  Menor codificación  Más fallas (por
manual. síndrome de El desarrollo de
 Mayor “codificar a lo aplicaciones enfrenta una
involucramiento de bestia”). transformación
los usuarios.  Prototipos pueden fundamental. Hace cinco
 Posiblemente no escalar, un años un proyecto para
menos fallas. problema desarrollar una aplicación
 Posiblemente mayúsculo. tomaba un periodo de
menor costo.  Funciones reducidas entre 18 a 24 meses;
 Ciclos de desarrollo (por “timeboxing”). actualmente, con la
más pequeños.  Dependencia en práctica del modelo RAD
componentes de toma entre 1 a 3 meses.
terceros:
funcionalidad de
más o de menos,
problemas legales.
Davis  Organización  Provee una meta-  Excelente para  Si no se dan las El modelo de desarrollo
Sitaram  Comunicaciones descripción del proyectos en los condiciones concurrente se utiliza a
década  Especificación proceso del software. que se conforman señaladas no es menudo como el
de 1990  Desarrollo de El modelo grupos de trabajo aplicable. paradigma de desarrollo
producto concurrente tiene la independientes.  Si no existen grupos de aplicaciones
capacidad de  Proporciona una de trabajo no se cliente/servidor.
describir las múltiples imagen exacta del puede trabajar en Un sistema
actividades del estado actual de un este método cliente/servidor se
software ocurriendo proyecto compone de un conjunto
simultáneamente. de componentes
 La mayoría de los funcionales.
modelos de procesos Cuando se aplica a
de desarrollo del cliente/servidor, el
software son dirigidos modelo de proceso
por el tiempo; cuanto concurrente define
Concurrente más tarde sea, más actividades en dos
atrás se encontrará dimensiones: una división
en el proceso de de sistemas y una división
desarrollo. Un de componentes.
modelo de proceso
concurrente está
dirigido por las
necesidades del
usuario, las
decisiones de la
gestión y los
resultados de las
revisiones.
IBM  Inicio  Los autores de RUP d  Las ventajas de este  Como desventajas, En RUP se han agrupado
Corporati  Elaboración estacan que el proces modelo son la podemos señalar las actividades en grupos
on, de  Construcción o de software reducción de que requiere una lógicos definiéndose 9
propieda  Transición propuesto por RUP ti riesgos en el gran previsión sobre flujos de trabajo
d de ene tres característica proyecto, la lo que va a ocurrir principales, los 6
Rational s garantía de calidad, (para poder primeros son conocidos
Software esenciales: estádirigid y la integración controlarlo) y que como flujos de ingeniería
en 2003. o por los Casos de Us entre lo que es genera abundante y los tres últimos como
o, está centrado en la propiamente trabajo adicional (y flujos de apoyo.
arquitectura, y es desarrollo con costes asociados) de o Modelo del Negocio
iterativo e increment mantenimiento de documentación y o Requerimiento
al. software (a base de comunicación, con o Análisis y Diseño
 1. Proceso dirigido po ir iterando en cada lo que no suele o Implementación
r Casos de Uso fase, combinando resultar práctico o Prueba (Testeo
RUP  2. Proceso actividades de uno y para proyectos o Instalación o despliegue
centrado en la arquit otro tipo). pequeños. o Administración del
ectura proyecto
 3. o Administración de
Proceso iterativo e in configuración y cambios
cremental o Ambiente
 4. Estructura Dinámic
a del proceso. Fases e
iteraciones
Ikujiro  1. Planificación del  Gestión regular de las  Entregables en  Algunos miembros En la actualidad, los
Nonaka y sprint expectativas del tiempo y forma, de tu equipo proyectos se desarrollan
Takeuchi  2. Etapa de cliente, resultados puedes ir enviando pueden saltar pasos en contextos muy
1986 desarrollo anticipados, entregables al importantes en el versátiles. Son más
 3. Revisión del flexibilidad y cliente mientras vas camino rápido para complejos que antes,
sprint adaptación, retorno atacando los llegar al “sprint” frente a unas exigencias
 4.Retroalimentaci de inversión, objetivos más final. del cliente y del mercado
ón mitigación de riesgos, sencillos, eso te  El cliente siempre mucho más variables, y
productividad y hace ganar tiempo va a esperar los con una incertidumbre
calidad, alineamiento para atacar los informes con la elevada. Por eso, la
entre cliente y objetivos más fecha exacta, y aplicación del método
SCRUM equipo, por último, complejos. muchas veces los va Scrum se ha extendido
equipo motivado.  el ScrumMaster a pedir antes, como la pólvora en
 Se hace uso de tiene el cuando capaz no numerosos sectores,
equipos auto- conocimiento pudiste avanzar en fuera del mundo del
dirigidos y auto- necesario para nada. desarrollo de software
organizados. lograr el objetivo  Demasiadas
 Se realiza a diario una primario y Reuniones para
reunión de Scrum, secundario por lo poco avance, a
que es una reunión cual puede ir veces es muy
de avance diaria que controlando el cansador y
no dura más de 15 proyecto y estresante reunirse
minutos con el delegando roles. demasiadas veces
objetivo de obtener  Cada persona sabe por el mismo tema,
realimentación sobre que es lo que tiene algunos van
las tareas del equipo. que hacer y no es perdiendo el interés
necesario estar en el proyecto.
reorganizando una y
otra vez los Tracks
de cada persona.
Kent  Planeación  Metodología liviana  Da lugar a una  Es recomendable Diseñar, implementar y
Beck  Diseño de desarrollo de programación emplearla solo en programar lo más rápido
1999  Codificación software sumamente proyectos a corto posible, hasta en casos se
 Prueba  Conjunto de prácticas organizada. plazo. recomienda saltar la
y reglas empleadas  Ocasiona eficiencias  En caso de fallar, las documentación y los
para desarrollar en el proceso de comisiones son muy procedimientos
software planificación y altas. tradicionales. Se
 Basada en diferentes pruebas.  Requiere de un fundamenta en la
ideas acerca de cómo  Cuenta con una tasa rígido ajuste a los capacidad del equipo
enfrentar ambientes de errores muy principios de XP. para comunicarse entre sí
muy cambiantes pequeña.  Puede no siempre y las ganas de aprender
 Originada en el  Fomenta la ser más fácil que el de los errores propios
proyecto C3 para comunicación entre desarrollo inherentes en un
Chrysler los clientes y los tradicional. programador.
 En vez de planificar, desarrolladores. La gran ventaja de XP es
analizar y diseñar  Facilita los cambios. su increíble capacidad de
XP para el futuro  Permite ahorar respuesta ante
distante, hacer todo mucho tiempo y imprevistos, aunque por
esto un poco cada dinero. diseño es una
vez, a través de todo  Puede ser aplicada a metodología que no
el proceso de cualquier lenguaje construye para el largo
desarrollo de programación. plazo y para la cual es
 El cliente tiene el difícil documentar.
control sobre las XP es un método
prioridades. estupendo para equipos
 Se hacen pruebas extremadamente
continuas durante pequeños que se centran
el proyecto. en un solo cliente.
 La XP es mejor
utilizada en la
implementación de
nuevas tecnologías.
Jim  Especulación  Iterativo  Sirve para aprender  Los errores o ASD resalta que las
Highsmit  Colaboración  Orientado a los de los errores y cambios que no son aproximaciones
h 1998  Aprendizaje componentes de SW volver a iniciar el detectados en secuenciales en cascada
 Tolerante a los ciclo de desarrollo reuniones solo funcionan en
cambios  Utiliza información anteriores a tiempo, entornos bien conocidos.
 Guiado por los disponible acerca de afecta la calidad del Pero como los cambios
riesgos cambios para producto y a su ocurren frecuentemente
 La revisión de los mejorar el costo total en el desarrollo software,
componentes sirve comportamiento  Dado a que es una es importante usar un
para aprender de los del SW metodología ágil método tolerante a
errores y volver a  Promulga implica no realizar cambios. El primer ciclo
iniciar el ciclo de colaboración, la procesos que son de un proyecto ASD suele
DAS desarrollo interacción de requeridos en las ser corto, asegurando
personas metodologías que el cliente está
tradicionales involucrado y
confirmando la viabilidad
del proyecto.
Cada ciclo termina con
una revisión en grupo
enfocada al cliente.
Durante las reuniones de
revisión, se estudia la
aplicación funcionando. El
resultado de las
reuniones son peticiones
de cambio
documentadas.