Desarrollo e Implementacin de Sistemas

Agile Unified Process

AUP
Grupo 4

Apea Menor, Jos Flores Eugenio, Mara Mora Mallqui, Ivn Pea Palacios, Luis Quiroz Antn, Luis Zumaeta Meja, Doris

La Molina, 17 de Abril DEL 2012

CONTENIDO

INTRODUCCION ............................................................................................................... 2 MARCO TEORICO ............................................................................................................ 3 DEFINICION .................................................................................................................. 3 CARACTERISTICAS...................................................................................................... 3 PRINCIPIOS BASICOS .................................................................................................. 4 Fases.......................................................................................................................... 4 Flujos .......................................................................................................................... 8 Hitos ......................................................................................................................... 16 Roles ........................................................................................................................ 19 Roles ........................................................................................................................ 21

AGILE UNIFIED PROCESS............................................................................................. 26 PRINCIPIOS DE AUP .................................................................................................. 25 CONCLUSIONES ............................................................................................................ 26 Bibliografa ....................................................................................................................... 27

INTRODUCCION

A principios de las dcada del 90 surgi un enfoque que era revolucionario para su momento ya que iba en contra de la creencia de que mediante procesos altamente definidos se iba a lograr obtener software de alta calidad en un tiempo y costo determinado. El enfoque fue planteado por primera vez en 1991 por James Martin, que consista en un entorno de desarrollo altamente productivo, en el que participaban grupos pequeos de programadores utilizando herramientas que generaban cdigo de forma automtica tomando como entrada sintaxis de alto nivel. En general se considera que este fue uno de los primeros hitos en pos de la agilidad en los procesos de desarrollo.

Tras pasar cierto tiempo despus de este primer enfoque de agilidad en los procesos de desarrollo, en febrero del 2001 se reunieron miembros prominentes de la comunidad Software y adoptaron el nombre de metodologas giles, poco despus formando la Alianza gil, que es una organizacin sin fines de lucro, que promueve el desarrollo gil de aplicaciones.

Las metodologas giles nacen como una reaccin contra los mtodos de peso pesado, muy estructurados y estrictos, extrados del modelo de desarrollo en cascada. El proceso originado del uso del modelo en cascada era visto como burocrtico, lento degradante e inconsistente con las formas de desarrollo de software que realmente realizaban un trabajo eficiente.

MARCO TEORICO

DEFINICION

El Proceso Unificado gil (Agile Unified Process en adelante, AUP), se describe como una metodologa fcil de entender para el desarrollo de aplicaciones software de negocio, utilizando tcnicas giles y conceptos aun fieles a las de RUP, por lo tanto, es una versin simplificada del Rational Unified Process (RUP).

AUP, incluye o hace uso de las siguientes tcnicas giles: Test driven development (TDD). Agile model driven development (AMDD). Agile change management. Data base refactoring.

AUP, es una metodologa que tiene la adopcin de muchas de las tcnicas giles de la metodologa XP (Extreme Programming) y de las formalidades de RUP, teniendo como filosofa adaptarse a las necesidades del proyecto y no al contrario como lo planteado en las metodologas tradicionales. Esta metodologa, plantea un ciclo de vida iterativo, que se basa en la ampliacin y refinamiento sucesivo del sistema, mediante mltiples iteraciones con retroalimentacin cclica y adaptacin como elementos principales que dirigen para converger hacia un sistema adecuado.

CARACTERISTICAS

AUP abarca siete flujos de trabajo, cuatro de ingeniera y tres de apoyo: Modelado Implementacin, Prueba, Despliegue, gestin de Configuracin, Gestin de Proyectos y Ambiente. El modelado agrupa los tres primeros flujos de RUP (Modelamiento del negocio, Requerimientos y Anlisis y Diseo). Dispone de cuatro fases igual que RUP: Incepcin o Creacin, Elaboracin, Construccin y Transicin.

