Instituto

Tecnolgico
Nacional de
Mxico

Instituto
Tecnolgico
Nacional de
Mxico

INSTITUTO TECNOLGICO SUPERIOR DE EL MANTE.

Nombre de la Materia:
GESTION DE PROYECTOS DE SOFTWARE
Nombre del Alumno:
Milka Isaura Sierra Reynoso.
NControl: 1201F0091
Semestre 7
Nombre del Docente:
Ing. ADRIANA AVALOS ROBLES

PORMETODOLOGIA SCRUM

Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas prcticas para trabajar
colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto. Estas prcticas se apoyan unas
a otras y su seleccin 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 innovacin,
la competitividad, la flexibilidad y la productividad son fundamentales.
Scrum tambin 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 reaccin ante la competencia.
Cuando la moral de los equipos es baja y la rotacin alta.
Cuando es necesario identificar y solucionar ineficiencias sistemticamente 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 iteracin, denominada Sprint, tiene una duracin
preestablecida de entre 2 y 4 semanas, obteniendo como resultado una versin del software con nuevas prestaciones
listas para ser usadas. En cada nuevo Sprint, se va ajustando la funcionalidad ya construida y se aaden nuevas
prestaciones priorizndose siempre aquellas que aporten mayor valor de negocio.

Product Backlog: Conjunto de requisitos demoninados historias descritos en un lenguaje no tcnico y

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

coste. Los requisitos y prioridades se revisan y ajustan durante el curso del proyecto a intervalos regulares.
Sprint Planning: Reunin 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 reunin, decidir y organizar cmo lo va a conseguir.

Sprint: Iteracin de duracin prefijada durante la cual el equipo trabaja para convertir las historias del Product

Backlog a las que se ha comprometido, en una nueva versin del software totalmente operativo.
Sprint Backlog: Lista de las tareas necesarias para llevar a cabo las historias del sprint.
Daily sprint meeting: Reunin diaria de cmo mximo 15 min. en la que el equipo se sincroniza para trabajar de

forma coordinada. Cada miembro comenta que hizo el da anterior, que har hoy y si hay impedimentos.
Demo y retrospectiva: Reunin que se celebra al final del sprint y en la que el equipo presenta las historias
conseguidas mediante una demonstracin del producto. Posteriormente, en la retrospectiva, el equipo analiza
qu se hizo bien, qu procesos seran mejorables y discute acerca de cmo perfeccionarlos.

Roles
En Scrum, el equipo se focaliza en construir software de calidad. La gestin de un proyecto Scrum se centra en definir
cules son las caractersticas que debe tener el producto a construir (qu construir, qu no y en qu orden) y en vencer
cualquier obstculo 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 guindolo para que cumpla las reglas y procesos de la metodologa.
Gestiona la reduccin 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 visin 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 tcnicos 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 gestin 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 estimacin 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 grficos de avance burndown y

tambin dar soporte a la estimacin con Planning Poker.

SprintoMeter: Herramienta para la gestin, medicin y seguimiento de proyectos Scrum y eXtreme
Programming. Para simplificar el intercambio de datos permite exportar grficos e informes a Excel. Posee

grficos de avance burndown en 3D.

IceScrum: Herramienta Scrum y Kanban. Ofrece las opciones de operacin, consulta y estimacin de historias
de usuario. Permite aadir 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 tcnica de Planning Poker para la estimacin 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 planificacin de Sprints y las reuniones.

Ventajas

Se obtiene software lo ms rpido posible y este cumple con los requerimientos ms 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 metodologa que difiere del resto, y esto causa cierta resistencia en su aplicacin para algunas personas.

Metodologa Espiral
MODELO en espiral, propuesto originalmente por BOEHM en 1976, 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.

En el modelo espiral, el software se desarrolla en una serie de versiones incrementales. Durante las primeras
iteraciones la versin incremental podra ser un modelo en papel o un prototipo, durante las ltimas
iteraciones se producen versiones cada vez ms completas del sistema diseado.

EL modelo en espiral se divide en un nmero de actividades de marco de trabajo, tambin llamadas

REGIONES DE TAREAS , Cada una de las regiones estn compuestas por un conjunto de tareas del trabajo
llamado CONJUNTO DE TAREAS que se adaptan a las caractersticas del proyecto que va a emprenderse en
todos los casos se aplican actividades de proteccin.

Herramientas para desarrollar cada etapa

tareas

que

componen

este

modelo

son:

Comunicacin con el cliente: las tareas requeridas para establecer comunicacin entre el
desarrollador y el cliente.

Planificacin: las tareas requeridas para definir recursos, el tiempo y otras informaciones
relacionadas con el proyecto. Son todos los requerimientos.

Anlisis de riesgos: las tareas requeridas para evaluar riesgos tcnicos y otras informaciones
relacionadas con el proyecto.

Ingeniera: las tareas requeridas para construir una o ms representaciones de la aplicacin.

