IMPLEMENTACIÓN DE UN SISTEMA DE GESTIÓN DE REQUERIMIENTOS DE INFORMACIÓN PARA LA GERENCIA DEL CENTRO DE INFORMACIÓN FINANCIERA DEL BANCO DE BOGOTÁ

Transcripción

1 IMPLEMENTACIÓN DE UN SISTEMA DE GESTIÓN DE REQUERIMIENTOS DE INFORMACIÓN PARA LA GERENCIA DEL CENTRO DE INFORMACIÓN FINANCIERA DEL BANCO DE BOGOTÁ TULIO ARMANDO NIÑO BALLESTEROS JUAN CARLOS LOZANO RAMÍREZ FERLEYN ANDRÉS DUARTE UNIVERSIDAD DE SAN BUENAVENTURA FACULTAD DE INGENIERÍA INGENIERÍA DE SISTEMAS BOGOTÁ D. C. 2007

2 IMPLEMENTACIÓN DE UN SISTEMA DE GESTIÓN DE REQUERIMIENTOS DE INFORMACIÓN PARA LA GERENCIA DEL CENTRO DE INFORMACIÓN FINANCIERA DEL BANCO DE BOGOTÁ TULIO ARMANDO NIÑO BALLESTEROS JUAN CARLOS LOZANO RAMÍREZ FERLEYN ANDRÉS DUARTE Proyecto de Grado como requisito para optar al Título de Ingeniero de Sistemas Sandra Lucía Guañarita Fernández UNIVERSIDAD DE SAN BUENAVENTURA FACULTAD DE INGENIERÍA INGENIERÍA DE SISTEMAS BOGOTÁ D. C. 2007

3 Nota de Aceptación: FIRMA FIRMA FIRMA Bogotá D. C., 26 de mayo de 2007

4 DEDICATORIA Queremos dedicarle este logro a Dios, por permitirnos llegar a este punto y a nuestros padres, por su motivación y apoyo.

5 AGRADECIMIENTOS Queremos agradecer a todas las personas que nos apoyaron y guiaron durante el desarrollo del proyecto; agradecemos su ayuda, su comprensión, sus conocimientos, pero lo más importante su fé.

6 ABSTRACT El término WorkFlow surgió en los años 80 para resolver las necesidades que tenían muchas empresas con respecto al movimiento de sus documentos dentro de las compañías. En aquel momento el término WorkFlow fue asociado a productos de gestión de imágenes (todo el mundo quería eliminar el papel y se produjo el boom del escaneado de documentos). Pero estos productos de entonces requerían un hardware y un software propietario, algo muy distinto a lo que ocurre ahora, que las herramientas de WorkFlow son abiertas e integradoras de cualquier producto. The term WorkFlow arose in years 80 to solve the necessities that had many companies with respect to the movement of their documents within the companies. At that time the term WorkFlow was associated to products of management of images (everybody wanted to eliminate the paper and the boom of the document scanned one took place). But these products of then required a hardware and a propietary software, something very different from which it happens now, that the tools of WorkFlow are opened and integrating of any product.

7 CONTENIDO Pág. LISTA DE TABLAS...9 LISTA DE FIGURAS...10 LISTA DE ANEXOS...12 INTRODUCCIÓN PLANTEAMIENTO DEL PROBLEMA ANTECEDENTES DESCRIPCIÓN Y FORMULACIÓN DEL PROBLEMA JUSTIFICACIÓN OBJETIVOS DE LA INVESTIGACIÓN OBJETIVO GENERAL OBJETIVOS ESPECÍFICOS ALCANCES Y LIMITACIONES DEL PROYECTO ALCANCES LIMITACIONES MARCO DE REFERENCIA MARCO CONCEPTUAL MARCO LEGAL O NORMATIVO MARCO TEÓRICO METODOLOGÍA HIPÓTESIS VARIABLES VARIABLES INDEPENDIENTES VARIABLES DEPENDIENTES DESARROLLO INGENIERIL ANÁLISIS ANÁLISIS SISTEMA ACTUAL ANÁLISIS SOLUCIÓN PROPUESTA ESPECIFICACIÓN DE REQUERIMIENTOS