La AUP tambin se caracteriza por ser iterativa y adems incremental. Esto quiere decir que en el desarrollo de un proyecto importante, ste se divide en pequeos proyectos derivados. Esto sirve para tener el control de las pequeas partes y si sale cualquier problema solucionarlo lo antes posible. A cada pequea parte de la divisin del proyecto es una iteracin. Esto hace que vaya poco a poco, y todo vaya saliendo bien como he explicado antes. Cada parte adems, trata un conjunto de casos de uso. Esto lo que hace es que le da importancia a la funcionalidad que el sistema tiene que tener para satisfaces todo lo que el usuario necesite en un futuro. Los casos de Uso es el que orienta todas las actividades del desarrollo del producto software. Las ventajas de que sta metodologa sea iterativa es que existe una deteccin de los riesgos y peligros con anterioridad. Adems de una buena administracin del cambio en el transcurro de cada iteracin. Todas estas caractersticas hacen que exista un grado mayor de reutilizacin aparte de la experiencia para el grupo del desarrollo. La arquitectura que sigue esta metodologa es muy parecidaa la que contiene una construccin. Esto se refiere a que existen varios planos de ste, y esto sirve para tener una imagen global del proyecto antes de que empiece el desarrollo de ste. Adems existe una arquitectura en el software. El cual tiene diferentes modos dentro del sistema, estos son por ejemplo: funcional, dinmico, estructural. etc. Esta arquitectura del software es la base dnde se realiza el proyecto. Y adems, un punto importante, es la que define la forma del sistema.

PRINCIPIOS BASICOS

Para conocer un poco ms del AUP detallaremos las fases que tiene y los flujos que lo conforman:

FASES
Al igual que RUP, AUP tiene las 4 fases clsicas consecutivas y que acaban cada uno de estas, con hitos claros alcanzados:

Incepcin (Concepcin): El objetivo de esta fase es obtener una comprensin comn cliente equipo de desarrollo, del alcance del nuevo sistema y definir una o varias arquitecturas candidatas para el mismo. Las actividades que se desarrollan en esta fase son: 1. Definir el alcance del proyecto. Esto incluye la definicin, a un alto nivel, de qu es lo que har el sistema. Es igualmente importante tambin definir qu es lo que el sistema no va a hacer. Aqu se establecen los lmites desde dnde el equipo operar. Esto suele tomar la forma de una lista de caractersticas de alto nivel y / o el punto de casos de uso. 2. Estimacin de costos y calendario. En un nivel alto, el calendario y el costo del proyecto son estimados. Estimaciones generales son realizadas en iteraciones de fases posteriores, ms especficamente es implementado en las fases tempranas de la Elaboracin. Esto no debe ser interpretarse en el sentido de que todo el proyecto es planeado en este punto. Como en todas las planificaciones, estas tareas que van a ser completadas en un futuro cercano y son detalladas con ms precisin y con una gran confianza mientras que las tareas bajo la lnea son entendidas para ser estimadas con un que no es posible programar todo un proyecto, en su pistoletazo de salida con cualquier grado aceptable de confianza con un margen de error ms grande. Esto ha sido (finalmente) reconocido por la mayora de las industrias de que no es posible programar un proyecto completo de un slo con algn grado de aceptable de desacuerdo. Lo mejor que se puede hacer es planificar para el corto plazo y la precisar a largo plazo lo mejor que se pueda. 3. Definicin de Riegos. Los riegos del proyecto son primeramente definido aqu. La administracin del riego es importante en proyectos de AUP. La lista de riegos es una compilacin en vivo que cambiar en el tiempo cuando los riesgos sern identificados, mitigados, evitados y / o materializados o exterminados. El control de

