Presentacion

Integrantes:
Jorge Javier Santos 118-4052
Jam Carlos Pimentel 116-3636
Scarlet Lebrón Ramos 219-5184
Milton Vicente 117-4653
Yamilka Peguero Ortiz 218-4616

Materia:
Ingeniería De Software

Tema:
Desarrollo Ágil

Profesor:
Gregorio De La Rosa
 Introducción

Como sabemos existen diferentes metodologías de desarrollo de software, las

mismas que se utilizan según los requerimientos de producto que se esté
realizando. Estas metodologías permiten seguir un conjunto de pasos que acerquen
cada vez más al objetivo de entregar un software totalmente funcional y a tiempo.

La metodología de desarrollo ágil busca desarrollar software a medida en el tiempo

o plazo establecido, para esto se realizan las actividades necesarias; la
característica más importante de un proceso ágil es que si los requerimientos
cambian en cualquier punto de desarrollo que se encuentre el proyecto, el equipo
debe estar preparado y adaptar el software a estos nuevos requerimientos.
Que es la agilidad.
La agilidad puede aplicarse a cualquier proceso del software. Sin embargo, para
lograrlo es esencial que éste se diseñe en forma que permita al equipo del proyecto
adaptar las tareas y hacerlas directas, ejecutar la planeación de manera que
entienda la fluidez de un enfoque ágil del desarrollo, eliminar todos los productos
del trabajo excepto los más esenciales y mantenerlos esbeltos, y poner el énfasis en
una estrategia de entrega incremental que haga trabajar al software tan rápido
como sea posible para el cliente, según el tipo de producto y el ambiente de
operación.
El desarrollo de software ágil requiere un cambio cultural en muchas empresas
porque se centra en la entrega limpia de piezas individuales o partes del software y
no en la aplicación completa.

Los principios básicos sobre los que se fundamenta el desarrollo ágil

son tres.
Individuos y procesos: en primer lugar, el capital humano prima ante los procesos
y herramientas. Por lo tanto, todo el proceso de desarrollo gira en torno a la
satisfacción de las necesidades concretas de los usuarios.
Cliente: por supuesto, la colaboración del cliente en todas y cada una de las etapas
que forman parte del proceso es muy importante. Por lo tanto, la relación entre el
cliente y el equipo de desarrolladores debe estar basada en la confianza mutua.
Adaptación: otro de los principios básicos es la capacidad de adaptación. Es
precisamente el mercado del Siglo XXI uno de los más variables y, además, los
cambios se producen a una velocidad cada vez mayor.

Metodologías De Desarrollo Ágil

Para que las metodologías de desarrollo ágil se puedan considerar como tal, es
requisito que cumplan estos cuatro aspectos. Por un lado, los individuos y las
interacciones que llevan a cabo entre ellos son más importantes que los propios
procesos y las herramientas. Por otro lado, prima que el software esté
implementado y funcionando. Además, es importante prestar atención a la
colaboración continua con el cliente. Y, por último, resulta esencial la respuesta
adecuada al cambio, adaptándose a las necesidades cambiantes, tanto del cliente
como del mercado. Es decir, hay que eliminar cualquier tipo de tarea que no sea
necesaria.
Se pueden diferenciar diferentes metodologías de desarrollo ágil, cada una de ellas
con sus propias características y ventajas. En función del proyecto a desarrollar y
de las necesidades concretas del equipo de desarrolladores, se puede optar por una
u otra.
Scrum: Scrum ofrece un marco de trabajo para el desarrollo, la entrega y el
mantenimiento de programas relativamente complejos. Se trata de una de las
metodologías de desarrollo ágil de software más demandadas en la actualidad.
eXtreme Programming: un entorno que permite el desarrollo de software
complejo y de gran calidad.
Kanban: Kanban es un sistema de información que controla el desarrollo de todos
los procesos necesarios en cada una de las etapas que implica la elaboración de un
proyecto de este tipo.
Test-Driven Development: Test-Driven Development supone un proceso de
desarrollo ágil basado en la repetición durante el ciclo de pruebas del software.

La agilidad y el costo de cambio

