2.2.5 Emergentes (Luismi)

11
2.2.5 Metodologías emergentes Una metodología emergente es aquel que permite adaptar la forma de trabajo a las condiciones del proyecto. Ventajas: las metodologías emergentes motivan más a los equipos de trabajo. El principal beneficio del diseño orientado a objetos es que proporciona un mecanismo para formalizar modelos de la realidad. Evita malos entendidos de requerimientos entre el cliente y el equipo. El uso del modelo orientado a objetos alienta la reutilización, no solo del software, sino de diseños completos. Proporciona mejores resultados en los proyectos de alto riesgo. Desventajas: Problemas derivados de la comunicación oral. Falta de calidad Las metodologías emergentes son: ICONIX: El proceso ICONIX se define como un proceso de desarrollo de software práctico. Está entre la complejidad de RUP y la simplicidad y pragmatismo de XP, sin eliminar las tareas de análisis y diseño que XP no contempla. Es un proceso simplificado en comparación con otros procesos más tradicionales, que unifica un conjunto de métodos de orientación a objetos con el objetivo de abarcar todo el ciclo de vida de un proyecto. ICONIX presenta claramente las actividades de cada fase y exhibe una secuencia de pasos que deben ser seguidos. Además,

description

2.2.5 Emergentes (Luismi)

Transcript of 2.2.5 Emergentes (Luismi)

2.2.5 Metodologas emergentesUna metodologa emergente es aquel que permite adaptar la forma de trabajo a las condiciones del proyecto.Ventajas: las metodologas emergentes motivan ms a los equipos de trabajo. El principal beneficio del diseo orientado a objetos es que proporciona un mecanismo para formalizar modelos de la realidad. Evita malos entendidos de requerimientos entre el cliente y el equipo. El uso del modelo orientado a objetos alienta la reutilizacin, no solo del software, sino de diseos completos. Proporciona mejores resultados en los proyectos de alto riesgo.

Desventajas: Problemas derivados de la comunicacin oral. Falta de calidad

Las metodologas emergentes son:ICONIX:El proceso ICONIX se define como un proceso de desarrollo de software prctico. Est entre la complejidad de RUP y la simplicidad y pragmatismo de XP, sin eliminar las tareas de anlisis y diseo que XP no contempla.Es un proceso simplificado en comparacin con otros procesos ms tradicionales, que unifica un conjunto de mtodos de orientacin a objetos con el objetivo de abarcar todo el ciclo de vida de un proyecto. ICONIX presenta claramente las actividades de cada fase y exhibe una secuencia de pasos que deben ser seguidos. Adems, est adaptado a patrones y ofrece el soporte UML, dirigido por Casos de Uso y es un proceso iterativo e incremental.Las tres caractersticas fundamentales de ICONIX son: Iterativo e incremental: varias interacciones ocurren entre el modelo del dominio y la identificacin de los casos de uso. El modelo esttico es incrementalmente refinado por los modelos dinmicos. Trazabilidad: cada paso est referenciado por algn requisito. Se define la trazabilidad como la capacidad de seguir una relacin entre los diferentes artefactos producidos Dinmica del UML: la metodologa ofrece un uso dinmico del UML como los diagramas del caso de uso, diagramas de secuencia y de colaboracin.Las tareas que se realizan en la metodologa ICONIX son:1. Analisis de RequerimientosModelo del dominio (Diagrama de Clases)Prototipo rpidoModelo de Casos de Uso2. Analisis y Diseo PreliminarDescripcin de Casos de UsoDiagrama de Robustez 3. DiseoDiagrama de Secuencia 4. ImplementacinEscribir y Generar el Cdigo

ScrumScrum 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.Proceso: En Scrum un proyecto se ejecuta en bloques temporales cortos y fijos (iteraciones de un mes natural y hasta de dos semanas, si as se necesita). Cada iteracin tiene que proporcionar un resultado completo, un incremento de producto final que sea susceptible de ser entregado con el mnimo esfuerzo al cliente cuando lo solicite.