8 4.2. DISEÑO DIAGRAMA DE CLASES DISEÑO CONCEPTUAL DE LA BASE DE DATOS DISEÑO FÍSICO DE LA BASE DE DATOS DICCIONARIO DE LA BASE DE DATOS DICCIONARIO DE RELACIONES DE LA BASE DE DATOS TABLAS ESTRUCTURALES DEL WORKFLOW DICCIONARIO DE PROCEDIMIENTOS ALMACENADOS IMPLEMENTACIÓN INTERFAZ DE USUARIO MAPA DEL SITIO ESQUEMA DE PRUEBAS CONCLUSIONES BIBLIOGRAFÍA

9 LISTA DE TABLAS Pág. TABLA 1. DICCIONARIO DE LA BASE DE DATOS...62 TABLA 2. DICCIONARIO DE RELACIONES DE LA BASE DE DATOS...63 TABLA 3. TABLA ESTRUCTURAL DE ESTADO...63 TABLA 4. TABLA ESTRUCTURAL DE ROL...63 TABLA 5. TABLA ESTRUCTURAL DE ESTADOEVENTO...64 TABLA 6. TABLA ESTRUCTURAL DE EVENTO...64 TABLA 7. TABLA ESTRUCTURAL DE TIPOARCHIVOADJUNTO...64 TABLA 8. DICCIONARIO DE PROCEDIMIENTOS ALMACENADOS

10 LISTA DE FIGURAS Pág. FIGURA 1. DIAGRAMA DE CONTEXTO SISTEMA ACTUAL...44 FIGURA 2. DIAGRAMA NIVEL 1 SISTEMA ACTUAL...45 FIGURA 3. DIAGRAMA DE FLUJO SISTEMA PROPUESTO...48 FIGURA 4. CAPAS DEL APLICATIVO WEB...49 FIGURA 5. MODELO CLIENTE SERVIDOR EN MV...50 FIGURA 6. CASOS DE USO: ADMINISTRADOR...52 FIGURA 7. CASOS DE USO: ANALISTA...53 FIGURA 8. CASOS DE USO: USUARIO...53 FIGURA 9. PROTOTIPO WEB INICIO SESIÓN...56 FIGURA 10. PROTOTIPO WEB CREAR SOLICITUD...56 FIGURA 11. PROTOTIPO WEB CONSULTAR SOLICITUD...56 FIGURA 12. PROTOTIPO WEB DESCARGAR ARCHIVOS...57 FIGURA 13. DIAGRAMA DE CLASES...57 FIGURA 14. DISEÑO CONCEPTUAL BD (ENTIDADES Y ATRIBUTO CLAVE)...58 FIGURA 15. DIAGRAMA DE LA BASE DE DATOS...60 FIGURA 16. FLUJO DE TRABAJO APLICATIVO WEB...69 FIGURA 17. FINAL WEB INICIO SESIÓN NO AUTORIZADO...74 FIGURA 18. FINAL WEB MENSAJE DE ALERTAS...74 FIGURA 19. FINAL WEB CREAR SOLICITUD...75 FIGURA 20. FINAL WEB CONSULTAR SOLICITUD...76 FIGURA 21. FINAL WEB VER DETALLES DE SOLICITUD...76 FIGURA 22. FINAL WEB VER HISTORIAL DE SOLICITUDES...77 FIGURA 23. FINAL WEB DE DESCARGA DE ARCHIVOS ADJUNTOS...78 FIGURA 24. FINAL WEB INTERFAZ DE DESCARGA...78 FIGURA 25. FINAL WEB DE REPORTES...79 FIGURA 26. FINAL WEB ARCHIVOS ADJUNTOS...79 FIGURA 27. FINAL WEB ÁREA...80 FIGURA 28. FINAL WEB ESTADO EVENTO

