SISTEMAS DE INFORMACIÓ N I CIS - UABJB

UNIVERSIDAD AUTONOMA DEL BENI

FACULTAD DE INGENIERIA Y TECNOLOGIA
CARRERA DE INGIENERIA DE SISTEMAS

TRABAJO PRACTICO 3
TRABAJO PRACTICO DE INVESTIGACIÓN

MATERIA: SISTEMAS DE INFORMACION I

5º SEMESTRE
DOC.: Ing. Egdar Montero Kenapp
UNI: James Quiñones Hurtado

GESTION 2021

Univ.: James Quiñ ones Hurtado Pá gina 1

SISTEMAS DE INFORMACIÓ N I CIS - UABJB

TRABAJO PRACTICO 3
TRABAJO PRACTICO DE INVESTIGACIÓN

1.- Investigar todo lo referente al ciclo de vida modelo en cascada con sub-proyecto,
modelo de entrega por etapas, donde se reflejen las ventajas, desventajas, y la
descripción de cada una de las actividades o fases.

Modelo Cascada es un procedimiento lineal que se caracteriza por dividir los procesos de

desarrollo en sucesivas fases de proyecto. Al contrario que en los modelos iterativos, cada una
de estas fases se ejecuta tan solo una vez. Los resultados de cada una de las fases sirven como
hipó tesis de partida para la siguiente. El waterfall model se utiliza, especialmente, en el
desarrollo de software.

¿Cómo funciona el modelo en cascada?

El desarrollo del modelo se atribuye al teó rico de la informá tica Winston W. Royce. Sin
embargo, Royce no es el inventor de este modelo. Muy al contrario, en su ensayo de 1970
titulado Managing the Development of Large Software Systems, el teó rico presenta
una reflexión crítica acerca de los procedimientos lineales. A modo de alternativa, Royce
presenta un modelo iterativo incremental en el que cada una de las fases se basa en la anterior
y verifica los resultados de esta.

Royce propone un modelo compuesto por siete fases que se ha de ejecutar en diversas vueltas
(iteraciones):

1. Requisitos de sistema
2. Requisitos de software
3. Análisis
4. Diseño
5. Implementación
6. Prueba
7. Servicio

El procedimiento popularmente conocido como waterfall model se basa en las fases definidas
por Royce, pero solo prevé una iteración.

En la práctica, se aplican diversas versiones del modelo. Los má s habituales son los modelos
que dividen los procesos de desarrollo en cinco fases. En ocasiones, las fases 1, 2 y 3 definidas
por Royce se integran en una sola fase de proyecto a modo de aná lisis de los requisitos.

1. Análisis: planificació n, aná lisis y especificació n de los requisitos.

2. Diseño: diseñ o y especificació n del sistema.
3. Implementación: programació n y pruebas unitarias.
4. Verificación: integració n de sistemas, pruebas de sistema y de integració n.

Univ.: James Quiñ ones Hurtado Pá gina 2

SISTEMAS DE INFORMACIÓ N I CIS - UABJB

5. Mantenimiento: entrega, mantenimiento y mejora.

Las fases del desarrollo en cascada

En este modelo, las diferentes fases de un proceso de desarrollo se suceden una detrá s de otra
como en una cascada. Cada una de las fases concluye con un resultado provisional
(hito) como, por ejemplo, un catá logo de requisitos en forma de pliego de condiciones, la
especificació n de una arquitectura de software o una aplicació n a nivel alfa o beta.

Análisis
Todo proyecto de software comienza con una fase de aná lisis que incluye un estudio de
viabilidad y una definició n de los requisitos. En el estudio de viabilidad se evalú an los costes,
la rentabilidad y la factibilidad del proyecto de software. El estudio de viabilidad da como
resultado un pliego de condiciones (una descripció n general de los requisitos), un plan y una
estimació n financiera del proyecto, así como una propuesta para el cliente, si fuera necesario.

Mientras que los análisis de salida se encargan de describir la problemá tica en sí, el concepto
ha de definir qué funciones y características debe ofrecer el producto de software para
cumplir con las correspondientes exigencias. La definició n de los requisitos da como resultado
un pliego de condiciones, una descripció n detallada de có mo se han de cumplir los requisitos
del proyecto, así como un plan para la prueba de aceptació n, entre otros.

Por ú ltimo, la primera fase del waterfall model incluye un análisis de la definición de los
requisitos en el que los problemas complejos se dividen en pequeñ as tareas secundarias y se
elaboran las correspondientes estrategias de resolució n.

