SISTEMA WEB DE SOLICITUD DE SERVICIOS PARA LA EMPRESA CORE BUSINESS CONSULTING (Informe final de Práctica Profesional II (341))

Tamaño: px
Comenzar la demostración a partir de la página:

Download "SISTEMA WEB DE SOLICITUD DE SERVICIOS PARA LA EMPRESA CORE BUSINESS CONSULTING (Informe final de Práctica Profesional II (341))"

Transcripción

1 REPÙBLICA BOLIVARIANA DE VENEZUELA UNIVERSIDAD NACIONAL ABIERTA CARACAS - CENTRO LOCAL METROPOLITANO ÀREA DE INGENIERÍA INGENIERÍA DE SISTEMAS (236) SISTEMA WEB DE SOLICITUD DE SERVICIOS PARA LA EMPRESA CORE BUSINESS CONSULTING (Informe final de Práctica Profesional II (341)) Autora: T.S.U. Liliana Silva CI: V Tutor Académico: Ing. Agustin Noronha CI: V Tutora Empresarial: Ing. Krystell Rico CI: V Caracas, diciembre de 2012

2 INDICE GENERAL LISTA DE CUADROS... vi LISTA DE GRÁFICOS... ix RESUMEN...xiv CAPITULO I. EL PROBLEMA...3 Planteamiento del Problema...3 Objetivos...5 Justificación e importancia de la investigación...6 II. MARCO TEÓRICO...7 Antecedentes...7 Los Sistemas Web...9 Mercadeo de Servicios por Internet...9 Desarrollo de sistemas orientados a objetos Arquitectura del software Proceso Unificado de Desarrollo (RUP) Lenguaje Unificado de Modelado (UML) Metodología UWE Ingeniería del Software basada en Componentes Herramientas para el desarrollo de Sistemas Web Alcance del proyecto III. MARCO METODOLÓGICO Tipo de investigación Técnicas e Instrumentos de recolección de datos Metodología para el desarrollo del sistema Web IV. SISTEMA WEB DE SOLICITUD DE SERVICIOS (CBCSYS) Fase de Comienzo Fase de Elaboración Análisis y Diseño Fase de Construcción V. CONCLUSIONES Y RECOMENDACIONES CONCLUSIONES RECOMENDACIONES iv

3 Lista de Referencias Anexos A. Pantallas de OsTicket v

4 LISTA DE CUADROS CUADRO pp. 1. Notación UML para las clases con estereotipos Estereotipos en UWE para la navegación Estereotipos en UWE para la presentación Actividades y productos por cada Disciplina Listado de actores Listado de casos de uso Relaciones casos de uso asociados al portal - actores Relaciones casos de uso asociados a los Tickets- actores Descripción caso de uso Validar Administrador Portal Descripción caso de uso Gestión Portal Descripción caso de uso Incluir Articulo Descripción caso de uso Editar Artículo Descripción caso de uso Eliminar Articulo Descripción caso de uso Mostrar Página Inicio Descripción caso de uso Mostrar Información de CBC Descripción caso de uso Mostrar Servicios Descripción caso de uso Mostrar Cursos Descripción caso de uso Mostrar Noticias Descripción caso de uso Descargar Archivos Descripción caso de uso Validar Administrador Ticket Descripción caso de uso Gestión Tickets Descripción caso de uso Registrar Usuario CBC Descripción caso de uso Editar usuario CBC Descripción caso de uso Eliminar Usuario CBC Descripción caso de uso Solicitar Ticket vi

5 26. Descripción caso de uso Validar Usuario CBC Descripción caso de uso Consultar Tickets Descripción caso de uso Reasignar Ticket Descripción caso de uso Responder Ticket Descripción caso de uso Escribir nota interna Clases bordes subsistema Portal Clases bordes subsistema Ticket Clases Entidad Clases Control Clase InterfaceAdministrador Clase InterfaceBasedeDatosJoomla Clase InterfaceVisitante Clase JUser Clase JContent Clase JCategories Clase ManejadorUsuarioJoomla Clase ManejadorArticulo Clase InterfaceAdministrador Clase InterfaceBasedeDatosTicket Clase InterfaceVisitante Clase InterfacePersonalCBC Clase Staff Clase Ticket Clase ManejadorUsuarioT Clase ManejadorTicket Archivo ostconfig.php en OsTicket Archivo index.php en OsTicket (parte 1) Archivo index.php en OsTicket (parte 2) Deshabilitar la edición de Cbcadmin (parte 1) vii

6 55. Deshabilitar la edición de Cbcadmin (parte 2) viii

7 GRÁFICO LISTA DE GRÁFICOS pp. 1. Diagrama de caso de uso Ejemplo Diagrama de clase Diagrama de objetos Diagrama de secuencias cajero supermercado Diagrama de secuencia Alquiler de videos Diagrama de colaboración Diagrama de estados Diagrama de actividad Diagrama de componentes Diagrama de despliegue Diagrama de despliegue ( conexión entre nodos) Diagrama de caso de uso general CBCSYS Diagrama de actividad caso de uso: Solicitar Ticket Diagrama de actividad caso de uso: Registrar Usuario Prototipo Administración del Portal Joomla Prototipo Gestión portal Prototipo interfaz caso de uso Incluir articulo Prototipo interfaz caso de uso Editar artículo- pantalla artículos Prototipo interfaz caso de uso Editar artículo- pantalla Editar artículos Prototipo interfaz caso de uso Mostrar Página inicio Prototipo interfaz caso de uso Mostrar Información CBC Prototipo interfaz caso de uso Mostrar Servicios Prototipo interfaz caso de uso Mostrar Cursos Prototipo interfaz caso de uso Mostrar Noticias Prototipo interfaz caso de uso Descargar Archivos ix

8 26. Prototipo interfaz caso de uso Validar Administrador OsTicket Prototipo interfaz caso de uso Gestión Ticket Prototipo interfaz caso de uso Registrar usuario CBC Prototipo interfaz caso de uso Editar usuario CBC- listado de usuarios Prototipo interfaz caso de uso Editar usuario CBC Prototipo interfaz caso de uso Solicitar Ticket Prototipo interfaz caso de uso Consultar Ticket Prototipo interfaz caso de uso Reasignar Ticket Prototipo interfaz caso de uso Responder Ticket Prototipo interfaz caso de uso Escribir notas internas Clases bordes relacionadas con los actores Clases bordes caso de uso Validar Administrador Portal Clases bordes caso de uso Gestión portal Clases bordes caso de uso Incluir articulo Clases bordes caso de uso Editar artículo Clases bordes caso de uso Eliminar artículo Clases bordes caso de uso Mostrar Página inicio Clases bordes caso de uso Mostrar Información CBC Clases de borde caso de uso Mostrar Servicios Clases bordes caso de uso Mostrar Cursos Clases bordes caso de uso Mostrar Noticias Clases bordes caso de uso Descargar Archivos Clases bordes caso de uso Validar Administrador OsTicket Clases bordes caso de uso Gestión Ticket Clases bordes caso de uso Registrar usuario CBC Clases bordes caso de uso Editar usuario CBC Clases bordes caso de uso Eliminar usuario CBC Clases bordes caso de uso Solicitar Ticket Clases bordes caso de uso Validar usuario x

9 55. Clases bordes caso de uso Consultar Ticket Clases bordes caso de uso Reasignar Ticket Clases bordes caso de uso Responder Ticket Clases bordes caso de uso Escribir notas internas Diagrama de secuencia Validar Administrador Portal Diagrama de secuencia Gestión Portal Diagrama de secuencia Incluir articulo Diagrama de secuencia Editar artículo Diagrama de secuencia Eliminar artículo Diagrama de secuencia Mostrar página inicio Diagrama de secuencia Mostrar Información de CBC Diagrama de secuencia Mostrar Servicios Diagrama de secuencia Mostrar cursos Diagrama de secuencia Mostrar Noticias Diagrama de secuencia Descargar Archivos Diagrama de secuencia Validar Administrador Ticket Diagrama de secuencia Gestión Ticket Diagrama de secuencia Registrar Usuario CBC Diagrama de secuencia Editar Usuario CBC Diagrama de secuencia Eliminar Usuario CBC Diagrama de secuencia Solicitar Ticket Diagrama de secuencia Consultar Ticket Diagrama de secuencia Validar Usuario CBC Diagrama de secuencia Reasignar Ticket Diagrama de secuencia Responder Ticket Diagrama de secuencia Escribir notas internas Diagrama de clases Subsistema Portal Diagrama de clases Subsistema Ticket Diagrama de estados Subsistema Portal Clase Articulo xi

10 84. Diagrama de estados Subsistema Ticket Clase Ticket Estructura base de datos Joomla(1) Estructura base de datos Joomla(2) Estructura base de datos Joomla(3) Estructura base de datos OsTicket Modelo de Navegación Administrador Portal Modelo de Navegación Visitante Subsistema Portal Modelo de Navegación Administrador Subsistema Ticket Modelo de Navegación Personal Subsistema Ticket Diagrama de Presentación PantallaPanelJoomla Diagrama de Presentación PantallaIncluirArticulo Diagrama de Presentación PantallaInicio Diagrama de Presentación PantallaNosotros Diagrama de Presentación PantallaServicios Diagrama de Presentación PantallaCursos Diagrama de Presentación PantallaNoticias Diagrama de Presentación PantallaDescargas Diagrama de Presentación PantallaSolicitarTicket Diagrama de componentes Subsistema Portal Diagrama de componentes Subsistema Tickets Diagrama de Despliegue CBCSYS Configuración global Joomla Configuración de Usuarios Joomla Plantilla HTML para el registro de cursos Modificación del archivo template_list.js Módulo EasyFolderListing Configuración mensaje Ticket nuevo Configuración mensajes Responder Ticket y otros Configuración mensajes Responder Ticket y otros xii

11 113. Cambio de Logo de OsTicket al logo CBC (ostlogo) Cambio de Logo de OsTicket al logo CBC (logo-support) Pantalla inicio Pantalla Nosotros Pantalla servicios Pantalla cursos Pantalla noticias Pantalla Descargas Pantalla contacto Pantalla solicitar Ticket Pantalla Servicios en el navegador Mozilla Firefox Pantalla Cursos en el navegador Mozilla Firefox Prueba validar administrador Ticket Prueba editar usuario CBC - listado de usuarios Prueba editar usuario CBC - editar Prueba solicitar ticket Prueba solicitar ticket - correo Prueba solicitar ticket mensaje transacción exitosa Prueba Consultar ticket Prueba responder Ticket- listado de tickets Prueba responder Ticket - escribir respuesta xiii

12 REPÚBLICA BOLIVARIANA DE VENEZUELA UNIVERSIDAD NACIONAL ABIERTA CARACAS - CENTRO LOCAL METROPOLITANO ÀREA DE INGENIERÌA INGENIERÌA DE SISTEMAS (236) SISTEMA WEB DE SOLICITUD DE SERVICIOS PARA LA EMPRESA CORE BUSINESS CONSULTING RESUMEN Autora: Liliana Silva Tutor Académico: Ing. Agustin Noronha Tutora Empresarial: Ing. Krystell Rico Fecha: diciembre de 2012 Actualmente es importante para las empresas el mercadeo por internet de sus servicios y productos; así como agilizar por este medio la comunicación con sus clientes. En este sentido, la empresa venezolana Core Business Consulting(CBC) requería de un sistema web que presentara información de la empresa y gestionara las solicitudes de servicio (CBCsys). Por ello, se planteó como objetivo general de la investigación: Desarrollar un sistema Web de solicitud de servicios para la empresa CBC. Dicho sistema fue realizado bajo la metodología UWE (Ingeniería Web basada en UML) y la Ingeniería del Software Basada en Componentes (ISBC). La investigación es un proyecto factible apoyado en una investigación de campo, descriptiva y documental. Para obtener los requerimientos del sistema se realizaron entrevistas a la presidenta de la empresa y se presentaron prototipos en las fases de inicio y de elaboración de la metodología UWE. Como resultado de la investigación se obtuvo un sistema que abarca dos grandes procesos: a) CBCsite: presenta información de CBC con el Manejador de Contenido Joomla, el cual permite de una manera rápida y sencilla realizar la actualización de los contenidos presentados a los clientes, tales como: servicios, cursos, noticias, entre otros y b) CBCticket: permite gestionar las solicitudes de atención de los clientes hacia las distintas áreas de atención de la empresa; para ello se utilizó una aplicación en Software libre denominada Osticket. Las herramientas para el desarrollo del sistema fueron: PHP como lenguaje de programación y Mysql como manejador de base de datos. También se usaron las herramientas ArgoUML y Microsoft Visio para la elaboración de los distintos diagramas que contempla la metodología. Palabras claves: Sistema web, UWE, Solicitudes de servicio. xiv

13 INTRODUCCIÓN La evolución de Internet como red de comunicación global y el surgimiento y desarrollo del Web como servicio imprescindible para compartir información, creó un excelente espacio para la interacción empresa-clientes. Es así como, se han utilizado ampliamente las tecnologías de la Información basadas en Internet, tales como las páginas Web y el correo electrónico, para agilizar el proceso de comunicación con los clientes. Ahora bien, Core Business Consulting (CBC) es una empresa venezolana, fundada en marzo del 2005, que se dedica a la Consultoría en las Tecnologías de la Información, usando Software libre, en cuatro áreas de servicio: Inteligencia de negocios, Sistemas Transaccionales, Plataforma Tecnológica y recientemente Capacitación en cursos de corta duración. La empresa CBC poseía una página Web estática que se encontraba desactualizada, debido a que se habían elevado mucho los costos de mantenimiento porque era necesario contactar a la empresa que desarrolló dicha página para cada actualización. Por otra parte, con la apertura del área de Capacitación se esperaba un aumento en el número de llamadas telefónicas del visitante con el fin de solicitar información, inscribirse en los cursos, entre otros. Para resolver la situación problemática existente en CBC, se planteó el desarrollo de un Sistema Web (CBCSYS), que permita mejorar la comunicación y agilizar la solicitud de los servicios y la atención de los clientes en dicha empresa. Se pretende brindar una solución eficaz y eficiente, en el área de Sistemas, utilizando las últimas tecnologías informáticas disponibles y los conocimientos adquiridos a lo largo de la carrera. La metodología utilizada para el desarrollo del sistema fue UWE (Ingeniería Web basada en UML). UWE fue creada por Nora Koch en el año Es una metodología detallada para el proceso de autoría de aplicaciones Web, que extiende el lenguaje UML, mediante el uso de estereotipos y permite gestionar la documentación del sistema para generar una solución flexible, adaptable y que pueda integrarse con

14 otras aplicaciones existentes o futuras en la empresa. También se utilizó la Ingeniería del Software Basada en Componentes (ISBC). Aprovechando una ventaja del Software libre, que es la entrega del código fuente para su modificación y adaptación a las necesidades del programador, se utilizaron dos aplicaciones gratuitas y disponibles por Internet: (a) JOOMLA: es un Manejador de Contenido, en el cual se gestiona la información que se presenta al usuario en las páginas Web y (b) OsTicket: es un sistema de gestión de tickets típico donde los usuarios dan de alta sus tickets con un helptopic y una prioridad. Ambas aplicaciones están basadas en PHP como lenguaje de programación y MYSQL como manejador de base de datos. El trabajo se encuentra dividido en cinco (5) capítulos: 1. Capítulo I: El Problema: se describe la situación del problema, el trabajo a desarrollar, la solución propuesta y los beneficios esperados; así como el Objetivo General, los objetivos Específicos y la justificación e importancia de la investigación. 2. Capítulo II: Marco Teórico: contiene los antecedentes de la investigación y los aspectos conceptuales que soportan el trabajo realizado: Los Sistemas Web, mercadeo de servicios por Internet, Desarrollo de Sistemas Web, entre otros. 3. Capítulo III: Marco metodológico: presenta los aspectos metodológicos de la investigación, indicando el tipo de investigación, las técnicas e instrumentos de recolección de datos y la metodología UWE y la ISBC para el desarrollo del sistema Web. 4. Capítulo IV: Sistema Web de Solicitud de servicios (CBCSYS): se presenta en este capítulo el desarrollo del CBCSYS bajo la metodología UWE y la ISBC, abarcando las fases de comienzo, elaboración y Construcción. 2

15 CAPÍTULO I EL PROBLEMA Planteamiento del Problema Actualmente el uso de Internet como estrategia de mercadeo representa una ventaja competitiva, ya que permite captar más clientes y mantener activa la comunicación con ellos. La empresa Core Business Consulting(CBC), es una empresa Consultora venezolana, ubicada en Caracas. Fue fundada en marzo de 2005 con el fin de ofrecer soluciones y capacitación en software libre, con respecto a tres áreas, (www.cbcvenezuela.com): 1. Inteligencia de negocios: se refiere a soluciones en cuanto a monitorear la gestión de la empresa cliente, en aspectos como presupuestos, indicadores de desempeño e integración de datos propios - competidores y con la información del mercado. 2. Sistemas transaccionales: se refiere a sistemas de información web que servirán de base para desarrollos futuros, bajo una metodología de desarrollo y estándares de programación. 3. Plataforma Tecnológica: Conocimientos básicos en redes, administración de Linux, instalación y configuración de los servidores de: dominio, impresión, web, correo, proxy y firewall, implementación de políticas de seguridad, monitoreo de la plataforma tecnológica. Desde el 2005 hasta la fecha, Core Business Consulting(CBC) ha suministrado sus servicios en las tres áreas especificadas a más de treinta clientes, en su mayoría empresas del sector de la administración pública, entre ellas: Comisión de administración de divisas, Servicio Autónomo de Sanidad Agropecuaria y Banco del Pueblo Soberano. Desde el mes de octubre del 2010 la empresa ha incursionado adicionalmente en el área de capacitación en Tecnologías de la información, usando software libre. 3

16 Para ello ha contratado a un conjunto de instructores con sólida formación en: base de datos, administración de plataformas tecnológicas y de contenido, desarrollo de software, Inteligencia de Negocios, Data Warehouse, entre otros. La empresa CBC posee una página Web con información general y estática para la promoción de sus servicios. Para modificaciones de esta página hay que contactar a la empresa que la desarrolló y esperar su actualización, lo cual ha traído como consecuencia que los contenidos allí reflejados no estén acordes con la realidad actual, por ello se hace necesaria su actualización y la colocación de contenidos que se puedan actualizar rápidamente. Otra situación observada es que los clientes potenciales no disponen de un Sistema web que les permita solicitar directamente los servicios de consultoría y de desarrollo de soluciones en las distintas áreas de la empresa y contar con información detallada al respecto. Por otra parte, la ampliación de los servicios al área de capacitación en cursos abiertos al visitante, plantea la necesidad de facilitar la comunicación, ya que los clientes son variados y dinámicos. Actualmente, la empresa posee una lista de clientes potenciales a los cuales se les envían correos electrónicos promoviendo los servicios. En el caso de los cursos, se indican las fechas de inicio y fin, número de horas y los costos asociados. La atención a los clientes también se realiza mediante vía telefónica. Generalmente, se maneja un conjunto de cursos que varían por trimestre y aumentarán de acuerdo a la demanda, en consecuencia se estima una carga administrativa mayor para la secretaria, que podría causar demoras en la atención de los clientes. De acuerdo a lo anteriormente planteado, surge la necesidad de dar respuesta oportuna a los requerimientos de los clientes, mediante un sistema que permita gestionar las solicitudes de servicios y de atención a los clientes, de forma tal que se pueda establecer un contacto inicial con ellos( personas naturales o jurídicas) y luego enviar una respuesta que dependiendo de la solicitud realizada puede ser información por medio de la aplicación, contacto telefónico o por correo electrónico. Se requiere adicionalmente, llevar el seguimiento de las solicitudes; distribuyendo las mismas 4

17 entre el personal que labora en la empresa, dependiendo del área técnica y permitiendo cambiar el status: abierto al recibir la solicitud, en proceso o cerrado cuando ya fue atendida, asimismo el cliente puede consultar en cualquier momento el status de sus solicitudes. Bajo este contexto, un Sistema Web para la empresa CBC, facilitaría el contacto inicial con los clientes, así como la comunicación y la atención a los mismos, ya que podrían tener información actualizada referida a los servicios, como por ejemplo: descripción detallada de cada servicio, cronogramas de cursos, contenidos de los cursos, entre otras. Asimismo, se podrían gestionar las solicitudes de servicios e información que requieran los clientes, de manera que se puedan consultar en cualquier momento el status de sus solicitudes y se agilice el proceso. Ahora bien, para la empresa es importante que el sistema Web se desarrolle en software libre, ya que podrían tener acceso al código fuente y realizar las actualizaciones con su propio personal técnico. En las investigaciones realizadas se encontró disponible el software Osticket que cumple con algunos de los requerimientos solicitados y se puede modificar e integrar con otras aplicaciones y/o herramientas de software libre (ver anexo 1). Para cumplir con el resto de los requerimientos se desarrollarán los subsistemas que correspondan. Objetivos Objetivo general Desarrollar un sistema Web de solicitud de servicios para la empresa Core Business Consulting. Objetivos específicos Diagnosticar la situación actual del proceso de solicitud de servicios para la empresa CBC. Realizar el análisis del sistema Web propuesto. 5

18 Diseñar el sistema Web que permita a los clientes de la empresa CBC hacer las solicitudes de servicios. Implementar el sistema Web. Probar el sistema Web. Justificación e importancia de la investigación El sistema permitirá agilizar los procesos de solicitud de servicios e información a la empresa CBC y, de manera concisa y eficaz mostrar los servicios y gestionar las solicitudes; los clientes obtendrán respuestas oportunas a sus solicitudes y la información necesaria para la toma de decisiones en cuanto a los servicios que se ofrecen, entre ellos la capacitación mediante cursos. Por otra parte, el uso de la Tecnología Web le dará a la empresa una mayor ventaja competitiva. En este sentido es importante destacar que existen empresas con una amplia trayectoria en el área de cursos y disponen de sistemas Web para la promoción de los mismos, entre ellas podemos destacar: Benllisoft, Centro de Enseñanza asistida por computador (CENEAC) de la Universidad Central de Venezuela y Softrain Caracas. 6

19 CAPÍTULO II MARCO TEÓRICO Antecedentes Se consultaron Trabajos especiales de grado de la Universidad Nacional Abierta., por medio de la biblioteca digital: y se encontraron cuatro(4) trabajos relacionados con la presente investigación. 1. Espinosa Miguel (2005). Sistema de inscripción en línea de los cursos de extensión desde el sitio Web ULA- Táchira. Este trabajo se toma como referencia ya que proporciona algunas bases teóricas y prácticas en cuanto al desarrollo de sitios Web, el uso de PHP como lenguaje de programación y de Mysql como manejador de base de datos. Asimismo, presenta similitud con respecto a la oferta de los cursos como servicio. 2. Fabia Halabi De el Halabi (2008). Portal Web para la información turística de Caicara del Orinoco, estado Bolivar. El aporte de este trabajo para la presente investigación está constituido por el uso de PHP como lenguaje de programación y de Mysql como manejador de base de datos. 3. Mora Raúl Andrés(2010). Portal Web informativo y de solicitud de servicios para la gobernación del estado Trujillo basado en herramientas interactivas de comunicación. En este trabajo se gestionan las solicitudes de servicios, referidos a pagos y constancias de trabajo, igualmente se presenta información sobre la gobernación del estado Trujillo. En este sentido, presenta similitudes con respecto a la investigación planteada, ya que se desea presentar al usuario la información de los distintos servicios que presta la empresa CBC y gestionar las solicitudes de servicios en las distintas áreas. 4. Febres G. Joseline(2010). Portal Web del Vicerrectorado académico de la Universidad Nacional Experimental de la Fuerza Armada (UNEFA). En esta investigación se utilizó la metodología RUP y el manejador de contenido JOOMLA, lo cual sirvió de referencia para el sistema Web desarrollado. 7

20 Por otra parte, se encontraron otros trabajos de diferentes países que ayudaron para la aplicación de la metodología UWE. Los de mayor relevancia fueron: 1. Tamayo Urgilès Diego Armando (2011). Análisis diseño e implementación de un sistema Web para administración de recursos de empresas productoras de muebles de oficina. El sistema desarrollado permitirá mejorar el proceso de Gestión de la producción y ventas para la industria de los muebles de oficina en el Ecuador. 2. Chavez Contreras Edith (2008). Transferencia de Información entre una Base de datos y una Aplicación de Comercio Electrónico mediante XML. El producto obtenido en este trabajo fue un prototipo de una tienda virtual dedicada a la comercialización de música por Internet, Music-e-Shop, dentro del paradigma de Negocio a clientes. 3. Quispe Apaza, Tony.(2009). Desarrollo de un ambiente educativo virtual. Esta investigación tuvo como objetivo desarrollar un ambiente educativo virtual en el Instituto Superior de Electrónica, Informática y Telecomunicaciones Santo Toribio de Mogrovejo, para facilitar el proceso de enseñanza y como un complemento a los cursos presenciales. Se utilizó la metodología SCRUM y la metodología UWE. 4. Llerena Espinosa, S. y Vivero Montalvo P. (2010). Desarrollo de una plataforma informática para el soporte de una comunidad virtual universitaria. El objetivo fue desarrollar e implantar, en base a fundamentos de la Ingeniería de Software, una plataforma informática que brinde soporte a una comunidad virtual académica dirigida a estudiantes universitarios, basada en la mayoría de características de lo que se conoce como Web 2.0 y en la utilización de herramientas de software libre. Se usó el manejador de contenido Joomla y la metodología UWE. 8