11 FIGURA 29. FINAL WEB EVENTOS...81 FIGURA 30. FINAL WEB HISTORIAL SOLICITUD...82 FIGURA 31. FINAL WEB ROL...82 FIGURA 32. FINAL WEB SOLICITUD...83 FIGURA 33. FINAL WEB TIPO ARCHIVO ADJUNTO...83 FIGURA 34. FINAL WEB USUARIO...84 FIGURA 35. FINAL WEB WORKFLOW...84 FIGURA 36. FINAL WEB AYUDA...85 FIGURA 37. MAPA DEL SITIO ADMINISTRADOR...86 FIGURA 38. MAPA DEL SITIO ANALISTA...87 FIGURA 39. MAPA DEL SITIO USUARIO

12 LISTA DE ANEXOS Pág. ANEXO A. CARTA DE AUTORIZACIÓN DEL BANCO DE BOGOTÁ...96 ANEXO B. FORMATO DE ENTREVISTA...98 ANEXO C. MANUAL TÉCNICO

13 INTRODUCCIÓN Se podría definir un proceso como una serie de actividades, en las que varias entidades (personas, máquinas, etc.) colaboran para conseguir un objetivo concreto. Por ejemplo, un proceso típico en una empresa podría consistir en el conjunto de actividades necesarias para responder a una solicitud de compra por parte de un cliente (negociación de precios y fechas de envío, facturación, envío de los bienes al cliente, etc.) El proceso puede ser visto también como una cadena de actividades coherentes que resulta en la creación de valor (ya sea material o inmaterial) para alguien. Un proceso de negocio es un tipo especial de proceso que describe, desde un punto de vista orientado al mercado, las actividades de una organización. El principal objetivo de los procesos de negocio es satisfacer necesidades de los clientes. El modelado de procesos de negocio resulta útil en una gran variedad de situaciones, que pueden ser clasificadas en tres grupos: descripción del proceso, análisis del proceso e implementación del proceso. Actualmente se utilizan diversas técnicas de modelado, como diagramas de actividad de UML y otros lenguajes, fundamentalmente gráficos y formales. Un concepto relacionado con el de proceso de negocio es el de workflow. Se define workflow como la automatización de un proceso de negocio, total o parcial, durante la cual se pasan documentos, información o tareas de un participante a otro para realizar una acción, de acuerdo con un conjunto de reglas de procedimiento. Estas reglas se establecen en la definición del proceso

14 Esta automatización la suele llevar a cabo un sistema de gestión de workflow, que es un sistema que define, crea y gestiona la ejecución de workflows mediante la ejecución de software en una o más máquinas, siendo capaz de interpretar la definición del proceso, interactuar con los participantes del workflow y cuando así se requiera, ejecutar otras herramientas y aplicaciones. Las técnicas de modelado de procesos de negocio son muy importantes en un sistema de workflow, ya que permiten definir formalmente procesos, de tal forma que puedan ser interpretados y ejecutados correctamente por el sistema de gestión de workflow. Además, una parte de los participantes en un sistema de workflow serán máquinas (en general, aplicaciones), y el resto, humanos. Para facilitar la participación de humanos en el sistema, éste debe proporcionar las interfaces de usuario adecuadas

15 1. PLANTEAMIENTO DEL PROBLEMA 1.1. ANTECEDENTES En la década de los 80 las empresas aplicaron tecnologías de la información a la automatización de los procesos administrativos y de gestión. Las grandes preocupaciones de aquellos años eran el control de los costes operativos, la mejora de la productividad y el logro de servicios más competitivos 1. En cambio, en el momento actual, el interés de muchas empresas, al menos de las más innovadoras, se centra en el rediseño de los procesos de trabajo y de información con el fin de mejorar la rentabilidad y hacerlos más eficaces. Para lograr estos objetivos, muchas organizaciones empresariales están incorporando mecanismos de workflow que enlazan los procesos de negocio con los sistemas de información con el fin de conseguir: Trabajar sin papeles. Saber cuánto cuesta cada proceso de trabajo. Reducir el tiempo empleado en cada una de las tareas. Aprovechar el conocimiento de la organización. Sin embargo, para que una organización implante con éxito un sistema de workflow necesita cumplir unos requisitos básicos. En primer lugar debe contar con una sólida infraestructura de ordenadores, redes, servidores, bases de datos y correo electrónico, es decir, debe tener una madurez tecnológica. 1 Información extraída de la revista Pc World publicada en noviembre de

