SISTEMA DE CONTROL DE PENSIONES INSTITUTO CEC

2.1 ANTECEDENTES DE LA ORGANIZACIN El instituto ICEI (Instituto de Capacitacin en Electrnica e Informtica), como parte de la formacin acadmica, requiere tecnologas que manejen y optimicen el tiempo en el pago de pensiones que realiza un usuario, y as asegurar la calidad de la misma, para lo cual se ha pensado en un sistema de control de pago de pensiones, lo cual permitir interactuar con los usuarios procesando sus peticiones. Se utilizar el organigrama para mostrar en qu nivel dentro de la estructura jerrquica se encuentra el rea en el cual se desarrolla el sistema de control de pago de pensiones del El instituto ICEI. La estructura organizativa del El instituto ICEI se halla configurada de la siguiente manera: Estructura Orgnica del El instituto ICEI

Direccion general

Direcion academica

kardex

secretaria

direccion de carreras

cordinador de materias y horarios

docentes por modulos

2.2 METODOLOGIAS 2.2.1 XP (programacin Extrema) Es un proceso ligero, gil, de bajo riesgo, flexible, predecible, cientfico y divertido de desarrollar software. Est orientado hacia quien produce y usa el software (retroalimentacin continua cliente y desarrollador). Reduce el costo del cambio en todas las etapas del ciclo de vida del sistema. Combina las que han demostrado ser las mejores prcticas para desarrollar software, y las lleva al extremo.

2.2.1.1 Roles XP 2.2.1.1 .1Programador El programador escribe las pruebas unitarias y produce el cdigo del sistema. Debe existir una comunicacin y coordinacin adecuada entre los programadores y otros miembros del equipo. 2.2.1.1 .2 Cliente El cliente escribe las historias de usuario y las pruebas funcionales para validar su implementacin. Adems, asigna la prioridad a las historias de usuario y decide cules se implementan en cada iteracin centrndose en aportar mayor valor al negocio. 2.2.1.1 .3 Encargado de pruebas (Tester) El encargado de pruebas ayuda al cliente a escribir las pruebas funcionales. Ejecuta las pruebas regularmente, difunde los resultados en el equipo y es responsable de las herramientas de soporte para pruebas. 2.2.1.1 .3 Encargado de seguimiento (Tracker) El encargado de seguimiento proporciona realimentacin al equipo en el proceso XP. Su responsabilidad es verificar el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, comunicando los resultados para mejorar futuras estimaciones. Tambin realiza el seguimiento del progreso de cada iteracin y evala si los objetivos son alcanzables con las restricciones de tiempo y recursos presentes. Determina cundo es necesario realizar algn cambio para lograr los objetivos de cada iteracin. 2.2.1.1 .4 Entrenador (Coach) Es responsable del proceso global. Es necesario que conozca a fondo el proceso XP para proveer guas a los miembros del equipo de forma que se apliquen las prcticas XP y se siga el proceso correctamente. 2.2.1.1 .5 Consultor Es un miembro externo del equipo con un conocimiento especfico en algn tema necesario para el proyecto. Gua al equipo para resolver un problema especfico. 2.2.1.1 .6 Gestor (Big boss) Es el vnculo entre clientes y programadores, ayuda a que el equipo trabaje efectivamente creando las condiciones adecuadas. Su labor esencial es de coordinacin.

2.2.1.1 .7 Proceso XP Un proyecto XP tiene xito cuando el cliente selecciona el valor de negocio a implementar basado en la habilidad del equipo para medir la funcionalidad que puede entregar a travs del tiempo. El ciclo de desarrollo consiste (a grandes rasgos) en los siguientes pasos: 1. El cliente define el valor de negocio a implementar. 2. El programador estima el esfuerzo necesario para su implementacin. 3. El cliente selecciona qu construir, de acuerdo con sus prioridades y las restricciones de tiempo. 4. El programador construye ese valor de negocio. 5. Vuelve al paso 1. 2.2.1.2 Fase I: Exploracin En esta fase, los clientes plantean a grandes rasgos las historias de usuario que son de inters para la primera entrega del producto. Al mismo tiempo el equipo de desarrollo se familiariza con las herramientas, tecnologas y prcticas que se utilizarn en el proyecto. Se prueba la tecnologa y se exploran las posibilidades de la arquitectura del sistema construyendo un prototipo. La fase de exploracin toma de pocas semanas a pocos meses, dependiendo del tamao y familiaridad que tengan los programadores con la tecnologa. 2.2.1.2 Fase II: Planificacin de la Entrega En esta fase el cliente establece la prioridad de cada historia de usuario, y correspondientemente, los programadores realizan una estimacin del esfuerzo necesario de cada una de ellas. Se toman acuerdos sobre el contenido de la primera entrega y se determina un cronograma en conjunto con el cliente. Una entrega debera obtenerse en no ms de tres meses. Esta fase dura unos pocos das.

2.2.1.3 Fase III: Iteraciones Esta fase incluye varias iteraciones sobre el sistema antes de ser entregado. El Plan de Entrega est compuesto por iteraciones de no ms de tres semanas. En la primera iteracin se puede intentar establecer una arquitectura del sistema que pueda ser utilizada durante el resto del proyecto. Esto se logra escogiendo las historias que fuercen la creacin de esta arquitectura, sin embargo, esto no siempre es posible ya que es el cliente quien decide qu historias se implementarn en cada iteracin (para maximizar el valor de negocio). Al final de la ltima iteracin el sistema estar listo para entrar en produccin. Los elementos que deben tomarse en cuenta durante la elaboracin del Plan de la Iteracin son: historias de usuario no abordadas, velocidad del proyecto, pruebas de aceptacin no superadas en la iteracin anterior y tareas no terminadas en la iteracin anterior. Todo el trabajo de la iteracin es expresado en tareas de programacin, cada una de ellas es asignada a un programador como responsable, pero llevadas a cabo por parejas de programadores.

2.2.1.4 Fase IV: Produccin La fase de produccin requiere de pruebas adicionales y revisiones de rendimiento antes de que el sistema sea trasladado al entorno del cliente. Al mismo tiempo, se deben tomar decisiones sobre la inclusin de nuevas caractersticas a la versin actual, debido a cambios durante esta fase. Es posible que se rebaje el tiempo que toma cada iteracin, de tres a una semana. Las ideas que han sido propuestas y las sugerencias son documentadas para su posterior implementacin (por ejemplo, durante la fase de mantenimiento). 2.2.1.2.5 Fase V: Mantenimiento Mientras la primera versin se encuentra en produccin, el proyecto XP debe mantener el sistema en funcionamiento al mismo tiempo que desarrolla nuevas iteraciones. Para realizar esto se requiere de tareas de soporte para el cliente. De esta forma, la velocidad de desarrollo puede bajar despus de la puesta del sistema en produccin. La fase de mantenimiento puede requerir nuevo personal dentro del equipo y cambios en su estructura. 2.2.1.2.6 Fase VI: Muerte del Proyecto Es cuando el cliente no tiene ms historias para ser incluidas en el sistema. Esto requiere que se satisfagan las necesidades del cliente en otros aspectos como rendimiento y confiabilidad del sistema. Se genera la documentacin final del sistema y no se realizan ms cambios en la arquitectura. La muerte del proyecto tambin ocurre cuando el sistema no genera los beneficios esperados por el cliente o cuando no hay presupuesto para mantenerlo. 2.2.1.7 El juego de la planificacin Es un espacio frecuente de comunicacin entre el cliente y los programadores. El equipo tcnico realiza una estimacin del esfuerzo requerido para la implementacin de las historias de usuario y los clientes deciden sobre el mbito y tiempo de las entregas y de cada iteracin. 2.2.1.8 Entregas pequeas La idea es producir rpidamente versiones del sistema que sean operativas, aunque obviamente no cuenten con toda la funcionalidad pretendida para el sistema pero s que constituyan un resultado de valor para el negocio. Una entrega no debera tardar ms 3 meses. 2.2.1.9 Diseo simple Se debe disear la solucin ms simple que pueda funcionar y ser implementada en un momento determinado del proyecto. La complejidad innecesaria y el cdigo extra debe ser removido inmediatamente.

