Sei sulla pagina 1di 12

LA METODOLOGÍA RUP ¿QUÉ ES Y CÓMO APLICA?

Rational Unified Process (RUP por sus siglas en inglés), es una metodología de proyecto
disciplinada que tiene como objetivo la producción de módulos entregables de software. La
metodología RUP además sugiere la distribución de tareas dentro del equipo de desarrollo.

Esta metodología fue desarrollada por Philippe Kruchten e Ivar Jacobsen entre otros dentro de la
organización Rational Corporation que luego fue comprada por IBM en 2003.

Frecuentemente, Project Managers, asumen que la metodología RUP (Rational Unified Process),
no es apropiada para ser aplicada en proyectos de software de limitado alcance. Sin embargo, esto
dista de la realidad, RUP puede ser aplicada a proyectos corto alcance, así como también a
aquellos más ambiciosos.

Una parte fundamental del espíritu RUP es que brinda la habilidad de dividir los requerimientos en
diferentes grupos:

 Concepción
 Elaboración
 Construcción
 Transición

Muchas controversias existen a la hora de catalogar a la metodología RUP como ágil o no ágil. Si el
proceso es ajustado a las necesidades de la situación, es posible afirmar con seguridad que RUP es
ágil. A continuación, algunas cualidades candidatas a adecuación que permiten utilizar RUP como
un proceso ágil:

 Escoger solo los artefactos más importantes para el cliente y el equipo de desarrollo
 Buscar constantemente mantener las iteraciones tan cortas como sea posible
 Integrar al cliente como parte del equipo de desarrollo
 Lanzamiento completo e incremental del producto
 Asegurar esfuerzos colaborativos y comunicación fluida
 Mantener modularidad del modelo de desarrollo
 Mantener flexibilidad y adaptabilidad ante riesgos emergentes

La metodología RUP es compatible con un enfoque iterativo para abordar el desarrollo de


software, ayuda de manera proactiva a identificar riesgos, reduce los costos de refactorización y
permite construir modelos que pueden ser fácilmente descartados. RUP además invita al uso de
escenarios y casos de uso para capturar los requerimientos funcionales.

Además, soporta el desarrollo de software basado en componentes, que consisten en módulos del
sistema y subsistemas con funciones específicas. RUP, provee un enfoque sistemático para definir
la arquitectura del sistema utilizando componentes nuevos y existentes.
¿QUIÉNES PARTICIPAN EN RUP?
Roles y Responsabilidades en un Equipo de Desarrollo de Software
Un equipo de desarrollo puede ser una sola persona, o 50, pero en cualquier equipo existen una
serie de roles (funciones), que pueden ser identificados.

En un equipo pequeño, puede que una persona cubra múltiples roles, mientras que en equipos más
grandes, es más común tener funciones dedicadas.

Independientemente del caso, la identificación de los roles en el equipo ayudará a estructurar el


mismo, y a crear conciencia de las responsabilidades. Por ejemplo, si nadie se siente responsable de
probar el software, será inevitable que se encuentren errores en la versión final.

Al leer cada uno de los roles descritos aquí, piense en su equipo de desarrollo (o si el desarrollo es
unipersonal, piense en usted mismo), y evalué cómo son tratadas dentro de su equipo las distintas
responsabilidades descriptas.

El Cliente
Se puede pensar que tratar al cliente como parte del equipo de desarrollo es extraño, pero en
realidad, no lo es: El cliente es un factor importante en el éxito de un proyecto, tanto como cualquier
otro miembro del equipo, por eso es importante contar con la participación activa del cliente dentro
del proyecto.

También es importante entender quién es en realidad “El Cliente”. Tanto si se desarrolla software
para clientes actuales, como si se desarrolla para uno mismo, o para la propia empresa u
organización, siempre hay un rol de cliente. El cliente, es en esencia, quien pone en marcha el
proyecto, paga las cuentas, o define el resultado final. Aun si no se tiene literalmente un “cliente”,
es bueno entender que aun así existe un rol “cliente” en su proyecto. Esto puede ayudar a evitar
confusiones. Si hay varias personas diciendo que características se necesitan, hay que asegurarse de
que exista algún responsable de tomar las decisiones cuando estos requisitos sean contradictorios.

El Analista
El analista es alguien que es responsable de entender las necesidades del cliente, y asegurarse de
que la solución que está siendo desarrollada se ajusta a esas necesidades.

