1. Carlos Andres Islas Maldonado
METODOLOGI definición características diagrama Tipos de Ventajas desventajas
AS CLASICAS sistemas
Cascada +Es el más utilizado Aplicable para La planificación es Iteraciones costosas
Sugiere un enfoque +Es una visión del proceso proyectos sencilla Los problemas que se
sistemático, de desarrollo de software pequeños y no La calidad del producto presentan son
secuencial hacia el como una sucesión de tan complejos. resultante es alta corregidos
desarrollo del etapas que producen Permite trabajar con posteriormente
software, que se productos intermedios personal poco Puede que el software
inicia con la +Para que el proyecto cualificado no cumpla con los
especificación de tenga éxito deben Los usuarios lo pueden requisitos
requerimientos del desarrollarse todas las comprender Es difícil incorporar
cliente y que fases fácilmente. nuevas cosas si se
continua con la +Las fases continúan hasta Sus fases son conocidas quiere actualizar
planeación, el que los objetivos se han por los desarrolladores. Es normal detenerse en
modelado, la cumplido. No necesita una su desarrollo y seguir
construcción y el definición completa con otras fases
despliegue para para empezar a Se tarda mucho tiempo
culminar en el funcionar. en pasar todo el ciclo
soporte del Las revisiones de
software proyectos de gran
terminado. complejidad son muy
difíciles
Incremental Es un proceso de Permite construir el Este modelo La solución se va Requiere de mucha
desarrollo de proyecto en etapas es aplicable mejorando en forma planeación, tanto
software, creado en incrementales en donde cuando es progresiva a través de administrativa como
respuesta a las cada etapa agrega difícil las múltiples técnica.
debilidades del funcionalidad. establecer los iteraciones. Requiere de metas
modelo tradicional Cada etapa consiste de requisitos Incrementa el claras para conocer el
de cascada. requerimientos, diseño, iniciales de un entendimiento del estado del proyecto.
Provee una codificación, pruebas, y proyecto y es problema y de la
estrategia para entrega. mas solución por medio de
controlar la Permite entregar al cliente apropiado los refinamientos
complejidad y los un producto más rápido para sucesivos.
riesgos, en comparación del proyectos
desarrollando una modelo de cascada. pequeños. Las
parte del producto Provee visibilidad sobre el nuevas
software progreso a través de sus versiones
reservando el resto nuevas versiones. pueden ser
de aspectos para el Provee retroalimentación planeadas de
futuro. a través de la modo que los
funcionalidad mostrada. requisitos
2. Carlos Andres Islas Maldonado
Permite atacar los técnicos
mayores riesgos desde el puedan ser
inicio. administrados.
Evolutivo • Gestionan bien la Este modelo •Nos permite hacer •El proceso no es
naturaleza evolutiva del es apropiado validaciones deforma visible
El desarrollo software en proyectos creciente •Sistema con
evolutivo se basa • Son iterativos: donde se •Retroalimentación estructura deficiente
en la idea de construyen versiones de desea realizar rápida a lo largo del •Se requieren
desarrollar una software mejoras para proceso herramientas y
implementación cada vez más completas ampliar el •El sistema evoluciona técnicas especiales
inicial e ir alcance del agregando nuevos
refinándola a través Se adaptan bien: mismo. atributos de acuerdo a
de diferentes • Los cambios de las propuestas del
versiones hasta requisitos del producto cliente
desarrollar un • Fechas de entrega
sistema software estrictas poco realistas
que satisfaga todos • Especificaciones
los requerimientos parciales del producto
del cliente.
Espiral En cada giro se construye Se aplican a +El análisis de riesgo se +La consideración
un nuevo modelo del cualquier lo hace de forma explicita del riesgo.
El desarrollo en sistema completo. proyecto, explícita y clara. Integra +Hacer uso de los
espiral es un Este modelo puede grande, el desarrollo con el mejores elementos de
modelo de ciclo de combinarse con otros mediano o mantenimiento de los restantes modelos.
vida del software modelos de proceso de pequeño, software etc. +Genera mucho
Las actividades de desarrollo (cascada, complejo o +Prevenir los errores tiempo en el desarrollo
este modelo se evolutivo). no. que se nos pueden del sistema
conforman en una Mejor modelo para el Proyectos presentar en un futuro, +Modelo costoso
espiral, en la que desarrollo de grandes pequeños lo cual es muy positivo Requiere experiencia
cada bucle o sistemas. requieren baja para poder mejorar la en la identificación de
iteración No hay un numero cantidad de calidad del software. riesgos
representa un definido de iteraciones, las tareas y +Utiliza los prototipos Genera mucho trabajo
conjunto de iteraciones debe decidirlas también de para disminuir los adicional. Cuando un
actividades. Las el equipo de gestión del formalidad. En riegos desde el punto sistema falla se pierde
actividades no proyecto. proyectos de vista técnico. tiempo y coste dentro
están fijadas a Este es el enfoque mas mayores o +Si nos tardamos de la empresa. Exige
ninguna prioridad, realista actualmente. críticos cada mucho tiempo en pasar una cierta habilidad en
sino que las El análisis de riesgo región de a otro nivel superior el los analistas (es
siguientes se eligen requiere la participación tareas proyecto se lo puede bastante difícil).
en función del de personal con alta contiene abandonar para no
3. Carlos Andres Islas Maldonado
análisis de riesgo, calificación. labores de gastar ni tiempo ni
comenzando por el más alto nivel dinero en vano.
bucle interior. de formalidad. +El desarrollador y el
cliente comprenden y
reacción mejor ante
riesgos.
Prototipos Un prototipo es Trata de mantener un Sirven para - Reducción de la se hacen fuertes
una representación continuo contacto con el modelar incertidumbre y del inversiones en un
de un sistema, usuario en la etapa de entradas y riesgo producto desechable
aunque no es un análisis salidas de un - Reducción de tiempo ya que los prototipos
sistema completo, Se preocupa mas del flujo sistema, y de costos se descartan. Esto
posee las de información y la modela - Incrementos en la puede hacer que
características del interface con el usuario también, aceptación del nuevo aumente el coste de
sistema final o No suelen considerarse consumo de sistema desarrollo del
parte de ellas. aspectos de calidad recursos, - Mejoras en la producto.
No se consideran ocupación, administración de Con este modelo
alternativas de diseño y rendimientos, proyectos pueden surgir
explotación reglas de - Mejoras en la problemas con el
Se presentan en cualquier negocio y comunicación entre cliente que ve
etapa del ciclo de datos. desarrolladores y funcionando versiones
desarrollo clientes del prototipo pero
puede desilusionarse
porque el producto
final aún no ha sido
construido.
Desarrollo Se define como el +El modelo de desarrollo Esta +El análisis del riesgo +Genera mucho
basado en paradigma de basado en componentes metodología se hace de forma tiempo en el desarrollo
componentes ensamblar incorpora muchas de las es mas explícita y clara. del sistema
componentes y
características del modelo utilizada en +Une los mejores +Modelo costoso
escribir código para
en espiral. proyectos de elementos de los +Requiere experiencia
hacer que estos
componentes +Es evolutivo por empresas de restantes modelos. en la identificación de
funcionen, de una naturaleza. alto nivel, las +Reduce riesgos del riesgos
manera coherente y +Exige un enfoque cuales proyecto. +Genera mucho
fluida. Sin embargo, iterativo para la creación cuentan con +Incorpora objetivos trabajo adicional.
el modelo de del software. los recursos de calidad. +Cuando un sistema
desarrollo basado en +Conduce a la reutilización suficientes +Integra el desarrollo falla se pierde tiempo y
componentes del software. para poder con el mantenimiento. coste dentro de la
configura aplicaciones
desarrollarla. +Ahorramos el 70% del empresa. Exige una
desde componentes
Cualquier tipo ciclo de vida de cierta habilidad en los
preparados de
software de proyecto desarrollo. analistas (es bastante
4. Carlos Andres Islas Maldonado
difícil).
OTRAS definición características diagrama Tipos de sistemas Ventajas desventajas
METODOLOGI
AS
Winwin +Trata de mejorar los Esta metodología, Permite a quien lo Al elaborarlo por
Es una adaptación ciclos de vida clásicos dado a que esta desarrolla aplicar el partes no tenemos
del modelo de y prototipos. basada en la de enfoque de construcción una visión global del
espiral que se hace +Este modelo puede espiral adquiere la de prototipos en problema.
hincapié combinarse con otros característica de cualquier etapa de Aquí nos dice que los
explícitamente modelos de proceso poder ser utilizado en evolución del producto. prototipos se van
situados en la de desarrollo. cualquier tipo de Mantiene el enfoque del validando, lo cual es
participación del +En cada giro se proyecto. ciclo de vida clásico pero muy negativo porque
cliente en un construye un nuevo lo incorpora al marco de como ya se ha dicho
proceso de modelo del sistema Sin embargo esta trabajo interactivo que ningún software
negociación en la completo. metodología es mas refleja un mundo más debe empezar como
génesis del +El análisis de riesgo utilizada en realista de la naturaleza un prototipo.
desarrollo de requiere la proyectos de del proyecto. Como es un modelo
productos. participación de empresas de alto Hace una consideración relativamente nuevo
Idealmente, el personal con alta nivel, empresas directa de los riesgos no es muy utilizado
desarrollador cualificación. directivas, empresas técnicos en todas las como los paradigmas
simplemente Incorpora objetivos con un mayor etapas del proyecto de lineales secuenciales
preguntar al cliente de calidad y gestión estimulo de ingresos tal manera que si se o de construcción de
lo que se requiere y de riesgos. anuales aplica adecuadamente prototipos.
el cliente +Permite iteraciones, reduce los riesgos antes Debido a su elevada
proporcionaría el vuelta atrás y de convertirse en complejidad no se
suficiente detalle finalizaciones problemáticos. aconseja utilizarlo en
para proceder. rápidas. sistemas pequeños
(sobre-costo de
gestión).
Proceso Forma disciplinada Es un marco de -Adaptabilidad del El método de PU
unificado Es un proceso de de asignar tareas y trabajo genérico que desarrollo a nuevos requiere costos de
desarrollo de responsabilidades puede especializarse requisitos o nuevos dedicación altos por
software que (quién hace qué, para una gran cambios lo que no es
describe “el cuándo y cómo) variedad de sistemas -Se reducen los riesgos conveniente usarlo
conjunto de Pretende software, para de no obtener el en procesos de
actividades implementar las diferentes áreas de producto deseado un proyecto
necesarias para mejores prácticas en aplicación, diferentes -En cada momento hay pequeño.
transformar los Ingeniería de tipos de una versión del sistema -Si el proceso no se
requisitos del Software organizaciones, funcionando que se aplica bien desde el
5. Carlos Andres Islas Maldonado
usuario en un Desarrollo iterativo diferentes niveles de modifica según las inicio el PU se puede
sistema de Administración de aptitud y necesidades y deseos del volver muy grande y
software”. Esta requisitos diferentes tamaños cliente. difícil, tanto para
dirigido por casos Uso de arquitectura de proyecto -Progreso visible en las aprender como para
de uso, centrado en basada en primeras etapas administrar
la arquitectura del componentes -Reducir la redundancia -Una cantidad
sistema, y es Control de cambios e incrementa la sustancial de tiempo
iterativo e Modelado visual del productividad se gasta en tratar de
incremental. software -El proceso es adecuar el PU a cada
Verificación de la comprensible proyecto.
calidad del software -La metodología de PU es -Es un proceso
más adaptable para pesado
proyectos de largo plazo -Se basa mucho en la
documentación
Ingeniería Las aplicaciones Para una misma La ingeniería de la
web Web es un tipo aplicación Web se Web es
particular de pueden utilizar varios multidisciplinar y
software, por ello modelados. aglutina
se puede modelar Dependiendo del tipo contribuciones de
con diagramas de aplicación, será diferentes
UML. más adecuado uno u áreas: arquitectura
●Muchas otro. de la información,
aplicaciones WSDM está ingeniería
telemáticas son un orientado para de hipermedia/hipert
caso particular de aplicaciones que exto, ingeniería de
aplicaciones Web. requiren diferentes requisitos, diseño
WebML: Web audiencias. de interfaz de
ModelingLanguage WebML está usuario,
Modelado orientado para usabilidad diseño
orientado a aplicaciones que grafico y de
aplicaciones con un tienen una alta presentación, diseño
uso intensivo de interacción con y análisis de
datos, donde hay datos. sistemas, ingeniería
gran cantidad de WA-UML está de software,
datos, con orientado para ingeniería de datos,
estructura aplicaciones indexado y
compleja y las adaptativas. recuperación de
aplicaciones tienen OO-H está orientado información, testeo,
que acceder a ellos para aplicaciones con modelado y
Modelado de énfasis en el interfaz. simulación,
aplicación Web en OOHDM y UWE están despliegue de
6. Carlos Andres Islas Maldonado
4 fases: orientados para aplicaciones,
Modelo de datos aplicaciones más operación de
Modelo de Genéricas. sistemas y gestión de
hipertexto proyectos.
Modelo de gestión
de contenido
Modelo de
presentación
Metodologías La mayoría minimiza Las metodologías
agiles Consiste en riesgos desarrollando ágiles de desarrollo Programación Es recomendable
desarrollar una software en cortos están especialmente organizada. emplearlo solo en
pequeña parte del lapsos de tiempo. indicadas en proyectos a corto
software que se Capacidad de proyectos con Menor taza de errores. plazo.
desea construir. De respuesta a cambios requisitos poco
esta forma, el de requisitos a lo definidos o Satisfacción del program Altas comisiones en
cliente nos indica si largo del desarrollo. cambiantes. ador. caso de fallar.
vamos por el buen Entrega continua y
camino, en plazos breves de
estableciendo software funcional.
aquellas partes que Trabajo conjunto
le son más entre el cliente y el
relevantes y así equipo de desarrollo.
juntos, nos Importancia de la
aseguramos de que simplicidad,
construimos una eliminado el trabajo
aplicación que innecesario.
añadirá valor a su Atención continua a
negocio. la excelencia técnica
y al buen diseño.
Mejora continua de
los procesos y el
equipo de desarrollo
METODOLOGI Una metodología El uso del modelo Las metodologías Problemas derivados
A EMERGENTE es emergente orientado a objetos Se utiliza emergentes motivan más de la comunicación
si permite adaptar ayuda a explotar el mayoritariamente en a los equipos de trabajo. oral. Este tipo de
la forma de trabajo poder expresivo de desarrollo de El principal beneficio del comunicación resulta
a las condiciones todos los lenguajes productos con diseño orientado a difícil de preservar
del proyecto. de programación innovaciones objetos es que cuando pasa el
basados en objetos y importantes, y para proporciona un tiempo y está sujeta
los orientados a sistemas de mecanismo para a muchas
7. Carlos Andres Islas Maldonado
objetos, como información formalizar modelos de la ambigüedades.
Smalltalk, Object empresarial. realidad. Falta de calidad.
Pascal, C++, CLOS, Evita malentendidos de Probar el código de
Ada y Java. requerimientos entre el forma constante no
Incertidumbre: la cliente y el equipo genera productos de
dirección indica la El uso del modelo calidad, sólo revela
necesidad estratégica orientado a objetos falta de análisis y
que se desea cubrir, alienta la reutilización no diseño.
ofreciendo máxima solo del software, sino
libertad al equipo de de diseños completos.
trabajo. Proporcionan mejores
Difusión y resultados en los
transferencia del proyectos de alto riesgo.
conocimiento: alta
rotación de los
miembros de los
equipos entre
diferentes proyectos.
Por otra parte,
potenciar el acceso
libre a la información
y documentación
REINGENIERIA Una reingeniería Unificación de tareas Simplifica el Exige una cierta
buscará el porqué Participación de los mantenimiento del habilidad en los
el como de lo que usuarios sistema analistas
ya existe. Cambio del orden Simplifica el costo Se puede
Los cambios en el secuencial Menor tiempo perder el primer
diseño deberán ser Reutilización de Mayor calidad proyecto
radicales (desde la componentes Reutilización del Necesita de varios
raíz y no Realización de software proyectos realizados
superficiales). diferentes versiones Simplifica las pruebas con éxito
Las mejoras Reducción de las Necesita que todo el
esperadas deben comprobaciones código sea orientado
ser dramáticas (no a objetos
de unos pocos
porcentajes).
Los cambios se
deben enfocarse
para no modificar
el fin del software.