2.2.1.10 Pruebas La produccin de cdigo est dirigida por las pruebas unitarias. Las pruebas unitarias son establecidas antes de escribir el cdigo y son ejecutadas constantemente ante cada modificacin del sistema. Los clientes escriben las pruebas funcionales para cada historia de usuario que deba validarse. En este contexto de desarrollo evolutivo y de nfasis en pruebas constantes, la automatizacin para apoyar esta actividad es crucial. 2.2.1.11 Programacin en parejas Toda la produccin de cdigo debe realizarse con trabajo en parejas de programadores. las principales ventajas de introducir este estilo de programacin son: muchos errores son detectados conforme son introducidos en el cdigo (inspecciones de cdigo continuas), por consiguiente la tasa de errores del producto final es ms baja, los diseos son mejores y el tamao del cdigo menor (continua discusin de ideas de los programadores). 2.2.1.12 Propiedad colectiva del cdigo Cualquier programador puede cambiar cualquier parte del cdigo en cualquier momento. Esta prctica motiva a todos a contribuir con nuevas ideas en todos los segmentos del sistema, evitando a la vez que algn programador sea imprescindible para realizar cambios en alguna porcin de cdigo. 2.2.1.13 horas por semana Se debe trabajar un mximo de 40 horas por semana. No se trabajan horas extras en dos semanas seguidas. Si esto ocurre, probablemente est ocurriendo un problema que debe corregirse. El trabajo extra desmotiva al equipo. Los proyectos que requieren trabajo extra para intentar cumplir con los plazos suelen al final ser entregados con retraso. En lugar de esto se puede realizar el juego de la planificacin para cambiar el mbito del proyecto o la fecha de entrega. 2.2.1.14 Cliente in-situ El cliente tiene que estar presente y disponible todo el tiempo para el equipo. Gran parte del xito del proyecto XP se debe a que es el cliente quien conduce constantemente el trabajo hacia lo que aportar mayor valor de negocio y los programadores pueden resolver de manera inmediata cualquier duda asociada. La comunicacin oral es ms efectiva que la escrita, ya que esta ltima toma mucho tiempo en generarse y puede tener ms riesgo de ser mal interpretada. 2.2.1.15 Estndares de programacin XP enfatiza la comunicacin de los programadores a travs del cdigo, con lo cual es indispensable que se sigan ciertos estndares de programacin (del equipo, de la organizacin u

otros estndares reconocidos para los lenguajes de programacin utilizados). Los estndares de programacin mantienen el cdigo legible para los miembros del equipo, facilitando los cambios.

2.3 RUP Las siglas RUP en ingles significa Rational Unified Process (Proceso Unificado de Rational) es un producto del proceso de ingeniera de software que proporciona un enfoque disciplinado para asignar tareas y responsabilidades dentro de una organizacin del desarrollo. Su meta es asegurar la produccin del software de alta calidad que resuelve las necesidades de los usuarios dentro de un presupuesto y tiempo establecidos.

Figura 1. Disciplinas, fases, iteraciones del RUP

Se puede hacer mencin de las tres caractersticas esenciales que definen al RUP: a) Proceso Dirigido por los Casos de Uso: Con esto se refiere a la utilizacin de los Casos de Uso para el desenvolvimiento y desarrollo de las disciplinas con los artefactos, roles y actividades necesarias. b) Un Caso de Uso es una secuencia de pasos a seguir para la realizacin de un fin o propsito, y se relaciona directamente con los requerimientos, ya que un Caso de Uso es la secuencia de pasos que conlleva la realizacin e implementacin de un Requerimiento planteado por el Cliente. c) Proceso Iterativo e Incremental: Es el modelo utilizado por RUP para el desarrollo de un proyecto de software. Este modelo plantea la implementacin del proyecto a realizar en Iteraciones, con lo cual se pueden definir objetivos por cumplir en cada iteracin y as poder ir completando todo el proyecto iteracin por iteracin, con lo cual se tienen varias ventajas, entre ellas se puede mencionar la de tener pequeos avances del proyectos que son entregables al cliente el cual puede probar mientras se est desarrollando otra iteracin del proyecto, con lo cual el proyecto va creciendo hasta completarlo en su totalidad. Este proceso se explica ms adelante a detalle. d) Proceso Centrado en la Arquitectura: Define la Arquitectura de un sistema, y una arquitectura ejecutable construida como un prototipo evolutivo. Arquitectura de un sistema es la organizacin o estructura de sus partes ms relevantes. Una arquitectura ejecutable es una implementacin parcial del sistema, construida para demostrar algunas funciones y propiedades. RUP establece refinamientos sucesivos de una arquitectura ejecutable, construida como un prototipo evolutivo. 2.3.1 FASES El ciclo de vida del software del RUP se descompone en cuatro fases secuenciales (figura 2). En cada extremo de una fase se realiza una evaluacin (actividad: Revisin del ciclo de vida de la finalizacin de fase) para determinar si los objetivos de la fase se han cumplido. Una evaluacin satisfactoria permite que el proyecto se mueva a la prxima fase.

Fig. 2Fases del RUP 2.3.1.1 Planeando las fases 1. Concepcin, Inicio o Estudio de oportunidad Define el mbito y objetivos del proyecto Se define la funcionalidad y capacidades del producto 2.3.1.2 Elaboracin Tanto la funcionalidad como el dominio del problema se estudian en profundidad Se define una arquitectura bsica

Se planifica el proyecto considerando recursos disponibles 2.2.1.1 .7 Proceso XP Un proyecto XP tiene xito cuando el cliente selecciona el valor de negocio a implementar basado en la habilidad del equipo para medir la funcionalidad que puede entregar a travs del tiempo. El ciclo de desarrollo consiste (a grandes rasgos) en los siguientes pasos: 1. El cliente define el valor de negocio a implementar. 2. El programador estima el esfuerzo necesario para su implementacin. 3. El cliente selecciona qu construir, de acuerdo con sus prioridades y las restricciones de tiempo. 4. El programador construye ese valor de negocio. 5. Vuelve al paso 1. 2.2.1.2 Fase I: Exploracin En esta fase, los clientes plantean a grandes rasgos las historias de usuario que son de inters para la primera entrega del producto. Al mismo tiempo el equipo de desarrollo se familiariza con las herramientas, tecnologas y prcticas que se utilizarn en el proyecto. Se prueba la tecnologa y se exploran las posibilidades de la arquitectura del sistema construyendo un prototipo. La fase de exploracin toma de pocas semanas a pocos meses, dependiendo del tamao y familiaridad que tengan los programadores con la tecnologa. 2.2.1.2 Fase II: Planificacin de la Entrega En esta fase el cliente establece la prioridad de cada historia de usuario, y correspondientemente, los programadores realizan una estimacin del esfuerzo necesario de cada una de ellas. Se toman acuerdos sobre el contenido de la primera entrega y se determina un cronograma en conjunto con el cliente. Una entrega debera obtenerse en no ms de tres meses. Esta fase dura unos pocos das.