Diseño
La fase de diseñ o sirve para formular una solució n específica en base a las exigencias, tareas y
estrategias definidas en la fase anterior. En esta fase, los desarrolladores de software se
encargan de diseñ ar la arquitectura de software, así como un plan de diseño detallado del
mismo, centrá ndose en componentes concretos, como interfaces, entornos de trabajo o
bibliotecas. La fase de diseñ o da como resultado un borrador preliminar con el plan de diseñ o
del software, así como planes de prueba para los diferentes componentes.

Implementación
La arquitectura de software concebida en la fase de diseñ o se ejecuta en la fase de
implementación, en la que se incluye la programación del software, la búsqueda de
errores y las pruebas unitarias.

En la fase de implementació n, el proyecto de software se traduce al correspondiente lenguaje

de programació n. Los diversos componentes se desarrollan por separado, se comprueban a
través de las pruebas unitarias y se integran poco a poco en el producto final. La fase de
implementació n da como resultado un producto de software que se comprueba por primera
vez como producto final en la siguiente fase (prueba alfa).

Prueba
La fase de prueba incluye la integració n del software en el entorno seleccionado. Por norma
general, los productos de software se envían en primer lugar a los usuarios finales

Univ.: James Quiñ ones Hurtado Pá gina 3

 SISTEMAS DE INFORMACIÓ N I CIS - UABJB

seleccionados en versión beta (pruebas beta). Las pruebas de aceptación desarrolladas en

la fase de aná lisis permiten determinar si el software cumple con las exigencias definidas con
anterioridad. Aquellos productos de software que superan con éxito las pruebas beta está n
listos para su lanzamiento.

Servicio
Una vez que la fase de prueba ha concluido con éxito, se autoriza la aplicación productiva del
software. La ú ltima fase del modelo en cascada incluye la entrega, el mantenimiento y
la mejora del software.

Resumen de las ventajas y desventajas del modelo en cascada

Ventajas Desventajas

✔ Una estructura sencilla gracias a unas fases de ✘ Por norma general, los proyectos má s complejos o de
proyecto claramente diferenciadas. varios niveles no permiten su divisió n en fases de
proyecto claramente diferenciadas.

✔ Buena documentació n del proceso de desarrollo a ✘ Poco margen para realizar ajustes a lo largo del
través de unos hitos bien definidos. proyecto debido a un cambio en las exigencias.

✔ Los costes y la carga de trabajo se pueden estimar al ✘El usuario final no se integra en el proceso de
comenzar el proyecto. producció n hasta que no termina la programació n.

✔ Aquellos proyectos que se estructuran en base al ✘En ocasiones, los fallos solo se detectan una vez
modelo en cascada se pueden representar finalizado el proceso de desarrollo.
cronoló gicamente de forma sencilla.

La metodología en cascada se suele emplear, especialmente, en aquellos proyectos cuyos

requisitos y procesos se pueden describir de forma precisa durante la fase de planificació n, en
los que cabe suponer que las hipó tesis no van a sufrir una gran variació n durante el
transcurso del proyecto. Los procedimientos estrictamente lineales se adaptan, así,
especialmente bien a proyectos de software pequeños, sencillos y claramente
estructurados. 

Univ.: James Quiñ ones Hurtado Pá gina 4

 SISTEMAS DE INFORMACIÓ N I CIS - UABJB

2.- Investigar todo lo referente a las metodologías de desarrollo de software: XP,

OOHDM, RAP, DSDM, descripción de cada una de las actividades o fases.

La metodología XP o Programació n Extrema es una metodología á gil y flexible utilizada para

la gestió n de proyectos.
Extreme Programming se centra en potenciar las relaciones interpersonales del equipo de
desarrollo como clave del éxito mediante el trabajo en equipo, el aprendizaje continuo y el
buen clima de trabajo.
Esta metodología pone el énfasis en la retroalimentació n continua entre cliente y el equipo de
desarrollo y es idó nea para proyectos con requisitos imprecisos y muy cambiantes.

Características
 Se considera al equipo de proyecto como el principal factor de éxito del proyecto
 Software que funciona por encima de una buena documentación.
 Interacció n constante entre el cliente y el equipo de desarrollo.
 Planificació n flexible y abierta.
 Rápida respuesta a cambios.
Roles
 Cliente: responsable de definir y conducir el proyecto así como sus objetivos.
 Programadores: estiman tiempos de desarrollo de cada actividad y programan el