16 En segundo lugar, sus responsables deben estar sensibilizados respecto al valor de la información y familiarizados con la circulación de la información electrónica. El tercer requisito está relacionado con la aceptación del sistema por parte de los usuarios, que en muchas ocasiones ven en él más inconvenientes que ventajas al relacionarlo con un controlador o un reestructurador de la plantilla de la empresa más que con un guía. Otro elemento importante a tener en cuenta es que, a diferencia de otras, el workflow no es una herramienta informática que se entrega al departamento de sistemas de información para que la aplique sin más. La implantación de workflow debe considerarse más como un proyecto de gestión que como uno informático, lo que supone un esfuerzo de análisis previo de la situación de la organización, de manera que se estudie la circulación de los documentos, su naturaleza y tratamiento, así como la asignación de normas y tareas y el orden de ejecución. Por tanto, para que la herramienta de workflow pueda guiar y controlar en cada uno de los procesos de trabajo y de información, es necesario que previamente se haga el diseño de los mismos, y es aquí donde está una de las claves del éxito del workflow, en el trabajo previo de análisis de la organización y de sus procesos, y que en la mayoría de las ocasiones suele requerir consultoría. Si bien es cierto que esta tecnología ha despertado gran interés entre las grandes empresas, éstas deben ser conscientes de que su implantación supone un período relativamente largo y complejo que requiere no sólo el convencimiento y apoyo de la alta dirección, sino además la aceptación de ciertos cambios por parte de los usuarios implicados

17 1.2. DESCRIPCIÓN Y FORMULACIÓN DEL PROBLEMA La Gerencia Centro de Información Financiera del Banco de Bogotá tiene la misión de entregar información oportuna y de calidad a todos los usuarios internos que la requieran, actualmente no existe una manera adecuada de administrar la gestión que realiza el GCIF en el Banco. En el proceso de control y seguimiento se han detectado alteraciones en las solicitudes, generando conflictos entre los usuarios y el GCIF. Cómo implementar una solución a nivel aplicativo que permita gestionar los procesos de entrega de información realizada por el GCIF del Banco de Bogotá? 1.3. JUSTIFICACIÓN Proporcionar al GCIF una solución que se ajuste a la organización a nivel de infraestructura, implementación, mantenimiento y por supuesto satisfaciendo las necesidades de la entidad, permitiendo a los usuarios internos realizar solicitudes de información fácilmente, para obtener resultados en menor tiempo al que se esta trabajando actualmente. A continuación se describen los beneficios que ofrece el aplicativo: Herramienta desarrollada a la medida: Aplicación que se ajuste a las necesidades y a la infraestructura tecnológica de la Entidad Banco de Bogotá. Generación de consecutivos que permitan el control y seguimiento: Se busca ofrecer controles para la realización de auditorias y garantizar el

18 correspondiente seguimiento por parte del Usuario o Administrador sobre las solicitudes. Mejora en los tiempos de respuesta: Gracias a la obtención de consecutivos y generación de alertas por parte del aplicativo se garantiza tiempos de respuesta más cortos. Generación de informes y estadísticas de acuerdo a las necesidades del GCIF: Con la información consolidada en una base de datos, la generación de reportes personalizados es más fácil. Entorno amigable y moderno para el usuario: La interfaz gráfica desarrollada con tecnología de punta, ofrece al usuario facilidad en la creación y seguimiento de solicitudes de información. Sólida administración del GCIF: Información de calidad en una base de datos robusta que se ajusta a la entidad, y una interfaz realizando la gestión de GCIF OBJETIVOS DE LA INVESTIGACIÓN Objetivo General Desarrollar un sistema de gestión de requerimientos de información para la Gerencia del Centro de Información Financiera del Banco de Bogotá