Es relativamente fácil efectuar un cambio cuando el equipo de software reúne los
requerimientos (al principio de un proyecto). El escenario de uso tal vez tenga que
modificarse, la lista de funciones puede aumentar, o editarse una especificación
escrita.
Los costos de hacer que esto funcione son mínimos, y el tiempo requerido no
perjudicará el resultado del proyecto. Pero ¿qué pasa una vez transcurridos algunos
meses? El equipo está a la mitad de las pruebas de validación (algo que ocurre
cuando el proyecto está relativamente avanzado) y un participante de importancia
solicita que se haga un cambio funcional grande. El cambio requiere modificar el
diseño de la arquitectura del software, el diseño y construcción de tres
componentes nuevos, hacer cambios en otros cinco componentes, diseñar nuevas
pruebas, etc. Los costos aumentan con rapidez, y no son pocos el tiempo y el
dinero requeridos para asegurar que se haga el cambio sin efectos colaterales no
intencionados.
Los defensores de la agilidad y afirman que un proceso ágil bien diseñado “aplana”
el costo de la curva de cambio, lo que permite que el equipo de software haga
cambios en una fase tardía de un proyecto de software sin que haya un efecto
notable en el costo y en el tiempo.
El lector ya sabe que el proceso ágil incluye la entrega incremental. Cuando ésta se
acopla con otras prácticas ágiles, como las pruebas unitarias continuas y la
programación por parejas (que se estudia más adelante, en este capítulo), el costo
de hacer un cambio disminuye. Aunque hay debate sobre el grado en el que se
aplana la curva de costo, existen evidencias que sugieren que es posible lograr una
reducción significativa del costo.
Si el cambio organizacional se implementara con el espíritu ágil, sería otra la
historia. Una de las metas en las empresas tradicionales es buscar un ahorro de
dinero, por lo que se buscan nuevos métodos, sin ver que reforzando los procesos
en las áreas se puede entorpecer el trabajo diario de las personas, esto afecta de
manera directa en la productividad.
Agilidad para reducir costos o cambiar a cualquier otro marco de trabajo, no es la
solución para tener empleados efectivos, aumentar la rentabilidad de una empresa
y ganar mercado. Estas prácticas heredadas de una era industrial están siendo cada
día más obsoleta. En la actualidad las empresas están dependiendo más de un
trabajo intelectual, y menos de un trabajo manual. Por esta razón no se pueden
aplicar las mismas técnicas para aumentar el rendimiento o productividad de los
empleados.

¿Qué es un proceso ágil?

Cualquier proceso del software ágil se caracteriza por la forma en la que aborda
cierto número de suposiciones clave acerca de la mayoría de proyectos de
software:
1. Es difícil predecir qué requerimientos de software persistirán y cuáles
cambiarán. También es difícil pronosticar cómo cambiarán las prioridades del
cliente a medida que avanza el proyecto.
2. Para muchos tipos de software, el diseño y la construcción están imbricados. Es
decir, ambas actividades deben ejecutarse en forma simultánea, de modo que los
modelos de diseño se prueben a medida que se crean. Es difícil predecir cuánto
diseño se necesita antes de que se use la construcción para probar el diseño.
3. El análisis, el diseño, la construcción y las pruebas no son tan predecibles como
nos gustaría (desde un punto de vista de planeación).
Dadas estas tres suposiciones, surge una pregunta importante: ¿cómo crear un
proceso que pueda manejar lo impredecible? La respuesta, como ya se dijo, está en
la adaptabilidad del proceso (al cambio rápido del proyecto y a las condiciones
técnicas). Por tanto, un proceso ágil debe ser adaptable.
Pero la adaptación continua logra muy poco si no hay avance. Entonces, un
proceso de software ágil debe adaptarse incrementalmente. Para lograr la
adaptación incremental, un equipo ágil requiere retroalimentación con el cliente
(de modo que sea posible hacer las adaptaciones apropiadas). Un catalizador eficaz
para la retroalimentación con el cliente es un prototipo operativo o una porción de
un sistema operativo. Así, debe instituirse una estrategia de desarrollo incremental.
Deben entregarse incrementos de software (prototipos ejecutables o porciones de
un sistema operativo) en periodos cortos de tiempo, de modo que la adaptación
vaya a ritmo con el cambio (impredecible). Este enfoque iterativo permite que el
cliente evalúe en forma regular el incremento de software, dé la retroalimentación
necesaria al equipo de software e influya en las adaptaciones del proceso que se
realicen para aprovechar la retroalimentación.

