Metodologia rup

32,634 views
32,319 views

Published on

1 Comment
10 Likes
Statistics
Notes
No Downloads
Views
Total views
32,634
On SlideShare
0
From Embeds
0
Number of Embeds
268
Actions
Shares
0
Downloads
1,328
Comments
1
Likes
10
Embeds 0
No embeds

No notes for slide

Metodologia rup

  1. 1. ANÁLISIS DE SISTEMAS II METODOLOGIA RUP (RATIONAL UNIFIED PROCESS)INTRODUCCIÓN.En la actualidad, la utilización de metodologías para el desarrollo de aplicaciones escasi imposible omitirla, debido a la gran necesidad de control de variables que conllevael mismo desarrollo, y para la ordenada elaboración de las aplicaciones, por lo tanto,seguir metodologías y estándares nos llevan a estar en competitividad en todomomento.Es de suma importancia conocer el modo como se interrelacionan metodologías conestándares y herramientas siguiendo un único propósito, el cual consiste en laelaboración de aplicaciones de manera eficiente, ordenada y con el menor número dedefectos.La metodología RUP nos proporciona disciplinas en las cuales se encuentran artefactoscon lo cual se podrá contar con guías para poder documentar e implementar de unamanera fácil y eficiente, todas las guías para un buen desarrollo, todo esto dentro de lasrespectivas fases con las cuales cuenta.RESUMEN.Las metodologías y estándares utilizados en un desarrollo de software nosproporcionan las guías para poder conocer todo el camino a recorrer desde antes deempezar la implementación, con lo cual se asegura la calidad del producto final, asícomo también el cumplimiento en la entrega del mismo en un tiempo estipulado.Es de suma importancia elegir la metodología adecuada, así como las herramientas deimplementación adecuadas, es por ello que la metodología RUP basada en UML nosproporciona todas las bases para llevar al éxito la elaboración del software, para ello lautilización de la herramienta RUP para el desarrollo rápido de aplicaciones.Este trabajo consta de siete capítulos, los cuales se describen a continuación: En el capítulo uno se abarcará la explicación de la metodología RUP con sus bases en el UML, las partes que la conforman, su funcionalidad; con lo cual podremos observar la interrelación entre ambos y la importancia de su uso en el desarrollo de aplicaciones. En el capítulo dos se abarcará lo que son las dimensiones de RUP dentro de ello específica los casos de uso y el proceso modelado a una arquitectura y los procesos iterativos. En el capítulo tres se abarca lo que son las fases y sus planeaciones los esfuerzos a los flujos de trabajo y a los de su respecto. En el capítulo cuatro se abarca lo que son las disciplinas como modelado de negocio, requerimientos, análisis, etc. En el capítulo cinco se abarca a lo que son las organizaciones del RUP como actores, artefactos y grados de artefacto. En el capítulo seis se trata de lo que es el Lenguaje Unificado de Modelado (UML) que se extiende hasta los casos de uso y diagramas y más ámbito de desarrollos de software. 1 - 25
  2. 2. ANÁLISIS DE SISTEMAS II Y como final el capítulo siete se abarca a lo que son las metodologías de diseño y Análisis de software con RUP y UML.RationalUnifiedProcess (RUP)Las siglas RUP en ingles significa RationalUnifiedProcess (Proceso Unificado deRacional) es un producto del proceso de ingeniería de software que proporciona unenfoque disciplinado para asignar tareas y responsabilidades dentro de unaorganización del desarrollo. Su meta es asegurar la producción del software de altacalidad que resuelve las necesidades de los usuarios dentro de un presupuesto ytiempo establecidos.Según Jacaboson, I., Booch, G., Rumbaugh J. (1998)1 El nombre Proceso Unificado seusa para describir el proceso genérico que incluye aquellos elementos que soncomunes a la mayoría de los refinamientos existentes. También permite evitarproblemas legales ya que Proceso Unificado de Rational o RUP son marcas registradaspor IBM (desde su compra de Rational Software Corporation en 2003).Según Grady Booch(2000)2 un reflejo de lo que hemos visto en el trabajo conliteralmente decenas de miles de proyectos en los últimos 20 años, la codificación de loque funciona en las organizaciones exitosas y lo que está notablemente ausente en losfallidos.Capítulo 1: Historia.La Figura 1 ilustra la historia de RUP. El antecedente más importante se ubica en 1967con la Metodología Ericsson (Ericsson Approach) elaborada por Ivar Jacobson,unaaproximación de desarrollo basada en componentes, que introdujo el conceptodeCaso de Uso. Entre los años de 1987 a 1995 Jacobson fundó la compañíaObjectoryAB y lanza el proceso de desarrollo Objectory (abreviación de Object Factory). Figura 1: Historia de RUPPosteriormente en 1995 Rational Software Corporation adquiere Objectory AB yentre1995 y 1997 se desarrolla RationalObjectoryProcess (ROP) a partir de Objectory3.8 ydel Enfoque Rational (RationalApproach) adoptando UML como lenguaje de modelado. 2 - 25
  3. 3. ANÁLISIS DE SISTEMAS IIDesde ese entonces y a la cabeza de Grady Booch, Ivar Jacobson y JamesRumbaugh,Rational Software desarrolló e incorporó diversos elementos para expandirRUP,destacándose especialmente el flujo de trabajo conocido como modelado delnegocio.En junio del 1998 se lanza RationalUnifiedProcess.AutoresJacaboson, I., Booch, G., Rumbaugh J., El Proceso Unificado de Desarrollo deSoftware, 2000 Addison Wesley2 Grady Booch, diseñador de software, unmetodologista de software y entusiasta de diseño de patrones. Es directorCientífico deRational Software (ahora parte de IBM) y editor de una serie de Benjamin/Cummings.Capítulo 2: Proceso de Desarrollo, Dimensiones del RUP.El RUP tiene dos dimensiones:El eje horizontal representa tiempo y demuestra los aspectos del ciclo de vidadelproceso.El eje vertical representa las disciplinas, que agrupan actividades definidasLógicamente por la naturaleza.La primera dimensión representa el aspecto dinámico del proceso y se expresaentérminos de fases, de iteraciones, y la finalización de las fases.La segunda dimensión representa el aspecto estático del proceso: cómo se describeentérminos de componentes de proceso, las disciplinas, las actividades, los flujosdetrabajo, los artefactos, y los roles.En la figura 2 se puede observar como varía el énfasis de cada disciplina en unciertoplazo en el tiempo, y durante cada una de las fases. Por ejemplo, eniteracionestempranas, pasamos más tiempo en requerimientos, y en las últimasiteracionespasamos más tiempo en poner en práctica la realización del proyecto en si. Figura 2. Disciplinas, fases, iteraciones del RUP 3 - 25
  4. 4. ANÁLISIS DE SISTEMAS IISe puede hacer mención de las tres características esenciales que definen al RUP:2.1.- Características esencialesLos autores de RUP destacan que el proceso de software propuesto por RUPtiene trescaracterísticas esenciales: está dirigido por los Casos de Uso, estácentrado en laarquitectura, y es iterativo e incremental.2.1.1.- Proceso dirigido por Casos de UsoSegún Kruchten, P.(2000)3, los Casos de Uso son una técnica de capturade requisitosque fuerza a pensar en términos de importancia para elusuario y no sólo en términos defunciones que seria bueno contemplar.Se define un Caso de Uso como un fragmento de funcionalidad delsistema queproporciona al usuario un valor añadido. Los Casos de Usorepresentan los requisitosfuncionales del sistema.En RUP los Casos de Uso no son sólo una herramienta para especificarlos requisitosdel sistema. También guían su diseño, implementación yprueba. Los Casos de Usoconstituyen un elemento integrador y una guíadel trabajo como se muestra en la Figura3. Figura 3: Los Casos de Uso integran el trabajoLos Casos de Uso4 no sólo inician el proceso de desarrollo sino queproporcionan unhilo conductor, permitiendo establecer trazabilidad entrelos artefactos que songenerados en las diferentes actividades delproceso de desarrollo. Como se muestra enla Figura 3, basándose en losCasos de Uso se crean los modelos de análisis y diseño,luego laimplementación que los lleva a cabo, y se verifica que efectivamente elproductoimplemente adecuadamente cada Caso de Uso. Todos losmodelos deben estarsincronizados con el modelo de Casos de Uso. 4 - 25
  5. 5. ANÁLISIS DE SISTEMAS II Figura 4: Trazabilidad a partir de los Casos de Uso2.1.2- Proceso centrado en la arquitecturaLa arquitectura de un sistema es la organización o estructura de suspartes másrelevantes, lo que permite tener una visión común entre todoslos involucrados(desarrolladores y usuarios) y una perspectiva clara delsistema completo, necesariapara controlar el desarrollo [Kru00]. Laarquitectura involucra los aspectos estáticos ydinámicos mássignificativos del sistema, está relacionada con la toma de decisionesqueindican cómo tiene que ser construido el sistema y ayuda a determinar enqué orden.Además la definición de la arquitectura debe tomar enconsideración elementos decalidad del sistema, rendimiento, reutilizacióny capacidad de evolución por lo que debeser flexible durante todo elproceso de desarrollo. La arquitectura se ve influenciada porla plataformasoftware, sistema operativo, gestor de bases de datos,protocolos,consideraciones de desarrollo como sistemas heredados. Muchas deestasrestricciones constituyen requisitos no funcionales del sistema.En el caso de RUP además de utilizar los Casos de Uso para guiar elproceso se prestaespecial atención al establecimiento temprano de unabuena arquitectura que no se veafuertemente impactada ante cambiosposteriores durante la construcción y elmantenimiento.Cada productotiene tanto una función como una forma. La función corresponde alafuncionalidad reflejada en los Casos de Uso y la forma la proporciona laarquitectura.Existe una interacción entre los Casos de Uso y laarquitectura, los Casos de Uso debenencajar en la arquitectura cuandose llevan a cabo y la arquitectura debe permitir eldesarrollo de todos losCasos de Uso requeridos, actualmente y en el futuro. Estoprovoca quetanto arquitectura como Casos de Uso deban evolucionar enparalelodurante todo el proceso de desarrollo de software.En la Figura 5 se ilustra la evolución de la arquitectura durante las fasesde RUP. Setiene una arquitectura más robusta en las fases finales delproyecto. En las fasesiniciales lo que se hace es ir consolidando laarquitectura por medio de baselinesy se vamodificando dependiendo delas necesidades del proyecto. 5 - 25
  6. 6. ANÁLISIS DE SISTEMAS II Figura 5: Evolución de la arquitectura del sistemaEs conveniente ver el sistema desde diferentes perspectivas paracomprender mejor eldiseño por lo que laarquitectura se representa mediante varias vistas que se centran enaspectos concretos del sistema, abstrayéndose de los demás. Para RUP,todas lasvistas juntas forman el llamado modelo 4+1 de la arquitecturasegún Kruchten, P.(19986),el cual recibe este nombre porque lo formanlas vistas lógica, de implementación, deproceso y de despliegue, más lade Casos de Uso que es la que da cohesión a todas. Figura 6: Los modelos se completan, la arquitectura no cambia drásticamenteAl final de la fase de elaboración se obtiene una baseline7 de laarquitectura dondefueron seleccionados una serie de Casos de Usoarquitectónicamente relevantes(aquellos que ayudan a mitigar los riesgosmás importantes, aquellos que son los másimportantes para el usuario yaquellos que cubran las funcionalidades significativas)Como se observaen la Figura 6, durante la construcción los diversos modelosvandesarrollándose hasta completarse (según se muestra con las formasrellenas en laesquina superior derecha). La descripción de la arquitecturasin embargo, no debería 6 - 25
  7. 7. ANÁLISIS DE SISTEMAS IIcambiar significativamente (abajo a la derecha)debido a que la mayor parte de laarquitectura se decidió durante laelaboración. Se incorporan pocos cambios a laarquitectura (indicadoscon mayor densidad de puntos en la figura inferior derecha)[JBR00].82.1.3.- Proceso iterativo e incrementalEl equilibrio correcto entre losCasos de Uso y la arquitectura es algo muy parecido alequilibrio de laforma y la función en el desarrollo del producto, lo cual se consigue coneltiempo. Para esto, la estrategia que se propone en RUP es tener unproceso iterativo eincremental en donde el trabajo se divide en partesmás pequeñas o mini proyectos.Permitiendo que el equilibrio entre Casosde Uso y arquitectura se vaya lograndodurante cada mini proyecto, asídurante todo el proceso de desarrollo. Cada miniproyecto se puede vercomo una iteración (un recorrido más o menos completo a lolargo detodos los flujos de trabajo fundamentales) del cual se obtiene unincremento queproduce un crecimiento en el producto. Una iteraciónpuede realizarse por medio de unacascada como se muestra en la Figura6. Se pasa por los flujos fundamentales(Requisitos, Análisis, Diseño,Implementación y Pruebas), también existe unaplanificación de laiteración, un análisis de la iteración y algunas actividades específicasdela iteración. Al finalizar se realiza una integración de los resultados con loobtenido delas iteraciones anteriores. Figura 7: Una iteración RUPEl proceso iterativo e incremental consta de una secuencia de iteraciones.Cadaiteración aborda una parte de la funcionalidad total, pasando portodos los flujos detrabajo relevantes y refinando la arquitectura. Cadaiteración se analiza cuando termina.Se puede determinar si hanaparecido nuevos requisitos o han cambiado los existentes,afectando alas iteraciones siguientes. Durante la planificación de los detalles delasiguiente iteración, el equipo también examina cómo afectarán los riesgosque aúnquedan al trabajo en curso. Toda la retroalimentación de laiteración pasada permitereajustar los objetivos para las siguientesiteraciones. Se continúa con esta dinámicahasta que se haya finalizadopor completo con la versión actual del producto. 7 - 25
  8. 8. ANÁLISIS DE SISTEMAS IIRUP divide el proceso en cuatro fases, dentro de las cuales se realizanvariasiteraciones en número variable según el proyecto y en las que sehace un mayor omenor hincapié en los distintas actividades. En la Figura8 se muestra cómo varía elesfuerzo asociado a las disciplinas según lafase en la que se encuentre elproyectoRUP. Figura 8: Ciclo de vidaLas primeras iteraciones (en las fases de Inicio y Elaboración) se enfocanhacia lacomprensión del problema y la tecnología, la delimitación delámbito del proyecto, laeliminación de los riesgos críticos, y alestablecimiento de una baseline10de laarquitectura.Durante la fase de inicio las iteraciones hacen ponen mayor énfasis enactividadesmodelado del negocio y de requisitos. En la fase deelaboración, las iteraciones seorientan al desarrollo de la baselinede laarquitectura, abarcan más los flujos de trabajode requerimientos, modelode negocios (refinamiento), análisis, diseño y una partedeimplementación orientado a la baselinede la arquitectura. En la fase deconstrucción,se lleva a cabo la construcción del producto por medio deuna serie de iteraciones.Para cada iteración se selecciona algunos Casos de Uso, se refina suanálisis y diseño yse procede a su implementación y pruebas. Se realizauna pequeña cascada para cadaciclo. Se realizan tantas iteracioneshasta que se termine la implementación de la nuevaversión del producto.En la fase de transición se pretende garantizar que se tiene un productopreparado parasu entrega a la comunidad de usuarios. Como se puedeobservar en cada faseparticipan todas las disciplinas, pero quedependiendo de la fase el esfuerzo dedicado auna disciplina varía. 8 - 25
  9. 9. ANÁLISIS DE SISTEMAS II Figura 9. Fases del RUPCapítulo 3: Desarrollo de Etapas (Fases).El ciclo de vida del software del RUP se descompone en cuatro fasessecuenciales(figura 9). En cada extremo de una fase se realiza una evaluación(actividad: Revisióndel ciclo de vida de la finalización de fase) para determinar si losobjetivos de la fase sehan cumplido. Una evaluación satisfactoria permite que el proyecto se mueva alapróxima fase.3.1.- Planeando las fasesEl ciclo de vida consiste en una serie de ciclos, cada uno de los cuales produceunanueva versión del producto, cada ciclo está compuesto por fases y cada unade estasfases está compuesta por un número de iteraciones, estas fases son:3.1.1.- Concepción, Inicio o Estudio de oportunidadDefine el ámbito y objetivos del proyecto Se define la funcionalidad ycapacidades delproducto.3.1.2.- ElaboraciónTanto la funcionalidad como el dominio del problema se estudian enprofundidad Sedefine una arquitectura básica Se planifica el proyectoconsiderando recursosdisponibles.3.1.3.- ConstrucciónEl producto se desarrolla a través de iteraciones donde cada iteracióninvolucra tareasde análisis, diseño e implementación Las fases de estudioy análisis sólo dieron unaarquitectura básica que es aquí refinada demanera incremental conforme se construye(se permiten cambios en laestructura) Gran parte del trabajo es programación ypruebas. Sedocumenta tanto el sistema construido como el manejo del mismo.Estafase proporciona un producto construido junto con la documentación.3.1.4.- Transición 9 - 25
  10. 10. ANÁLISIS DE SISTEMAS IISe libera el producto y se entrega al usuario para un uso real Se incluyentareas demarketing, empaquetado atractivo, instalación, configuración,entrenamiento, soporte,mantenimiento, etc.Los manuales de usuario se completan y refinan con la información anterior,estastareas se realizan también en iteraciones Todas las fases no son idénticasentérminos de tiempo y esfuerzo.Aunque esto varía considerablemente dependiendo del proyecto, un ciclo dedesarrolloinicial típico para un proyecto de tamaño mediano debe anticipar ladistribución siguienteel esfuerzo y horario: Tabla I. Esfuerzo-horario contra fases del RUPLo cual se puede representar gráficamente como se muestra en la figura 10: Figura 10. Recursos utilizados en las fases del RUP en el tiempo.El modelo cascada según Winston Royce(1970)13, es un secuencial modelo deldesarrollo delsoftware (un proceso para la creación del software) en que el desarrollo seconsidera comofluyendo constantemente hacia abajo (como a cascada) con las fases deanálisis de requisitos,diseño, puesta en práctica, prueba (validación), integración, ymantenimiento.Las fases de concepción y elaboración serían considerablemente máspequeñas.Algunas herramientas que pueden automatizar una cierta porción delesfuerzo dela fase de construcción pueden atenuar esto, haciendo que la fasedeconstrucción sea mucho más pequeña que las fases de concepción yelaboraciónjuntas. Este es precisamente el objetivo del trabajo. Cada paso con lascuatrofases produce una generación del software. A menos que el producto "muera",sedesarrollará nuevamente repitiendo la misma secuencia las fases deconcepción,elaboración, construcción y transición, pero con diversos énfasis cada fase. 10 - 25
  11. 11. ANÁLISIS DE SISTEMAS IIEstos ciclos subsecuentes se llaman los ciclos de la evolución. Mientras que elproductopasa durante varios ciclos, se producen las nuevas generaciones. En lafigura 11 semuestre este ciclo evolutivo. Figura 11. Ciclo evolutivo en la elaboración de software basado en el RUPLos ciclos evolutivos pueden ser iniciados por las mejoras sugeridas por elusuario,cambios en el contexto del usuario, cambios en la tecnología subyacente,reacción a lacompetición, etcétera. Los ciclos evolutivos tienen típicamente fasesde concepción yelaboración mucho más cortas, puesto que la definición y laarquitectura básicas delproducto son determinadas por los ciclos de desarrolloanteriores. Las excepciones aesta regla son los ciclos evolutivos en los cualesocurre o surge un producto significativoo unaredefinición arquitectónica.3.1.4.1.- Esfuerzo respecto de los flujos de trabajoEn la figura 5 se muestran ciertos porcentajes, de forma verticalse muestra el esfuerzoque se tiene que realizar por cada una delas disciplinas o flujos de trabajo14, y los dosporcentajes que semuestran de forma horizontal son para todo el proyecto.Explicando mas puntualmente la figura 12 se puede observar quepara la obtención derequerimientos o requisitos en la fase deconcepción se empiezan a obtener, en la fasede elaboracióntiene su auge y va declinando en la fase de construcción, realizartodoesto requiere aproximadamente un 15% de esfuerzo, y asísucesivamente con lasdemás disciplinas. En esta sección y lasiguiente, los porcentajes pueden variar de unproyecto a otro.El flujo de trabajo (workflow) es el estudio de los aspectos operacionales de unaactividad de trabajo:cómo se estructuran las tareas, cómo se realizan, cuál es su ordencorrelativo, cómo se sincronizan, cómofluye la información que soporta las tareas ycómo se le hace seguimiento al cumplimiento de las tareas. 11 - 25
  12. 12. ANÁLISIS DE SISTEMAS II Figura 12. Esfuerzo respecto de los flujos de trabajo3.1.4.2 Esfuerzo respecto de las fases.En la figura 6 se muestran dos filas de porcentajes, el primero quees el esfuerzorealizado por cada fase en forma general eincluyendo las iteraciones dentro de cadafase; y en la segunda fila,la duración que tiene aproximadamente en porcentajes deltiempototal del proyecto para cada una de las fases incluyendo todas lasiteraciones queconlleven realizar cada fase.Explicando más puntualmente una pequeña parte de la figura 13 sepuede observar quepara la fase de construcción se tiene quededicar más esfuerzo y mayor duración,siempre y cuandodependiendo de qué disciplina estemos ejecutando, por ejemplo enla disciplina de implementación se tiene mucho auge en la fase deconstrucción. Figura 13. Esfuerzo respecto de las fases 12 - 25
  13. 13. ANÁLISIS DE SISTEMAS IICapítulo 4: Notación de la metodología y Disciplinas.Las disciplinas conllevan los flujos de trabajo, los cuales son una secuencia depasospara la culminación de cada disciplina, estas disciplinas se dividen en dos grupos:lashyprimarias y las de apoyo. Las primarias son las necesarias para la realización deunproyecto de software, aunque para proyectos no muy grandes se puedenomitiralgunas; entre ellas se tienen: Modelado del Negocio, Requerimientos, AnálisisyDiseño, Implementación, Pruebas, Despliegue. Las de apoyo son las que comosunombre lo indica sirven de apoyo a las primarias y especifican otras característicasenla realización de un proyecto de software; entre estas se tienen: Entorno, GestióndelProyecto, Gestión de Configuración y Cambios. A continuación sedescriberápidamente cada una de estas disciplinas.4.1.- Modelado del negocio.Esta disciplina tiene como objetivos comprender la estructura y la dinámica delaorganización, comprender problemas actuales e identificar posiblesmejoras,comprender los procesos de negocio. Utiliza el Modelo de CU del Negocioparadescribir los procesos del negocio y los clientes, el Modelo de Objetos delNegociopara describir cada CU del Negocio con los Trabajadores, ademásutilizan losDiagramas de Actividad y de Clases.4.2.- Requerimientos.Esta disciplina tiene como objetivos establecer lo que el sistema debe hacer(EspecificarRequisitos), definir los límites del sistema, y una interfaz de usuario,realizar unaestimación del costo y tiempo de desarrollo. Utiliza el Modelo de CUpara modelar elSistema que comprenden los CU, Actores y Relaciones, ademásutiliza los diagramas deEstados de cada CU y las especificacionessuplementarias.4.3.- Análisis y diseño.Esta disciplina define la arquitectura del sistema y tiene como objetivostrasladarrequisitos en especificaciones de implementación, al decir análisis se refiereatransformar CU en clases, y al decir diseño se refiere a refinar el análisis parapoderimplementar los diagramas de clases de análisis de cada CU, losdiagramas decolaboración de de cada CU, el de clases de diseño de cada CU, elde secuencia dediseño de CU, el de estados de las clases, el modelo dedespliegue de la arquitectura.4.4.- Implementación.Esta disciplina tiene como objetivos implementar las clases de diseñocomocomponentes (ej. fichero fuente), asignar los componentes a los nodos, probarloscomponentes individualmente, integrar los componentes en un sistemaejecutable(enfoque incremental). Utiliza el Modelo de Implementación, conjuntamentelosDiagramas de Componentes para comprender cómo se organizan losComponentes ydependen unos de otros. 13 - 25
  14. 14. ANÁLISIS DE SISTEMAS II4.5.- Pruebas.Esta disciplina tiene como objetivos verificar la integración de los componentes(pruebade integración), verificar que todos los requisitos han sido implementados(pruebas delsistema), asegurar que los defectos detectados han sido resueltosantes de ladistribución4.6.- Despliegue.Esta disciplina tiene como objetivos asegurar que el producto está preparado paraelcliente, proceder a su entrega y recepción por el cliente. En esta disciplina serealizanlas actividades de probar el software en su entorno final (Prueba Beta),empaquetarlo,distribuirlo e instalarlo, así como la tarea de enseñar al usuario.4.7.- Gestión y configuración de cambios.Es esencial para controlar el número de artefactos producidos por la cantidaddepersonal que trabajan en un proyecto conjuntamente. Los controles sobre loscambiosson de mucha ayuda ya que evitan confusiones costosas como lacompostura de algoque ya se había arreglado etc., y aseguran que los resultadosde los artefactos noentren en conflicto con algunos de los siguientes tipos deproblemas:Actualización simultánea: Es la actualización de algo elaborado con anterioridad,sinsaber que alguien más lo está actualizando.Notificación limitada: Al realizar alguna modificación, no se deja información sobreloque se hizo, por lo tanto no se sabe quién, como, y cuando se hizo.Versiones múltiples: No saber con exactitud, cual es la última versión, y al final nosetiene un orden sobre que modificaciones se han realizado a las diversasversiones.4.8.- Gestión del proyecto.La gestión de proyectosu objetivo es equilibrar los objetivos competitivos,administrar elriesgo, y superar restricciones para entregar un producto quesatisface las necesidadese ambos clientes con éxito (los que pagan el dinero) ylos usuarios. Con la Gestión delProyecto se logra una mejoría en el manejo deuna entrega exitoso de software. Enresumen su propósito consiste en proveerpautas para:- Administrar proyectos de software intensivos.- Planear, dirigir personal, ejecutar acciones y supervisar proyectos.- Administrar el riesgo.Sin embargo, esta disciplina no intenta cubrir todos los aspectos de direccióndelproyecto. Por ejemplo, no cubre problemas como:Administración de personal: contratando, entrenando, enseñando.Administración del presupuesto: definiendo, asignando.Administración de los contratos con proveedores y clientes. 14 - 25
  15. 15. ANÁLISIS DE SISTEMAS II4.9.- Entorno.Esta disciplina se enfoca sobre las actividades necesarias para configurar elprocesoque engloba el desarrollo de un proyecto y describe las actividadesrequeridas para eldesarrollo de las pautas que apoyan un proyecto.Su propósito es proveer a la organización que desarrollará el software, unambiente enel cual basarse, el cual provee procesos y herramientas para poderdesarrollar elsoftware.Capítulo 5: Ejemplodesarrollado. Plan de Desarrollo de Software1. Introducción A continuación se presenta un plan inicial de desarrollo del sistema Repositorio de Sistemas, el cual consiste en un proyecto de gestión de sistemas para cualquier empresa de tamaño considerable, que requiera un manejo automatizado de la información de los sistemas utilizados. El proyecto nace como necesidad de muchos gerentes de empresas grandes de mantener un “Repositorio” de sus sistemas, para así mantener un control de la información manejada en la empresa tanto a nivel de la central como en las distintas oficinas. La central se refiere a la sede principal de la empresa, las oficinas son centrales que de forma autónoma manejan la información correspondiente a cada país o región. De acuerdo a las características del proyecto se tomó como enfoque de desarrollo una configuración del proceso RUP, seleccionando los roles de los participantes, las actividades a realizar y los artefactos (entregables) que serán generados. Este documento es a su vez uno de los artefactos de RUP.1.1 Propósito El propósito del Plan de Desarrollo de Software es proporcionar la información necesaria para llevar el control del proyecto. Se describe la organización del proyecto y la forma en cómo debe ser llevado o elaborado por los usuarios desarrolladores del sistema. También sirve como base para llevar a cabo un análisis más detallado del mismo. En cuanto a cuáles son los usuarios del Plan de Desarrollo del Software tenemos: El representante del proyecto: hace uso de este documento para organizar y designar las tareas del equipo de trabajo, para ver necesidades de recursos y para realizar su seguimiento. Los miembros del equipo lo usan para entender qué es lo que deben hacer, cuáles técnicas aplicar, en cuál momento se debe hacer y qué otras actividades dependen de ello. 15 - 25
  16. 16. ANÁLISIS DE SISTEMAS II1.2 Alcance El Plan de Desarrollo del Software consiste en describir el plan global usado para el desarrollo del Sistema de Repositorio de Sistemas, el cual pretende gestionar los diferentes sistemas presentes en una organización. Adicionalmente, se requiere realizar el detalle de las iteraciones individuales, esto se describe en los planes de cada iteración, documentos que se aportan en forma separada. Se necesita del documento “Visión” durante el proceso de desarrollo, ya que en ese artefacto se definen las características del producto a desarrollar, lo cual constituye la base para la planificación de las iteraciones. Para esta versión 1.0 del Plan de Desarrollo del Software, se ha realizado una estimación aproximada en base a los requerimientos iniciales del sistema. Para producir nuevas versiones actualizadas y mejoradas de este documento, se tiene que realizar un seguimiento en cada una de las iteraciones y de esta manera realizar los ajustes necesarios.1.3 Definiciones, Acrónimos y AbreviacionesRS: Repositorio de SistemasRUP: RationalUnifiedProcess1.4 Referencias Este documento hace referencia a los documentos Visión y Arquitectura del Software.1.5 Vista Global El Plan de Desarrollo contempla las 4 secciones siguientes: Vista General del Proyecto: proporciona información acerca del propósito, el alcance y los objetivos del proyecto; las suposiciones y las restricciones consideradas para el sistema; y por último la evolución de este plan a medida que se comienza una nueva iteración. Organización del Proyecto: describe los roles correspondientes a los integrantes del equipo de desarrollo, así como las fases en las cuales se divide el proceso de desarrollo del sistema. Gestión del Proceso: estima el costo y la planificación aproximada del proyecto, define las fases e hitos del proyecto y describe cómo se realizará su seguimiento.2. Vista General del Proyecto2.1 Propósito, Alcance y Objetivos En una organización (por ejemplo: una empresa por departamentos transnacional), muchas veces es desconocida la cantidad de sistemas internos, más aún es difícil llevar un monitoreo de cada sistema para llevar un mantenimiento de las funcionalidades de cada uno de ellos. El propósito principal de este proyecto es hacer cumplir esos objetivos. Se quiere tener un sistema de control que monitoree y mantenga información detalladas sobre los sistemas de una organización. Actualmente, no se cuenta con un sistema que proporcione tal información, es por ello que nace la necesidad de tener un sistema automatizado para tal fin. Al ser el primer sistema de este tipo, no se cuenta con precedentes o versiones pasadas de un sistema anterior, por lo tanto será desarrollado en su totalidad desde cero. 16 - 25
  17. 17. ANÁLISIS DE SISTEMAS II2.2 Suposiciones y Restricciones1. Se asume que el usuario final, en este caso el gerente general de la empresa, encargada del monitoreo general de los sistemas de la organización, cuenta con los recursos necesarios para el efectivo funcionamiento del sistema, esto abarca tanto los aspectos relacionados con el hardware como los de software.2. Queda a disposición de los desarrolladores utilizar el lenguaje de programación más conveniente, por lo cual hasta el momento la opción más aceptada sería utilizar un framework de PHP llamado PHPCake.3. En cuanto a la información manejada, esta debe mantenerse con cierto grado de confidenciabilidad, flexibilidad, usabilidad y seguridad.2.3 Evolución del Plan de Desarrollo del Software. El Plan de Desarrollo del Software se revisará periódicamente y se refinará antes del comienzo de cada iteración.3. ORGANIZACIÓN DEL PROYECTO. Se pretende adaptar el modelo bajo el que se desarrollara el software al proceso definido por RUP. En vista de que todas las etapas del proyecto se no se adaptan perfectamente al modelo definido por RUP, se toman solo aquellos aspectos aplicables del proyecto y se realizan las modificaciones necesarias en los demás casos. Se debe considerar las posteriores modificaciones al presente plan de desarrollo.3.1 Modelo De Proceso. El proceso de desarrollo del sistema se dividirá en cuatro fases: 1. Investigación:Esta fase implica un estudio profundo de técnicas, herramientas y avances en el área de investigación, para generar un documento de contexto de trabajo donde se resuma la información recavada. 2. Inicio: Una vez generada la documentación de contexto de trabajo, al finalizar la fase de investigación, el grupo cuenta con la información necesaria para analizar el problema y proponer una solución al mismo. Esto se realiza en la fase de inicio. Luego de planteada una solución al problema, se comienza a detallar técnicamente la implementación de la solución propuesta. 3. Elaboración: Es en la fase de elaboración donde se realiza el diseño del sistema, lo cual implica definición de la arquitectura del mismo. Esta fase se da por culminada cuando dicha arquitectura sea estable. 4. Construcción: Demostrada la estabilidad de la arquitectura adoptada se comienza a implementar el sistema final. La fase de construcción implica una fuerte carga horaria de implementación. A fines de esta fase se comienzan las sesiones de prueba de la solución implementada. 17 - 25
  18. 18. ANÁLISIS DE SISTEMAS II3.2 Planificación De Fases De La Metodología RUP.3.2.1. Inicio. Los objetivos de esta fase son: Establecer los límites y alcance del proyecto Definir casos de uso Estimar potenciales riesgos Determinar la factibilidad del proyecto Definir plan de desarrollo de software Desarrollar un prototipo inicial no funcional3.2.2. Elaboración. Los objetivos de esta fase son: Definir la arquitectura del sistema y vistas de casos de uso Resolver los principales riesgos de la arquitectura Definir vistas restantes y refinar vistas de casos de uso Implementar los casos de uso críticos3.2.3. Construcción. Los objetivos de la fase son: Refinar las vistas de la fase anterior Implementar las funcionalidades del sistema Desarrollo iterativo incremental del producto completo Realización de pruebas Corrección y ajuste de errores3.3 Estructura Organizacional El equipo consta de nueve integrantes. La estructura organizacional del grupo ha sido definida como horizontal, debido a las características del mismo. Cada integrante esta en capacidad de realizar cualquier actividad referente al proceso de desarrollo del proyecto. Es necesaria la colaboración entre miembros y conocimiento de todas las áreas para poder llevar a cabo todas las etapas del proceso. Sin embargo, es importante llevar a cabo una división de tareas con el fin de incrementar la eficiencia de trabajo, donde sin embargo cualquier integrante deberá estar en la capacidad de suplantar a otro, si así fuese requerido.3.3.1 Interfaces Externas. La profesora Marlene Goncalves se encargará de evaluar el avance del proyecto basándose en el calendario y el plan de desarrollo. 18 - 25
  19. 19. ANÁLISIS DE SISTEMAS II3.3.2 Roles y Responsabilidades Los roles y responsabilidades serán rotadas en el transcurso del desarrollo, cada integrante del grupo deberá estar involucrado en todas las áreas del proceso de desarrollo y el nivel de responsabilidad es el mismo para todos.4. Gestión del Proceso4.1 Estimaciones del Proyecto Al ser un proyecto de carácter académico, se deja de lado el aspecto económico ya que no se cuenta con un presupuesto ni costos asociados al desarrollo, ya que su valor se representa en el aporte tecnológico para la Universidad Simón Bolívar.4.2 Plan del Proyecto Para el desarrollo satisfactorio del sistema fue necesario dividirlo en varias fases, basadas en la metodología RUP, cada una estas fases podrá contener una o mas iteraciones obteniendo en cada iteración un hito especifico. La descripción detallada de cada una de las fases y sus iteraciones que conforman el proceso de desarrollo del sistema se encuentran a continuación4.2.1 Plan de las Fases Nro. Fase Duración Iteraciones Fase de Inicio 1 4 semanas Fase de Elaboración 1 6 semanas Fase de Construcción 2 12 semanas4.2.2 Objetivos de las Fases Fase Descripción Fase de Inicio Durante esta fase, se desarrolla una descripción del producto final a partir de una buena idea y se presenta el análisis de negocio para el producto. En su única iteración se especifica las funcionalidades que debe poseer el sistema y su alcance. Además se lleva a cabo un estudio detallado de todo lo que es el negocio al cual se le está creando el sistema, para así determinar cuáles son las necesidades a ser satisfechas con mayor prioridad, esto se define en el artefacto Visión. Se definen los casos de uso, como una representación de las funcionalidades del sistema y de la interacción con el usuario. Se establece el Plan de Desarrollo, donde se describe de forma 19 - 25
  20. 20. ANÁLISIS DE SISTEMAS II detallada las actividades que se llevarán a cabo para crear el sistema. El final de la fase esta marcado con la aceptación por parte del cliente del artefacto Visión y el Plan de Desarrollo. Fase de Se obtiene un entendimiento más detallado de los Elaboración requerimientos, se procede a diseñar, implementar, validar y generar una línea base para la arquitectura. Se definen los subsistemas, los componentes clave y sus interfaces; se usan los casos de uso significantes arquitectónicamente para dirigir la arquitectura. Se consolidan y empaquetan las clases identificadas. Se diseña la Base de datos. Se implementan y prueban los escenarios críticos. Se debe mitigar los riesgos esenciales y producir un plan de desarrollo más preciso. Se elabora el artefacto de arquitectura el cual contempla todo el diseño de la arquitectura. La culminación de esta fase viene dada por el documento arquitectura y el prototipo implementado. Fase de Durante la fase de construcción se terminan de analizar y Construcción diseñar todos los casos de uso, refinando el Modelo de Análisis / Diseño, para el plan inicial no se ha determinado la cantidad de iteraciones a realizar. Se elaboran varios prototipos que constituyen versiones iniciales que muestran parcialmente el funcionamiento de ciertas características del sistema, las cuales son probadas hasta ser validadas por el cliente. El fin de esta fase viene dado por la versión final del sistema, la cual incluye toda la funcionalidad del producto.4.2.3 Calendario del Proyecto A continuación se presenta un calendario de las principales tareas del proyecto incluyendo sólo la fase de Inicio. Ya que debido al proceso iterativo e incremental de RUP se realizan en paralelo de todas las disciplinas de desarrollo a lo largo del proyecto, con lo cual la mayoría de los artefactos son generados muy tempranamente en el proyecto pero van desarrollándose en mayor o menor grado de acuerdo a la fase e iteración del proyecto. Se incluyen los artefactos a entregar en cada fase. La fecha de aprobación indica cuándo el artefacto en cuestión tiene un estado de completitud suficiente para someterse a revisión y aprobación, pero esto no quita la posibilidad de su posterior refinamiento y cambios. 20 - 25
  21. 21. ANÁLISIS DE SISTEMAS II Fase de Inicio Duración: 4 semanas. Actividad Semana Criterio de culminación Comienzo - Semana Entrega Levantamiento de Información 1-3 (Finalizado) Esta fase culminará Detalles del proyecto 1-3 (Finalizado) cuando se tengan al Elaboración de página Web con 3-4 (Finalizado) menos 90% de las artefactos actividades aquí Plan de Iteración de la fase de 4-5 (Finalizado) mencionadas. elaboración Creación del Plan inicial de 2-4 (Finalizado) Desarrollo del proyecto Creación de documento Visión 3-4 (Finalizado) del sistema Refinación del documento Visión 4-5 (Finalizado) del sistema Modelos de Casos de Uso del 4-5 (Finalizado) Negocio Lista inicial de Requerimientos 3-5 (Finalizado) Especificación de requerimientos 5-6 (Finalizado) funcionales y no funcionales Lista inicial de riesgos asociados 4-6 (Finalizado) Glosario inicial del proyecto 5-6 (Finalizado) Prototipo de estructura del 4-5 (Finalizado) sistema Elaboración del documento de 4-5 (Finalizado) arquitectura inicial. Fase de Elaboración Duración: 6 semanas. Actividad Semana Iteración Casos de Usos Comienzo Implementados y Criterio -Semana de culminación de la Entrega iteraciónRefinación y diagramas de los 6-7 1 Casos de Uso:Casos de Uso del sistema (Finalizado) 1. Ingresar SistemaVista de Datos: Creación de 7-8 1 2. Solicitar AsociaciónModelo Entidad Relación (ER) (Finalizado) 3. Listar AsociacionesVista Lógica: Modelo de 7-8 1 pendientesAnálisis (Finalizado) 4. Aceptar asociaciónDiagrama de Clases 8-9 1 5. Rechazar asociación (Finalizado) 6. Ver AsociaciónDiagrama de Secuencia 8-9 1 7. Ver Grados de (Finalizado) AsociaciónEstablecer casos de uso 7-7 1 8. Consultar 21 - 25
  22. 22. ANÁLISIS DE SISTEMAS IIcríticos del sistema. (Finalizado) AsociaciónRefinación del documento de 8-9 1 9. Listar SistemasArquitectura del Software (Finalizado) 10. Ver SistemaRefinación del prototipo con 10-12 1 11. Consultarlos casos de uso críticos del (Finalizado) estadísticas generalessistema 12. Modificar SistemaPlan de la segunda Iteración 8-9 1de la fase de elaboración (Eliminado) Esta iteración culminaráRefinación de diagramas y de 9-12 1 cuando:los casos de uso (Finalizado) -Se tengan completos losRefinación y actualización del 11-12 1 modelos de casos de uso,plan de proyecto (Finalizado) con sus respectivos diagramas de secuencia. -Se haya especificado una arquitectura del software en al menos un 80% Fase de Construcción Duración: 12 semanas. Actividad Semana Iteración Casos de Usos Implementados Comienzo - y Criterio de culminación de la Semana iteración EntregaPlan de la primera 1-2 1Iteración de la fase de Casos de Uso:construcciónRefinamiento de los 1-2 1 1. Finalización del módulodiagramas y la base sistemas.de datos 2. Refinación del módulo asociaciones.Desarrollo del Sistema 1-6 1 3. Módulo de errores.Manual del Usuario 5-6 1Ajustes al Sistema 7-7 1Pruebas 1-7 1 - Base de datos en un 100%Plan de la segunda 6-7 1 - Sistema desarrollado en un 80%.Iteración de la fase de - Manual completado en un 80%.construcciónRefinamiento de los 7-8 2diagramas y la base Casos de Uso:de datosPruebas 8-12 2 1. Manejo de la seguridadDesarrollo del Sistema 6-11 2 2. Refinación módulo de errores.Culminación del 10-11 2 3. Gráficos asociacionesmanual de usuario Se han realizado todas lasCorrección de errores 8-11 2 pruebas para asegurar que el sistema está libre de errores. 22 - 25
  23. 23. ANÁLISIS DE SISTEMAS II4.3 Seguimiento y Control del Proyecto.4.4.1 Plan de Manejo de Requerimientos. En el documento Visión se encuentran de manera detallada los requerimientos funcionales y no funcionales del sistema. Se establecerán en la fase inicial y serán revisados durante la fase de elaboración y construcción. En caso de que surjan nuevos requerimientos durante estas fases habrá que discutir sobre su factibilidad y los riesgos que implicaría incluirlos en el desarrollo.4.3.1 Plan de Control de Plazos. Con el objetivo de llevar un control sobre el desarrollo del sistema está establecido un Plan de Proyecto, en el cual se establece un cronograma de actividades semanales que deben ser realizadas por el equipo de desarrolladores a lo largo de cada una de las cuatro fases y por cada iteración.4.3.2 Plan de Control de Presupuesto Debido a que el proyecto es de carácter académico no supone la elaboración y mantenimiento de un presupuesto.4.3.3 Plan de Control de Calidad. Para establecer puntos de control sobre el sistema, se realizarán pruebas sobre los prototipos entregados pertenecientes a cada una de las fases. En base a la metodología RUP se aplican las siguientes pruebas para asegurar la calidad del sistema detectando errores a tiempo: -. Prueba de Funcionalidad: Certifica que el funcionamiento es acorde con las funcionalidades reflejadas en los casos de uso, esta prueba incluye la prueba de seguridad funcional en la cual se certifica que las funciones y datos del sistema sean accesibles por los actores autorizados. -. Prueba de Robustez: Certifica la capacidad de resistencia a fallar que tiene el sistema, probando casos en que el sistema podría fallar, como lo son los casos borde. -. Prueba de Volumen Funcional: Certifica si el sistema esta en la capacidad de manejar altos volúmenes de datos sin afectar su rendimiento. -.Prueba de Concurrencia: Certifica la capacidad del sistema de atender múltiples solicitudes de parte de los actores que acceden a un mismo recurso. -. Prueba de Instalación: En la ultima fase certifica que el sistema esta operativo y listo para funcionar.4.3.4 Plan de Reportes. Esta prevista la entrega de un reporte de status semanalmente, el cual se contrasta con el plan de desarrollo, además de los artefactos correspondientes y estipulados dentro de este plan. 23 - 25
  24. 24. ANÁLISIS DE SISTEMAS II4.4 Plan de Manejo de Riesgos Para el manejo de riesgos se aplica el modelo CMMI, llamada Gestión de riesgos (RSKM), su objetivo es de identificar problemas potenciales antes de que ellos ocurran de modo que actividades que manejan riesgo puedan ser planificadas e invocadas como sea necesario a través de la vida del producto y el mitigar impactos adversos en el alcanzar objetivos. En la primera fase de determinan los riesgos iniciales y se define su alcance y se establece una estrategia para mitigarlos. Luego de identificados se evalúan, categorizar y se determina su importancia para el desarrollo del proyecto. Por último se procede a desarrollar el plan para mitigar los riesgos, el manejo de riesgos es una actividad presente a lo largo del desarrollo.4.5 Plan de Culminación Para que el desarrollo del sistema culmine de manera exitosa es necesario el seguimiento constante del plan de desarrollo mediante los reporte de status semanal, para establecer el avance del proyecto. Es importante tomar en cuenta los riesgos asociados al proyecto a lo largo de su desarrollo para mitigarlos a tiempo y así evitar cualquier situación que ponga en peligro su culminación. Para lograr un sistema perdurable y evolutivo, se proporciona la documentación de todo el proceso en sus diferentes fases para que de esta manera un equipo de desarrolladores distinto pueda realizar el mantenimiento y futuras mejoras al sistema.CONCLUSIONES.1. La elaboración de distintos diagramas y artefactos siguiendo la metodología RUPproveen una fácil ejecución del proceso de elaboración de un Sistema de Software, yaque describen cómo está estructurado el sistema desde diferentes perspectivasorientadas a los diferentes involucrados en un proyecto.2. Se puede reducir el tiempo de desarrollo de un Sistema de Software, aplicando lametodología RUP y UML ya que permite lograr de una manera fiable y rápida eldesarrollo del Sistema deseado.3. Colocando componentes en los distintos servidores que conformen el sistema adesarrollar,se cuenta de una manera automática con todos los servicios prestados pordichos componentes, es decir, se ponen a disposición de los desarrollador es un grannúmero de herramientas que se pueden aprovechar en la realización del Sistema deSoftware de una manera mucho más eficaz.4. El tener todo el procedimiento de desarrollo de un Sistema de Software, es unaherramienta necesaria y efectiva para administrarlo; y así contar con una visiónunificada de todo el proceso, con lo que se facilita la implementación del mismo.RECOMENDACIONES.1. la metodología RUP cuenta con un enfoque disciplinado en la asignación de tareas yresponsabilidades dentro de una organización del desarrollo, con la cual se puedemantener una fácil administración de este proceso. 24 - 25
  25. 25. ANÁLISIS DE SISTEMAS II2. Para obtener un máximo control de variables que conlleva un desarrollo de aplicaciones ypoder mantener una ordenada implementación de éstas, es importante seguirmetodologías y estándares que nos lleven a estar en competitividad en todo momento.3. Al implementar un Desarrollo Rápido de Aplicaciones de un Sistema particular, esimportante la utilización de Patrones, los cuales ya tienen una funcionalidad general y hansido predefinidos, y así contar con una base consistente y previamente elaborada para laimplementación del Software.BIBLIOGRAFIA.1. Grupo Isaias Carrillos Perez. (2008) Metodología del desarrollo de software.New York:Editorial Edit and write.2. IBM, Rational Software. (2003). Rational Rapid Developer, Technical Overview.EE.UU:IBM publications, World Wide Web.3. ITSA (2008). Metodologías De Desarrollo De Software Canada:Editorial Canada Pen.4. Jacaboson, I., Booch, G., Rumbaugh J. (2000) Proceso Unificado de Desarrollo deSoftware.New York:Editorial Mc Graw Hill.5. Kruchten, P. (1995). Architectural Blueprints—the “4+1” View Model of SoftwareArchitecture.IEEE Software.6. Marcos, E. (2005). “Investigación en Ingeniería del Software vs. DesarrolloSoftware”, Grupo KYBELE,Universidad Rey Juan Carlos.7. Morgan, Stanley (2001). Sr. Business Analyst. New York:Editorial Pretince Hall.8. Pressman, Roger. (2003) Ingenieria de Software 6ta edic.New York:Editorial McGraw Hill.9. RUP/Easy. (2004). GUÍA METODOLÓGICA DE DESARROLLO DE SISTEMAS10.Schmuller, Joseph. (2000) Aprendiendo UML en 24 horas.México:Editorial Prentice all.11. Sommerville, I. (2005) Ingeniería del software, 7ª edición, Pearson- Addison.España:Editorial Wesley.12.Wasserfallmodell, Entstehungskontext, Markus Rerych, und Wirkungsforschung,(2007). TU-Wien de Gestaltungs- del für de Institut. Tenido acceso en línea 28 denoviembre. 25 - 25

×