21 Los Sistemas Web Los sistemas Web, también denominados Aplicaciones Web son aquellas que los usuarios pueden utilizar accediendo a un servidor a través de una Intranet local o Internet haciendo uso de un navegador, se codifican en un lenguaje soportado por los navegadores web y son interactivas y dinámicas permitiendo el uso de base de datos. Las Aplicaciones Web son populares debido a lo práctico del navegador web como cliente ligero, a la independencia del sistema operativo, así como a la facilidad para actualizar y mantener aplicaciones web sin distribuir e instalar software a miles de usuarios potenciales. Existen muchas variantes posibles a nivel de estructura en una aplicación web, sin embargo éstas usualmente están estructuradas como una aplicación de tres capas: (a) interfaz de usuario: es ofrecido por el navegador web, (b) la segunda capa la representa el motor capaz de usar una tecnología web dinámica (ejemplo: PHP, Java Servlets, ASP, ASP.NET, Python, etc.) y (c) capa de la aplicación: la constituye la base de datos. En esta investigación se plantea el uso de PHP como lenguaje de programación y Mysql como manejador de base de datos. Mercadeo de Servicios por Internet En la dirección: podemos encontrar la clasificación del mercado de servicios, esto se cita con el fin de clasificar a la empresa y proponer posteriormente algunas estrategias que proporcionen mayor eficacia en el sistema a implementar. El mercado de servicios está compuesto básicamente por cuatro tipos de mercado en el que confluyen la oferta y la demanda de servicios: 1. El mercado de servicios del sector público: La oferta de este mercado está conformado por las instituciones del estado que ofrecen y brindan diversos servicios a través del parlamento, agencias públicas de empleo, servicios 9

22 militares, policiales y de bomberos, correos, escuelas, universidades, hospitales públicos, instituciones reguladoras, defensorías públicas, etc. Por su parte, la demanda de este mercado está conformado básicamente por la "población en su conjunto". 2. El mercado de servicios del sector privado: La oferta de este mercado está conformado por diversos tipos de organizaciones y empresas que se dividen en dos grandes grupos: 1) Instituciones no lucrativas: Son organizaciones que ofrecen servicios sin fines de lucro, ya que su objetivo es cumplir con una determinada labor social. Algunos ejemplos de este tipo de instituciones son: los museos, las iglesias, las fundaciones y 2) empresas de servicios con fines de lucro: Se dividen en dos: 1) Empresas que ofrecen servicios a negocios como: estudios de mercado, publicidad, transporte, préstamos bancarios, seguros, servicios jurídicos, servicios contables, consultorías, etc. 2) Empresas que ofrecen servicios de consumo, como: renta de viviendas, recreación, entretenimiento. 3. El mercado de servicios del sector productivo: A este mercado pertenecen los millones de suministradores de servicios, tales como operadores informáticos, contadores, personal de limpieza, etc., que según Kotler, Cámara, Grande y Cruz, constituyen una «factoría de servicios» que proporciona servicios a «empresas productivas» [2]. 4. El mercado de servicios en internet: La oferta y demanda de servicios en internet está proliferando rápidamente, en especial, los orientados hacia los negocios. Por ese motivo, en la actualidad muchas empresas y emprendedores ofrecen y/o solicitan servicios de asistencia virtual, consultorías, educación a distancia (online), asesoramiento, ventas online, diseño de sitios web, diseño gráfico, entre otros. Desarrollo de sistemas orientados a objetos Las metodologías de análisis y diseño orientadas a objetos presentan las siguientes ventajas sobre las metodologías estructuradas (Booch,1996): 10

23 1. Produce sistemas más pequeños a través de la reutilización de mecanismos comunes, proporcionando así una importante economía de expresión. 2. Los sistemas Orientados a Objetos son más resistentes al cambio y por tanto están mejor preparados para evolucionar en el tiempo, porque sus diseños están basados en formas intermedias estables. 3. Reduce en gran medida el riesgo que representa construir sistemas de software complejos porque están diseñados para evolucionar de forma incremental partiendo de sistemas más pequeños en los que ya se tiene confianza. 4. Resuelve indirectamente la complejidad innata del software ayudando a tomar decisiones inteligentes respecto a la separación de intereses en un gran espacio de estados. 5. Existen aplicaciones de software libre desarrolladas bajo esta metodología, por lo cual se tiene acceso al código fuente y se pueden adaptar a las necesidades y características de la empresa CBC. Arquitectura del software La arquitectura del software implica el diseño y la implementación de estructuras de software de alto nivel. Es el producto del ensamblaje adecuado de elementos arquitectónicos para obtener la mayor funcionalidad y requerimientos de desempeño de un sistema, y también de satisfacer requerimientos no funcionales tales como, la confiabilidad, escalabilidad, portabilidad y disponibilidad. Dentro de los tipos de arquitectura más usados de software se encuentran: Monolítica: el software se estructura en grupos funcionales muy acoplados. Cliente-servidor: el software reparte su carga de cómputo en dos partes independientes pero sin reparto claro de funciones. Arquitectura de tres niveles: la carga se divide en tres partes (o capas) con un reparto claro de funciones para cada una de ellas. Una capa es para la 11

24 presentación (interfaz de usuario), otra para el cálculo (donde se encuentra modelado el negocio) y otra para el almacenamiento (persistencia). Una capa solamente tiene relación con la siguiente. Orientada a servicios: define la utilización de servicios para dar soporte a los requisitos del negocio. Proceso Unificado de Desarrollo (RUP) El proceso Unificado de Desarrollo fue creado por Booch, Jacobson, y Rumbaugh, en el año 2000, con el fin de mitigar los riesgos en el proceso de desarrollo de software. Este proceso contiene todas las actividades necesarias para convertir los requisitos de un usuario en un sistema software. Sigue un proceso iterativo e incremental. Fases del Proceso Unificado de Desarrollo 1. Fase de comienzo o inicio: el objetivo en esta etapa es concretar la visión del proyecto. Es la etapa donde se establecen los requerimientos y se delimita el alcance del proyecto. Finalmente se determinan los objetivos del ciclo de vida. 2. Fase de elaboración: en esta fase se planifican las actividades a ejecutar y los recursos necesarios, haciendo énfasis en la arquitectura del software a utilizar. Al término de esta fase se llega al punto de no retorno del proyecto, ya que luego de ésta se debe afrontar la fase de construcción que es la más costosa y arriesgada. 3. Fase de construcción: es la fase en la que se desarrolla el producto y se observa la evolución de la visión, la arquitectura y los planes hasta obtener la primera versión de lo que será manejado por el usuario final. En esta fase se hace especial énfasis en el control de las operaciones realizadas, administrando los recursos eficientemente de tal forma de minimizar costes, cumplir con el calendario y garantizar la calidad. 12

25 4. Fase de transición: en esta fase se efectúa la transición del producto a los usuarios, lo cual incluye: manejo del producto, envío, entrenamiento, documentación, soporte y mantenimiento del producto hasta que el cliente esté satisfecho. Cada una de estas etapas o fases es desarrollada mediante el ciclo de iteraciones. Una iteración es un ciclo de desarrollo completo dando como resultado una entrega de producto ejecutable (interna o externa). Desarrollo Iterativo El desarrollo iterativo es un método de construcción de productos cuyo ciclo de vida está compuesto por un conjunto de iteraciones, las cuales tienen como objetivo entregar versiones del software. Cada iteración se considera un subproyecto que genera productos de software y no sólo documentación, permitiendo al usuario tener puntos de verificación y control más rápidos e induciendo un proceso continuo de pruebas y de integración desde las primeras iteraciones. Las iteraciones están compuestas por el conjunto de disciplinas o actividades ya conocidas en el proceso de desarrollo de software. Estas son la especificación de requerimientos, el análisis y diseño, las pruebas, la administración de la configuración y el proceso de gerencia de proyectos. El grado de esfuerzo que se invertirá en cada disciplina va a depender de la fase del proceso en la cual se encuentre el proyecto. Arquitectura del sistema El conjunto de todas las vistas representa a la arquitectura. Cada vista es una perspectiva diferente del sistema. Se usa para la comprensión del sistema. Se divide el proyecto en clases para facilitar su reutilización. Todas las personas que trabajen en el desarrollo del sistema deben comprenderla lo cual es un reto difícil porque: operan en entornos complejos y al dividirlos en miniproyectos es difícil coordinarlos. 13

26 Mientras más grande sea el proyecto habrá mayor sobrecarga en la comunicación entre los distintos desarrolladores; para ello se divide el sistema en subsistemas donde cada uno tendrá un responsable. También es importante tener interfaces bien definidas. La arquitectura se ve condicionada por: Los casos de usos más importantes (más significativos). El producto software que se desea desarrollar. Por ejemplo: sistemas operativos, base de datos, entre otros. Los productos de capa media que se van a utilizar. Sistemas heredados a utilizar. Estándares y políticas corporativas. Requisitos no funcionales. La arquitectura del sistema se desarrolla en fase de elaboración junto con los casos de usos más importantes. Una vez que se tiene una arquitectura estable se realiza el resto de los casos de uso (los menos relevantes) que por lo general se basan en los requisitos de los clientes y usuarios. Cada vez que se quiera implementar un conjunto de Casos de Uso al sistema, lo ideal es ampliar la arquitectura para darles soporte. Dicha ampliación se realiza una vez por cada iteración. 14

27 Lenguaje Unificado de Modelado (UML) UML, por sus siglas en inglés, Unified Modeling Language es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables. Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo. Se puede aplicar en el desarrollo de software entregando gran variedad de formas para dar soporte a una metodología de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o proceso usar. En esta investigación se utiliza UML dentro de la metodología UWE, la cual será descrita posteriormente. Según IBM Libro 1: análisis y Diseño de Sistemas Orientado a Objetos (2006) UML está constituido por tres(3) elementos importantes : (a) bloque de construcción de UML, (b) reglas que ayuden a agrupar los bloques de construcción y (c) mecanismos comunes aplicados en el proceso de uso del lenguaje de modelado. Antes de entrar en detalle sobre cada uno de estos elementos, pasemos a definir algunos términos básicos de UML. 15

28 Términos básicos de UML Caso de uso: es una descripción de un conjunto de acciones que realiza un sistema con respecto a un actor particular interesado en el sistema, definiendo al actor como una entidad que interactúa con algún aspecto del sistema. Colaboración: se usa en UML para representar una sociedad de elementos, tanto estáticos como dinámicos, que ayuden a implementar el comportamiento de un caso de uso, esto es, un caso de uso es realizado por una colaboración. La colaboración de un caso de uso se representa como una elipse punteada. Clase: representa un dominio de objetos que comparten los mismos atributos, operaciones y relaciones. Son tipos de datos definidos por el usuario. Clase activa: es una clase cuyos objetos pueden poseer uno o mas procesos y pueden iniciar una actividad de control. Objeto: es una instancia de una clase, se define en términos del comportamiento que muestre o se espere que muestre. Interfaz: es un conjunto de operaciones que revela los servicios ofrecidos por una clase o componente. Componente: es la parte reemplazable de un sistema. Tal reemplazo es posible sólo si el componente se ajusta al contrato proporcionado por la interfaz. Nodo: es un recurso que existe en tiempo de ejecución, es un elemento estructural físico. Interacción: las interacciones son mensajes que se pasan entre objetos para permitirles interactuar unos con otros con el fin de acometer una tarea particular. Evento: es un suceso o hecho en el sistema que causa una transición de estado, posee tiempo y espacio asociados a él. Por ejemplo: un suceso que cambie el estado de un objeto de Activo a Inactivo. Máquina de estado: describe los diferentes estados que atraviesa un objeto en respuesta a eventos. 16

29 Paquete: es un mecanismo para agrupar elementos, comúnmente estos elementos son clases y sus relaciones. Esto es similar al concepto de módulos, donde los elementos de la función son agrupados. Bloques de construcción de UML Según IBM Libro 1: análisis y Diseño de Sistemas Orientado a Objetos (2006) los bloques de construcción de UML se clasifican en tres conceptos amplios: (a) elementos del modelo, (b) relaciones y (c) diagramas. 1. Elementos del modelo: existen cuatro tipos de elementos del modelo: Elementos estructurales: son entidades estáticas, que representan ya sea un elemento físico o uno conceptual. Está constituido por los casos de uso, las colaboraciones, las clases, clase activa, la interfaz, componente y nodo. Elementos de comportamiento: son entidades dinámicas, se clasifican en Interacción y Máquina de estados. Elementos de agrupación: representan elementos organizacionales para crear grupos, a cada elemento de este tipo se le denomina Paquete. Elementos de anotación: se usan para describir las partes de UML. Se tiene un elemento de anotación llamado nota, que se usa para documentar restricciones y comentarios asociados con los elementos. 2. Relaciones: las relaciones en UML se clasifican en: Dependencia: es una relación semántica entre dos elementos. Un cambio en un elemento puede causar un cambio en el elemento dependiente. Asociación: es una relación estructural. Es el enlace entre dos o más objetos en el sistema, es a través de la asociación que los objetos interactúan unos con otros para cumplir tareas específicas. Generalización o herencia: establece la relación generalización/ especialización. El objeto especializado, el hijo, hereda los atributos, operaciones, relaciones y semántica de la clase generalizada, el padre. 17

30 Realización: esta relación existe entre las interfaces y las clases o componentes que realizan o implementan las interfaces. También existe entre casos de uso y las colaboraciones que realizan los casos de uso. 3. Diagramas: un diagrama es una representación gráfica, que proporciona una vista del sistema. Los tipos de diagramas son: diagrama de casos de uso, diagrama de clases, diagrama de objetos, diagrama de secuencia, diagrama de colaboración, diagrama de estados, diagrama de actividad, diagrama de componente y diagrama de Despliegue (los dos últimos son llamados colectivamente diagramas de implementación). Seguidamente ahondaremos en los diagramas utilizados en UML. Diagrama de casos de uso (use case) Un diagrama de casos de uso representa la forma en como un Cliente (Actor) opera con el sistema en desarrollo. Un diagrama de casos de uso consta de los siguientes elementos: Actor: es un rol que un usuario juega con respecto al sistema, por lo cual un Actor no necesariamente representa a una persona en particular, sino mas bien la labor que realiza frente al sistema. Se representa mediante el siguiente símbolo: Casos de uso: es una operación/tarea específica que se realiza tras una orden de algún agente externo, sea desde una petición de un actor o bien desde la invocación desde otro caso de uso. Se representa mediante el siguiente símbolo: Observe un ejemplo de diagrama de caso de uso: (ver gráfico 1) 18

31 Gráfico 1. Diagrama de caso de uso. Tomado de: Diagrama de clases Un diagrama de clases permite visualizar las relaciones entre las clases que involucran el sistema, se compone de los siguientes elementos: Clase (atributos, métodos y visibilidad), relaciones (herencia, composición, agregación, asociación y realización o uso). El elemento Clase es la unidad básica que encapsula toda la información de un objeto, a través de ella podemos modelar el entorno en estudio. En este caso, las solicitudes de servicio, las áreas de servicio, los técnicos, entre otros. divisiones: En UML, una clase es representada por un rectángulo que posee tres Un ejemplo de diagrama de clase se observa a continuación. (Ver gráfico 2). 19

32 Gráfico 2. Ejemplo Diagrama de clase. Las clases pueden representarse con Estereotipos, para reflejar el tipo de funcionalidad de un objeto dentro de una arquitectura. Al respecto, señala Weitzenfelf (2008) los siguientes estereotipos (P. 255): Entidad(entity): para los objetos que guardan información sobre el estado interno del sistema corto y a largo plazo. Estos objetos corresponden al dominio del problema. Borde(boundary): para los objetos que implementan las interfaces del sistema con el mundo externo, correspondientes a todos los actores, incluyendo aquellos que no son humanos. Control: para los objetos que implementan el comportamiento o control de la lógica de los casos de uso, especificando cuándo y cómo el sistema cambia de estado. 20

33 A continuación se presenta la notación UML de los tres estereotipos: Entidad, Borde y Control. (Ver cuadro 1). Cuadro 1 Notación UML para las clases con estereotipos Estereotipo Notación como rectángulo Notación como íconos Entidad <<Entidad>> Nombre de la Clase1 Borde <<Borde>> Nombre de la Clase2 Nombre de la clase1 Control <<Control>> Nombre de la Clase3 Nombre de la clase2 Nombre de la clase3 Diagrama de Objetos Un diagrama de objetos muestra un conjunto de objetos y sus relaciones. Un ejemplo se observa a continuación. (Ver gráfico 3). Gráfico 3. Diagrama de objetos. 21

34 Diagrama de interacción Según IBM Libro 1: análisis y Diseño de Sistemas Orientado a Objetos (2006) el diagrama de interacción representa la forma en como un cliente (Actor) u Objetos (Clases) se comunican entre sí en petición a un evento. Esto implica recorrer toda la secuencia de llamadas, de donde se obtienen las responsabilidades claramente. Dicho diagrama puede ser obtenido de dos partes, desde el Diagrama estático de clases o el de Casos de Uso. Los componentes de un diagrama de interacción son: (a) un objeto o actor, (b) mensaje de un objeto a otro objeto y (c) mensaje de un objeto a sí mismo. Se utilizan los siguientes símbolos: Objeto/Actor: representa una instancia de un Objeto en particular, y la Líne línea punteada indica las llamadas a métodos del objeto. Mensaje a otro objeto: se relaciona por una flecha entre un objeto y otro, que indica la llamada de un método (operación) de un objeto en particular. Los Diagramas de interacción se clasifican en: Diagramas de secuencias y Diagramas de colaboración. Diagrama de secuencias Muestra el ordenamiento en el tiempo de los mensajes, así como el enfoque de control de cada objeto que participa en un escenario. (ob. cit). Un diagrama de secuencia es una forma de diagrama de interacción que muestra los objetos como líneas de vida a lo largo de la página y con sus interacciones en el tiempo representadas como mensajes dibujados como flechas desde la línea de vida origen hasta la línea de vida destino. Los diagramas de secuencia son buenos para mostrar qué objetos se comunican con qué otros objetos y qué mensajes disparan esas comunicaciones. Los diagramas de secuencia no están pensados para mostrar lógicas de procedimientos complejos. Observe a continuación dos ejemplos. El primer ejemplo está relacionado con el pago de articulo de un 22

35 supermercado (Ver gráfico 4) y el segundo con una empresa de alquiler de películas. (Ver gráfico 5). Gráfico 4. Diagrama de secuencias cajero supermercado. Gráfico 5. Diagrama de secuencia Alquiler de videos. 23

36 Diagrama de colaboración Muestra la organización estructural de objetos que interactúan unos con otros. Observe un ejemplo a continuación. (Ver gráfico 6). Gráfico 6. Diagrama de colaboración. Tomado de: Diagrama de estados Un diagrama de estados se usa para representar máquinas de estado. Está conformado por: estados, transiciones, eventos y acciones (ob. cit). Un diagrama de estados muestra la secuencia de estados por los que pasa bien un caso de uso, bien un objeto a lo largo de su vida, o bien todo el sistema. En él se indican qué eventos hacen que se pase de un estado a otro y cuáles son las respuestas y acciones que genera. En cuanto a la representación, un diagrama de estados es un grafo cuyos nodos son estados y cuyos arcos dirigidos son transiciones etiquetadas con los nombres de los eventos. Un estado se representa como una caja redondeada con el nombre del estado en su interior. Una transición se representa como una flecha desde el estado origen al estado destino. 24

37 La caja de un estado puede tener 1 o 2 compartimientos. En el primer compartimiento aparece el nombre del estado. El segundo comportamiento es opcional, y en él pueden aparecer acciones de entrada, de salida y acciones internas. Una acción de entrada aparece en la forma entrada/acción_asociada donde acción_asociada es el nombre de la acción que se realiza al entrar en ese estado. Cada vez que se entra al estado por medio de una transición la acción de entrada se ejecuta. Una acción de salida aparece en la forma salida/ acción_asociada. Cada vez que se sale del estado por una transición de salida la acción de salida se ejecuta. Una acción interna es una acción que se ejecuta cuando se recibe un determinado evento en ese estado, pero que no causa una transición a otro estado. Se indica en la forma nombre_de_evento/acción_asociada. Observe a continuación un ejemplo. (Ver gráfico 7). Gráfico 7. Diagrama de estados. Un diagrama de estados puede representar ciclos continuos o bien una vida finita, en la que hay un estado inicial de creación y un estado final de destrucción (finalización del caso de uso o destrucción del objeto). El estado inicial se muestra como un círculo sólido y el estado final como un círculo sólido rodeado de otro círculo. En realidad, los estados inicial y final son pseudoestados, pues un objeto no puede estar en esos estados, pero nos sirven para saber cuáles son las transiciones inicial(es) y final(es). 25

38 Diagrama de actividad Muestra el flujo de una actividad a otra en el sistema. Es un tipo de diagrama de estados. Se usa para modelar los aspectos dinámicos de un sistema. (Ver gráfico 8). Gráfico 8. Diagrama de actividad. Diagrama de componentes Un componente en UML es aquel que realiza o usa una interfaz (conjunto de operaciones que una clase o componente revela al mundo exterior). Existen tres tipos de componentes: 1. Componentes de despliegue o Distribución (Deployment): se usan para formar un sistema ejecutable. Por ejemplo: la librería de enlace dinámico, los archivos ejecutables, componentes COM+, Enterprise Java Beans, componentes CORBA y objetos de base de datos. 2. Componentes de Producto de Trabajo: son parte del proceso de desarrollo que es esencial para el sistema. Algunos ejemplos son: los archivos fuente, archivos de datos y tablas. 26

