TECNOLÓGICO NACIONAL DE MÉXICO

INSTITUTO TECNOLÓGICO DE VERACRUZ

NOMBRE DEL ALUMNO:

HERRERA MEZA LUIS ALBERTO

NUMERO DE CONTROL:

E15020562

PROFESOR TITULAR

VERDALET GUZMAN FELIPE

TEMA

2.1

MATERIA:

INGENIERIA DE SOFTWARE

H. VERACRUZ, VER. 22/ 03/ 2018

 Índice
Introducción ............................................................................................................. 3
Modelos para el desarrollo de software ................................................................... 4
El modelo en cascada .......................................................................................... 4
Desarrollo incremental.......................................................................................... 5
Ingeniería de software orientada a la reutilización ............................................... 7
Modelo en espiral de Boehm ................................................................................ 8
Metodologías para el desarrollo ágil del software. ................................................ 12
Programación Extrema (XP)............................................................................... 12
Otros modelos agiles de procesos ........................................................................ 13
Desarrollo adaptativo de software (DAS) ........................................................... 14
Scrum ................................................................................................................. 14
Método de desarrollo de sistemas dinámicos (MDSD) ....................................... 16
Cristal ................................................................................................................. 17
El proceso unificado ágil (PUA) .......................................................................... 17
Conclusión............................................................................................................. 18
Bibliografía ............................................................................................................ 18
Introducción
En esta investigación hablaremos de los diferentes tipos de metodologías para el
desarrollo de software, veremos a detalle cuales son cada una de ellas.

Existen diferentes modelos y metodologías que han sido en los últimos años
herramientas de apoyo para el desarrollo del software. Somerville (2005), menciona
que:

• Modelo de desarrollo de software: es una representación simplificada del

proceso para el desarrollo de software, presentada desde una perspectiva
específica.

• Metodología de desarrollo de software: es un enfoque estructurado para

el desarrollo de software que incluye modelos de sistemas, notaciones,
reglas, sugerencias de diseño y guías de procesos.
Modelos para el desarrollo de software
un modelo para el desarrollo de software es una representación abstracta de un
proceso. Cada modelo representa un proceso desde una perspectiva particular y
así proporcione información parcial sobre el proceso. Éstos modelos generales no
son descripciones definitivas de los procesos del software más bien son
abstracciones de los procesos que se pueden utilizar para el desarrollo del software.

Puede pensarse en ellos como marcos de trabajo del proceso y que pueden ser
adaptados para crear procesos más específicos. Los modelos que mencionaremos
en este punto son:

• El modelo en cascada (waterfall) Éste toma las actividades fundamentales

del proceso de especificación, desarrollo, validación y evolución y, luego,
los representa como fases separadas del proceso, tal como
especificación de requerimientos, diseño de software, implementación,
pruebas, etcétera.

• Desarrollo incremental Este enfoque vincula las actividades de

especificación, desarrollo y validación. El sistema se desarrolla como una
serie de versiones (incrementos), y cada versión añade funcionalidad a la
versión anterior.

• Ingeniería de software orientada a la reutilización Este enfoque se basa

en la existencia de un número significativo de componentes reutilizables.
El proceso de desarrollo del sistema se enfoca en la integración de estos
componentes en un sistema, en vez de desarrollarlo desde cero.

El modelo en cascada
El modelo en cascada es un ejemplo de un proceso dirigido por un plan; en principio,
usted debe planear y programar todas las actividades del proceso, antes de
comenzar a trabajar con ellas.
Las principales etapas del modelo en cascada reflejan directamente las actividades
fundamentales del desarrollo:

1. Análisis y definición de requerimientos Los servicios, las restricciones y las

metas del sistema se establecen mediante consulta a los usuarios del
sistema. Luego, se definen con detalle y sirven como una especificación del
sistema.
2. Diseño del sistema y del software El proceso de diseño de sistemas asigna
los requerimientos, para sistemas de hardware o de software, al establecer
una arquitectura de sistema global. El diseño del software implica identificar
y describir las abstracciones fundamentales del sistema de software y sus
relaciones.

3. Implementación y prueba de unidad Durante esta etapa, el diseño de

software se rea liza como un conjunto de programas o unidades del
programa. La prueba de unidad consiste en verificar que cada unidad cumpla
con su especificación.

4. Integración y prueba de sistema Las unidades del programa o los programas

individuales se integran y prueban como un sistema completo para
asegurarse de que se cumplan los requerimientos de software. Después de
probarlo, se libera el sistema de software al cliente.