proyecto.
 Tester: Encargado de Pruebas.
 Tracker: Encargado de Seguimiento.
 Coach: Entrenador. Su papel es guiar y orientar al equipo.
 Big Boss: Gestor del proyecto, gerente del proyecto, debe tener una idea general del
proyecto y estar familiarizado con su estado.

MODELO OOHDM o Método de Diseño de Hipermedia Orientado a Objetos

El modelo OOHDM u Object Oriented Hypermedia Design Methodology, para diseñ o de

aplicaciones hipermedia y para la Web, fue diseñ ado por D. Schwabe, G. Rossi, and S. D. J.
Barbosa y es una extensió n de HDM con orientació n a objetos, que se está convirtiendo en una
de las metodologías má s utilizadas. Ha sido usada para diseñ ar diferentes tipos de
aplicaciones hipermedia como galerías interactivas, presentaciones multimedia y, sobre todo,
numerosos sitios web.

Al igual que RMM, este método se inspira en el modelo HDM, pero lo que le distingue

claramente del primero es el proceso de concepció n orientado a objetos. OOHDM propone el
desarrollo de aplicaciones hipermedia mediante un proceso de 4 etapas:

  diseñ o conceptual

Univ.: James Quiñ ones Hurtado Pá gina 5

SISTEMAS DE INFORMACIÓ N I CIS - UABJB

  diseñ o navegacional

  diseñ o de interfaces abstractas

  implementació n

Cada etapa de la concepció n define un esquema objeto específico en el que se introducen

nuevos elementos (clases).

En la primera etapa se construye un esquema conceptual representado por los objetos de

dominio o clases y las relaciones entre dichos objetos. Se puede usar un modelo de datos
semá ntico estructural (como el modelo de entidades y relaciones). El modelo OOHDM
propone como esquema conceptual basado en clases, relaciones y subsistemas.

En la segunda etapa, el diseñ ador define clases navegacionales tales como nodos, enlaces y

estructuras de acceso (índices y visitas guiadas) inducidas del esquema conceptual.
Los enlaces derivan de las relaciones y los nodos representan ventanas ló gicas (views) sobre
las clases conceptuales. A continuació n, el diseñ ador describe la estructura navegacional en
términos de contextos navegacionales. Un contexto navegacional es un conjunto
de nodos, enlaces, clases de contextos y otros contextos navegacionales (contextos anidados)
-igual que en HDM definen agrupaciones- que pueden ser definidos por comprensió n o
extensió n, o por enumeració n de sus miembros. Los nodos se enriquecen con un conjunto de
clases especiales que permiten presentar atributos así como métodos o comportamientos
cuando se navega en un contexto particular. Durante esta etapa, es posible adaptar los objetos
navegacionales para cada contexto, de forma similar a las perspectivas de HDM.

OOHDM no propone un modelo enriquecido para el dominio de la aplicació n, por lo que deja
libre al diseñ ador para elegir el modelo de especificació n del dominio. Sin embargo, el
modelo hipermedia está definido en dos niveles de abstracció n: las clases navegacionales y los
contextos navegacionales.

En el momento de la especificació n de las clases navegacionales es cuando el diseñ ador define

las correspondencias y, aunque OOHDM sugiere algunas, no impone metá foras
preestablecidas tan sistemá ticamente como RMM. Los nodos inducidos de las clases del
modelo del dominio y los enlaces inducidos de las relaciones del modelo del dominio se
pueden precisar. Como el segundo nivel está consagrado a la especificació n de la navegació n,
expresada exclusivamente sobre los objetos navegacionales (no sobre los elementos del
modelo del dominio), constituye un mecanismo que permite enriquecer el
modelo hipermedia.

La tercera etapa está dedicada a la especificació n de la interfaz abstracta. Así, se define la

forma en la cual deben aparecer los contextos navegacionales. También se incluye aquí el
modo en que dichos objetos de interfaz activará n la navegació n y el resto de funcionalidades
de la aplicació n, esto es, se describirá n los objetos de interfaz y se los asociará con objetos de
navegació n. La separació n entre el diseñ o navegacional y el diseñ o de interfaz abstracta
permitirá construir diferentes interfaces para el mismo modelo navegacional.

Por fin, la cuarta etapa, dedicada a la puesta en prá ctica, es donde se hacen corresponder los
objetos de interfaz con los objetos de implementació n.

Univ.: James Quiñ ones Hurtado Pá gina 6

SISTEMAS DE INFORMACIÓ N I CIS - UABJB

