INSTITUTO TECNOLÓGICO SUPERIOR DE EL MANTE.

Nombre de la Materia:

GESTION DE PROYECTOS DE SOFTWARE

Nombre del Alumno:

Milka Isaura Sierra Reynoso.

N°Control: 1201F0091

Semestre °7

Nombre del Docente:

Ing. ADRIANA AVALOS ROBLES

PORMETODOLOGIA SCRUM

Instituto Tecnológico Nacional de México

Instituto Tecnológico Nacional de México

Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas para trabajar

colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto. Estas prácticas se apoyan unas

a otras y su selección tiene origen en un estudio de la manera de trabajar de equipos altamente productivos.

En Scrum se realizan entregas parciales y regulares del producto final, priorizadas por el beneficio que aportan al

receptor del proyecto. Por ello, Scrum está especialmente indicado para proyectos en entornos complejos, donde se

necesita obtener resultados pronto, donde los requisitos son cambiantes o poco definidos, donde la innovación,

la competitividad, la flexibilidad y la productividad son fundamentales.

Scrum también se utiliza para resolver situaciones como las siguientes:

No se está entregando al cliente lo que necesita.

Cuando las entregas se alargan demasiado.

Los costes se disparan o la calidad no es aceptable.

Cuando se necesita capacidad de reacción ante la competencia.

Cuando la moral de los equipos es baja y la rotación alta.

Cuando es necesario identificar y solucionar ineficiencias sistemáticamente o cuando se quiere trabajar utilizando

un proceso especializado en el desarrollo de producto.

Proceso y Roles de Scrum

El proceso

El desarrollo se realiza de forma iterativa e incremental. Cada iteración, denominada Sprint, tiene una duración

preestablecida de entre 2 y 4 semanas, obteniendo como resultado una versión del software con nuevas prestaciones

listas para ser usadas. En cada nuevo Sprint, se va ajustando la funcionalidad ya construida y se añaden nuevas

prestaciones priorizándose siempre aquellas que aporten mayor valor de negocio.

Product Backlog: Conjunto de requisitos demoninados historias descritos en un lenguaje no técnico y

priorizados por valor de negocio, o lo que es lo mismo, por retorno de inversión considerando su beneficio y

coste. Los requisitos y prioridades se revisan y ajustan durante el curso del proyecto a intervalos regulares.

Sprint Planning: Reunión durante la cual  el Product Owner presenta las historias del backlog por orden de

prioridad. El equipo determina la cantidad de historias que puede comprometerse a completar en ese sprint, para

en una segunda parte de la reunión, decidir y organizar cómo lo va a conseguir.

Sprint: Iteración de duración prefijada durante la cual el equipo trabaja para convertir las historias del Product

Backlog a las que se ha comprometido, en una nueva versión del software totalmente operativo.

Sprint Backlog: Lista de las tareas necesarias para llevar a cabo las historias del sprint.

Daily sprint meeting: Reunión diaria de cómo máximo 15 min. en la que el equipo se sincroniza para trabajar de

forma coordinada. Cada miembro comenta que hizo el día anterior, que hará hoy y si hay impedimentos.

Demo y retrospectiva: Reunión que se celebra al final del sprint y en la que el equipo presenta las historias

conseguidas mediante una demonstración del producto. Posteriormente, en la retrospectiva, el equipo analiza

qué se hizo bien, qué procesos serían mejorables y discute acerca de cómo perfeccionarlos.

Roles

En Scrum, el equipo se focaliza en construir software de calidad. La gestión de un proyecto Scrum se centra en definir

cuáles son las características que debe tener el producto a construir (qué construir, qué no y en qué orden) y en vencer

cualquier obstáculo que pudiera entorpecer la tarea del equipo de desarrollo.

El equipo Scrum está formado por los siguientes roles:

Scrum master: Persona que lidera al equipo guiándolo para que cumpla las reglas y procesos de la metodología.

Gestiona la reducción de impedimentos del proyecto y trabaja con el Product Owner para maximizar el ROI. 

Product owner (PO): Representante de lso accionistas y clientes que usan el software. Se focaliza en la parte de