5. Operación y mantenimiento Por lo general (aunque no necesariamente), ésta

es la fase más larga del ciclo de vida, donde el sistema se instala y se pone
en práctica. El mantenimiento incluye corregir los errores que no se
detectaron en etapas anteriores del ciclo de vida, mejorar la implementación
de las unidades del sistema e incrementar los servicios del sistema conforme
se descubren nuevos requerimientos.

Desarrollo incremental
El desarrollo incremental se basa en la idea de diseñar una implementación inicial,
exponer ésta al comentario del usuario, y luego desarrollarla en sus diversas
versiones hasta producir un sistema adecuado.
Las actividades de especificación, desarrollo y validación están entrelazadas en vez
de separadas, con rápida retroalimentación a través de las actividades.

El desarrollo de software incremental, que es una parte fundamental de los enfoques

ágiles, es mejor que un enfoque en cascada para la mayoría de los sistemas
empresariales, de comercio electrónico y personales. El desarrollo incremental
refleja la forma en que se resuelven problemas. Rara vez se trabaja por adelantado
una solución completa del problema, más bien se avanza en una serie de pasos
hacia una solución y se retrocede cuando se detecta que se cometieron errores. Al
desarrollar el software de manera incremental, resulta más barato y fácil realizar
cambios en el software conforme éste se diseña.

Cada incremento o versión del sistema incorpora algunas de las funciones que
necesita el cliente. Por lo general, los primeros incrementos del sistema incluyen la
función más importante o la más urgente. Esto significa que el cliente puede evaluar
el desarrollo del sistema en una etapa relativamente temprana, para constatar si se
entrega lo que se requiere. En caso contrario, sólo el incremento actual debe
cambiarse y, posiblemente, definir una nueva función para incrementos posteriores.

Comparado con el modelo en cascada, el desarrollo incremental tiene tres

beneficios
importantes:

1. Se reduce el costo de adaptar los requerimientos cambiantes del cliente. La

cantidad de análisis y la documentación que tiene que reelaborarse son
mucho menores de lo requerido con el modelo en cascada.

2. Es más sencillo obtener retroalimentación del cliente sobre el trabajo de

desarrollo que se realizó. Los clientes pueden comentar las demostraciones
del software y darse cuenta de cuánto se ha implementado. Los clientes
 encuentran difícil juzgar el avance a partir de documentos de diseño de
software.

3. Es posible que sea más rápida la entrega e implementación de software útil

al cliente, aun si no se ha incluido toda la funcionalidad. Los clientes tienen
posibilidad de usar y ganar valor del software más temprano de lo que sería
posible con un proceso en cascada.

Ingeniería de software orientada a la reutilización

En la mayoría de los proyectos de software hay cierta reutilización de software.

Sucede con frecuencia de manera informal, cuando las personas que trabajan en el
proyecto conocen diseños o códigos que son similares a lo que se requiere. Los
buscan, los modifican según se necesite y los incorporan en sus sistemas.

Esta reutilización informal ocurre independientemente del proceso de desarrollo que

se emplee. Sin embargo, en el siglo XXI, los procesos de desarrollo de software que
se enfocaban en la reutilización de software existente se utilizan ampliamente. Los
enfoques orientados a la reutilización se apoyan en una gran base de componentes
de software reutilizable y en la integración de marcos para la composición de dichos
componentes. En ocasiones, tales componentes son sistemas por derecho propio
(sistemas comerciales, off-the-shelf o COTS) que pueden mejorar la funcionalidad
específica, como el procesador de textos o la hoja de cálculo.

En la siguiente imagen se muestra un modelo del proceso general para desarrollo

basado en reutilización. Aunque la etapa inicial de especificación de
requerimientos y la etapa de validación se comparan con otros procesos de
software en un proceso orientado a la reutilización, las etapas intermedias son
diferentes. Dichas etapas son:
 1. Análisis de componentes Dada la especificación de requerimientos, se
realiza una búsqueda de componentes para implementar dicha
especificación. Por lo general, no hay coincidencia exacta y los
componentes que se usan proporcionan sólo parte de la funcionalidad
requerida.

2. Modificación de requerimientos Durante esta etapa se analizan los

requerimientos usando información de los componentes descubiertos.
Luego se modifican para reflejar los componentes disponibles. Donde las
modificaciones son imposibles, puede regresarse a la actividad de análisis
de componentes para buscar soluciones alternativas.