Las actividades típicas de un analista incluyen la elicitación de requisitos, reuniones con clientes y la
redacción de especificaciones funcionales.

Incluso si un proyecto es demasiado pequeño para escribir un verdadero documento de


especificación, la comprensión de las necesidades del cliente es un trabajo importante, dado que a
menudo el éxito de un proyecto de desarrollo depende de qué tan cerca está la solución
desarrollada de las expectativas del cliente.

El Arquitecto de Software
El papel del arquitecto de software es traducir los requisitos, tal como se define por el analista, en
una solución técnica. Él puede crear un diseño técnico, o simplemente algunos bocetos a mano
alzada, de cómo el sistema va a estar estructurado. En cualquier caso, es la responsabilidad del
arquitecto a pensar en el sistema antes de que se desarrolle. Si se hace bien, durante la fase de
diseño que se abordarán correctamente todos los problemas que se enfrenten en el desarrollo de
la solución.

A menudo hay muchas maneras de lograr algo. El arquitecto de una aplicación es el que decide qué
camino tomar, en base a la arquitectura global que ha elegido. Cuando el desarrollo se ha iniciado,
es responsabilidad del arquitecto realizar un seguimiento del desarrollo, para ver si todavía se
mantiene en consonancia con el diseño general.

El Arquitecto del Sistema


Al igual que el arquitecto de software, el Arquitecto del Sistema es responsable de pensar el sistema
antes de construirlo. Así como el arquitecto de software es responsable para el software, un
arquitecto del sistema es responsable del hardware. Muchas aplicaciones ejecutan completamente
en un único servidor. Muchos otros sin embargo se ejecutan en grupos de servidores, con servidores
dedicados de bases de datos, servidores web y balanceadores de carga. Un arquitecto del sistema
tiene en cuenta los requisitos de rendimiento y disponibilidad, el número de usuarios / visitantes,
etc. y en base a esto, diseña una infraestructura de servidores y una red.

El Desarrollador de Software
El desarrollo efectivo de una aplicación es hecho por los desarrolladores del equipo. Pero un
desarrollador tiene más responsabilidades que solo escribir código. Él es a menudo responsable de
hacer el seguimiento de su propio progreso, e informar al jefe de proyecto de los problemas a los
que se enfrenta. Él es también quien implementa las ideas del arquitecto, y como tal, puede tener
que discutir las (in)posibilidades de la implementación con el arquitecto.

Una responsabilidad importante es documentar el código. Mientras que muchos desarrolladores


piensan que la documentación es algo que será realizado mejor por alguien más, esta es en realidad
una responsabilidad importante del desarrollador.

La Documentación de Código tiene como objetivo el explicar a otros desarrolladores aquellas cosas
que no resulten evidentes o claras a partir de la lectura del propio código en sí. Se debe dar una idea
de por qué un fragmento de código es de la manera que es. El desarrollador es el único que conoce
los pensamientos e ideas detrás del código que escribe, lo cual lo convierte en el candidato perfecto
para documentarlo.

El Jefe de Desarrolladores
Un desarrollador líder, que tiene las mismas responsabilidades que los otros desarrolladores, pero
también tiene añadidas algunas más. Un desarrollador líder debe entrenar a los otros
desarrolladores, y ayudarles a resolver los problemas que puedan enfrentar. Este desarrollador, que
suele ser el miembro del equipo más experimentado, también será capaz de asegurarse de que la
ejecución sigue de cerca al diseño planteado, y no se dé lugar a lo que se denomina “invasión de
características” durante el desarrollo. El desarrollador líder tiene una gran influencia en la calidad
del código.

El Diseñador Gráfico
“Lo de dentro es lo que cuenta.”, es tan cierto, como que también la percepción de los usuarios
depende mucho de la mirada y la sensación que le produce una aplicación o sitio web. No importa
lo buena que la aplicación sea, si la interfaz es inconsistente, se sentirá menos robusto.
Es importante reconocer el papel del diseñador en un proyecto. Es bueno tener alguien encargado
de la disposición general de una aplicación. Esto puede ir desde el diseño completo de la interfaz de
usuario, hasta el definir sólo algunas directrices de interfaz de usuario que los desarrolladores deban
cumplir.

Incluso si el diseño está determinado por los desarrolladores, es una responsabilidad importante
crear un diseño consistente en toda la aplicación.