negocio y el es responsable del ROI del proyecto (entregar un valor superior al dinero invertido). Traslada la visión del

proyecto al equipo, formaliza las prestaciones en historias a incorporar en el Product Backlog y las reprioriza de forma

regular. 

Team: Grupo de profesionales con los conocimientos técnicos necesarios y que desarrollan el proyecto de manera

conjunta llevando a cabo las historias a las que se comprometen al inicio de cada sprint.

Herramientas Scrum

Kunagi: Herramienta Web que proporciona un sistema de gestión de proyectos basado en Scrum. Ofrece

herramientas colaborativas y otras facilidades, como un cuadro de mando del proyecto, un panel interactivo para

el Sprint o soporte a la estimación con Planning Poker.

ScrumDo: Herramienta Scrum muy centrada en la simplicidad y en la facilidad de uso. Permite gestionar las

listas de tareas e historias de usuario, crear y gestionar iteraciones, obtener gráficos de avance “burndown” y

también dar soporte a la estimación con Planning Poker.

SprintoMeter: Herramienta para la gestión, medición y seguimiento de proyectos Scrum y eXtreme

Programming. Para simplificar el intercambio de datos permite exportar gráficos e informes a Excel. Posee

gráficos de avance burndown en 3D.

IceScrum: Herramienta Scrum y Kanban. Ofrece las opciones de operación, consulta y estimación de historias

de usuario. Permite añadir historias de usuario a la pila de producto, dividir el tiempo en Sprints y mover estas

historias de la pila de producto a cada uno de los Sprint. Posee la técnica de Planning Poker para la estimación y

paneles virtuales.

Pango Scrum: Otra de las herramientas Scrum online, con una interfaz sencilla y amigable que permite escribir,

estimar y priorizar la pila de producto. Facilita en gran medida la planificación de Sprints y las reuniones.

Ventajas

Se obtiene software lo más rápido posible y este cumple con los requerimientos más importantes.

Se trabaja en iteraciones cortas, de alto enfoque y total transparencia.

Se acepta que el cambio es una constante universal y se adapta el desarrollo para integrar los cambios que son

importantes.

Se incentiva la creatividad de los desarrolladores haciendo que el equipo sea auto administrado.

Se mantiene la efectividad del equipo habilitando y protegiendo un entorno libre de interrupciones e

interferencias.

Permite producir software de una forma consistente, sostenida y competitiva.

Las reuniones se dedican a inconvenientes recientes, evitando el estancamiento

Desventajas

Requiere delegar responsabilidades al equipo, incluso permite fallar si es necesario.

Es una metodología que difiere del resto, y esto causa cierta resistencia en su aplicación para algunas personas.

Metodología Espiral

MODELO en espiral, propuesto originalmente por BOEHM en 1976, es un modelo de proceso de software

evolutivo donde se conjuga la naturaleza de construcción de prototipos con los aspectos controlados y

sistemáticos del MODELO LINEAL y SECUENCIAL. Proporciona el potencial para el desarrollo rápido de

versiones incrementales del software que no se basa en fases claramente definidas y separadas para crear un

sistema.

En el modelo espiral, el software se desarrolla en una serie de versiones incrementales. Durante las primeras

iteraciones la versión incremental podría ser un modelo en papel o un prototipo, durante las últimas

iteraciones se producen versiones cada vez más completas del sistema diseñado.

EL modelo en espiral se divide en un número de actividades de marco de trabajo, también llamadas

REGIONES DE TAREAS , Cada una de las regiones están compuestas por un conjunto de tareas del trabajo

llamado CONJUNTO DE TAREAS que se adaptan a las características del proyecto que va a emprenderse en

todos los casos se aplican actividades de protección.

Herramientas para desarrollar cada etapa

tareas que componen este modelo son:

Comunicación con el cliente: las tareas requeridas para establecer comunicación entre el

desarrollador y el cliente.

Planificación: las tareas requeridas para definir recursos, el tiempo y otras informaciones

relacionadas con el proyecto. Son todos los requerimientos.

Análisis de riesgos: las tareas requeridas para evaluar riesgos técnicos y otras informaciones