3. Diseño de sistema con reutilización Durante esta fase se diseña el marco

conceptual del sistema o se reutiliza un marco conceptual existente. Los
creadores toman en cuenta los componentes que se reutilizan y organizan
el marco de referencia para atenderlo. Es posible que deba diseñarse algo
de software nuevo, si no están disponibles los componentes reutilizables

4. Desarrollo e integración Se diseña el software que no puede procurarse de

manera externa, y se integran los componentes y los sistemas COTS para
crear el nuevo sistema. La integración del sistema, en este modelo, puede
ser parte del proceso de desarrollo, en vez de una actividad independiente.

Existen tres tipos de componentes de software que pueden usarse en un proceso

orientado a la reutilización:

1. Servicios Web que se desarrollan en concordancia para atender servicios

estándares y que están disponibles para la invocación remota.

2. Colecciones de objetos que se desarrollan como un paquete para su

integración con un marco de componentes como .NET o J2EE.

3. Sistemas de software independientes que se configuran para usar en un

entorno particular.

Modelo en espiral de Boehm

El proceso de software se representa como una espiral, y no como una secuencia

de actividades con cierto retroceso de una actividad a otra. Cada ciclo en la espiral
representa una fase del proceso de software. Por ende, el ciclo más interno puede
relacionarse con la factibilidad del sistema, el siguiente ciclo con la definición de
requerimientos, el ciclo que sigue con el diseño del sistema, etcétera. El modelo en
espiral combina el evitar el cambio con la tolerancia al cambio. Lo anterior supone
que los cambios son resultado de riesgos del proyecto e incluye actividades de
gestión de riesgos explícitas para reducir tales riesgos.

Cada ciclo en la espiral se divide en cuatro sectores:

1. Establecimiento de objetivos Se definen objetivos específicos para dicha

fase del proyecto. Se identifican restricciones en el proceso y el producto, y
se traza un plan de gestión detallado. Se identifican los riesgos del
proyecto. Pueden planearse estrategias alternativas, según sean los
riesgos.
2. Valoración y reducción del riesgo En cada uno de los riesgos identificados
del proyecto, se realiza un análisis minucioso. Se dan acciones para reducir
el riesgo. Por ejemplo, si existe un riesgo de que los requerimientos sean
inadecuados, puede desarrollarse un sistema prototipo.
3. Desarrollo y validación Después de una evaluación del riesgo, se elige un
modelo de desarrollo para el sistema. Por ejemplo, la creación de prototipos
desechables sería el mejor enfoque de desarrollo, si predominan los riesgos
en la interfaz del usuario. Si la principal consideración son los riesgos de
seguridad, el desarrollo con base en transformaciones formales sería el
proceso más adecuado, entre otros. Si el principal riesgo identificado es la
integración de subsistemas, el modelo en cascada sería el mejor modelo de
desarrollo a utilizar.
4. Planeación El proyecto se revisa y se toma una decisión sobre si hay que
continuar con otro ciclo de la espiral. Si se opta por continuar, se trazan los
planes para la siguiente fase del proyecto.
Modelo Características Ventajas
Cascada • Es el más utilizado
• Es una visión de proceso
de desarrollo de software
como una sucesión de
etapas que produce
productos
• Si se cambia el orden de
las fases, el producto
final será de inferior
calidad
Incremental • Se envían proyectos
largos y se entrega algo
de valor a los usuarios
con cierta frecuencia
• El resultado puede ser
muy positiva
Basado en • Se basa en la
Componentes reutilización de software
existente
• Este modelo nos permite
reutilizar partes de
código pre elaborado
Desventajas
• Se tiene todo bien organizado y
no se mezcla las fases
• La planificación es sencilla
• La calidad del producto
resultante es alta
• Con un paradigma incremental
se reduce el tiempo de
desarrollo inicial, ya que se
implementa la funcionalidad
parcial
• También provee un impacto
ventajoso frente al cliente, que
es la entrega temprana de
partes operativas del software
• Se ahorra tiempo en desarrollo
del software y ahorro de dinero
• Simplifica las pruebas, permite
que las pruebas sean
ejecutadas probando cada uno
de los componentes antes de
probar el conjunto completo de
componentes ensamblados.
• Se tarda mucho
tiempo en pasar por
todo el ciclo
• Es difícil incorporar
nuevas cosas si se
quiere actualizar
• Iteraciones costosas
• Requiere de mucha
planeación, tanto
administrativa como
técnica.
• Requiere de metas
claras para conocer el
estado del proyecto
• Las actualizaciones
de los componentes
adquiridos no están
en manos de las
desarrolladores del
sistema
Espiral • En cada giro se • El modelo en espiral permite a • Tiene una elevada
construye un nuevo quien desarrolla aplicar el complejidad
modelo del sistema enfoque de construcción de • Es un modelo costoso
completo prototipos en cualquier etapa • Genera mucho tiempo
• Es el mejor modelado de evolución del producto en el desarrollo del
para el desarrollo de sistema
grandes sistemas
• Este modelo puede
combinarse con otros
modelos de procesos de
desarrollo
Metodologías para el desarrollo ágil del software.
Actualmente los negocios operan en un entorno global que cambia rápidamente.
Tienen que responder a nuevas oportunidades y mercados, condiciones
económicas cambiantes y la aparición de productos y servicios competidores. El
software es parte de casi todas las operaciones de negocio, por lo que es
fundamental que el software nuevo se desarrolle rápidamente para aprovechar
nuevas oportunidades y responder a la presión competitiva. Actualmente el
desarrollo y entrega de manera rápida son los requerimientos más críticos de los
sistemas. De hecho, muchas organizaciones están dispuestas a obtener una
pérdida en la calidad del software y en el compromiso sobre los requerimientos en
favor de una entrega rápida del software.