riegos del proyecto, como los riegos de ms alta prioridad, manejan la programacin de las iteraciones. Los riegos ms altos, por ejemplo, son dirigidos en iteraciones ms tempranas que los riegos de menor prioridad. 4. Determinar la factibilidad del proyecto. Su proyecto debe tener sentido desde la perspectiva tcnica, operacional y del negocio. En otras palabras, debe ser capaz de crearlo, una vez desplegado debe ser capaz de correrlo, y debe tener un sentido econmico para hacer estos aspectos. Si su proyecto no es viable, este debe ser cancelado. 5. Preparar el entorno del proyecto. Esto incluye la reserva de reas de trabajo para el equipo. Solicitar el personal que se necesitar, obteniendo hardware y software que ser requerido inmediatamente y compilar una lista de hardware y software que ser necesitado despus. Adems, deber ajustar AUP para completar las necesidades de su equipo. Esta fase tiene como artefacto de trabajo el documento de definicin del proyecto. Elaboracin: El principal objetivo de la fase de elaboracin es probar la arquitectura del sistema a desarrollar. El punto es asegurar que el equipo puede desarrollar un sistema que satisfaga los requisitos, y la mejor manera de hacerlo que es la construccin de extremo a extremo del esqueleto de trabajo del sistema conocido como "prototipo de la arquitectura". Esto es en realidad un concepto pobre porque mucha gente piensa en deshacerse de los prototipos. En cambio, su significado es software funcional de alto nivel, el cual incluye varias casos de uso de alto riegos (a partir de un punto de vista tcnico) para demostrar que el sistema es tcnicamente factible. Es importante sealar que los requisitos no se especifican por completo en este punto. Se detallan slo lo suficiente como para entender los riesgos de la arquitectura y para asegurar que exista una comprensin de los alcances de cada requerimiento para que la planificacin posterior se puede llevar a cabo. Los riegos de la Arquitectura son identificados y priorizados durante la Elaboracin. Hacer frente a los riesgos de arquitectura puede adoptar varias formas: investigacin en un sistema similar(s), en una estacin de pruebas, un prototipo de trabajo, etc. En la mayora de los casos, un prototipo que muestra la arquitectura se ha completado. Su nivel de la arquitectura del sistema tambin deber reflejar su arquitectura general de la empresa. Durante la Elaboracin, el equipo tambin se est preparando para la Fase de Construccin. Como el equipo gana una mano en la arquitectura del sistema, ellos comienzan con la creacin del ambiente propicio para la Construccin mediante la compra de hardware, software y herramientas. Las personas son dirigidas desde la perspectiva de la Administracin del Proyecto; los recursos son solicitados o contratados. Los planes de comunicacin y la colaboracin se finalizan (especialmente importantes si el equipo debe estar fsicamente separado). Para salir o cerrar la fase de Elaboracin el equipo tiene que pasar el hito de la Arquitectura del Ciclo de Vida (LCA). Los principales puntos que se abordan con este hito es la de si el equipo ha demostrado que tienen un prototipo de trabajo de extremo a extremo que muestra que el equipo tiene una estrategia viable para construir el sistema y

que los interesados estn dispuestos a seguir financiando el proyecto. Si el equipo pasa esta etapa del proyecto, pasa a la Fase de Construccin, de lo contrario el proyecto puede ser re-dirigido o cancelado. En esta fase manejaremos ms artefactos de trabajo como el modelo de dominio, el modelo de procesos, el modelo funcional de alto nivel y la arquitectura bsica.

Construccin:El objetivo de la fase de Construccin consiste en desarrollar el sistema hasta el punto en que est listo para la pre-produccin de pruebas. En las etapas anteriores, la mayora de los requisitos han sido identificados y la arquitectura del sistema se ha establecido. El nfasis es priorizar y comprender los requerimientos, modelado que ataca una solucin y, a luego, la codificacin y las pruebas del software. Si es necesario, las primeras versiones del sistema se desarrollan, ya sea interna o externamente, para obtener los comentarios de los usuarios. Para salir de la fase de Construccin su equipo debe pasar el hito de la Capacidad Operativa Inicial (IOC). El principal problema aqu es si la versin actual del sistema est preparado para entrar en la pre-produccin de su entorno de prueba para el sistema y las pruebas de aceptacin. Si el equipo pasa esta etapa el proyecto pasa a la fase de Transicin, de lo contrario puede ser re-dirigido o cancelado.

Transicin:La fase de Transicin se enfoca en liberar el sistema a produccin. Deben hacerse pruebas extensivas a lo largo de esta fase, incluyendo las pruebas beta. Una buena afinacin del proyecto tiene lugar aqu incluyendo el retrabajo dirigido a los defectos significantes (su usuario puede escoger aceptar la existencia de algunos defectos conocidos en la versin actual). El tiempo y esfuerzo necesarios en la Transicin vara de un proyecto a otro. Shrinkwrapped software supone la fabricacin y distribucin de software y documentacin. Sistemas internos son generalmente ms simples de desplegar que sistemas externos. Los sistemas de alta visibilidad puede requerir pruebas beta extensiva por grupos pequeos antes de liberarse a la poblacin ms grande. La liberacin de un nuevo sistema de marca puede traer consigo la compra y configuracin de hardware mientras se actualiza un sistema existente que tambin puede traer una conversin de datos y una coordinacin exhaustiva con la comunidad de usuarios. Cada proyecto es diferente.