relacionadas con el proyecto.

Ingeniería: las tareas requeridas para construir una o más representaciones de la aplicación.

Construcción y adaptación: las tareas requeridas para construir, probar, instalar y proporcionar

soporte al usuario.

Evaluación del cliente: las tareas requeridas para obtener la reacción del cliente según la evaluación

de las representaciones del software creadas durante la etapa de ingeniería e implementación durante

la etapa de instalación.

Ventajas

El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora.

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.

El modelo en espiral permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en

cualquier etapa de evolución del producto.

El modelo en espiral demanda una consideración directa de los riesgos técnicos en todas las etapas

del proyecto y si se aplica adecuadamente debe reducir los riesgos antes de que se conviertan en

problemas.

En la utilización de grandes sistemas doblado la productividad.

Desventajas

Resulta difícil convencer a grandes clientes de que el enfoque evolutivo es controlable.

Debido a su elevada complejidad no se aconseja utilizarlo en pequeños sistemas.

Genera mucho tiempo en el desarrollo del sistema

Modelo costoso

Requiere experiencia en la identificación de riesgos

A qué tipo de desarrollo se dirige

A diferencia de otros modelos el modelo espiral se usa también una vez entregado el software (para su

mantenimiento).

En el modelo espiral no hay un número de iteraciones ni costes cerrados, ya que esto se revisa en cada paso

por la actividad de planeamiento.

El modelo en espiral es realista para el desarrollo de software a gran escala. Ejemplos:

- Software para gestión de las subvenciones agrarias de un país

- Software para gestión de la actividad de negocio de una empresa (nóminas, facturación, etc.)

Metodología Cascada

También conocido como modelo clásico, modelo tradicional o modelo lineal secuencial. Él método de la cascada es considerado como el enfoque clásico para el ciclo de vida del desarrollo de sistemas, se puede decir que es un método puro que implica un desarrollo rígido. Está es una secuencia de actividades(o etapas) que consisten en el análisis de requerimientos, él diseño, la implementación, la integración y las pruebas.

Herramientas para desarrollar cada etapa

El análisis de requerimientos consiste en reunir las necesidades del producto y casi siempre su salida es texto.

    El diseño describe la estructura interna del producto y suele representarse con diagramas y texto.

      La implementación significa programación. Producto de esta etapa es el código en cualquier nivel, incluido el producido por sistemas de generación automática.

         La integración es el proceso de integración es el proceso de ensamblar las partes para completar el producto.

Ventajas

1. Permite la departamentalización y control de gestión.

2. El horario se establece con los plazos normalmente adecuados para cada etapa de desarrollo.

3. Este proceso conduce a entregar el proyecto a tiempo.

4. Es sencilla y facilita la gestión de proyectos.

5. Permite tener bajo control el proyecto.

6. Limita la cantidad de interacción entre equipos que se produce durante el desarrollo.

Desventajas

No refleja realmente el proceso de desarrollo del software. Ya que la mayoría de los que desarrollan proyectos no cumple con este lineamiento.

Se tarda mucho tiempo en pasar por todo el ciclo

La aplicación de la metodología en cascada se orienta mejor al desarrollo de proyectos de corto plazo, de poca innovación y proyectos definitivos y detallados.

Metodología pueden confundir al equipo profesional en las etapas tempranas del proyecto.

No es frecuente que el cliente o usuario final explicite clara y completamente los requisitos.

A qué tipo de desarrollo se dirige

Análisis de requisitos

-Personal administrativo des el jefe hasta la persona de menor rango.

Diseño del Sistema

–Arquitectura pura de donde se va trabaja teniendo dependencia a su vez del hardware.

Diseño del Programa

–Todo el hardware y el software que se usara para el desarrollo Del sistema

Codificación

–De igual manera el hardware y el software para desarrollar el programa

Pruebas

–Personal capacitado para realizar las acciones del sistema.

Verificación

–Personal capacitado para verificar que todo esté en orden.

Mantenimiento

– Desarrolladores para la actualización y estabilidad del sistema.

Metodología Prototipo