Los procesos de desarrollo del software basados en una completa especificación

de los requerimientos, diseño, construcción y pruebas del sistema no se ajustan al
desarrollo rápido de aplicaciones. Cuando los requerimientos cambian o se
descubren problemas con ellos, el diseño o implementación del sistema se tiene
que volver a realizar o probar. Como consecuencia, normalmente se prolonga en el
tiempo un proceso en cascada convencional y el software definitivo se entrega
mucho tiempo después al cliente con el que inicialmente se pactó. En un entorno de
negocios tan cambiante, esto puede causar verdaderos problemas. Para cuando
esté disponible el software, la razón original de su adquisición puede ser que haya
cambiado de forma radical que en realidad éste sea inútil. Dicha metodología
combina una filosofía y un conjunto de directrices de desarrollo. La filosofía busca
la satisfacción del cliente y la entrega temprana de software incremental, equipos
pequeños con alta motivación, métodos informales y una simplicidad general del
desarrollo. Los procesos de desarrollo rápido de software están diseñados para
producir software útil de forma rápida. Generalmente, son procesos interactivos en
los que se entrelazan la especificación, el diseño, el desarrollo y las pruebas.

Algunas de las metodologías agiles más usadas en la actualidad se describen a

continuación.

Programación Extrema (XP)

La programación extrema usa un enfoque orientado a objetos (véase el apéndice 2)

como paradigma preferido de desarrollo, y engloba un conjunto de reglas y prácticas
que ocurren en el contexto de cuatro actividades estructurales: planeación, diseño,
codificación y pruebas. La imagen a continuación ilustra el proceso XP y resalta
algunas de las ideas y tareas clave que se asocian con cada actividad estructural.
En los párrafos que siguen se resumen las actividades de XP clave.
Planeación. La actividad de planeación (también llamada juego de planeación)
comienza escuchando actividad para recabar requerimientos que permite que los
miembros técnicos del equipo XP entiendan el contexto del negocio para el software
y adquieran la sensibilidad de la salida y características principales y funcionalidad
que se requieren.

Diseño. El diseño XP sigue rigurosamente el principio MS (mantenlo sencillo). Un

diseño sencillo siempre se prefiere sobre una representación más compleja.
Además, el diseño guía la implementación de una historia conforme se escribe:
nada más y nada menos. Se desalienta el diseño de funcionalidad adicional porque
el desarrollador supone que se requerirá después.

Codificación. Después de que las historias han sido desarrolladas y de que se ha

hecho el trabajo de diseño preliminar, el equipo no inicia la codificación, sino que
desarrolla una serie de pruebas unitarias a cada una de las historias que se van a
incluir en la entrega en curso (incremento de software).

Pruebas. Ya se dijo que la creación de pruebas unitarias antes de que comience la

codificación es un elemento clave del enfoque de XP. Las pruebas unitarias que se
crean deben implementarse con el uso de una estructura que permita
automatizarlas (de modo que puedan ejecutarse en repetidas veces y con facilidad).

Otros modelos agiles de procesos