Construccin y adaptacin: las tareas requeridas para construir, probar, instalar y proporcionar
soporte al usuario.

Evaluacin del cliente: las tareas requeridas para obtener la reaccin del cliente segn la evaluacin
de las representaciones del software creadas durante la etapa de ingeniera e implementacin durante
la etapa de instalacin.

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 construccin de prototipos en

cualquier etapa de evolucin del producto.

El modelo en espiral demanda una consideracin directa de los riesgos tcnicos en todas las etapas
del proyecto y si se aplica adecuadamente debe reducir los riesgos antes de que se conviertan en
problemas.
En la utilizacin de grandes sistemas doblado la productividad.

Desventajas

Resulta difcil convencer a grandes clientes de que el enfoque evolutivo es controlable.

Debido a su elevada complejidad no se aconseja utilizarlo en pequeos sistemas.

Genera mucho tiempo en el desarrollo del sistema

Modelo costoso

Requiere experiencia en la identificacin de riesgos

A qu tipo de desarrollo se dirige

A diferencia de otros modelos el modelo espiral se usa tambin una vez entregado el software (para su
mantenimiento).
En el modelo espiral no hay un nmero 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 gestin de las subvenciones agrarias de un pas
- Software para gestin de la actividad de negocio de una empresa (nminas, facturacin, etc.)
Metodologa Cascada
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. Est es una secuencia de actividades(o etapas)
que consisten en el anlisis de requerimientos, l diseo, la implementacin, la integracin y las pruebas.
Herramientas para desarrollar cada etapa

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

El diseo describe la estructura interna del producto y suele representarse con diagramas y texto.

La implementacin significa programacin. Producto de esta etapa es el cdigo en cualquier nivel,

incluido el producido por sistemas de generacin automtica.

La integracin es el proceso de integracin es el proceso de ensamblar las partes para completar

el producto.

Ventajas
1. Permite la departamentalizacin y control de gestin.
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 gestin de proyectos.

5.

Permite tener bajo control el proyecto.

6.

Limita la cantidad de interaccin entre equipos que se produce durante el desarrollo.

Desventajas
No refleja realmente el proceso de desarrollo del software. Ya que la mayora de los que desarrollan proyectos
no cumple con este lineamiento.
Se tarda mucho tiempo en pasar por todo el ciclo
La aplicacin de la metodologa en cascada se orienta mejor al desarrollo de proyectos de corto plazo, de
poca innovacin y proyectos definitivos y detallados.
Metodologa 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
Anlisis de requisitos
-Personal administrativo des el jefe hasta la persona de menor rango.
Diseo del Sistema
Arquitectura pura de donde se va trabaja teniendo dependencia a su vez del hardware.
Diseo del Programa
Todo el hardware y el software que se usara para el desarrollo Del sistema
Codificacin
De igual manera el hardware y el software para desarrollar el programa
Pruebas
Personal capacitado para realizar las acciones del sistema.

Verificacin
Personal capacitado para verificar que todo est en orden.
Mantenimiento
Desarrolladores para la actualizacin y estabilidad del sistema.

Metodologa Prototipo
El modelo de prototipos permite que todo el sistema, o algunos de sus partes, se construyan rpidamente
para comprender con facilidad y aclarar ciertos aspectos en los que se aseguren que el desarrollador, el
usuario, el cliente estn de acuerdo en lo que se necesita as como tambin la solucin 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 diseos 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 interacta el hombre y la mquina. Este modelo se encarga principalmente de ayudar al
ingeniero de sistemas y al cliente a entender de mejor manera cul ser el resultado de la construccin
cuando los requisitos estn satisfechos.
Herramientas para desarrollar cada etapa
Paradigma de construccin de prototipos tiene tres pasos:

Escuchar al cliente. Recoleccin de requisitos. Se encuentran y definen los objetivos globales, se

identifican los requisitos conocidos y las reas donde es obligatorio ms definicin.

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-mquina.

Etapas para la elaboracin 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. Tambin 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 debera tomar la interaccin humano-mquina.
Desventajas
Su principal desventaja es que una vez que el cliente ha dado su aprobacin 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 ms seguro es que el desarrollador haya hecho compromisos de
implementacin para hacer que el prototipo funcione rpidamente. 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 programacin
inadecuado.
El cliente ve funcionando lo que para l es la primera versin del prototipo que ha sido construido con
"plastilina y alambres", y puede desilusionarse al decirle que el sistema an 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 aplicacin, su cara externa, pero dicha interfaz
est fija, esttica, no procesa datos. El prototipo no tiene desarrollada una lgica interna, slo muestra las
pantallas por las que ir pasando la futura aplicacin.
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, segn 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 ms seguro, en cuanto a la satisfaccin de las
necesidades del cliente.

Cuando un prototipo se desarrolla con el slo propsito de precisar mejor las necesidades del cliente y
despus no se va a aprovechar ni total ni parcialmente en la implementacin del sistema final se habla de un
prototipo desechable.
Para que la construccin de prototipos sea posible se debe contar con la participacin activa del cliente.