El modelo de prototipos permite que todo el sistema, o algunos de sus partes, se construyan rápidamente para comprender con facilidad y aclarar ciertos aspectos en los que se aseguren que el desarrollador, el usuario, el cliente estén de acuerdo en lo que se necesita así como también la solución que se propone para dicha necesidad y de esta forma minimizar el riesgo y la incertidumbre en el desarrollo, este modelo se encarga del desarrollo de diseños para que estos sean analizados y prescindir de ellos a medida que se adhieran nuevas especificaciones, es ideal para medir el alcance del producto, pero no se asegura su uso real.

Este modelo principalmente se lo aplica cuando un cliente define un conjunto de objetivos generales para el software a desarrollarse sin delimitar detalladamente los requisitos de entrada procesamiento y salida, es decir cuando el responsable no está seguro de la eficacia de un algoritmo, de la adaptabilidad del sistema o de la forma en que interactúa el hombre y la máquina. Este modelo se encarga principalmente de ayudar al ingeniero de sistemas y al cliente a entender de mejor manera cuál será el resultado de la construcción cuando los requisitos estén satisfechos.

Herramientas para desarrollar cada etapa

Paradigma de construcción de prototipos tiene tres pasos: 

Escuchar al cliente. Recolección de requisitos. Se encuentran y definen los objetivos globales, se identifican los requisitos conocidos y las áreas donde es obligatorio más definición. 

Construir y revisar la maqueta (prototipo). 

El cliente prueba la maqueta (prototipo) y lo utiliza para refinar los requisitos del software. 

Este modelo es útil cuando: 

El cliente no identifica los requisitos detallados. 

El responsable del desarrollo no está seguro de la eficiencia de un algoritmo, sistema operativo o de la interface hombre-máquina. 

Etapas para la elaboración del Modelo de Prototipo.

Ventajas

Este modelo es útil cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida. También ofrece un mejor enfoque cuando el responsable del desarrollo del software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humano-máquina.

Desventajas

Su principal desventaja es que una vez que el cliente ha dado su aprobación final al prototipo y cree que está a punto de recibir el proyecto final, se encuentra con que es necesario reescribir buena parte del prototipo para hacerlo funcional, porque lo más seguro es que el desarrollador haya hecho compromisos de implementación para hacer que el prototipo funcione rápidamente. Es posible que el prototipo sea muy lento, muy grande, no muy amigable en su uso, o incluso, que esté escrito en un lenguaje de programación inadecuado.

El cliente ve funcionando lo que para él es la primera versión del prototipo que ha sido construido con "plastilina y alambres", y puede desilusionarse al decirle que el sistema aún no ha sido construido. El desarrollador puede ampliar el prototipo para construir el sistema final sin tener en cuenta los compromisos de calidad y de mantenimiento que tiene con el cliente.

A qué tipo de desarrollo se dirige

Una maqueta o prototipo de pantallas muestra la interfaz de la aplicación, su cara externa, pero dicha interfaz está fija, estática, no procesa datos. El prototipo no tiene desarrollada una lógica interna, sólo muestra las pantallas por las que irá pasando la futura aplicación.

Por su parte, el prototipo funcional evolutivo desarrolla un comportamiento que satisface los requisitos y necesidades que se han entendido claramente. Realiza, por tanto, un un proceso real de datos, para contrastarlo con el usuario. Se va modificando y desarrollando sobre la marcha, según las apreciaciones del cliente. Esto ralentiza el proceso de desarrollo y disminuye la fiabilidad, puesto que el software está constantemente variando, pero,  a la larga, genera un producto más seguro, en cuanto a la satisfacción de las necesidades del cliente.

Cuando un prototipo se desarrolla con el sólo propósito de precisar mejor las necesidades del cliente y después no se va a aprovechar ni total ni parcialmente en la implementación del sistema final se habla de un prototipo desechable.

Para que la construcción de prototipos sea posible se debe contar con la participación activa del cliente.

 

Metodología XP