FLUJOS
El proceso AUP, establece un modelo ms simple que el planteado en RUP, por lo que rene enuna nica disciplina: el modelado de negocio, requisitos y anlisis y diseo. El resto dedisciplinas coinciden con las restantes de RUP, a continuacin se describe las disciplinasconsideradas por AUP:

Modelado:Se busca entender el negocio de la organizacin, el problema de dominio que seabordan en el proyecto, y determinar una solucin viable.

Implementacin:Consiste en transformar los modelos o modelo en cdigo ejecutable yrealizar un nivel bsico de las pruebas, en particular Unit testing.

Pruebas:Se busca realizar una evaluacin objetiva para garantizar la calidad. Esto incluye labsqueda de defectos, validar que el sistema funciona tal como est establecido, yverificando que se cumplan los requisitos.

Despliegue:Consiste en la elaboracin de un plan para la entrega del sistema y ejecutar elplan para que el sistema est a disposicin de los usuarios finales.

Gestin de Configuracin: Consiste en administrar el acceso a los artefactos del proyecto. Esto incluye no slo el seguimiento de las versiones de los artefactos en el tiempo, sinotambin el control y la gestin de los cambios de estos.

Gestin del Proyecto:Consiste en dirigir las actividades que se llevan a cabo dentrodel proyecto. Esto incluye la gestin de riesgos, la direccin de personas (la asignacin detareas, el seguimiento de los progresos, etc.), y de coordinacin con el personal y lossistemas fuera del alcance del proyecto para asegurarse de que el software final seaentregado a tiempo y dentro del presupuesto.

Ambiente: Es un soporte para el resto de los esfuerzos para garantizar un proceso adecuado,orientacin (normas y directrices), y herramientas (hardware, software, etc.) estndisponibles para el equipo segn sea necesario.

Grficos Descriptivos de los Flujos de Trabajo de AUP

MODELADO El objetivo de esta disciplina es entender el negocio de la organizacin, el problema de dominio que se abordan en el proyecto, y determinar una solucin viable para resolver el problema de dominio. Flujo de trabajo

IMPLEMENTACION El objetivo de esta disciplina es transformar su modelo (s) en cdigo ejecutable y llevar a cabo un nivel bsico de las pruebas, en particular, la unidad de prueba.

Flujo de trabajo

PRUEBAS El objetivo de esta disciplina es ejecutar una objetiva evaluacin para asegurar la calidad. Esto incluye la deteccin de defectos, validaciones de que el sistema funciona como fue diseado, y verificar que se cumplan los requerimientos. Flujo de Trabajo

DESPLIEGUE El objetivo de esta disciplina es planificar la entrega del proyecto de desarrollo y ejecutar el plan, para dejar disponible el sistema al usuario final. Flujo de trabajo

ADMINISTRACION DE LA CONFIGURACION La meta de esta disciplina es manejar el acceso a sus productos de trabajo de proyecto. Esta no slo incluye el rastreo de versiones del trabajo del producto en el tiempo, sino que tambin el control y administracin de los cambio estos productos.

Flujo de Trabajo

ADMINISTRACION DEL PROYECTO El objetivo de esta disciplina es dirigir las actividades a lo largo del proyecto. Esto incluye la administracin del riesgo, administracin del personal (asignacin de tareas, rastreo del progreso, etc.), y coordinacin con personas y sistemas fuera del alcance del proyecto para asegurar su liberacin a tiempo y dentro del presupuesto. Flujo de Trabajo

ENTORNO El objetivo de esta disciplina es soportar el resto del esfuerzo asegurando que el proceso apropiado, las guas (normas y directrices), y herramientas (hardware y software) estn disponibles para cuando el equipo las necesite. Flujo de Trabajo

HITOS:
Hay cuatro hitos en AUP. En cada uno de estos hitos, los cuales sealan el final de la fase, usted debera considerar tener una "revisin de hitos" que verifique que su equipo de trabajo est cumpliendo satisfactoriamente con los criterios de hitos. Los cuatro hitos son:

Hito de la Fase de Inicio: Objetivos del Ciclo de Vida

En ste hito, los involucrados evalan el estado del proyecto. Debe estar de acuerdo en lo siguiente:

Acuerdo del Alcance. Los interesados llegan a un acuerdo sobre el alcance del proyecto. Definicin Inicial de Requerimientos. Existe un acuerdo en que el conjunto correcto de requisitos han sido capturados, en un nivel alto, y hay un entendimiento comn de esos requisitos. Acuerdo del Plan. Los involucrados llegan a un acuerdo con el costo inicial y la estimacin del cronograma. Aceptacin del Riesgo. El riesgo ha sido identificado, evaluado y se han abordado estrategias aceptables para controlarlos. Aceptacin de Proceso. La Metodologa de Proceso Unificado gil (AUP, por sus siglas en ingls) ha sido inicialmente adoptado y aceptado por todas las partes. Viabilidad. El proyecto tiene sentido desde la perspectiva tcnica, operacional y del negocio. Plan del Proyecto. Existen adecuados planes para la siguiente fase (Elaboracin). Cumplimiento del Portafolio. El alcance del proyecto encaja bien en su organizacin general del portafolio de proyectos?

Hito de la Fase de Elaboracin: Arquitectura del Ciclo de Vida

En este hito, los involucrados evalan el estado del proyecto. Ellos deben estar de acuerdo en la siguiente:

Estabilidad de la visin. La visin del proyecto ha sido estabilizada y es realista. Estabilidad de la arquitectura. Est de acuerdo en que la arquitectura est estable y es suficiente para satisfacer los requerimientos. La arquitectura ha sido prototipada apropiadamente para ser direccionada con los riesgos de la arquitectura principales. Aceptacin del riesgo. El riesgo ha sido evaluado para asegurar que ha sido apropiadamente entendido, documentado y que se han desarrollado estrategias para manejarlo como aceptable. Viabilidad. El proyecto aun tiene sentido desde la perspectiva tcnica, operacional y del negocio. Plan del Proyecto. Plan de iteracin detallado para las prximas iteraciones de la etapa de Construccin, as como un plan de proyecto de alto nivel ya elaborado. Cumplimiento de la organizacin. La arquitectura del sistema refleja las realidades de la arquitectura de la empresa?

Hito de la fase de Construccin: Capacidad Operacional Inicial

En este hito, los involucrados del proyecto deben estar de acuerdo en:

Estabilidad del Sistema. El software y la documentacin de soporte son aceptables (estable y madura) para implementar el sistema a los usuarios. Involucrados preparados. Los involucrados (y el negocio) estn listos para que el sistema sea implementado (aunque an necesiten entrenamiento). Aceptacin del riesgo. El riesgo ha sido evaluado para asegurar que ha sido apropiadamente entendido, documentado y que se han desarrollado estrategias para manejarlo como aceptable. Aceptacin y estimacin del costo. Los gastos son aceptables y las estimaciones razonables han sido calculadas y programadas para los costos futuros. Plan del proyecto. Plan de iteracin detallado para las prximas iteraciones de la etapa de Transicin, as como un plan de proyecto de alto nivel ya elaborado. Cumplimiento de la organizacin. El producto elaborado por el equipo cumplen con los estndares apropiados de la organizacin?

Hito de la Fase de Transicin: Liberacin del Producto

En este hito, los involucrados del proyecto deben estar de acuerdo en:

Aceptacin de los involucrados del negocio. Los involucrados del negocio estn satisfechos con el sistema y lo aceptan. Operaciones de aceptacin. Las personas se responsabilizan de operar el sistema una vez que este est en produccin y estn satisfechos con losprocedimientos y documentacin relevantes. Aceptacin del soporte. Las personas se responsabilizan del soporte del sistema una vez que este est en produccin y estn satisfechos con losprocedimientos y documentacin relevantes. Aceptacin del costo estimado. Los gastos actuales son aceptados, y las estimaciones razonables han sido hechas parar los costos futuros de produccin

ROLES:
Asuntos importantes por entender: 1. 2. 3. 4. Los roles pueden ser asumidos por varias personas. Una persona puede tomar varios roles. Un rol no es un puesto. Usted debe tratar de convertirse en un especialista general que domine una o ms especialidades (por ejemplo, administracin de base de datos, administracin de proyectos, entre otras), un conocimiento general de todo el proceso del software y una gran comprensin del dominio de sus labores.

ROL
DBA gil