Como se dijo en la sección anterior, el más usado de todos los modelos ágiles de
proceso es la programación extrema (XP). Pero se han propuesto muchos otros y
están en uso en toda la industria.
Entre ellos se encuentran los siguientes:

• Desarrollo adaptativo de software (DAS)

• Scrum
• Método de desarrollo de sistemas dinámicos (MDSD)
• Cristal
• • Desarrollo impulsado por las características (DIC)
• Desarrollo esbelto de software (DES)
• Modelado ágil (MA)
• • Proceso unificado ágil (PUA)

Desarrollo adaptativo de software (DAS)

El desarrollo adaptativo de software (DAS) fue propuesto por Jim Highsmith como
una técnica para elaborar software y sistemas complejos. Los fundamentos
filosóficos del DAS se centran en la colaboración humana y en la organización
propia del equipo. Highsmith argumenta que un enfoque de desarrollo adaptativo
basado en la colaboración es “tanto una fuente de orden en nuestras complejas
interacciones, como de disciplina e ingeniería”. Él define un “ciclo de vida” del DAS
que incorpora tres fases: especulación, colaboración y aprendizaje.

Scrum

Scrum (nombre que proviene de cierta jugada que tiene lugar durante un partido de
rugby)13 es un método de desarrollo ágil de software concebido por Jeff Sutherland
y su equipo de desarrollo a principios de la década de 1990. En años recientes,
Schwaber y Beedle [Sch01a] han desarrollado más los métodos Scrum. Los
principios Scrum son congruentes con el manifiesto ágil y se utilizan para guiar
actividades de desarrollo dentro de un proceso de análisis que incorpora las
siguientes actividades estructurales: requerimientos, análisis, diseño, evolución y
entrega. Dentro de cada actividad estructural, las tareas del trabajo ocurren con un
patrón del proceso (que se estudia en el párrafo siguiente) llamado sprint. El trabajo
realizado dentro de un sprint (el número de éstos que requiere cada actividad
estructural variará en función de la complejidad y tamaño del producto) se adapta al
problema en cuestión y se define y con frecuencia se modifica en tiempo real por
parte del equipo Scrum. El flujo general del proceso Scrum se ilustra en la imagen.

Retraso: lista de prioridades de los requerimientos o características del proyecto

que dan al cliente un valor del negocio. Es posible agregar en cualquier momento
otros aspectos al retraso (ésta es la forma en la que se introducen los cambios). El
gerente del proyecto evalúa el retraso y actualiza las prioridades según se requiera.

Sprints: consiste en unidades de trabajo que se necesitan para alcanzar un

requerimiento definido en el retraso que debe ajustarse en una caja de tiempo14
predefinida (lo común son 30 días). Durante el sprint no se introducen cambios (por
ejemplo, aspectos del trabajo retrasado). Así, el sprint permite a los miembros del
equipo trabajar en un ambiente de corto plazo, pero estable.

Reuniones Scrum: son reuniones breves (de 15 minutos, por lo general) que el
equipo Scrum efectúa a diario. Hay tres preguntas clave que se pide que respondan
todos los miembros del equipo.
Método de desarrollo de sistemas dinámicos (MDSD)

El método de desarrollo de sistemas dinámicos (MDSD) es un enfoque de desarrollo

ágil de software que “proporciona una estructura para construir y dar mantenimiento
a sistemas que cumplan restricciones apretadas de tiempo mediante la realización
de prototipos incrementales en un ambiente controlado de proyectos”. La filosofía
MDSD está tomada de una versión modificada de la regla de Pareto: 80 por ciento
de una aplicación puede entregarse en 20 por ciento del tiempo que tomaría
entregarla completa (100 por ciento). El MDSD es un proceso iterativo de software
en el que cada iteración sigue la regla de 80 por ciento. Es decir, se requiere sólo
suficiente trabajo para cada incremento con objeto de facilitar el paso al siguiente.
Los detalles restantes se terminan más tarde, cuando se conocen los
requerimientos del negocio y se han pedido y efectuado cambios.

El consorcio ha definido un modelo de proceso ágil, llamado ciclo de vida MDSD,

que define tres ciclos iterativos distintos, precedidos de dos actividades adicionales
al ciclo de vida:

Estudio de factibilidad: establece los requerimientos y restricciones básicas del

negocio, asociados con la aplicación que se va a construir, para luego evaluar si la
aplicación es un candidato viable para aplicarle el proceso MDSD.