El Tester
Las pruebas son una parte importante para asegurar que el software funciona de la manera que
debería. El papel de ‘tester’ se realiza a menudo por los desarrolladores para los aspectos técnicos
y los usuarios para los aspectos funcionales. Un problema que surge de hacer a los desarrolladores
probar su propio código es que, no importa lo bueno que sean, se ven influidos por la forma de su
código fue creado. Cuando se prueba, se tendrá en cuenta esas mismas situaciones que que ya se
tuvieron en cuenta a la hora de escribirlo.

Si se prueba código de otra persona, se puede pensar en escenarios que la otra persona no los
pensó. Así que incluso si no se tiene un equipo de Testers dedicado, es una buena idea que cada
desarrollador pruebe código de otro desarrollador, en lugar del suyo propio.

El Gerente del Proyecto


Un gerente de proyecto tiene muchas responsabilidades. Es responsable de la planificación del
proyecto, de mantener el proyecto dentro del presupuesto, y de la solución de problemas. En
resumen, él resuelve cualquier problema que ponga en peligro el progreso del proyecto.

Muchas de las tareas del gerente del proyecto tienen que ver con la comunicación, la comunicación
al cliente sobre el progreso del proyecto y la comunicación con todos los miembros del equipo.
Incluso en los proyectos de desarrollo que no cuentan con un gerente de proyecto, es conveniente
asignar el rol de gerente de proyecto a alguien, para que quede claro quién es responsable de la
ejecución del mismo.

El Administrador de Cuentas
Si usted desarrolla proyectos para clientes, sus proyectos pueden beneficiarse de las funciones de
un Administrador de Cuentas. Un administrador de cuentas cultiva la relación con el cliente. Aunque
la gestión de proyectos y administración de cuentas se hace a menudo por la mismo persona dentro
de un proyecto, hay situaciones en las que ayuda a dividir estos roles.

Un administrador de cuentas puede mantener una relación más independiente con el cliente, y
avisar si el cliente no está contento con la forma en que se ejecuta el proyecto por parte del gerente
del proyecto.

Al separar los roles de Administrador de cuentas, y Gerente de proyecto,


también lograremos evitar conflictos de interés.
El director del proyecto puede concentrarse y proyectar lo mejor de sus habilidades para el
funcionamiento del proyecto, mientras que el administrador de cuentas puede tomarse el trabajo
de reconocer oportunidades comerciales.
El Administrador de sistemas
El sistema en que la aplicación será instalada es creado por un administrador del sistema.

Se arman los servidores, se instala el sistema operativo, un servidor web, PHP, una base de datos y
cualquier software adicional que se requiera.

Incluso antes de que el proyecto se haya terminado, un administrador del sistema puede tener
que construir los entornos de desarrollo y ambientes de prueba.

Más adelante en el proyecto, se ocupará de mantener los sistemas operando.

El Administrador de Código
El Código es importante y debe ser tratado como tal, el código necesita ser gestionado. Si varios
de los desarrolladores están trabajando en conjunto, el código que escriben debe integrarse en
algún momento, independientemente del sistema de control de versiones utilizado.

Además, cuando haya terminado, el proyecto debe ser implementado. La implementación del
proyecto significa tomar el código y desplegarlo en el servidor. Aunque usualmente no hay una
persona manejando esto, es importante identificar dicho rol.

El Capacitador
Cuando un proyecto se haya completado, los usuarios pueden necesitar ser capacitados, en
particular si en el proyecto se desarrollado una aplicación.

No es común capacitar a los usuarios de un sitio web, pero a menudo hay un back-end que los
administradores tendrán que ser aprender a usar.

El Capacitador relaciona las soluciones que se han creado con el usuario final.

Una importante responsabilidad del Capacitador es explicar cómo la aplicación resuelve el


problema del cliente y, como tal, juega un papel importante en asegurar que las expectativas del
cliente sobre el software están en línea con lo que ha sido creado.
RUP ¿Ágil o no?
Rational Unified Process (RUP) es una infraestructura de procesos que Rational Software ha
perfeccionado a lo largo de los años y que se ha utilizado ampliamente para todo tipo de
proyectos de software, fueran grandes o pequeños. Recientemente, un número creciente de
procesos "ágiles", como eXtreme Programming (XP), SCRUM, Feature-Driven Development (FDD) y
la metodología Crystal Clear, han ido adquiriendo reconocimiento como métodos eficaces para la
creación de sistemas más pequeños.

Las secciones siguientes se han concebido como una ayuda para los equipos de proyecto mediante
la evaluación de prácticas "ágiles" que se hayan hallado en uno de estos métodos para ver cómo
las tratan los procesos de desarrollo de software más completos definidos por RUP.