2.2.1.3 Fase III: Iteraciones Esta fase incluye varias iteraciones sobre el sistema antes de ser entregado. El Plan de Entrega est compuesto por iteraciones de no ms de tres semanas. En la primera iteracin se puede intentar establecer una arquitectura del sistema que pueda ser utilizada durante el resto del proyecto. Esto se logra escogiendo las historias que fuercen la creacin de esta arquitectura, sin embargo, esto no siempre es posible ya que es el cliente quien decide qu historias se implementarn en cada iteracin (para maximizar el valor de negocio). Al final de la ltima iteracin el sistema estar listo para entrar en produccin. Los elementos que deben tomarse en cuenta durante la elaboracin del Plan de la Iteracin son: historias de usuario no abordadas, velocidad del proyecto, pruebas de aceptacin no superadas en la iteracin anterior y tareas no terminadas en la iteracin anterior. Todo el trabajo de la iteracin

es expresado en tareas de programacin, cada una de ellas es asignada a un programador como responsable, pero llevadas a cabo por parejas de programadores. 2.2.1.3.1 Construccin El producto se desarrolla a travs de iteraciones donde cada iteracin involucra tareas de 2.2.1.3.2 anlisis, diseo e implementacin Las fases de estudio y anlisis slo dieron una arquitectura bsica que es aqu refinada de 2.2.1.3.3 manera incremental conforme se construye (se permiten cambios en la estructura) Gran parte del trabajo es programacin y pruebas. Se documenta tanto el sistema construido como el manejo del mismo. Esta fase proporciona un producto construido junto con la documentacin 2.2.1.3.4 Transicin Se libera el producto y se entrega al usuario para un uso real. Se incluyen tareas de marketing, empaquetado atractivo, instalacin, configuracin, 2.2.1.3.5 mantenimiento, soporte, etc. Los manuales de usuario se completan y refinan con la informacin anterior Estas tareas se realizan tambin en iteraciones Todas las fases no son idnticas en trminos de tiempo y esfuerzo. Aunque esto vara considerablemente dependiendo del proyecto, un ciclo de desarrollo inicial tpico para un proyecto de tamao mediano debe anticipar la distribucin siguiente el esfuerzo y horario:

En un ciclo evolutivo, las fases de concepcin y elaboracin seran considerablemente ms pequeas.

Ciclo evolutivo en la elaboracin de software basado en el RUP Los ciclos evolutivos pueden ser iniciados por las mejoras sugeridas por el usuario, cambios en el contexto del usuario, cambios en la tecnologa subyacente, reaccin a la competicin, etctera. 1. Esfuerzo respecto de los flujos de trabajo De forma vertical se muestra el esfuerzo que se tiene que realizar por cada una de las disciplinas o flujos de trabajo, y los dos porcentajes que se muestran de forma horizontal son para todo el proyecto. Explicando mas puntualmente se puede observar en la figura que para la obtencin de requerimientos o requisitos en la fase de concepcin se empiezan a obtener, en la fase de elaboracin tiene su auge y va declinando en la fase de construccin, realizar todo esto requiere aproximadamente un 15% de esfuerzo, y as sucesivamente con las dems disciplinas. En esta seccin y la siguiente, los porcentajes pueden variar de un proyecto a otro.

2. Esfuerzo respecto de las fases El esfuerzo realizado por cada fase en forma general e incluyendo las iteraciones dentro de cada fase; y en la segunda fila, la duracin que tiene aproximadamente en porcentajes del tiempo total del proyecto para cada una de las fases incluyendo todas las iteraciones que conlleven realizar cada fase. Explicando ms puntualmente una pequea parte de la figura se puede observar que para la fase de construccin se tiene que dedicar ms esfuerzo y mayor duracin, siempre y

cuando dependiendo de qu disciplina estemos ejecutando, por ejemplo en la disciplina de implementacin se tiene mucho auge en la fase de construccin.

3. Iteraciones El RUP maneja el proceso Iterativo Incremental para el desarrollo de las aplicaciones o proyectos, por tal motivo es de suma importancia explicar brevemente en qu consiste este proceso. 4. Proceso Iterativo e Incremental Este proceso se refiere a la realizacin de un ciclo de vida de un proyecto y se basa en la evolucin de prototipos ejecutables que se muestran a los usuarios y clientes. En este ciclo de vida iterativo a cada iteracin se reproduce el ciclo de vida en cascada a menor escala, estableciendo los objetivos de una iteracin en funcin de la evaluacin de las iteraciones precedentes y las actividades se encadenan en una mini-cascada con un alcance limitado por los objetivos de la iteracin. En la figura 7 se muestran los pasos a realizar para seguir el ciclo de vida iterativo incremental, hasta la realizacin de una fase.

5. Comparacin entre 2 enfoques El ciclo de Cascada, en el cual cada disciplina se realiza al finalizar su predecesora y solo al finalizar la nueva se empieza la sucesora y hasta terminar con las disciplinas necesarias.

El ciclo de vida de un software siguiendo el enfoque Iterativo Incremental (utilizado por el RUP), en el cual se puede observar que en cada iteracin se realiza una pequea parte de cada disciplina en paralelo, aumentando poco a poco hasta concluir con la realizacin, todas las disciplinas con un numero de iteraciones prudente.

6. Disciplinas Las disciplinas conllevan los flujos de trabajo, los cuales son una secuencia de pasos para la culminacin de cada disciplina, estas disciplinas se dividen en dos grupos: las primarias y las de apoyo. Las primarias son las necesarias para la realizacin de un proyecto de software, aunque para proyectos no muy grandes se pueden omitir algunas; entre ellas se tienen: Modelado del Negocio, Requerimientos, Anlisis y Diseo, Implementacin, Pruebas, Despliegue. Las de apoyo son las que como su nombre lo indica sirven de apoyo a las primarias y especifican otras caractersticas en la realizacin de un proyecto de software; 2.3.2 MODELADO DEL NEGOCIO Esta disciplina tiene como objetivos comprender la estructura y la dinmica de la organizacin, comprender problemas actuales e identificar posibles mejoras, comprender los procesos de negocio. Utiliza el Modelo de CU del Negocio para describir los procesos del negocio y los clientes, el Modelo de Objetos del Negocio para describir cada CU del Negocio con los Trabajadores, adems utilizan los Diagramas de Actividad y de Clases. 1.Requerimientos Esta disciplina tiene como objetivos establecer lo que el sistema debe hacer (Especificar Requisitos), definir los lmites del sistema, y una interfaz de usuario, realizar una estimacin del costo y tiempo de desarrollo. Utiliza el Modelo de CU para modelar el Sistema que