También conocido como desarrollo con prototipación o modelo de desarrollo evolutivo, se inicia con la definición de los objetivos globales para el software, luego se identifican los requisitos conocidos y las áreas del esquema en donde es necesaria más definición. Este modelo se utiliza para dar al usuario una vista preliminar de parte del software. Este modelo es básicamente prueba y error ya que si al usuario no le gusta una parte del prototipo significa que la prueba fallo por lo cual se debe corregir el error que se tenga hasta que el usuario quede satisfecho. Además el prototipo debe ser construido en poco tiempo, usando los programas adecuados y no se debe utilizar mucho dinero pues a partir de que este sea aprobado nosotros podemos iniciar el verdadero desarrollo del software. Pero eso si al construir el prototipo nos asegura que nuestro software sea de mejor calidad, además de que su interfaz sea de agrado para el usuario. Un prototipo podrá ser construido solo si con el software es posible experimentar.

Herramientas para desarrollar cada etapa

-Recolección y refinamiento de requisitos

-Modelado, diseño rápido

-Construcción del Prototipo

-Desarrollo, evaluación del prototipo por el cliente

-Refinamiento del prototipo

-Producto de Ingeniería

Ventajas

No modifica el flujo del ciclo de vida

Reduce el riesgo de construir productos que no satisfagan las necesidades de los usuarios

Reduce costo y aumenta la probabilidad de éxito

Exige disponer de las herramientas adecuadas

Este modelo es útil cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida.

También ofrece un mejor enfoque cuando el responsable del desarrollo del software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humano-máquina

Desventajas

Debido a que el usuario ve que el prototipo funciona piensa que este es el producto terminado y no entienden que recién se va a desarrollar el software.

El desarrollador puede caer en la tentación de ampliar el prototipo para construir el sistema final sin tener en cuenta los compromisos de calidad y mantenimiento que tiene con el cliente.

A qué tipo de desarrollo se dirige

Modelo de Prototipos rápido: Metodología de diseño que desarrolla rápidamente nuevos diseños, los evalúa y prescinde del prototipo cuando el próximo diseño es desarrollado mediante un nuevo prototipo.

Modelo de Prototipos reutilizable: También conocido como "Evolutionary Prototyping"; no se pierde el esfuerzo efectuado en la construcción del prototipo pues sus partes o el conjunto pueden ser utilizados para construir el producto real. Mayormente es utilizado en el desarrollo de software, si bien determinados productos de hardware pueden hacer uso del prototipo como la base del diseño de moldes en la fabricación con plásticos o en el diseño de carrocerías de automóviles.

Modelo de Prototipos Modular: También conocido como Prototipo Incremental (Incremental prototyping); se añaden nuevos elementos sobre el prototipo a medida que el ciclo de diseño progresa.

Modelo de Prototipos Horizontal: El prototipo cubre un amplio número de aspectos y funciones pero la mayoría no son operativas. Resulta muy útil para evaluar el alcance del producto, pero no su uso real.

Modelo de Prototipos Vertical: El prototipo cubre sólo un pequeño número de funciones operativas. Resulta muy útil para evaluar el uso real sobre una pequeña parte del producto.

Modelo de Prototipos de Baja-fidelidad: El prototipo se implementa con papel y lápiz, emulando la función del producto real sin mostrar el aspecto real del mismo. Resulta muy útil para realizar tests baratos.

Modelo de Prototipos de Alta-fidelidad: El prototipo se implementa de la forma más cercana posible al diseño real en términos de aspecto, impresiones, interacción y tiempo.

Metodologías Definición Ventajas Desventajas

Scrum Es una metodología ágil y flexible para gestionar el desarrollo de software, cuyo principal objetivo es maximizar el retorno de la inversión para su empresa (ROI). Se basa en construir primero la funcionalidad de mayor valor para el cliente y en los principios de inspección continua, adaptación, auto-gestión e innovación.

Cumplimento de expectativas: El cliente establece sus expectativas indicando el valor que le aporta cada requisito / historia del proyecto, el equipo los estima y con esta información el Product Owner establece su prioridad.Flexibilidad a cambios: Alta capacidad de reacción ante los cambios de requerimientos generados por necesidades del cliente o evoluciones del mercado.