DESCRIPCION
Un administrador de bases de datos (DBA) que trabaja de manera colaborativa con los integrantes del equipo del proyecto para disear, probar y brindar soporte a los diferentes esquemas de datos. Alguien que cree y desarrolle modelos, ya sean dibujos, tarjetas, o archivos complejos realizados con herramientas CASE, de manera colaborativa y evolutiva. Los modelos giles son apenas lo suficientemente buenos. Cualquier otra persona en otro rol distinto.

DISCIPLINAS(s)

Implementacin Modelado Implementacin Administracin de la Configuracin Administracin del Proyecto Administracin de la Configuracin Desarrollo Modelado Implementacin Desarrollo

Modelador gil

Cualquiera

Administrador de la configuracin Implementador Desarrollador

Un administrador de configuracin se encarga de proporcionar la infraestructura y crear el medio ambiente para el equipo de desarrollo. Un implementador es responsable de poner en disponer el sistema en los ambientes de preproduccin y produccin. Es quien escribe cdigo, realiza pruebas y construye el software.

Especialista proceso Administrador proyecto

del

Desarrolla, adapta y apoya el material de los procesos de la organizacin (descripcin de procesos, plantillas, guas, ejemplos, entre otros). Administra los miembros de los equipos de trabajo, crea relaciones con los involucrados, coordina las interacciones con los involucrados, planea, administra y dispone recursos, enmarca prioridades y mantiene el equipo enfocado.

Entorno Modelado Pruebas Desarrollo Administracin del Proyecto Pruebas Modelado Implementacin

del

Examinador Involucrado

Evala los productos del proyecto, inclusive "el trabajo en progreso", suministrando retroalimentacin al equipo de trabajo. Un involucrado es cualquiera que sea usuario directo, usuario indirecto, administrador de usuarios, administrador, miembro de equipo de operacin o soporte, desarrolladores que trabajan en otros sistemas que se integran o interactan con el sistema implementado, en fin todo aquel

que se vea afectado de una u otra forma con el proyecto.

Pruebas Desarrollo Administracin del Proyecto

Documentador tcnico

Administrador pruebas Equipo de pruebas Especialista herramientas

de

en

Es responsable de producir documentacin para los involucrados, tal como: materiales de capacitacin, documentacin de operaciones, documentacin de mantenimiento, y documentacin de usuario. El administrador de pruebas es el responsable del xito de las pruebas, incluye planificar la administracin, y promover las pruebas y las actividades de calidad. El equipo de pruebas es responsables de ejecutar las pruebas y documentar los resultados que proyecten. Es responsable de seleccionar, adquirir, configurar y brindar mantenimiento al equipo requerido.

Desarrollo

Pruebas Pruebas Entorno

ENTREGABLES
El Agile UP distingue entre: Entregable que absolutamente se debe producir como un producto permanente de trabajo del sistema. Otros productos de trabajo del proyecto que probablemente descartar porque no se quiere mantenerlos en el tiempo. Productos de trabajo de la organizacin que son mantenidos dentro de su departamento de TI y compartida a travs de proyectos. 1. Mantenga sus productos de trabajo tan simples y concisos como sea posible. 2. Usted necesita menos documentacin de la que cree. 3. Trabaje cerca de las personas con las cuales usted est creando el producto de trabajo para que haga slo lo que ellos necesitan. 4. Documentos giles son los suficientemente buenos para la tarea en cuestin. 5. Producir un documento es la peor forma de comunicar informacin, muchas personas paradas frente a una pizarra hablando es la mejor manera. 6. Use herramientas simples como una pizarra (antigua), hojas de papel, y wikis para modelar y capturar documentacin. 7. Considere adoptar las plantillas de cdigo abierto como base de partida para crear su propio trabajo. Estas tienen, probablemente ms de lo que usted necesita, pero son un buen comienzo.

Entregables Mnimos
El mnimo de entregables para un sistema bajo AUP es descrito, en orden prioritario, en la tabla siguiente:

Entregable Sistema

Descripcin

Sugerencias
Hay ms en su sistema que slo el software que se escribe. Siga las directrices de codificacin comn. Automatice sus pruebas. Ejectelas tan frecuentemente como sea posible, sobre todo cuando ocurre algn cambio.

