a06v7n2 (1)

of 8
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Categories
Published
Description:
  R EVISTA   DE  I NVESTIGACIÓN   DE  S ISTEMAS   E  I NFORMÁTICA F ACULTAD   DE  I NGENIERÍA   DE  S ISTEMAS   E  I NFORMÁTICA   ISSN 1815-0268 (versión impresa) U NIVERSIDAD  N ACIONAL  M AYOR   DE  S AN  M ARCOS  ISSN 1816-3823 (versión electrónica) RISI 7(2), 2010 Mejorando las debilidades de RUP  para la gestión de proyectos Lenis Wong Portillo, Fernando Torres Sánchez Universidad Nacional Mayor de San MarcosFacultad de Ingeniería de Sistemas e Informáticalwongpuni@yahoo.com.pe, ftorres@avatarsrl.com RESUMEN El objetivo del presente artículo es identicar las debilidades que tiene la metodología Rational Unied Process (RUP) para la Gerencia de Proyectos de Software. RUP es un proceso de desa -rrollo de software cuyas características son: iterativo, conducido por casos de uso, centrado en la arquitectura y gestión temprana de riesgos. Es un proceso bidimensional, eso quiere decir que está compuesta por fases y disciplinas. Se hace un estudio para identicar y clasicar las debilidades del RUP usando el Diagrama Causa-Efecto. Una vez identicados los problemas, se plantea una solución buscando las mejores prácticas para la gestión de proyectos en el PMBOK. El PMBOK posee un framework para gestión de proyectos, procesos principales que son agrupados en nueve áreas de conocimientos, y muestra el nivel de actividad de cada proceso basado en el tiempo. Palabras clave:  RUP, PMBOK, PMI, framework, disciplinas, iteración, artefactos ABSTRACT The objective of this article is to identify the weaknesses in the methodology Rational Unied Pro -cess (RUP) for Project Management Software. RUP is a software development process whose cha-racteristics are: iterative, use case driven, architecture-centric and early management of risks. It is a two-dimensional process that means is comprised of phases and disciplines. A study is to identify and classify the weaknesses of RUP using Cause-Effect Diagram. Having identied the problems, we propose a solution looking for the best practices for project management in the PMBOK. The PMBOK has a project management framework, major processes are grouped into nine areas of knowledge and shows the level of activity of each process based on time. Keywords:  RUP, PMBOK, PMI, framework, disciplines, iteration, artifacts (49-56) Improving the weaknesses of RUP for Project Management   50 Revista de Ingeniería de Sistemas e Informática vol. 7, N.º 2, Julio - Diciembre 2010 1. INTRODUCCIÓN Este trabajo describe brevemente el proceso de desa-rrollo de software RUP, el Framework de Gestión de Proyectos PMBOK, se identican y clasican las de -bilidades que tiene RUP para la Gestión de Proyecto haciendo uso del diagrama Causa-Efecto, luego se buscan las mejores prácticas del PMBOK y se plantea la solución.RUP es un proceso de desarrollo de software y junto con el Lenguaje Unicado de Modelado UML, cons -tituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. Asimismo, provee a través de un entorno WEB: Lineamientos, plantillas, workows y he -rramientas, que guían una implementación efectiva de las mejores prácticas de la industria del software.La Guía del PMBOK proporciona pautas para la direc- ción de proyectos tomados de forma individual. Dene la dirección de proyectos y otros conceptos relacionados, y describe el ciclo de vida de la dirección de proyectos y los procesos conexos. La dirección de proyectos es la aplicación de conocimientos, habilidades, herramientas y técnicas a las actividades del proyecto para cumplir con los requisitos del mismo. Se logra mediante la aplicación e integración adecuadas de los 42 procesos de la direc-ción de proyectos, agrupados lógicamente, que confor-man los cinco grupos de procesos y las nueve Áreas de Conocimiento de la Dirección de Proyectos. 2. FUNDAMENTACIÓN TEÓRICA2.1. RUP 2.1.1. Descripción El Proceso Unicado Racional (Rational Unied Pro -cess en inglés, habitualmente resumido como RUP) es un proceso de desarrollo de software y junto con el Lenguaje Unicado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, im-plementación y documentación de sistemas orientados a objetos. El RUP no es un sistema con pasos rmemente esta -blecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización.También se conoce por este nombre al software desa-rrollado por Rational, hoy propiedad de IBM, el cual in-cluye información entrelazada de diversos artefactos y descripciones de las diversas actividades. Está incluido en el Rational Method Composer (RMC), que permite la personalización de acuerdo a necesidades.Originalmente se diseñó un proceso genérico y de do- minio público, el Proceso Unicado, y una especica - ción más detallada, el Rational Unied Process, que se vendiera como producto independiente. 2.1.2. Características RUP es un proceso de ingeniería de software. Se des-cribe entre otras cosas como: – Centrado en una arquitectura. – Guiado por casos de uso (requerimientos). – Iterativo e incremental. – Enfrenta riesgos. – Controla cambios. – Soportado por varias herramientas.  – Se dene como una “Base de Conocimiento” Fue concebido por los tres “amigos”: Booch, Rumbaugh y Jacobson. Provee a través de un entorno WEB: Li- neamientos, plantillas, workows y herramientas, que guían una implementación efectiva de las Mejores Prácticas de la industria del software. 2.1.3. Estructura 2.1.3.1. Estructura Estática Eje vertical, representa workows nucleares, que agru -pan actividades por su disciplina. Las disciplinas son las siguientes: Concepción Elaboración Construcción Transición Fases Iteraciones Figura N.° 1.  RUP.  51 Mejorando las debilidades de RUP para la gestión de proyectosRISI 7(2), 49 - 56 (2010)  – Disciplinas del proceso: – Modelo del negocio – Requerimientos – Análisis y Diseño – Implementación – Prueba – DistribuciónDisciplinas para soporte  – Conguración y administración de Cambios  – Administración del proyecto  – Denición del ambiente 2.1.3.2. Estructura Dinámica Eje horizontal, representa el tiempo y muestra el ciclo de vida del proceso tal y como se desenvuelve en cada iteración. Está compuesta por las siguientes fases: 2.1.3.2.1. Concepción En esta fase se dene el alcance del proyecto y el de -sarrollo de los casos del negocio. Se identican todas las entidades externas con las que se trata (actores) y se dene la interacción a un alto nivel de abstracción: Identicar todos los casos de uso, describir algunos en detalle.La oportunidad del negocio incluye: Criterios de éxito, Identicación de riesgos, Estimación de recursos nece -sarios y un Plan de las fases incluyendo hitos. 2.1.3.2.2. Elaboración En esta fase se planica el proyecto, especica las características, focaliza los detalles del análisis del dominio del problema y dene los cimientos de la ar  -quitectura.Se desarrolla un plan de proyecto.Se eliminan los elementos de mayor riesgo para el de-sarrollo exitoso del proyecto.Se tiene una Visión de “una milla de amplitud y una pulgada de profundidad” porque las decisiones de ar-quitectura requieren una visión global del sistema. 2.1.3.2.3. Construcción Construye el producto, desarrollando a detalle el diseño y produciendo el código.En esta fase todas las componentes restantes se desa-rrollan e incorporan al producto.Todo es probado en profundidad. El énfasis está en la producción eciente y no ya en la creación intelectual.Puede hacerse construcción en paralelo, pero esto exi- ge una planicación detallada y una arquitectura muy estable. Figura N.° 2.  Estructura Dinámica y Estática de RUP  52 Revista de Ingeniería de Sistemas e Informática vol. 7, N.º 2, Julio - Diciembre 2010 2.1.3.2.4. Transición Implementa el producto a su comunidad de usuarios.El objetivo es traspasar el software desarrollado a la comunidad de usuarios.Una vez instalado surgirán nuevos elementos que im-plicarán nuevos desarrollos (ciclos). 2.2. PMBOK 2.2.1. Descripción PMI es la Organización internacional orientada a la di-fusión y determinación de las mejores prácticas de ges-tión de proyectos. En este afán, produce documentos y prácticas generalmente aceptadas de dirección y de gestión de proyectos.EL PMBOK es una Guía de los Fundamentos para la Dirección de Proyectos, es una norma reconocida en la profesión de la dirección de proyectos. Es uno de los más importantes documentos publicados en la actualidad por el Project Management Institute (PMI). Por norma se hace referencia a un documento formal que describe normas, métodos, procesos y prácticas establecidos. Al igual que en otras profesiones, como la abogacía, la medicina y las ciencias económicas, el conocimiento contenido en esta norma evolucionó a partir de las buenas prácticas reco-nocidas por profesionales dedicados a la dirección de pro-yectos, quienes contribuyeron a su desarrollo.La Guía del PMBOK proporciona pautas para la direc- ción de proyectos tomados deforma individual. Dene la dirección de proyectos y otros conceptos relaciona-dos, y describe el ciclo de vida de la dirección de pro-yectos y los procesos conexos. El Project Management Institute (PMI) considera la norma como una referencia fundamental en el ámbito de la dirección de proyectos para sus certicaciones y programas de desarrollo profesional.En su carácter de referencia fundamental, esta norma no está completa ni abarca todos los conocimientos. Se trata de una guía, más que de una metodología. Se pueden usar diferentes metodologías y herramientas para implementar el marco de referencia. 2.2.2. ¿Qué es un proyecto?  Un proyecto es un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único. La naturaleza temporal de los proyectos indica un prin- cipio y un nal denidos. El nal se alcanza cuando se logran los objetivos del proyecto o cuando se termina el proyecto, porque sus objetivos no se cumplirán o no pueden ser cumplidos, o cuando ya no existe la nece-sidad que dio srcen al proyecto. Temporal no necesa- riamente signica de corta duración. En general, esta cualidad no se aplica al producto, servicio o resultado creado por el proyecto; la mayor parte de los proyectos se emprenden para crear un resultado duradero. Por ejemplo, un proyecto para construir un monumento na-cional creará un resultado que se espera que perdure durante siglos. Por otra parte, los proyectos pueden te-ner impactos sociales, económicos y ambientales que durarán mucho más que los propios proyectos. 2.2.3. Dirección de proyectos La dirección de proyectos es la aplicación de conoci-mientos, habilidades, herramientas y técnicas a las ac-tividades del proyecto para cumplir con los requisitos del mismo. Se logra mediante la aplicación e integra-ción adecuadas de los 42 procesos de la dirección de proyectos, agrupados lógicamente, que conforman los 5 grupos de procesos y las nueve Áreas de Conoci-miento de la Dirección de Proyectos . Los cinco grupos de procesos son: – Grupos de procesos de Iniciación  – Grupos de procesos de Planicación  – Grupos de procesos de Ejecución – Grupos de procesos de Seguimiento y Control – Grupos de procesos de CierreLas nueve Áreas de Conocimiento de la Dirección de Proyectos son: – Integración – Alcance – Tiempo – Costo – Calidad – Recursos Humanos – Comunicaciones – Riesgo – Adquisiciones
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks
SAVE OUR EARTH

We need your sign to support Project to invent "SMART AND CONTROLLABLE REFLECTIVE BALLOONS" to cover the Sun and Save Our Earth.

More details...

Sign Now!

We are very appreciated for your Prompt Action!

x