Manifiesto por el Desarrollo Ágil de Software


Estamos descubriendo formas mejores de desarrollar

software tanto por nuestra propia experiencia como

ayudando a terceros. A través de este trabajo hemos

aprendido a valorar:

Individuos e interacciones sobre procesos y herramientas

Software funcionando sobre documentación extensiva

Colaboración con el cliente sobre negociación contractual

Respuesta ante el cambio sobre seguir un plan

Esto es, aunque valoramos los elementos de la derecha,

valoramos más los de la izquierda.

Prácticas de XP compatibles con RUP


En las disciplinas en las que XP y RUP se solapan, las prácticas siguientes, que se describen en XP,
pueden emplearse en RUP, y en algunos casos ya se emplean.

El juego de la planificación: la guía de XP para la planificación puede utilizarse para alcanzar


muchos de los objetivos utilizados en la disciplina de gestión de proyectos de RUP para un
proyecto que sea muy pequeño. Esto es muy útil para los proyectos con un nivel bajo de
formalidad que no deben producir artefactos formales de gestión de proyectos de nivel
intermedio.

Diseño de primera prueba y refactorización: se trata de dos buenas técnicas que pueden aplicarse
en la disciplina de implementación de RUP. En concreto, la práctica de pruebas de XP, que
requiere del diseño de primera prueba, es una forma excelente de clarificar los requisitos con
mucho detalle. Como se verá en la siguiente sección, la refactorización puede no escalar
adecuadamente para los sistemas grandes.
Integración continuada: RUP da soporte a esta práctica por medio de compilaciones en el nivel de
sistema y de subsistema (dentro de una iteración). Componentes probados en unidades se
integran y se prueban en el contexto del sistema emergente.

Cliente in situ: muchas de las actividades de RUP pueden aprovechar en gran medida la presencia
de un cliente in situ como miembro del equipo, lo que reducirá el número de entregas intermedias
necesarias, en especial, de documentos. Al igual que su favorito medio de comunicación entre el
desarrollador y el cliente, XP favorece la opción de la conversación, que depende de la continuidad
y de la familiaridad para tener éxito; sin embargo, cuando un sistema, incluso uno pequeño, tiene
que sufrir una transición, se necesitará más que conversaciones. XP permite abordar este tipo de
cuestiones a posteriori mediante, por ejemplo, documentos de diseño al final del proyecto.
Aunque no prohíbe la producción de documentos u otro tipo de artefactos, XP indica que debe
producir sólo los que verdaderamente necesite. RUP coincide, pero lo lleva más allá y describe lo
que necesitará cuando la continuidad y la familiaridad no son ideales.

Estándares de codificación: RUP tiene directrices para la programación de artefactos que deben
observarse casi siempre como si fuesen obligatorias. (La mayoría de los perfiles de riesgo de
proyectos, al ser uno de los principales factores de la personalización, harían que lo fuesen).

Semana de cuarenta horas: como en XP, RUP sugiere que el trabajar horas extras no debe ser una
condición crónica. XP no sugiere un límite estricto en las 40 horas, pues reconoce distintas
tolerancias en las jornadas de trabajo. Los ingenieros de software son tristemente famosos por sus
jornadas con muchas horas extra sin compensación, simplemente por la satisfacción de ver que
han completado alguna parte, y sus responsables no tienen por qué detener ese impulso de forma
arbitraria. Lo que los directores no deben es explotar esta práctica o imponerla. Deben recopilar
constantemente mediciones de las horas trabajadas realmente, aunque no se compensen. Si el
registro de horas trabajadas parece alto durante un periodo extendido, debe investigarse; sin
embargo, estas son cuestiones que resolver en las circunstancias en las que se den, entre el
individuo y su director, con un reconocimiento de las preocupaciones que puedan derivarse para
el resto del equipo. Las cuarenta horas no son más que una guía, pero son una guía muy sólida.