El software de trabajo, el hardware y la documentacin para ser liberada a produccin. El cdigo de programa para su Cdigo fuente sistemas Suite de Pruebas Una coleccin de casos de prueba, y el cdigo para correrlas en una orden de Regresin adecuado. El suite de pruebas de regresin incluir un gran rango de pruebas, tomando en cuenta apruebas de aceptacin, unidad de pruebas, pruebas de sistema y muchas otras. Scripts de Cdigo para instalar su sistema su ambiente de pre-produccin.

Necesitar un script, o scripts, para instalarlo en un ambiente de

pre-produccin tan exacto como el de produccin. Probablemente deba desinstalar los scripts si su instalacin falla. La documentacin liberada como una Mantenga su documentacin tan Documentacin parte del sistema para ayudar al liviana como sea posible. del Sistema usuario al trabajar con l, y a los desarrolladores para mantenerlo actualizado. Integra potencialmente las operaciones, soporte, usuarios, y una documentacingeneral del sistema. Sus notas deben resumir "las buenas Una lista puntual es a menudo Notas cosas a saber" acerca de las suficiente. versiones actuales que se estn construyendo. Modelado de Describe los requisitos que su Su objetivo es entender y luego sistema debe cumplir. Consta de una construir lo que sus usuarios requerimientos variedad de productos de trabajo, quieren, no escribir montculos de incluyendo potencialmente apruebas documentacin. de aceptacin,oportunidades de No necesita mantener todos los automatizacin, modelos de aspectos para su modelo de procesos del negocio,reglas del requerimientos, slo la porcin negocio, modelo del dominio, modelo que resuma el alcance de su de la organizacin,glosario del sistema. proyecto, requerimientos Considere mantener: tcnicos, modelo de casos de uso, y Diagramas de Procesos del el modelo de interface de usuario. Negocio(s) el cual resume qu es su sistema. El glosario del proyecto. Cualquier otro requisito de productos, comopuntos de forma de los casos de uso, que todava no han sido implementados. Pruebas de aceptacin para requerimientos implementados (que son parte de su suite de pruebas de regresin). el diseo de su Mantenga su modelo tan simple Modelo de Diseo Describe sistema. Consta de una variedad de como sea posible, y descarte en productos de trabajo, incluye cuanto le sea posible una vez que potencialmente un modelo de haya extrado el valor de ellos. despliegue, un modelo de objetos, El mejor lugar para documentar un modelo de datos fsico (PDM), es en su unidad de un modelo de seguridad de pruebas y cdigo fuente. amenazas, un documento de Mantenga el documento de resumen del sistema, y un modelo de resumen del sistema y el modelo interface de usuario. fsico de datos para documentacin

Instalacin

permanente. Debe tambin mantener unos pocos diagramas de diseo detallados, tales como diagramas de secuenciao diagramas de las mquinas de estado.

Entregables del Negocio

Equipos de su empresa (por ejemplo, los arquitectos, administradores de base de datos, gestores del portafolio) a menudo proporcionan el seguimiento de la labor de productos para ayudar a orientar y facilitar los esfuerzos de su proyecto:

Entregable

Descripcin

Sugerencias

Modelo de la Representa el marco de trabajo, la red, la Documentar es bueno, pero configuracin de la liberacin, la participacin en un equipo de Arquitectura infraestructura tcnica de soporte y la proyecto son ms efectivos. del Negocio
infraestructura de dominio para la organizacin. Normas y directrices aplicables a todos Las Guas deben ser concisas, Orientacin los sistemas dentro de su organizacin, prcticas, y contienen ejemplos del incluida la codificacin de las directrices, realistas. Desarrollo la red de directrices, normas de datos, y del Negocio as sucesivamente. Normas y directrices que deben seguirse Orientacin de la dentro de su organizacin, incluyendo guas de desarrollo, guas de recursos Empresa humanos, guas de modelo, y gua de usabilidad. Estado de la Una declaracin de las estrategias que Misin de la deben seguirse para alcanzar los Visin Organizacin empresarial.

Visin de la Una declaracin del principal objetivo (s) Deben ser unos pocos, concretos, de una organizacin. puntuales. Lamentablemente, esto Empresa
es raramente el caso.

Guas de Normas y directrices para las actividades de gestin de personas-tales como la Recursos contratacin, promocin, transferencia, Humanos Guas de Modelado