Fases:Planificacin de la iteracinEl primer da de la iteracin se realiza la reunin de planificacin de la iteracin. Tiene dos partes: Seleccin de requisitos (4 horas mximo). El cliente presenta al equipo la lista de requisitos priorizada del producto o proyecto. El equipo pregunta al cliente las dudas que surgen y selecciona los requisitos ms prioritarios que se compromete a completar en la iteracin, de manera que puedan ser entregados si el cliente lo solicita.Planificacin de la iteracin (4 horas mximo). El equipo elabora la lista de tareas de la iteracin necesarias para desarrollar los requisitos a que se ha comprometido. La estimacin de esfuerzo se hace de manera conjunta y los miembros del equipo se auto asignan las tareas.Ejecucin de la iteracinCada da el equipo realiza una reunin de sincronizacin (15 minutos mximo). Cada miembro del equipo inspecciona el trabajo que el resto est realizando (dependencias entre tareas, progreso hacia el objetivo de la iteracin, obstculos que pueden impedir este objetivo) para poder hacer las adaptaciones necesarias que permitan cumplir con el compromiso adquirido. En la reunin cada miembro del equipo responde a tres preguntas:Qu he hecho desde la ltima reunin de sincronizacin?Qu voy a hacer a partir de este momento?Qu impedimentos tengo o voy a tener?Durante la iteracin el Facilitador (Scrum Master) se encarga de que el equipo pueda cumplir con su compromiso y de que no se merme su productividad.Elimina los obstculos que el equipo no puede resolver por s mismo.Protege al equipo de interrupciones externas que puedan afectar su compromiso o su productividad.

Inspeccin y adaptacin El ltimo da de la iteracin se realiza la reunin de revisin de la iteracin. Tiene dos partes:Demostracin (4 horas mximo). El equipo presenta al cliente los requisitos completados en la iteracin, en forma de incremento de producto preparado para ser entregado con el mnimo esfuerzo. En funcin de los resultados mostrados y de los cambios que haya habido en el contexto del proyecto, el cliente realiza las adaptaciones necesarias de manera objetiva, ya desde la primera iteracin, replanificando el proyecto.Retrospectiva (4 horas mximo). El equipo analiza cmo ha sido su manera de trabajar y cules son los problemas que podran impedirle progresar adecuadamente, mejorando de manera continua su productividad. El Facilitador se encargar de ir eliminando los obstculos identificados.Ver en detalle las diferentes actividades, responsabilidades y herramientas en cmo funciona Scrum.

Programacin Extrema (XP)Es un enfoque de la ingeniera de software formulado por Kent Beck. Es una de las llamadas Metodologas giles de desarrollo de software ms exitosas de los tiempos recientes, nace como nueva disciplina de desarrollo de software.Caractersticas Se diferencia porque pone ms nfasis en la adaptabilidad. Software que funcione es ms importante que documentacin exhaustiva. La respuesta ante el cambio es ms importante que el seguimiento de un plan.

Los 4 valores de la metodologa XP

Simplicidad: Se simplifica el diseo para agilizar el desarrollo y facilitar el mantenimiento.Comunicacin: Para los programadores el cdigo comunica mejor cuanto ms simple sea.

Retroalimentacin (feedback): Al estar el cliente integrado en el proyecto, su opinin sobre el estado del proyecto se conoce en tiempo real.Coraje o valenta: Una de ellas es siempre disear y programar para hoy y no para maana.

Fases de la metodologa XP Fase I: Exploracin. Fase II: Planificacin de la Entrega. Fase III: Iteraciones. Fase IV: Produccin. Fase V: Mantenimiento. Fase VI: Muerte del Proyecto.Ventajas y desventajas de la metodologa XPVENTAJAS:Programacin organizada.Menor taza de errores.DESVENTAJAS:Es recomendable emplearlo solo en proyectos a corto plazo.ROLES XP1. Programador: Debe existir una comunicacin y coordinacin adecuada entre los programadores y otros miembros del equipo.2. Cliente: El cliente escribe las historias de usuario y las pruebas funcionales para validar su implementacin.3. Encargado de pruebas (Tester): El encargado de pruebas ayuda al cliente a escribir las pruebas funcionales.4. Encargado de seguimiento (Tracker): El encargado de seguimiento proporciona realimentacin al equipo en el proceso XP. Su responsabilidad es verificar el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, comunicando los resultados para mejorar futuras estimaciones.5. Entrenador (Coach): Es responsable del proceso global. Es necesario que conozca a fondo el proceso XP para proveer guas a los miembros del equipo de forma que se apliquen las prcticas XP y se siga el proceso correctamente.6. Consultor: Es un miembro externo del equipo con un conocimiento especfico en algn tema necesario para el proyecto. Gua al equipo para resolver un problema especfico.7. Gestor (Big Boss): Es el vnculo entre clientes y programadores, ayuda a que el equipo trabaje efectivamente creando las condiciones adecuadas. Su labor esencial es de coordinacin.