Estudio del negocio: establece los requerimientos e información funcionales que

permitirán la aplicación para dar valor al negocio; asimismo, define la arquitectura
básica de la aplicación e identifica los requerimientos para darle mantenimiento.

Iteración del modelo funcional: produce un conjunto de prototipos incrementales que

demuestran al cliente la funcionalidad. (Nota: todos los prototipos de MDSD están
pensados para que evolucionen hacia la aplicación que se entrega.) El objetivo de
este ciclo iterativo es recabar requerimientos adicionales por medio de la obtención
de retroalimentación de los usuarios cuando practican con el prototipo.

Diseño e iteración de la construcción: revisita los prototipos construidos durante la

iteración del modelo funcional a fin de garantizar que en cada iteración se ha hecho
ingeniería en forma que permita dar valor operativo del negocio a los usuarios
finales; la iteración del modelo funcional y el diseño e iteración de la construcción
ocurren de manera concurrente.

Implementación: coloca el incremento más reciente del software (un prototipo

“operacional”) en el ambiente de operación. Debe notarse que: 1) el incremento tal
vez no sea el de 100% final, o 2) quizá se pidan cambios cuando el incremento se
ponga en su lugar. En cualquier caso, el trabajo de desarrollo MDSD continúa y
vuelve a la actividad de iteración del modelo funcional.
Cristal

Alistar Cockburn [Coc05] creó la familia Cristal de métodos ágiles15 a fin de obtener
un enfoque de desarrollo de software que premia la “maniobrabilidad” durante lo
que Cockburn caracteriza como “un juego cooperativo con recursos limitados, de
invención y comunicación, con el objetivo primario de entregar software útil que
funcione y con la meta secundaria de plantear el siguiente juego”. Para lograr la
maniobrabilidad, Cockburn y Highsmith definieron un conjunto de metodologías,
cada una con elementos fundamentales comunes a todos, y roles, patrones de
proceso, producto del trabajo y prácticas que son únicas para cada uno. La familia
Cristal en realidad es un conjunto de ejemplos de procesos ágiles que han
demostrado ser efectivos para diferentes tipos de proyectos. El objetivo es permitir
que equipos ágiles seleccionen al miembro de la familia Cristal más apropiado para
su proyecto y ambiente.

El proceso unificado ágil (PUA)

El proceso unificado ágil (PUA) adopta una filosofía “en serie para lo grande” e
“iterativa para lo pequeño” a fin de construir sistemas basados en computadora. Al
adoptar las actividades en fase clásicas del PU concepción, elaboración,
construcción y transición, el PUA brinda un revestimiento en serie (por ejemplo, una
secuencia lineal de actividades de ingeniería de software) que permite que el equipo
visualice el flujo general del proceso de un proyecto de software. Sin embargo,
dentro de cada actividad, el equipo repite con objeto de alcanzar la agilidad y
entregar tan rápido como sea posible incrementos de software significativos a los
usuarios finales. Cada iteración del PUA aborda las actividades siguientes:

• Modelado. Se crean representaciones de UML de los dominios del negocio y el

problema. No obstante, para conservar la agilidad, estos modelos deben ser “sólo
suficientemente buenos” [Amb06] para permitir que el equipo avance.

• Implementación. Los modelos se traducen a código fuente.

• Pruebas. Igual que con la XP, el equipo diseña y ejecuta una serie de pruebas
para detectar errores y garantizar que el código fuente cumple sus requerimientos.

• Despliegue. Como en la actividad general del proceso que se estudió en los

capítulos 1 y 2, el despliegue en este contexto se centra en la entrega de un
incremento de software y en la obtención de retroalimentación de los usuarios
finales.

• Configuración y administración del proyecto. En el contexto del PUA, la

administración de la configuración incluye la administración del cambio y el riesgo,
y el control de cualesquiera productos del trabajo persistentes17 que produzca el
equipo.
Conclusión
En torno a todo lo que hemos visto nos damos cuenta que tanto las metodologías
tradicionales o clásicas como nos guste llamarlas y las metodologías agiles nos
ayudan de manera muy eficiente para trabajar en equipo dentro de las empresas.

Otro caso que dentro de la investigación me di cuenta es que las dos metodologías
nos ayudan con el mismo objetivo.

Bibliografía
Autor: Summerville, Ian Libro: Ingeniería de Software
Autor: Roger S. Pressmam, Ph.D. Libro: Ingeniería de Software un enfoque
practico