comprenden los CU, Actores y Relaciones, adems utiliza los diagramas de Estados de cada CU y las especificaciones suplementarias. 2.Anlisis y diseo Esta disciplina define la arquitectura del sistema y tiene como objetivos trasladar requisitos en especificaciones de implementacin, al decir anlisis se refiere a transformar CU en clases, y al decir diseo se refiere a refinar el anlisis para poder implementar los diagramas de clases de anlisis de cada CU, los diagramas de colaboracin de de cada CU, el de clases de diseo de cada CU, el de secuencia de diseo de CU, el de estados de las clases, el modelo de despliegue de la arquitectura. 3. Implementacin Esta disciplina tiene como objetivos implementar las clases de diseo como componentes (ej. fichero fuente), asignar los componentes a los nodos, probar los componentes individualmente, integrar los componentes en un sistema ejecutable (enfoque incremental). Utiliza el Modelo de Implementacin, conjuntamente los Diagramas de Componentes para comprender cmo se organizan los Componentes y dependen unos de otros. 4. Pruebas Esta disciplina tiene como objetivos verificar la integracin de los componentes (prueba de integracin), verificar que todos los requisitos han sido implementados (pruebas del sistema), asegurar que los defectos detectados han sido resueltos antes de la distribucin. 5. Despliegue Esta disciplina tiene como objetivos asegurar que el producto est preparado para el cliente, proceder a su entrega y recepcin por el cliente. En esta disciplina se realizan las actividades de probar el software en su entorno final (Prueba Beta), empaquetarlo, distribuirlo e instalarlo, as como la tarea de ensear al usuario. 6. Gestin y configuracin de cambios Es esencial para controlar el nmero de artefactos producidos por la cantidad de personal que trabajan en un proyecto conjuntamente. Los controles sobre los cambios son de mucha ayuda ya que evitan confusiones costosas como la compostura de algo que ya se haba arreglado etc., y aseguran que los resultados de los artefactos no entren en conflicto con algunos de los siguientes tipos de problemas: Actualizacin simultnea: Es la actualizacin de algo elaborado con anterioridad, sin saber que alguien ms lo est actualizando Notificacin limitada: Al realizar alguna modificacin, no se deja informacin sobre lo que se hizo, por lo tanto no se sabe quien, como, y cuando se hizo. Versiones mltiples: No saber con exactitud, cual es la ltima versin, y al final no se tiene un orden sobre que modificaciones se han realizado a las diversas versiones.

7. Gestin del proyecto Su objetivo es equilibrar los objetivos competitivos, administrar el riesgo, y superar restricciones para entregar un producto que satisface las necesidades de ambos clientes con xito (los que pagan el dinero) y los usuarios. Con la Gestin del Proyecto se logra una mejora en el manejo de una entrega exitoso de software. En resumen su propsito consiste en proveer pautas para:

o Administrar proyectos de software intensivos. o Planear, dirigir personal, ejecutar acciones y supervisar proyectos. o Administrar el riesgo. Sin embargo, esta disciplina no intenta cubrir todos los aspectos de direccin del proyecto. Por ejemplo, no cubre problemas como: o Administracin de personal: contratando, entrenando, enseando. o Administracin del presupuesto: definiendo, asignando. o Administracin de los contratos con proveedores y clientes. o 8. Entorno Esta disciplina se enfoca sobre las actividades necesarias para configurar el proceso que engloba el desarrollo de un proyecto y describe las actividades requeridas para el desarrollo de las pautas que apoyan un proyecto. Su propsito es proveer a la organizacin que desarrollar el software, un ambiente en el cual basarse, el cual provee procesos y herramientas para poder desarrollar el software. 9. Organizacin y elementos en RUP: Ya conociendo varias partes del RUP nos concentraremos ahora en los elementos que lo componen, entre estos se tienen: Flujos de Trabajo, Detalle de los Flujos de Trabajo, Actores, Actividades y Artefactos. En la figura 10 se muestran ms claramente como se representan grficamente cada uno de estos elementos y la interrelacin entre ellos. Se puede observar que el Flujo de Trabajo de Requerimientos conlleva varios pasos, cada uno de estos pasos tiene asociado uno o varios actores, los cuales a su vez son los encargados de la ejecucin de varias actividades, las cuales a la vez estn definidas artefactos o guas para su realizacin.

2.3.3. Actores o roles Son los personajes encargados de la realizacin de las actividades definidas dentro de los flujos de trabajo de cada una de las disciplinas del RUP, estos actores se dividen en varias categoras: Analistas, Desarrolladores, Probadores, Encargados, Otros actores. A continuacin se presenta una lista de actores de acorde a las categoras mencionadas con anterioridad:

1. Analistas a) Analista del Proceso del Negocio. b) Diseador del Negocio. c) Revisor del Modelo del Negocio. d) Revisor de Requerimientos Analista del Sistema. e) Especificador de Casos de Uso. f) Diseador de Interfaz del Usuario 2. Desarrolladores Arquitecto Revisor de la Arquitectura Diseador de Cpsulas Revisor del Cdigo y Revisor del Diseo Diseador de la Base de Datos Diseador Implementador y un Integrador. 3. Probadores Profesionales Diseador de Pruebas Probador. 4. Encargados Encargado de Control del Cambio Encargado de la Configuracin Encargado del Despliegue Ingeniero de Procesos Encargado de Proyecto Revisor de Proyecto 5. Otros Cualquier trabajador Artista Grfico Stakeholder Administrador del Sistema Escritor tcnico Especialista de Herramientas 6. Artefactos Los artefactos son el resultado parcial o final que es producido y usado por los actores durante el proyecto. Son las entradas y salidas de las actividades, realizadas por los actores, los cuales utilizan y van produciendo estos artefactos para tener guas. Un artefacto puede ser un documento, un modelo o un elemento de modelo. 2.3.4 Conjuntos de artefactos Se tiene un conjunto de artefactos definidos en cada una de las disciplinas y utilizadas dentro de ellas por lo actores para la realizacin de las mismas, a continuacin se definen cada una de estas categoras o grupos de artefactos dentro de las disciplinas del RUP: a) Modelado del negocio Los artefactos del modelado del negocio capturan y presentan el contexto del negocio del sistema. Los artefactos del modelado del negocio sirven como entrada y como referencia para los requisitos del sistema. b) Requerimientos Los artefactos de requerimientos del sistema capturan y presentan la informacin usada en definir las capacidades requeridas del sistema. c) Anlisis y diseo del sistema Los artefactos para el anlisis y del diseo capturan y presenta la informacin relacionada con la solucin a los problemas se presentaron en los requisitos fijados. d) Implementacin Los artefactos para la implementacin capturan y presentan la realizacin de la solucin presentada en el anlisis y diseo del sistema.

e) Pruebas Los artefactos desarrollados como productos de las actividades de prueba y de la evaluacin son agrupadas por el actor responsable, con el cual se lleva un conjunto de documentos de informacin sobre las pruebas realizadas y las metodologas de pruebas aplicadas. f) Despliegue Los artefactos del despliegue capturan y presentan la informacin relacionada con la transitividad del sistema, presentada en la implementacin en el ambiente de la produccin. g) Administracin del proyecto El conjunto de artefactos de la administracin del proyecto capturan los artefactos asociados con el proyecto, el planeamiento y a la ejecucin del proceso. h) Administracin de cambios y configuracin Los artefactos de la configuracin y administracin del cambio capturan y presentan la informacin relacionada con la disciplina de configuracin y administracin del cambio. i) Entorno o ambiente El conjunto de artefactos del ambiente presentan los artefactos que se utilizan como direccin a travs del desarrollo del sistema para asegurar la consistencia de todos los artefactos producidos. 2.3.5 Grado de finalizacin de artefactos Consiste en cuanto hemos finalizado del artefacto propuesto, con esto nos referimos por ejemplo, si definimos que vamos a utilizar un artefacto, este nos dice los lineamientos que necesita para ser completado, por lo tanto con grado de finalizacin nos referimos a cuntos de esos lineamientos del artefacto hemos completado o llenado, esto en cada una de las disciplinas, de acorde a la fase en que se encuentre, para entender de mejor manera lo antes dicho se muestra en la figura, en la cual se puede observar que en la fase de Concepcin, en la disciplina de Implementacin del Sistema los artefactos tienen una poca finalizacin y van aumentando progresivamente en cada fase hasta llegar a su culminacin en la fase de Transicin, en la disciplina de Ingeniera del Negocio los artefactos tienen una media finalizacin y sucede lo mismo que con los artefactos de la disciplina anterior los cuales finalizan tambin en la fase de Transicin.

Con esto se puede mostrar el aumento progresivo de los artefactos en cada disciplina en la fase

