1. Fases
1.1. Concepcion
1.1.1. Suele ser la fase más corta del desarrollo, y no debería alargarse demasiado en el tiempo
1.1.2. Hitos
1.1.2.1. En éste hito, los involucrados evalúan el estado del proyecto. Debe estar de acuerdo en lo siguiente:
1.1.2.1.1. Acuerdo del Alcance.
1.1.2.1.2. Definición Inicial de Requerimientos.
1.1.2.1.3. Acuerdo del Plan.
1.1.2.1.4. Aceptación del Riesgo.
1.1.2.1.5. Aceptación de Proceso.
1.1.2.1.6. Viabilidad.
1.1.2.1.7. Plan del Proyecto.
1.2. Elaboracion
1.2.1. Durante esta fase deberían capturarse la mayoría de requisitos del sistema, aunque los objetivos principales son tratar los riesgos ya identificados y establecer y validar la base de la arquitectura
1.2.2. Hitos
1.2.2.1. En este hito, los involucrados evalúan el estado del proyecto. Ellos deben estar de acuerdo en la siguiente:
1.2.2.1.1. Estabilidad de la visión.
1.2.2.1.2. Estabilidad de la arquitectura.
1.2.2.1.3. Aceptación del riesgo.
1.2.2.1.4. Viabilidad.
1.2.2.1.5. Plan del Proyecto.
1.3. Construccion
1.3.1. DEFINICIÓN. Fase mas larga y la que completa la implementacion del sistema tomando como base la arquitectura obtenida durante la fase de elaboración. A partir de ella se añade las nuevas funcionalidades en distintas iteraciones esta fase concluye con el hito de la obtención de una funcionalidad completa lista para ponerla a trabajar en producción, también en esta fase es necesario trabajar alado del cliente para identificar sus necesidades paso a paso.
1.3.2. participacion activa del cliente y modelado inclusivo
1.3.2.1. La idea es que los clientes participen del modelado usar tecnicas y herramientas demasiado sencillas para esto
1.3.3. mostrar los detalles de casos de uso
1.3.3.1. usar diagramas de actividades UML en lugar de descripciones textuales
1.3.4. aplicar model storming para el diseño
1.3.4.1. se debe utilizar el modelado suficiente para resolver un unico requerimiento antes de implementarlo: puede resultar util realizar diagramas de secuencia UML, diagramas de clase UML, modelo de seguridad frente a amenazas, modelo de datos fisicos, no es necesario utilizar todas las tecnicas la utilidad o no de ellas depende del proyecto.
1.3.5. documentar las decisiones de diseño criticas
1.3.5.1. Se recomienda documentar aquellas decisiones que no resulten obvias y aquellas que puedan resultar interesantes para alguien en el futuro. Estas decisiones documentadas pueden considerarse como un comienzo para el documento general del sistema que se finaliza en la fase de transición.
1.3.6. HITO DE LA FASE DE CONSTRUCCION: CAPACIDAD OPERACIONAL INICIAL(IOC)
1.3.6.1. EN ESTE HITO LOS INVOLUCRADOS DEL PROYECTO DEBEN ESTAR DE ACUERDO EN:
1.3.6.1.1. Estabilidad del sistema
1.3.6.1.2. Involucrados preparados
1.3.6.1.3. Aceptación del riesgo
1.3.6.1.4. Aceptacion y Estimacion del Costo
1.3.6.1.5. plan del proyecto
1.4. Transición
1.4.1. DEFINICIÓN. En la fase final del proyecto se lleva a cabo el despliegue del producto en el entorno de los usuarios, lo que incluye la formación de estos
1.4.2. Disciplinas
1.4.2.1. modelado
1.4.2.1.1. Modelado por lluvia de ideas, finalice la documentacion general del sistema
1.4.2.2. implementacion
1.4.2.2.1. corrija defectos
1.4.2.3. pruebas
1.4.2.3.1. valide el sistema, valide la documentacion, finalice su modelo de pruebas
1.4.2.4. despliegue
1.4.2.4.1. finalice el paquete de entrega o liberacion, finalice la documentacion, anuncie el despliegue o liberacion, capacite el personal, libere el sistema en produccion
1.4.2.5. administración de la configuracion
1.4.2.5.1. poner todos los productos bajo el CM control
1.4.2.6. administracion del proyecto
1.4.2.6.1. administre el equipo de proyecto, Cerrar esta fase, inicie el proximo ciclo del proyecto
1.4.2.7. entorno
1.4.2.7.1. Establezca las operaciones y/o el ambiente de soporte recupere las licencias del sw
1.4.3. HITO DE LA FASE DE TRANSICION: LIBERACION DEL PRODUCTO
1.4.3.1. En este Hito los involucrados del proyecto deben estar de acuerdo en:
1.4.3.1.1. Aceptacion de los involucrados del negocio.
1.4.3.1.2. operaiones de aceptacion
1.4.3.1.3. Aceptacion del soporte
1.4.3.1.4. Aceptacion del costo estimado
2. Conceptos Generales
2.1. Disciplinas
2.1.1. Modelos
2.1.1.1. Entender el negocio, el problema y identificar una solución.
2.1.2. Aplicacion
2.1.2.1. Transformar modelos en en codigo ejecutable
2.1.3. Prueba
2.1.3.1. Evaluar los objetivos. Encontrar defectos, validar que funcione como fue diseñado
2.1.4. Despliegue
2.1.4.1. Planificar la entrega del sistema y ejecutar el plan
2.1.5. Gestion de la configuracion
2.1.5.1. Se administra el acceso a las actividades que se llevan a cabo en el proyecto. EJ: Seguimiento de versiones y el control de cambios
2.1.6. Gestion de proyectos
2.1.6.1. La meta es dirigir las actividades que se llevan a cabo en el proyecto. EJ: Gestión de riesgos, coordinación con el personal
2.1.7. Entorno
2.1.7.1. Su meta es apoyar esfuerzos para garantizar el proceso adecuado, la orientación y herramientas adecuadas.
2.2. Hitos
2.2.1. Un hito es una señal que marca el final de una fase
2.2.1.1. Hitos especificos
2.3. Entregables
2.3.1. Sistema
2.3.1.1. Software de trabajo, hardware y documentacion
2.3.2. Codigo Fuente
2.3.2.1. El codigo del programa
2.3.3. Suite de pruebas de regresion
2.3.3.1. Casos de prueba, pruebas de aceptación, de unidad.
2.3.4. Scripts de instalacion
2.3.4.1. Codigos para instalar el sistema en un ambiente de produccion
2.3.5. Documentacion del sistema
2.3.5.1. Documentacion para ayudar al usuario a trabajar con el y facilitar la actualizacion de los usuarios
2.3.6. Notas
2.3.6.1. Se resumen las novedades de cada actualizacion
2.3.7. Modelado de requerimientos
2.3.7.1. Describe los requisitos que el sistema debe cumplir para poder ejecutarse
2.3.7.1.1. oportunidades de automatizacion
2.3.7.1.2. Modelos de procesos del negocio
2.3.7.1.3. Reglas del negocio
2.3.8. Modelo de diseño
2.3.8.1. Describe el diseño del sistema
2.3.8.1.1. Modelo de despliegue.
2.3.8.1.2. Modelo de objetos
2.3.8.1.3. Modelo de datos fisicos
3. Que es?
3.1. Introduccion
3.1.1. Desarrollado en septiembre del 2005 como versión simplificada del RUP
3.1.1.1. En la disciplina de Modelado reúne: -Modelado de Negocio -Ingeniería de Requisitos -Análisis y Diseño
3.1.1.2. -Desarrollo dirigido por pruebas -Modelado Ágil -Gestión de Cambios Ágiles -Refactorización de Base de Datos
3.1.2. AUP esta dirigido especialmente a la gestión de riesgos proponiendo priorizar elementos con alto riesgo
3.2. Principios
3.2.1. El personal sabe lo que está haciendo.
3.2.1.1. Se proporcionan enlaces a muchos de los detalles, pero no obliga a aquellos que no lo deseen el conocerlos.
3.2.2. Simplicidad.
3.2.2.1. Toda documentación se describe en un de forma concisa
3.2.3. Agilidad.
3.2.3.1. Basado el los 12 principios del Manifiesto Ágil
3.2.3.1.1. 1. satisfacer al cliente con la entrega temprana y continua de software con valor. 2. que los requisitos cambien, incluso en etapas tardías del desarrollo 3. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, 4. Los responsables de negocio y los desarrolladores trabajamos juntos
3.2.4. Centrarse en actividades de alto valor.
3.2.4.1. Centra su atención en actividades que son esenciales para el de desarrollo
3.3. Caracteristicas
3.3.1. Iterativo e incremental
3.3.1.1. Dividida en fases y estas a su vez, dividida en una serie de iteraciones que ofrecen un incremento del producto.
3.3.2. Dirigido por los casos de uso
3.3.2.1. para así capturar los requisitos funcionales y definir los objetivos de las iteraciones.
3.3.3. Centrado en la arquitectura
3.3.3.1. Por involucrar los aspectos estáticos y dinámicos más significativos del sistema,
3.3.3.2. Actúa como vista del diseño
3.3.3.3. Muestra una perspectiva completa y describiendo los elementos más importantes.
3.3.4. Enfocado en los riesgos
3.3.4.1. Para disminuir la posibilidad de fallo en las iteraciones.
3.3.4.2. Para identificar los riesgos en una etapa temprana del ciclo de vida
3.3.5. Ciclo de Vida del Proceso Unificado de Desarrollo
4. Roles
4.1. DBA Ágil
4.1.1. trabaja de manera colaborativa con los integrantes del equipo del proyecto
4.1.1.1. diseñar
4.1.1.2. probar
4.1.1.3. brindar soporte a los diferentes esquemas de datos.
4.2. Modelador Ágil
4.2.1. Persona que crea y desarrolle modelos realizados con herramientas CASE
4.3. Implementador
4.3.1. responsable de poner Y disponer el sistema en los ambientes
4.3.1.1. pre-producción
4.3.1.2. producción.
4.4. Desarrollador
4.4.1. Es quien escribe código.
4.4.1.1. realiza pruebas
4.4.1.2. construye el software.
4.5. Administrador del proyecto
4.5.1. Administra los miembros de los equipos de trabajo
4.5.2. coordina las interacciones con los involucrados,
4.5.3. planea, administra y dispone recursos,
4.5.4. prioriza actividades y mantiene el equipo enfocado.
4.6. Examinador
4.6.1. Evalúa los productos del proyecto
4.7. Administrador de pruebas
4.7.1. responsable del éxito de las pruebas
4.7.1.1. planificar la administración de las pruebas
4.7.1.2. planifica las actividades de calidad