Programación de dos en dos: XP sostiene que la programación de dos en dos es beneficiosa para la
calidad del código, y que una vez que se adquiere, se disfruta más de esta habilidad. RUP no
describe los mecanismos de la producción de código de una forma tan granulada, aunque sería
ciertamente posible utilizar la programación de dos en dos en un proceso basado en RUP. RUP es
ahora quien proporciona parte de la información sobre programación de dos en dos, así como el
diseño de primera prueba y la refactorización, en la forma de documentación. Obviamente, el uso
de estas prácticas en RUP no es un requisito, sin embargo, en un entorno de equipo, con una
cultura de comunicación abierta, significaría la sospecha de que las ventajas de la programación de
dos en dos (en términos del efecto sobre los costes del ciclo vital total) sería difícil de discernir. El
personal se reúne para hablar de los problemas y para resolverlos de una forma muy natural en un
equipo que funciona bien, sin estar obligado a ello.

La insinuación de que el proceso adecuado debe imponerse en el nivel "micro" suele ser mal
recibida y puede no ser bien recibida en algunas culturas de empresa. RUP, por tanto, no aboga
por la imposición estricta. Sin embargo, en algunas circunstancias, el trabajo en pareja, y algunas
de las otras prácticas basadas en equipos recomendadas en XP, son claramente beneficiosas, ya
que cada miembro del equipo puede ayudar al otro, por ejemplo:

 los primeros días de la formación del equipo, cuando las personas se están conociendo
 los equipos sin experiencia en alguna nueva tecnología
 los equipos compuestos por personal muy experimentado y por novicios
UTILIZANDO RUP EN PROYECTOS PEQUEÑOS
David Kohrell, miembro de la IBM Scholar Network afirma que la metodología RUP puede
adaptarse a todo tipo de proyectos, es decir, puede ser utilizada tanto para proyectos corporativos
de gran alcance como para organizar la información y solicitudes de cambio en proyectos
pequeños.

TAP (Technology as Promised) University es un proyecto que consiste en la implementación de un


sistema en línea de gestión de cursos. El propósito de TAP University es el de extender el
entrenamiento Cara-a-Cara proveído por los asociados de TAP a sus clientes corporativos y
expandir su oferta de productos en-línea a corporaciones, clientes y estudiantes.

Se le considera un proyecto pequeño. Toma ventaja de la plataforma de código abierto para


gestión de cursos Moodle con algunas modificaciones. El documento visión para este proyecto fue
expuesto por primera vez en Febrero 22 del 2005 y el plan de proyecto, completado el 3 de Mayo
de 2005, incluyendo los recursos necesarios, costo y alcance.

Iteración Fecha de Lanzamiento


1. Sistema de Gestión de Cursos listo para Mayo 23, 2005
hospedar cursos
a) Casos de uso:
 Administrar Sistema de Gestión
 Ingresar Contenido
 Gestionar Usuarios – cargar
instructores y estudiantes
b) Actores
 Instructores
 Administradores de Sistema
 Estudiantes

2. Registro de estudiantes y e-Commerce Junio 20, 2005


a) Casos de Uso:
 Registrar estudiantes
 Procesar pagos
 Activar cursos
b) Actores:
 Mismos que en #1 mas
 Sistema de Validación de Tarjeta de
Crédito
 Sistema de Acreditación

3. Extensiones y Modificación de Cursos Agosto 15, 2005


a) Casos de Uso
 Modificar cursos
 Interfaz para instituciones
b) Actores
 Mismos que en #1 y #2 mas
 Sistema Institucional
Partiendo de la idea inicial hasta la implementación, este producto requiere menos de seis meses;
desde la concepción inicial del proyecto hasta llevarlo a su capacidad de total functionamiento, el
proyecto estipuló soportar este producto por 90 días.

Hay ocho recursos envueltos, el número de horas total estimado para completar este proyecto es
de 652 horas y el costo de aproximadamente $15,000.

RUP sirvió a este proyecto de dos formas:

1. RUP ofreció un marco de trabajo (framework) en términos de iteraciones y organización


de casos de uso. Los casos de uso mostrados en la tabla anterior en conjunto con un plan
de proyectos de dos páginas, constituyen la documentación. El servidor donde se hospeda
el Sistema de Gestión de Cursos sirvió como repositorio compartido.
2. RUP permitió el comenzar la etapa de Construcción y Transición incluso cuándo solo el
80% de los requerimientos eran conocidos. Por ejemplo, hay tres alternativas para la
implementación del e-Commerce bajo evaluación. La decisión de qué herramienta utilizar
para la gestión e-Commerce no nos priva de completar la iteración 1. Es decir, desde la
iteración 1, los clientes privados corporativos ya pueden usar la aplicación.
4 DISCIPLINAS: RUP PROCESO EN 4 FASES
DURANTE LA FASE DE INICIO las iteraciones hacen mayor énfasis en actividades de modelado del
negocio y de requerimientos.