dada, teniendo una idea un poco ms amplia sobre el desenvolvimiento del proyecto hablando en trminos de sus artefactos.

2.4 PARADIGMA ORIENTADO A OBJETOS: Es una tcnica o estilo de programacin que utiliza objetos como parte fundamental de Construccin. 2.4.1 Elementos bsicos de la POO. Bloques. Son un conjunto complejo de datos (atributos) y funciones (mtodos) que poseen una determinada Estructura y forman parte de una organizacin. Mtodos: Es un programa procedimental que est asociado a un objeto determinado y cuya ejecucin solo Puede desencadenarse a travs del mensaje correspondiente. Mensajes. Es simplemente una peticin de un objeto a otro para que este se comporte de una manera Determinada, ejecutando uno de sus mtodos. Los mensajes comunican a los objetos con otros y con el mundo exterior. Clases. Es un tipo definido por el usuario que determina la estructura de datos y las operaciones Asociadas con ese tipo. Todos los objetos estn compuestos de tres cosas Interfaz. La Interfaz. Es el conjunto de mtodos, propiedades, eventos y atributos que se declaran como pblicos en su alcance y que pueden invocar los programas escritos para usar nuestro objeto Implementacin Al cdigo dentro de los mtodos se le llama Implementacin. Algunas veces tambin se le llama comportamiento, ya que este cdigo es el que efectivamente logra que el objeto haga un trabajo til. 2.4.2 Caractersticas. Abstraccin: Significa extraer las propiedades esenciales de un objeto que lo distinguen de los dems tipos de Objetos y proporciona fronteras conceptuales definidas respecto al punto de vista del observador. Encapsulamiento: Es el proceso de almacenar en un mismo compartimiento (una caja negra) los elementos de una Abstraccin (toda la informacin relacionada con un objeto) que constituyen su estructura y su Comportamiento. Esta informacin permanece oculta tanto para los usuarios como para otros objetos Y puede ser accedida solo mediante la ejecucin de los mtodos adecuados. Herencia: Es la propiedad que permite a los objetos construirse a partir de otros objetos. La clase base contiene todas las caractersticas comunes. Las sub-clases contienen las Caractersticas de la clase base ms las caractersticas particulares de la sub-clase. Si la sub-clase hereda caractersticas de una clase base, se trata de herencia simple. Si hereda de dos o ms clases base, herencia mltiple. Polimorfismo: Literalmente significa cualidad de tener ms de una forma. En poo, se refiere al hecho que una Misma operacin puede tener diferente comportamiento en diferentes objetos. En otras palabras, Diferentes objetos reaccionan al mismo mensaje de modo diferente.

Modularidad: Un programa es modular si se compone de mdulos independientes y robustos. Esto permite la Reutilizacin y facilita la verificacin y depuracin de los mismos. Jerarqua: La mayora de nosotros ve de manera natural nuestro mundo como objetos que se relacionan entre s de una manera jerrquica. Las clases de un programa se organizan mediante la jerarqua. La representacin de dicha organizacin da lugar a los denominados rboles de herencia Mediante la herencia una clase hija puede tomar determinadas propiedades de una clase padre. As se simplifican los diseos y se evita la duplicacin de cdigo al no tener que volver a codificar mtodos ya implementacin Al acto de tomar propiedades de una clase padre se denomina heredar. 2.4.4 Otras propiedades El modelo objeto ideal no solo tiene las propiedades anteriormente citadas sino que es conveniente que soporte, adems, estas otras propiedades. Concurrencia (multitarea).El lenguaje soporta la creacin de procesos paralelos independientes del sistema operativo. Esta propiedad simplificar la transportabilidad de un sistema de tiempo real de una plataforma a otra. Se dice que dos o ms procesos son concurrentes si estn construidos de manera tal que pueden ejecutarse al mismo tiempo y compartiendo recursos. Persistencia. Los objetos deben poder ser persistentes; es decir, los objetos han de poder permanecer despus de la ejecucin del programa. Genericidad. Las clases parametrizadas (mediante plantillas o unidades genricas) sirven para soportar un alto grado de reutilizacin. Estos elementos genricos se disean con parmetros formales, que se instanciaran con parmetros reales, para crear instancias de mdulos que se compilan y enlazan, y ejecutan posteriormente. Manejo de Excepciones. Se deben poder detectar, informar y manejar condiciones excepcionales utilizando construcciones del lenguaje. 2.5 UML UML surge como respuesta al problema de contar con un lenguaje estndar para escribir planos de software. Muchas personas han credo ver UML como solucin para todos los problemas sin saber en muchos casos de lo que se trataba en realidad. El Lenguaje Unificado de Modelado, UML es una notacin estndar para el modelado de sistemas software,

2.5.2 Descripcin del lenguaje UML es un lenguaje de propsito general para el modelado orientado a objetos, que combina notaciones provenientes desde: Modelado Orientado a Objetos, Modelado de Datos, Modelado de Componentes, Modelado de Flujos de Trabajo (Workflows). En todos los mbitos de la ingeniera se construyen modelos, en realidad, simplificaciones de la realidad, para comprender mejor el sistema que vamos a desarrollar: los arquitectos utilizan y construyen planos (modelos) de los edificios, los grandes diseadores de coches preparan modelos en sistemas existentes con todos los detalles y los ingenieros de software deberan igualmente construir modelos de los sistemas software. Un enfoque sistemtico permite construir estos modelos de una forma consistente demostrando su utilidad en sistemas de cierto tamao. 2.5.3 Inconvenientes en UML Como todo en el desarrollo de software UML presenta ciertos inconvenientes, entre los cuales se pueden mencionar: Falta integracin con respecto de otras tcnicas tales como patrones de diseo, interfaces de usuario, documentacin, etc., los ejemplos aislados, el monopolio de conceptos, tcnicas y mtodos en torno a UML. 2.5.4 Perspectivas de UML Tambin se prev varias perspectivas de UML ya que por ser un lenguaje de propsito general ser un lenguaje de modelado orientado a objetos estndar predominante los prximos aos, esto se basa en las siguientes razones: Participacin de metodlogos influyentes Participacin de importantes empresas Aceptacin del OMG como notacin estndar Tambin se muestran las siguientes evidencias que apoyan lo antes dicho: Herramientas que proveen la notacin UML Edicin de libros Congresos, cursos, camisetas, etc. 2.4.5 Descripcin de los diagramas Un modelo captura una vista de un sistema del mundo real. Es una abstraccin de dicho sistema, considerando un cierto propsito. As, el modelo describe completamente aquellos aspectos del sistema que son relevantes al propsito del modelo, y a un apropiado nivel de detalle. Un

diagrama es una representacin grfica de una coleccin de elementos de modelado, a menudo dibujada como un grafo con vrtices conectados por arcos Un proceso de desarrollo de software debe ofrecer un conjunto de modelos que permitan expresar el producto desde cada una de las perspectivas de inters. Es aqu donde se hace evidente la importancia de UML en el contexto de un proceso de desarrollo de software. El cdigo fuente del sistema es el modelo ms detallado del sistema (y adems es ejecutable). Sin embargo, se requieren otros modelos. 2.5.6 Relaciones de enlaces entre modelos

Cada modelo es completo desde su punto de vista del sistema, sin embargo, existen relaciones de enlaces entre los diferentes modelos (figura). Varios modelos aportan diferentes vistas de un sistema los cuales nos ayudan a comprenderlo desde varios frentes. As, UML recomienda la utilizacin de nueve diagramas que, para representar las distintas vistas de un sistema. Estos diagramas de UML se presentan en la figura 14 y se describen a continuacin:

2.5.7 Diagramas, partes de un modelo 1.Diagrama de Casos de Uso: modela la funcionalidad del sistema agrupndola en descripciones de acciones ejecutadas por un sistema para obtener un resultado. 2.Diagrama de Clases: muestra las clases (descripciones de objetos que comparten caractersticas comunes) que componen el sistema y cmo se relacionan entre s. 3. Diagrama de Objetos: muestra una serie de objetos (instancias de las clases) y sus relaciones. a) Diagramas de Comportamiento: dentro de estos diagramas se encuentran: b) Diagrama de Estados: modela el comportamiento del sistema de acuerdo con eventos. c) Diagrama de Actividades: simplifica el Diagrama de Estados modelando el comportamiento mediante flujos de actividades. Tambin se pueden utilizar caminos verticales para mostrar los responsables de cada actividad. d) Diagramas de Interaccin: Estos diagramas a su vez se dividen en 2 tipos de diagramas, segn la interaccin que enfatizan:

+ Diagrama de Secuencia: enfatiza la interaccin entre los objetos y los mensajes que intercambian entre s junto con el orden temporal de los mismos. + Diagrama de Colaboracin: igualmente, muestra la interaccin entre los objetos resaltando la organizacin estructural de los objetos en lugar del orden de los mensajes intercambiados. 4. Diagramas de implementacin a) Diagrama de Componentes: muestra la organizacin y las dependencias entre un conjunto de componentes. b) Diagrama de Despliegue: muestra los dispositivos que se encuentran en un sistema y su distribucin en el mismo. 2.6 SISTEMAS DE GESTIONES DE BASE DE DATOS Los sistemas gestores de base de datos son un tipo de software especifico, dedicado a servir de interfaz entre la base de datos y el usuario, las aplicaciones que la utilizan. Se compone de un lenguaje de definicin de datos de un lenguaje de manipulacin de datos y de un lenguaje de consulta. 2.7 MYSQL Es un sistema de gestin de bases de datos relacional, fue creada por la empresa sueca MySQL AB, la cual tiene el copyright del cdigo fuente del servidor SQL, as como tambin de la marca. MySQL es un software de cdigo abierto, licenciado bajo la GPL de la GNU, aunque MySQL AB distribuye una versin comercial, en lo nico que se diferencia de la versin libre, es en el soporte tcnico que se ofrece, y la posibilidad de integrar este gestor en un software propietario, ya que de otra manera, se vulnerara la licencia GPL. El lenguaje de programacin que utiliza MySQL es Structured Query Language (SQL) que fue desarrollado por IBM en 1981 y desde entonces es utilizado de forma generalizada en las bases de datos relacionales. MySQL es un sistema de gestin de bases de datos relacional, multihilo y multiusuario con ms de seis millones de instalaciones.[1] MySQL AB desde enero de 2008 una subsidiaria de Sun Microsystems y sta a su vez de Oracle Corporation desde abril de 2009 desarrolla MySQL como software libre en un esquema de licenciamiento dual. MySQL es muy utilizado en aplicaciones web, como Drupal o phpBB, en plataformas (Linux/Windows-Apache-MySQL-PHP/Perl/Python), y por herramientas de seguimiento de errores como Bugzilla. 3. Caractersticas principales Inicialmente, MySQL careca de algunos elementos esenciales en las bases de datos relacionales, tales como integridad referencial y transacciones. A pesar de esto, atrajo a los desarrolladores de pginas web con contenido dinmico, debido a su simplicidad, de tal manera que los elementos faltantes fueron complementados por la va de las aplicaciones que la utilizan. Poco a poco estos elementos faltantes, estn siendo incorporados tanto por desarrolladores internos, como por desarrolladores de software libre. En las ltimas versiones se pueden destacar las siguientes

2.7.1 caractersticas principales: o El principal objetivo de MySQL es velocidad y robustez. o Soporta gran cantidad de tipos de datos para las columnas. o Gran portabilidad entre sistemas, puede trabajar en distintas plataformas y sistemas operativos. o Cada base de datos cuenta con 3 archivos: Uno de estructura, uno de datos y uno de ndice y soporta hasta 32 ndices por tabla. o Aprovecha la potencia de sistemas multiproceso, gracias a su implementacin multihilo. o Flexible sistema de contraseas (passwords) y gestin de usuarios, con un muy buen nivel de seguridad en los datos. o El servidor soporta mensajes de error en distintas lenguas 2.7.2VENTAJAS o Velocidad al realizar las operaciones, lo que le hace uno de los gestores con mejor rendimiento. o Bajo costo en requerimientos para la elaboracin de bases de datos, ya que debido a su bajo consumo puede ser ejecutado en una mquina con escasos recursos sin ningn problema. o Facilidad de configuracin e instalacin. o Soporta gran variedad de Sistemas Operativos o Baja probabilidad de corromper datos, incluso si los errores no se producen en el propio gestor, sino en el sistema en el que est. o Conectividad y seguridad 2.7.3 DESVENTAJAS o Un gran porcentaje de las utilidades de MySQL no estn documentadas. o No es intuitivo, como otros programas (ACCESS). 2.7.4 PANORMICA DE PROGRAMAS MYSQL MySQL AB proporciona varios tipos de programas El servidor MYSQL y los scripts de inicio del servidor: mysqld es el servidor MySQL mysqld_safe, mysql.server, y mysqld_multi son scripts de inicio del servidor mysql_install_db inicializa el directorio data y las bases de datos que MySQL instala por defecto. . Programas cliente que acceden al servidor: mysql es un programa cliente que porporciona una interfaz de linea de comandos para ejecutar sentencias SQL en modo interactivo o por lotes. mysqladmin es un cliente para administracin. mysqlcheck ejecuta operaciones de mantenimiento de tablas. mysqldump y mysqlhotcopy son utilidades para copia de respaldo. mysqlimport realiza importacin de ficheros de datos. mysqlshow muestra informacin relativa a tablas y bases de datos. .

Programas que operan independientemente del servidor: myisamchk ejecuta operaciones de mantenimiento de tablas. myisampack genera tablas comprimidas, de slo lectura. mysqlbinlog es una herramienta para procesar archivos de registro binario (binary logs). perror informa el significado de un cdigo de error. La mayora de las distribuciones de MySQL incluyen todos los programas mencionados, con excepcin de los que son especficos de cada plataforma. (Por ejemplo, los scripts de inicio de servidor no son necesarios en Windows). Otra excepcin es que las distribuciones RPM son ms especializadas. Existe una RPM para el servidor, otra para los programas cliente, etc. 2.8 ORACLE Oracle es bsicamente una herramienta cliente/servidor para la gestin de Bases de Datos. Es un producto vendido a nivel mundial, aunque la gran potencia que tiene y su elevado precio hace que slo se vea en empresas muy grandes y multinacionales, por norma general. En el desarrollo de pginas web pasa lo mismo: como es un sistema muy caro no est tan extendido como otras bases de datos, por ejemplo, Access, MySQL, SQL Server, etc. Vamos ahora en centrarnos en que es Oracle exactamente y como funciona la programacin sobre ste. Oracle como antes he mencionado se basa en la tecnologa cliente/servidor, pues bien, para su utilizacin primero sera necesario la instalacin de la herramienta servidor (Oracle 8i) y posteriormente podramos atacar a la base de datos desde otros equipos con herramientas de desarrollo como Oracle Designer y Oracle Developer, que son las herramientas bsicas de programacin sobre oracle. Para desarrollar en Oracle utilizamos PL/SQL un lenguaje de 5 generacin, bastante potente para tratar y gestionar la base de datos, tambin por norma general se suele utilizar SQL al crear un formulario. Es posible lgicamente atacar a la base de datos a travs del SQL plus incorporado en el paquete de programas Oracle para poder realizar consultas, utilizando el lenguaje SQL. El Developer es una herramienta que nos permite crear formularios en local, es decir, mediante esta herramienta nosotros podemos crear formularios, compilarlos y ejecutarlos, pero si queremos que los otros trabajen sobre este formulario deberemos copiarlo regularmente en una carpeta compartida para todos, de modo que, cuando quieran realizar un cambio, debern copiarlo de dicha carpeta y luego volverlo a subir a la carpeta. Este sistema como podemos observar es bastante engorroso y poco fiable pues es bastante normal que las versiones se pierdan y se machaquen con frecuencia. La principal ventaja de esta herramienta es que es bastante intuitiva y dispone de un modo que nos permite componer el formulario, tal y como lo haramos en Visual Basic o en Visual C. Los problemas anteriores quedan totalmente resueltos con Designer que es una herramienta que se conecta a la base de datos y por tanto creamos los formularios en ella, de esta manera todo el mundo se conecta mediante Designer a la aplicacin que contiene todos los formularios y no hay problemas de diferentes versiones, esto es muy til y perfecto para evitar machacar el trabajo de otros. Pero el principal y ms notable problema es la falta de un entorno visual para disear el