Principios de agilidad
La Alianza Ágil define 12 principios de agilidad para aquellos que la quieran
alcanzar:
1. La prioridad más alta es satisfacer al cliente a través de la entrega pronta y
continua de software valioso.
2. Son bienvenidos los requerimientos cambiantes, aun en una etapa avanzada del
desarrollo. Los procesos ágiles dominan el cambio para provecho de la ventaja
competitiva del cliente.
3. Entregar con frecuencia software que funcione, de dos semanas a un par de
meses, de preferencia lo más pronto que se pueda.
4. Las personas de negocios y los desarrolladores deben trabajar juntos, a diario y
durante todo el proyecto.
5. Hay que desarrollar los proyectos con individuos motivados. Debe darse a éstos
el ambiente y el apoyo que necesiten, y confiar en que harán el trabajo.
6. El método más eficiente y eficaz para transmitir información a los integrantes de
un equipo de desarrollo, y entre éstos, es la conversación cara a cara.
7. La medida principal de avance es el software que funciona.
8. Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores,
desarrolladores y usuarios deben poder mantener un ritmo constante en forma
indefinida.
9. La atención continua a la excelencia técnica y el buen diseño mejora la agilidad.
10. Es esencial la simplicidad: el arte de maximizar la cantidad de trabajo no
realizado.
11. Las mejores arquitecturas, requerimientos y diseños surgen de los equipos con
organización propia.
12. El equipo reflexiona a intervalos regulares sobre cómo ser más eficaz, para
después afinar y ajustar su comportamiento en consecuencia.
No todo modelo de proceso ágil aplica estos 12 principios con igual intensidad y
algunos eligen ignorar (o al menos soslayar) la importancia de uno o más de ellos.
Sin embargo, los principios definen un espíritu ágil que se mantiene en cada uno de
los modelos de proceso que se presentan en este capítulo.

Factores humanos

Los defensores del desarrollo de software ágil enfatizan la importancia de los

“factores personales”. Como dicen Cockburn y Highsmith: el proceso se adapta a
las necesidades de las personas y del equipo.
Listare algunas de las características que deben de tener aquellos miembros del
equipo de software que elaborarán las características aplicadas a la elaboración del
software.
Competencia. La "capacidad" incluye talento innato, habilidades específicas de
software y conocimiento general del proceso que el equipo ha elegido usar. Las
habilidades y el conocimiento de los procesos pueden y deben ser considerados por
todos los miembros de un equipo ágil.
Enfoque común. Los miembros del equipo Ágil realizan diferentes tareas y aportan
diferentes habilidades al proyecto, todos deben estar enfocados en el mismo
objetivo: brindar productividad al cliente dentro del marco de tiempo prometido.
Para lograr esto, el equipo también se enfocará en la adaptación continua para
asegurar que el proceso satisfaga las necesidades del equipo.
Colaboración. El desarrollo de software implica la evaluación, el análisis y el uso
de la información proporcionada al equipo de desarrollo; crear información que
ayude a todos los participantes a comprender el trabajo del grupo; y generar
información que aporte valor empresarial a los clientes. Para realizar estas tareas,
los miembros del equipo deben colaborar entre sí y con todos los participantes.
Habilidad para tomar decisiones. Cualquier buen equipo de desarrollo debe ser
libre de dirigir su propio destino. Esto significa que se otorga autonomía al equipo:
el poder de tomar decisiones sobre cuestiones de ingeniería y diseño.
Capacidad para resolver problemas difusos. Los administradores de software deben
ser conscientes de que los equipos ágiles a menudo se enfrentan a la incertidumbre
y se verán constantemente abrumados por el cambio. En algunos casos, el equipo
tiene que aceptar que el problema que están resolviendo ahora puede no ser el
problema que tendrán que resolver mañana.

El proceso 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 figura 3.2 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.
Escuchar lleva a la creación de algunas “historias” (también llamadas historias del
usuario) que describen la salida necesaria, características y funcionalidad del
software que se va a elaborar. Cada historia (similar a los casos de uso descritos en
el capítulo 5) es escrita por el cliente y colocada en una tarjeta indizada.
El cliente asigna un valor (es decir, una prioridad) a la historia con base en el valor
general de la característica o función para el negocio.

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.
Como el diseño XP virtualmente no utiliza notación y genera pocos, si alguno,
productos del trabajo que no sean tarjetas CRC y soluciones en punta, el diseño es
visto como un artefacto en transición que puede y debe modificarse continuamente
a medida que avanza la construcción. El objetivo del rediseño es controlar dichas
modificaciones, sugiriendo pequeños cambios en el diseño que “son capaces de
mejorarlo en forma radical”
Sin embargo, debe notarse que el esfuerzo que requiere el rediseño aumenta en
forma notable con el tamaño de la aplicación.
Un concepto central en XP es que el diseño ocurre tanto antes como después de
que comienza la codificación.
Rediseñar significa que el diseño se hace de manera continua conforme se
construye el sistema. En realidad, la actividad de construcción en sí misma dará al
equipo XP una guía para mejorar el diseño.
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).8 Una vez creada la prueba
unitaria, el desarrollador está mejor capacitado para centrarse en lo que debe
implementarse para pasar la prueba. No se agrega nada extraño (MS). Una vez que
el código está terminado, se le aplica de inmediato una prueba unitaria, con lo que
se obtiene retroalimentación instantánea para los desarrolladores.

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.

Principios del DSDM