19 Objetivos Específicos Analizar el proceso actual de gestión de solicitudes para establecer sus necesidades e identificar las falencias, con el fin de determinar los requerimientos. Diseñar la base de datos y la interfaz de usuario. Implementar la base de datos y los formularios web en ambiente Cliente Servidor, para simular un escenario de trabajo acorde al real. Realizar un esquema de pruebas basados en el escenario de trabajo, planteando diferentes situaciones que se podrían presentar eventualmente en el escenario real ALCANCES Y LIMITACIONES DEL PROYECTO Alcances El Sistema Gestión de Requerimientos de Información para la Gerencia Centro de Información Financiera ofrece una herramienta capaz de registrar y controlar los requerimientos realizados por los usuarios, brindando a la Gerencia poder de análisis para la toma de decisiones. Se hará entrega al finalizar este proyecto de: Un aplicativo para la administración, recepción y seguimiento de solicitudes de información con el Manual del Usuario vinculado en formato de videos

20 Manual Técnico Limitaciones El Banco de Bogotá posee una infraestructura tecnológica basada en arquitectura ASP.NET, igualmente la Gerencia Centro de Información Financiera cuenta con un servidor propio con motor de base de datos de Microsoft SQL Server Por otra parte la decisión de implantación depende del Banco, toda vez que la Gerencia de Sistemas debe realizar una serie de análisis e identificar como el sistema afecta el entorno de trabajo actual

21 2. MARCO DE REFERENCIA 2.1. MARCO CONCEPTUAL Es preciso determinar que se entiende por un concepto, para poder aplicarlo y evitar confusiones a las que podrían llevar a otras interpretaciones teóricas. Este apartado busca definir y, se espera, aclarar los conceptos elementales del proyecto. La búsqueda de la eficiencia viene acompañada de cambios y/o mejoras en la tecnología que soporta los procesos de negocios. La implementación de soluciones sin duda requiere de un esfuerzo importante para poner en funcionamiento la aplicación métodos, medidas, ya que no solo se debe trabajar en el flanco de hacer definiciones en el plano de procesos, tablas y organización; sino que también, se debe interactuar con la organización. Dentro de una organización todas las áreas tienen como función realizar actividades afines para alcanzar un objetivo que busque el crecimiento de ella, trabajando de forma sincronizada con las otras áreas, áreas dinámicamente relacionadas entre sí, como un sistema. Hoy en día la información es el elemento más importante al interior de una organización, ya que ésta es el conjunto de elementos (datos, códigos, investigaciones, experiencias) que permiten la toma de decisiones sobre las situaciones que se presentan en cualquier medio; a partir de establecer relaciones entre los elementos y el problema o situación dada

22 Durante el desarrollo de aplicaciones web que cumplan con el objetivo de la compañía es común que aparezcan bugs o errores que hacen que el desarrollador intervenga para erradicar dichos bugs. Para un buen desarrollo hay que tener en cuenta diferentes modelos o arquitecturas de software y analizar cada una de las capas que nos ofrecen estas arquitecturas. Una vez adoptado la arquitectura que mejor resultados nos pueda generar, debemos seguir una metodología secuencial para así dar cumplimiento a todos los objetivos propuestos, esta metodología debe estar involucrada en todos los procesos que hacen parte de este sistema El usuario es parte primordial dentro del proceso de desarrollo, sobre todo cuando se diseña un sistema con procesos síncronos ya que estos dependen de un acontecimiento externo, generalmente un usuario para así continuar con el proceso MARCO LEGAL O NORMATIVO Un elemento crítico para el éxito y supervivencia de las organizaciones, es la administración efectiva de la información y definición de nuevas alternativas que le permitan mantenerse dentro del medio en constante cambio. Como punto de apoyo básico a estos cambios, se encuentra el desarrollo de proyectos que genera las nuevas aplicaciones necesarias para soportar el Plan Estratégico que definen las organizaciones, los cuales requieren de una adecuada administración de los recursos disponibles