formulario, es decir, nos aparece una estructura como de rbol en la cual insertamos un formulario, a la vez dentro de ste insertamos bloques o mdulos que son las estructuras que contendrn los elementos del formularios, que pueden estar basados en tablas o no. Por lo tanto si queremos hacer formularios para practicar o para probar qu es esto de Oracle, es recomendable que se utilic Developer pues es mucho ms fcil e intuitivo al principio. 2. Explorador de servidores para base de datos de oracle Las bases de datos de Oracle presentan algunas diferencias en el Explorador de servidores. Por ejemplo, cuando agrega una conexin a una base de datos de Oracle, ver las siguientes carpetas: Diagramas de base de datos, Tablas, Sinnimos, Vistas, Procedimientos almacenados, Funciones, Especificaciones de paquete y Cuerpos de paquete. En los siguientes temas se describen brevemente cada uno de los objetos del Explorador de servidores para bases de datos de Oracle. 3. Diagramas de base de datos La carpeta Diagramas de base de datos contiene diagramas con nombre que muestran la estructura de la base de datos de forma grfica. 4. Tablas La carpeta Tablas contiene las tablas base de la base de datos. Visual Database Tools le ayuda a realizar modificaciones en la base de datos. Es posible controlar cundo y cmo se guardarn los cambios realizados a una base de datos creada en un diagrama de base de datos. Para ello, se deben anotar los objetos que han sido modificados y los que no han sufrido cambios en el diagrama de base de datos, guardar nicamente los cambios realizados en las tablas seleccionadas y descartar los cambios no deseados. Tambin puede utilizar secuencias de comandos de cambio SQL para hacer un seguimiento de los cambios, descartarlos y aplicar cambios no guardados. 5. Sinnimos La carpeta Sinnimos contiene nombres alternativos para las tablas, vistas, secuencias, procedimientos almacenados, funciones, paquetes e instantneas. Puede utilizar sinnimos para tener acceso fcilmente a los objetos de base de datos sin utilizar calificadores. 6. Para crear un nuevo sinnimo Desde una consulta o secuencia de comandos SQL, ejecute la siguiente instruccin: create synonym name for table Sustituya name por el nombre del sinnimo y table por el nombre de la tabla. 7. Para recuperar datos de un sinnimo En el Explorador de servidores, haga clic con el botn secundario del mouse (ratn) y elija Recuperar datos de sinnimo. Una cuadrcula muestra el propietario, nombre de columna, tipo de tabla, precisin, etc., para las columnas accesibles de todas las tablas, vistas y clsteres. 8. Vistas La carpeta Vistas contiene bloques con nombre de cdigo SQL que filtran los datos disponibles de las tablas subyacentes. 9. Funciones La carpeta Funciones contiene bloques con nombre de cdigo SQL que puede devolver valores a un programa de llamada. Para obtener informacin adicional sobre cmo trabajar con funciones

10. Especificaciones del paquete La carpeta Especificaciones del paquete contiene grupos con nombre de procedimientos pblicos, funciones, excepciones, variables, constantes y cursores. Las especificaciones de paquete resultan tiles para compartir datos y aumentar la eficiencia. 11. Para crear una nueva especificacin de paquete En el Explorador de servidores, haga clic con el botn secundario del mouse en el nodo Especificaciones del paquete y elija Nueva especificacin de paquete en el men contextual. En el editor se muestra una plantilla con la sintaxis correcta de Oracle para especificaciones de paquete. Para editar una especificacin de paquete En el Explorador de servidores, haga clic con el botn secundario del mouse y elija Editar especificacin de paquete en el men contextual. En el editor se muestra el cdigo SQL para la especificacin de paquete. 12. Cuerpos de paquete La carpeta Cuerpos de paquete contiene cuerpos de paquete con nombre creados a partir de especificaciones de paquete. 13. Para crear un nuevo cuerpo de paquete En el Explorador de servidores, haga clic con el botn secundario del mouse en el nodo Cuerpos de paquete y elija Nuevo cuerpo del paquete en el men contextual. En el editor se muestra una plantilla con la sintaxis correcta de Oracle para cuerpos de paquete. 14. Para editar un cuerpo de paquete En el Explorador de servidores, haga clic con el botn secundario del mouse y elija Editar cuerpo de paquete en el men contextual. En el editor se muestra el cdigo SQL para el cuerpo de paquete. 2.8 LENGUAJES DE PROGRAMACION PHP es un lenguaje de programacin interpretado (Lenguaje de alto rendimiento), diseado originalmente para la creacin de pginas web dinmicas. Se usa principalmente para la interpretacin del lado del servidor (server-side scripting) pero actualmente puede ser utilizado desde una interfaz de lnea de comandos o en la creacin de otros tipos de programas incluyendo aplicaciones con interfaz grfica usando las bibliotecas Qt o GTK+.