Hay ocho principios de DSDM:
1- Concéntrese en la necesidad del negocio: Para aplicar con éxito este
principio a todas las decisiones del proyecto, el equipo de DSDM debe
entender a los profesionales de los negocios y comprometerse a entregar al
menos el subconjunto mínimo utilizable. Un caso de negocio válido debe ser
creado antes de que el proyecto comience, y apoyado continuamente.
2- Entregar a tiempo: Para asegurarse de que el proyecto se entregue a tiempo,
el equipo de DSDM está dividiendo el trabajo en incrementos, priorizando
 los requisitos del proyecto y protegiendo los plazos. Los objetivos del
proyecto a largo plazo se entregan a tiempo mediante la entrega puntual de
cada incremento, o Timebox.
3- Colabora: Los equipos de DSDM mejoran el rendimiento a través de una
colaboración exitosa con las partes interesadas adecuadas. Para asegurar un
trabajo efectivo, cada miembro del equipo debe estar facultado para tomar
decisiones dentro de sus áreas de especialización.
4- Nunca comprometa la calidad: La calidad deseada de los productos del
proyecto se acuerda al principio del proyecto mediante la definición de los
criterios de aceptación. Las pruebas, revisiones y documentación continuas
son cruciales para asegurar un nivel de calidad aceptable.
5- Construir gradualmente desde cimientos firmes: Antes de que se dediquen
recursos significativos a la entrega del proyecto, el DSDM construye una
sólida comprensión de los requisitos del proyecto y la solución propuesta.
Después de cada incremento del proyecto, o Timebox, es entregado, las
prioridades del proyecto y la viabilidad son reevaluadas.
6- Se desarrolla de forma iterativa: El proceso de desarrollo se divide en
iteraciones, o cajas de tiempo. Una parte crucial de cada iteración es la
demostración de los resultados y la retroalimentación del negocio. Este
enfoque permite al equipo de DSDM ajustarse a los cambios en las
necesidades del negocio.
7- Comunicarse de forma continua y clara: la metodología DSDM fomenta la
comunicación informal. Las necesidades de comunicación del proyecto se
satisfacen con las reuniones y los talleres diarios. Los prototipos de
soluciones se comparten con los interesados lo antes posible para
beneficiarse de la retroalimentación.
8- Demostrar control: Para asegurarse de que el proyecto sigue estando bajo el
control del director del proyecto, la planificación y el seguimiento de los
progresos son cruciales.

Requisitos previos para el uso de DSDM:

 Interactividad, los usuarios y los jefes de Desarrollo.
 Motivación y participación entre las partes (humanas) que integran el equipo.
 Intercambio de ideas o funcionalidades necesarias.

Situaciones No Aplicables Para DSDM

 No existe aceptación por parte de la dirección y otros empleados.
 Consiste en la falta de motivación y participación.
 Poca habilidad por parte de los integrantes del equipo.
 Si no hay apoyo entre cliente y proveedor.

Ventajas del DSDM

 La calidad del producto es mejorada a través de la participación de los

usuarios a lo largo del ciclo de vida del proyecto y la naturaleza iterativa del
desarrollo.
 DSDM asegura desarrollos rápidos.
 Reduce los costos de proyectos a través de las ventajas mencionadas
anteriormente
 Permite realizar cambios de forma fácil.
 Permite la reutilización de aplicación a través de los módulos existentes.

Desventajas del DSDM

 Se necesita una alta participación de los usuarios en el desarrollo, para evitar

que los desarrolladores asuman criterios que no son ciertos.
 No es una metodología de desarrollo común. El proceso es un tanto difícil de
comprender
 Conclusión

Dentro del desarrollo de un proyecto de software existen varios eventos que

pueden ocurrir, uno de estos es que los requerimientos funcionales que se
definieron en un principio para el producto cambien, esto trae consigo costos
inesperados en el proyecto y pérdida de tiempo. 

Las metodologías de desarrollo ágil buscan entregar software a medida y en el

tiempo o plazo establecido sin importar que los requerimientos cambien en
cualquier etapa del proyecto ya que utiliza el principio de la agilidad que es la
respuesta efectiva al cambio.
 Bibliografía

- Una buena parte del libro “Ingeniería del software. Un enfoque practico 7ma
edición”
- https://axarnet.es/blog/desarrollo-agil
- https://fabianthinking.wordpress.com/2019/09/10/que-es-la-
agilidad-realmente-un-tema-de-software/
- https://www.computerweekly.com/es/definicion/Desarrollo-de-
software-agil-o-Agile
- https://es.wikipedia.org/wiki/Desarrollo_
%C3%A1gil_de_software#:~:text=El%20desarrollo
%20%C3%A1gil%20de%20software,seg%C3%BAn%20la
%20necesidad%20del%20proyecto.