EN LA FASE DE ELABORACIÓN, las iteraciones se orientan al desarrollo de la baseline de la


arquitectura, abarcan más los flujos de trabajo de requerimientos, modelo de negocios
(refinamiento), análisis, diseño y una parte de implementación orientado a la baseline de la
arquitectura.

EN LA FASE DE CONSTRUCCIÓN se lleva a cabo la construcción del producto por medio de una
serie de iteraciones.

Para cada iteración se selecciona algunos Casos de Uso, se refina su análisis y diseño y se procede
a su implementación y pruebas. Se realiza una pequeña cascada para cada ciclo. Se realizan tantas
iteraciones hasta que se termine la implementación de la nueva versión del producto.

EN LA FASE DE TRANSICIÓN se pretende garantizar que se tiene un producto preparado para su


entrega a la comunidad de usuarios.

Como se puede observar en cada fase participan todas las disciplinas, pero que dependiendo de la
fase el esfuerzo dedicado a una disciplina varía.

La metodología RUP es más apropiada para proyectos grandes (Aunque también pequeños), dado
que requiere un equipo de trabajo capaz de administrar un proceso complejo en varias etapas.

En proyectos pequeños, es posible que no se puedan cubrir los costos de dedicación del equipo de
profesionales necesarios.
PLANIFICACIÓN INTEGRAL DE LOS OBJETIVOS (PIO)
Objetivo General: Optimizar el sistema de información para la gestión de inscripción de participantes CE_GESTIÓN, en el Centro de Capacitación Laboral Simón
Rodríguez, El Tigre, estado Anzoátegui.
Objetivo específico Metodología Actividad Producto
Diagnosticar la situación actual del proceso RUP/Inicio 1. Asignar roles al equipo de investigación Documento Visión
de inscripción de nuevos participantes 2. Aplicar técnicas de recolección de datos
3. Aclaración del proceso actual
llevado a cabo en el Centro de Capacitación
4. Estudio de factibilidad técnica, operativa y económica
Laboral Simón Rodríguez , El Tigre , Estado 5. Realizar análisis de riesgo
Anzoátegui por medio de CE_GESTIÓN. 6. Planteamiento de la solución propuesta
7. Planeación de la propuesta (Diagrama Grantt)
8. Aprobación de la solicitud
9. Iteración 1

Definir los nuevos requerimientos del sistema RUP/Inicio 10. Definir requerimientos funcionales del sistema Requerimientos del sistema CE
de inscripción CE_GESTIÓN, implantado en 11. Definir requerimientos no funcionales del sistema
12. Iteración 2 Gestión
el Centro de Capacitación Laboral Simón
Rodríguez , El Tigre , Estado Anzoátegui.

Realizar modelado del Sistema de RUP/Elaboración 13. Establecer casos de uso del sistema Modelado completo del sistema
14. Diagrama de colaboración
Inscripción CE_GESTIÓN implantado 15. Elaborar Diagrama de Actividades de inscripción CE Gestión
en el Centro de Capacitación Laboral 16. Diseñar modelo Entidad-Relación Extendido
Simón Rodríguez , El Tigre , Estado 17. Diseñar Modelo Relacional
18. Elaborar Diagrama de Clases
Anzoátegui. 19. Elaborar Diccionario de Datos
20. Elaborar diagrama de Secuencia de Datos
21. Elaborar Diagrama Navegacional
22. Modelo de despliegue
23. Definir Prototipos de Pantalla

Codificar los Módulos para expandir el RUP/Construcción 24. Definir lenguaje de programación a utilizar Sistema de inscripción CE
Sistema de Inscripción CE_GESTIÓN, 25. Iteración 3
26. Programar base de datos Gestión
implantado en el Centro de Capacitación
27. Programar módulos que integran el sistema
Laboral Simón Rodríguez , El Tigre , Estado 28. Iteración 4
Anzoátegui. 29. Realizar conexión entre el sistema y la base de datos

Implementar nuevos módulos y RUP/Transición 30. Entrega e instalación del sistema Manual de instalación
actualizaciones en el Sistema de Inscripción 31. Realizar pruebas al sistema
32. Elaborar manuales (de instalación, de usuario) Manual de usuario
CE_GESTIÓN implantado en el Centro de Sistema instalado
33. Capacitación de personal
Capacitación Laboral Simón Rodríguez , El
Tigre , Estado Anzoátegui.
Capacitación de personal