INTRODUCCIÓN Y OBJETIVO DE LA CLASE
El día 17 de noviembre del 2014 se planteó en clase una investigación rápida y una demostración de lo aprendido mediante la socialización por parte de los alumnos todo lo investigado, es decir que aquel día se realizó una metodología de enseñanza bastante practica que en lo personal me permitió asumir que los compañeros de clases guardaran de forma permanente el conocimiento socializado por ellos mismos.
En este entrada el blog les mencionare acerca del proceso unificado ágil que es el tema que me toco investigar y compartir en clases.
MARCO TEÓRICO
Agile Unified Process (AUP) es una versión simplificada del Rational Unified Process (RUP) desarrollado por Scott Ambler (Waters. 2008). Se describe un simple, fácil de entender enfoque para el desarrollo de software de aplicaciones de negocio utilizando técnicas y conceptos ágiles y aún así se mantiene fiel a el RUP. El AUP se aplica técnicas ágiles incluyendo el desarrollo guiado por pruebas (TDD), Agile Modeling (AM), la gestión del cambio ágil, y refactorización de base de datos para mejorar la productividad.
En 2011 el PUA representó uno por ciento de todas las Metodologías Ágiles utilizados(State of Agile Development. 2011).En 2012, la AUP fue reemplazado por Disciplinado Agile Entrega (DAD). Desde entonces el trabajo ha dejado de evolucionar PUA. Es una versión simplificada del Rational Unified Process (RUP). En él se describe un simple, fácil de entender enfoque para el desarrollo de software de aplicaciones de negocio utilizando técnicas y conceptos ágiles y aun así se mantiene fiel a la RUP. He tratado de mantener el Agile UP tan simple como sea posible, tanto en su planteamiento como en su descripción. Las descripciones son simples y al punto, con enlaces a los detalles (en la web) si usted las quiere. El enfoque se aplica técnicas ágiles incluyen el desarrollo de pruebas (TDD), Agile Model Driven Desarrollo (AMDD), gestión del cambio ágil, y refactorización de base de datos para mejorar su productividad.
La Figura 1 muestra el ciclo de vida de la PUA. Lo primero que notarás es que las disciplinas han cambiado. En primer lugar, la disciplina Modelo abarca disciplinas modelado de negocio, requisitos y Análisis y Diseño de la PUA. Modelo es una parte importante de la política de uso aceptable, como se puede ver, pero no domina el proceso – usted desea permanecer ágil mediante la creación de modelos y documentos que son lo suficientemente apenas bueno. En segundo lugar, la configuración y la disciplina de Gestión del Cambio es ahora la disciplina Gestión de la Configuración. En el desarrollo ágil de sus actividades de gestión del cambio son típicamente parte de sus esfuerzos de gestión de requisitos, lo cual es parte de la disciplina del modelo.
ITERATIVO:
Disciplinas se llevan a cabo de manera sistemática, la definición de las actividades que realizan los miembros del equipo de desarrollo para construir, validar y desplegar software de trabajo que responda a las necesidades de sus grupos de interés. Las disciplinas son:
MODELO. El objetivo de esta disciplina es entender el negocio de la organización, el dominio del problema siendo abordado por el proyecto, y para identificar una solución viable para hacer frente al dominio del problema.
IMPLEMENTACIÓN. El objetivo de esta disciplina es transformar su modelo (s) en código ejecutable y para llevar a cabo un nivel básico de las pruebas, en las pruebas de unidad en particular.
Test. El objetivo de esta disciplina es llevar a cabo una evaluación objetiva para garantizar la calidad. Esto incluye encontrar defectos, validar que el sistema funciona tal como fue diseñado, y verificar que se cumplen los requisitos.
DESPLIEGUE. El objetivo de esta disciplina es planificar para la entrega del sistema y ejecutar el plan para que el sistema disponible para los usuarios finales.
GESTIÓN DE CONFIGURACIÓN . El objetivo de esta disciplina es para administrar el acceso a sus artefactos del proyecto. Esto incluye no sólo el seguimiento de versiones de artefactos en el tiempo, sino también el control y la gestión de los cambios a los mismos.
GESTIÓN DE PROYECTOS. El objetivo de esta disciplina es dirigir las actividades que lleva a cabo el proyecto. Esto incluye los riesgos de gestión y dirección de personas (la asignación de tareas, seguimiento del progreso, etc.), y la coordinación con las personas y los sistemas fuera del alcance del proyecto para asegurarse de que está entregado a tiempo y dentro del presupuesto.
AMBIENTE. El objetivo de esta disciplina es apoyar el resto del esfuerzo por garantizar que el proceso adecuado, orientación (normas y directrices) y herramientas (hardware, software, etc.) están disponibles para el equipo, según sea necesario.
¿Si usted adopta la PUA?
Si quieres algo en entre XP y RUP tradicional, un proceso que es ágil aún explícitamente incluye actividades y artefactos que usted está acostumbrado, entonces es probable que la AUP. Muchas organizaciones son recelosos de XP, ya que parece ser demasiado clara: XP no muestra explícitamente cómo crear algunos de los artefactos que la administración quiere ver. Esta es una actitud lamentable porque XP es un gran proceso. En el otro extremo del espectro se encuentra RUP, que la gestión parece que me encanta, pero los desarrolladores parece receloso de debido a la gran cantidad de artefactos. Esto también es lamentable porque el RUP tiene mucho que ofrecer, y se puede reducir a algo bastante útil (que es exactamente lo que IBM Rational se lo recomienda). Las tierras AUP entre los dos, la adopción de muchas de las técnicas ágiles de XP y otros procesos ágiles aún conserva algo de la formalidad de la RUP(Universidad Union Bolivariana. 2015 )
CONCLUSIÓN
En cuanto respecta a PUA o proceso unificado agil puede concluirse que es el conjunto de metodologías agiles que permiten una optimización adecuada a un proyecto de software que se puede apreciar en conceptos matemáticos sobre un eje en un plano cartesiano. En cuanto respecta a la metodología de clase puedo concluir con una felicitación a la docente por tener esa magnífica idea de enseñanza.
REFERENCIAS
Waters, J. 2008. Agile lands role in games and business software. The Register. Retrieved 2009-08-03.
State of Agile Development Survey Results, 2011. VersionOne. Formato HTML. Disponible en: http://www.versionone.com/state_of_agile_development_survey/2011/
Pressman, R., Ingeniería de software, un enfoque práctico, sexta edición. Editorial McGrawHill, México, año 2010 (Libro digital). Capítulo 3
Universidad Unión Bolivariana. 2015. Proceso Unificado Ágil .Consultado 14 de Feb. Disponible en: http://ingenieriadesoftware.mex.tl/63758_AUP.html
Ingeniería de Software 