39 3. Componentes de ejecución: son el resultado de un sistema que se está ejecutando. Por ejemplo: un DLL que es instanciado como un componente COM+. Un diagrama de componentes es un conjunto de componentes y la relación entre ellos. Se pueden agregar notas y restricciones a un diagrama de componentes. Se usa para modelar la implementación estática de los elementos físicos que residen en un nodo, como los ejecutables, librerías, tablas y archivos. Se utilizan los siguientes símbolos: Representa al componente. UML define cinco (5) estereotipos estándar que se aplican a los componentes: Executable: especifica un componente que se puede ejecutar en un nodo. Library: especifica una biblioteca de objetos estática o dinámica. Table: especifica una tabla de una base de datos. File: representa un documento que contiene código fuente o datos. Document: representa un documento. gráfico 9). Observemos a continuación un ejemplo de diagrama de componente. (Ver Gráfico 9. Diagrama de componentes. 27

40 Diagrama de Despliegue Los diagramas de despliegue (deployment) muestran la disposición de los elementos de procesamiento en tiempo de ejecución. Estos elementos contienen componentes, procesos y objetos (ob. cit). A cada elemento físico que existe en tiempo de ejecución y que representa un recurso computacional (un procesador o un dispositivo sobre el que se pueden desplegar los componentes) se le denomina NODO y su símbolo se presenta a continuación: Los componentes representan el empaquetamiento físico de los elementos lógicos, mientras que los nodos representan el despliegue físico de los componentes. La relación entre un nodo y el componente que despliega puede mostrarse con una relación de dependencia, o listando los nodos desplegados en un compartimiento adicional dentro del nodo, tal como se presenta a continuación: Observemos a continuación un ejemplo de diagrama de despliegue, donde se pueden distinguir tipos de nodos y conexiones por estereotipado. (Ver gráfico 10). 28

41 Gráfico 10. Diagrama de despliegue. gráfico 11). En el siguiente ejemplo podemos apreciar la conexión entre nodos. (Ver Gráfico 11. Diagrama de despliegue ( conexión entre nodos).tomado de : Metodología UWE La propuesta de Ingeniería Web basada en UML (UWE) según (Koch y Kraus, 2002) fue propuesta por Nora Koch en el año 2001 y extendida en los documentos posteriores [Hennicker & Koch, 2001; Kraus & Koch, 2002]. UWE es una metodología detallada para el proceso de autoría de aplicaciones Web con una definición exhaustiva del proceso de diseño que debe ser utilizado. Este proceso, 29

42 iterativo e incremental, incluye flujos de trabajo (disciplinas) y puntos de control, y sus fases coinciden con las propuestas en el Proceso Unificado de Desarrollo: comienzo o inicio, elaboración, construcción y transición. Por lo que respecta al proceso de autoría de la aplicación, UWE hace un uso exclusivo de estándares reconocidos como UML y el lenguaje de especificación de restricciones asociado OCL. Para simplificar la captura de las necesidades de las aplicaciones web UWE propone una extensión que se utiliza a lo largo del proceso de autoría. En el marco de UWE es necesario la definición de un perfil UML (extensión) basado en estereotipos, con este perfil se logra la asociación de una semántica distinta a los diagramas del UML puro, con el propósito de acoplar el UML a un dominio específico, en este caso, las aplicaciones Web. Disciplinas de la metodología UWE 1. Análisis de requisitos: se ocupa de recoger las necesidades de clientes y usuarios (requisitos) sobre un sistema dado y traducirlas a especificaciones técnicas del sistema. Se llevarán a cabo las tareas de captura de datos, definición y validación. El objetivo es encontrar los requisitos funcionales de la aplicación Web para representarlos como casos de uso. Centra el trabajo en el estudio de los casos de uso, la generación de los glosarios y el prototipado de la interfaz de usuario. Se obtienen Diagramas de caso de uso para describir los requisitos funcionales, glosarios y prototipos de la interfaz de usuario. La Captura de requisitos es aquella en la que las personas que conforman el equipo de desarrollo de una aplicación extraen toda la información necesaria para cubrir las necesidades del sistema a desarrollarse de diferentes tipos de fuentes de información disponibles. Para la captura de requisitos de un sistema Web la metodología UWE propone entrevistas, cuestionarios, checklist y casos de uso. Para la definición de requisitos UWE propone los escenarios, el glosario y los casos de uso 30

43 Glosario y ontologías: Consiste en la creación de un glosario de términos en el que están las definiciones más críticas e importantes del sistema. Escenarios: Esta técnica se basa en la descripción de todas las características del sistema a desarrollar por medio de una secuencia de pasos. Casos de uso: Esta técnica es la más utilizada en la definición de requisitos sin embargo, puede resultar muy ambiguo por lo que para eliminar esa ambigüedad se utilizan plantillas o diccionarios de datos. Finalmente para la validación de requisitos UWE propone los walkthroughs, prototipos y las auditorias: Reviews o Walk-throughs: Está técnica consiste en modelar la definición de requisitos es decir la correcta y completa lectura y corrección de la documentación. Auditorias: Esta técnica de validación consiste en revisar la documentación mediante el checklist definida a comienzos del proceso. Prototipos: Esta técnica se basa en la obtención de la definición de requisitos prototipos permitiendo a los usuarios tener una idea de la estructura de la interfaz del sistema con el usuario sin tener la total funcionalidad del mismo. 2. Análisis y diseño: UWE distingue entre diseño conceptual, de navegación y de presentación (Koch y Kraus, 2002). Diseño conceptual: se basa en los requisitos reflejados en los casos de uso, para construir un modelo conceptual del dominio de la aplicación. Este modelo se reflejará en diagramas de clases, identificando las distintas vistas de los usuarios, en función de los roles que estos asumen en el sistema y en el diseño de la base de datos. 31

44 Diseño de navegación: sirve para la generación de la documentación de la estructura de la aplicación, se obtiene un modelo de navegación que especifica qué objetos pueden ser visitados a través de la aplicación web y cómo se alcanzan estos objetos a través de la web. Se obtienen diagramas de clases de navegación. Diseño de presentación: consiste en la creación de un modelo de presentación basado en el modelo de navegación y la información adicional recogida en el análisis de requisitos. 3. Implementación: UWE incluye implementación de la arquitectura del sistema, de la estructura del hiperespacio, del modelo conceptual, de los mecanismos adaptativos y las tareas referentes a la integración de todas estas implementaciones. Se obtienen diagramas de componentes y diagramas de despliegue; así como los programas correspondientes. Modelo Conceptual Según (Koch y Kraus, 2002) UWE apunta a construir un modelo conceptual de una aplicación Web, procura no hacer caso en la medida de lo posible de cuestiones relacionadas con la navegación, y de los aspectos de interacción de la aplicación Web. La construcción de este modelo conceptual se debe llevar a cabo de acuerdo con los casos de uso que se definen en la especificación de requerimientos. El modelo conceptual incluye los objetos implicados en las actividades típicas que los usuarios realizarán en la aplicación Web. Se obtienen diagramas de clases, para ello se siguen los pasos dados a continuación: Distinguir las clases. Especificar los atributos más importantes y su funcionamiento. Determinar las asociaciones entre las clases. Agregar las clases e identificar la composición de estas. Definir las jerarquías de herencia Definir las restricciones de los métodos. 32

45 Modelo de Navegación Consta de la construcción de dos modelos: el modelo del espacio de navegación y el modelo de la estructura de navegación. El primero especifica que objetos serán visitados por el navegador a través de la aplicación. El segundo define como se relacionarán. Los elementos básicos de navegación son: 1. Clase de navegación: Está relacionada con las clases del modelo conceptual sobre la cual se va a realizar navegación, a través de los objetos navegacionales. En el caso que se esté utilizando una herramienta case, tal como MagicUwe para la generación semi-automática de los modelos, las clases de navegación tendrán el mismo nombre que las clases dominios. Para su representación se usa el estereotipo UML <<NavigationClass>> 2. Clases de Proceso: Especifica los nodos que van a ser visitados por el usuario a través del browser. Están asociadas a métodos de clases del modelo conceptual. Para su representación se usa el estereotipo UML <<ProcessClass>> 3. Link de navegación: especifica que el objeto navegacional destino es accedido por navegación desde el objeto navegacional fuente. Los elementos adicionales de navegación son: Indice: Un índice permite el acceso directo a instancias de una clase de navegación. Este es modelado por un objeto compuesto el cual contiene un número arbitrario de Items índice. Cada ítem índice es a su vez un objeto el cual tiene un nombre que identifica la instancia y posee un link a una instancia de una clase de navegación. Tour Guía: un tour guía proporciona acceso secuencial a instancias de una clase navegación. Para las clases, las cuales contienen objetos tour guía usamos el estereotipo <<guidedtour>> y su correspondiente icono, las guías tour pueden ser controlados por un usuario o por el sistema. Query: Un Query es modelado por una clase la cual tiene un query string como un atributo. Para las clases query utilizamos el estereotipo <<query>> cualquier clase 33

46 query es la fuente de dos asociaciones directas relacionadas por el constraint (XOR). De esta forma el resultado es un query con varios objetos modelado para llevar primero un índice soportando la selección de una instancia particular de una clase navegación. El resultado del query puede ser utilizado alternativamente como entrada para un tour guía. Menú: un menú es un índice para un set de elementos, tales como tour guía, un query, una instancia de una clase navegación u otro menú. Este es modelado por un objeto compuesto que contiene un número fijo de ítems de menú. Cada ítem menú tiene un nombre constante y posee un link a una instancia de una clase de navegación o a un elemento de acceso. Los estereotipos definidos en UWE se presentan seguidamente. (ver cuadro 2). Cuadro 2 Estereotipos en UWE para la navegación Elemento (s) Clase de navegación y Link de navegación Estereotipo «NavigationClass» Nombre clase Clases de proceso «ProcessClass» Nombre clase Indices Tour guía Query Menú 34

47 Modelo de presentación Describe dónde y cómo los objetos de navegación y accesos primitivos serán presentados al usuario, es decir, una representación esquemática de los objetos visibles al usuario. Para el diseño de los storyboard (diagramas de cajas) empezamos con un primer modelo de navegación de la aplicación Web. Las reglas que guían el proceso son: construir una clase presentación para: (a) cada clase de navegación que aparece en el modelo de estructura de navegación, (b) cada menú e índice que aparece en el modelo de estructura de navegación, (c) cada consulta y vuelta guiada y (d) para apoyo de la navegación; agregar los enlaces a las clases de la presentación que permitan la creación, destrucción y ejecución de operaciones sobre el modelo conceptual, determinar qué elementos de la presentación deben presentarse juntos al usuario (en la ventana); agregar los restricciones OCL, si son necesarias, construir el escenario de storyboarding representados por las sucesiones de vistas de interfaz de usuario. Observe a continuación los símbolos para el modelo de presentación. (ver cuadro 3). Cuadro 3 Estereotipos en UWE para la presentación Elemento (s) Clase de presentación Texto Ancla Botón Imagen Formulario Selección Conjunto de anclas Cuadro de Texto Símbolo 35

48 Ingeniería del Software basada en Componentes Cuando se trabaja con Software libre generalmente se dispone del código fuente para modificar los sistemas y cumplir con los requerimientos solicitados. Por otra parte, está implícito el concepto de reutilización. En este sentido señala Pressman(2002) que los programadores han reutilizado ideas, abstracciones y procesos desde el principio de la era de los computadores (p.473). Luego enfatiza en que hoy en día, los sistemas complejos y de alta calidad basados en computadora se deben construir en períodos de tiempo muy cortos. Esto se mitiga con un enfoque de reutilización más organizado. Por ello surgió la ingeniería del software basada en componentes (ISBC). Según Pressman (2002) la ISBC es un proceso que se centra en el diseño y construcción de sistemas basados en computadora que utilizan componentes de software reutilizables. Señala más adelante este autor que en su base se encuentra la suposición de que en muchos sistemas grandes de software existe una base común suficiente como para justificar los componentes reutilizables para explotar y satisfacer a esa base común. En este contexto, podemos aplicar la ISBC al Sistema Web de solicitud de Servicios para la empresa Core Business Consulting, considerando como componentes al manejador de contenido Joomla y al software OsTicket. Definición de componente Un componente es según Pressman(2002) una parte reemplazable, casi independiente y no trivial de un sistema que cumple una función clara en el contexto de una arquitectura bien definida (p.475). Desarrollo basado en componentes El desarrollo basado en componentes es una actividad de la ISBC que tiene lugar en paralelo a la ingeniería del dominio. Una vez que se ha establecido la 36

49 arquitectura, se debe popularizar mediante los componentes que (1) están disponibles en bibliotecas de reutilización, y/o (2) se han diseñado para satisfacer las necesidades del cliente. Se llevan a cabo tres tareas durante el desarrollo: (a) Cualificación de componentes, (b) adaptación de componentes y (c) composición o integración de componentes. 1. Cualificación de componentes: asegura que un componente candidato llevará a cabo la función necesaria, encajará además adecuadamente en el estilo arquitectónico especificado para el sistema y exhibirá las características de calidad necesarias para la aplicación. 2. Adaptación de componentes: el objetivo de la adaptación (Pressman, 2002) es mitigar los conflictos que puedan presentarse para cumplir con los requerimientos solicitados. Cuando un equipo de software tiene total acceso al diseño interno y al código de un componente, como en nuestro caso de estudio, se utiliza una técnica de adaptación llamada encubrimiento de caja blanca, para ello se examinan los detalles del procesamiento interno del componente y se realizan las modificaciones a nivel de código para eliminar los conflictos ( p. 479). 3. Composición o integración de componentes: esta tarea consiste en ensamblar componentes cualificados, adaptados y diseñados para popularizar la arquitectura establecida para una aplicación. Herramientas para el desarrollo de Sistemas Web Base de datos y Mysql Las bases de datos surgen como alternativa a los sistemas de archivos, intentando eliminar o al menos reducir sus inconvenientes, ya que en un sistema basado en archivo los datos no se comparten a diferencia de un sistema de bases de datos. 37

50 A continuación se exponen algunos requisitos que debe cumplir un sistema de bases de datos: Acceso múltiple: Diversos usuarios pueden acceder a la base de datos, sin que se produzcan conflictos, ni visiones incoherentes. Utilización múltiple: Cada usuario podrá tener una imagen o visión particular de la estructura de la base de datos. Flexibilidad: Se podrán usar distintos métodos de accesos, con tiempos de respuesta razonablemente pequeños. Confidencialidad y seguridad: Se controlará el acceso a los datos (a nivel de campo), impidiéndoselo a los usuarios no autorizados, es decir, habrá usuarios que podrán acceder a unos datos y a otros no. Protección contra fallo: Existirán mecanismos concretos de recuperación en caso de fallo de la computadora. Independencia física: Se puede cambiar el soporte físico de la base de datos (modelo de disco por ejemplo), sin que esto repercuta en la base de datos ni en los programas que la usan. Redundancia controlada. Los datos se almacenan una sola vez en la base de datos. Interfaz de alto nivel. Existe una forma sencilla y cómoda de utilizar la base de datos al menos desde un lenguaje de programación de alto nivel. Interrogación directa (Queri). Existe una utilidad que permite el acceso de los datos de forma conversacional. El manejador Mysql cumple con todas las características antes mencionadas por lo cual se usará para el desarrollo del sistema Web. PHP El lenguaje PHP fue desarrollado en el año 1994 por Rasmus Lerdorf como un CGI escrito en C, que permitía la interpretación de un número limitado de comandos, 38

51 las siglas significaban PHP: Personal Home Page Tools, posteriormente el código fue liberado y se le añadieron mas funcionalidades, tales como: interpretación automática de variables de formulario, sintaxis embebida HTML, entre otras. En 1997 con la versión PHP 3.0 se cambió el nombre del lenguaje a: PHP: Hypertext Pre-processor. (Procesador de Hipertexto PHP). PHP 5 fue liberado en julio de 2004, utiliza el motor Zend: un intérprete que analiza el código de entrada, lo traduce y lo ejecuta; además de proporcionar algunas funciones básicas. Cabe destacar, que en esta versión se mejoró el manejo de Objetos y de la Programación Orientada a Objetos. Joomla Según (Consultrans, 2007) Joomla es: Un gestor de contenidos Web que hace un especial hincapié en aunar un número suficiente de funcionalidades que permitan cubrir las operaciones más habituales de una empresa con mantener la sencillez tanto en la administración como en su empleo por parte de los que introducen los contenidos. Es altamente modular y dispone de muchos complementos que permiten mejorar o complementar sus funcionalidades básicas (la mayor parte a su vez de código libre). Está programado en PHP y su modelo de desarrollo es en comunidad, con una amplia base de desarrolladores e instalaciones. (p. 21). Joomla es un sistema de administración de contenidos de código abierto construido con PHP bajo licencia GPL, utiliza una base de datos en Mysql para publicar en Intranets y Extranet. Las páginas de la interfaz de usuario de un sitio web creado con Joomla tienen como objetivo principal mostrar el contenido de dicho sitio web. El concepto contenido en Joomla tiene un significado muy general y puede resumirse como cualquier tipo de información que es almacenada y gestionada por el sistema. Joomla es capaz de gestionar diversos tipos de contenidos como, por ejemplo, imágenes, información de usuario, información de contacto de la empresa, catálogo 39

52 de productos, lista de enlaces web, etc. El tipo de contenido habitualmente más utilizado es información multimedia que incluye el contenido textual y gráfico que se incluye en una página web (y que habitualmente se denomina contenido web). El contenido web en Joomla recibe el nombre genérico de artículo. Según (Consultrans, 2007) Joomla se encuentra dividido en dos partes principales: 1. Portada o Interfaz de usuario (en inglés, front end). La portada o interfaz de usuario del sitio web es lo que ven los clientes. Existen distintos tipos de clientes o usuarios (ejemplo: visitante, usuario registrado, etc.) y dependiendo del tipo de usuario la portada puede cambiar. 2. nterfaz administrativa (en inglés, back end). La interfaz administrativa de Joomla es donde se realiza tanto la administración de la instalación concreta de Joomla, como la creación de nuevos contenidos por aquellos usuarios que estén autorizados. (p. 146). OsTicket Se utilizó el software OsTicket, con algunas modificaciones, para gestionar las solicitudes de los clientes en cuanto a servicios de consultoría y de desarrollo de soluciones, en las distintas áreas de la empresa. OsTicket es un sistema de código abierto para la generación y resolución de tickets, estos tickets pueden ser incidencias, consultas u otro. Su interfaz de usuario es muy fácil de usar. Se puede gestionar, organizar y archivar todas las solicitudes de apoyo y las respuestas en un solo lugar mientras que se proporciona a los clientes la capacidad de respuesta que se merecen. 40

53 señala que: En se Los sistemas de gestión de tickets son las herramientas ideales para llevar a cabo aquella frase de Convertir las llamadas en s. Podemos usar un sistema de gestión de tickets para, por ejemplo, Gestionar las incidencia típicas de cuando se arranca un proyecto (Webs, software de gestión, etc.) o dar el soporte al cliente ( Hostings, gestorías, soportes, etc. ). El sistema nos permitirá tener el soporte bien controlado, ordenado y clasificado. OsTicket es un sistema de gestión de tickets típico donde los usuarios dan de alta sus tickets con un helptopic y una prioridad. El sistema dispone de un panel de administración donde gestionar los tickets (Asignar, responder, cerrar, cambiar prioridad, etc.). En lo que a requisitos técnicos se refiere está hecho en PHP sobre una base de datos MySql y se distribuye como software libre. Alcance del proyecto En esta investigación se contemplan las fases de comienzo o inicio, elaboración y construcción, según la metodología UWE. La fase de Transición, donde se realizará la implantación y mantenimiento del sitio Web serán responsabilidad de la empresa CBC ya que dependerán de la selección que realicen del servidor para colocarlo. Se obtendrán los productos especificados en la metodología UWE para cada uno de los modelos. 41

54 CAPÍTULO III MARCO METODOLÓGICO Tipo de investigación El trabajo de investigación es del tipo proyecto factible. En este sentido, el Manual de Trabajos de grado de Especialización y Maestría y Tesis Doctorales (UPEL,2006) señala que: El Proyecto Factible consiste en la investigación, elaboración y desarrollo de una propuesta de un modelo operativo viable para solucionar problemas, requerimientos o necesidades de organizaciones o grupos sociales; puede referirse a la formulación de políticas, programas, tecnologías, métodos o procesos(p. 16). Por otra parte, dado que los datos se van a tomar de la realidad en el proceso de solicitud de servicios y atención al cliente, podemos clasificar a la investigación como una investigación de campo. En este sentido, señala el mencionado manual de la UPEL que : Se entiende por Investigación de Campo, el análisis sistemático de problemas en la realidad, con el propósito bien sea de describirlos, interpretarlos, entender su naturaleza y factores constituyentes, explicar sus causas y efectos, o predecir su ocurrencia, haciendo uso de métodos característicos de cualquiera de los paradigmas o enfoques de investigación conocidos o en desarrollo. Los datos de interés son recogidos en forma directa de la realidad (p. 14) También se utilizará la investigación descriptiva para identificar los procesos a automatizar en la empresa CBC. Al respecto señalan Hernández y Fernández (1998) que Los estudios descriptivos buscan especificar las propiedades importantes de personas, grupos, comunidades o cualquier otro fenómeno que sea sometido a análisis (p. 60). 42

55 Finalmente, durante el desarrollo de la propuesta del sistema se complementará el proyecto factible con una investigación documental, ya que se usará la aplicación Osticket que se encuentra implementado bajo software libre y posee documentación digital. En este sentido, señala Arias (2006), que la investigación documental es un proceso basado en la búsqueda, recuperación, análisis, crítica e interpretación de datos secundarios, es decir, los obtenidos y registrados por otros investigadores en fuentes documentales: impresas, audiovisuales o electrónicas (p. 27). Técnicas e Instrumentos de recolección de datos Se utilizará la Técnica de la Entrevista para realizar el levantamiento de la información necesaria para el desarrollo del sistema. Los instrumentos previstos serán guiones de entrevista con preguntas abiertas, dirigidas a la presidenta y a la secretaria de la empresa, quienes se encargarán de la actualización y manejo de la aplicación. Metodología para el desarrollo del sistema Web Se utilizará la metodología UWE (Ingeniería Web basada en UML). Esta metodología sigue un proceso iterativo e incremental, que incluye flujos de trabajo y puntos de control, y sus fases coinciden con las propuestas en el Proceso Unificado de Desarrollo: comienzo, elaboración, construcción y transición. Dentro de cada fase se ejecutan las siguientes disciplinas o flujos de trabajo: 1. Análisis de requisitos: se ocupa de recoger las necesidades de clientes y usuarios (requisitos) sobre un sistema dado y traducirlas a especificaciones técnicas del sistema. Se llevarán a cabo las tareas de captura de datos, definición y validación. El objetivo es encontrar los requisitos funcionales de la aplicación Web para representarlos como casos de uso. También se presentan diagramas de actividad para los casos de uso encontrados. Adicionalmente, en nuestro caso de estudio, se ejecutará, en esta fase, la tarea de cualificación de componentes (Pressman, 2002). 2. Análisis y diseño: se trasladan los requerimientos dentro de la arquitectura de software. En esta disciplina se define la arquitectura del sistema y tiene como 43

56 objetivos trasladar requisitos en especificaciones de implementación. UWE distingue en esta disciplina entre: Diseño conceptual: se basa en los requisitos reflejados en los casos de uso, para construir un modelo conceptual del dominio de la aplicación. Este modelo se reflejará en diagramas de clases, identificando las distintas vistas de los usuarios, en función de los roles que estos asumen en el sistema. Diseño de navegación: sirve para la generación de la documentación de la estructura de la aplicación, se obtiene un modelo de navegación que especifica qué objetos pueden ser visitados a través de la aplicación web y cómo se alcanzan estos objetos a través de la web. Se obtienen diagramas de clases de navegación y el diseño de los menús para la navegación. Diseño de presentación: consiste en la creación de un modelo de presentación basado en el modelo de navegación y la información adicional recogida en el análisis de requisitos. El modelo de presentación describe dónde y cómo los objetos de navegación y accesos primitivos serán presentados al usuario, es decir, una representación esquemática de los objetos visibles al usuario. 3. Implementación: UWE incluye implementación de la arquitectura, de la estructura del hiperespacio, del modelo conceptual, de los mecanismos adaptativos y las tareas referentes a la integración de todas estas implementaciones. Se obtienen diagramas de componentes, diagramas de despliegue y las aplicaciones correspondientes. En nuestro caso de estudio, en esta fase se ejecutarán también las tareas de adaptación y composición de componentes (Pressman, 2002). 4. Pruebas: se verifica que el comportamiento requerido es el correcto y que todo lo solicitado está presente. Tiene como objetivos verificar la integración de los componentes, verificar que todos los requisitos han sido implementados y asegurar la corrección de las fallas antes de la distribución. 44

57 En cada disciplina de la metodología se plantearon las actividades para el desarrollo del sistema web, como se presenta a continuación (ver cuadro 4): Cuadro 4 Actividades y productos por cada Disciplina Disciplina Actividades a realizar Productos resultantes Análisis de Requisitos Determinar los requerimientos del sistema, usando como técnica las entrevistas. Determinar los casos de uso. Determinar los actores del sistema. Determinar las relaciones entre casos de uso y actores del sistema. Realizar los diagramas de caso de uso. Realizar los diagramas de actividad. Realizar la cualificación de componentes Construir prototipos de interfaz de usuario. Diseño de la entrevista y aplicación de la entrevista. Listado de casos de uso Listado de los actores del sistema Listado de relaciones entre casos de uso Diagramas de caso de uso. Diagramas de actividad. Descripción de Cualificación de componentes Prototipos de la interfaz de usuario. Análisis y Diseño Identificar las distintos subsistemas. Definir la arquitectura del sistema Construir los Diagramas de secuencia Construir los diagramas de clase, para el modelo conceptual del sistema. Construir los diagramas de estados Construir el modelo de navegación Construir el modelo de presentación Listado de subsistemas Descripción de la arquitectura del sistema Diagramas de Secuencia Diagramas de clase Diagramas de estado Diagramas de navegación Diagramas de presentación Implementación Pruebas Obtener los diagramas de componentes. Obtener los diagramas de despliegue. Realizar la tarea de adaptación de componentes del sistema Realizar la tarea de composición o integración de componentes Realizar pruebas de caja negra por cada caso de uso Realizar pruebas de integración de los programas 45 Diagramas de componentes Diagramas de despliegue Listado de adaptación e integración de componentes Prototipo del sistema, Sistema Web Pruebas de componentes. Requerimientos de ajuste del prototipo

58 CAPÍTULO IV SISTEMA WEB DE SOLICITUD DE SERVICIOS (CBCSYS) Se desarrolla en este capítulo el sistema Web de Solicitud de Servicios para la empresa Core Business Consulting, aplicando la metodología UWE, considerando las tres primeras fases de dicha metodología: fase de comienzo, fase de elaboración y fase de construcción. Se presentan dentro de cada fase sólo las disciplinas en las que se hace mayor énfasis. Es importante destacar que se utilizó la herramienta CASE de software libre ArgoUML, para la elaboración de los diferentes diagramas mostrados en este capítulo; así como también Microsoft Visio Fase de Comienzo En la fase de comienzo el mayor énfasis se hizo sobre la disciplina de análisis de requisitos, por ello se presentan a continuación los resultados obtenidos reflejados en los casos de uso que guiarán el desarrollo del CBCSYS. Análisis de requisitos Descripción del Problema La empresa Core Business Consulting (CBC) requiere de un sistema que le permita publicar en la Web información sobre la empresa y mantenerla actualizada permanentemente. Se requiere publicar información sobre los servicios que presta, los cursos que dicta, las noticias sobre software libre y otras de impacto sobre los visitantes del portal. También, se ha planteado que los visitantes puedan obtener información de interés, tales como manuales de software libre que puedan descargar en sus computadoras. El acceso a esta información será público, de manera que no se requiere autenticación. 46

59 El sistema debe permitir la comunicación vía Web con los clientes que deseen información adicional a la que se presente en el portal o desee solicitar alguno de los servicios que presta la empresa. Existen cuatro (4) áreas de atención: Inteligencia de Negocios, Sistemas Transaccionales, Plataforma tecnológica, y Capacitación. Existirá un Administrador del sistema que se encargará de actualizar los artículos que se publiquen en el Portal; así como también de gestionar a los empleados de CBC que pueden responder y dar mantenimiento a las solicitudes de atención. Los departamentos que se comunicarán con los clientes serán: Mercadeo y ventas para el área de Capacitación y Consultoría para el resto de las áreas. Se utilizará el manejador de contenido Joomla, ya que permite la actualización rápida de la información del portal por parte del administrador y el software OsTicket, para la administración y gestión de las solicitudes. Ambas aplicaciones funcionan como software libre y serán configuradas y adaptadas a los requerimientos de la empresa. Subsistemas Del análisis realizado podemos destacar que existen dos Subsistemas perfectamente diferenciables. Por un lado tenemos el subsistema Portal que permite realizar las operaciones sobre el CMS Joomla y por la otra parte el subsistema Ticket que permite realizar las operaciones sobre OsTicket a fin de adaptarlo a las necesidades de la empresa CBC. 47

60 Casos de uso Se determinaron los actores que intervienen en el sistema y el rol que cumplen en el mismo, tal como se presenta seguidamente. (Ver cuadro 5). Cuadro 5 Listado de actores Actor Tipo Rol Administrador Principal Persona encargada del mantenimiento y la administración del portal; así como la gestión del personal de CBC y la administración del sistema de Tickets Personal CBC Principal Los empleados de la empresa que harán uso del sistema de Tickets. Visitante Principal Cualquier persona que requiera información de la empresa. Público con Ticket Principal Personas que han solicitado algún servicio Base de datos Joomla Base de datos Osticket (Ticket de atención) a la empresa por medio del sistema. Secundario Representa a la base de datos del Manejador de Contenido Joomla, la cual está predeterminada. Secundario Representa a la base de datos del Help Desk Osticket, la cual está predeterminada. 48

61 Posteriormente, se determinaron los Casos de uso del sistema, tal como se presentan a continuación. (ver cuadro 6). Cuadro 6 Listado de casos de uso Casos de uso Subsistema Portal Validar Administrador Portal Gestión Portal Incluir articulo Editar articulo Eliminar Articulo Mostrar página inicio Mostrar información CBC Mostrar Servicios Mostrar Cursos Mostrar Noticias Descargar Archivos Casos de uso Subsistema Tickets Validar Administrador Ticket Gestión Tickets Registrar Usuario CBC Editar Usuario CBC Eliminar Usuario CBC Solicitar ticket Consultar Ticket Validar Usuario CBC Reasignar Ticket Responder Ticket Escribir nota interna Se establecieron las relaciones entre los casos de uso asociados al portal y los actores, como se presenta a continuación. (Ver cuadro 7). Cuadro 7 Relaciones casos de uso asociados al portal - actores Casos de uso/actores Administrador Personal CBC Validar Administrador Portal X Gestión Portal X Incluir articulo X Editar Articulo X Eliminar articulo X Mostrar página inicio Mostrar Información CBC Mostrar Servicios Mostrar cursos Mostrar Noticias Descargar Archivos Visitante X X X X X X 49

62 Luego, se establecieron las relaciones entre los casos de uso asociados a los Tickets y los actores. (Ver cuadro 8). Cuadro 8 Relaciones casos de uso asociados a los Tickets- actores Casos de uso/actores Administrador Personal Validar Administrador Ticket Validar Usuario CBC Gestión Tickets Registrar Usuario CBC Editar Usuario CBC Eliminar Usuario CBC X X X X X CBC X Visitante Solicitar ticket X X Consultar Ticket X X Reasignar Ticket X X Responder Ticket X X Escribir notas internas X X Público con Ticket 50

63 12). Seguidamente se presenta el diagrama de casos de uso general (Ver gráfico Gráfico 12. Diagrama de caso de uso general CBCSYS 51

64 Para la descripción de los casos de uso, se utilizará el formato: CU_XXXNN, en donde: CU significa caso de uso, XXXX son las siglas del módulo al que pertenece dicho caso de uso y NN representa el número de identificación del caso de uso. Las abreviaturas para los módulos son las siguientes: PORT para los casos de uso asociados al portal, TICK para los casos de uso asociados a los Tickets de atención. Seguidamente se muestran las descripciones de los casos de uso. (Ver cuadros desde el 9 al 30). Cuadro 9 Descripción caso de uso Validar Administrador Portal Nombre de caso de uso: Validar Administrador Portal Id Caso de Uso: CU_PORT01 Actores: Administrador Descripción: Permite certificar que el usuario es el Administrador para el Portal del sistema. Casos de uso Relacionados: Gestión Portal Entradas: Código de usuario Salidas: Curso Típico Acción del Actor Respuesta del Sistema 1.- El actor introduce el código del usuario y el password. 2.- El sistema verifica que el usuario esté registrado y el password sea válido. Curso Alternativo #1: El cliente no está registrado como usuario Administrador del Acción del Actor Pre-condiciones: Post-condiciones: Portal Respuesta del Sistema 1.- El sistema muestra un mensaje indicando que el usuario no está registrado como Administrador del Portal. Usuario Administrador del Portal validado 52

65 Cuadro 10 Descripción caso de uso Gestión Portal Nombre de caso de uso: Id Caso de Uso: Actores: Descripción: Casos de uso Relacionados: Gestión Portal CU_ PORT02 Administrador Permite Habilitar las opciones para el Administrador del Portal del sistema Eliminar articulo, editar articulo, incluir articulo, validar Administrador. Entradas: Código de usuario Salidas: Curso Típico Acción del Actor Respuesta del Sistema 1.- El sistema presenta las opciones disponibles para el Administrador Portal. 2.- El Administrador Portal selecciona la opción que desea ejecutar. Pre-condiciones: Usuario Administrador Portal validado Post-condiciones: Cuadro 11 Descripción caso de uso Incluir Articulo Nombre de caso de uso: Id Caso de Uso: Actores: Descripción: Casos de uso Relacionados: Entradas: Salidas: Acción del Actor 1.- El actor selecciona la categoría donde incluirá el artículo. 2. El actor ingresa los datos del artículo Pre-condiciones: Post-condiciones: Incluir Artículo CU_PORT03 Administrador Permite registrar un nuevo artículo en el sistema. Gestión Portal Curso Típico Respuesta del Sistema 3.- El sistema actualiza la base de datos. Usuario Administrador Portal validado Actualización del artículo en la base de datos 53

66 Cuadro 12 Descripción caso de uso Editar Artículo Nombre de caso de uso: Id Caso de Uso: Actores: Descripción: Casos de uso Relacionados: Entradas: Salidas: Acción del Actor 1.- El actor selecciona el articulo a editar. 2.- El actor introduce los nuevos datos para el artículo. Pre-condiciones: Post-condiciones: Cuadro 13 Descripción caso de uso Eliminar Articulo Editar Artículo CU_PORT04 Administrador Portal Permite realizar cambios en un artículo previamente registrado. Gestión Portal Curso Típico Respuesta del Sistema 4.- El sistema actualiza la base de datos. Usuario Administrador Portal validado Actualización del artículo en la base de datos Nombre de caso de uso: Eliminar Artículo Id Caso de Uso: CU_ PORT05 Actores: Administrador Portal Descripción: Permite la eliminación de un artículo del sistema Casos de uso Relacionados: Gestión Portal Entradas: Salidas: Curso Típico Acción del Actor Respuesta del Sistema 1. El sistema muestra un listado con los artículos registrados. 2.- El actor selecciona el artículo a eliminar 2.- El sistema muestra un mensaje solicitando la confirmación de la eliminación. 3.- El actor realiza la confirmación. 4.- El sistema actualiza la base de datos. Pre-condiciones: Usuario Administrador Portal validado Post-condiciones: Actualización del artículo en la base de datos 54

67 Cuadro 14 Descripción caso de uso Mostrar Página Inicio Nombre de caso de uso: Id Caso de Uso: Actores: Descripción: Casos de uso Relacionados: Entradas: Salidas: Acción del Actor 1.- El Actor introduce en la barra de direcciones la dirección del sistema. Pre-condiciones: Post-condiciones: Cuadro 15 Mostrar Página Inicio CU_ PORT06 Administrador, visitantes, Personal CBC, público con Ticket. Permite que el usuario visualice la página Inicio del sistema. Mostrar información CBC, Mostrar servicios, Descargar archivos, Mostrar cursos, Mostrar Noticias. Curso Típico Respuesta del Sistema Descripción caso de uso Mostrar Información de CBC Nombre de caso de uso: Id Caso de Uso: Actores: Descripción: Casos de uso Relacionados: Entradas: Salidas: Acción del Actor 1.- El Actor selecciona la opción en el menú de la página inicio del sistema. Pre-condiciones: Post-condiciones: 2.- El sistema muestra los artículos solicitados. Mostrar Información de CBC CU_ PORT07 Administrador, Visitante, Personal CBC, Usuarios registrados. Permite que el usuario visualice una descripción, Misión, visión de CBC y valores. Mostrar página inicio Curso Típico Respuesta del Sistema 2.- El sistema muestra los artículos solicitados. 55

68 Cuadro 16 Descripción caso de uso Mostrar Servicios Nombre de caso de uso: Mostrar Servicios Id Caso de Uso: CU_ PORT08 Actores: Administrador, Visitante, Personal CBC, Usuarios registrados. Descripción: Permite que el usuario visualice los servicios que presta la empresa. Casos de uso Relacionados: Mostrar página inicio Entradas: Salidas: Curso Típico Acción del Actor Respuesta del Sistema 1.- El Actor selecciona la opción en el menú de la página inicio del sistema. Pre-condiciones: Post-condiciones: Cuadro 17 Descripción caso de uso Mostrar Cursos Nombre de caso de uso: Id Caso de Uso: Actores: Descripción: Casos de uso Relacionados: Entradas: Salidas: Acción del Actor 1.- El Actor selecciona la opción en el menú de la página inicio del sistema. 2.- El sistema muestra los artículos solicitados. Mostrar Cursos CU_ PORT09 Visitante. Permite que el usuario visualice un listado de los cursos que oferta la empresa y seleccione el curso del cual desee obtener más detalles: contenido, fechas y costo. Mostrar página inicio Curso Típico Respuesta del Sistema 2.- El sistema muestra un listado con los cursos registrados. 3.- El actor selecciona el curso que desea visualizar Pre-condiciones: 4.- El sistema muestra la información del curso solicitado. 56

69 Cuadro 18 Descripción caso de uso Mostrar Noticias Nombre de caso de uso: Id Caso de Uso: Actores: Descripción: Casos de uso Relacionados: Entradas: Salidas: Acción del Actor 1.- El Actor selecciona la opción en el menú de la página inicio del sistema. Pre-condiciones: Mostrar Noticias CU_ PORT10 Administrador Portal, Visitante, Personal CBC, Usuarios registrados. Permite que el usuario visualice las Noticias registradas por el Administrador del Portal de Joomla. Mostrar página inicio Curso Típico Respuesta del Sistema 2.- El sistema muestra los artículos solicitados. Cuadro 19 Descripción caso de uso Descargar Archivos Nombre de caso de uso: Id Caso de Uso: Actores: Descripción: Casos de uso Relacionados: Entradas: Salidas: Acción del Actor 1.- El Actor selecciona la opción del menú de la página inicio. 3.- El actor selecciona el archivo a descargar. Acción del Actor Pre-condiciones: Post-condiciones: Descargar Archivos CU_ PORT11 Visitante. Permite al usuario descargar archivos de interés. Mostrar página inicio Curso Típico Respuesta del Sistema El sistema presenta un listado con los archivos disponibles para descargar. 4.- El sistema abre el archivo para que el actor pueda guardarlo. Curso Alternativo #1: no se puede ejecutar la descarga Respuesta del Sistema 1.- El sistema muestra un mensaje indicando que no se puede ejecutar la descarga. Archivo registrado.

70 Cuadro 20 Descripción caso de uso Validar Administrador Ticket Nombre de caso de uso: Validar Administrador Ticket Id Caso de Uso: CU_ TICK 01 Actores: Administrador Descripción: Permite certificar que el usuario es el Administrador Ticket en el sistema. Casos de uso Relacionados: Gestión Tickets Entradas: Código de usuario Salidas: Curso Típico Acción del Actor Respuesta del Sistema 1.- El actor introduce el código del usuario y el password. 2.- El sistema verifica que el usuario esté registrado y el password sea válido. Curso Alternativo #1: El cliente no está registrado como usuario Administrador de Tickets Acción del Actor Respuesta del Sistema 1.- El sistema muestra un mensaje indicando que el usuario no está registrado como Administrador de Tickets. Pre-condiciones: Post-condiciones: Cuadro 21 Descripción caso de uso Gestión Tickets Usuario Administrador Ticket validado Nombre de caso de uso: Id Caso de Uso: Actores: Descripción: Casos de uso Relacionados: Gestión Tickets CU_TICK02 Administrador Permite Habilitar las opciones para el Administrador de Tickets del sistema Registrar Usuario CBC, Eliminar Usuario CBC, Editar usuario CBC, validar Administrador Tickets. Entradas: Código de usuario Salidas: Opción seleccionada Curso Típico Acción del Actor Respuesta del Sistema 1.- El sistema presenta las opciones disponibles para el Administrador en el subsistema Ticket. 2.- El Administrador selecciona la opción que desea ejecutar. Pre-condiciones: Usuario Administrador validado Post-condiciones: 58

71 Cuadro 22 Descripción caso de uso Registrar Usuario CBC Nombre de caso de uso: Registrar Usuario CBC Id Caso de Uso: CU_ TICK03 Actores: Administrador Descripción: Permite registrar un usuario (Personal de CBC), con sus datos personales y su contraseña. Casos de uso Relacionados: Gestión Tickets Entradas: Código de usuario Salidas: Curso Típico Acción del Actor Respuesta del Sistema 1.- El administrador ingresa los datos del usuario 2.- El sistema verifica que el usuario no está registrado. 3.- El sistema actualiza la base de datos. Curso Alternativo #1: El usuario ya está registrado Acción del Actor Respuesta del Sistema 1.- El sistema muestra un mensaje indicando que el usuario ya está registrado. Pre-condiciones: Usuario Administrador Portal validado Post-condiciones: Actualización del usuario en la base de datos Cuadro 23 Descripción caso de uso Editar usuario CBC Nombre de caso de uso: Editar Usuario Id Caso de Uso: CU_ TICK04 Actores: Administrador Descripción: Permite realizar cambios o agregar información a un usuario(personal CBC) registrado. Casos de uso Relacionados: Gestión Portal Entradas: Salidas: Curso Típico Acción del Actor Respuesta del Sistema 1.- El Actor selecciona el usuario a modificar 2.- El sistema muestra los datos del usuario solicitado. 3.- El actor introduce los nuevos datos para el usuario 4.- El sistema actualiza la base de datos. Curso Alternativo #1: El usuario ya está registrado Acción del Actor Respuesta del Sistema 1.- El sistema muestra un mensaje indicando que el usuario ya está registrado. Pre-condiciones: Usuario Administrador validado Post-condiciones: Actualización del usuario en la base de datos 59

72 Cuadro 24 Descripción caso de uso Eliminar Usuario CBC Nombre de caso de uso: Id Caso de Uso: Actores: Descripción: Casos de uso Relacionados: Entradas: Salidas: Acción del Actor 1.- El Actor selecciona el usuario a eliminar Eliminar Usuario CU_ TICK05 Administrador Permite la eliminación de un usuario del sistema Gestión Ticket Curso Típico Respuesta del Sistema 2.- El sistema muestra un mensaje solicitando la confirmación de la eliminación. 3.- El actor realiza la confirmación 4.- El sistema actualiza la base de datos. Pre-condiciones: Usuario Administrador validado Post-condiciones: Actualización del usuario en la base de datos 60

73 Cuadro 25 Descripción caso de uso Solicitar Ticket Nombre de caso de uso: Id Caso de Uso: Actores: Descripción: Casos de uso Relacionados: Entradas: Salidas: Acción del Actor 1.- El actor introduce su correo electrónico. 3.- El actor selecciona el servicio al que desea asociar el ticket. 4.- El actor escribe el mensaje para la empresa. 7.- El actor introduce el código de seguridad. Solicitar Ticket CU_ TICK06 Usuario registrado, visitante Permite que el cliente(persona natural o jurídica) solicite un ticket de atención Datos del cliente y del servicio o la información solicitada Registro del Ticket generado Curso Típico Respuesta del Sistema El sistema muestra los servicios que presta. 5.- El sistema genera un número de Ticket de atención aleatorio. 6.- El sistema solicita el código de seguridad. 8.- El sistema verifica los datos colocados por el actor. 9.- El sistema envía un correo electrónico con los datos del ticket generado El sistema actualiza la base de datos de los Ticket. Curso Alternativo #1: El cliente se equivoca en los datos colocados Acción del Actor Respuesta del Sistema 1.- El sistema muestra un mensaje de error. 4.- El caso de uso continúa en el paso 1 del flujo típico. Pre-condiciones: N/A Post-condiciones: Ticket registrado en la Base de Datos.

74 Cuadro 26 Descripción caso de uso Validar Usuario CBC Nombre de caso de uso: Id Caso de Uso: Actores: Descripción: Casos de uso Relacionados: Entradas: Salidas: Acción del Actor 1.- El actor introduce el código del usuario y el password. Acción del Actor Pre-condiciones: Post-condiciones: Validar Usuario CBC CU_TICK07 Personal CBC Permite certificar que el usuario está registrado en el sistema. Gestionar Ticket Código de usuario Curso Típico Respuesta del Sistema 2.- El sistema verifica que el usuario esté registrado. Curso Alternativo #1: El cliente no está registrado Usuario validado Respuesta del Sistema 1.- El sistema muestra un mensaje indicando que el usuario no está registrado. Cuadro 27 Descripción caso de uso Consultar Tickets Nombre de caso de uso: Id Caso de Uso: Actores: Descripción: Casos de uso Relacionados: Entradas: Salidas: Acción del Actor 1.- El actor introduce su correo electrónico y el número de su ticket. Pre-condiciones: Post-condiciones: Consultar Tickets CU_ TICK08 Publico con Ticket Permite que el actor consulte el estatus de una solicitud de atención (Tickets). Gestionar Ticket Curso Típico Respuesta del Sistema El sistema muestra el estado del Ticket solicitado.

75 Cuadro 28 Descripción caso de uso Reasignar Ticket Nombre de caso de uso: Reasignar Ticket Id Caso de Uso: CU_TICK09 Actores: Administrador Portal, Personal CBC Descripción: Permite que el actor cambie el área de servicio relacionada a un Ticket, de acuerdo al mensaje enviado por el cliente. Casos de uso Relacionados: Gestionar Ticket Entradas: Código de usuario Salidas: Curso Típico Acción del Actor Respuesta del Sistema 1.- El actor selecciona el código del ticket a reasignar. 2.- El sistema muestra las áreas de atención registradas. 3.- El actor selecciona la nueva área de solicitud de servicio. 4.- El sistema actualiza la base de datos de los Ticket. Pre-condiciones: El usuario es válido. Post-condiciones: Actualización de ticket en la base de datos Cuadro 29 Descripción caso de uso Responder Ticket Nombre de caso de uso: Id Caso de Uso: Actores: Descripción: Casos de uso Relacionados: Entradas: Salidas: Acción del Actor 1.- El actor selecciona el código del ticket al cual va a dar respuesta. 3.- El actor escribe el mensaje de Respuesta al ticket de atención. Pre-condiciones: Post-condiciones: Responder Ticket CU_TICK10 Administrador, Personal CBC Permite que el actor escriba una respuesta a un Ticket de atención. Gestionar Ticket Código de usuario Curso Típico Respuesta del Sistema 2.- El sistema solicita el mensaje a enviar al cliente como respuesta. 4.- El sistema actualiza la base de datos de los Ticket. 5. El sistema envía un correo electrónico con la respuesta registrada. El usuario es válido. Actualización de ticket en la base de datos 63

76 Cuadro 30 Descripción caso de uso Escribir nota interna Nombre de caso de uso: Id Caso de Uso: Actores: Descripción: Casos de uso Relacionados: Entradas: Salidas: Acción del Actor 1.- El actor selecciona el código del ticket al cual le va a escribir una nota interna. 3.- El actor escribe el mensaje de la nota interna. Pre-condiciones: Post-condiciones: Diagramas de actividades Escribir nota interna CU_TICK11 Administrador, Personal CBC Permite que el actor escriba una nota interna relacionada con un ticket de atención. Gestionar Ticket Código de usuario Curso Típico Respuesta del Sistema 2.- El sistema solicita el mensaje para la nota interna. 4.- El sistema actualiza la base de datos de los Ticket. El usuario es válido. Actualización de ticket en la base de datos Se diseñaron los diagramas de actividad de los casos de uso que consideraban flujos alternos, a fin de detallar un poco más el proceso que se llevará a cabo. (Ver gráfico 13). 64

77 Gráfico 13. Diagrama de actividad caso de uso: Solicitar Ticket 65

78 El diagrama de actividad caso de uso: Registrar usuario muestra las acciones a seguir para registrar un usuario, tomando en cuenta que si el usuario ya estaba registrado se emite un mensaje de error y se solicitan nuevamente los datos. (Ver gráfico 14). Gráfico 14. Diagrama de actividad caso de uso: Registrar Usuario 66

79 Cualificación de componentes En la tarea de cualificación de componentes se busca garantizar que los componentes seleccionados cumplan con los requerimientos solicitados. En este sentido, se ha seleccionado el CMS Joomla para el subsistema Portal y el Osticket para la gestión de las solicitudes. A continuación de hace una descripción de las características técnicas de los mismos y se justifica la selección. Características técnicas CMS Joomla 1.7.4: Posee actualización constante y compatibilidad con el servidor Web Apache. Integración con la base de datos Mysql. Soporta la versión de licenciamiento GNU/GPL, lo que garantiza la libre utilización de estas herramientas. Seguridad: Joomla trae incluidos módulos que facilitan la tarea de administración de la seguridad, tales como: registro y validación de login, soporte para conexiones SSL; así como aceptar páginas con contenido SSL, entre otros. Soporte: Joomla brinda un excelente soporte, están disponibles manuales de instalación y configuración iniciales, además de foros en línea y varias comunidades de desarrollo dedicadas a mejorar y revisar vulnerabilidades constantemente. Facilidad de uso: Joomla incluye un editor WYSIWIG, plantillas personalizables, prototipo y asistente para carga masiva de datos. Rendimiento: Joomla proporciona una gestión eficiente del contenido almacenado en memoria cache, además de realizar balanceo de carga, lo cual garantiza a los administradores un excelente rendimiento. Administración: Joomla incluye módulos de administración, como manejo de publicidad, estilos de administración de plantillas y reportes estadísticos, facilitando las tareas del administrador del portal. Interoperatibilidad: Joomla brinda compatibilidad con contenido RSS, protocolo FTP y soporte para codificación UTF-8. 67

80 Flexibilidad: Joomla integra módulos para reutilización de contenidos, manejo de perfiles de usuario y permite la libre instalación de módulos para páginas multilenguaje, facilitando así la tarea de integración y brindando funcionalidad al contenido del portal. De lo anteriormente expuesto, podemos concluir que Joomla proporciona una serie de características apropiadas para cubrir con las necesidades del subsistema Portal. Características técnicas OsTicket: Manejo de correos electrónicos: para la gestión de las solicitudes y consultas se mantiene una comunicación constante con el cliente a través del correo electrónico ( ). Auto respuesta: Una respuesta automática es enviada cuando se genera un nuevo ticket. No se necesita registro de usuario: No es necesario ninguna cuenta de usuario o registrarse para generar los tickets (el y el n de ticket se utilizan para verificar el status), lo cual es muy apropiado para el visitante al portal. Notas internas: Se pueden agregar notas internas para los integrantes del personal de la empresa, de manera que se agilice la comunicación con respecto a la atención de los clientes. Interfaz multiusos de la web Facilidad de uso: se maneja fácilmente, ya que considera el uso de menús y elementos gráficos estandarizados. Historial: Permite Organizar y archivar todas las consultas y solicitudes realizadas por los clientes potenciales y los ya existentes; así como las respuestas dadas por los empleados de la empresa. Es muy ligero y confiable De fuente abierta, modificable si se necesita. Desarrollado en : PHP 5 y Mysql 5. 68

81 De lo anteriormente expuesto, podemos concluir que OsTicket proporciona una serie de características apropiadas para cubrir con las necesidades del subsistema Ticket. Fase de Elaboración En la fase de elaboración se siguieron depurando los requisitos a través de la creación de un prototipo de la interfaz de usuario, tomando en cuenta que algunas de las pantallas ya están predefinidas en Joomla o en OsTicket, luego se hizo énfasis en la disciplina de Análisis y Diseño. Análisis de requisitos Prototipo de la interfaz de usuario En esta fase se presentaron como parte del prototipo las pantallas del Joomla y del OsTicket que ya están preestablecidas y se diseñaron las interfaces para el resto de los casos de uso, presentando un prototipo general. Observe a continuación las interfaces que corresponderán a cada caso de uso. Caso de uso Validar Administrador Portal: se interactúa con la pantalla Principal de Administración del Joomla. (ver gráfico 15). Gráfico 15. Prototipo Administración del Portal Joomla. 69

82 Caso de uso Gestión portal: se interactúa con la pantalla que corresponde al Panel de Control de Joomla. (ver gráfico 16). Gráfico 16. Prototipo Gestión portal. 70

83 Caso de uso Incluir artículo: se interactúa con la pantalla de Incluir artículo de Joomla.. (ver gráfico 17). Gráfico 17. Prototipo interfaz caso de uso Incluir articulo 71

84 Caso de uso Editar artículo: se interactúa con la pantalla de artículos de Joomla (ver gráfico 18), y con la pantalla de edición de articulos. (ver gráfico 19). Gráfico 18. Prototipo interfaz caso de uso Editar artículo- pantalla artículos. 72

85 Gráfico 19. Prototipo interfaz caso de uso Editar artículo- pantalla Editar artículos. 73

86 Caso de uso Eliminar Articulo: se interactúa con la pantalla de artículos de Joomla (Ver gráfico 18) para seleccionar el articulo a eliminar y luego presionar el botón Papelera. Casos de uso Mostrar página inicio: se interactúa con la pantalla de inicio. (ver gráfico 20). Gráfico 20. Prototipo interfaz caso de uso Mostrar Página inicio 74

87 Caso de uso Mostrar Información de CBC: se interactúa con la pantalla Nosotros. (ver gráfico 21). Gráfico 21. Prototipo interfaz caso de uso Mostrar Información CBC Caso de uso Mostrar Servicios: se interactúa con la pantalla de Mostrar Servicios. (ver gráfico 22). Gráfico 22. Prototipo interfaz caso de uso Mostrar Servicios 75

88 Caso de uso Mostrar Cursos: se interactúa con la pantalla de Mostrar Cursos (ver gráfico 23). Gráfico 23. Gráfico 23. Prototipo interfaz caso de uso Mostrar Cursos Caso de uso Mostrar Noticias: se interactúa con la pantalla de Mostrar Noticias. (ver gráfico 24). Gráfico 24. Prototipo interfaz caso de uso Mostrar Noticias 76

89 Caso de uso Descargar Archivos: se interactúa con la pantalla de Descargar Archivos. (ver gráfico 25). Gráfico 25. Prototipo interfaz caso de uso Descargar Archivos Caso de uso Validar Administrador Ticket: se interactúa con la pantalla Principal de Administración del Osticket. ( ver gráfico 26). 77

90 Gráfico 26. Prototipo interfaz caso de uso Validar Administrador OsTicket. Caso de uso Gestión OsTicket: se interactúa con la pantalla Panel OsTicket. (ver gráfico 27). Gráfico 27. Prototipo interfaz caso de uso Gestión Ticket 78

91 Caso de uso Registrar Usuario CBC: se interactúa con la pantalla de Registrar usuario de Osticket. (ver gráfico 28). Gráfico 28. Prototipo interfaz caso de uso Registrar usuario CBC 79

92 Caso de uso Editar Usuario CBC: se interactúa con la pantalla que presenta la lista de Usuarios registrados por el administrador (ver gráfico 29) y luego con la pantalla de Editar usuario de Osticket. (ver gráfico 30). Gráfico 29. Prototipo interfaz caso de uso Editar usuario CBC- listado de usuarios 80

93 Gráfico 30. Prototipo interfaz caso de uso Editar usuario CBC Caso de uso Eliminar Usuario: se interactúa con la pantalla de Usuarios registrados. (ver gráfico 29). 81

94 Caso de uso Solicitar ticket: se interactúa con la pantalla Solicitar Ticket de Osticket. (ver gráfico 31). Gráfico 31. Prototipo interfaz caso de uso Solicitar Ticket Caso de uso Validar Usuario CBC: se interactúa con la pantalla Validar Usuario de Osticket. (ver gráfico 26), verificando que el usuario haya sido registrado previamente por el administrador. Caso de uso Consultar ticket: se interactúa con la pantalla Consultar Ticket de Osticket. (ver gráfico 32). Gráfico 32. Prototipo interfaz caso de uso Consultar Ticket 82

95 Caso de uso Reasignar ticket: se interactúa con la pantalla Reasignar Ticket de Osticket. (ver gráfico 33). Gráfico 33. Prototipo interfaz caso de uso Reasignar Ticket Caso de uso Responder ticket: se interactúa con la pantalla Responder Ticket de Osticket. (ver gráfico 34). Gráfico 34. Prototipo interfaz caso de uso Responder Ticket 83

96 Caso de uso Escribir notas internas: se interactúa con la pantalla Escribir notas internas de Osticket. (ver gráfico 35). Gráfico 35. Prototipo interfaz caso de uso Escribir notas internas Análisis y Diseño En la disciplina de análisis y diseño se definió la arquitectura del sistema, luego se procedió a plantear el modelo conceptual, tomando en cuenta que para una descripción más detallada se utiliza UML puro. Para el modelo conceptual se definieron las clases de análisis, los diagramas de secuencia, diagramas de clases, diagramas de estado y finalmente el diccionario de clases. Cabe destacar que las interacciones fueron captadas sólo mediante los diagramas de secuencia, ya que los diagramas de colaboración representan una notación equivalente. Señala al respecto (Pressman, 2008) que : el otro diagrama se conoce como diagrama de colaboración, y es equivalente al diagrama de secuencia; de hecho, son tan similares que las herramientas CASE pueden normalmente crear un diagrama, a partir de una instancia o de la otra. (p. 396). 84

97 Arquitectura del sistema El sistema se diseñó en base a una arquitectura cliente-servidor. Esta consiste en peticiones que realiza un cliente a un servidor que le da respuesta; las transacciones se dividen en procesos independientes que cooperan entre sí para intercambiar información, servicios o recursos. Para el CBCSys se requiere un servidor Web, un servidor de aplicaciones, un servidor de base de datos y un servidor de correo. En cuanto a la división del sistema se establecieron dos subsistemas: a) CBCsite: presenta información de CBC con el Manejador de Contenido Joomla, el cual permite de una manera rápida y sencilla realizar la actualización de los contenidos presentados a los clientes, tales como: servicios, cursos, noticias, entre otros y b) CBCticket: permite gestionar las solicitudes de atención de los clientes hacia las distintas áreas de atención de la empresa; para ello se utilizó una aplicación en Software libre denominada Osticket. Modelo conceptual clases de análisis Para definir las clases de análisis se utilizó UML puro, de manera que se capturaran los requisitos con mayor precisión. Algunas de estas clases serán detalladas posteriormente de acuerdo a los modelos propuestos por UWE. Por cada caso de uso, se determinaron las clases de análisis asociadas a los casos de uso clasificándolas según los estereotipos propuestos por UML: clases borde, clases entidad y clases control. A continuación se identifican las clases Bordes, asociadas a los actores. En el Cbcsys, cada uno de los actores Administrador Portal, Personal CBC, Visitante, Público con Ticket, Base de datos Joomla, Base de datos Osticket, requiere de su propio objeto de borde, de manera que: Administrador Portal, Personal CBC, Visitante y Público con Ticket requerirán de pantallas de presentación, mientras que la Base de datos Joomla y la Base de datos Osticket requiere de sus propias clases bordes para intercambiar información con el sistema. (Ver gráfico 36). 85