capacitacin, educacin, etc. Describe las tcnicas, tales como Existencia de normas de estilo de convenciones de nomenclatura, las UML directrices de estilo de diseo, estilo e incluso la notacin de directrices sobre cmo los modelos deben ser organizados y documentados.

Arquitectura de Referencia

Un enfoque de la arquitectura diseado y probado para usarse en un dominio particular, junto con el soporte del producto para habilitar su uso; Esto frecuentemente provee una base por crear una arquitectura de aplicacin.

Software funcional con un suite de pruebas y una documentacin general es una buena forma para empaquetar una arquitectura de referencia. Los arquitectos de la empresa deben ayudar al equipo a entender y luego aplicar la arquitectura de referencia.

Guas de Normas y directrices para el desarrollo de la interfaz de usuario de un sistema y Usabilidad

para determinar su uso efectivo.

AGILE UNIFIED PROCESS

PRINCIPIOS DE AUP

El personal necesita saber lo que est haciendo: La gente no va a leer la documentacin de los procesos en detalle, sino que quieren una orientacin de alto nivel y/o formacin de vez en cuando.

Simplicidad: Todo se describe concisamente utilizando unas pginas, no miles de ellas.

Agilidad: El ajuste a los valores y principios de La Alianza gil.

Centrarse en actividades de alto valor: La atencin se centra en las actividades que en realidad lo requieren, no en todo el proyecto.

Herramienta de la independencia: Usted puede usar cualquier conjunto de herramientas que desea con el AUP. Se sugiere utilizar las herramientas ms adecuadas para el trabajo, que a menudo son las herramientas simples o incluso herramientas de cdigo abierto.

Usted querr adaptar este producto para satisfacer sus propias necesidades: La metodologa AUP es un producto de fcil uso utilizando cualquier herramienta. No es necesario comprar una herramienta especial, o tomar un curso, para adaptar esta metodologa.

CONCLUSIONES

AUP se preocupa especialmente de la gestin de riesgos. Propone que aquellos elementos con alto riesgo obtengan prioridad en el proceso de desarrollo y sean abordados en etapas tempranas del mismo.

El proceso AUP establece un Modelo ms simple que el que aparece en RUP por lo que rene en una nica disciplina las disciplinas de Modelado de Negocio, Requisitos y Anlisis y Diseo. El resto de disciplinas (Implementacin, Pruebas, Despliegue, Gestin de Configuracin, Gestin y Entorno) coinciden con las restantes de RUP.

Si deseamos un mtodo gil entre XP y RUP, que incluya explcitamente las actividades y las herramientas a las cuales estamos acostumbrados, entonces la ms aconsejable es la AUP. XP, Scrum u otra metodologa gil no muestra explcitamente cmo crear algunos de las herramientas que la administracin quiere ver ,En el otro extremo del espectro est RUP una metodologa pesada y ms aconsejable para proyectos grandes que requieran documentacin detallada y con plazos de desarrollo mas amplios.

BIBLIOGRAFA

Amber, S. (2002). Agile Modeling: Effective Practices for EXtreme Programing and the Unified Process. DotinianO. (22 de Septiembre de 2011). Implementacin Adempiere en Ubuntu. Recuperado el 10 de Abril de 2012, de Metodologa AUP (Agile Unified Process Proceso Unificado Agil) para Implementacin del ERP ADempiere - Parte 1: http://ubuntu-adempiere.blogspot.com/2011/09/metodologia-aup-agile-unifiedprocess.html EcuRed. (2011). EcuRed. Recuperado el 10 de Abril de 2012, de Agile Unified Process: http://www.ecured.cu/index.php/Agile_Unified_Process JOCBaesm, G. (s.f.). Scrib. Recuperado el 08 de Abril de 2012, de Otras Metodologas giles: http://es.scribd.com/doc/84533226/Practica-3-AESM-MetodologiasAgiles#outer_page_15 Thomas Stober, U. H. (2009). Agile Software Development: Best Practices for Large Software Development Projects (1 Edition ed.). Springer. Universidad de Alicante, Otras Metodologas gil ,Recuperado el 3 de Junio de 2012 http://es.scribd.com/doc/84455024/aesm-p3 Ambysoft, The Agile Unified Process (AUP), Recuperado el 2 de Junio de 2012 http://www.ambysoft.com/unifiedprocess/agileUP.html