Definición de qué es una metodología RAD

Profundizando en qué es una metodología RAD, tenemos que tener claros cuales son sus
premisas bá sicas. La primera persona que habló del método RAD fue James Martin a finales de
los 80 y, actualmente, estamos ante uno de los métodos de desarrollo má s populares, dentro
de las técnicas de desarrollo á gil. James Martin consideró que para aplicar de forma correcta
la metodología RAD tenemos que tener en cuenta 4 componentes: Personas, herramientas,
metodología y gestió n.

La idea principal es entregar sistemas de alta calidad, en poco tiempo y con un coste bajo de
inversió n. Para conseguir esto, hay que seguir determinadas pautas que hará n que estemos
ante una auténtica metodología DRA (las siglas en castellano: Desarrollo Rá pido de
Aplicaciones), que veremos má s adelante.

Para qué sirve la metodología RAD

En la actualidad, las empresas invierten gran parte de sus recursos en desarrollar aplicaciones
que les permitan trabajar de forma má s eficiente. Con la aparició n de los modelos de
desarrollo rá pido de aplicaciones, podremos crear softwares de forma rá pida y barata para
satisfacer las necesidades empresariales sin invertir tanto tiempo y dinero.

Ventajas y desventajas del modelo de desarrollo rápido de aplicaciones RAD

A la hora de adoptar la metodología DRA, deberemos tener en cuenta un buen puñ ado de
ventajas y desventajas de su uso y saber por qué usar RAD. Algunos de los beneficios
principales del uso de la metodología RAD serían los siguientes:

 Avances medibles: Al contar con numerosas iteraciones, componentes y prototipos

desplegados cada cierto tiempo, se podrá medir y evaluar de forma sencilla el
desarrollo del proyecto y, así, cumplir con los presupuestos.
 Productivos má s pronto: La metodología DRA permitirá a los desarrolladores adoptar
roles multidisciplinares que creen prototipos y có digos de trabajo de forma rá pida, lo
que supone ser productivos má s rá pido.
 Separació n de los componentes del sistema: La metodología RAD exige a los
diseñ adores y desarrolladores a generar componentes funcionales e independientes
por sí mismos, y así poder usarlos en en una versió n o prototipo iterativo. De esta
manera, cada elemento se reparte en compartimentos y se podrá modificar segú n
evolucionen las necesidades del software y/o usuario.
 Comentarios constantes de los usuarios: Al poder lanzar prototipos e iteraciones
á gilmente, obtendremos un feedback muy valioso por parte de los usuarios de forma
continuada.
 Integració n temprana de sistemas: Los softwares desarrollados con la metodología
RAD podrá n ser integrados casi desde el comienzo con otros sistemas. A diferencia de
los softwares desarrollados en cascada que deben esperar prá cticamente al final del
desarrollo a ser integrados. Al poder realizar estas integraciones tempranas,
podremos identificar los posibles errores que existan en las mismas y buscar la
solució n.

Univ.: James Quiñ ones Hurtado Pá gina 7

SISTEMAS DE INFORMACIÓ N I CIS - UABJB

 Adaptabilidad: Gracias al desarrollo rá pido de aplicaciones, el software es bastante

maleable, lo que nos beneficiará para poder realizar cualquier posible adaptació n a los
prototipos o iteraciones.

Desventajas de RAD

Por supuesto, no todo podía ser perfecto y, como cualquier otro método de desarrollo de
software, el método RAD tiene algunas desventajas que también hay que tener en cuenta a la
hora de elegirlo para trabajar.

 Requiere sistemas modulares: Cuando aplicamos el método RAD, cada componente

del sistema debe ser iterable y constatable por sí mismo, para poder ser modificados o
intercambiados por cualquier miembro del equipo.
 Dificultad dentro de proyectos a gran escala: Cuando estemos ante un proyecto que
implique muchas personas y aplicaciones, la flexibilidad puede llegar a ser un
problema puesto que perderemos ligeramente el control sobre el diseñ o y el
desarrollo.
 Exige mucha interactividad del usuario: Conseguir feedback del usuario desde una
etapa temprana es muy ú til pero, a la vez, puede ser una espada de doble filo ya que
tendremos que aceptar todo tipo de críticas constructivas y ser competente a la hora
de comunicarse con los usuarios.
 Necesidad de desarrolladores senior: Aplicar la metodología RAD no es tan fá cil como
parece, por lo que en el equipo será n necesarios desarrolladores há biles que sean
capaces de aplicar y adaptarse a cualquier necesidad o cambio.