Metodologa XP
Tambin conocido como desarrollo con prototipacin o modelo de desarrollo evolutivo, se inicia con la
definicin de los objetivos globales para el software, luego se identifican los requisitos conocidos y las reas
del esquema en donde es necesaria ms definicin. Este modelo se utiliza para dar al usuario una vista
preliminar de parte del software. Este modelo es bsicamente 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. Adems 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, adems 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
-Recoleccin y refinamiento de requisitos
-Modelado, diseo rpido
-Construccin del Prototipo
-Desarrollo, evaluacin del prototipo por el cliente
-Refinamiento del prototipo
-Producto de Ingeniera
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.
Tambin 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 debera tomar la
interaccin humano-mquina
Desventajas
Debido a que el usuario ve que el prototipo funciona piensa que este es el producto terminado y no entienden
que recin se va a desarrollar el software.
El desarrollador puede caer en la tentacin 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 rpido: Metodologa de diseo que desarrolla rpidamente nuevos diseos, los evala y
prescinde del prototipo cuando el prximo diseo es desarrollado mediante un nuevo prototipo.
Modelo de Prototipos reutilizable: Tambin conocido como "Evolutionary Prototyping"; no se pierde el esfuerzo
efectuado en la construccin 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 diseo de moldes en la fabricacin con plsticos o
en el diseo de carroceras de automviles.
Modelo de Prototipos Modular: Tambin conocido como Prototipo Incremental (Incremental prototyping); se
aaden nuevos elementos sobre el prototipo a medida que el ciclo de diseo progresa.
Modelo de Prototipos Horizontal: El prototipo cubre un amplio nmero de aspectos y funciones pero la
mayora no son operativas. Resulta muy til para evaluar el alcance del producto, pero no su uso real.
Modelo de Prototipos Vertical: El prototipo cubre slo un pequeo nmero de funciones operativas. Resulta
muy til para evaluar el uso real sobre una pequea parte del producto.
Modelo de Prototipos de Baja-fidelidad: El prototipo se implementa con papel y lpiz, emulando la funcin 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 ms cercana posible al diseo
real en trminos de aspecto, impresiones, interaccin y tiempo.

Metodologas

Definicin

Ventajas

Desventajas

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 (ROI).
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.

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
informacin
el Product
Owner establece su prioridad.
Flexibilidad
a
cambios: Alta
capacidad de reaccin ante los
cambios
de
requerimientos
generados por necesidades del
cliente o evoluciones del mercado.

Reduccin de riesgos: El hecho

de
llevar
a
cabo
las
funcionalidades de ms 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
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.

-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 construccin de
prototipos en cualquier etapa de
evolucin del producto.

Resulta
difcil
convencer
a
grandes clientes de que el
enfoque evolutivo es controlable.
Debido a su elevada complejidad
no se aconseja utilizarlo en
pequeos sistemas.
Genera mucho tiempo en el
desarrollo del sistema
Modelo costoso
Requiere experiencia en la
identificacin de riesgos

Cascada

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. Est
es una secuencia de actividades(o
etapas) que consisten en el
anlisis de requerimientos, l
diseo, la implementacin, la
integracin y las pruebas.

Permite la departamentalizacin y
control de gestin.
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 gestin
de proyectos.
5.
Permite tener bajo control el
proyecto.
6.
Limita la cantidad de
interaccin entre equipos que se
produce durante el desarrollo.

No refleja realmente el proceso de

desarrollo del software. Ya que la
mayora de los que desarrollan
proyectos no cumple con este
lineamiento.
Se tarda mucho tiempo en pasar
por todo el ciclo
La aplicacin de la metodologa
en cascada se orienta mejor al
desarrollo de proyectos de corto
plazo, de poca innovacin y
proyectos definitivos y detallados.
Metodologa 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
rpidamente
para
comprender con facilidad y aclarar
ciertos aspectos en los que se
aseguren que el desarrollador, el
usuario, el cliente estn de
acuerdo en lo que se necesita as
como tambin la solucin 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 diseos 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. Tambin
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
debera tomar la interaccin
humano-mquina.

Su principal desventaja es que

una vez que el cliente ha dado su
aprobacin 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 ms seguro
es que el desarrollador haya
hecho
compromisos
de
implementacin para hacer que el
prototipo funcione rpidamente.
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
programacin inadecuado.
El cliente ve funcionando lo que
para l es la primera versin del
prototipo que ha sido construido
con "plastilina y alambres", y
puede desilusionarse al decirle
que el sistema an 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

Tambin conocido como desarrollo

No modifica el flujo del ciclo de

Debido a que el usuario ve que el

(Desconocido, desconocido)
(rodrygo, 2010)
(BRAUDE, 2013)
(INGENIERA DE SOFTWARE, 2011)