aos Semana CONTENIDOS, UNIDAD 1 UNIDAD 2 UNIDAD 3 mana 1 mana 2 mana 3 mana 4 man: mana 6 Semana 7 Semana 8 Semana 9 Semana 10 Semana 11 Semana 12 Semana 13 Semana 14 ‘Semana 15, Semana 16 ‘Semana 17 Conocimiento 1 Ejscucién de planes de accién corectives, Conocimiento 01 asus Ejecucién de planes de accién correctivos Integracién de Modelos y estandares en la Gestién de Proyectos. Comparacién entre el proceso unificado racional RUP y PMBOK, respecto de las mejores practicas en el PMBOK. Muchas organizaciones desean estandardizar sus précticas de la tecnologia de dotacién légica tan blen como sus précticas de la gerencia de proyecto (P.M.), y dos procesos bien conocidos estan disponibles para ayudar en ambas estas éreas, respectivamente. él proceso unificado Rational de 18M, elo RUP, las BEBP ofertas un acercamiento preceptivo para estandardizar en précticas de la tecnologia de dotacién légica las mejores, y la guia Ge Institute de la gerencia de proyecto (PMI) al cuerpa de gerencia de proyecto de Knowledge (PMBOK) ofrece Un acercamiento descriptivo pare estandardizar en practicas de la gerencia de proyecto las mejores, Descripcién de RUP RUP es un proceso de la tecnologia de dotacién légica que describe quién hace lo que, cuando, y cémo en un proyecto del desarrollo y del despliegue del software, Tiene las caracteristicas de ser utlizar-caso conducido, arquitecture-céntrico, riesgo-conducido, ¢ iterativa, Consideremos cada uno de estas caracteristicas importantes. A través de un proyecto dirigida por RUP, los Fequisitos funcionales expresados bajo la forma de casos del uso conducen la realizacién de la arquitectura ejecutable del uso, Ademas, el proceso se centre esfuerza del equipo en la construccién de los elementos del comportemiento y estructurales importantes del uso (los elementos arquitecténicos) antes de construir los elementos menos importantes, La mitigacién de los elementos mas importantes del riesgo conduce la definicién del alcance de las iteraciones tempranas de su cdo de vida. Y finalmente, RUP reparte el ciclo de vida del desarrollo del software en las iteraciones que producen versiones incrementales del uso ejecutable RUP pone précticas siguientes de la tecnologia de dotacién légica en ejecucién las mejores: Convertirte iterative Manejar los requisites Utllizar las arquitecturas componentes Modelo visualmente Verificar continuamente la [DBD calidad Manejar el cambio Dimensiones de RUP RUP pone las mejores précticas en ejecucién enumeradas arriba dentra de un proceso de dos dimensiones. Una dimensién describe “disciplinas” mientras que la otra dimensién describe “fases” dentro del ciclo de vida del proceso. £l cuadro 1 demuestra una representacién grifica de alto nivel del praceso, campus tus. duoe. bbe sway istiun/MIGRACION_2010/ESC._INFORMATICANCPISOY. stmaos Semana Disciplines Business Modeling Requirements Analysis & Design Implementation Test Deployment Configuration & Change Mgmt Project Management Environment Iterations Cuadro 1: Proceso unificado racional Disciplines de RUP Las disciplines de RUP se relacionan daramente con las sels mejores practicas, pero representan mas de cerca los papeles ingividuales de miembros o de sudgrupos dentro del equipo lleno del desarrollo, Estas disciplinas 1, El modelar del negodo 2: Requisitos 3. Andlisis y diseno 4. Puesta en practice 5. Prueba 6. Despliegue 7. Gerencia de proyecto 8. Ambiente 9. Gerencla de la configuracién y del cambio Dentro de RUP, cada disciplina se expresa en términos de papeles (quién realiza la tarea), actividades (cémo él realize estas tareas), y artefactos (quéla actividad alcanza). Un papel define al comportamiento y a las, Fesponsabilidades de un individuo, 0 2 grupo de individues, responsable de actividades y de artefactos, Una actividad es une tarea de la cual’ un papel es responsable y se puede pedir realizarse. Describe los pasos Fequerides para crear o para poner al dia un o mucho artefactos, Un artefacto es una entrada y/o una salida a tuna actividad. Otros elementos suplen estos tres elementos dominantes, tales como conceptos, pautas del trabajo, mentores de la herramienta, informes, pautas del artefacto, plantillas, y puntos de comprobacién El cuadro 2 demuestra una representacién gréfica de papeles, de artefactos, de actividades y de otros elementos suplementales de RUP. campus tus. duoe. bbe sway istiun/MIGRACION_2010/ESC._INFORMATICANCPISOY. stm anaos Semana Opanized by . Sp bisane Software Engineering Process ¢ D> Activity A ino gq veto =a vette Artifact Described by B Checkpoints Template Report Workflow Details Refers to Rates '5, Cuadro 2: Papeles, actividades, y artefactos Ciclo de vida de RUP Segin lo observado anterior, el ciclo de vida de RUP es iterative, y su dimensién del ciclo de vida se divide en cuatro fases 1. Inicio 2 Elaboraaén 3) Construccién 4) Transiaén Cada fase tiene un sistema bien definido de EE objetives y de extremos con un jalén importante. Los jalones en el final de cada fase so 1. Objetive del ciclo de vida en el final del inicio 2 Arguitectura del cio de vida en el final de la elaboracién 3. Capacidad operacional inicial en el extremo de la construccién 4. Lanzamiento de producto en el final de la transicén La meta del Inicio es definir el alcance del proyecto. La meta de la elaboradén es construlr una arquitectura ejecutable para el uso. La meta de la construccdn es a la came hacia fuera el esqueleto arquitecténico con a mayor parte de las capacidades del uso. ¥ finalmente, la meta de la transicén es a la transicién el uso a la comunidad del usuario final Cada fase de RUP se divide més a fondo en las iteradones, cada conclusién con un jalén de menor importancia La disciplina de RUP P.M. De as disciplinas de RUP conocidas anterior, nos referimos a la disciplina de la gerencia de proyecto (P-M.). E! RUP define el software P.M. pues el arte de objetivos competentes que balancean, del riesgo de manejo, y de superar apremios para entregar con éxito un producto que resuelva las necesidades de los clientes (és0s que requieren el software ser desarrollados) y de los usuarios del software La disciplina de RUP P.M. proporciona: 1. Un marco para manejar proyectos orientados al software 2. Pautas précticas para el planeamiento, proveyendo de personal, ejecutando, y supervisands proyectos 3. Un marco para el riesgo de manejo Esta disciplina se centra principalmente en los aspectos importantes de un proceso iterative del desarrollo: 1. Gerencia de riesgo 2. Planeando un proyecto iterativo, con el cido de vida y para una iteracién particular campus tus. duoe. bbe sway stun MIGRACION_2010/ESC._INFORMATICANCPIOSOY. 8 &.tm3. Supervisién de progreso de un proyecto iterativa, métrica Una comparacién de RUP/PMBOK Aqui debo precisar a varias éreas de la gerencia que se caigan fuera del alcance de la disciplina de RUP P.M., pero que son cubiertos por précticas de PMBOK 1. Gente de manejo: £1 emplear, entrenando, entrenando (mapas al drea del conocimiento de la gerencia de recurso humano del proyecto de PMBOK) 2. Presupuesto de manejo: El definir, asignando, y asi sucesivamente (mapas al érea del conocimiento de la gerentie del coste del proyecto de PMBOK) 3. Contratos de manejo: Con los surtidores y los clientes (mapas al 4rea del conocimiento de la gerencia de la consecucién del proyecto de PMBOK) Discutiremos éreas del conocimiento de PMBOK mds detalladamente mas adelante, Para ahora, observar simplemente que tres de las nueve areas del conocimiento de PMBOK no tienen ninguna disciplina equivalente Ge RUP: Gerencia de recurso humano, gerencia del coste, y gerencia de la consecucidn. No obstante el proceso de organizacién del planeamiento de la gerencia de reairso humano traz a los “papeles” el aspecto de RUP, Pues su propésito es identificar, documenter, y asignar papeles y responsabilidades del proyecto. Artefactos primarios de RUP P.M. Los artefactos numerosos se crean dentro de la disciplina de RUP P.M, Los artefactos principales se enumeran aqui, con el numero de los casos creados en un proyecto tipico demostrada entre paréntesis. # Plan de desarrollo del software (uno) © Plan de la garantia de calidad © Plan de la gerencia de riesgo © Plan de le medida Plan de le aceptacién del producto Plan de le resolucén del DIED problema Caso del negocio (uno) Plan de le iteracién (muchos) Gravamen de la iteracién (muchos) Gravamen del estado (muchos) Liste del riesgo (una) Orden de trabajo (muchas) Liste de las ediciones (una) Medidas del proyecto (muchas) Deseamos traz caracteristicas de RUP a ésas encontradas en el PMBOK, cavaré un pedacito més lejos en los artefactos enumerados arriba y caracterizaré cuatro de ellos: 1, Elplen de desarrollo del software es: + Creado en la fase del inicio + Puesto al dia a través de cido de vida * Contorneado como sigue © Descripcién del proyecto + Propésito, alcance y objetivos del proyecto + Asunciones y apremios 1 Deliverables del proyecto + Organizacién del proyecto + Estructura de organizacién 1 Interfaces externos + Papeles y responsabilidades + Proceso de la gerenca + Estimacones del proyecto + Plan del proyecto 1 Planes de la eracén + Supervisién y control del proyecto © Otros planes 1. El plan de la iteracién es Creado una vez porla iteracién = Contomeado como sigue ° Plan © LLG Recursos © Utlizar los casos © Criterios de la evaluacién 1. La visién es: + No un artefacto del P.M. (artefacto de los requisitos) + Creado en la fase del inicio + Contomeado como sigue Colacaciénaos Semana + Oportunidad de negocio + Dedaracién del problema + Dedaracién de posicién del producto © Descripciones del tenedor de apuestas y del usuario, + Descripciones del tenedor de apuestas + Descipciones del usuario + Necesidades del tenedor de apuestas Descripcién del producto Caracteristicas de producto Apremios La otra informacion 1. 81 caso del negocio es: * Creado en la fase del inicio * Contomeado como sigue: © Descripcién del producto ® Contexto del negocio © Objetivos del producto © Pronéstico financiero © Apremios Descripcién de PMBOK Ahora, demos vuelta a nuestra atencién al PMBOK. & PMBOK describe un sistema de las practicas generalmente aceptades que los médicos del P.M. pueden utilizar para manejar todos los tipos de proyectos, incluyendo proyectos del desarrollo del software y del despliegue. El PMBOK define un proyecto como “esfuerzo temporal emprendido para crear un producto 0 un servicio nico.” Define el P.M, como "el uso del conocimiento, de las habilidades, de las herramlentas, y de las técnicas para proyectar actividades para resolver requisitos del proyecto.” Dimensiones de PMBOK El PMBOK presenta précticas del P.M. en agrupaciones légicas. Una dimensién describe “reas del conocimiento” mientras que le otre dimensin describe los procesos de la gerenda de proyecto partidos en cinco grupos de proceso. &l cuadro 3 demuestra una representacién grafica de alto nivel de los 39 P.M, © goenonny 6 52 quatyaninee | 85 Gianyar 10: Frome Comers 103 peter [a0 nna Th Rak Pomt Mtegeent Secon Cuadro 3: Procesos de PMBOK P.M. Areas del conocimiento de PMBOK y grupos de proceso campus tus. duoe. bbe sway istiun/MIGRACION_2010/ESC._INFORMATICANCPISOY. stmLas reas del conocimiento de PM30K son: Gerencia de la integracién del proyecto Gerencia del alcance del proyecto Gerencia de tiempo del proyecto Gerencia del coste del proyecto Gerencia de la calidad del proyecto Gerencia de recurso humano del proyecto Gerencia de las comunicaciones del proyecto Gerencia de riesgo del proyecto Gerencia de la consecucion del proyecto Cada area del conocimiento de PMBOK describe conocimiento de la gerencia de proyecto y practica en términos de unos 0 mas procesos. Cada proceso se describe mas a fondo en términos de sus entradas, salidas, y herramientas y técnicas. Las entradas y las salidas son documentos o articulas documentable. Las herramientas y las técnicas Son mecanismos aplicados a las entradas para cear las salidas. Los 39 procesos se organizan en cinco grupos de proceso Iniciar procesos Procesos del planeamiento Ejecuter procesos Procesos que controlan Procesos de cierre El cuadro 4 demuestra una representacién grafica de los cinco grupos de proceso Initiating Processes Planning Processes Controlling Processes Executing Processes (arrows represent flow of information} Closing Processes Cuadro 4: Grupos de proceso de PMBOK Cielo de vida de PMBOK EI PMBOK no prescribe ningdn cido de vida espectfico para los proyectos. Especttica que el cielo de vida del proyecto se debe dividir en fases. El numero de fases varia basado en el alcance del proyecto y el dominio del Uso. Identifica que cuatro a nueve fases son tipicas para cualquier tipo de proyecto. Deliverables de PMBOK EI PMBOK define un entregable como “un producto tangible, comprobable del trabajo tal como un estudio de Viabilidad, un disefio del detalle, © prototipo de trabajo.” Algunos de los deliverables principales de PMBOK son. Plan del proyecto (con los detalles de soporte) Resultados del trabajo y peticones del cambio Las acciones correctivas y las lecciones aprendieron Carta del proyecto (con apremios y asuncones) El plan del proyecto es + Creado en proceso del desarrollo del plan del proyecto temprano en el ciclo de vida del proyecto + Puesto al dia a través del cido de vida del proyecto + Contomneado como sigue © Carta del proyecto © Acercamiento o estr © Dedlaracién del alcance + Objetivos del proyecto 1 Deliverables del proyecto gia de la gerencia de proyectoEstructura de la interrupcién del trabajo (WBS) Valoraciones de costes, horario y asignaciones de la responsabilidad para Deliverables Lineas de fondo de la medida para el alcance, el harario y el coste Jalones y fechas importantes de la blanco Personal requeride Otros planes. Consideremos una de las caracteristicas de! plan del proyecto: la carta del proyecto. La carta del proyecto tiene Sus propias caracteristicas, como sigue + Autoriza formalmente un proyecto + Creado en el proceso de Ia iniciacién temprano en el ciclo de vida del proyecto + Contomeado come sigue © Necesidades de! negodo Descripcién del producto MAPA DE UBICACION Estas en la Unidad 3 Estas en la Semana 03 04 05 06 O7 08 o9 10 11 12 13 14 45 16 17