Fases dentro de un proceso con metodología RAD

Para implantar el modelo de desarrollo rá pido de aplicaciones, hay que seguir una
metodología concreta que incluye las siguientes fases, las cuales son cíclicas:

➡Planificación de necesidades:

En esta primera fase, lo que habrá que hacer será sentar las bases de las necesidades del
proyecto, tanto de necesidades de la aplicació n como de alcance del proyecto y de esta
manera comenzar a trabajar en la creació n de prototipos.

➡Diseño y feedback con el usuario:

Los usuarios aportará n comentarios que será n determinantes a la hora de diseñ ar la

arquitectura del sistema. Con el feedback del usuario crearemos modelos y prototipos
iniciales. Y este paso se podrá repetir tantas veces como se considere necesario segú n avance
el proyecto.

Univ.: James Quiñ ones Hurtado Pá gina 8

 SISTEMAS DE INFORMACIÓ N I CIS - UABJB

➡Construcción:

Ahora que tenemos el diseñ o bá sico, tendremos que realizar el grueso del proyecto:
Codificació n, pruebas e integració n reales de la aplicació n. Al igual que en la fase anterior, esta
se podrá repetir tantas veces como necesitemos, segú n haya nuevos componentes o
modificaciones en el proyecto.

➡Transición:

La ú ltima fase, también conocida como “cutover”, permitirá al equipo de desarrollo pasar los
componentes a un entorno de producció n en vivo, para realizar todas las pruebas que sean
necesarias.

En la actualidad, existen herramientas que aplican el desarrollo RAD o desarrollo low code, en
su forma de trabajar. Una de ellas es Mendix, si quieres saber qué es Mendix no dejes de
visitar el post del link.

Con todo esto, creemos que será mas fácil comprender por qué usar RAD es una buena
elecció n para tu forma de trabajar.

DSDM es un método á gil que se enfoca en el ciclo de vida completo del proyecto. DSDM
(formalmente conocido como Método de desarrollo diná mico del sistema) se creó en 1994,
después de que los gerentes de proyectos que usaban RAD (Desarrollo rá pido de aplicaciones)
buscaran má s gobernanza y disciplina para esta nueva forma iterativa de trabajo.

El éxito de DSDM se debe a la filosofía de que cualquier proyecto debe estar alineado con
objetivos estratégicos claramente definidos y centrarse en la entrega temprana de beneficios
reales para el negocio. 

Existen ocho principios de la metodología de DSDM y estos son:

 Centrarse en la necesidad comercial
 Entregar a tiempo
 Colaborar
 Nunca comprometer la calidad
 Construir incrementalmente a partir de cimientos firmes
 Desarrollar iterativamente
 Comunicarse de forma continua y clara
 Demostrar control

3.- Describir las metodologías agiles.

Univ.: James Quiñ ones Hurtado Pá gina 9

SISTEMAS DE INFORMACIÓ N I CIS - UABJB

Las metodologías ágiles son aquellas que permiten adaptar la forma de trabajo a las

condiciones del proyecto, consiguiendo flexibilidad e inmediatez en la respuesta para amoldar
el proyecto y su desarrollo a las circunstancias específicas del entorno.

En esencia, las empresas que apuestan por esta metodología consiguen gestionar sus
proyectos de forma flexible, autó noma y eficaz reduciendo los costes e incrementando su
productividad.

 Las ventajas que nos brinda la gestió n á gil de proyectos:

 Mejora de la calidad del producto: Estas metodologías fomentan el enfoque

proactivo de los miembros del equipo en la bú squeda de la excelencia del producto.
Ademá s, la integració n, comprobació n y mejora continú a de las propiedades del
producto mejora considerablemente el resultado final.
 Mayor satisfacción del cliente: El cliente está má s satisfecho al verse involucrado y
comprometido a lo largo de todo el proceso de desarrollo. Mediante varias
demostraciones y entregas, el cliente vive a tiempo real las mejoras introducidas en el
proceso.
 Mayor motivación de los trabajadores: Los equipos de trabajo autogestionados,
facilitan el desarrollo de la capacidad creativa y de innovació n entre sus miembros.
 Trabajo colaborativo: La divisió n del trabajo por distintos equipos y roles junto al
desarrollo de reuniones frecuentes, permite una mejor organizació n del trabajo.
 Uso de métricas más relevantes: Las métricas utilizadas para estimar pará metros