98 Gráfico 36. Clases bordes relacionadas con los actores Seguidamente se identifican las clases bordes asociadas a cada caso de uso. Caso de uso Validar Administrador Portal: se interactúa con los actores Administrador y Base de datos Joomla, a través de las clases bordes InterfaceAdministrador e InterfaceBaseDatosJoomla. Se utiliza la pantalla Principal de Administración del Joomla, cuya clase denominaremos PantallaAdminJoomla. ( ver gráfico 37). Gráfico 37. Clases bordes caso de uso Validar Administrador Portal 86

99 Caso de uso Gestión portal: se interactúa con la pantallapaneljoomla y con las InterfaceAdministrador e InterfaceBaseDatosJoomla. (ver gráfico 38). Gráfico 38. Clases bordes caso de uso Gestión portal Caso de uso Incluir artículo: se interactúa con los actores Administrador, Base de Datos Joomla, a través de las clases borde InterfaceAdministrador e InterfaceBaseDatosJoomla, respectivamente. Se utiliza la pantalla de Incluir artículo de Joomla, cuyo clase borde denominaremos PantallaIncluirArticulo. (ver gráfico 39). Gráfico 39. Clases bordes caso de uso Incluir articulo 87

100 Caso de uso Editar artículo: se interactúa con los actores Administrador, Base de Datos Joomla, a través de las clases bordes InterfaceAdministrador e InterfaceBaseDatosJoomla, respectivamente. Se utiliza la pantalla de artículos de Joomla, cuyo clase borde denominaremos PantallaArticulos para presentar un listado de los artículos registrados, luego el administrador debe seleccionar el que va a modificar y se le presentará otra pantalla que denominaremos PantallaEditarArticulos. (ver gráfico 40). Gráfico 40. Clases bordes caso de uso Editar artículo Caso de uso Eliminar Articulo: se interactúa con los actores Administrador, Base de Datos Joomla, a través de las clases bordes InterfaceAdministrador e InterfaceBaseDatosJoomla, respectivamente. Se utiliza la pantalla de artículos de Joomla, cuyo clase borde denominaremos PantallaArticulos. (ver gráfico 41). 88