Proceso UnificadoEl Proceso Unificado de Desarrollo Software o simplemente Proceso Unificado es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura y por ser iterativo e incremental. El refinamiento ms conocido y documentado del Proceso Unificado es el Proceso Unificado de Rational o simplemente RUP.

CaractersticasIterativo e IncrementalEl Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto de cuatro fases denominadas Inicio, Elaboracin, Construccin y Transicin. Cada una de estas fases es a su vez dividida en una serie de iteraciones (la de inicio puede incluir varias iteraciones en proyectos grandes). Estas iteraciones ofrecen como resultado un incremento del producto desarrollado que aade o mejora las funcionalidades del sistema en desarrollo.Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que recuerdan a las definidas en el ciclo de vida clsico o en cascada: Anlisis de requisitos, Diseo, Implementacin y Prueba. Aunque todas las iteraciones suelen incluir trabajo en casi todas las disciplinas, el grado de esfuerzo dentro de cada una de ellas vara a lo largo del proyecto.Dirigido por los casos de usoEn el Proceso Unificado los casos de uso se utilizan para capturar los requisitos funcionales y para definir los contenidos de las iteraciones. La idea es que cada iteracin tome un conjunto de casos de uso o escenarios y desarrolle todo el camino a travs de las distintas disciplinas: diseo, implementacin, prueba, etc. El proceso dirigido por casos de uso es el rup. Nota: en UP se est Dirigido por requisitos y riesgos de acuerdo con el Libro UML 2 de ARLOW, Jim que menciona el tema.Centrado en la arquitecturaEl Proceso Unificado asume que no existe un modelo nico que cubra todos los aspectos del sistema. Por dicho motivo existen mltiples modelos y vistas que definen la arquitectura de software de un sistema. La analoga con la construccin es clara, cuando construyes un edificio existen diversos planos que incluyen los distintos servicios del mismo: electricidad, fontanera, etc.

Enfocado en los riesgosEl Proceso Unificado requiere que el equipo del proyecto se centre en identificar los riesgos crticos en una etapa temprana del ciclo de vida. Los resultados de cada iteracin, en especial los de la fase de Elaboracin deben ser seleccionados en un orden que asegure que los riesgos principales son considerados primero.

FasesInicioEn la fase de inicio se define el negocio: facilidad de realizar el proyecto, se presenta un modelo, visin, metas, deseos del usuario, plazos, costos y viabilidad.ElaboracinEn esta fase se obtiene la visin refinada del proyecto a realizar, la implementacin iterativa del ncleo de la aplicacin, la resolucin de riesgos altos, nuevos requisitos y se ajustan las estimaciones.ConstruccinEsta abarca la evolucin hasta convertirse en producto listo incluyendo requisitos mnimos. Aqu se afinan los detalles menores como los diferentes tipos de casos o los riesgos menores.TransicinEn esta fase final, el programa debe estar listo para ser probado, instalado y utilizado por el cliente sin ningn problema. Una vez finalizada esta fase, se debe comenzar a pensar en futuras novedades para la misma.

Bibligrafias:http://gerardocuevassaucedo.blogspot.mx/2013/04/metodologias-emergentes.htmlhttp://www.proyectosagiles.org/que-es-scrumhttp://fgaith2.blogspot.mxhttp://prezi.com/zjfb-05xyj5a/proceso-unificado-de-desarrollo-de-software/