como tiempo, coste, rendimiento, etc. son normalmente má s reales en proyectos á giles
que en los tradicionales. Gracias a la divisió n en pequeñ os equipos y fases podemos
ser má s conscientes de lo que está sucediendo.
 Mayor control y capacidad de predicción: La oportunidad de revisar y adaptar el
producto a lo largo del proceso á gil, permite a todos los miembros del proyecto ejercer
un mayor control sobre su trabajo, cosa que permite mejorar la capacidad de
predicció n en tiempo y costes.
 Reducción de costes: La gestió n á gil del proyecto elimina prá cticamente la
posibilidad de fracaso absoluto en el proyecto, porque los errores se van identificando
a lo largo del desarrollo en lugar de esperar a que el producto esté acabado y toda la
inversió n realizada.

4.- Describir las metodologías tradicionales.

Metodologías tradicionales
Las metodologías tradicionales, como su nombre nos indica, son las que se han usado toda
la vida. Buscan imponer disciplina al proceso de desarrollo de software y de esa forma
volverlo predecible y por ello eficiente.
De hecho, estas metodologías tienen un enfoque predictivo, donde se sigue un proceso
secuencial en una sola dirección y sin marcha atrá s. La estimació n/captura de requisitos se
realiza una ú nica vez (exacto, una vez solo) al principio del proyecto y es precisamente por
eso que nuestra estimació n tendrá mucha importancia ya que de ella dependen todos los
recursos que emplearemos en el proyecto. Si queremos adoptar una metodología
tradicional, el desarrollo de un proyecto debe empezar siempre con un riguroso proceso de
captura de requisitos, aná lisis y diseñ o. Recuerda: los requisitos son acordados de una vez y,
para todo el proyecto, no se esperan cambios en ellos.

Univ.: James Quiñ ones Hurtado Pá gina 10

SISTEMAS DE INFORMACIÓ N I CIS - UABJB

Un consejo: adopta este tipo de metodología cuando ya tienes mucha experiencia con un
determinado tipo de producto y sabes estimarlo perfectamente. Ademá s, es la opció n ideal
para proyectos donde los requisitos no cambian y las condiciones del entorno son conocidas y
estables. 
¿Y qué pasa si tienes que desarrollar un proyecto/producto nuevo? ¿Está s 100% seguro de
que todo saldrá exactamente segú n la estimació n y lo previsto?
Un consejo: en este caso, considera aplicar una metodología ágil.
Las metodologías ágiles surgen como alternativa a las tradicionales porque nos ayudan
a reducir la probabilidad de fracaso por sub-estimació n de costos, tiempos y
funcionalidades en entornos cambiantes.

4.- Describir la diferencia que existe entre una metodología ágil y las tradicionales.

La diferencia entre los factores ágiles es que se incorpora el cómo gestionan  la
incertidumbre. En cambio, las tradicionales aportan la facilidad de predecir los costes y
necesidades del proyecto. Un ejemplo claro es có mo podemos enfrentarnos a la incertidumbre
del día a día con metodologías á giles y ver su impacto en la planificació n a medio y largo plazo
cada semana. 

5.- Elaborar una tabla comparativa, donde se muestre las características de cada una
de ella.

Tabla de comparación de Metodología Tradicional y Ágil

Metodologías Ágiles Metodologías Tradicionales

Iterativa Lineal
Pequeños y medios Grandes
Dinámicos Bien definidos antes de empezar
Alta Baja
Entrega evolutiva Ciclo de vida
Los clientes se involucran al principio del
Los clientes participan desde el momento en
proyecto, pero no una vez que la ejecución
que se empieza a realizar el trabajo.
ha comenzado.
Cuando ocurren problemas, todo el equipo El problema se escala a los gerentes del
trabaja junto para resolverlo. proyecto.
El modelo tradicional favorece la
El modelo ágil favorece la adaptación.
anticipación.
Menos enfoque en los procesos formales y Más enfocados sobre los procesos que
directivos. sobre el producto.
Se planifica de Sprint en Sprint. Se planifica todo con gran detalle.
El Scrum Master facilita las tareas y el El gestor del proyecto estima y obtiene la
equipo hace la estimación. aprobación del propietario del proyecto.
Las revisiones se realizan después de cada Constantes revisiones y aprobaciones por

Univ.: James Quiñ ones Hurtado Pá gina 11

SISTEMAS DE INFORMACIÓ N I CIS - UABJB

iteración. parte de los líderes del proyecto.

Univ.: James Quiñ ones Hurtado Pá gina 12