101 Gráfico 41. Clases bordes caso de uso Eliminar artículo Caso de uso Mostrar página inicio: se interactúa con los actores, Visitante y Base de Datos Joomla, a través de las clases bordes InterfaceVisitante e InterfaceBaseDatosJoomla, respectivamente. Se utiliza la pantalla de inicio, cuya clase borde denominaremos PantallaInicio. (ver gráfico 42). Gráfico 42. Clases bordes caso de uso Mostrar Página inicio 89

102 Caso de uso Mostrar Información de CBC: se interactúa con los actores Visitante y Base de Datos Joomla, a través de las clases bordes InterfaceVisitante e InterfaceBaseDatosJoomla, respectivamente. Se utiliza la pantalla de Mostrar Información CBC, cuya clase borde denominaremos PantallaNosotros. (ver gráfico 43). Gráfico 43. Clases bordes caso de uso Mostrar Información CBC Caso de uso Mostrar Servicios: se interactúa con los actores Visitante y Base de Datos Joomla, a través de las clases bordes InterfaceVisitante e InterfaceBaseDatosJoomla, respectivamente. Se utiliza la pantalla de Mostrar Servicios, cuya clase borde denominaremos PantallaServicios. (ver gráfico 44). Gráfico 44. Clases de borde caso de uso Mostrar Servicios 90

103 Caso de uso Mostrar Cursos: se interactúa con los actores Visitante y Base de Datos Joomla, a través de las clases bordes InterfaceVisitante e InterfaceBaseDatosJoomla, respectivamente. Se utiliza la pantalla de Mostrar Cursos cuya clase borde denominaremos PantallaCursos. (ver gráfico 45). Gráfico 45. Clases bordes caso de uso Mostrar Cursos Caso de uso Mostrar Noticias : se interactúa con los actores Visitante y Base de Datos Joomla, a través de las clases bordes InterfaceVisitante e InterfaceBaseDatosJoomla, respectivamente. Se utiliza la pantalla de Mostrar Noticias, cuya clase borde denominaremos PantallaNoticias. (ver gráfico 46). Gráfico 46. Clases bordes caso de uso Mostrar Noticias 91

104 Caso de uso Descargar Archivos: se interactúa con los actores Visitante y Base de Datos Joomla, a través de las clases bordes InterfaceVisitante e InterfaceBaseDatosJoomla, respectivamente. Se utiliza la pantalla de Descargar Archivos, cuya clase borde denominaremos PantallaDescargas. (ver gráfico 47). Gráfico 47. Clases bordes caso de uso Descargar Archivos Caso de uso Validar Administrador Ticket: se interactúa con los actores Administrador y Base de datos OsTicket, a través de las clases bordes InterfaceAdministrador e InterfaceBaseDatosOsTicket. Se utiliza la pantalla Principal de Administración del Osticket, cuya clase denominaremos PantallaAdminOsTicket. ( ver gráfico 48). Gráfico 48. Clases bordes caso de uso Validar Administrador OsTicket 92

105 Caso de uso Gestión OsTicket: se interactúa con la pantallapanelosticket y con las InterfaceAdministrador e InterfaceBaseDatosOsTicket. (ver gráfico 49). Gráfico 49. Clases bordes caso de uso Gestión Ticket Caso de uso Registrar Usuario CBC: se interactúa con los actores Administrador, Base de Datos Ticket, a través de las clases bordes InterfaceAdministrador e InterfaceBaseDatosOsticket, respectivamente. Se utiliza la pantalla de Registrar usuario de Osticket, cuyo clase borde denominaremos PantallaRegistrarUsuario. (ver gráfico 50). 93

106 Gráfico 50. Clases bordes caso de uso Registrar usuario CBC Caso de uso Editar Usuario CBC: se interactúa con los actores Administrador, Base de Datos Joomla, a través de las clases bordes InterfaceAdminTickets e InterfaceBaseDatosOsTicket, respectivamente. Se presenta una pantalla con el listado de los usuarios, cuyo clase borde denominaremos PantallaUsuarios y la pantalla de Editar usuario de Osticket, cuyo clase borde denominaremos PantallaEditarUsuario. (ver gráfico 51). Gráfico 51. Clases bordes caso de uso Editar usuario CBC 94

107 Caso de uso Eliminar Usuario: se interactúa con los actores Administrador Base de Datos Tickets, a través de las clases bordes InterfaceAdministrador e InterfaceBaseDatosOsticket, respectivamente. Se utiliza la pantallausuarios. (ver gráfico 52). Gráfico 52. Clases bordes caso de uso Eliminar usuario CBC Caso de uso Solicitar ticket: se interactúa con los actores Visitante, Base de Datos OsTicket, a través de las clases bordes InterfaceVisitante e InterfaceBaseDatosOsticket, respectivamente. Se utiliza la pantalla Solicitar Ticket de Osticket, cuyo clase borde denominaremos PantallaSolicitarTicket. (ver gráfico 53). Gráfico 53. Clases bordes caso de uso Solicitar Ticket 95

108 Caso de uso Validar Usuario CBC: se interactúa con los actores Personal CBC y Base de Datos OsTicket, a través de las clases bordes InterfacePersonalCBC e InterfaceBaseDatosOsticket, respectivamente. Se utiliza la pantalla Validar Usuario de Osticket, cuyo clase borde denominaremos PantallaValidarUsuario. (ver gráfico 54). Gráfico 54. Clases bordes caso de uso Validar usuario Caso de uso Consultar ticket: se interactúa con los actores Público con Ticket, Base de Datos OsTicket, a través de las clases bordes InterfacePublicoConTicket, e InterfaceBaseDatosOsticket, respectivamente. Se utiliza la pantalla Consultar Ticket de Osticket, cuyo clase borde denominaremos PantallaConsultarTicket. (ver gráfico 55). Gráfico 55. Clases bordes caso de uso Consultar Ticket 96

109 Caso de uso Reasignar ticket: se interactúa con los actores Personal CBC y Base de Datos OsTicket, a través de las clases bordes InterfacePersonalCBC e InterfaceBaseDatosOsticket, respectivamente. Se utiliza la pantalla Reasignar Ticket de Osticket, cuyo clase borde denominaremos PantallaReasignarTicket. (ver gráfico 56). Gráfico 56. Clases bordes caso de uso Reasignar Ticket Caso de uso Responder ticket: se interactúa con los actores Personal CBC y Base de Datos OsTicket, a través de las clases bordes InterfacePersonalCBC e InterfaceBaseDatosOsticket, respectivamente. Se utiliza la pantalla Responder Ticket de Osticket, cuyo clase borde denominaremos PantallaResponderTicket. (ver gráfico 57). Gráfico 57. Clases bordes caso de uso Responder Ticket 97

110 Caso de uso Escribir notas internas: se interactúa con los actores Personal CBC y Base de Datos OsTicket, a través de las clases bordes InterfacePersonalCBC e InterfaceBaseDatosOsticket, respectivamente. Se utiliza la pantalla Escribir notas internas de Osticket, cuyo clase borde denominaremos PantallaNotasInternas. (ver gráfico 58). Gráfico 58. Clases bordes caso de uso Escribir notas internas A continuación se presenta una tabla resumen de las clases bordes identificadas, para cada subsistema. Subsistema Portal (ver cuadro 31). 98

111 Cuadro 31 Clases bordes subsistema Portal Clases Bordes subsistema Portal InterfaceAdministrador InterfaceBasedeDatosJoomla PantallaAdminJoomla PantallaIncluirArticulo PantallaArticulos PantallaEditarArticulo PantallaPanelJoomla PantallaInicio PantallaNosotros PantallaServicios PantallaDescargas InterfaceVisitante PantallaCursos PantallaNoticias Descripción Esta clase permite manejar la interacción con el usuario Administrador. Esta clase permite manejar la interacción con la base de datos de Joomla. Pantalla de solicitud de identificación del Administrador Portal de Joomla. Pantalla que le permite al Administrador de Joomla incluir un Articulo. Pantalla que presenta los artículos registrados en la base de datos de Joomla. Pantalla que permite al Administrador de Joomla editar un Articulo. Pantalla que le permite al Administrador tener acceso a las opciones de mantenimiento de los artículos Joomla. Pantalla que permite tener acceso al Front-End del Joomla, donde se muestran los artículos registrados. Pantalla que permite consultar información general de CBC. Pantalla que permite mostrar los servicios que presta la empresa CBC. Pantalla que permite seleccionar los archivos que se desean descargar desde el sitio Web. Esta clase permite manejar la interacción con el actor Visitante. Pantalla que permite mostrar los cursos que se dictan en CBC. Pantalla que permite mostrar las noticias 99

112 Subsistema Ticket (Ver cuadro 32). Cuadro 32 Clases bordes subsistema Ticket Clases Bordes subsistema Ticket InterfaceAdministrador InterfaceVisitante InterfaceBaseDatosOsticket PantallaSolicitarTicket PantallaConsultarTicket InterfacePublicoConTicket InterfacePersonalCBC PantallaReasignarTicket PantallaResponderTicket PantallaNotasInternas PantallaValidarUsuario Descripción Esta clase permite manejar la interacción con el usuario Administrador. Esta clase permite manejar la interacción con el actor Visitante. Esta clase permite manejar la interacción con la base de datos del OsTicket. Pantalla que permite registrar los datos de una solicitud de ticket de atención. Pantalla que permite consultar los datos de un ticket de atención registrado anteriormente. Esta clase permite manejar la interacción con el actor público con Ticket. Esta clase permite manejar la interacción con el actor personal CBC, que está asociado con el personal de la empresa. Pantalla que permite reasignar un ticket a otra área de atención de la empresa. Pantalla que permite responder un ticket de atención registrado. Pantalla que permite crear notas internas en torno a los ticket de atención. Pantalla que permite solicitar los datos del personal de CBC para la gestión de los ticket de atención. PantallaUsuarios Pantalla que permite mostrar los usuarios(personal CBC) que están registrados. PantallaRegistrarUsuario Pantalla que permite registrar un usuario(personal CBC) en Osticket. PantallaEditarUsuario Pantalla que permite editar un usuario(personal CBC) en Osticket. El segundo grupo de clases a identificar, lo constituyen las clases entidad, las cuales se identifican a partir del dominio del problema y permiten modelar la información que el sistema debe manejar a corto y a largo plazo. 100

113 Para CBCsys nos centraremos en algunas clases del Joomla (subsistema Portal) que se utilizan para la comunicación con los actores, como son: Artìculos, Categorias y Usuarios, que denominaremos UsuariosP. Para el subsistema Ticket se utilizará la clase entidad Ticket y la clase Usuarios que denominaremos UsuariosT. (ver cuadro 29). Vale destacar que el conjunto de clases del que hacen uso tanto el manejador Joomla como el OsTicket es mucho más amplio.(ver cuadro 33). Cuadro 33 Clases Entidad Caso de uso Validar Administrador Portal Incluir articulo Editar articulo Eliminar Articulo Mostrar página inicio Mostrar Información de CBC Mostrar Servicios Mostrar Cursos Mostrar Noticias Descargar Archivos Validar Administrador Ticket Registrar Usuario CBC Editar Usuario CBC Eliminar Usuario CBC Solicitar ticket Consultar Ticket Reasignar Ticket Responder Ticket Escribir notas internas Validar Usuario CBC Clases Entidad UsuarioP Articulo Articulo Articulo Articulo,Categoria Articulo, Categoria Articulo, Categoria Articulo, Categoria Articulo, Categoria Articulo UsuarioT UsuarioT UsuarioT UsuarioT Ticket Ticket Ticket Ticket Ticket UsuarioT 101