Reducción de riesgos: El hecho de llevar a cabo las funcionalidades de más valor en primer lugar y de conocer la velocidad con que el equipo avanza en el proyecto, permite despejar riesgos eficazmente de manera anticipada.

Espiral MODELO en espiral, propuesto originalmente por BOEHM en 1976, es un modelo de proceso de software evolutivo donde se conjuga la naturaleza de construcción de prototipos con los aspectos controlados y sistemáticos del MODELO LINEAL y SECUENCIAL. Proporciona el potencial para el desarrollo rápido de versiones incrementales del software que no se basa en fases claramente definidas y separadas para crear un sistema.

-El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora.-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.-El modelo en espiral permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del producto.

Resulta difícil convencer a grandes clientes de que el enfoque evolutivo es controlable.Debido a su elevada complejidad no se aconseja utilizarlo en pequeños sistemas.Genera mucho tiempo en el desarrollo del sistemaModelo costosoRequiere experiencia en la identificación de riesgos

Cascada También conocido como modelo clásico, modelo tradicional o modelo lineal secuencial. Él método de la cascada es considerado como el enfoque clásico para el ciclo de vida del desarrollo de sistemas, se puede decir que es un método puro que implica un desarrollo rígido. Está es una secuencia de actividades(o etapas) que consisten en el análisis de requerimientos, él diseño, la implementación, la integración y las pruebas.

Permite la departamentalización y control de gestión.2. El horario se establece con los plazos normalmente adecuados para cada etapa de desarrollo.3. Este proceso conduce a entregar el proyecto a tiempo.4. Es sencilla y facilita la gestión de proyectos.5. Permite tener bajo control el proyecto.6. Limita la cantidad de interacción entre equipos que se produce durante el desarrollo.

No refleja realmente el proceso de desarrollo del software. Ya que la mayoría de los que desarrollan proyectos no cumple con este lineamiento. Se tarda mucho tiempo en pasar por todo el ciclo La aplicación de la metodología en cascada se orienta mejor al desarrollo de proyectos de corto plazo, de poca innovación y proyectos definitivos y detallados. Metodología pueden confundir al equipo profesional en las etapas tempranas del proyecto.No es frecuente que el cliente o usuario final explicite clara y completamente los requisitos.

Prototipo Permite que todo el sistema, o algunos de sus partes, se construyan rápidamente para comprender con facilidad y aclarar ciertos aspectos en los que se aseguren que el desarrollador, el usuario, el cliente estén de acuerdo en lo que se necesita así como también la solución que se propone para dicha necesidad y de esta forma minimizar el riesgo y la incertidumbre en el desarrollo, este modelo se encarga del desarrollo de diseños para que estos sean analizados y prescindir de ellos a medida que se adhieran nuevas especificaciones, es ideal para medir el alcance del producto, pero no se asegura su uso real.

Este modelo es útil cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida. También ofrece un mejor enfoque cuando el responsable del desarrollo del software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humano-máquina.

Su principal desventaja es que una vez que el cliente ha dado su aprobación final al prototipo y cree que está a punto de recibir el proyecto final, se encuentra con que es necesario reescribir buena parte del prototipo para hacerlo funcional, porque lo más seguro es que el desarrollador haya hecho compromisos de implementación para hacer que el prototipo funcione rápidamente. Es posible que el prototipo sea muy lento, muy grande, no muy amigable en su uso, o incluso, que esté escrito en un lenguaje de programación inadecuado.El cliente ve funcionando lo que para él es la primera versión del prototipo que ha sido construido con "plastilina y alambres", y puede desilusionarse al decirle que el sistema aún no ha sido construido. El desarrollador puede ampliar el prototipo para construir el sistema final sin tener en cuenta los compromisos de calidad y de mantenimiento que tiene con el cliente.

XP También conocido como desarrollo con prototipación o modelo de desarrollo evolutivo, se inicia con la definición de los objetivos globales para el

No modifica el flujo del ciclo de vidaReduce el riesgo de construir productos que no satisfagan las necesidades de los usuarios

Debido a que el usuario ve que el prototipo funciona piensa que este es el producto terminado y no entienden que recién se va a desarrollar el software.