Comprendiendo RUP
Descargar como PPTX, PDF1 recomendación512 vistas
1. El Proceso Unificado de Rational (RUP) es un proceso de ingeniería de software que cubre todo el ciclo de vida del desarrollo de software. 2. RUP incorpora las mejores prácticas de la industria como el desarrollo iterativo e incremental, la administración de requisitos, el uso de arquitecturas basadas en componentes y el modelado visual del software. 3. El objetivo de RUP es producir software de alta calidad, dentro del presupuesto y el calendario planificado según las necesidades de los usuarios.
Comprendiendo RUP
- 2. ¿Qué es? Una vez más nos encontramos frente a un concepto, herramienta o moda en la administración de IT. El que ahora nos compete es RUP que viene del inglés: Rational Unified Process, que es el Proceso Unificado «Rational» y ésta última sigla no traducible por ser un nombre propio, en sí es una marca. Y se define como un Proceso de Ingeniería de Software. Sus creadores y comercializadores indican que este Proceso Unificado, reúne las mejores prácticas de la industria del Desarrollo de Software. Hay que tener en cuenta que: Rational, el logo de Rational y Rational Unified Process son marcas registradas de la Corporación de Software: Rational, en los Estados Unidos y en otros países. El objetivo según ellos indican de este «Proceso» es producir en un calendario, presupuesto y alta calidad predecibles acorde a las necesidades de los usuarios.
- 3. ¡Conceptos, conceptos, conceptos! ¿Mejores prácticas? Cuando se evalúan las actividades (métodos, procedimientos) «normados» que utiliza una empresa, institución, entidad o similar agrupación, que en comparación con el resto, resultan ser las mejores en la producción o prestación de un bien o servicio. ¿Cuáles son las mejores prácticas entonces que encierra RUP? 1. 2. 3. 4. 5. 6. Develop software iteratively. Manage requirements. Use component-based architectures. Visually model software. Continuously verify software quality. Control changes to software. Desarrollar Software de forma Iterativa. Administrar los requerimientos. Utilizar arquitecturas basadas en componentes. Modelado visual del Software. Verificación continua de la calidad del Software. Control del cambio de Software.
- 4. Desarrollo en forma Iterativa Iterativa significa que es de forma «repetida, reiterada, insistida, insistente o renovada», es decir como en un «loop» o «bucle». Pero esta buena práctica está complementada con la INCREMENTALIDAD de esas iteraciones.
- 5. Desarrollo en forma Iterativa, sus beneficios Los beneficios adquiridos de una programación que no se hace de una sola vez, más bien, se hace en varias fases presentables y comprobables, que van creciendo en madurez. Deberían ser: 1. 2. 3. 4. 5. 6. 7. 8. Los malos entendidos son evidentes de forma temprana en el ciclo de vida iterativo e incremental, cuándo aún es posible reaccionar a ellos. Además alienta a la retroalimentación del usuario, con lo que se lograría llegar el desarrollo al ideal esperado. El equipo de trabajo es forzado a enfocarse en aquellos aspectos que son realmente importantes para el proyecto. Y alejarse de aquellos que resultan en distractores que los alejan de los riesgos reales del proyecto. Las pruebas constantes permiten la definición asertiva del estatus del proyecto. Las inconsistencias entre lo requerido, lo diseñado y lo implementado son detectadas de forma temprana. La carga de trabajo en especial del grupo de pruebas es distribuida a lo largo del ciclo de vida del proyecto. El equipo pude aplicar la experiencia adquirida e irlos implementando continuamente en el proceso. Los participantes en el proyecto pueden obtener evidencia concreta del mismo avance a través del ciclo de vida que recorre de forma iterativa e incremental.
- 8. Administración de Requerimientos Los beneficios adquiridos de una programación que no se hace de una sola vez, más bien, se hace en varias fases presentables y comprobables, que van creciendo en madurez. Deberían ser: 1. 2. 3. 4. 5. 6. 7. 8. Los malos entendidos son evidentes de forma temprana en el ciclo de vida iterativo e incremental, cuándo aún es posible reaccionar a ellos. Además alienta a la retroalimentación del usuario, con lo que se lograría llegar el desarrollo al ideal esperado. El equipo de trabajo es forzado a enfocarse en aquellos aspectos que son realmente importantes para el proyecto. Y alejarse de aquellos que resultan en distractores que los alejan de los riesgos reales del proyecto. Las pruebas constantes permiten la definición asertiva del estatus del proyecto. Las inconsistencias entre lo requerido, lo diseñado y lo implementado son detectadas de forma temprana. La carga de trabajo en especial del grupo de pruebas es distribuida a lo largo del ciclo de vida del proyecto. El equipo pude aplicar la experiencia adquirida e irlos implementando continuamente en el proceso. Los participantes en el proyecto pueden obtener evidencia concreta del mismo avance a través del ciclo de vida que recorre de forma iterativa e incremental.
- 9. Arquitectura de Componentes(1) Una solución de IT, tiene distintos puntos de vista basado en el participante o actor que lo evalúa, así pues, un usuario tendrá una concepción de la solución informática, el programador tendrá otra y así sucesivamente. Indican pues, que la clave para conciliar estos puntos de vista de la solución, radica en la arquitectura que se empleará para la construcción (de la solución informática) . Y unidos los puntos de vista o expectativas (requisitos) de los participantes y/o actores con una programación iterativa e incremental son la mezcla idónea que fijará los objetivos revisables en cada iteración. Es decir, el horizonte está fijado por las definiciones funcionales que nacen de la fusión de las expectativas de cada participante del proyecto. La definición de una arquitectura te permite pues tomar decisiones sobre los siguientes aspectos: • • • • • Cómo está organizado el Sistema (o cómo se organizará). La selección de los elementos estructurales y sus interfaces por los cuales está compuesto el Sistema. El comportamiento, especificado por la colaboración de esos elementos. La composición de esos elementos estructurales y funcionales dentro de grandes y progresivos Sub Sistemas. El estilo de arquitectura que guía la organización: esos elementos, sus interfaces, su colaboración y su composición.
- 10. Arquitectura de Componentes(2) ¿Qué arquitecturas están basadas en el? …Desarrollo basado en componentes (CBD: Component-based development) … • • • • Component-based development (COM) , de Microsoft. The Object Management Group's (OMG). Common Object Request Broker Architecture (CORBA). Sun Micro-systems' Enterprise Java-Beans (EJB). El valor de una arquitectura de componentes, es que los mismos pueden ser reutilizados en distintas soluciones. Es decir, una solución puede estar disponible como módulo para las siguientes solicitudes.
- 11. Arquitectura de Componentes(2) ¿Qué arquitecturas están basadas en el? …Desarrollo basado en componentes (CBD: Component-based development) … • • • • Component-based development (COM) , de Microsoft. The Object Management Group's (OMG). Common Object Request Broker Architecture (CORBA). Sun Micro-systems' Enterprise Java-Beans (EJB). El valor de una arquitectura de componentes, es que los mismos pueden ser reutilizados en distintas soluciones. Es decir, una solución puede estar disponible como módulo para las siguientes solicitudes.
- 13. Modelado Visual del Software El modelo es la simplificación de la realidad y que presenta al Sistema desde una perspectiva. Construimos modelos de tal suerte que podamos entender mejor el Sistema que se está modelando y dado que no podemos comprender de forma completa lo complejo de los Sistemas o los Sistemas complejos. Modelar es importante puesto que esto permite a los desarrolladores, visualizar, especificar, construir y documentar la estructura y el comportamiento de la arquitectura del software. Y esto constituye un medio sin ambigüedad, que permitirá la comunicación hacia el resto del equipo.
- 15. Verificación continua de la Calidad del Software El no tener un programa de control de calidad del producto entregado, en este caso, software, generará a través del tiempo un costo más alto que si se le monitorease y corrigiese de forma iterativa. Los elementos que deberían monitorearse deberían ser: funcionalidad, eficiencia de la aplicación (presta el soporte que se supone al proceso del negocio) y eficiencia del Sistema (cómo la aplicación impacta a la eficiencia de ejecución de su entorno de IT). Esta verificación involucra el tener definidos Escenarios Clave (key scenario) que representarán aspectos funcionales del Sistema y que evidenciarán que la iteración y el desarrollar de forma incremental están cumpliendo con el objetivo de un avance significativo y asertivo del proyecto.
- 16. Control de Cambios Uno de los retos claves al trabajar con equipos de desarrolladores que se conforman en grupos que participan en distintas iteraciones del desarrollo, en distintitas versiones, productos y plataformas, es realizarlo de forma armónica, ordenada y disciplinada de manera que no reine el caos. Entonces la coordinación permitirá el empleo eficiente de los recursos basado en las prioridades y riesgos del proyecto. Entonces esta práctica de poder controlar los cambios de la mano con la iteración, permitirá el manejo del impacto derivado de los cambios y garantizar la trazabilidad de los mismos. Para ello es necesario un control entre iteración y versión entregable del proyecto.
- 18. RUP, sus tres entidades fundamentales. Trabajadores Actividades Artefactos • ¿Quién? • ¿Cómo? • ¿Hace qué?
- 20. RUP, sus tres entidades fundamentales… Que fundamentalmente es Quién hace qué y de qué manera… Trabajadores Flujo Actividades Artefactos Y el Flujo de trabajo (workflow que identifica el ¿Cuándo?)
- 21. RUP, en pocas líneas. 1. El Proceso Unificado de Rational, es el Proceso de Desarrollo de Software que cubre todo el ciclo de vida del Software en sí. 2. El producto de este proceso, resulta en una riqueza en conocimiento, siempre actualizado. 3. Así pues trae consigo una guía basada en varias técnicas, un acercamiento a la tecnología basada en objetos, en el desarrollo basado en componentes, el modelado bajo UML, la definición de una arquitectura, desarrollo iterativo y así sucesivamente. 4. No es un producto estático o congelado, más bien, es algo vivo en constante actualización. 5. Está basado en un proceso sólido de arquitectura y permite a una organización de desarrollo configurarlo y confeccionarlo justo a la medida de sus necesidades. 6. Además soporta las seis mejores prácticas en desarrollo de software: 1. Desarrollo iterativo. 2. Administración de requerimientos. 3. Arquitectura basada en componentes. 4. Modelado visual del software. 5. Verificación continua de la calidad del Software. 6. Control de Cambios. 7. Está respaldado por una paleta extensiva de herramientas desarrolladas por Rational Software.