CAPITUTO III CONSTRUCCION DEL SISTEMA DE COBRO DE PENSIONES ICEI En la actualidad, la utilizacin de metodologas para el desarrollo de aplicaciones es casi imposible omitirla, debido a la gran necesidad de control de variables que conlleva el mismo desarrollo, y para la ordenada elaboracin de las aplicaciones, por lo tanto, seguir metodologas y estndares nos llevan a estar en competitividad en todo momento. Es de suma importancia conocer el modo como se interrelacionan metodologas con estndares y herramientas siguiendo un nico propsito, el cual consiste en la elaboracin de aplicaciones de manera eficiente, ordenada y con el menor nmero de defectos. La metodologa RUP nos proporciona disciplinas en las cuales se encuentran artefactos con lo cual se podr contar con guas para poder documentar e implementar de una manera fcil y eficiente, todas las guas para un buen desarrollo, todo esto dentro de las respectivas fases con las cuales cuenta. No es posible realizar un desarrollo de software de una manera lenta, ya que las exigencias de los clientes actuales conllevan a verse en la necesidad de implementar soluciones rpidas y que cumplan con los requerimientos planteados, por lo que el Desarrollo Rpido de Aplicaciones es una de las caractersticas que ms impacto tiene en la actualidad, para solventar esto se deben utilizar herramientas basadas en este nuevo enfoque. Durante el desarrollo del presente capitulo se define el marco de trabajo y las tareas que se requieren para desarrollar, construir implementar el sistema de control de pago de pensiones, con el que se pretende cumplir con los objetivos trazados y dar solucin a la problemtica presentado en la institucin. Para la construccin del sistema de control de pago de pensiones del CPRGB, se optado por usar la metodologa RUP ( Proceso Racional Unificado). A continuacin se desarrolla en detalle cada una de las fases del ciclo de vida o de desarrollo de RUP y los flujos de trabajo sobre los cuales iteran. 3.2 FASE INICIO 1. Propsito alcance y Espacio del proyecto El propsito del presente proyecto es disear, desarrollar e implementar un sistema de informacin computarizado para el control de pago de pensiones para la administracin del ICEI que manipule y administre toda la informacin concerniente al cobro de pago de pensiones. Con el desarrollo del sistema de control de pago de pensiones del ICEI, se busca dar solucin a los problemas presentados en la institucin de forma eficiente y eficaz, empleando informacin confiable y segura. 3.3. REQUERIMIENTOS DEL SISTEMA Dentro los alcances del proyecto, el sistema de control de pago de pensiones del ICEI permitir cumplir los requerimientos del sistema de cobro de pensiones. Estos requerimientos se pueden diferenciar en los siguientes subsistemas o mdulos. Pago de Mensualidad Registra de pago de mensualidad. Realizar informes y reportes sobre los ingresos (pago de pensin).

 Genera comprobante de pago (Emitir Factura) 3. 4 REQUERIMIENTO TECNOLOGICO En el requerimiento de software el lenguaje de programacin PHP, como motor de base de datos MYSQL que es eficiente y segura. La institucin ICEI no cuenta con ningn tipo de red por lo cual se optara por un enlace de red local. 4. PLANIFICACIN INICIAL DEL PROYECTO:

Para poder cumplir con los objetivos establecidos en el proyecto y desarrollar todas las fases que contempla la metodologa RUP, es necesario realizar una planificacin temporal respecto al tiempo de trabajo que tomara la conclusin del sistema de control de pago de pensiones del ICEI. La planificacin del presente proyecto estar en base al tiempo estimado por la institucin ICEI. Realizar el modelo de requisitos que incluya: Identificacin de los casos de negocio Descripcin de los casos de uso Definicin del Modelo Conceptual Diagrama de Estados 3.5 EL CASO DEL NEGOCIO El caso del negocio proporciona la informacin necesaria, desde el punto de vista del sistema a) Descripcin de sistema El sistema de control de pago de pensiones del ICEI, est diseado para realizar el control y administracin de los ingresos en la institucin por concepto cobro de pago de pensiones, dando una solucin eficaz y eficiente. Adems el sistema se encargara de automatizar las tareas como: Paga Mensualidad, Registra en Sistema, Emite Factura. o Paga Mensualidad: Cobro de pensiones. o Registro de pago de mensualidad. Primero el encargado verifica si tiene deudas, una vez verificada la deuda se registra el monto recibido. o Realizar informes y reportes sobre los ingresos (pago de pensin). o Genera comprobante de pago (Emitir Factura) b) Identificacin de Subsistemas Los subsistemas identificados estn en relacin al alcance del proyecto. Para desarrollar el Sistema de control de pago de pensiones del ICEI se identificaron los siguientes subsistemas o mdulos. Es importante sealar que existe dependencia entre los subsistemas anteriormente indicados, es por eso que analizando los elementos compartidos entre ellos, o las interfaces entre subsistema, se logra determinar que uno depende del otro y viceversa.

c) Descripcin de los subsistemas.- La descripcin de cada sistema es como sigue: Subsistema de paga mensualidad

Verificacin de Cdigo de estudiante. Verifica deuda. Subsistema Registro de pago de mensualidad: Comprende: Registro de pago Actualizacin del registro de pago.. Generar Informes y reportes: Comprende Reportes de ingresos. Actualizacin de reportes. Emite Factura: Comprende Confirmacin de Cdigo de estudiante. Generacin de recibo o factura d) Gestin de riesgos.- El riesgo es un problema potencial que puede ocurrir o no, y que puede afectar a los futuros acontecimientos. Por esta razn es necesario evaluar su probabilidad de aparicin, estimar su impacto y establecer un plan de contingencia. 6. Identificacin del riesgo.- El mtodo que utilizamos para identificar los riesgos es una lista de comprobacin de elementos de riesgo: Definicin del proceso. El tamao de la base de datos a crear es grande? Nmero de usuarios del sistema es grande? La cantidad de software reutilizable es considerable Entorno de desarrollo. Se tiene disponible las herramientas de gestin del proyecto de software? Existen herramientas de anlisis y diseo disponibles? Proporcionan las herramientas de anlisis y diseo mtodos apropiados para el producto a construir? Existen expertos disponibles para responder todas las preguntas sobre las herramientas? Con el Usuario. Entiende el usuario el proceso del software? El Usuario est dispuesto en invertir su tiempo en reuniones y revisiones del producto que requiere? Tecnologa a construir. Es necesaria para la institucin la tecnologa a construir? Es nueva la tecnologa que se va a construir? El software interacta con hardware nuevo o no probado? 7. Proyeccin del riesgo.- Los riesgos ms altos identificados en el proyecto son los siguientes: o Estimacin del tamao de software o Mayor nmero de usuarios de lo previsto o Falta de informacin sobre las herramientas o Falta de capacitacin al usuario 8. Anlisis de costos.- En este punto se presenta una estimacin del costo que implica el desarrollo del SCPP.

Costos directos: Son aquellos recursos utilizados en el desarrollo del sistema desde el inicio hasta su finalizacin y entrega al usuario. Costos indirectos: Estos solo sern de apoyo, no implicaran dentro del proyecto, ya que solo son materiales extras que son necesarios para el desarrollo del sistema 3.6. MODELO DEL NEGOCIO El modelo de negocio del proyecto est enmarcado dentro de las delimitaciones del contexto del sistema y describe los procesos exactos relacionados con los actores y casos de uso encontrados. a) Actores del Negocio director de la institucion, estudiante, intermediario(secretaria de registro) caja b) Casos de uso del negocio Paga Mensualidad: Registro de pago de mensualidad. Generar reportes. Emite Factura. c) Modelo inicial del caso de Uso del Negocio: El siguiente diagrama muestra los casos de uso del negocio.

3.7 DIAGRAMA DE CASOS DE USO: En los diagramas de casos de uso se utiliza los diagramas de UML:

3.8 DETALLE DE CASO DE USO EXPANDIDO El caso de uso expandido describe de forma detallada la informacin del ICEI, donde el objetivo principal se muestran en los casos de uso que realiza el personal administrativo, que se encarga del cobro y registro de pensiones. A continuacin se detallara los casos de uso:

Casos de uso: Paga mensualidad

3.9 DIAGRAMA DE SECUENCIA: El diagrama de secuencias se muestran los eventos y se realiza operaciones en el proceso del sistema, permite que el sistema y el actor interactu.

3.10 DIAGRAMA DE COMUNICACIN:

3.11 DIAGRAMA DE CLASES DEL SISTEMA:

3.12 CONCLUSIN: En este proyecto se ha dado una visin general de lo que es el RUP, UML, as como de la estructura bidimensional que sigue, dividiendo el proceso en fases, y estas en flujos de trabajo. El anlisis y desarrollo orientado a objetos aplicando RUP que es una metodologa completa y extensa que intenta abarcar todo el mundo del desarrollo software, tanto para pequeos proyectos, como proyectos ms ambiciosos de varios aos de duracin. No es fcil manejar esta metodologa, pero con toda la bibliografa que existe sobre RUP, las herramientas disponibles para desarrollo de software Y UML esta tarea se hace mas causada.