23 Es importante tener en cuenta la normatividad que tiene el Banco de Bogotá, respecto al desarrollo de software (aplicaciones) y su respectiva entrega. POLÍTICAS PARA EL DESARROLLO DE PROYECTOS EN EL BANCO DE BOGOTÁ Para dar inicio al desarrollo de un proyecto, debe haber un requerimiento escrito del área usuaria interesada, una evaluación del impacto del mismo (alternativas de solución, recursos requeridos, tiempo requerido, impacto en el plan de trabajo de la División). Todo proyecto debe tener un Líder Técnico, un Líder Usuario, un Gerente de Proyecto y un equipo de trabajo. Todo proyecto debe contar con la siguiente documentación: Etapa Planificación Definición de requerimientos Diseño Pruebas Documentación Documentación Requerimiento Objetivo Alcance e impacto Cronograma Relación de interfaces Requerimientos de controles funcionales Recomendaciones sobre seguridades, perfiles y privilegios Diseño conceptual o funcional del proyecto Diseño físico / lógico o diseño técnico detallado Control de cambios (al diseño inicial) Plan de pruebas Manuales técnicos del producto Manuales de usuario del producto

24 Las actividades de ingeniería de software posteriores a su instalación o mantenimiento, deben preverse con anticipación, es decir, el desarrollo del software debe facilitar su propio mantenimiento garantizando que no se degrade como resultado de este proceso. Por lo tanto, el software construido debe propender por: Ser modular y de codificación simple. Ser parametrizable. Estar perfectamente documentado. Tener registros de pruebas. POLÍTICAS PARA ENTREGA DE APLICACIONES OBJETIVOS Establecer un marco general de referencia metodológico que permita identificar los requisitos para la realización de Cambios en las diferentes plataformas que se administran. Ayudar a garantizar el correcto funcionamiento del sistema, mediante la disminución de los errores de operación de la aplicación y la definición de acciones a tomar en caso de mensajes de error. Facilitar el desarrollo de versiones de una aplicación. Permitir a la División de Sistemas y de Operaciones, tener una documentación estándar

25 Facilitar la consulta de información relacionada con aplicaciones desarrolladas. Ayudar a la capacitación de los funcionarios de la División y a los usuarios del sistema. NORMAS GENERALES Cualquier sistema realizado por la División de Sistemas y de Operaciones, Sistemas Corporativos o contratado su desarrollo externamente por el Banco de Bogotá, deberá estar soportado por los manuales de usuario, operación, control y técnico y deberá cumplir con los estándares definidos. El líder del Proyecto o líder técnico o funcional para el caso de requerimientos, es el encargado de llevar el cambio, al Comité de Cambios de la División de Sistemas y Operaciones, donde se autoriza la fecha final para la realización del mismo. Para los paquetes adquiridos por el Banco y que tengan unos estándares preestablecidos debe continuarse con los mismos, en caso contrario, utilizar los mencionados en este capítulo. El Líder del proyecto, debe asegurar como parte de la planeación, que se cuenta con los recursos necesarios para la realización exitosa del plan, en lo que tiene que ver con recursos de hardware, software o espacio adicional de almacenamiento que se deba conseguir si el que existe en ambiente de Producción no es suficiente, tramitando las aprobaciones y