114 cuadro 34). El tercer grupo de clases a identificar, lo constituyen las clases Control. (ver Cuadro 34 Clases Control Casos de uso Validar Administrador Portal Incluir articulo Editar articulo Eliminar Articulo Validar Administrador Ticket Registrar Usuario Editar Usuario Eliminar Usuario Mostrar página inicio Mostrar Información de CBC Mostrar Servicios Descargar Archivos Solicitar ticket Consultar Ticket Reasignar Ticket Responder Ticket Escribir notas internas Validar Usuario Clases Control ManejadorUsuarioJoomla ManejadorArticulo ManejadorArticulo ManejadorArticulo ManejadorUsuarioT ManejadorUsuarioT ManejadorUsuarioT ManejadorUsuarioT ManejadorArticulo ManejadorArticulo ManejadorArticulo ManejadorArticulo ManejadorTicket ManejadorTicket ManejadorTicket ManejadorTicket ManejadorTicket ManejadorUsuarioT 102

115 Modelo Conceptual diagramas de secuencia Como parte del modelo conceptual se realizaron los diagramas de secuencia por cada caso de uso, con el fin de describir la interacción entre las clases para lograr la funcionalidad del sistema 1. Caso de uso Validar Administrador Portal: el diagrama de secuencia para validar Administrador Portal muestra que el ManejadorUsuarioJoomla solicita a la InterfaceAdministrador que Despliegue la pantalla de administración de Joomla, mediante DesplegarPantallaAdminJoomla, luego el administrador ingresa sus datos y se realiza la verificación en la base de datos de Joomla, para enviar el mensaje correspondiente al administrador, por medio de su clase interface. (ver gráfico 59). Gráfico 59. Diagrama de secuencia Validar Administrador Portal 1 Se hace abstracción del procesamiento real que hacen Joomla y OsTicket. 103

116 Caso de uso Gestión Portal: el diagrama de secuencia para la Gestión Portal muestra que el ManejadorUsuarioJoomla solicita a la InterfaceAdministrador que Despliegue la pantalla de Control de opciones de administración de Joomla, mediante DesplegarPantallaPanelJoomla, luego el administrador selecciona la opción deseada. (ver gráfico 60). Gráfico 60. Diagrama de secuencia Gestión Portal 104

117 Caso de uso Incluir artículo: se muestra en el diagrama de secuencia que para incluir un artículo es necesario crear un objeto de la clase Artículo y uno de la clase Categoría para enviarlos posteriormente a la base de datos. (ver gráfico 61) Gráfico 61. Diagrama de secuencia Incluir articulo 105

118 Caso de uso Editar artículo: se muestra en el diagrama de secuencia que para editar un artículo es necesario crear un objeto de la clase Articulo y uno de la clase Categoría para enviarlos posteriormente a la base de datos y actualizar la información correspondiente. (ver gráfico 62) Gráfico 62. Diagrama de secuencia Editar artículo. 106

119 Caso de uso eliminar Artículo: se muestra en el diagrama de secuencia que para Eliminar un artículo es necesario crear un objeto de la clase Artículo para enviar la solicitud de eliminación a la base de datos. (ver gráfico 63). Gráfico 63. Diagrama de secuencia Eliminar artículo. 107

120 Caso de uso mostrar página inicio: se observa en el diagrama de secuencia que para mostrar la página inicio es necesario crear un objeto de la clase Categoria y otro de la clase Articulo para que reciban la información registrada en la base de datos de Joomla con respecto a la página de inicio, mediante el método ObtenerArtículos, que recibe como parámetro el tipo de artículos que se buscan; en este caso los asociados al Inicio. Posteriormente se procede a DesplegarPantallaInicio. (ver gráfico 64). Gráfico 64. Diagrama de secuencia Mostrar página inicio. 108

121 Caso de uso mostrar Información de CBC: se observa en el diagrama de secuencia que para mostrar la información de CBC es necesario crear un objeto de la clase Categoria y otro de la clase Articulo para que reciban la información registrada en la base de datos de Joomla con respecto a la página Nosotros, mediante el método ObtenerArtículos, que recibe como parámetro el tipo de artículos que se buscan; en este caso los asociados a Nosotros. Posteriormente se procede a DesplegarPantallaNosotros. (ver gráfico 65). Gráfico 65. Diagrama de secuencia Mostrar Información de CBC. 109

122 Caso de uso mostrar Servicios: se observa en el diagrama de secuencia que para mostrar los servicios es necesario crear un objeto de la clase Categoria y otro de la clase Articulo para que reciban la información registrada en la base de datos de Joomla con respecto a la página Servicios, mediante el método ObtenerArtículos, que recibe como parámetro el tipo de artículos que se buscan; en este caso los asociados a Servicios. Posteriormente se procede a DesplegarPantallaServicios. (ver gráfico 66). Gráfico 66. Diagrama de secuencia Mostrar Servicios. 110

123 Caso de uso mostrar Cursos: se observa en el diagrama de secuencia que para mostrar los servicios es necesario crear un objeto de la clase Categoria y otro de la clase Articulo para que reciban la información registrada en la base de datos de Joomla con respecto a la página Cursos, mediante el método ObtenerArtículos, que recibe como parámetro el tipo de artículos que se buscan; en este caso los asociados a Cursos. Posteriormente se procede a DesplegarPantallaCursos para que el visitante seleccione un curso y se muestre la información que corresponda mediante la InterfaceVisitante. (ver gráfico 67). Gráfico 67. Diagrama de secuencia Mostrar cursos 111

124 Caso de uso mostrar Noticias: se observa en el diagrama de secuencia que para mostrar las noticias es necesario crear un objeto de la clase Categoria y otro de la clase Articulo para que reciban la información registrada en la base de datos de Joomla con respecto a la página Noticias, mediante el método ObtenerArtículos, que recibe como parámetro el tipo de artículos que se buscan; en este caso los asociados a Noticias. Posteriormente se procede a DesplegarPantallaNoticias. (ver gráfico 68). Gráfico 68. Diagrama de secuencia Mostrar Noticias. 112

125 Caso de uso descargar Archivos: se observa en el diagrama de secuencia que para descargar archivos es necesario crear un objeto de la clase Categoria y otro de la clase Articulo para que reciban la información registrada en la base de datos de Joomla con respecto a la página Cursos, mediante el método ObtenerArtículos, que recibe como parámetro el tipo de artículos que se buscan; en este caso los asociados a Descargas. Posteriormente se procede a DesplegarPantallaDescargas para que el visitante seleccione un archivo y se muestre la información que corresponda mediante la InterfaceVisitante. (ver gráfico 69). Gráfico 69. Diagrama de secuencia Descargar Archivos. 113

126 Caso de uso Validar Administrador Ticket: el diagrama de secuencia para validar Administrador Ticket muestra que el ManejadorUsuarioTicket solicita a la InterfaceAdministrador que Despliegue la pantalla de administración de Ticket, mediante DesplegarPantallaAdminTicket, luego el administrador ingresa sus datos y se realiza la verificación en la base de datos de OsTicket. (ver gráfico 70). Gráfico 70. Diagrama de secuencia Validar Administrador Ticket Caso de uso Gestión Ticket: el diagrama de secuencia para la Gestión Ticket muestra que el ManejadorUsuarioTicket solicita a la InterfaceAdministrador que Despliegue la pantalla de administración de OsTicket, mediante DesplegarPantallaAdminTicket, luego el administrador selecciona la opción a ejecutar del OsTicket. (ver gráfico 71). Gráfico 71. Diagrama de secuencia Gestión Ticket 114

127 Caso de uso Registrar Usuario CBC: se muestra en el diagrama de secuencia que para incluir un Usuario es necesario crear un objeto de la clase UsuarioT para enviarlo a la base de datos de OsTicket. (ver gráfico 72). Gráfico 72. Diagrama de secuencia Registrar Usuario CBC 115

128 Caso de uso Editar Usuario CBC: se muestra en el diagrama de secuencia que para Editar un usuario es necesario mostrar un listado de los usuarios registrados (Personal de CBC) para que el administrador elija el usuario a modificar, seguidamente se crea un objeto de la clase UsuarioT, que registre los cambios en los datos del usuario para enviarlo posteriormente a la base de datos de OsTicket. (ver gráfico 73). Gráfico 73. Diagrama de secuencia Editar Usuario CBC 116

129 Caso de uso Eliminar Usuario CBC: se muestra en el diagrama de secuencia que para Eliminar un usuario es necesario mostrar un listado de los usuarios registrados (Personal de CBC) para que el administrador elija el usuario a Eliminar, seguidamente se crea un objeto de la clase UsuarioT, por medio del cual se solicite la eliminación en la base de datos de OsTicket. (ver gráfico 74). Gráfico 74. Diagrama de secuencia Eliminar Usuario CBC 117

130 Caso de uso Solicitar ticket: se muestra en el diagrama de secuencia que para Solicitar un Ticket el visitante debe seleccionar la opción contacto del subsistema Portal, luego es necesario crear un objeto de la clase Ticket para enviarlo a la base de datos de OsTicket. (ver gráfico 75). Gráfico 75. Diagrama de secuencia Solicitar Ticket 118

131 Caso de uso Consultar Ticket: se muestra en el diagrama de secuencia que para Consultar un Ticket el visitante debe seleccionar la opción contacto del subsistema Portal, luego es necesario crear un objeto de la clase Ticket para poder solicitar la consulta a la base de datos de OsTicket. (ver gráfico 76). Gráfico 76. Diagrama de secuencia Consultar Ticket 119

132 Caso de uso Validar Usuario CBC: el diagrama de secuencia para validar usuario CBC muestra que el ManejadorUsuarioTicket solicita a la InterfacePersonalCBC que Despliegue la pantalla de administración de Ticket, mediante DesplegarPantallaAdminTicket, luego el usuario ingresa sus datos y se realiza la verificación en la base de datos de OsTicket. (ver gráfico 77). Gráfico 77. Diagrama de secuencia Validar Usuario CBC 120

133 Caso de uso Reasignar Ticket: se muestra en el diagrama de secuencia que para Reasignar un Ticket es necesario mostrar un listado de los Ticket registrados para que el Usuario(Personal CBC) elija el ticket a reasignar, seguidamente se crea un objeto de la clase Ticket, que registre los cambios en los datos del Ticket para enviarlo posteriormente a la base de datos de OsTicket. (ver gráfico 78). Gráfico 78. Diagrama de secuencia Reasignar Ticket 121

134 Caso de uso Responder Ticket: se muestra en el diagrama de secuencia que para Responder un Ticket es necesario mostrar un listado de los Ticket registrados para que el Usuario(Personal CBC) elija el ticket a responder, seguidamente se crea un objeto de la clase Ticket, que registre los cambios en los datos del Ticket para enviarlo posteriormente a la base de datos de OsTicket. (ver gráfico 79). Gráfico 79. Diagrama de secuencia Responder Ticket 122

135 Caso de uso Escribir notas internas: se muestra en el diagrama de secuencia que para Escribir notas internas es necesario mostrar un listado de los Ticket registrados para que el Usuario(Personal CBC) elija el ticket al que quiere asociar la nota interna, seguidamente se crea un objeto de la clase Ticket, que registre la nota interna para el historial del Ticket, posteriormente se envían estos cambios a la base de datos de OsTicket. (ver gráfico 80). Gráfico 80. Diagrama de secuencia Escribir notas internas 123

136 Modelo conceptual Diagramas de clase Mediante los diagramas de clases se describe la estructura estática del sistema. Recordemos que en nuestro caso de estudio tenemos dos Subsistemas: Portal y Ticket. Por ello a continuación se presentará un diagrama de clases para cada subsistema. Cabe destacar que la metodología UWE procura en este modelo no hacer caso, de cuestiones relacionadas con la navegación, y de los aspectos de interacción de la aplicación Web. En el caso de aplicaciones que se desarrollen desde cero, el énfasis en este modelo se haría en los atributos para las clases entidad y en las operaciones para las clases interfaz. Por ello, no se detallarán las clases de Interfaz asociadas a Pantallas. Posteriormente en el Modelo de Presentación se podrá obtener todo la información requerida. En este punto se toma la decisión de agrupar las pantallas, bajo una relación de herencia para facilitar algunos procesos, tal como propone (Weitzenfeld,2008) al señalar que para simplificar las relaciones de colaboración entre las clases y aprovechar las ventajas que proporciona el polimorfismo, es necesario crear una nueva superclase Pantalla. (p. 416). Para la elaboración del diagrama de clases del subsistema Portal, se toma en cuenta que las clases entidad Articulo, Categorias y usuarios son propias del CMS Joomla (JContent, JCategories y JUsers respectivamente) y para reflejar su estructura, se consultaron las definiciones existentes en los archivos del directorio en el que se instala el Joomla, en la siguiente carpeta: htdocs/cbcsite/libraries/joomla. (Ver gráfico 81). 124

137 Gráfico 81. Diagrama de clases Subsistema Portal. 125

138 Para la elaboración del diagrama de clases del subsistema Ticket, se toma en cuenta que la clase entidad Ticket y usuariost son propias del OsTicket y para reflejar su estructura, se consultaron las definiciones existentes en los archivos de definición de clases, en la carpeta include: clase Ticket: htdocs/cbcticket/include/class.ticket.php y clase staff (UsuarioT en el análisis) htdocs/cbcticket/include/class.staff.php. (Ver gráfico 82). Gráfico 82. Diagrama de clases Subsistema Ticket. 126

139 Modelo Conceptual diagramas de estados Los diagramas de estados muestran la secuencia de estados por los que pasa bien un caso de uso, bien un objeto a lo largo de su vida, o bien todo el sistema. En él se indican qué eventos hacen que se pase de un estado a otro y cuáles son las respuestas y acciones que genera. En nuestro caso representaremos objetos de la clase Articulo para el Subsistema Portal (Ver gráfico 83). Gráfico 83. Diagrama de estados Subsistema Portal Clase Articulo Para el subsistema Ticket, representaremos un diagrama de estados de la clase Ticket, allí podemos observar que existen cuatro estados(4). Tres de ellos explícitos: abierto, cerrado y Borrado; el estado En proceso está implícito y se ejecuta mientras se va colocando información en el historial, por los métodos Responder, Reasignar o notas internas. (Ver gráfico 84). Gráfico 84. Diagrama de estados Subsistema Ticket Clase Ticket 127

140 Modelo conceptual diccionario de clases A continuación se presenta un diccionario de clases para detallar los resultados del análisis realizado, obviando las pantallas ya que están son detalladas posteriormente. Subsistema Portal (ver cuadro 35 al 42). Cuadro 35 Clase InterfaceAdministrador Nombre de la clase: Subsistema: Estereotipo: Descripción: Atributos InterfaceAdministrador Portal, Ticket Borde Esta clase permite manejar la interacción con el usuario Administrador Operaciones EnviarUsuarioPassword() DesplegarPantallaAdminJoomla() MostrarMensaje() EnviarDatosArticulos() Cuadro 36 Clase InterfaceBasedeDatosJoomla Nombre de la clase: Subsistema: Estereotipo: Descripción: Atributos InterfaceBasedeDatosJoomla Portal Borde Esta clase permite manejar la interacción con la base de datos de Joomla. Operaciones Conectar() Desconectar() ObtenerArticulos(TipodeArticulo:objeto) ObtenerAdminPortal() ModificarArticulos() EliminarArticulos() CrearCategorias(TipodeArticulo:objeto) 128

141 Cuadro 37 Clase InterfaceVisitante Nombre de la clase: Subsistema: Estereotipo: Descripción: Atributos InterfaceVisitante Portal Borde Esta clase permite manejar la interacción con el actor Visitante. Operaciones SolicitarArticulosInicio() SolicitarArticulosNosotros() SolicitarArticulosCursos() SolicitarArticulosNoticias() SolicitarArticulosServicios() SolicitarArticulosDescargas() EnviarArticulo(TipodeArticulo:objeto) DesplegarPantalla(TipoPantalla: objeto) Cuadro 38 Clase JUser Nombre de la clase: Subsistema: Estereotipo: Descripción: Atributos $id: integer $name: string $username: string $ string $password: string $usertype: string $block: integer $send integer $registerdate: Date $lastvisitdate: Date $activation: string $params: string $groups: array $guest: Boolean $authgroups: array $authlevels: array $authactions: array $errormsg JUser Portal Entidad Esta clase permite registrar a los usuarios del portal. En este caso sólo el administrador será registrado. Corresponde a la clase de análisis UsuarioJ Operaciones getinstance() getparam() setparam() defparam() authorize() authorisedlevels() 129

142 Cuadro 39 Clase JContent Nombre de la clase: Subsistema: Estereotipo: Descripción: Atributos $id: integer $sectionid: string $catid: string $title: string $alias: string $title_alias: string $introtext: integer $fulltext: integer $mask: Date $created: Date $created_by: string $modified: string $cheked_out: Boolean $ cheked_out_time: Date $publish_up: array $publish_dows: array $images: array $urls: string $metadata: array JContent Portal Entidad Esta clase permite registrar los artículos del portal. Corresponde a la clase de análisis Articulo. Operaciones getinstance() defparam() setimages() getimages() Cuadro 40 Clase JCategories Nombre de la clase: Subsistema: Estereotipo: Descripción: Atributos $instances: array $nodes:array $checkedcategories: array $_extension: string $_table: string $_key: string $_options: array $_statefield: string JCategories Portal Entidad Esta clase permite registrar las categorías de los artículos del portal. Corresponde a la clase de análisis Categoria. Operaciones getinstance() get() _construct() 130

143 Cuadro 41 Clase ManejadorUsuarioJoomla Nombre de la clase: Subsistema: Estereotipo: Descripción: Atributos ManejadorUsuarioJoomla Portal Control Esta clase permite controlar todo lo relacionado con el administrador del portal. Operaciones DesplegarPantallaAdminJoomla() DesplegarPantallaPanelJoomla() EnviarUsuarioPassword() ValidarAdminPortal() MostrarMensaje() Cuadro 42 Clase ManejadorArticulo Nombre de la clase: Subsistema: Estereotipo: Descripción: Atributos ManejadorArticulo Portal Control Esta clase permite controlar todo lo relacionado con los artículos de Joomla. Operaciones DesplegarPantallaIncluirArticulo(() DesplegarPantallaArticulos() DesplegarPantallaEditarArticulo() DesplegarPantallaInicio() DesplegarPantallaNosotros() DesplegarPantallaCursos() DesplegarPantallaNoticias() DesplegarPantallaServicios() DesplegarPantallaDescargas() Articulos(TipodeArticulo: objeto) CrearArticulo() CrearEnlaceArtCategoria() IncluirArticulo() ListarArticulos(TipodeArticulo:objeto) CrearArticulos(TipodeArticulo:objeto) CrearCategorias() MostrarArchivo() 131

144 Para el subsistema Ticket se presentan a continuación las clases identificadas. (ver cuadro 43 al ). Cuadro 43 Clase InterfaceAdministrador Nombre de la clase: Subsistema: Estereotipo: Descripción: Atributos InterfaceAdministrador Portal, Ticket Borde Esta clase permite manejar la interacción con el usuario Administrador Operaciones EnviarUsuario() DesplegarPantallaAdminticket() MostrarMensaje() Cuadro 44 Clase InterfaceBasedeDatosTicket Nombre de la clase: Subsistema: Estereotipo: Descripción: Atributos InterfaceBasedeDatosJoomla Ticket Borde Esta clase permite manejar la interacción con la base de datos de OsTicket. Operaciones Conectar() Desconectar() ObtenerTickets ObtenerAdminTicket() EditarUsuario() EliminarUsuario() IncluirTicket() BuscarTicket() ObtenerUsuariosTicket() ModificarTicket() GuardarNotaInterna() RegistrarRespuesta() RegistrarNotaInterna() 132

145 Cuadro 45 Clase InterfaceVisitante Nombre de la clase: Subsistema: Estereotipo: Descripción: Atributos Cuadro 46 Clase InterfacePersonalCBC Nombre de la clase: Subsistema: Estereotipo: Descripción: Atributos Cuadro 47 Clase Staff Nombre de la clase: Subsistema: Estereotipo: Descripción: Atributos $udata integer $group_id: string $dept_id: string $password: string $id: string $fullname: string $username: integer $ integer $firstname: string $lastname: string $signature: string $dept: string InterfaceVisitante Ticket Borde Esta clase permite manejar la interacción con el actor Visitante. Operaciones DesplegarPantallaSolicitarTicket() MostrarMensaje() EnviarTicket() InterfacePersonalCBC Ticket Borde Esta clase permite manejar la interacción con el actor Personal CBC Operaciones EnviarRespuesta() EnviarNotaInterna() EnviarTicket() DesplegarPantalla(tipoPantalla: objeto) Staff Ticket Entidad Esta clase permite registrar a los usuarios del subsistema Ticket. En este caso el administrador y el personal de CBC Corresponde a la clase de análisis UsuarioT Operaciones Lockup($var) Check_passwd(passwd) Getdata() Ismanager() isstaff() isadmin() candeletetickets() update($vars,$errors) save($id, $vars, $errors) 133

146 Cuadro 48 Clase Ticket Nombre de la clase: Subsistema: Estereotipo: Descripción: Atributos $id: integer $extid: string $ string $status: string $created: string $updated: date $lastrespdate: date $lastmsgdate: date $duedate: date $priority: string $priority_id: string $fullname: string $staff_id: string $dept_id: Boolean $topic_id: string $dept_name: string $subject: string $helptopic: string $overdue: string $lastmsgid: string $dept: string $staff: string $topic: string $Tlock: string Ticket Ticket Entidad Esta clase permite registrar los Ticket. Corresponde a la clase de análisis Ticket. Operaciones Ticket() Load($id) Isopen(): Boolean Isclose(): Boolean get (): string getstatus(): string getdept(): string transfer(deptid) Cuadro 49 Clase ManejadorUsuarioT Nombre de la clase: Subsistema: Estereotipo: Descripción: Atributos ManejadorUsuarioT Ticket Control Esta clase permite controlar todo lo relacionado con el administrador en el subsistema Ticket. Operaciones DesplegarPantallaAdminTicket() DesplegarPantallaPanelTicket() EnviarUsuarioPassword() ValidarAdminTicket() MostrarMensaje() 134

147 Cuadro 50 Clase ManejadorTicket Nombre de la clase: Subsistema: Estereotipo: Descripción: Atributos ManejadorTicket Ticket Control Esta clase permite controlar todo lo relacionado con los Ticket de OsTicket. Operaciones DesplegarPantallaRegistrarUsuario() DesplegarEditarUsuario() DesplegarPantallaUsuarios() DesplegarPantallaSolicitarTicket() DesplegarPantallaConsultaTicket() DesplegarPantallaReasignarTicket() DesplegarPantallaTickets() DesplegarPantallaNotaInterna() Tickets() CrearTicket() IncluirTicket() ListarTicket() CrearTickets() Modelo Conceptual bases de datos Dado que se utilizan aplicaciones en software libre: Joomla y OsTicket. Estas ya poseen base de datos creadas en Mysql, para su funcionamiento. Por ello, a continuación se presenta la estructura de cada base de datos, tomadas por medio del phpmyadmin. Observe a continuación la estructura de la base de datos Joomla 2, debido a que está conformada por 51 tablas se presenta en varios gráficos (ver gráfico 85) (ver gráfico 86) (ver gráfico 87) y la de la base de datos OsTicket (ver gráfico 88). 2 Al instalar el Joomla se genera un código para las tablas, en este caso: w0kwt_ 135

148 Gráfico 85. Estructura base de datos Joomla(1) Gráfico 86. Estructura base de datos Joomla(2) 136

149 Gráfico 87. Estructura base de datos Joomla(3) Gráfico 88. Estructura base de datos OsTicket 137

150 Modelo de Navegación El modelo de navegación especifica que objetos serán visitados por el navegador a través de la aplicación y como se relacionarán. Para aplicaciones que se desarrollan desde cero, se deben abordar estos aspectos de navegación en este modelo. Se presenta seguidamente el modelo de navegación para cada uno de los sitios Web que se utilizarán. Iniciamos con el modelo de navegación para el Administrador del sistema en el subsistema Portal. En él se muestra que existe un Menú de opciones para que el administrador gestione los artículos, las categorías, los menús, entre otros elementos. En la opción de Gestión de Articulos, se podrá incluir uno nuevo, mediante la Clase de Proceso IncluirArticulo o se presentarán los artículos mediante la clase de proceso Articulos y se podrá navegar hasta la clase de proceso EditarArticulo. (Ver gráfico 89). 138

151 Gráfico 89. Modelo de Navegación Administrador Portal 139

152 El modelo de navegación para el visitante muestra las relaciones con la clase de navegación Articulo (JContent en Joomla) y la forma de navegación para los visitantes en el sitio Web. (Ver gráfico 90). Gráfico 90. Modelo de Navegación Visitante Subsistema Portal 140

153 El siguiente modelo de navegación corresponde al administrador del sistema en el subsistema Ticket. En él se muestra que existe un Menú de opciones para que el administrador gestione los usuarios de Osticket(personal), las áreas de atención, los Departamentos, entre otros elementos. En la opción de Personal, se presentarán los Usuarios y se podrá incluir un nuevo usuario o se podrá navegar hasta la clase de proceso EditarUsuario. (Ver gráfico 91). Gráfico 91. Modelo de Navegación Administrador Subsistema Ticket 141

154 El modelo de navegación Personal CBC Subsistema Ticket muestra la forma de navegación para la gestión de las solicitudes de atención por parte del personal CBC. (Ver gráfico 92). Gráfico 92. Modelo de Navegación Personal Subsistema Ticket 142

155 Modelo de Presentación En el caso de estudio, el modelo de presentación está conformado por las pantallas identificadas en la disciplina de análisis y diseño (Clases bordes) por cada caso de uso. Dado que dichas pantallas ya están predefinidas, sólo se presentarán algunas de ellas y se hará énfasis en los prototipos que fueron diseñados para el Cbcsys. Caso de uso Gestión Portal: para este caso de uso tenemos asociada la PantallaPanelJoomla. Esta página está predeterminada en el Manejador de Contenido Joomla, consta de un menú con 7 link a las opciones disponibles: Sitio, Usuarios, Menu, Contenido, Componentes, Extensiones y Ayuda. Luego, podemos observar los distintos botones disponibles para la gestión de los artículos, organizados dentro del Frame Opciones de Artículo. (Ver gráfico 93). Gráfico 93. Diagrama de Presentación PantallaPanelJoomla 143

156 Caso de uso Incluir articulo: para este caso de uso tenemos asociada la PantallaIncluirArticulo. En el modelo de presentación se muestra el Frame Datos de Artículo que contiene los distintos elementos que le serán solicitados al Administrador del sistema: título del artículo, Alias, categoría, entre otros. (Ver gráfico 94). Gráfico 94. Diagrama de Presentación PantallaIncluirArticulo 144

157 Para el caso de uso Mostrar Página inicio, tenemos el siguiente diagrama de presentación. (Ver gráfico 95). Gráfico 95. Diagrama de Presentación PantallaInicio 145

158 Para el caso de uso Mostrar información CBC, tenemos el siguiente diagrama de presentación. (Ver gráfico 96). Gráfico 96. Diagrama de Presentación PantallaNosotros 146

159 Para el caso de uso Mostrar Servicios, tenemos el siguiente diagrama de presentación. (Ver gráfico 97). Gráfico 97. Diagrama de Presentación PantallaServicios 147

160 Para el caso de uso Mostrar cursos, tenemos el siguiente diagrama de presentación. (Ver gráfico 98). Gráfico 98. Diagrama de Presentación PantallaCursos 148

161 Para el caso de uso Mostrar Noticias, tenemos el siguiente diagrama de presentación. (Ver gráfico 99). Gráfico 99. Diagrama de Presentación PantallaNoticias. 149

162 Para el caso de uso Mostrar Descargas, tenemos el siguiente diagrama de presentación. (Ver gráfico 100). Gráfico 100. Diagrama de Presentación PantallaDescargas. Caso de uso Solicitar Ticket: para este caso de uso tenemos asociada la PantallaSolicitarTicket. En el diagrama de presentación de esta pantalla se muestra el 150

163 Frame Datos del Ticket_incluir, que contiene los distintos elementos que le deberá introducir el usuario para Solicitar un Ticket de atención. (Ver gráfico 101). Gráfico 101. Diagrama de Presentación PantallaSolicitarTicket 151

164 Fase de Construcción En la fase de construcción el mayor énfasis estuvo en la implementación del sistema, para ello se elaboraron los diagramas de componentes, diagramas de interfaz y se realizaron las tareas de adaptación y composición de componentes (Pressman, 2002). Implementación Diagrama de Componentes A continuación se presentan los diagramas de componentes para el subsistema Artículos y el subsistema Ticket, considerando que ambos subsistemas manejan una gran cantidad de componentes y sólo se presentará un grupo representativo de ellos. En el diagrama de componentes subsistema Portal se muestran como componentes el archivo joomla.php, desde donde se gestiona todo el manejo del sitio Web, JPlugin.php: se utiliza para incorporar extensiones al JOOMLA; entre otros archivos fuentes importantes en la ejecución del sistema. (Ver gráfico 102). Gráfico 102. Diagrama de componentes Subsistema Portal. 152

165 En el diagrama de componentes Subsistema Ticket se muestran como componentes los archivos: Ticket.php, Class.Ticket.php, mysql.php, class.sys.php, sendmail.php, mail.php, login.php y common.php; entre otros archivos fuentes importantes en la ejecución del sistema. (Ver gráfico 103). Gráfico 103. Diagrama de componentes Subsistema Tickets. Diagrama de Despliegue Los diagramas de despliegue (deployment) muestran la disposición de los elementos de procesamiento en tiempo de ejecución. Estos elementos contienen componentes, procesos y objetos. De esta forma, el CBCSys utiliza un servidor Web, que incluye el Apache, las aplicaciones Joomla y OsTicket. Estas aplicaciones se comunican con las bases de datos: CBCSite y CBCTicket. También es necesaria la conexión con las computadoras de los clientes a través de los navegadores Web. (Ver gráfico 104). 153

166 Gráfico 104. Diagrama de Despliegue CBCSYS Adaptación de componentes La adaptación de componentes contempla la adecuación del CMS Joomla y del software OsTicket para cumplir con los requerimientos contemplados en los subsistemas Portal y Ticket, respectivamente. Adaptación de Joomla (subsistema Portal) Para cumplir con los casos de uso establecidos para el subsistema Portal se procedió a realizar la configuración general del manejador de contenido, posteriormente se fueron implementando los casos de uso. La configuración general se realizó de la siguiente manera: 154

167 1. Se procedió a Instalar Joomla y a renombrar la carpeta de instalación Joomla por cbcsite. 2. Tomando en cuenta que se requiere el mercadeo de los servicios que presta CBC, se estableció el nombre del sitio, la meta descripción, las meta Palabras, y el sufijo en el título de la página. Es importante destacar que la meta descripción es una meta etiqueta utilizada para describir la página en la que nos encontramos. Proporciona un corto resumen de la página para que los lectores puedan decidir si esta contiene la información que están buscando o si es interesante para ellos. Los motores de búsqueda utilizan la meta descripción para describir la página en los resultados de búsqueda. Si una página no tiene una buena meta descripción, puede que sea listada entre los primeros resultados, pero estos no recogerán el contenido de la página, lo cual puede resultar en que nadie pulse el enlace hacia ella. La configuración del sitio se realizó mediante el ajuste de los siguientes parámetros en la opción de Configuración Global del panel del control, pestaña Sitio: Nombre del sitio: Core Business Consulting. Meta-Descripción del sitio: Core Business Consulting (CBC), es una empresa de consultoría y capacitación en software libre que ofrece soluciones basadas en sistemas transaccionales e inteligencia de negocios. Meta-Palabras del sitio: Core Business Consulting, CBC, Consultoría, Software Libre, Inteligencia de negocios, Sistemas transaccionales, Caracas, Venezuela. Sufijo en el título de la página: Core Business Consulting. Estas configuraciones pueden ser observadas en el gráfico que se presenta a continuación. (ver gráfico 105). 155

168 Gráfico 105. Configuración global Joomla Para reducir el tiempo de envío de la respuesta HTML y agilizar el proceso de desarrollo del sitio, se cambió la configuración del servidor al permitir la compresión Gzip de las páginas en la opción de Configuración Global del panel del control, pestaña Servidor. Se creó una imagen representativa de la empresa para la página de inicio (tomando algunas imágenes del anterior sitio web de la empresa) y se sustituyó el archivo de imagen original templates/beez_20/images/personal/personal2.png por este. Se cambió la información del pie de página. En el archivo templates/beez_20/index.php, se editó la siguiente línea: <p><?php echo JText::_('TPL_BEEZ2_POWERED_BY');?> Core Business Consulting</p>. Se instaló el componente Akeeba Backup Core , el cual se utiliza para el respaldo y restauración de sitios web basados en Joomla. Se instaló el componente Admin Tools 2.2.0, el cual ofrece un conjunto de funcionalidades administrativas y de seguridad. 156

169 Se eliminó la línea templates/beez_20/index.php:139 para descartar el uso del ajuste de fuente. Se cambió la configuración de usuarios mediante el ajuste de las siguientes opciones: No se registran usuarios en el frontend (ya que el acceso al portal es público). No se muestra el idioma del sitio, ya que el público objeto del sistema es hispanohablante y no requieren la presentación en otros idiomas. Se configuró la opción de correo, en el menú Usuarios, correo masivo, clic en Opciones, pestaña Envio masivo: Prefijo Asunto: CBC - Sufijo de contenido: (una línea en blanco) --- CBC de Venezuela. Observe a continuación la configuración de usuarios (ver gráfico 106). Gráfico 106. Configuración de Usuarios Joomla Luego el mayor énfasis estuvo en la creación de las pantallas nuevas, contempladas en los casos de uso, para ello primeramente se procedió a crear un árbol de categorías (estructura de almacenamiento lógica), con las siguientes opciones: Nosotros, 157

170 Servicios, Cursos, Noticias, Opciones del Menú. Seguidamente se fueron creando las categorías y artículos necesarios para cumplir con los casos de uso: Mostrar página inicio, Mostrar información CBC, Mostrar Servicios, Mostrar Cursos, Mostrar Noticias y Descargar Archivos. 1. Se creó un único menú con las siguientes opciones: Inicio, Nosotros, Servicios, Cursos, Noticias, Descargas y Contacto. 2. Se creó un elemento de menú para la página de inicio que muestra tres artículos aleatorios. 3. Se asoció la opción Nosotros a los artículos de la categoría Nosotros. Se muestran como un blog: 1 como principal, 2 como destacados en 2 columnas, ninguno como enlace y sin paginación. 4. Se asoció la opción Servicios a los artículos de la categoría Servicios. Se muestran como un blog: ninguno como principal, 4 como destacados en 2 columnas, ninguno como enlace y con la paginación correspondiente. 5. Se crearon artículos para las diferentes categorías existentes. Los artículos sobre cursos ofrecidos por CBC se crearon a partir de una plantilla HTML diseñada para tal fin, la cual se encuentra en media/editors/tinymce/templates/curso-cbc.html.(ver gráfico 107 ). Gráfico 107. Plantilla HTML para el registro de cursos 158

171 La actualización de la lista de plantillas existentes es manual, se debe modificar el valor de la variable tinymcetemplatelist del archivo: media/editors/tinymce/templates/template_list.js agregando los datos de la nueva plantilla. (ver gráfico 108). Gráfico 108. Modificación del archivo template_list.js Además, se debe incrementar en uno el segundo parámetro de la llamada a la función $this->params->def('template', en el archivo plugins/editors/tinymce/tinymce.php:367 aproximadamente. 6. Se asoció la opción Noticias a los artículos de la categoría Noticias. Se muestran como un blog: 1 como principal, 2 como destacados en 2 columnas, 4 como enlaces y con la paginación correspondiente. Además, se muestran los artículos de la categoría Responsabilidad Social. 7. Se asoció la opción Cursos a los artículos de la categoría Cursos. Se muestran como un blog: 4 como principales, ninguno como destacados, sin columnas, sin enlaces y con la paginación correspondiente. 159

172 8. Se instaló el módulo EasyFolderListing 2.0, el cual sirve para mostrar la lista de enlaces de los archivos de una carpeta dada. Además, se tradujeron las respuestas HTML. 9. Se asoció la opción Descargas a los archivos de la carpeta /downloads, mediante el módulo EasyFolderListing 2.0. (ver gráfico 109). Gráfico 109. Módulo EasyFolderListing 2.0 Adaptación de OsTicket Luego de instalar el OsTicket se procedió a: 1. Renombrar la carpeta de instalación OsTicket por CbcTicket. 2. Configurar las opciones de conexión con el SCP(Módulo de administración, Back-End ) y el acceso a la base de datos de la siguiente forma: Usuario: cbcadmin Contraseña: XXXXX 3. Se cambiaron los permisos de /include/ostconfig.php para considerar la configuración del servidor local del mysql. Tal como se muestra a continuación. (ver cuadro 51). 160

173 Cuadro 51 Archivo ostconfig.php en OsTicket <?php /********************************************************************* ost-config.php Static osticket configuration file. Mainly useful for mysql login info. Created during installation process and shouldn't change even on upgrades. Peter Rotich Copyright (c) osticket Released under the GNU General Public License WITHOUT ANY WARRANTY. See LICENSE.TXT for details. vim: expandtab sw=4 ts=4 sts=4: $Id: $ **********************************************************************/ #Disable direct access. if(!strcasecmp(basename($_server['script_name']),basename( FILE ))!defined('root_path')) die('elartedeganar.com'); #Install flag define('ostinstalled',true); if(ostinstalled!=true){ if(!file_exists(root_path.'setup/install.php')) die('error: Contact system admin.'); //Something is really wrong! //Invoke the installer. header('location: '.ROOT_PATH.'setup/install.php'); exit; } # Encrypt/Decrypt secret key - randomly generated during installation. define('secret_salt','2a73532c34bba40'); #Default admin . Used only on db connection issues and related alerts. #Mysql Login info define('dbtype','mysql'); define('dbhost','localhost'); define('dbname','cbcticket'); define('dbuser','cbcdba'); define('dbpass','cbcdba'); #Table prefix define('table_prefix','ost_');?> 161

174 4. Se configuró el usuario administrador. Para ello se creó un usuario llamado cbcadmin 5. Se editó el archivo /index.php para cambiar el texto de introducción.(ver cuadros 52 y 53). Cuadro 52 Archivo index.php en OsTicket (parte 1) <?php /******************************************************************** * index.php Helpdesk landing page. Please customize it to fit your needs. Peter Rotich Copyright (c) osticket Released under the GNU General Public License WITHOUT ANY WARRANTY. See LICENSE.TXT for details. vim: expandtab sw=4 ts=4 sts=4: $Id: $ ******************************************************************** **/ require('client.inc.php'); //We are only showing landing page to users who are not logged in. if($thisclient && is_object($thisclient) && $thisclient->isvalid()) { require('tickets.php'); exit; } 162

175 Cuadro 53 Archivo index.php en OsTicket (parte 2) require(clientinc_dir.'header.inc.php');?> <div id="index"> <h1>bienvenido al centro de soporte de Core Business Consulting (CBC)</h1> <p class="big">con el fin de agilizar la comunicación con nuestros clientes y ofrecerles un mejor servicio, utilizamos el sistema de ticket de soporte. Toda solicitud de apoyo se le asigna un número de ticket único que se puede utilizar para rastrear el progreso y respuestas en línea. Para su referencia le proporcionamos la historia de todas sus solicitudes de apoyo. Es necesario una dirección de correo electrónico válida.</p> <hr /> <br /> <div class="lcol"> <img src="./images/new_ticket_icon.jpg" width="48" height="48" align="left" style="paddingbottom:150px;"> <h3>abrir un Ticket Nuevo</h3> <p>por favor, facilite el mayor número de detalles posibles. Si deseas actualizar una peticion ya realizada, utiliza el formulario a la derecha.</p> Para Abrir un ticket nuevo, haga clic en el boton <br /><br /> <form method="link" action="open.php"> <input type="submit" class="button2" value="abrir Ticket Nuevo"> </form> </div> <div class="rcol"> <img src="./images/ticket_status_icon.jpg" width="48" height="48" align="left" style="paddingbottom:150px;"> <h3>comprobar estado de los Tickets</h3>Proporcionamos los archivos y el historial de todas tus solicitudes de soporte completo con respuestas. <br /><br /> <form class="status_form" action="login.php" method="post"> <fieldset> <label> </label> <input type="text" name="l "> </fieldset> <fieldset> <label>ticket ID:</label> <input type="text" name="lticket"> </fieldset> <fieldset> <label> </label> <input type="submit" class="button2" value="ver Estado"> </fieldset> </form> </div> <div class="clear"></div><br /> </div><br /> <?php require(clientinc_dir.'footer.inc.php');?> 163

176 6. se incorporaron las siguientes áreas de atención: Inteligencia de negocios, Sistemas transaccionales, Plataforma tecnológica y Capacitación. 7. Se crearon 4 departamentos con su staff y sus respectivas áreas de atención. Físicamente existen sólo dos departamentos que atienden a los clientes: (a) Mercadeo y ventas y (b) Consultoría; sin embargo de forma predeterminada le llegan las solicitudes a los jefes de departamento y éste las puede asignar a otros empleados. La empresa sólo cuenta con seis(6) empleados, por lo cual se decidió colocar en el sistema cuatro departamentos asociados a las àreas de atención. 1. Departamento de Consultoria_Plataforma tecnológica atiende Plataforma tecnológica. 2. Departamento de Consultoria_Inteligencia atiende Inteligencia de negocios 3. Departamento de Consultoria_Sistemas atiende Sistemas transaccionales. 4. Departamento de Mercadeo y ventas atiende Capacitación. Se configuraron los mensajes en la opción Panel de Configuración, correos, Plantillas, Plantillas por defecto. Allí se escribieron, entre otros, los mensajes que se muestran cuando el visitante solicita un Ticket (ver gráfico 110) o cuando se le responde a la solicitud. (ver gráfico 111). Gráfico 110. Configuración mensaje Ticket nuevo 164

177 Gráfico 111. Configuración mensajes Responder Ticket y otros 165

178 Composición o Integración de los componentes Se asoció la opción Contacto a la URL embebida de cbcticket. Para ello, se creó un elemento de menú de tipo URL embebida, asignándole la dirección de CBCTicket. (ver gráfico 112). Gráfico 112. Configuración mensajes Responder Ticket y otros 1. Dado que el actor administrador del sistema es el que se encarga de actualizar la información del subsistema Portal y también gestionar al personal de CBC, se decidió registrar a este actor sólo una vez en el BackEnd del Joomla y luego trabajar con la clave en el subsistema Ticket, para ello fue necesario mantener los datos del usuario cbcadmin. o Se suprimió la opción de cambio de contraseña para este usuario, modificando la línea scp/profile.php:135. o Se agregó la lógica necesaria para deshabilitar la edición de datos de este usuario, modificando el archivo include/staff/staff.inc.php. (ver cuadros 54 y 55). 166

179 Cuadro 54 Deshabilitar la edición de Cbcadmin (parte 1) <?php if(!defined('ostadmininc')!$thisuser->isadmin()) die('acceso Denegado'); $rep=null; $newuser=true; if($staff && $_REQUEST['a']!='new' && $staff->getid()==1){ // Logica de deshabilitacion de usuario 1 $rep=$staff->getinfo(); $title='consutar Datos de: '.$rep['firstname'].' '.$rep['lastname']; $action='default'; $disabled='disabled="disabled"'; $newuser=false; }elseif($staff && $_REQUEST['a']!='new'){ $rep=$staff->getinfo(); $title='editar Datos de: '.$rep['firstname'].' '.$rep['lastname']; $action='update'; $pwdinfo='para restablecer la contraseña escriba una nueva a continuación'; $newuser=false; }else { $title='añadir Nuevo Miembro'; $pwdinfo='contraseña temporal (obligatoria)'; $action='create'; $rep['resetpasswd']=isset($rep['resetpasswd'])?$rep['resetpasswd']:1; $rep['isactive']=isset($rep['isactive'])?$rep['isactive']:1; $rep['dept_id']=$rep['dept_id']?$rep['dept_id']:$_get['dept']; $rep['isvisible']=isset($rep['isvisible'])?$rep['isvisible']:1; } $rep=($errors && $_POST)?Format::input($_POST):Format::htmlchars($rep); //get the goodies. $groups=db_query('select group_id,group_name FROM '.GROUP_TABLE); $depts= db_query('select dept_id,dept_name FROM '.DEPT_TABLE);?> <div class="msg"><?php echo $title?></div> <table width="100%" border="0" cellspacing=0 cellpadding=0> <form action="admin.php" method="post"> <input type="hidden" name="do" value="<?php echo $action?>"> <input type="hidden" name="a" value="<?php echo Format::htmlchars($_REQUEST['a'])?>"> <input type="hidden" name="t" value="staff"> <input type="hidden" name="staff_id" value="<?php echo $rep['staff_id']?>"> <tr><td> <table width="100%" border="0" cellspacing=0 cellpadding=2 class="tform"> <tr class="header"><td colspan=2>cuenta de Usuario</td></tr> <tr class="subheader"><td colspan=2>información de la Cuenta</td></tr> <tr> 167

180 Cuadro 55 Deshabilitar la edición de Cbcadmin (parte 2) <th>nombre:</th> <td><input type="text" name="username" value="<?php echo $rep['username']?>" <?php echo $disabled?>> <font class="error">* <?php echo $errors['username']?></font></td> </tr> <tr> // Se omite el código asociado a la presentación del formulario <th>confirmar Contraseña:</th> <td class="maintablealt"><input type="password" name="vpassword" AUTOCOMPLETE=OFF <?php echo $disabled?> > <font class="error"> <?php echo $errors['vpassword']?></font></td> </tr> <tr> <th>forzar Cambio de Contraseña:</th> <td> <input type="checkbox" name="resetpasswd" <?php echo $rep['resetpasswd']? 'checked': ''?> <?php echo $disabled?>>requerir cambio de contraseña en el siguiente inicio de sesión</td> </tr> <tr class="header"><td colspan=2>estado y Configuración de Permisos</td></tr> <tr class="subheader"> <td colspan=2> Los permisos para los miembros del Staff estan también basados en la asignación de grupo.<br> <b>el Administrador no se ve afectado por los permisos del grupo.</b></td> <tr><th>mostrar en el Listado</th> <td> <input type="checkbox" name="isvisible" <?php echo $rep['isvisible']? 'checked': ''?> <?php echo $disabled?>>mostrar miembro en el directorio del Staff </td> </tr> <tr><th>modo Vacaciones</th> <td class="maintablealt"> <input type="checkbox" name="onvacation" <?php echo $rep['onvacation']? 'checked': ''?> <?php echo $disabled?>> Miembro en modo vacaciones. (<i>no asignarle Tickets o Alertas</i>) <font class="error"> <?php echo $errors['vacation']?></font> </td> </tr> </table> </td></tr> <tr><td style="padding:5px 0 10px 210px;"> <input class="button" type="submit" name="submit" value="guardar" <?php echo $disabled?>> <input class="button" type="reset" name="reset" value="restablecer" <?php echo $disabled?>> <input class="button" type="button" name="cancel" value="cancelar" onclick='window.location.href="admin.php?t=staff"'> </td></tr> </form></table> 168

181 o Se modificó la función check_passwd para buscar la contraseña de cbcadmin en la base de datos cbcsite, Para mantener el entorno visual del portal en el subsistema Ticket se cambiaron los encabezados del sistema para colocar el logo de la empresa CBC, para ello se ubicaron las carpetas de las imágenes a fin de sustituir los archivos que correspondieran al logo de OsTicket por el archivo con el logo de CBC. Los cambios se realizaron en la carpeta /scp/images en los archivos ostlogo (ver gráfico 113) y logo-support. Es importante destacar que el tamaño de las imágenes debió reducirse antes de proceder a realizar la sustitución.(ver gráfico 114) Gráfico 113. Cambio de Logo de OsTicket al logo CBC (ostlogo) Gráfico 114. Cambio de Logo de OsTicket al logo CBC (logo-support) 169

182 Interfaces A continuación se podrán observar las pantallas finales (interfaces) desarrolladas en el CBCSYS. Tal como se indicó en el modelo de presentación se hará énfasis en las pantallas nuevas, ya que las pantallas estándar del Joomla y del OsTicket sólo se modificaron para incluir elementos, tales como el nombre de la empresa, logo, colores, entre otros. Caso de uso mostrar página principal: la primera interfaz que se le presenta al usuario es la pantalla Inicio que muestra las opciones disponibles para el visitante: información general de la empresa CBC: Información de CBC, servicios, cursos, noticias, descargas y contacto. (Ver gráfico 115). Gráfico 115. Pantalla inicio. 170

183 Caso de uso mostrar Información CBC: se muestra la pantalla Nosotros donde se puede observar información de la empresa CBC: descripción, Misión y Visión y valores. Esta información puede ser modificada por el Administrador del sistema, en caso de que ocurran actualizaciones sobre la misma. (Ver gráfico 116). Gráfico 116. Pantalla Nosotros 171

184 Caso de uso mostrar Servicios: La Pantalla Servicios permite consultar las cuatro áreas de servicios que ofrece la empresa: Capacitación, Sistemas transaccionales, plataforma tecnológica e inteligencia de negocios. Para obtener la descripción detallada de los servicios el usuario debe hacer Clic sobre el enlace <<Leer más>>. (Ver gráfico 117). Gráfico 117. Pantalla servicios 172

185 Caso de uso mostrar cursos: La pantalla Cursos presenta una lista de los cursos que ofrece la empresa. El usuario elegirá el nombre del curso que desea consultar y se le presentarán los detalles del mismo: contenidos, fecha, costo, entre otros. (Ver gráfico 118). Gráfico 118. Pantalla cursos 173

186 Caso de uso mostrar noticias: la pantalla Noticias muestra las noticias, colocadas por el Administrador del sistema, que sean de relevancia para los clientes. (Ver gráfico 119). Gráfico 119. Pantalla noticias 174

187 Caso de uso Descargar archivos: La pantalla descargas presenta una lista de materiales en software libre que le permiten al cliente mantenerse actualizado en el área de software libre. (Ver gráfico 120). Gráfico 120. Pantalla Descargas. 175

188 Caso de uso Solicitar Ticket: por medio de la pantalla Contacto el visitante podrá solicitar un ticket de atención, hacia alguna de las áreas de la empresa y luego realizar la consulta del estatus del Ticket solicitado. (ver gráfico 121). Luego, el visitante tendrá que escribir los datos que desee para su ticket de atención. (ver gráfico 122). Gráfico 121. Pantalla contacto 176

189 Gráfico 122. Pantalla solicitar Ticket Pruebas En la disciplina de Pruebas se llevaron a cabo las pruebas al sistema web desarrollado, para las pruebas de correo fue necesario colocar el sistema en un servidor público. En una primera fase se probó la visualización de las páginas en distintos navegadores. Al respecto, todas las interfaces fueron capturadas ejecutando el sistema desde el navegador Internet Explorer. Se presentan seguidamente algunas pantallas en 177

190 Firefox. Observe la pantalla Servicios en el navegador Mozilla Firefox para Windows 7.0. (Ver gráfico 123). Gráfico 123. Pantalla Servicios en el navegador Mozilla Firefox 178

191 124). En la siguiente pantalla se muestra la prueba de la opción Cursos. (ver gráfico Gráfico 124. Pantalla Cursos en el navegador Mozilla Firefox En la segunda fase se realizaron las pruebas a los casos de uso asociados al subsistema Ticket. Se presentan a continuación algunos de los más representativos. Es importante destacar que se realizaron las pruebas de los cursos alternativos que se seguían en los casos de uso, como por ejemplo los mensajes de error en caso de que el password del administrador fuese incorrecto. Caso de uso validar administrador Ticket: (ver gráfico 125). Gráfico 125. Prueba validar administrador Ticket 179

192 Caso de uso editar usuario CBC: el administrador debe seleccionar el usuario que desea editar (ver gráfico 126). Gráfico 126. Prueba editar usuario CBC - listado de usuarios 180

193 Luego debe modificar los datos que desee. (ver gráfico 127). Gráfico 127. Prueba editar usuario CBC - editar 181

194 Caso de uso solicitar ticket: para este caso de uso se presenta una solicitud de presupuesto para el área de capacitación. (ver gráfico 128). Gráfico 128. Prueba solicitar ticket 182

195 Al registrar la solicitud, el sistema envía un correo con el número de Ticket de atención. (ver gráfico 129) y seguidamente le envía al visitante un mensaje indicándole que la transacción fue exitosa. (ver gráfico 130). Gráfico 129. Prueba solicitar ticket - correo Gráfico 130. Prueba solicitar ticket mensaje transacción exitosa 183

196 Caso de uso consultar Ticket: luego de haber realizado la solicitud se puede consultar el ticket con el número asignado por el sistema. (ver gráfico 131). Gráfico 131. Prueba Consultar ticket 184

197 Caso de uso responder Ticket: para responder un ticket el usuario debe seleccionar uno de los tickets registrados (ver gráfico 132), luego debe seleccionar la opción responder y escribir el texto correspondiente. (ver gráfico 133). Gráfico 132. Prueba responder Ticket- listado de tickets 185

198 Gráfico 133. Prueba responder Ticket - escribir respuesta 186

Programación orientada a

Programación orientada a Programación orientada a objetos con Java Pedro Corcuera Dpto. Matemática Aplicada y Ciencias de la Computación Universidad de Cantabria corcuerp@unican.es Objetivos Presentar los conceptos de la programación

Más detalles

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado 1. Introducción Unified Modeling Languaje Fuente: Booch- Jacobson-Rumbauch y diversos sitios Internet, entre otros:

Más detalles

Tema 5: El Lenguaje Unificado de Modelado. Departamento de Lenguajes y Sistemas Informáticos II www.kybele.urjc.es

Tema 5: El Lenguaje Unificado de Modelado. Departamento de Lenguajes y Sistemas Informáticos II www.kybele.urjc.es Tema 5: El Lenguaje Unificado de Modelado Departamento de Lenguajes y Sistemas Informáticos II Contenidos Introducción Diagramas de UML Modelado de la parte estática Modelado de la parte dinámica Las 4+1

Más detalles

Interacción Persona - Ordenador

Interacción Persona - Ordenador Interacción Persona - Ordenador Diseño de la interfaz en la Ingeniería del Software Dr. Pedro Latorre Dra. Sandra Baldassarri Dra. Eva Cerezo Ingeniería del Software Ingeniería del Software: Definición

Más detalles

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1 Introducción al Proceso Unificado de Desarrollo de Software Autor: Ing. Silverio Bonilla 1 James Rumbaugh et al. Concepto de Método Una metodología de ingeniería del software es un proceso para producir

Más detalles

BASES DE DATOS. Ivon Tarazona Oriana Gomez

BASES DE DATOS. Ivon Tarazona Oriana Gomez BASES DE DATOS Ivon Tarazona Oriana Gomez Introducción Introducción Ventajas e (Unified Modeling Language) Es un lenguaje usado para especificar, visualizar y documentar los diferentes aspectos relativos

Más detalles

Índice. http://www.dicampus.es

Índice. http://www.dicampus.es Módulo 2 UML Índice Introducción a UML Lenguaje Unificado de Modelado (UML) Diagramas UML Diagramas de casos de uso Diagramas estructurales: Clases Diagramas estructurales: Objetos Diagramas de interacción:

Más detalles

http://www.cem.itesm.mx/extension/ms

http://www.cem.itesm.mx/extension/ms Diplomado Programación orientada a objetos con Java y UML Las empresas necesitan contar con sistemas de información modernos, ágiles y de calidad para alcanzar sus objetivos y ser cada vez más competitivos

Más detalles

Rational Unified Process (RUP)

Rational Unified Process (RUP) Rational Unified Process (RUP) Este documento presenta un resumen de Rational Unified Process (RUP). Se describe la historia de la metodología, características principales y estructura del proceso. RUP

Más detalles

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Página 1 de 23 Índice del Documento 1.- Introducción... Página 4 2.- Propuesta

Más detalles

Análisis del Sistema de Información

Análisis del Sistema de Información Análisis del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD ASI 1: DEFINICIÓN DEL SISTEMA... 6 Tarea ASI 1.1: Determinación del Alcance del Sistema... 6 Tarea ASI 1.2: Identificación

Más detalles

Capitulo III. Diseño del Sistema.

Capitulo III. Diseño del Sistema. Capitulo III. Diseño del Sistema. Para el desarrollo del sistema en la presente tesis se utilizo el paradigma orientado a objetos utilizando el lenguaje Java en su versión 1.2. Por medio de este lenguaje

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA... 7 Tarea DSI 1.1: Definición de Niveles de Arquitectura... 9 Tarea DSI

Más detalles

Primer avance de proyecto de software para la gestión de inscripciones en cursos

Primer avance de proyecto de software para la gestión de inscripciones en cursos Primer avance de proyecto de software para la gestión de inscripciones en cursos 1. Introducción Andrés Felipe Bustamante García, Carolina Sarmiento González En este documento se presentan los resultados

Más detalles

desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el

desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el Capitulo II. Análisis de herramientas y tecnologías de desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el lenguaje de Modelo de Objetos llamado UML (Unified

Más detalles

En el siguiente apartado se detallan ciertos conceptos que ayudan a comprender en mayor medida el Proyecto.

En el siguiente apartado se detallan ciertos conceptos que ayudan a comprender en mayor medida el Proyecto. APÉNDICES En el siguiente apartado se detallan ciertos conceptos que ayudan a comprender en mayor medida el Proyecto. APÉNDICE 1. Herramientas Las herramientas que se usaron en el análisis, desarrollo

Más detalles

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes:

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: 1. Proporcionar una guía de actividades para el trabajo en equipo. (Guía detallada para el desarrollo

Más detalles

CAPÍTULO 4 ANÁLISIS Y DISEÑO: e-commerce CONSTRUCTOR

CAPÍTULO 4 ANÁLISIS Y DISEÑO: e-commerce CONSTRUCTOR CAPÍTULO 4 ANÁLISIS Y DISEÑO: e-commerce CONSTRUCTOR En este capítulo se describe el análisis y diseño de un sistema, denominado e-commerce Constructor, el cual cumple con los siguientes objetivos: Fungir

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA...7 Tarea DSI 1.1: Definición de Niveles de Arquitectura...9 Tarea DSI 1.2:

Más detalles

Diseño y Modelación de un Proyecto de Software Utilizando el lenguaje UML

Diseño y Modelación de un Proyecto de Software Utilizando el lenguaje UML Diseño y Modelación de un Proyecto de Software Utilizando el lenguaje UML INTRODUCCION Desde los inicios de la informática se han estado utilizando distintas formas de representar los diseños de una manera

Más detalles

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON)

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1.1 Introducción Este método proporciona un soporte para el diseño creativo de productos de software, inclusive a escala industrial.

Más detalles

RESUMEN. IV P á g i n a

RESUMEN. IV P á g i n a RESUMEN El Sistema Web para el Control de la Caja de Ahorros de SENECA, fue desarrollado siguiendo las fases establecidas por la Metodología RUP (Proceso Unificado de Rational). Las fases de esta metodología

Más detalles

BPMN vs UML. Los Requerimientos y el Modelo del Negocio. Autor: Norberto Figuerola

BPMN vs UML. Los Requerimientos y el Modelo del Negocio. Autor: Norberto Figuerola BPMN vs UML Autor: Norberto Figuerola Los Requerimientos y el Modelo del Negocio Normalmente, siempre que iniciamos un esfuerzo de desarrollo de software éste tiene como objetivo automatizar procesos del

Más detalles

Analista Programador Java: Business Apps Expert

Analista Programador Java: Business Apps Expert Analista Programador Java: Business Apps Expert TITULACIÓN DE FORMACIÓN CONTINUA BONIFICADA EXPEDIDA POR EL INSTITUTO EUROPEO DE ESTUDIOS EMPRESARIALES Analista Programador Java: Business Apps Expert Duración:

Más detalles

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta (Business Process Management, BPM). La Gerencia de los Procesos del Negocio: Se define como: "integración

Más detalles

Ingeniería de Software I

Ingeniería de Software I Ingeniería de Software I Agenda Objetivo. Unidades de aprendizaje. Formas de evaluación. Bibliografía. 2 Datos del profesor Correo electrónico: egonzalez@upemor.edu.mx Asesorías Jueves de 11:00 a 13:00

Más detalles

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.1 UML: Introducción

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.1 UML: Introducción PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación II MODELOS y HERRAMIENTAS UML 1 1 Técnica de modelado de objetos (I) El modelado orientado a objetos es una técnica de especificación semiformal para

Más detalles

Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Gobierno Municipal del Cantón Bolívar

Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Gobierno Municipal del Cantón Bolívar Gobierno Municipal del Cantón Bolívar Versión: Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Plan de Desarrollo de Software Universidad

Más detalles

CAPÍTULO IV - GUÍA PARA HACER ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS

CAPÍTULO IV - GUÍA PARA HACER ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS CAPÍTULO IV - GUÍA PARA HACER ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS 4.1 Diferencias entre análisis y diseño La división entre el análisis y diseño es poco clara, el trabajo de los dos se mezcla continuamente

Más detalles

OMG UML 2.0 Marcando un hito en el desarrollo de software Resumen Keywords Historia del Surgimiento

OMG UML 2.0 Marcando un hito en el desarrollo de software Resumen Keywords Historia del Surgimiento OMG UML 2.0 Marcando un hito en el desarrollo de software Resumen A través de este artículo se ofrece un panorama amplio y de alto nivel sobre la especificación y los diferentes diagramas del Lenguaje

Más detalles

Ingeniería de Software

Ingeniería de Software Ingeniería de Software MSDN Ingeniería de Software...1 Ingeniería del Software_/_ Ingeniería y Programación...1 Análisis de Requerimientos...2 Especificación...3 Diseño...4 Desarrollo en Equipo...5 Mantenimiento...6

Más detalles

Inicio de MO Inicio de MD Inicio de MF. Documento de Análisis. Base de datos de las especificaciones OMT. MO, MD, MF Detallados. Librería de Clases

Inicio de MO Inicio de MD Inicio de MF. Documento de Análisis. Base de datos de las especificaciones OMT. MO, MD, MF Detallados. Librería de Clases 3.2 TÉCNICA DE MODELADO DE OBJETOS (OMT) (JAMES RUMBAUGH). 3.2.1 Introducción. En este documento se trata tanto el OMT-1 como el OMT-2, el primero contenido en el Libro Modelado y Diseño Orientado (Metodología

Más detalles

Diseño lógico de sistemas aplicando el lenguaje de modelado unificado

Diseño lógico de sistemas aplicando el lenguaje de modelado unificado Diseño lógico de sistemas aplicando el lenguaje de modelado unificado No. De Registro CGPI: 20061221. Director del proyecto: Roberto De Luna Caballero. Profesores participantes: M. en C Fabiola Ocampo

Más detalles

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.2 UML: Modelado de casos de uso

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.2 UML: Modelado de casos de uso PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación II MODELOS y HERRAMIENTAS UML 1 1 Modelado de casos de uso (I) Un caso de uso es una técnica de modelado usada para describir lo que debería hacer

Más detalles

Analista Programador Android: Business Android Apps Expert

Analista Programador Android: Business Android Apps Expert Analista Programador Android: Business Android Apps Expert TITULACIÓN DE FORMACIÓN CONTINUA BONIFICADA EXPEDIDA POR EL INSTITUTO EUROPEO DE ESTUDIOS EMPRESARIALES Analista Programador Android: Business

Más detalles

Arquitectura de Aplicaciones

Arquitectura de Aplicaciones 1 Capítulo 13: Arquitectura de aplicaciones. - Sommerville Contenidos del capítulo 13.1 Sistemas de procesamiento de datos 13.2 Sistemas de procesamiento de transacciones 13.3 Sistemas de procesamiento

Más detalles

Boletín de Asesoría Gerencial SOA: enfoque técnico orientado a procesos

Boletín de Asesoría Gerencial SOA: enfoque técnico orientado a procesos Espiñeira, Sheldon y Asociados No. 4-2010 Contenido Haga click en los enlaces para navegar a través del documento Haga click en los enlaces para llegar directamente a cada sección 4 Introducción 4 Qué

Más detalles

SIGPRE Sistema de Gestión Presupuestaria

SIGPRE Sistema de Gestión Presupuestaria SIGPRE Sistema de Gestión Presupuestaria Documento de Arquitectura UTN Histórico de Revisiones Fecha Versión Descripción Autor 11/17/2009 1.0 Borrador de la arquitectura Roberto López Hinojosa 12/14/2009

Más detalles

UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos

UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos 2.1. Principios básicos del Modelado de Objetos UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos Hoy en día muchos de los procesos que intervienen en un negocio o empresa y que resuelven

Más detalles

El Proceso Unificado de Desarrollo de Software

El Proceso Unificado de Desarrollo de Software El Proceso de Desarrollo de Software Ciclos de vida Métodos de desarrollo de software El Proceso Unificado de Desarrollo de Software 1 Fases principales del desarrollo de software Captura de requisitos:

Más detalles

Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL

Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL DNI Apellidos y nombre 1. Cuál de las siguientes afirmaciones no es una causa de los problemas del software?

Más detalles

CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA

CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA PROGRAMACIÓN DIDACTICA ANUAL Parte específica del módulo: 0485. Programación Departamento de Familia Profesional de Informática Curso: 2014-15

Más detalles

Contenidos. Parte I - Introducción Capítulo 1 - Evolución. Capítulo 2 Condiciones de trabajo en el Desarrollo de Software

Contenidos. Parte I - Introducción Capítulo 1 - Evolución. Capítulo 2 Condiciones de trabajo en el Desarrollo de Software IX Contenidos Prólogo... XIX Prefacio... XXI Guía de lectura...xxiii Parte I - Introducción Capítulo 1 - Evolución 1.1 Introducción... 2 1.2 Los hitos en la evolución histórica del desarrollo de software...

Más detalles

Desarrollo y comercialización de productos de software [El proceso unificado]

Desarrollo y comercialización de productos de software [El proceso unificado] Desarrollo y comercialización de productos de software [El proceso unificado] M. en C. Sergio Luis Pérez Pérez UAM CUAJIMALPA, MÉXICO, D. F. Trimestre 13-P Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo

Más detalles

Simulador de Protocolos de Red a tráves de WEB

Simulador de Protocolos de Red a tráves de WEB Simulador de Protocolos de Red a tráves de WEB Propuesta de Estudio 20071608 Director Ing. Francisco Antonio Polanco Montelongo Resumen Introducción Actualmente, el desarrollo tecnológico a alcanzado niveles

Más detalles

Anexo 4 Documento de Arquitectura

Anexo 4 Documento de Arquitectura Anexo 4 Documento de Arquitectura 1. Introducción El anexo se describe el propósito y alcance referentes al proyecto correspondiente al documento de arquitectura. 2. Propósito El propósito del anexo de

Más detalles

La Necesidad de Modelar. Diseño de Software Avanzado Departamento de Informática

La Necesidad de Modelar. Diseño de Software Avanzado Departamento de Informática La Necesidad de Modelar Analogía Arquitectónica Tiene sentido poner ladrillos sin hacer antes los planos? El modelo, los planos, ayuda a afrontar la complejidad del proyecto. Cuál es el lenguaje adecuado

Más detalles

Especificación de Requisitos del Sistema de Registro y Control de Bienes Muebles de la ULA (ULA_SRCBM, versión 1.0)

Especificación de Requisitos del Sistema de Registro y Control de Bienes Muebles de la ULA (ULA_SRCBM, versión 1.0) Proyecto: Actualización del Sistema de Información de Muebles Documento: Especificación de s del Sistema de Registro y Control de Muebles ULA (ULA_SRCBM, versión 1.0) Elaborado por: William J. Montilva

Más detalles

DESARROLLO DE SOFTWARE EMPRESARIAL. Jonás Montilva C. Judith Barrios A. Universidad de Los Andes

DESARROLLO DE SOFTWARE EMPRESARIAL. Jonás Montilva C. Judith Barrios A. Universidad de Los Andes DESARROLLO DE SOFTWARE EMPRESARIAL Jonás Montilva C. Judith Barrios A. Universidad de Los Andes Desarrollo de Software Empresarial Derechos Reservados. Ninguna parte de este documento puede ser reproducida,

Más detalles

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 17 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 5 Situación RD 1201/2007 Actualización Competencia

Más detalles

Ingeniería de Software: Parte 2

Ingeniería de Software: Parte 2 Ingeniería de Software: Parte 2 Agustín J. González ElO329: Diseño y Programación Orientados a Objeto Adaptado de: http://www.dsic.upv.es/~uml http://inst.eecs.berkeley.edu/~cs169/ entre otras fuentes.

Más detalles

IWG-101: Introducción a la Ingeniería. Departamento de Informática, UTFSM 1

IWG-101: Introducción a la Ingeniería. Departamento de Informática, UTFSM 1 IWG-101: Introducción a la Ingeniería Departamento de Informática, UTFSM 1 Introducción a UML Historia Potencialidades Diagramas soportados UML en el proceso de desarrollo de SW. Introducción a UML Necesidad

Más detalles

Gestión de. Requisitos previos. Carácter ECTS. Periodo NINGUNOO. Idiomas en Inglés. Departamento. Ciencias de. Presentación. Despacho y.

Gestión de. Requisitos previos. Carácter ECTS. Periodo NINGUNOO. Idiomas en Inglés. Departamento. Ciencias de. Presentación. Despacho y. = =drð^=al`bkqb qfqri^`flkbp=ab=do^al= TITULACIÓN: INGENIERÍA DE SISTEMAS DE INFORMACIÓN CURSO: Segundo ASIGNATURA: Ingeniería del Software I Nombre del Módulo o Materia al que pertenece la asignatura.

Más detalles

Bienvenidos a la presentación: Introducción a conceptos básicos de programación.

Bienvenidos a la presentación: Introducción a conceptos básicos de programación. Bienvenidos a la presentación: Introducción a conceptos básicos de programación. 1 Los programas de computadora son una serie de instrucciones que le dicen a una computadora qué hacer exactamente. Los

Más detalles

Programación Orientada a Objetos Profr. Pedro Pablo Mayorga

Programación Orientada a Objetos Profr. Pedro Pablo Mayorga Actividad 2 Unidad 1 Ciclo de vida del software y Diseño Orientado a Objetos Ciclo de Vida del Software Un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto

Más detalles

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 6. Actualización

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 6. Actualización Página 1 de 19 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 6 Situación Contraste externo Actualización

Más detalles

Desarrollo de software

Desarrollo de software Agenda 1. Introducción 2. Aspectos Metodológicos del Desarrollo de Software 3. Aplicación Web (Modelo del Producto) 4. Modelo del proceso 5. Dos enfoques Metodológicos 6. Métodos Seleccionados 7. Evaluación

Más detalles

GLOSARIO. Arquitectura: Funcionamiento, estructura y diseño de una plataforma de desarrollo.

GLOSARIO. Arquitectura: Funcionamiento, estructura y diseño de una plataforma de desarrollo. GLOSARIO Actor: Un actor es un usuario del sistema. Esto incluye usuarios humanos y otros sistemas computacionales. Un actor usa un Caso de Uso para ejecutar una porción de trabajo de valor para el negocio.

Más detalles

JAVA EE 5. Arquitectura, conceptos y ejemplos.

JAVA EE 5. Arquitectura, conceptos y ejemplos. JAVA EE 5. Arquitectura, conceptos y ejemplos. INTRODUCCIÓN. MODELO DE LA APLICACIÓN JEE5. El modelo de aplicación Java EE define una arquitectura para implementar servicios como lo hacen las aplicaciones

Más detalles

DISEÑO DE COMPONENTES DE SOFTWARE *

DISEÑO DE COMPONENTES DE SOFTWARE * DISEÑO DE COMPONENTES DE SOFTWARE * NOTAS DEL CURSO Ingeniería de Software I DRA. MARIA DEL PILAR GÓMEZ GIL INAOEP * Resumen del capítulo 10 de libro de [Pressman 2010] V:18-11-2008 (c) P. Gomez-Gil, INAOE.

Más detalles

DIPLOMADO EN TECNOLOGÍAS DE LA INFORMACIÓN

DIPLOMADO EN TECNOLOGÍAS DE LA INFORMACIÓN DIPLOMADO EN TECNOLOGÍAS DE LA INFORMACIÓN MODULO I: Análisis y Diseño de Sistemas El alumno se familiarizará y describirá los conceptos y aspectos fundamentales del Análisis y Diseño Orientado a Objetos

Más detalles

SUPLEMENTO EUROPASS AL TÍTULO

SUPLEMENTO EUROPASS AL TÍTULO SUPLEMENTO EUROPASS AL TÍTULO DENOMINACIÓN DEL TÍTULO Técnico Superior en Desarrollo de Aplicaciones Web --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Más detalles

TEMA 1.-Programación orientada a objetos (POO) Objetivo

TEMA 1.-Programación orientada a objetos (POO) Objetivo CURSO DE UML Dotar al alumno de los fundamentos de la programación orientada a objetos (POO, a partir de ahora), definir las características básicas del lenguaje de modelado unificado (Unified Modeling

Más detalles

Tema 3. 3.3 Tecnologías de Desarrollo

Tema 3. 3.3 Tecnologías de Desarrollo Tema 3 3.3 Tecnologías de Desarrollo HTML pronto pasa a ser insuficiente para todas las posibilidades de la Red No se puede interactuar con el servidor Aparecen los primeros scripts para propocionar dichar

Más detalles

CAPÍTULO 1. MARCO TEÓRICO

CAPÍTULO 1. MARCO TEÓRICO CAPÍTULO 1. MARCO TEÓRICO Capítulo 1. Marco teórico 1.1 Ingeniería Web (IWeb) Con el desarrollo de Internet, la mayoría de los proyectos y sistemas están enfocados para las aplicaciones basadas en la Web

Más detalles

CAPÍTULO V. Propuesta

CAPÍTULO V. Propuesta CAPÍTULO V Propuesta 5.1 Propuesta Implantación de una aplicación WEB para optimizar el Enlace Laboral de la Cámara de Comercio e Industria de El Salvador, Filial San Miguel 5.2 Requerimientos de la Aplicación

Más detalles

Javier Velásquez Maldonado velasquezj7@hotmail.com. Jhoanna Isabel Lansinot Tocain jlansinot@yahoo.com

Javier Velásquez Maldonado velasquezj7@hotmail.com. Jhoanna Isabel Lansinot Tocain jlansinot@yahoo.com DISEÑO, DESARROLLO E IMPLANTACIÓN DE UNA APLICACIÓN WEB PARA LA AUTOMATIZACIÓN DE LA INFORMACIÓN DE LA IGLESIA EVANGÉLICA INDÍGENA ECUATORIANA DE LA ALIANZA CRISTIANA Y MISIONERA. Javier Velásquez Maldonado

Más detalles

El Proceso Unificado

El Proceso Unificado El Proceso Unificado de Desarrollo de Software Prof. Gustavo J. Sabio Alcance de la presentación QA Entradas Proceso de desarrollo Salida equipo Cliente sistemas Cliente necesidades actividades varias

Más detalles

APROBACIÓN DEL TUTOR

APROBACIÓN DEL TUTOR APROBACIÓN DEL TUTOR En mi calidad de tutor del trabajo de investigación sobre el tema: Portal Web usando software libre con conexión a Base de Datos para consultas de pagos de servicios municipales en

Más detalles

Trabajo Final de Graduación para optar por el título. Bachiller en Ingeniería en Computación

Trabajo Final de Graduación para optar por el título. Bachiller en Ingeniería en Computación Trabajo Final de Graduación para optar por el título Bachiller en Ingeniería en Computación Migración del Módulo de Inventario del Sistema Business Advance Víctor Guzmán Alfaro Carrera Ingeniería en Computación

Más detalles

1 GLOSARIO. Actor: Es un consumidor (usa) del servicio (persona, sistema o servicio).

1 GLOSARIO. Actor: Es un consumidor (usa) del servicio (persona, sistema o servicio). 1 GLOSARIO A continuación se definen, en orden alfabético, los conceptos básicos que se han abordado a lo largo del desarrollo de la metodología para la gestión de requisitos bajo la Arquitectura Orientada

Más detalles

Ingeniería del Software. Diseño. Diseño en el PUD. Diseño de software. Patrones arquitectónicos. Diseño Orientado a Objetos en UML

Ingeniería del Software. Diseño. Diseño en el PUD. Diseño de software. Patrones arquitectónicos. Diseño Orientado a Objetos en UML Diseño Diseño en el PUD Diseño de software Patrones arquitectónicos Diseño Orientado a Objetos en UML 1 Iteración en PUD Planificación de la Iteración Captura de requisitos: Modelo de casos de uso, Modelo

Más detalles

Antes de imprimir este documento piense en el medio ambiente!

Antes de imprimir este documento piense en el medio ambiente! Versión 1.0 Página 1 de 14 1. OBJETIVO: Suministrar la metodología que se aplicará para la estimación de esfuerzo para los desarrollos nuevos en el ICBF, para lo cual se detallan los aspectos a tener en

Más detalles

Facultad de Ingeniería Informática. Informe de las Prácticas Profesionales

Facultad de Ingeniería Informática. Informe de las Prácticas Profesionales Facultad de Ingeniería Informática CEIS Informe de las Prácticas Profesionales Título: Informatización de los Procesos de Negocio Solicitud de Trabajo Extra laboral en el CITI, a través de la BPMS BizAgi

Más detalles

DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL

DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL Página 1 de 21 CUALIFICACIÓN DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC154_3 Versión 5 Situación RD 1087/2005 Actualización

Más detalles

MODELADO DE OBJETOS DE DATOS

MODELADO DE OBJETOS DE DATOS Manual Página Web MODELADO DE OBJETOS DE DATOS MANUALES ESPECIALES Documento: Manual Páginas Web (SemanticWebBuilder). Fecha de Elaboración: Marzo de 2009. INFOTEC CONACYT FIDEICOMISO. Página i Glosario

Más detalles

Modulo I. Introducción a la Programación Web. 1.1 Servidor Web.

Modulo I. Introducción a la Programación Web. 1.1 Servidor Web. Modulo I. Introducción a la Programación Web. 1.1 Servidor Web. Antes de analizar lo que es un servidor Web y llevara a cabo su instalación, es muy importante identificar diferentes elementos involucrados

Más detalles

DESARROLLO DE COMPONENTES PARA LA INTEGRACIÓN DEL PORTAL CORPORATIVO DEL CITI CON LA BPMS BIZAGI

DESARROLLO DE COMPONENTES PARA LA INTEGRACIÓN DEL PORTAL CORPORATIVO DEL CITI CON LA BPMS BIZAGI DESARROLLO DE COMPONENTES PARA LA INTEGRACIÓN DEL PORTAL CORPORATIVO DEL CITI CON LA BPMS BIZAGI Informe de Práctica Profesional de 4to Año, Ingeniería Informática Autor: Manuel Alejandro Aguilar Díaz

Más detalles

Capítulo I. Marco Teórico

Capítulo I. Marco Teórico 1 Capítulo I. Marco Teórico 1. Justificación Hoy en día existe una gran diversidad de aplicaciones que corren sobre la World Wide Web (WWW o Web), y cada una orientada a un fin en particular, el cuál depende

Más detalles

Visión General GXflow. Última actualización: 2009

Visión General GXflow. Última actualización: 2009 Última actualización: 2009 Copyright Artech Consultores S. R. L. 1988-2009. Todos los derechos reservados. Este documento no puede ser reproducido en cualquier medio sin el consentimiento explícito de

Más detalles

Entidad Formadora: Plan Local De Formación Convocatoria 2010

Entidad Formadora: Plan Local De Formación Convocatoria 2010 Entidad Formadora: Enterprise Architect Comenzando Puede iniciar Enterprise Architect desde el ícono que se creó en su escritorio de Windows durante la instalación, o alternativamente: 1. Abrir el menú

Más detalles

ASI. Análisis del Sistema de Información

ASI. Análisis del Sistema de Información ASI Análisis del Sistema de Información 1 ASI Análisis del Sistema de Información Introducción Objetivo Obtención de una especificación detallada del Sistema Información a través de: Catálogo de Requisitos

Más detalles

Capítulo III. Análisis y diseño.

Capítulo III. Análisis y diseño. Capítulo III. Análisis y diseño. 3.1 Análisis. El análisis es el intermediario entre los requisitos del sistema y el diseño, esta sección definiremos el análisis con una serie de modelos técnicos del sistema,

Más detalles

BOLETÍN DE NOVEDADES Barcelona, junio de 2008

BOLETÍN DE NOVEDADES Barcelona, junio de 2008 BOLETÍN DE NOVEDADES Barcelona, junio de 2008 Introducción El objeto de este documento es presentar y describir brevemente las principales actuaciones en los últimos meses de Carver en algunos de sus clientes,

Más detalles

"Módulo OOWS para StarUML" INTRODUCCIÓN

Módulo OOWS para StarUML INTRODUCCIÓN UNA HERRAMIENTA PARA DIAGRAMAS OOWS: "Módulo OOWS para StarUML" Richard Medina Z. Universidad de Concepción, Chile INTRODUCCIÓN Una herramienta CASE (Computer Aided Software Engineering,

Más detalles

CAPÍTULO V PROPUESTA DE LA SOLUCIÓN

CAPÍTULO V PROPUESTA DE LA SOLUCIÓN CAPÍTULO V PROPUESTA DE LA SOLUCIÓN 5.1 Introducción En los últimos tres años la entidad financiera ha venido sufriendo cambios que le han permitido crecer y pasar de ser una Sociedad Financiera a un Banco

Más detalles

Boletín de Asesoría Gerencial* Arquitectura orientada a servicios (SOA)

Boletín de Asesoría Gerencial* Arquitectura orientada a servicios (SOA) Espiñeira, Sheldon y Asociados * No. 12-2009 *connectedthinking Haga click en los enlaces para navegar a través del documento Haga click en los enlaces para llegar directamente a cada sección 4 Introducción

Más detalles

Analista Programador PL/SQL Oracle 11g

Analista Programador PL/SQL Oracle 11g TITULACIÓN DE FORMACIÓN CONTINUA BONIFICADA EXPEDIDA POR EL INSTITUTO EUROPEO DE ESTUDIOS EMPRESARIALES Analista Programador PL/SQL Oracle 11g Duración: 360 horas Precio: 0 * Modalidad: Online * hasta

Más detalles

PROYECTO DE INGENIERIA DE SISTEMAS I

PROYECTO DE INGENIERIA DE SISTEMAS I PROYECTO DE INGENIERIA DE SISTEMAS I PROFESOR: CHAVEZ FARFAN, Pedro Enrique VIII CICLO - PROCOU 2012-I INTEGRANTES: LUIS MIGUEL VARGAS TAMAYO - 0831226 NOMBRE DE PROYECTO: FACULTAD: SISTEMA INTEGRADO DE

Más detalles

IBM Rational Statemate ayuda a los ingenieros de sistemas a enfrentarse a los retos del mercado de sistemas integrados complejos

IBM Rational Statemate ayuda a los ingenieros de sistemas a enfrentarse a los retos del mercado de sistemas integrados complejos ZP09-0207, con fecha 2 de junio de 2009 IBM Rational Statemate ayuda a los ingenieros de sistemas a enfrentarse a los retos del mercado de sistemas integrados complejos Índice 1 Resumen de características

Más detalles

CAPÍTULO 5. DESARROLLO Y PRUEBAS

CAPÍTULO 5. DESARROLLO Y PRUEBAS CAPÍTULO 5. DESARROLLO Y PRUEBAS 5.1 Introducción a las Tecnologías 5.1.1 Herramientas 5.1.1.1 SQL Server Es un sistema que sirve para la gestión de base de datos basado en un modelo relacional. Así mismo

Más detalles

INSTITUTO DE EDUCACIÓN SUPERIOR TECNOLÓGICO IBEROTEC SEMESTRE ACADÉMICO: 2014-II SÍLABO UNIDAD DIDÁCTICA : ANÁLISIS Y DISEÑO DE SISTEMAS INFORMÁTICOS

INSTITUTO DE EDUCACIÓN SUPERIOR TECNOLÓGICO IBEROTEC SEMESTRE ACADÉMICO: 2014-II SÍLABO UNIDAD DIDÁCTICA : ANÁLISIS Y DISEÑO DE SISTEMAS INFORMÁTICOS INSTITUTO DE EDUCACIÓN SUPERIOR TECNOLÓGICO IBEROTEC SEMESTRE ACADÉMICO: 201-II 1. DATOS GENERALES SÍLABO UNIDAD DIDÁCTICA : ANÁLISIS Y DISEÑO DE SISTEMAS INFORMÁTICOS MÓDULO : DESARROLLO DE SOFTWARE TIPO

Más detalles

Desarrollo de Aplicaciones con Tecnologías Web (Online) (Dirigida a la Acreditación de las Competencias Profesionales R.D.

Desarrollo de Aplicaciones con Tecnologías Web (Online) (Dirigida a la Acreditación de las Competencias Profesionales R.D. Desarrollo de Aplicaciones con Tecnologías Web (Online) (Dirigida a la Acreditación de las Competencias Profesionales R.D. 1224/2009) Titulación certificada por EUROINNOVA BUSINESS SCHOOL Desarrollo de

Más detalles

Estructura de clases. Estructura de Objetos. Arquitectura de módulos. Arquitectura de procesos

Estructura de clases. Estructura de Objetos. Arquitectura de módulos. Arquitectura de procesos 3.3 EL MÉTODO DE BOOCH. 3.3. Introducción. El método cuenta con una notación expresiva y bien definida que le permite al diseñador comunicar sus ideas y concentrarse en problemas más serios. Para la captura

Más detalles

Ingeniería de Software

Ingeniería de Software Ingeniería de Software Tabla de Contenidos PARTE I INTRODUCCIÓN Capítulo 1: Evolución Los hitos en la evolución histórica del Desarrollo de Software Problemas y soluciones... Fallas, malas estimaciones

Más detalles

RUP. Rational Unified Process

RUP. Rational Unified Process RUP Rational Unified Process Rational Unified Process Basado en 6 mejores prácticas de la industria de software: Desarrollo incremental Administración de requisitos Uso de arquitecturas basadas en componentes

Más detalles

PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA. Plan de Pruebas. File: 20130211-QA-INF-V2-PLAN DE PRUEBAS.odt STD-INF-GENERAL Versión: 1.

PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA. Plan de Pruebas. File: 20130211-QA-INF-V2-PLAN DE PRUEBAS.odt STD-INF-GENERAL Versión: 1. Cliente: FCM-UNA Página 1 de 14 PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA Cliente: FCM-UNA Página 2 de 14 Tabla de contenido 1. INTRODUCCIÓN 1.1. PROPÓSITO 1.2. ALCANCE 1.3. DEFINICIONES, ACRÓNIMOS

Más detalles

Universidad acional Experimental Del Táchira Decanato de Docencia Departamento de Ingeniería en Informática

Universidad acional Experimental Del Táchira Decanato de Docencia Departamento de Ingeniería en Informática Universidad acional Experimental Del Táchira Decanato de Docencia Departamento de Ingeniería en Informática Metodología Evolutiva Incremental Mediante Prototipo y Técnicas Orientada a Objeto (MEI/P-OO)

Más detalles

Aplicaciones Web a tu medida!

Aplicaciones Web a tu medida! Nota aclaratoria: El presente documento se realizó tomando como base el documento titulado Ingeniería de Requisitos en Aplicaciones para la Web Un estudio comparativo escrito por María José Escalona (Universidad

Más detalles

Ciclo Formativo de Grado Superior Desarrollo de Aplicaciones Web

Ciclo Formativo de Grado Superior Desarrollo de Aplicaciones Web Ciclo Formativo de Grado Superior Desarrollo de Aplicaciones Web Proyecto Propio de Ampliación con Programación de Dispositivos Móviles e Inteligentes Paseo de la Puerta del Ángel, s/n 28011 Madrid www.iesellago.net

Más detalles