26 compras que se requieran por intermedio de la Gerencia de Investigación y Desarrollo. Toda modificación realizada a un sistema deberá documentarse tanto en los programas fuentes como en los manuales ya existentes y éstos deberán ser enviados a las diferentes áreas usuarias. La Gerencia de Tecnología procede a realizar una revisión de los cambios enviados, emite sus comentarios y recomendaciones necesarias, que den lugar a mejoras. Si el cambio da lugar a correcciones, no se debe continuar con el proceso de instalación. Cuando un proceso ejecutado en el área de Procesamiento tenga alguna implicación en los Centros de Operaciones, las Gerencias de Desarrollo deben generar un(os) instructivo(s) y enviarlo(s) a la Sección de Soporte Técnico para coordinar su distribución. La entrega de nuevas aplicaciones y actualizaciones debe ir con Acta de Entrega respectiva. Las actualizaciones de nuevas versiones, no deben efectuarse los días lunes, después de festivo, fin de mes, quincena o fin de año, ya que la oportunidad de la entrega de la información a las oficinas y clientes se pueden ver afectadas por errores en el cambio de los programas instalados. Buscando prestar un buen soporte en producción, la entrega de nuevas aplicaciones debe integrar un plan de capacitación

27 MANUALES Y PLANILLAS Para ejecutar una aplicación en el ambiente de Producción deben entregarse previamente los siguientes manuales y planillas (ó la actualización de los mismos): Planillas de Operación: Dirigido a los funcionarios del centro de cómputo. Deben generarse dos copias para el área de Procesamiento y Centro de Cómputo. Manual de Control: Dirigido a los funcionarios encargados de realizar el cuadre de las aplicaciones y verificar su correcto funcionamiento. Deben generarse dos copias para el área de Procesamiento. Manual del Usuario: Dirigido al área usuaria de la aplicación. Manual Técnico: Dirigido a las Gerencias de Desarrollo y Tecnología. Los manuales deben contener en parte inferior izquierda de la última línea la fecha de realización o modificación según sea el caso, en formato: MES (alfabético) Día/Año MARCO TEÓRICO Para el óptimo desarrollo de un aplicativo que solucione el problema que tiene la Gerencia Centro de Información Financiera del Banco de Bogotá en el proceso de gestión de requerimientos de información, debemos plantear una base teórica fundamentada en la versatilidad que nos proporcionan las aplicaciones web en el marco presentado por el mismo

28 UML El Lenguaje Unificado de Modelado preescribe un conjunto de notaciones y diagramas estándar para modelar sistemas orientados a objetos, y describe la semántica esencial de lo que estos diagramas y símbolos significan. Mientras que ha habido muchas notaciones y métodos usados para el diseño orientado a objetos, ahora los modeladores sólo tienen que aprender una única notación. UML se puede usar para modelar distintos tipos de sistemas: sistemas de software, sistemas de hardware, y organizaciones del mundo real. UML ofrece nueve diagramas en los cuales modelar sistemas. Diagramas de Casos de Uso para modelar los procesos 'business'. Diagramas de Secuencia para modelar el paso de mensajes entre objetos. Diagramas de Colaboración para modelar interacciones entre objetos. Diagramas de Estado para modelar el comportamiento de los objetos en el sistema. Diagramas de Actividad para modelar el comportamiento de los Casos de Uso, objetos u operaciones. Diagramas de Clases para modelar la estructura estática de las clases en el sistema. Diagramas de Objetos para modelar la estructura estática de los objetos en el sistema

29 Diagramas de Componentes para modelar componentes. Diagramas de Implementación para modelar la distribución del sistema. UML es una consolidación de muchas de las notaciones y conceptos más usadas orientados a objetos. Empezó como una consolidación del trabajo de Grade Booch, James Rumbaugh, e Ivar Jacobson, creadores de tres de las metodologías orientadas a objetos más populares. En 1996, el Object Management Group (OMG), un pilar estándar para la comunidad del diseño orientado a objetos, publicó una petición con propósito de un metamodelo orientado a objetos de semántica y notación estándares. UML, en su versión 1.0, fue propuesto como una respuesta a esta petición en enero de Hubo otras cinco propuestas rivales. Durante el transcurso de 1997, los seis promotores de las propuestas, unieron su trabajo y presentaron al OMG un documento revisado de UML, llamado UML versión 1.1. Este documento fue aprobado por el OMG en Noviembre de El OMG llama a este documento OMG UML versión 1.1. Aplicaciones Web Una aplicación web es una interface entre un formulario diseñado específicamente para cubrir con las necesidades de un negocio y su información, como pueden ser sistemas administrativos, inventarios, facturación, cuentas por cobrar, productos, etc. (la información puede ser de dominio público o restringida a ciertas personas a través de un nombre de usuario y contraseña) con el objetivo de que cualquier persona pueda consultarla e interactuar con ella desde Internet

30 En ingeniería de software una aplicación web es aquella que los usuarios usan accediendo a un servidor web a través de internet o de una intranet. Las aplicaciones web son populares debido a la practicidad del navegador web como cliente ligero. La habilidad para actualizar y mantener aplicaciones web sin distribuir e instalar software en miles de potenciales clientes es otra razón de su popularidad. En los primeros tiempos de la computación cliente - servidor, cada aplicación tenía su propio programa cliente y su interfaz de usuario, estos tenían que ser instalados separadamente en cada estación de trabajo de los usuarios. Una mejora al servidor, como parte de la aplicación, requería típicamente una mejora de los clientes instalados en cada una de las estaciones de trabajo, añadiendo un costo de soporte técnico y disminuyendo la eficiencia del personal. En contraste, las aplicaciones web generan dinámicamente una serie de páginas en un formato estándar, soportado por navegadores web comunes como HTML (acrónimo inglés de HyperText Markup Language), lenguaje de marcación diseñado para estructurar textos y presentarlos en forma de hipertexto, que es el formato estándar de las páginas web o XHTML (acrónimo inglés de extensible Hypertext Markup Language), es el lenguaje de marcado pensado para sustituir a HTML como estándar para las páginas web. XHTML es la versión XML de HTML, por lo que tiene, básicamente, las mismas funcionalidades, pero cumple las especificaciones, más estrictas, de XML. Su objetivo es avanzar en el proyecto del World Wide Web Consortium de lograr una web semántica, donde la información, y la forma de presentarla estén claramente separadas. Se utilizan lenguajes interpretados del lado del cliente, tales como JavaScript, para añadir elementos dinámicos a la interfaz de usuario. Generalmente cada página web individual es enviada al cliente como

31 un documento estático, pero la secuencia de páginas provee de una experiencia interactiva. Las aplicaciones web como ya se mencionó, vienen acompañadas de unos beneficios entre los cuales se pueden mencionar 2 : 1. Compatibilidad multiplataforma: Las aplicaciones web tienen un camino mucho más sencillo para la compatibilidad multiplataforma que las aplicaciones de software descargables. Varias tecnologías incluyendo Java, Flash, ASP y Ajax permiten un desarrollo efectivo de programas soportando todos los sistemas operativos principales. 2. Actualización: Las aplicaciones basadas en web están siempre actualizadas con el último lanzamiento sin requerir que el usuario tome acciones pro - activas, y sin necesitar llamar la atención del usuario o interferir con sus hábitos de trabajo con la esperanza de que va a iniciar nuevas descargas y procedimientos de instalación (algunas veces imposible cuando usted está trabajando dentro de grandes organizaciones). 3. Inmediatez de acceso: Las aplicaciones basadas en web no necesitan ser descargadas, instaladas y configuradas. Usted accede a su cuenta online y están listas para trabajar sin importar cuál es su configuración o su hardware. 4. Facilidad de prueba: Finalmente no habrá más obstáculos para permitir pruebas sencillas y efectivas de herramientas y aplicaciones antes de cargar su tarjeta de crédito. Actualmente, especialmente cuando hablamos de software costoso, hay todavía una gran cantidad de funcionalidades y 2 Información extraída de