REINGENIERÍA DEL SISTEMA DE RESERVAS INMEDIATAS DE VENEZUELATUYA.COM: APLICACIONES WEB Y MÓVIL

Transcripción

1 UNIVERSIDAD SIMÓN BOLÍVAR DECANATO DE ESTUDIOS PROFESIONALES COORDINACIÓN DE INGENIERÍA DE LA COMPUTACIÓN REINGENIERÍA DEL SISTEMA DE RESERVAS INMEDIATAS DE VENEZUELATUYA.COM: APLICACIONES WEB Y MÓVIL Por: David Antunes Jiménez INFORME DE PASANTÍA Presentado ante la Ilustre Universidad Simón Bolívar como requisito parcial para optar al título de Ingeniero en Computación Sartenejas, Abril de 2011

2 UNIVERSIDAD SIMÓN BOLÍVAR DECANATO DE ESTUDIOS PROFESIONALES COORDINACIÓN DE INGENIERÍA DE LA COMPUTACIÓN REINGENIERÍA DEL SISTEMA DE RESERVAS INMEDIATAS DE VENEZUELATUYA.COM: APLICACIONES WEB Y MÓVIL Por: David Antunes Jiménez Realizado con la asesoría de: Tutor Académico: Kenyer Domínguez Tutor Industrial: Hernán Rosas INFORME DE PASANTÍA Presentado ante la Ilustre Universidad Simón Bolívar como requisito parcial para optar al título de Ingeniero en Computación Sartenejas, Abril de 2011

3

4 REINGENIERÍA DEL SISTEMA DE RESERVAS INMEDIATAS DE VENEZUELATUYA.COM: APLICACIONES WEB Y MÓVIL Por: David Antunes Jiménez RESUMEN El presente documento abarca los procesos de reingeniería y subsecuentes procesos de análisis, diseño e implementación de una versión mejorada del Sistema de Reservaciones Inmediatas, producto de la empresa creado con la finalidad de aportar a la comunidad hotelera de Venezuela una herramienta con la que los dueños de hoteles y posadas podrán administrar sus establecimientos y agilizar sus procesos de negocio. Durante el proyecto se llevó a cabo un análisis del Sistema de Reservaciones Inmediatas existente (basado en tecnología web), aplicando métodos y técnicas de reingeniería. Este proceso permitió el diseño y construcción de un producto con una arquitectura de alta calidad que sirvió de base para el desarrollo de una versión móvil del sistema. El proyecto se llevó a cabo con éxito obteniéndose como resultado un sistema con altos rangos de calidad y con un alto grado de mantenibilidad. Para diseñar la arquitectura se usó la metodología del Proceso Unificado de Rational (RUP) y se utilizó el framework de desarrollo Zend Framework para PHP, el cual implementa el patrón de diseño Modelo Vista Controlador (MVC) que permitió separar las capas de negocio, presentación y acceso a datos del software. De igual manera, se obtuvieron logros adicionales: el éxito del proyecto hizo considerar la implantación de la filosofía de Zend Framework dentro de la empresa para los proyectos futuros; se implantaron los estándares de desarrollo móvil para los proyectos venideros; y se inició el diseño y desarrollo de un nuevo proyecto bajo Zend Framework: VenezuelaTuya Móvil, llevándose a cabo el módulo de hoteles y dejando las bases para los módulos restantes. iv

5 DEDICATORIA Al amor de mi vida, Iranid, que me da la luz que necesito para vivir A mis padres, Milena y Eurico, por permitirme llegar hasta aquí v

6 AGRADECIMIENTOS A mi novia Iranid, que me regocija de amor a cada instante. Gracias por darme fuerzas todos los días y ser siempre la fuente de inspiración para todas las cosas que hago. A mi amiga Silma, co-fundadora y miembro activo del coffee team (al cual tengo el gusto de pertenecer), por su inquebrantable amistad y por aquellos momentos de alegría que compartimos y seguimos compartiendo. A mis padres, Milena y Eurico, por el apoyo incondicional que me han dado en todo lo que me he propuesto. Sin ustedes no habría alcanzado esta meta. A mi tutor académico, ingeniero y profesor Kenyer Domínguez, por su aceptación, su valioso tiempo, su paciencia y, especialmente, por su constancia, profesionalismo y apoyo académico que permitieron alcanzar de buena forma los objetivos de este proyecto. A mi tutor industrial y actual jefe, ingeniero Hernán Rosas, por su carisma, dedicación, y apoyo incondicional que me ha brindado desde el principio. Gracias por confiar en mí y por la doble oportunidad que me has dado. vi

7 ÍNDICE GENERAL RESUMEN iv ÍNDICE GENERAL vii ÍNDICE DE TABLAS x ÍNDICE DE FIGURAS xi LISTA DE ABREVIATURAS xii INTRODUCCIÓN Planteamiento del problema Objetivo General Objetivos Específicos Alcance Justificación e Importancia CAPÍTULO 1 ENTORNO EMPRESARIAL Descripción General Misión Visión Estructura Organizacional Ubicación del Pasante CAPÍTULO 2 MARCO TEÓRICO Reingeniería de Software Reutilización de Software Modelo Vista Controlador Zend Framework Net2Client Software como Servicio CAPÍTULO 3 MARCO METODOLÓGICO Descripción de la Metodología Características, buenas prácticas y metas de RUP Estructura de RUP Estructura dinámica vii

8 3.5 Estructura estática Aplicación para el proyecto de pasantía.. 25 CAPÍTULO 4 DESARROLLO Fase de Inicio Plan del Proyecto Visión del sistema y alcance del proyecto Stakeholders Usuarios Necesidades de los Stakeholders y Usuarios Perspectiva y beneficios del sistema Características y rangos de calidad Restricciones de diseño e implementación Herramientas de desarrollo Arquitectura del sistema en su versión previa al proyecto Fase de Elaboración Primera Iteración Plan del Proyecto Técnicas de reingeniería y reutilización de software Arquitectura del sistema en su versión previa al proyecto Segunda Iteración Plan del Proyecto Arquitectura del sistema en su nueva versión Fase de Construcción Primera Iteración Segunda Iteración Tercera Iteración Cuarta Iteración Fase de Transición CAPÍTULO 5 LOGROS ADICIONALES CONCLUSIONES Y RECOMENDACIONES REFERENCIAS viii

9 APÉNDICES Apéndice A: Glosario de Términos Apéndice B: Documento de Visión Apéndice C: Especificaciones de Requerimientos del Software Apéndice D: Documento de Arquitectura del Software Apéndice E: Herramientas de Desarrollo ix

10 ÍNDICE DE TABLAS Tabla 4.1. Plan del proyecto - Fase de Inicio Tabla 4.2. Descripción de los Stakeholders del sistema Tabla 4.3. Descripción de los Usuarios del sistema.. 29 Tabla 4.4. Necesidades de los Stakeholders y Usuarios Tabla 4.5. Descripción de los beneficios del sistema 31 Tabla 4.6. Características del sistema Tabla 4.7. Rangos de calidad del sistema Tabla 4.8. Plan del proyecto - Fase de Elaboración (Primera Iteración) Tabla 4.9. Plan del proyecto - Fase de Elaboración (Segunda Iteración). 43 x

11 ÍNDICE DE FIGURAS Figura 1.1. Estructura Organizacional de... 8 Figura 2.1. Representación gráfica del patrón Modelo Vista Controlador Figura 3.1. Estructura del proceso de RUP Figura 4.1. Diagrama de clases del sistema en la versión previa al proyecto de pasantía Figura 4.2. Diagrama de componentes del sistema en la versión previa al proyecto de pasantía 40 Figura 4.3. Diagrama de despliegue del sistema en la versión previa al proyecto de pasantía 41 Figura 4.4. Modelo Entidad-Relación del sistema en la versión previa al proyecto de pasantía 42 Figura 4.5. Modelo final de casos de uso para la nueva arquitectura del sistema 45 Figura 4.6. Diagrama de clases de la nueva arquitectura del sistema Figura 4.7. Diagrama de componentes de la nueva arquitectura del sistema Figura 4.8. Pruebas de estrés sobre el ambiente de desarrollo usando Sellenium IDE Figura 4.9. Pruebas de estrés sobre el ambiente de producción usando Sellenium IDE xi

12 LISTA DE ABREVIATURAS ASP CASE CRM CSS DAS EA ER ERS GWT HTML IDE KISS LAMP MVC N2C PDF PHP RUP SAAS SQL SRI SSH UML USB VT ZF Application Service Provider (Proveedor de Servicios de Aplicación) Computer Aided Software Engineering (Ingeniería de Software Asistida por Computadora) Customer Relationship Managament Cascading Style Sheets (Hojas de Estilo en Cascada) Documento de Arquitectura del Software Enterprise Architect Entidad Relación Especificaciones de Requerimientos del Software HyperText Markup Language (Lenguaje de Marcado de HiperTexto) Integrated Development Enviroment (Entorno de Desarrollo Integrado) Keep It Short and Simple (Manténgalo corto y simple) Linux-Apache-MySQL-PHP Modelo Vista Controlador Net2Client Portable Document Format Hypertext Preprocessor Rational Unified Process (Proceso Unificado de Rational) Software As A Service (Software como Servicio) Structured Query Language (Lenguaje de Consulta Estructurado) Sistema de Reservaciones Inmediatas Secure Shell (Intérprete de Órdenes Segura) Unified Model Language (Lenguaje Unificado de Modelado) Universidad Simón Bolívar VenezuelaTuya Zend Framework xii

13 INTRODUCCIÓN En los últimos quince años, Venezuela se ha visto inmersa en una constante oleada tecnológica en el área de telefonía móvil. Los dispositivos celulares han pasado de ser simples objetos utilizados para realizar llamadas y enviar mensajes de texto, a herramientas inteligentes para comunicarse en tiempo real; almacenar y/o enviar contenidos multimedia; organizar agendas personales; entre otras aplicaciones. Este crecimiento acelerado de la tecnología móvil ha venido desplazando el uso de las computadoras personales por el uso de celulares inteligentes o smartphones. Cada día aumenta el número de personas que observan en la tecnología móvil múltiples ventajas que no pueden obtener con las computadoras de escritorio: encuentran un medio que les permite agilizar sus actividades cotidianas y mantenerse comunicado a cualquier parte que se desplacen sin tener que estar atados a una silla [1]., empresa dedicada al desarrollo de soluciones ebusiness mediante el uso de la tecnología web, en conjunto con VenezuelaTuya, agencia de viajes y turismo en Venezuela posicionada en Internet, han llevado a cabo estudios que demuestran que dentro de la comunidad turística de Venezuela son muchos los hoteles y posadas que poseen una cobertura limitada a Internet y sus dueños en reemplazo utilizan sus dispositivos móviles para comunicarse y gestionar sus establecimientos. Además de esto, algunos de ellos no cuentan con herramientas que les permitan administrar sus negocios de manera eficiente. En vista de esta situación se desarrolló el presente proyecto para llevar a cabo la construcción del Sistema de Reservaciones Inmediatas Móvil, un producto de tecnología web para dispositivos móviles que les permitirá a los hoteleros y posaderos llevar a cabo de manera rápida, sencilla y cómoda la administración de sus operaciones en sus celulares, a la vez que potencian sus negocios y maximizan sus ventas. El presente documento muestra cómo fue llevado a cabo el análisis y construcción del sistema. En primer lugar se expone la introducción que abarca el planteamiento del problema y la definición del proyecto. Posteriormente el documento se estructura de la siguiente forma: el capítulo 1 describe el entorno empresarial donde se realizó el proyecto de pasantía; el capítulo 2 engloba el marco teórico sobre el cual se basaron las soluciones al problema; el capítulo 3 señala la metodología que fue seguida para desarrollar el sistema; el capítulo 4 describe cómo fue el

14 2 proceso de implementación; el capítulo 5 expone los logros adicionales conseguidos. Por último, se mencionan las conclusiones obtenidas una vez culminado el proyecto de pasantía y se sugieren una serie de recomendaciones para futuros desarrollos. A continuación se exponen las disposiciones y lineamientos generales que definen el proyecto de pasantía. Se describe el planteamiento del problema que involucra el proyecto; los objetivos; el alcance que abarca y la importancia de su desarrollo. Planteamiento del Problema A pesar del auge tecnológico que está viviendo Venezuela en los últimos años, son muchas las regiones de la nación que aún no disfrutan de las bondades que ofrece la red de redes o Internet [1]. Según (GWT), en el entorno hotelero de Venezuela son muchos los posaderos y hoteleros que debido a limitaciones de acceso a Internet, recurren a la tecnología móvil para conectarse a la misma y realizar la mayoría de las tareas que llevan a cabo en sus computadoras de escritorio a través de sus dispositivos móviles, además de usarlos para administrar su establecimiento sin necesidad de estar presente en el mismo [1]. Esto se explica debido a que muchos establecimientos se encuentran ubicados en zonas retiradas que poseen acceso limitado o poco fiable a Internet. En el peor de los casos, no poseen cobertura alguna. Esta situación priva a los dueños de los hoteles y posadas la posibilidad de utilizar los servicios que ofrece la Internet para automatizar los procesos de sus negocios, además de limitar las formas de comunicación a las que se está acostumbrado y que son necesarias hoy en día. De igual forma, GWT establece que no existe actualmente en Venezuela ningún servicio o aplicación para tecnología móvil que permita automatizar los procesos de negocio concernientes a los hoteles y posadas [1]. Para ayudar a los hoteleros y posaderos en la tarea de administrar sus establecimientos, GWT desarrolló inicialmente el Sistema de Reservaciones Inmediatas (SRI), el cual fue desarrollado bajo tecnología web para computadoras de escritorio. Comprende dos (2) secciones:

15 3 la primera orientada a los hoteleros, donde éstos pueden administrar sus establecimientos y reservaciones de forma privada; y la segunda dedicada a los clientes o huéspedes en la cual pueden realizar reservaciones en sus hoteles o posadas de preferencia. Sin embargo, dicho sistema no fue diseñado bajo un esquema de abstracción por capas, por lo que contiene la lógica de negocio y las rutinas de acceso a datos fuertemente ligadas con la capa de presentación visual. Dentro de la empresa este inconveniente genera un alto nivel de dificultad a la hora de realizar mantenimiento o implementar nuevas funcionalidades. En vista de la creciente demanda de uso de dispositivos móviles por parte de los hoteleros y posaderos, y tomando en cuenta la situación del SRI en su versión previa a esta pasantía, se decidió realizar una reingeniería del mismo, considerando el patrón de diseño Modelo Vista Controlador (MVC), que permita diseñar y construir una arquitectura de alta calidad que garantice la reestructuración del código fuente y facilite la mantenibilidad del sistema para futuros desarrollos. Una vez finalizado este proceso, el nuevo sistema servirá de base para llevar a cabo el desarrollo de una versión móvil que será denominada Sistema de Reservaciones Inmediatas Móvil o SRI Móvil, con miras a expandir el servicio ofrecido por el SRI y satisfacer la demanda previamente descrita. Objetivo General Diseñar y desarrollar una versión del SRI orientada a tecnología web móvil. Objetivos Específicos - Rediseñar la versión web orientada a computadoras de escritorio empleando técnicas de reingeniería y utilizando el patrón de diseño MVC.

16 4 - Implementar el SRI de acuerdo a su nuevo diseño utilizando tecnologías y técnicas de desarrollo web de última generación y probar su correcto funcionamiento. - Diseñar, desarrollar y probar una versión web móvil para el SRI, tomando en cuenta el nuevo diseño obtenido como consecuencia del proceso de reingeniería sobre su versión web orientada a computadoras de escritorio. Alcance Durante las etapas de levantamiento de información y análisis del problema, fueron establecidas algunas prioridades respecto al proceso de reingeniería e implementación del sistema. Debido a la complejidad del SRI, el proyecto de pasantía sólo abarcará la reingeniería e implementación de la sección orientada a los hoteleros y posaderos en las dos versiones mencionadas anteriormente. Específicamente, se llevarán a cabo dichas actividades sobre los módulos de visualización de las situaciones de reservaciones y ocupación; administración de cupos y los reportes de reservaciones y ocupación. Sin embargo, es importante mencionar que durante el proceso de reingeniería planificado se especificarán los lineamientos y la visión que definirán la sección orientada a los huéspedes que será desarrollada en futuras iteraciones del sistema. Justificación e Importancia El desarrollo del presente proyecto beneficiará en gran medida tanto a la comunidad hotelera venezolana como a la empresa. Los dueños de hoteles y posadas del país podrán adquirir los servicios innovadores del SRI, producto que les permitirá automatizar las actividades que llevan día a día para administrar sus establecimientos y maximizar la productividad de los mismos. Además, con el desarrollo de la versión móvil podrán disfrutar de las mismas funcionalidades del sistema en su versión web de

17 5 escritorio y administrar su negocio sin importar el lugar donde se encuentren. Por otro lado, la implementación de la versión móvil del SRI permitirá a aumentar el número de sus clientes y maximizar sus ventas: la nueva versión facilitará la captación de nuevos clientes dueños de hoteles y/o posadas que no posean servicios fiables de Internet y que estén interesados en automatizar sus actividades cotidianas. De igual forma, la nueva implementación derivada del proceso de reingeniería involucrará la reestructuración del código fuente del sistema de acuerdo a estándares de calidad, que contribuirá a minimizar los tiempos de mantenimiento del mismo, en los casos que presente fallas o se desee anexar nuevas funcionalidades, lo que a su vez se traducirá en un aumento de la productividad del equipo de desarrollo.

18 CAPÍTULO 1 ENTORNO EMPRESARIAL Este capítulo tiene como propósito dar a conocer la empresa, en la cual fue desarrollado el proyecto de pasantía. Se expone brevemente la descripción de la empresa, la misión y visión que contemplan, su estructura organizacional y la ubicación del pasante dentro de la misma. 1.1 Descripción General (GWT) es una empresa venezolana desarrolladora de software que presta asesoría a empresas en la creación de estrategias efectivas de e-business con la finalidad de potenciar su manera de hacer negocios en internet [2]. La empresa surge en el año 2003 con el objetivo de crear tecnología de la información que ayude a las empresas a unirse con sus clientes. Cuenta actualmente con una amplia experticia en desarrollos de alta tecnología y en el área de consultoría, experiencia que le permite asesorar a sus clientes en el aprovechamiento de Internet para ayudarlos a crecer, potenciar su capital humano, vender más, optimizar procesos y reducir costos [2]. A lo largo de su trayectoria, GWT ha tenido una clientela diversa dentro y fuera del país, comprendiendo distintos sectores de negocio: bancos, hoteles, casas automotrices, asociaciones, turismo, entre otras. Entre las actividades que ha realizado para cada uno de sus clientes se encuentran la asesoría de estrategias web; análisis de usabilidad; desarrollo de portales, intranets y CRM (Customer Relationship Management); implementación de Google Apps y herramientas de colaboración; mercadeo web y gerencia de proyectos; entre otros [3].

19 7 1.2 Misión Nuestra misión comprende la creación de soluciones que permitan a los clientes mejorar y transformar sus relaciones con sus clientes y proveedores, a través de la tecnología de Internet [4]. 1.3 Visión Ser reconocidos como una de las empresas venezolanas, creadoras de software para Internet, más innovadoras y con proyección internacional, con profesionales altamente preparados, motivados, orientados al logro, y con clientes muy satisfechos [4]. 1.4 Estructura Organizacional La estructura organizacional de GWT se muestra en la Figura 1.1 y comprende varias dependencias que en conjunto permiten a la empresa el logro de sus objetivos. Dentro de éstas se encuentra la entidad de Gerencia de Proyectos, encargada de la coordinación de los proyectos que la empresa desarrolla y ha desarrollado. Tiene adscritas la Unidad de Diseño y la Unidad de Desarrollo. La primera está conformada por los diseñadores gráficos, los cuales se encargan del diseño de páginas web con altos estándares de usabilidad adaptadas a los requerimientos de clientes que deseen mejorar su rentabilidad y/o posicionamiento en la red. Por otro lado, se encuentra la Unidad de Desarrollo, conformada por analistas programadores y desarrolladores que se encargan de diseñar la arquitectura de los sistemas y realizar posteriormente su correcta implementación, con miras a satisfacer los requerimientos solicitados por los clientes.

20 8 Figura 1.1. Estructura Organizacional de [5]. 1.5 Ubicación del Pasante Durante el período de elaboración del proyecto, el pasante ocupó el cargo de Analista Programador, perteneciendo a la Unidad de Desarrollo de la empresa. El jefe inmediato fue el tutor industrial y Director General de la empresa, el Ingeniero Hernán Rosas.

21 CAPÍTULO 2 MARCO TEÓRICO En este capítulo se presentan los fundamentos, conceptos y términos que conforman la base teórica necesaria para comprender el proyecto. Dicha base teórica está conformada por el resultado de investigaciones realizadas sobre los procesos de reingeniería de software y reutilización de software; el patrón de diseño de software: Modelo Vista Controlador; el framework de desarrollo de software: Zend Framework; la herramienta de modelación de negocios: Net2Client; y, por último, el modelo de distribución de software: Software como Servicio. Para cada concepto se expone la importancia que representa dentro del desarrollo del proyecto para alcanzar los objetivos propuestos. 2.1 Reingeniería de Software Según Sommerville, la reingeniería de software es un proceso que tiene como finalidad la reimplementación de un sistema heredado para hacerlo más mantenible [6]. Por otra parte, Valarezo expone que la reingeniería de software involucra diferentes procedimientos que se realizan con la finalidad de crear versiones de programas ya existentes que sean de mejor calidad y tengan una mayor facilidad de mantenimiento [7]. De esta forma, se puede argumentar que la reingeniería de software es una práctica que permite tomar un producto o sistema desarrollado previamente, y mediante la puesta en práctica de ciertas técnicas y actividades recomendadas, conseguir el desarrollo de una nueva versión del producto que permita alargar su vida útil. Normalmente, la reingeniería permite que el software conserve su arquitectura y sus funcionalidades sigan siendo las mismas o sean mejoradas. Este proceso puede llevarse a cabo mediante el esquema de actividades propuesto por Valarezo, a saber [7]:

22 10 Reestructuración de código fuente: es el tipo de reingeniería más común. Conlleva el análisis y comprensión del código mediante la lectura o el uso de herramientas de reestructuración; se identifican las estructuras que facilitan la organización del código y se inicia el proceso; posteriormente el código se revisa y es probado para asegurar que no existan fallas; finalmente, se actualiza la documentación interna del código. Ingeniería inversa: es un proceso que consiste en analizar un software con la finalidad de identificar sus componentes e interacciones y construir una representación del sistema en un nivel de abstracción más alto que el código fuente. La ingeniería inversa es útil para recuperar el diseño de un sistema y regenerar su documentación (redocumentación). Reestructuración de datos: es una actividad en donde la arquitectura de datos actual se analiza para definir los modelos de datos de los cuales dependerá el sistema y determinar la calidad de su estructura. La reestructuración de datos solo se requiere si la estructura de datos cambia durante el proceso de reingeniería. Ingeniería directa: llamada también renovación o ingeniería para la reutilización, consiste en considerar el diseño y/o las funcionalidades del sistema existente para la reconstrucción de su futura versión, con la finalidad de optimizar la calidad del producto mediante el análisis y mejora de especificaciones que deben conservarse y son de gran importancia para el mismo. No siempre será necesario realizar todas las tareas previamente mencionadas; debe realizarse un análisis previo para decidir cuáles de ellas son suficientes para minimizar los costos invertidos en la operación de reingeniería [6]. Realizar reingeniería a un software permite alcanzar ciertos beneficios, como lo son [8]: Reducir los riesgos evolutivos de una organización. Puede ayudar a las organizaciones a recuperar sus inversiones en software. Mejorar la facilidad de mantenimiento y aumentar la productividad de los desarrolladores

23 en dicha actividad. Mejorar la documentación del sistema y forzar estándares sobre su desarrollo futuro. Aumentar la esperanza de vida del sistema. Ampliar las capacidades del uso de herramientas CASE (Ingeniería de Software Asistida por Computadora ó Computer Aided Software Engineering, por sus siglas en inglés). Facilitar su migración: traducirlo a otros lenguajes, moverlo de un entorno operativo o actualizar su tecnología. Mejorar su estructura y comprensibilidad. 11 El proceso de reingeniería de software puede realizarse en conjunto con el proceso de reutilización de software, el cual es explicado a continuación. 2.2 Reutilización de Software La reutilización de software es una estrategia de ingeniería de software que se basa en la reutilización de sistemas o componentes existentes para desarrollar nuevos sistemas. Viene ejecutándose desde hace más de 30 años y surge como respuesta a la demanda de una menor producción de software y de menores costos de mantenimiento, de una entrega más rápida de los sistemas y del incremento de la calidad del software [6]. Este proceso comprende distintas aproximaciones, a saber [6]: Reutilización de sistemas: en donde un sistema completo es reutilizado incorporándolo sin cambios dentro de otro sistema. Reutilización de componentes: consiste en acoplar componentes de un sistema a otro sistema para ampliar sus capacidades. Reutilización de objetos y funciones: es la reutilización más común y se basa en la reutilización de clases, funciones o librerías que contienen características valiosas para otros sistemas.

24 Para llevar a cabo la reutilización de software se han desarrollado muchas técnicas a lo largo de los años, todas ellas se fundamentan en el uso de estándares que definen si un objeto, componente o sistema es fácilmente reutilizable o no. Entre las técnicas más importantes se encuentran [6]: 12 Patrones de diseño: son abstracciones genéricas que encapsulan las buenas prácticas de diseño y experiencias para resolver un problema común de desarrollo de software, de tal forma que dicha experiencia pueda ser reutilizada por otros. Desarrollo basado en componentes: los sistemas se desarrollan identificando e integrando componentes de acuerdo a estándares establecidos. Sistemas orientados a servicios: los sistemas se desarrollan enlazando servicios compartidos, que pueden provenir de fuentes externas. Generadores de programas: en donde existe un sistema que posee conocimientos sobre un dominio en particular y puede generar sistemas que abarquen dicho dominio. Algunas ventajas que se obtienen al usar el enfoque de reutilización de software son [9]: Reduce el tiempo y los costos de desarrollo. Reduce los riesgos que puedan presentarse durante el desarrollo del software. Fuerza el uso de estándares para aumentar su calidad y posibilitar su futura reutilización. Acelera la producción del sistema para colocarlo en el mercado lo más pronto posible. Aumenta la productividad en la labor de mantenimiento. Sin embargo, sufre de ciertas desventajas, entre ellas [9]: Es necesario invertir tiempo y esfuerzo antes de poder obtener resultados. Puede ser costoso determinar cuáles son los componentes que se necesitan reutilizar. Falta de soporte de herramientas CASE, las cuales difícilmente soportan el desarrollo con reutilización.

25 Tomar la decisión de escoger la reutilización como estrategia para construir un sistema no es algo sencillo. Es necesario derivar los costos estimados y analizar cuál de las técnicas de reutilización es la más adecuada para el producto en cuestión, lo cual siempre dependerá de los requerimientos que solicite el sistema, el dominio o tópico en que se basa, el tiempo máximo de desarrollo, las tecnologías que serán usadas y la experiencia del grupo de desarrollo. 13 Para el proyecto de pasantía la reutilización de software fue escogida como uno de los métodos para aplicar el proceso de reingeniería y su inmediata reimplementación. La decisión se debió al requerimiento de conservar algunos componentes y librerías del sistema cuya lógica es indispensable para su correcto funcionamiento. De igual forma, la reutilización permitirá satisfacer la necesidad latente de aumentar la mantenibilidad del sistema, incrementar la productividad de las tareas de mantenimiento y fomentar buenas prácticas de desarrollo que permitan que el sistema, sus componentes y objetos puedan ser reusables en un futuro. 2.3 Modelo Vista Controlador Modelo Vista Controlador (MVC) es un patrón de diseño de software que describe una manera de separar las distintas partes que conforman una aplicación en tres secciones principales: modelo, vista y controlador [10]. El modelo define la funcionalidad principal del sistema y engloba las rutinas de acceso a datos y la lógica de negocio. La vista define que será presentado al usuario y se encarga de recoger los datos que éste proporcione. El controlador actúa de intermediario entre la vista y el modelo, recibiendo y enviando información de ambas partes y controlando su ejecución. Las interacciones entre las diferentes secciones pueden observarse en la Figura 2.1. Las líneas sólidas indican comunicación directa entre dos secciones y las líneas pespunteadas indican comunicación indirecta.

26 14 Figura 2.1. Representación gráfica del patrón Modelo Vista Controlador [11]. La separación conseguida por el patrón MVC fomenta el bajo acoplamiento de la arquitectura del software y trae como beneficio que los cambios efectuados en una de la secciones tengan un mínimo impacto en las otras secciones [12]. Esto a su vez promueve la mantenibilidad y extensibilidad de un sistema, ya que cada componente puede ser actualizado o reemplazado completamente sin afectar la integridad del sistema. Durante el proceso de reingeniería se decidió enfocar el desarrollo del SRI bajo las buenas prácticas del patrón MVC, mediante las facilidades que ofrece el framework de desarrollo Zend Framework (el cual será explicado en el siguiente apartado de este capítulo). La implementación de este patrón permitirá la generación de una arquitectura de software sólida, fácil de comprender para nuevos desarrolladores y conformada por componentes que respetan los conceptos de alta cohesión y bajo acoplamiento, que permitirán que el sistema pueda ser mantenido con mayor facilidad en las futuras modificaciones que se presenten. 2.4 Zend Framework De acuerdo a su manual oficial, Zend Framework es un framework de código abierto para desarrollar aplicaciones y servicios web con PHP (Hypertext Preprocessor) en su versión 5 [13]. Fue diseñado con la finalidad de ayudar a los desarrolladores de PHP5 en la tarea de asegurar que la producción de sus sistemas sea más sencilla y conserven estándares de calidad que les permitan ser mucho más mantenibles a lo largo del tiempo [10].

27 Se encuentra implementado bajo un enfoque orientado a objetos y fue diseñado para utilizar múltiples patrones que faciliten al desarrollador la creación de aplicaciones web de manera sencilla y conservando altos niveles de calidad. 15 Los patrones de diseño más importantes que implementa son el patrón MVC el cual compondrá la arquitectura del software que será desarrollado y el patrón Front Controller que centraliza la entrada a la aplicación, estableciendo un único de acceso para atender todas las solicitudes. Está compuesto por una serie de componentes que respetan el principio de alta cohesión y bajo acoplamiento ; entre ellos se encuentra un componente que implementa el patrón de diseño MVC y un componente que provee abstracciones para acceder a la base de datos con facilidad; otros componentes permiten controlar las actividades de autenticación, acceso, búsqueda, fechas y localización, generación de PDF (Portable Document File), envío y configuración de s, creación y conexión entre web services, entre otros. Debido al bajo acoplamiento de los componentes, Zend Framework no obliga a utilizarlos todos, sino que pueden ser usados a la medida que se vayan necesitando [13]. Este tipo de diseño se conoce como use-at-will (uso a voluntad) y permite que los componentes de Zend Framework puedan ser utilizados en otros sistemas que no estén diseñados bajo su estructura e incluso integrarse con otros frameworks para PHP, como Symphony o CakePHP. Las ventajas de utilizar Zend Framework se engloban en los siguientes aspectos [10]: Permite implementar el patrón MVC para separar las capas lógica, vista y datos de un sistema. Promueve el uso de buenas prácticas de diseño y desarrollo de software. Estandariza los procesos de desarrollo forzando el uso de patrones de diseño para aumentar la mantenibilidad del código e incrementar la productividad de los desarrolladores en las tareas de mantenimiento. Posee componentes débilmente acoplados que pueden ser usados a la medida que se necesiten.

28 Promueve estándares de codificación que facilitan la documentación interna del código. Acorta los tiempos que nuevos desarrolladores deben dedicar para la comprensión del sistema. Facilita la integración del software con otros sistemas, independientemente si trabajan bajo Zend Framework o no. Cuenta con el respaldo de Zend, empresa creadora de PHP, lo que asegura su continuo desarrollo y mantenimiento. 16 De entre todos los frameworks para PHP existentes, se decidió utilizar Zend Framework principalmente por su robusta implementación del patrón MVC [10]. Uno de los requerimientos más importantes que se necesitaba en el proyecto abarcaba la comprensión del código del sistema y mediante su análisis poder identificar los distintos componentes que lo conforman, para luego distribuir sus funcionalidades de acuerdo a los estándares del patrón MVC. De esta forma, en combinación con el proceso de reingeniería podrá separarse la lógica de negocios, la capa de presentación y la capa de acceso a datos y reubicarlas de acuerdo a las necesidades del proyecto. 2.5 Net2Client Net2Client (N2C) es una herramienta modeladora de negocios que permite a sus usuarios crear bases de datos relacionales, facilitar el control del manejo de las relaciones con los clientes y potenciar el mercadeo en Internet [14]. Se encuentra desarrollada con software libre bajo la plataforma LAMP (L: Linux; A: Apache; M: MySQL; P: PHP), pero puede utilizarse también bajo el entorno Windows gracias a la portabilidad y el soporte multiplataforma de las tecnologías que lo constituyen. Trabaja bajo la modalidad de Application Service Provider (Proveedor de Servicios de Aplicación ASP por sus siglas en inglés), esto es, se encuentra instalado en un servidor web desde el cual puede ser accedido. Éste servidor puede ser de la empresa o de la empresa que ha adquirido el sistema.

29 La filosofía de N2C consiste en darle poder a los usuarios, sin importar si son desarrolladores o no tienen conocimiento alguno sobre sistemas, y aumentar la productividad de los mismos en la realización de sus tareas. Entre las bondades que caracterizan a N2C se encuentran las siguientes [15]: 17 Multiidioma y multiplataforma. Permite centralizar la información de clientes y proveedores, así como las comunicaciones con sus empleados y colaboradores. Manejo de campañas de mercadeo a través de correos electrónicos. Automatización de la creación de bases de datos y sus tablas. Uso de wizards (asistentes) para facilitar a los usuarios la administración de sus datos. Generación de reportes a la medida del usuario. Manejo de correos masivos y personalizados. Seguridad integrada, manejo de sesiones y perfiles. Capacidad de integrarse con otros sistemas El uso de la herramienta N2C forma parte de las normativas de trabajo para cualquier proyecto dentro de la empresa, y fue utilizada desde el comienzo del proyecto de pasantía para la creación y administración de las bases de datos. La facilidad de generar reportes de las tablas para visualizar sus datos y la posibilidad de obtener y presentar la metadata de las tablas y sus interrelaciones, son sólo algunas de las capacidades que permitirán agilizar el tiempo de análisis del sistema y aumentar la productividad de desarrollo. Una ventaja adicional del uso de N2C dentro de la empresa es la posibilidad de visualizar las bases de datos de otros proyectos, lo cual facilita realizar análisis y comparaciones de la estructuras de datos de dos o más sistemas y, de ser necesario, poder conectarlas para que puedan interactuar entre sí y compartir sus datos. Esta situación podría aplicarse al Sistema de Reservaciones Inmediatas si se determina que debe comunicarse con otros sistemas desarrollados en la empresa.

30 Software como Servicio El Software como Servicio (Software As A Service, SAAS por sus siglas en inglés) puede ser definido como un modelo que permite distribuir aplicaciones de computación a través de Internet [16]. Una descripción más precisa expone al término como un modelo de distribución de software donde la compañía vendedora despliega una versión de su sistema en Internet, pudiendo ser accedida por los usuarios finales desde cualquier parte, y otorgando al proveedor la responsabilidad del mantenimiento y soporte del producto, así como de su hospedaje y actualización [17]. Se le conoce también como Software bajo Demanda. Este modelo ha recibido una buena aceptación en los últimos años y ha beneficiado tanto a los desarrolladores como a sus clientes. El uso de Software como Servicio ha abierto las puertas a muchas pequeñas y medianas empresas que no cuentan con los recursos para costear licencias de software, pero si pueden pagar por alquileres o rentas mensuales razonables. De esta forma el software se paga a medida que se necesite [17]. De igual forma, al usar SAAS se reducen los costos que normalmente las empresas invierten en instalaciones, la configuración del ambiente para que el software pueda ejecutarse correctamente, el mantenimiento del mismo y la preparación del personal necesario para dar soporte y realizar dicho mantenimiento [17]. En general, un SAAS tiene las siguientes características y ventajas [17]: Acceso a través de Internet, sin importar el sistema operativo. El sistema se hospeda en un servidor centralizado propio de la empresa desarrolladora y no en el servidor de la empresa que solicita el producto. La empresa que ofrece el producto se encarga de proveer los medios seguros de acceso al sistema. La responsabilidad de mantenimiento y de garantizar la completa funcionalidad del sistema recae sobre la empresa desarrolladora. El sistema no requiere de licencias para poder ser utilizado, sino del pago de un alquiler o renta, generalmente accesible, y la cual se paga a medida que se usa.

31 La empresa que adquiere el sistema no necesita tener un departamento para dar soporte del sistema. El usuario no requiere software o hardware que comprar, instalar o mantener. Las actualizaciones son centralizadas y son realizadas por la empresa desarrolladora, por lo que el usuario final no debe preocuparse por descargar parches ni actualizaciones. 19 Por otro lado, el enfoque de SAAS no siempre satisface los requisitos de todos los usuarios, presentando las siguientes desventajas [17]: El usuario no tiene acceso directo a sus contenidos, los cuales se encuentran en un servidor remoto y si no cuentan con mecanismos de cifrado la privacidad puede ser vulnerada por parte de la empresa que ofrece el producto. El usuario no tiene acceso al código fuente en caso de querer realizar modificaciones que se ajusten a sus necesidades. Si el servicio de Internet no está disponible, el usuario no tendrá acceso al sistema ni a los datos de su cuenta. La implantación del SRI bajo el enfoque de SAAS fue pensada desde el momento de la concepción del sistema y se conservó durante su reimplementación para mantener transparente a los usuarios finales (hoteleros y posaderos de Venezuela) todas las actividades de desarrollo, mantenimiento y actualización del producto.

32 CAPÍTULO 3 MARCO METODOLÓGICO Para garantizar la correcta implementación de un sistema es importante definir una metodología de desarrollo que permita estructurar, planear y controlar las actividades que deben llevarse a cabo para la construcción del software. Esta metodología debe proveer herramientas, técnicas y métodos que permitan el manejo efectivo del tiempo y los recursos para alcanzar los objetivos propuestos. De esta forma, para el presente proyecto de pasantía se escogió la metodología de desarrollo RUP (Rational Unified Process), que permitió estructurar y organizar las actividades de análisis, diseño e implementación necesarias para el desarrollo del mismo. 3.1 Descripción de la metodología La metodología de desarrollo RUP es un proceso de ingeniería de software desarrollado por Rational Software Corporation, filial de IBM desde el año 2003, que constituye una de las metodologías más usadas hoy en día para el análisis, implementación y documentación de software [18]. Provee un enfoque disciplinado para asignar tareas y responsabilidades dentro de una entidad desarrolladora y su flexibilidad le permite adaptarse a las necesidades de cualquier proyecto [19]. Además de ello, utiliza el lenguaje UML (Unified Modeling Language) para modelar y representar de manera sencilla requerimientos, procesos y aspectos de un sistema. 3.2 Características, buenas prácticas y metas de RUP El proceso de software propuesto por RUP tiene tres (3) características principales [19]:

33 Está dirigido por casos de uso, los cuales guían el diseño, implementación y pruebas del sistema. 21 Se centra en la arquitectura, garantizando la construcción de una estructura sólida que no se vea fuertemente afectada ante cambios posteriores. Es iterativo e incremental: el proceso se divide en partes más pequeñas o mini proyectos para garantizar el equilibrio entre casos de uso y arquitectura, asegurando que el sistema se conserve estable al final de cada mini proyecto o iteración. Por otro lado, RUP define seis (6) buenas prácticas a seguir para asegurar el desarrollo efectivo de software [19]: Desarrollar software iterativamente, definiendo iteraciones con metas definidas y garantizando la evaluación continua para conocer el estado del proyecto. Modelar el software visualmente, utilizando el lenguaje UML para facilitar la gestión y comprensión del software. Gerenciar los requerimientos, siguiendo los cambios de los requisitos funcionales y restricciones para evaluar que lo implementado satisfaga dichos requerimientos. Usar arquitecturas basadas en componentes, que se van identificando a medida que evoluciona el software y promueven la modularidad y el uso de estándares en el sistema. Verificación continua de la calidad, que permite la evaluación del proyecto en distintos puntos de su desarrollo para detectar inconsistencias. Gerenciar los cambios, para asegurar que se conserve la integridad del sistema cuando se presente la necesidad de realizar cambios y evaluar cuál será el impacto sobre el mismo.

34 22 En general, las metas que persigue la metodología RUP son [20]: Asegurar la producción de un software de alta calidad. Ajustarse a las necesidades de los usuarios finales y satisfacerlas plenamente. Proveer un enfoque disciplinado para asignar tareas y responsabilidades dentro del desarrollo del sistema. Reducir los riesgos del desarrollo de sistemas complejos. Proporcionar un camino metódico, sistemático y adecuado para diseñar, desarrollar y validar una arquitectura de software. 3.3 Estructura de RUP El proceso propuesto por RUP contempla dos (2) dimensiones, a saber [19]: La dimensión dinámica, representada por el eje horizontal de la Figura 3.1, que indica las características del ciclo de vida del proceso, expresado en términos de fases, iteraciones e hitos. La dimensión estática, representada por el eje vertical de la Figura 3.1, que es descrita en términos de componentes de disciplinas, actividades, artefactos y roles. Figura 3.1. Estructura del proceso de RUP [20]

35 Estructura dinámica La estructura dinámica del proceso de RUP contempla un ciclo de vida del software, el cual puede repetirse varias veces durante la vida de un sistema. Cada ciclo está conformado por cuatro (4) fases: inicio, elaboración, construcción y transición. Éstas a su vez se dividen en iteraciones, cuyo número es variable para cada fase. A continuación se describe brevemente cada fase, sus objetivos y resultados esperados [20]. Fase de Inicio: comprende la definición del modelo del negocio y el alcance del proyecto. Se deben identificar los actores y casos de uso críticos del sistema; definir una arquitectura inicial y estimar los riesgos de desarrollo. Al final de esta fase es recomendable que se tengan elaborados el documento de visión del proyecto, un glosario inicial del proyecto, un modelo inicial de los casos de uso del sistema (10-20%), el caso del negocio y el plan del proyecto. Fase de Elaboración: tiene como propósito analizar el dominio del problema y presentar el diseño y características que conformarán la arquitectura. Se deben planificar las actividades y recursos necesarios para las siguientes fases, eliminar los riesgos identificados y presentar un prototipo de la arquitectura que contenga los casos de uso especificados en la fase de inicio. Al final de esta fase deben obtenerse los siguientes artefactos: un modelo de casos refinado (completado en al menos el 80%), la descripción de la arquitectura del software, un prototipo ejecutable de la arquitectura y un plan de proyecto refinado. Fase de Construcción: su finalidad es llevar a cabo la implementación del producto y alcanzar su capacidad operacional de forma incremental a través de las distintas iteraciones. Durante esta fase todos los componentes, características y requisitos deben ser implementados y probados en su totalidad para obtener una versión aceptable del sistema que pueda ser enviada a producción. Al final de esta fase deben obtenerse: el modelo de casos de uso completo, una arquitectura íntegra, el plan de proyecto para la fase de transición y el manual de usuario inicial. Fase de Transición: su objetivo es entregar el producto a los usuarios finales y hacer que éstos puedan valerse por sí mismos en el manejo del sistema. Para ello es necesario realizar

36 actividades como: completar la documentación, entrenar al usuario en el manejo del producto, y en general tareas relacionadas con la instalación, ajuste, configuración y búsqueda de facilidad de uso del producto. Al final de esta fase debe conseguirse una versión completamente operacional del producto que cumpla con los requisitos esperados y satisfaga las necesidades de los usuarios finales Estructura estática Está dimensión del proceso define quién hace qué, cómo y cuándo. RUP define cuatro elementos que responden a estas preguntas [19]: los roles que responden la pregunta Quién?; las actividades que responden la pregunta Cómo?; los artefactos que responden a la pregunta Qué?; y las disciplinas que responden a la pregunta Cuándo? A continuación se presenta una breve descripción de cada uno de estos elementos [19]: Roles: un rol define el comportamiento y responsabilidades de un individuo dentro de un equipo de trabajo. RUP define distintos de roles, agrupados en seis grupos de acuerdo a sus actividades: analistas, desarrolladores, gestores, apoyo, especialistas en pruebas, entre otros. Actividades: una actividad es una unidad de trabajo que una persona que desempeñe un rol puede ser encargada a que la realice. Artefactos: un artefacto es un trozo de información producido durante el proceso de desarrollo de software. Son resultados tangibles del proyecto, por ejemplo documentos (documento de visión), modelos (modelo de casos de uso) o un elemento de un modelo (una clase o un caso de uso). Disciplinas: agrupa una serie de actividades que deben ejecutarse por diferentes roles para conseguir unos resultados observables. Las disciplinas que plantea RUP se agrupan en dos categorías: de proceso o ingeniería (modelado empresarial, requisitos, análisis y diseño, implementación, pruebas y despliegue) y de apoyo (gestión de cambios y configuración, gestión de proyectos y entorno).

37 Aplicación para el proyecto de pasantía De acuerdo al plan de trabajo, el proyecto debía abarcar las tres (3) primeras fases de la metodología RUP: Inicio, Elaboración y Construcción. Sin embargo, por requerimientos de la empresa fue necesario llevar a cabo la fase de Transición, completando el ciclo de vida de software planteado por RUP. En el siguiente capítulo se describen las actividades, decisiones y resultados obtenidos durante las distintas fases contempladas.

38 CAPÍTULO 4 DESARROLLO En este capítulo se describe el proceso de desarrollo del proyecto de pasantía. A continuación se presentaran varias secciones que corresponden a las fases de inicio, elaboración, construcción y transición de la metodología RUP, en las que se detallan las actividades realizadas y los resultados obtenidos para cada una de dichas fases. 4.1 Fase de Inicio Esta fase abarcó la captura de requerimientos, la comprensión del problema del proyecto y la definición del alcance. Durante esta fase se realizaron reuniones semanales dirigidas por el tutor industrial para indagar en los aspectos y necesidades que perseguía la empresa para satisfacer la demanda de clientes potenciales mediante la reingeniería del SRI y la creación de su versión móvil. Dichas reuniones también permitieron conocer los aspectos internos de la empresa y las convenciones que siguen para llevar a cabo la elaboración de sus proyectos. Adicionalmente se realizaron una serie de reuniones con los desarrolladores del sistema que sirvieron de soporte para comprender los aspectos técnicos, la organización del código fuente, la comprensión de la documentación existente y la plataforma sobre la cual trabajaba el producto. A su vez, las reuniones realizadas permitieron recoger los requerimientos funcionales y no funcionales deseados, y analizar las características que debían mejorarse durante el proceso de reingeniería Plan del proyecto esta fase. En la Tabla 4.1 se definen las actividades más importantes que fueron realizadas durante

39 27 Tabla 4.1. Plan del proyecto Fase de Inicio. Fuente: Elaboración propia Actividades Análisis de la visión del sistema y definición del alcance del proyecto Definición de los stakeholders involucrados en el proyecto Definición de los usuarios del sistema Determinación de las necesidades de los stakeholders y usuarios Análisis de la perspectiva y beneficios del sistema Definición de las características y rangos de calidad Definición de las restricciones de diseño e implementación del producto Selección de las herramientas de desarrollo a ser utilizadas durante el proyecto Análisis inicial de la arquitectura del sistema en su versión previa al desarrollo del proyecto Elaboración del Apéndice A: Glosario de términos, Apéndice B: Documento de Visión y Apéndice E: Herramientas de Desarrollo Planificación de actividades para la Fase de Elaboración Visión del sistema y alcance del proyecto La visión que cubre el sistema se presenta en el Apéndice B: Documento de Visión. Dicho documento permitió recoger, analizar y definir las características y necesidades de alto nivel del SRI, la oportunidad de negocio perseguida y el alcance que abarca. El SRI está orientado al ambiente hotelero de Venezuela, esto es, a todos aquellos clientes propietarios de hoteles y posadas venezolanos, permitiéndoles administrar sus establecimientos y automatizar los procesos de sus negocios. Inicialmente fue pensado como un Software como servicio desplegado a través de Internet y entregado a aquellos hoteleros y posaderos que lo fueran solicitando. Sin embargo, estudios de mercado elaborados por demuestran que son muchos los establecimientos en Venezuela que poseen cobertura limitada a Internet, y en su reemplazo utilizan la tecnología móvil como medio para comunicarse, y agilizar y llevar registro de sus actividades cotidianas. Siendo el uso de dispositivos móviles una tendencia cada vez mayor en la actualidad, se decidió implementar una versión Web del sistema para tecnología móvil, la que permitirá capturar a una gran cantidad de hoteleros y posaderos que encontrarán en el mismo una herramienta que complementará y facilitará las actividades diarias en su negocio.

40 Sin embargo, era conocida la premisa que el sistema no estaba estructurado adecuadamente, lo que dificultaba su mantenimiento y elevaba los tiempos invertidos en dicha tarea. En vista de ello, se decidió realizar un proceso de reingeniería al sistema en su versión previa al proyecto, con el fin de establecer una arquitectura sólida que permitiese maximizar la eficiencia del sistema y aumentar su grado de mantenibilidad. Posteriormente se prosiguió a la implementación de la versión móvil Stakeholders El término stakeholder se refiere a aquella persona o grupo que afecta o puede ser involucrado en un proyecto en particular. En otras palabras, es el público interesado o involucrado en el proyecto. En la Tabla 4.2 puede observarse la descripción de los stakeholders interesados en el desarrollo y éxito del SRI, indicando además las responsabilidades que adquieren dentro del mismo. Tabla 4.2. Descripción de los Stakeholders del sistema. Fuente: Elaboración propia Nombre Descripción Responsabilidades Hoteleros y posaderos de Venezuela Son los clientes a los cuales está dirigido el sistema, y cuyas necesidades y tendencias determinan como se desarrollará el mismo. Son propietarios de hoteles y/o posadas. Empresa desarrolladora de software encargada del diseño, implementación e implantación del sistema VenezuelaTuya Empresa que administra el portal venezuelatuya.com y ofrece los servicios del SRI Administran sus establecimientos apoyándose de las funcionalidades del sistema. Aportar feedback a los desarrolladores a través de sus opiniones y necesidades crecientes. Recoger requerimientos y necesidades de los usuarios finales. Analizar y diseñar la arquitectura del sistema. Implementar e implantar el sistema Garantizar su mantenibilidad. Monitorear que las necesidades de los usuarios se satisfagan efectivamente. Garantizar que el sistema esté a la vanguardia tecnológica. Captar a los clientes hoteleros y posaderos que necesiten el sistema. Administrar las cobranzas del sistema a los clientes registrados. Analizar las necesidades crecientes de los clientes y comunicárselas a los desarrolladores de.

41 Usuarios La Tabla 4.3 muestra los usuarios del sistema, las responsabilidades que les corresponden y cómo se encuentran representados de acuerdo a la lista de stakeholders. En vista del alcance del proyecto, el usuario Público no será tomado en cuenta para los análisis de las fases siguientes, ya que no existen escenarios donde interactúe con la sección privada del SRI. Sin embargo, es mencionado en esta lista ya que forma parte de la visión global del sistema. Tabla 4.3. Descripción de los Usuarios del sistema. Fuente: Elaboración propia Nombre Descripción Responsabilidades Representado por Hotelero o posadero Agente Dueño y administrador principal de un hotel o posada. Administrador del sistema, posee todos los privilegios sobre el mismo. Asesor de servicios de VenezuelaTuya. Es el super usuario del sistema, esto es, administra todas las cuentas de todos los hoteles registrados al SRI. Utiliza el SRI para administrar su establecimiento. Consulta las situaciones de ocupación y de reservaciones diarias. Consulta los datos y el status de pago de sus huéspedes. Realiza reservaciones de nuevos huéspedes. Genera reportes dinámicos de reservaciones y ocupación de habitaciones. Vende y presta asesoría al Público sobre viajes y paquetes turísticos. Presta soporte a los Hoteleros sobre el manejo del SRI. Administra y supervisa las cuentas de los Hoteleros registrados en caso de fallas o errores reportados. Genera reportes sobre las necesidades crecientes del Público y los Hoteleros. Hoteleros y posaderos de Venezuela VenezuelaTuya Público Es cualquier persona que realiza una reservación a un hotel utilizando el servicio de Reservaciones Inmediatas de venezuelatuya.com. Su reservación será administrada en el SRI por los hoteleros Visita el portal venezuelatuya.com para buscar información de Venezuela y planes de viaje y hospedaje. Realiza reservaciones en cualquier hotel que preste el servicio de Reservaciones Inmediatas de VenezuelaTuya Necesidades de los Stakeholders y Usuarios Las necesidades que requieren los stakeholders y usuarios del sistema se enuncian en la Tabla 4.4. Se expone la prioridad que poseen y las soluciones propuestas para solventar cada una.

42 30 Tabla 4.4. Necesidades de los Stakeholder y Usuarios. Fuente: Elaboración propia Necesidad Prioridad Preocupación Solución Actual Soluciones propuestas Disponer de una herramienta que les permita a los hoteleros administrar de forma eficiente sus establecimientos Alta Ineficiencia en las actividades de administración de habitaciones de un hotel Llevar el registro de sus operaciones manualmente en agendas o programas electrónicos no dedicados Desarrollar y ofrecer el SRI para ayudar a los hoteleros a automatizar sus procesos de negocio Ofrecer a los hoteleros la capacidad de controlar su establecimiento sin estar presente en el mismo Alta El hotelero siempre debe estar presente en su establecimiento para atender nuevas reservaciones y para tomar decisiones que afecten sus actividades diarias Existen soluciones limitadas, como atender llamadas a celular y anotarlas en una agenda, pero luego habría que pasarlas al entorno donde se administran. Esto no aplica para verificar la disponibilidad de su establecimiento Elaborar una versión móvil del sistema que permita a los hoteleros administrar la situación de su hotel desde cualquier lugar sin estar presente físicamente en el mismo El sistema debe poder usarse desde cualquier parte y desde cualquier plataforma de hardware y software Alta Muchos establecimientos no tienen un servicio de internet confiable y además utilizan sistemas operativos distintos. De esta forma, existe una demanda de usuarios que aún queda por satisfacer El SRI en su versión actual es un sistema multiplataforma Web que puede ser visitado mediante cualquier navegador Web. No obstante depende de un buen servicio de Internet y del uso de un dispositivo de escritorio, como una computadora personal o una laptop El SRI móvil permitirá que el sistema pueda ser usado desde cualquier dispositivo de telefonía móvil, permitiendo a los hoteleros usar el sistema desde cualquier lugar y sin necesidad de estar afiliado a un servicio de acceso a internet Perspectiva y beneficios del sistema El SRI consta de dos secciones: una sección privada dedicada a los hoteleros en la que podrán administrar la situación de reservaciones y ocupación de sus establecimientos; y una sección pública orientada al público en general, donde podrán realizar reservaciones de habitaciones en hoteles que cuenten con el servicio de Reservas Inmediatas, de tal forma que sus reservaciones serán atendidas posteriormente por los hoteleros. Para efectos del proyecto se decidió realizar únicamente la reingeniería de la sección privada del sistema, por lo que los requerimientos para su rediseño e implementación fueron enfocados principalmente en las necesidades y procesos de negocio de los hoteleros y posaderos.

43 La sección pública del sistema también requerirá realizar un proceso de reingeniería para lograr acoplarla adecuadamente a la sección privada, sin embargo, no forma parte del alcance del proyecto. 31 La Tabla 4.5, presentada a continuación, expone una breve descripción de las capacidades y beneficios deseados en el SRI y que fundamentarán el éxito de su expansión en el mercado venezolano. Tabla 4.5. Descripción de los beneficios del sistema. Fuente: Elaboración propia Beneficios Incremento del número de clientes potenciales Automatización de procesos de negocio Facilidad de uso Mayor accesibilidad Reducción de los costos de soporte y mantenimiento Descripción El sistema será desarrollado bajo tecnología Web. Contará con una versión para computadoras de escritorio y una versión para teléfonos móviles, de tal forma que sea un sistema multiplataforma y multidispositivo. De esta forma se expande el alcance del sistema a muchos más usuarios, en especial a aquellos que no posean un servicio de Internet confiable El hotelero podrá automatizar sus procesos de negocio, llevando por sí mismo la administración de las situaciones de ocupación y reservaciones de su establecimiento. La interfaz gráfica del sistema será sencilla y de carácter intuitivo; poseerá un menú de navegación para organizar los distintos procesos de negocio y facilitar el aprendizaje de las funcionalidades del sistema El SRI será desplegado en Internet como un SAAS y será mantenido por. De esta forma, podrá ser accedido desde cualquier parte. En el caso de la versión móvil, está podrá ser accedida por Internet o alternativamente a través de la red del proveedor de telefonía móvil Gracias al enfoque SAAS, la contratación del servicio del SRI no necesitará de ninguna instalación ni tampoco invertir en costos de mantenimiento por parte del usuario hotelero Además, el sistema contará con un manual de usuario en línea creado bajo el servicio de Google Sites, que permite la navegación por hiperlinks y provee del motor de búsquedas de Google Características y rangos de calidad Tomando en cuenta las necesidades previamente descritas, se definieron las características y rangos de calidad que debe poseer el sistema para cumplir con los requisitos definidos. Las características se generalizan en la Tabla 4.6 mientras que los rangos de calidad se exponen en la Tabla 4.7.

44 32 Tabla 4.6. Características del sistema. Fuente: Elaboración propia Característica Multidispositivo Multiplataforma Monousuario Acceso desde cualquier parte Visualizar las situaciones de reservaciones y ocupación Administración de cupos Administración de reservaciones Generación de reportes dinámicos de reservaciones y ocupación Descripción El sistema comprenderá una versión para computadoras personales y una versión móvil. Ambas versiones podrán ser utilizadas por el usuario de acuerdo a sus necesidades sin ninguna restricción, una vez que contrate el servicio con VenezuelaTuya. Es independiente del sistema operativo y del hardware del dispositivo que se usa para visitarlo; las únicas condiciones son tener un navegador web con el cual poder acceder al sistema y disponer cualquier acceso a la red Internet. El sistema temporalmente ofrecerá la creación y acceso de un solo usuario por hotel. Para futuros desarrollos se implementará la funcionalidad para que el sistema sea multiusuario y los hoteleros administradores puedan asignar a otros usuarios y configurar sus permisos sobre el sistema. El sistema será desplegado en Internet, proveyendo a los usuarios acceso desde cualquier lugar de Venezuela y el mundo. El SRI proveerá al hotelero la capacidad de observar la situación completa de su establecimiento apenas ingrese al sistema. En la versión para computadoras personales se mostrará la situación de reservaciones del presente y los últimos 15 días así como la situación de ocupación del mes en curso. En la versión móvil, debido a las limitaciones de ancho de pantalla, ambas situaciones se presentarán para el día en curso y el día anterior. El hotelero podrá consultar y controlar el número de cupos destinados a reservaciones online realizadas desde el portal venezuelatuya.com y el número de cupos de reservaciones que serán realizadas dentro del establecimiento. El usuario hotelero podrá administrar sus reservaciones de manera rápida y sencilla. En la versión de escritorio podrán hacerlo desde un panel dinámico que organiza sus habitaciones por tipos de habitación y en el cual podrá hacer operaciones de consulta y control: consultar los datos de un cliente; crear nuevas reservaciones y consultar, modificar y eliminar las ya existentes; verificar el status de pago de las reservaciones de los clientes; entre otras. En la versión móvil, la interfaz gráfica será más sencilla pero con las mismas operaciones. El sistema dispondrá una funcionalidad para generar reportes de reservaciones y ocupación que podrán ser organizados de acuerdo a los siguientes criterios: por período de fechas, por tipo de habitación, por clientes, entre otros. Tabla 4.7. Rangos de calidad del sistema. Fuente: Elaboración propia Rango de calidad Usabilidad Descripción Debe poseer una interfaz gráfica intuitiva y amigable, organizada de tal forma que los usuarios puedan aprender rápido a utilizarlo y se sientan cómodos. La interfaz debe ser tal que permita al usuario sentirse identificado y motivado a usar el sistema como su herramienta diaria. La interfaz debe estar aprobada por la W3C para garantizar su visibilidad en múltiples navegadores y dispositivos. En el caso móvil, debe seguir los análisis y estudios del reconocido Grupo Nielsen [21]

45 33 Portabilidad Mantenibilidad Seguridad Confiabilidad Eficiencia Gracias al uso de PHP y la estructura de diseño planteada por Zend Framework bajo el patrón MVC, el sistema puede ser fácilmente migrado a otro ambiente sin inconvenientes. La filosofía de Zend Framework permite desacoplar las clases de tal forma que estén lo menos relacionadas posible y que funcionalidades con objetivos comunes sean agrupadas en clases. De esta forma el grado de mantenibilidad del sistema aumentará y futuras implementaciones serán más fáciles de realizar. Además con el uso de RUP se dejará un sistema totalmente documentado, permitiendo recopilar de forma clara y precisa la arquitectura y el diseño del mismo, lo que facilitará aún más su facilidad de modificación. El sistema debe garantizar el acceso de solamente aquellos usuarios que estén registrados, y que efectivamente los datos presentados correspondan al usuario que se identifica en el mismo. De igual forma, la modelación de las consultas a la base de datos debe seguir los estándares y técnicas para evitar ataques del estilo sql injection 1, para evitar la filtración de datos o que caigan en manos indebidas. Por otro lado, el SRI debe aprobar el estándar de seguridad de la marca McCaffe SECURE para recibir el título de sitio de confianza [22] El sistema debe estar preparado para identificar fallas y/o excepciones y capturarlas apropiadamente. Si la falla se presenta en el entorno del usuario, debe ponerse en contexto al usuario acerca de la misma, ya sea mediante un mensaje o cualquier otro método utilizado. El sistema debe ser eficiente y tener tiempos de respuesta adecuados para garantizar que el usuario hotelero pueda agilizar sus actividades. En específico, las funcionalidades implementadas deben ser depuradas apropiadamente para que los tiempos de respuesta de las operaciones no se prolonguen más de 20 segundos independientemente del dispositivo que se use Restricciones de diseño e implementación Siguiendo los lineamientos de la Unidad de Desarrollo de, se definieron las restricciones de diseño e implementación que afectaron el desarrollo del SRI. A continuación se describen brevemente cada una de ellas: El proyecto abarcará solamente la reingeniería de la sección privada del SRI, es decir, la sección orientada a los hoteleros y posaderos, contemplando únicamente los módulos de visualización de las situaciones de reservaciones y ocupación; administración de cupos y generación de reportes. Los módulos mencionados anteriormente serán implementados tanto para la versión para 1 Sql injection: técnica que aprovecha las vulnerabilidades de un sistema y mediante la cual personas no autorizadas acceden a datos privados utilizando ciertos comandos para interactuar con el manejador de base de datos.

46 34 computadoras personales como para la versión móvil. Se dejarán montadas las bases para el desarrollo posterior de los otros módulos y futuras funcionalidades. El sistema se desarrollará utilizando el lenguaje PHP 5.0. Su diseño e implementación se realizarán bajo el patrón de diseño MVC utilizando Zend Framework A nivel visual, se utilizarán los lenguajes de maquetación HTML y CSS. De igual forma se empleará el lenguaje JavaScript y su framework JQuery 1.4. La base de datos a utilizar se creará y administrará bajo el manejador MySQL 5.1. El sistema podrá ser usado únicamente por aquellos hoteleros registrados al servicio por los agentes de VenezuelaTuya. Toda la documentación del sistema, tanto de código fuente como de documentos de RUP, deben regirse bajo los estándares y estar disponible en línea a través de la página privada Google Sites dedicada al sistema, para su futura consulta y uso de otros miembros de la empresa [23] Herramientas de desarrollo Las herramientas de desarrollo utilizadas durante el proyecto de pasantía se exponen en el Apéndice E: Herramientas de Desarrollo Arquitectura del sistema en su versión previa al proyecto Durante la fase de Inicio también se realizó un análisis preliminar sobre la arquitectura del SRI en la versión previa al proyecto de pasantía, con la finalidad de determinar los requerimientos necesarios para diseñar un plan para llevar a cabo la reingeniería del software. Las reuniones y entrevistas realizadas al Tutor Industrial, así como a los desarrolladores del sistema, permitieron conocer los detalles de desarrollo del sistema, que estándares se utilizaron y que

47 35 herramientas fueron usadas para su implementación e implantación. De esta forma, se determinó que el SRI fue construido sin seguir alguna metodología de desarrollo, y en vista de esto su documentación era escasa e informal. La documentación existente se encontraba en la aplicación web Google Sites asociada al SRI [23] y mantenida por. Contaba únicamente con un análisis del modelo de datos actual y su diagrama asociado, así como de una descripción general de los módulos, clases y librerías principales del sistema. Tampoco fue seguido patrón de diseño alguno para llevar a cabo la implementación y estructuración del código fuente. El análisis inicial realizado sobre esta documentación no fue suficiente para entender la arquitectura y los procesos asociados al sistema, necesarios para llevar a cabo la elaboración del plan de aplicación del proceso de reingeniería, esto debido a la ausencia de documentación y diagramas sobre los casos de uso, clases y componentes del sistema que esclarecieran dicha necesidad. Esta actividad fue pospuesta para continuarse en la fase de elaboración. 4.2 Fase de Elaboración La fase de Elaboración se llevó a cabo en dos iteraciones que contemplaron el análisis y comprensión de la arquitectura del sistema en su versión previa y la reingeniería de esta última que permitió elaborar un diseño inicial de la arquitectura del SRI en su nueva versión. A continuación se detallan las actividades y la descripción de cada una de las iteraciones realizadas Primera Iteración La primera iteración de esta fase comprendió el análisis y selección de las técnicas que serían llevadas a cabo para aplicar los procesos de reingeniería y reutilización del software. Estas técnicas facilitaron la continuación del análisis de la arquitectura del SRI en su versión anterior al proyecto de pasantía y de la cual se obtuvieron abstracciones de alto nivel (diagramas y especificaciones) que definen el diseño de arquitectura mencionada.

48 Seguidamente, se elaboró el documento de Especificaciones de Requerimientos del Software (ERS) para la nueva versión del sistema, tomando en cuenta los resultados del análisis previamente mencionado y las especificaciones contenidas en el Documento de Visión elaborado en la fase de Inicio. De igual manera, se definió la estructura inicial de la arquitectura de la nueva versión del SRI, comenzando por el diseño preliminar del modelo de casos de uso. 36 Plan del proyecto elaboración. La Tabla 4.8 lista las actividades realizadas durante la primera iteración de la fase de Tabla 4.8. Plan del proyecto - Fase de Elaboración (Primera Iteración). Fuente: Elaboración propia Actividades Selección de técnicas de reingeniería y reutilización de software Obtención y análisis de la arquitectura del sistema en su versión previa al proyecto Elaboración del Apéndice C: Especificación de Requerimientos del Software (ERS) Planificación de actividades para la fase de Elaboración en su segunda iteración Técnicas de reingeniería y reutilización de software En referencia a las investigaciones realizadas en la fase de Inicio y el análisis de la arquitectura del sistema en su versión previa, el proceso de reingeniería se realizó mediante la aplicación de las técnicas de ingeniería inversa, ingeniería directa y reestructuración de código (ver Capítulo 3: Marco Teórico). No se tomó en cuenta la técnica de reingeniería de datos, ya que recientemente se había realizado una reestructuración a la misma y decidió conservarse. La ingeniería inversa proporcionó un mecanismo con el que se obtuvieron los diseños: arquitectónico, de datos y de procesos del sistema necesarios para comprenderlo y reeimplementar una versión de mayor calidad del mismo y, posteriormente, llevar a cabo su documentación que servirá de referencia a los desarrolladores.

49 Por su parte, las actividades de ingeniería directa y la reestructuración de código comprendieron el análisis, comprensión y reorganización del código; la identificación de sus componentes y su desacoplamiento; la reutilización de modelos de datos y librerías consideradas vitales para el funcionamiento del sistema; entre otros. Estas actividades aumentarán la calidad y la facilidad de mantenimiento del sistema para futuros desarrollos. Los detalles de la aplicación de estas técnicas se encuentran en apartado 4.3 Fase de Construcción, perteneciente al presente capítulo. 37 Por otra parte, el proceso de reutilización de software fue llevado a cabo mediante la adopción del patrón de diseño MVC para la nueva versión del sistema, siguiendo las facilidades que ofrece el framework de desarrollo Zend Framework. La implementación de este patrón permitió la generación de una arquitectura de software sólida, que respeta los rangos de calidad expuestos en los documentos de Visión y ERS. Arquitectura del sistema en su versión previa al proyecto Para analizar con mayor profundidad la arquitectura de la versión anterior del sistema fue utilizada la técnica de ingeniería inversa. Debido a las limitaciones de documentación e información sobre el sistema, ésta fue llevada a cabo de diversas formas dependiendo del elemento analizado. La arquitectura presentada a continuación se encuentra organizada de acuerdo a los lineamientos del Modelo 4+1 Vistas de Krutchen (ver Apéndice D: Documento de Arquitectura del Software). Por motivos de tiempo se decidió reconstruir únicamente las vistas: lógica, de implementación y de implantación. Adicionalmente se presenta la vista de datos que muestra la estructura de la base de datos del sistema. Vista lógica La vista lógica describe un modelo constituido por las abstracciones fundamentales del sistema tomadas del dominio del problema, las cuales son representadas como clases [24].

50 Para obtener las diversas clases que conforman el sistema, se realizó un profundo análisis del código fuente para conocer los diferentes archivos, clases y librerías, así como sus interrelaciones y formas de ejecución. Este análisis permitió la construcción del diagrama de clases presentado en la Figura Este diagrama expone una estructura cuyos procesos están básicamente centralizados en una sola clase. En efecto, la clase APP controlaba todas las funcionalidades básicas de un sistema: acceso a la base de datos, autenticación de usuarios y controles de acceso, creación/destrucción de sesiones, entre otros, y su instancia física poseía un código fuente relativamente grande (alrededor de 2000 líneas de código). Dicha situación sumada a la escasa documentación del código fuente dificultaba la comprensión de la clase y las labores de mantenimiento, al no conocerse exactamente dónde realizar la modificación. Adicionalmente se determinó que el SRI se encontraba fuertemente integrado a N2C, puesto que existían un conjunto de clases y librerías que no pertenecían al SRI sino a la aplicación N2C, entre las cuales encontraba APP. Esto complicaba las labores de mantenimiento, ya que era difícil detectar si un error provenía del SRI o de N2C, y futuras mejoras del SRI siempre dependerían del estado en que se encontrase N2C. Vista de implementación Esta vista describe la organización estática del software en el ambiente de desarrollo, agrupando sus módulos en componentes [24]. La vista de implementación para la versión previa del sistema se representa a través del diagrama de componentes de la Figura 4.2. Por simplicidad, en dicho diagrama las interfaces de los componentes APP y Hotel no presentan a nivel visual acoplamiento alguno con otros componentes del sistema, sin embargo, todos los componentes restantes del diagrama se acoplan con cada una de las interfaces de los componentes mencionados.

51 39 Figura 4.1. Diagrama de clases del sistema en la versión previa al proyecto de pasantía. Fuente: Elaboración propia

52 40 Figura 4.2. Diagrama de componentes del sistema en la versión previa al proyecto de pasantía. Fuente: Elaboración propia Al igual que la vista lógica, los componentes presentes fueron determinados mediante la comprensión del código fuente y las interrelaciones entre los archivos. En esta vista vuelve a presentarse el mismo fenómeno: la mayoría de interfaces se encuentran centralizadas en un solo componente. Vista de implantación La vista de implantación se encarga de modelar la disposición física del software dentro del hardware y las configuraciones que éstos presentan [24]. La Figura 4.3 muestra un diagrama

53 de despliegue que muestra el hardware donde se aloja el SRI, el cual es el servidor número cuatro (4) de, también conocido como GWT4. 41 Físicamente, GWT4 se encuentra hospedado en la ciudad de Los Ángeles, Estados Unidos, bajo los servicios de la empresa ServInt. Es un servidor dedicado altamente configurable que corre bajo la plataforma de CentOS Linux y puede ser accedido por medio de consola y SSH. Figura 4.3. Diagrama de despliegue del sistema en la versión previa al proyecto de pasantía Fuente: Elaboración propia Vista de datos La vista de datos modela la estructura y organización de la información dentro del sistema. Consta del modelo Entidad-Relación (ER) y del diccionario de datos, que en conjunto muestran cuales son las tablas que conforman la base de datos del sistema y como están interrelacionadas unas con otras. Esta vista fue obtenida revisando la documentación disponible y

54 realizando observaciones sobre la base de datos utilizando las aplicaciones de administración N2C y MySQL Workbench. La primera herramienta mostraba la metadata de las tablas de una manera cómoda y sencilla, mientras que la segunda permitía reconstruir visualmente el modelo ER a partir de la base de datos utilizando procedimientos de ingeniería inversa. El modelo Entidad-Relación se presenta en la Figura 4.4 mientras que el diccionario de datos se encuentra disponible en el Apéndice D: Documento de Arquitectura del Software. 42 Figura 4.4. Modelo Entidad-Relación del sistema en la versión previa al proyecto de pasantía Fuente: Elaboración propia

55 Segunda Iteración En la segunda iteración de la fase de Elaboración se tomaron en cuenta las abstracciones de alto nivel resultantes del análisis de la arquitectura de la versión previa del sistema y las investigaciones realizadas sobre Zend Framework y el patrón de diseño MVC, con la finalidad de refinar el diseño de la nueva arquitectura del sistema propuesto en la iteración anterior. En este sentido, se presentó un modelo refinado de los casos de uso y se realizaron las distintas vistas propuestas por el Modelo 4+1 Vistas. Toda esta información fue documentada posteriormente en el Apéndice D: Documento de Arquitectura del Software. Plan del proyecto elaboración. La Tabla 4.9 lista las actividades realizadas durante la segunda iteración de la fase de Tabla 4.9. Plan del proyecto - Fase de Elaboración (Segunda Iteración). Fuente: Elaboración propia Actividades Análisis y definición de la nueva arquitectura del sistema Elaboración del Apéndice D: Documento de Arquitectura del Software Planificación de actividades para la fase de Construcción Arquitectura del sistema en su nueva versión La arquitectura propuesta para la nueva versión del sistema se encuentra organizada de acuerdo a los lineamientos del Modelo 4+1 Vistas de Krutchen [24]. Este modelo propone la existencia de cinco (5) vistas concurrentes, cada una dirigida a un conjunto específico de conceptos. Adicionalmente se presenta la vista de datos que presenta la organización de la información del sistema.

56 De igual forma, el diseño de la arquitectura se encuentra sometido a los atributos de calidad mencionados en el aparatado número diez (10) del Apéndice C: Especificaciones de Requerimientos del Software y a las restricciones de diseño expuestas en del Apéndice D: Documento de Arquitectura de Software. De este conjunto de características, una de las más importantes fue la decisión de seguir el patrón de diseño MVC siguiendo las especificaciones de Zend Framework, con la finalidad de construir una arquitectura de alta calidad. 44 A continuación se presenta cada una de las vistas de la nueva arquitectura del software, explicando las decisiones de diseño tomadas. Vista de casos de uso La vista de casos de uso define los escenarios en los que el usuario interactúa con el sistema y facilita a las demás vistas ilustrar el comportamiento y funcionalidad del sistema [24]. Para su construcción fueron estudiadas las distintas funcionalidades presentes en la versión anterior mediante la revisión del código fuente y pruebas no formales llevadas a cabo en navegadores web. También fue tomado en cuenta el diagrama de clases obtenido en la iteración anterior de esta fase y sus análisis correspondientes. La vista de casos de uso está organizada de acuerdo al enfoque de agrupación por paquetes de UML 2.0 [25], y se encuentra representada por el Modelo final de Casos de Uso presente en la Figura 4.5 que lista todos los casos de uso contemplados durante el proyecto, organizados en paquetes de acuerdo a su funcionalidad y objetivos. Para obtener información sobre algún caso de uso en específico, debe consultarse el Apéndice C: Especificaciones de Requerimientos del Software. La decisión de separar y organizar los casos de uso por paquetes fue inspirada por la metodología del patrón de diseño MVC, que expone la separación de elementos dependiendo de sus responsabilidades [10], y principalmente por el rango de calidad que menciona que un sistema debe poseer alta cohesión y bajo acoplamiento, es decir, que funcionalidades comunes pertenezcan a una misma clase y que clases diferentes no dependan o estén ínfimamente relacionadas unas con otras [10].

57 45 Figura 4.5. Modelo final de casos de uso para la nueva arquitectura del sistema Fuente: Elaboración propia Vista lógica La reconstrucción de la vista lógica fue orientada bajo la filosofía de desarrollo de Zend Framework, la cual sigue los lineamientos del patrón de diseño MVC que diferencia tres secciones: la sección de Modelos, la sección de Vistas y la sección de Controladores. En este sentido, las clases del sistema fueron renombradas y reorganizadas en dos áreas: el área de las clases Modelos y el área de las clases Controladores. La sección de Vistas no fue contemplada dentro de la reorganización, debido a que Zend Framework no implementa esta sección como clases, sino como archivos de presentación con contenido HTML. La reestructuración de las clases permitió reorganizar el código del sistema, asignado a cada clase sus responsabilidades dentro del sistema y desacoplando su interdependencia. La clase APP de la arquitectura anterior fue sustituida por las distintas clases de los componentes de Zend Framework, las cuales se encuentran optimizadas y débilmente acopladas.

58 La Figura 4.6 muestra un diagrama de clases con los resultados de la reorganización del modelo lógico del SRI. 46 Figura 4.6. Diagrama de clases de la nueva arquitectura del sistema. Fuente: Elaboración propia

59 47 Vista de procesos La vista de procesos describe los aspectos de diseño relacionados con la concurrencia y sincronización de los procesos e hilos que conforman el sistema [24]. Esta vista no fue considerada para el estudio del proyecto, ya que el SRI está implementado sobre el lenguaje PHP, y trabaja sobre un servidor web (Apache) cuyas peticiones son controladas por el mismo, interpretadas por el lenguaje PHP y, de ser necesario, solicitan información a un servidor de base de datos (MySQL). De esta forma, los procesos e hilos que conforman el programa pertenecen a varias aplicaciones cuya ejecución y concurrencia son controladas automáticamente por los servidores ya mencionados. Vista de implementación La vista de implementación de la nueva arquitectura fue reestructurada siguiendo el esquema formulado en la vista lógica. Se agruparon las clases con funcionalidades comunes en componentes con la finalidad de encapsular sus implementaciones y se establecieron interfaces bien definidas, con el objetivo de otorgar al sistema la capacidad de poder reemplazar componentes de ser necesario. De esta forma, se identificaron los siguientes componentes: - Reservaciones: representa la entidad de administración de reservaciones del sistema. - Ocupación: simboliza la entidad de administración y despliegue de información de la ocupación para un hotel. - Cupos: componente que encapsula las funcionalidades de consulta y disponibilidad de cupos de un hotel. - TipoHabitacion: representa la entidad que administra los tipos de habitación, habitaciones reservadas y la situación de disponibilidad y ocupación. - Hotel: encapsula las implementaciones de administración de un hotel. - Login: suministra los servicios de creación y destrucción de sesiones de usuarios.

60 Las interacciones entre los distintos componentes se representan en el diagrama de componentes de la Figura Figura 4.7. Diagrama de componentes de la nueva arquitectura del sistema. Fuente: Elaboración propia Vista de implantación En vista que la nueva versión del SRI reemplazará a la versión existente y debido a la buena experiencia que la empresa ha tenido utilizando su servidor para hospedar el sistema, se decidió conservar la misma disposición de hardware. De esta forma, la vista de implantación de la nueva arquitectura conserva las mismas características mencionadas en la vista de implantación de su versión predecesora.

61 49 Vista de datos La vista de datos tampoco sufrió alteraciones, ya que no se planificaron actividades de reestructuración de datos bajo el proceso de reingeniería. Esto se debió a que la estructura de datos fue modificada dos meses antes del comienzo del proyecto de pasantía y se realizaron ajustes importantes discutidos por los desarrolladores de. En este sentido, la vista de datos de la nueva arquitectura se rige por los lineamientos de la vista de datos de la versión previa del sistema. 4.3 Fase de Construcción Una vez finalizado el diseño de la nueva arquitectura del software, se procedió a su implementación en la fase de Construcción. Esta fase fue programada para realizarse en cuatro (4) iteraciones: las dos primeras iteraciones para realizar la implementación de las versiones web y móvil del SRI, y las dos siguientes para llevar a cabo las pruebas del sistema para cada versión. Inicialmente fue especificada en el plan de trabajo la realización de pruebas unitarias y pruebas de estrés. Las pruebas de estrés fueron llevadas a cabo exitosamente utilizando la herramienta Sellenium para pruebas de aplicaciones web (ver puntos y 4.4 de este capítulo). Sin embargo, debido a limitaciones de las capacidades de instalación en el servidor de la empresa y por restricciones del servicio de hospedaje web, no pudieron ser instaladas las librerías de la herramienta phpunit, en vista de ello no se pudieron realizar las pruebas unitarias. Éstas se pospusieron para futuras iteraciones del desarrollo del sistema. A continuación se describe cada una de las iteraciones, especificando las actividades desarrolladas y los resultados obtenidos: Primera Iteración En la primera iteración se llevó a cabo el desarrollo de la versión web de escritorio del SRI, llevando a cabo la implementación de los casos de uso propuestos y la arquitectura diseñada en la fase de elaboración.

62 La labor de desarrollo se llevó a cabo en el servidor GWT4 bajo un ambiente de desarrollo. Fueron utilizadas diversas técnicas: reutilización de software, en específico la reutilización de clases y funciones que formaban parte de la lógica de negocios de la empresa y eran de vital importancia para su funcionamiento; y también fue usada la ingeniería directa, tomando en cuenta la estructura de directorios y la nomenclatura de las clases y sus funciones, con la finalidad que el proceso de adaptación de los desarrolladores al nuevo sistema fuese más sencillo. 50 Sin embargo, la actividad más importante fue la separación de las funcionalidades del sistema siguiendo el diagrama de clases diseñado y las buenas prácticas de desarrollo de Zend Framework y el patrón de diseño MVC. Una de las dificultades que se presentaron al iniciar esta actividad fue el desconocimiento de las convenciones y capacidades de los componentes del framework, sin embargo la lectura e investigaciones sobre el tema permitieron dominar la filosofía de trabajo. Para esta iteración se finalizó el desarrollo de los casos de uso de los paquetes: Administración de Reservaciones, Administración de Ocupación y Administración de Cartelera Informativa, los cuales reunían la funcionalidad más importante. Los otros dos paquetes fueron pospuestos para la tercera iteración donde se retomaría el desarrollo y pruebas orientadas a la versión web de escritorio del SRI Segunda Iteración La segunda iteración abarcó la implementación de la versión móvil del sistema. Para llevar a cabo la diferenciación entre dispositivos móviles y computadoras de escritorio, se utilizó el componente Zend_User_Agent y una librería externa a Zend Framework, que en conjunto se encargan de comparar el user agent (ver Apéndice A: Glosario de Términos) del dispositivo que se conecta contra una base de datos conformada por una lista de dispositivos conocidos a nivel mundial para determinar si es un dispositivo móvil o no. De esta forma, el sistema renderizará la vista apropiada de acuerdo al tipo de dispositivo detectado. Se siguieron las prácticas de las investigaciones realizadas durante la fase de Inicio para desarrollar páginas que pudieran ser visualizadas correctamente en la mayoría de los dispositivos,

63 siguiendo la metodología KISS. En este sentido, se establecieron algunas convenciones para desarrollar las Vistas del sistema y garantizar su correcta visualización en el mayor porcentaje de navegadores web móviles, siguiendo las buenas prácticas de Fling [26] y el Grupo Nielsen [26], a saber: 51 Resoluciones soportadas: 240x260, 340x260, 480x360. Tecnologías web: CSS 2.1, HTML 4, HTML 5. No se permite el uso de JavaScript ni alguno de sus frameworks con orientación a web de escritorio (JQuery, MooTools, etc.). Imágenes de poco peso: las imágenes deben ser bastante ligeras (menores a 10K) y adecuarse a las resoluciones consideradas. No se deben escalar imágenes con los atributos width y height del tag img de HTML. Usar Div s en conjunto con CSS en vez de tablas: sólo los navegadores web móviles de última generación renderizan adecuadamente las tablas. Requests ligeros: el tamaño total de una página junto a sus elementos no debe pasar de 20K. Para esta iteración todos los casos de uso pudieron ser implementados correctamente, utilizando las mismas clases implementadas para la versión web de escritorio. Es necesario hacer constancia que aunque ambas versiones del sistema siguen los mismos casos de uso no siempre presentarán los mismos datos en las vistas, o informaciones iguales podrán tener diferentes formas de presentación Tercera Iteración Esta fase se inició con la implementación de los casos de uso que quedaron pendientes en la primera iteración, a saber: los casos de uso de los paquetes de Administración de Sesiones y Administración de Cupos. Seguidamente se llevaron a cabo las pruebas de estrés utilizando la herramienta Sellenium IDE Se desarrollaron dos casos de prueba de estrés, cada una con un nivel de estrés mayor que la anterior. Las pruebas no perseguían sobrecargar el sistema; se basaban un rango máximo

64 estimado que aseguraba la calidad del sistema de acuerdo a las necesidades de la empresa. La primera prueba fue denominada loginandlogout, y tenía como finalidad probar cuantos inicios y cierres de sesiones soportaba el sistema. Se estimó una cantidad máxima de 100 inicios y cierres de sesión sucesivos. Los resultados fueron satisfactorios y pueden observarse en la Figura Figura 4.8. Pruebas de estrés sobre el ambiente de desarrollo usando Sellenium IDE Fuente: Elaboración propia. La segunda prueba fue denominada logindothingslogout y se basaba en realizar un inicio de sesión y realizar la mayoría de las actividades de los distintos casos de uso, intentando sobrecargar el sistema durante la ejecución de la prueba. Esta prueba se programó 50 veces consecutivas. Los resultados fueron satisfactorios al igual que en la prueba de estrés anterior Cuarta Iteración La cuarta iteración se inició con la realización de pruebas sobre la versión móvil del sistema para verificar que los distintos casos de uso se observaban correctamente en distintos navegadores web móviles. El sistema fue probado en varios dispositivos Blackberry (modelos 8320, 8120, 8900 y 9600) con el navegador Blackberry Browser y en un Nokia E71 con el

65 53 navegador Opera Mini. Seguidamente se realizaron las mismas pruebas de estrés llevadas a cabo en la tercera iteración. Debido la imposibilidad de utilizar la herramienta Sellenium IDE en un dispositivo móvil, se emuló el user agent (ver Apéndice A: Glosario de Términos) de diferentes dispositivos desde el navegador web Firefox, para habilitar la detección y renderización adecuada y proceder a realizar las pruebas. Ambas pruebas fueron satisfactorias, obteniéndose cero (0) errores. 4.4 Fase de Transición La fase de Transición de la metodología RUP contempla la entrega del producto a los usuarios finales y hacer que éstos puedan valerse por sí mismos [19]. Esta fase no fue contemplada dentro del alcance inicial del proyecto; sin embargo, fue llevada a cabo debido a requerimientos de la empresa y su realización fue de vital importancia tanto para la empresa como para la eficiente evaluación del proyecto de pasantía, en vista de que permitió verificar la correcta funcionalidad del sistema y realizar pruebas de estrés para garantizar que la implementación realizada se ajuste adecuadamente al ambiente de producción. Para llevar a cabo estas actividades se realizó una revisión adicional de la arquitectura del software y la configuración del SRI para que pudiera ejecutarse correctamente en el ambiente de producción. Seguidamente, fueron realizadas las pruebas de estrés utilizando Sellenium IDE , realizando los mismos casos pruebas ejecutados en la fase de Construcción. Las pruebas fueron exitosas, obteniéndose cero errores y sus resultados pueden observarse en la Figura 4.9. Por otro lado, la actividad de entrenamiento de los usuarios finales no fue realizada, en vista que éstos son los mismos desarrolladores de que llevaron a cabo la implementación del sistema en su versión previa al proyecto de pasantía. Finalmente, se llevó a cabo la actualización de la documentación en línea del SRI con las decisiones y resultados obtenidos durante las fases anteriores del proyecto.

66 54 Figura 4.9. Pruebas de estrés sobre el ambiente de producción usando Sellenium IDE Fuente: Elaboración propia.

67 CAPÍTULO 5 LOGROS ADICIONALES Adicionalmente a los objetivos planteados en el plan de trabajo, se pudo realizar una serie actividades de gran significado tanto para el desarrollo del proyecto como para los procesos internos de la empresa. A continuación se describe cada uno de los logros adicionales: Fase de Transición: la puesta en marcha de la fase de Transición de RUP fue decidida debido a las necesidades de la empresa de colocar el SRI en su ambiente de producción para que otros desarrolladores continuarán la labor de desarrollo y pruebas una vez finalizado el proyecto de pasantía. Esta fase, como bien se expresó en el Capítulo 4: Desarrollo, permitió la completa evaluación del ciclo de desarrollo de software propuesta por RUP y la garantía de tener un producto 100% funcional en el entorno de destino. Implantación de buenas prácticas de Zend Framework dentro de la empresa: uno de los problemas de mayor impacto negativo en la empresa (GWT) era el tiempo que debía invertirse en mantenimiento, especialmente para arreglar bugs 2. Esta situación se daba en todos los proyectos de la misma a causa del alto grado de acoplamiento de las clases, librerías y archivos. En este sentido, los desarrolladores de la empresa realizaron una investigación en búsqueda de una buena estrategia para solucionar este problema, y concluyeron que debían optar por el uso de Zend Framework. De esta forma, decidió aprovechar el proyecto de pasantía como medio para verificar si era posible alcanzar y dominar las bondades del framework para resolver el problema de mantenibilidad. El éxito del proceso de reingeniería y la implementación de Zend Framework bajo el patrón MVC permitieron construir una arquitectura de alta calidad para el SRI, de la cual destaca su alto grado de mantenibilidad. Este resultado motivó a usar el marco de trabajo de Zend Framework para los proyectos futuros. Curso introductorio de Zend Framework para los desarrolladores de GWT: una práctica muy utilizada en las empresas es la capacitación de los desarrolladores en nuevas 2 Bug: es un error o defecto en un software que hace que un programa funcione incorrectamente.

68 tendencias y tecnologías, inscribiendo a los desarrolladores en cursos que les permitan conocer nuevos mecanismos que le permita a él mismo y a la empresa realizar sus operaciones de manera más eficiente. Sin embargo, puede resultar costoso llevar a cabo dicha inversión. De esta forma, se pidió al pasante elaborar un curso introductorio e intensivo de Zend Framework para los desarrolladores de la sede de GWT de Barquisimeto que les permitiera entender la filosofía de trabajo del framework y prepararlos para la implementación de los proyectos venideros bajo su enfoque. El curso fue realizado los días 29 y 30 de Noviembre de 2010 y fue preparado con los conocimientos adquiridos de las investigaciones y lecturas realizadas durante el proyecto de pasantía. Para la semana final del período del proyecto de pasantía, dos desarrolladores de Barquisimeto ya se encontraban implementando proyectos bajo Zend Framework. 56 Establecimiento de estándares de programación en móvil: siendo el proyecto de pasantía el primer proyecto realizado para dispositivos móviles, también se solicitó la creación de un documento que listase las características, restricciones, buenas prácticas y estándares que fueron adquiridos durante la etapa de implementación de la versión móvil del proyecto, a fin de agilizar los procesos de conocimiento e implementación por parte de otros desarrolladores de la empresa. Estos lineamientos pueden observarse en el Apéndice F: Estándares de Programación Web para Dispositivos Móviles Concepción de un nuevo proyecto: VenezuelaTuya Móvil: el enfoque móvil que fue concebido para el SRI dio paso a la creación del segundo proyecto de la empresa bajo la plataforma móvil: la página web móvil del portal VenezuelaTuya.com. Se realizó un análisis entre el tutor industrial y el pasante para definir la visión del sistema, su alcance, las tecnologías a usar y los módulos que compondrían la aplicación. La idea general del sitio web móvil consiste en obtener a la palma de la mano las distintas localidades de Venezuela y los hoteles, vuelos nacionales, casas de alquiler de automóviles, terminales de autobuses y casas de taxis disponibles en la misma. Para un futuro se quiere investigar si existe la posibilidad de detectar la ubicación de un usuario por geolocalización y presentarle los servicios que se encuentran más cercanos de acuerdo a su posición. El proyecto se realizó bajo Zend Framework, llevándose a cabo el diseño e implementación del módulo de hoteles.

69 CONCLUSIONES Y RECOMENDACIONES Las actividades programadas para el proyecto de pasantía sobre el Sistema de Reservaciones Inmediatas fueron realizadas en su totalidad de manera exitosa. La aplicación del proceso de reingeniería sobre el SRI en su versión previa al proyecto permitió obtener las abstracciones de alto nivel, diagramas y especificaciones que conformaban su arquitectura. Esta información fue analizada en conjunto con las necesidades y requerimientos recogidas durante la fase inicial del proyecto para determinar los cambios que eran necesarios realizar. Los resultados de este análisis en conjunto con las buenas prácticas de desarrollo bajo Zend Framework y su implementación del patrón Modelo Vista Controlador permitieron llevar a cabo el diseño y la implementación de una nueva versión del SRI con los enfoques web y móvil, caracterizada principalmente por disponer de una arquitectura que satisface las necesidades, rangos de calidad y objetivos planteados. Posteriormente fueron llevadas a cabo las pruebas de estrés pertinentes y se llevó a cabo la transición del sistema al ambiente de producción final. Esta actividad, aunque no fue inicialmente programada, permitió asegurar el cierre del ciclo de vida del software propuesto por la metodología RUP y garantizar el correcto funcionamiento del mismo en el entorno de producción que visitarán los usuarios finales que contraten el servicio. La nueva versión del SRI en sus dos modalidades, web y móvil, permitirán tanto a la empresa como a VenezuelaTuya poner en el mercado venezolano un producto innovador que satisfará a los posaderos y hoteleros de Venezuela permitiéndoles escoger la modalidad de uso del sistema de acuerdo a las necesidades que se les presenten. También podrán ser captados aquellos dueños de hoteles y posadas que busquen una herramienta para llevar a cabo la automatización de las operaciones de sus negocios y la gestión de sus establecimientos. Por otro lado, el éxito del proyecto de pasantía originó cambios en los lineamientos y procesos internos de la empresa. Siendo el primer proyecto realizado bajo los enfoques de Zend Framework y el enfoque móvil, el alto grado de mantenibilidad que se obtuvo al separar el código del SRI mediante el enfoque MVC fue considerado un atractivo que captó la atención de la empresa, por la posibilidad de disminuir los costos de mantenimiento y corrección de bugs que se daban en bastantes de los proyectos de la misma. En este sentido, fueron conseguidos varios

70 logros adicionales durante el período de pasantía, los cuales se resumen en la actividad de implantación del modelo de desarrollo de Zend Framework en la empresa para los proyectos venideros, con el fin de gozar de una arquitectura de alta calidad y alto grado de mantenibilidad para los mismos. 58 Finalmente, tras la culminación del proyecto de pasantía se sugieren las siguientes recomendaciones: Revisar y analizar la arquitectura de software y documentación obtenida en este proyecto para culminar la implementación del SRI. Seguir los estándares de programación móvil para desarrollar correctamente bajo el ambiente móvil. Supervisar las necesidades de los hoteleros y posaderos en búsqueda de nuevas funcionalidades que aporten valor extra al sistema. En particular, se sugiere implementar la característica multiusuario para un mismo establecimiento. Mantener el proyecto bajo control de versiones para garantizar el seguimiento de los cambios realizados por los distintos desarrolladores.

71 REFERENCIAS [1] GlobalWebtek Situación Hotelera en Venezuela Disponible en Internet: consultado el 9 de Agosto de [2] GlobalWebtek Quiénes somos? Disponible en Internet: consultado el 9 de Agosto de [4] GlobalWebtek Nuestros clientes y nuestro portafolio. Disponible en Internet: consultado el 11 de Agosto de [5] GlobalWebtek Misión, Visión y Organización. Disponible en Internet: consultado el 02 de Diciembre de [6] I. Sommerville. Ingeniería de Software. Séptima Edición. Pearson Addison Wesley, Madrid, España, [7] D. Valarezo, V. Morocho. Ingeniería de Software - Reingeniería. Universidad Técnica Particular de Loja, Ecuador, [8] E. Fernández, M. Patón. Mantenimiento del Software. Universidad de Castilla, España, [9] R. Rodríguez. Reutilización de Software. Tecnología de la Información y Comunicación. Universidad Politécnica de Puebla, México,2008. [10] R. Allen, N. Lo, S. Brown. Zend Framework in Action. Second Edition. Manning Pubblications, [11] M. Perraud. Zend Framework & MVC Introduction. Disponible en Internet: consultado el 8 de Septiembre de [12] E. Gamma, R. Helm, J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley [13] Zend Framework. Zend Framework: Documentation: Overview. Disponible en Internet: consultado el 8 de Septiembre de [14] Net2Client. Qué es Net2Client? Disponible en Internet: consultado el 7 de Agosto de [15] Net2Client. Por qué es tan chévere Net2Client? Disponible en Internet: consultado el 7 de Agosto de 2010.

72 [16] E. Traudt, A. Konary Software as a Service Taxonomy and Research Guide. IDC [17] J. Pereira. Software como Servicio. Disponible en Internet: consultado el 8 de Diciembre de [18] P. Krutchen. The Rational Unified Process: An Introduction. Addison-Wisley, Massachusetts, [19] I. Jacobason, G. Booch, J. Rumbaugh. El Proceso Unificado de Desarrollo de Software. Addison-Wisley, [20] P. Krutchen, P. Kroll. Rational Unified Process Made Easy-A Practitioner's Guide to the RUP. Addison-Wisley, Massachusetts, [21] J. Nielsen, R. Budiu. Usability of Mobile Websites. Nielsen Norman Group, USA [22] McAfee Secure. McAfee SECURE for Websites Services. Disponible en Internet: consultado el 05 de Enero de [23] VenezuelaTuya. SRI - Proyecto de Reservaciones Inmediatas. Disponible en Internet: consultado el 10 de Septiembre de [24] R. Pressman. Ingeniería del Software. Quinta Edición. McGraw Hill, España, 2002 [25] Milestone Consulting. Divide y vencerás: utilizando paquetes. Disponible en Internet: consultado el 24 de Noviembre de [26] B. Fling. Mobile Design and Development. O Reilly, USA,

73 APÉNDICE A GLOSARIO DE TÉRMINOS

74 Reingeniería del Sistema de Reservaciones Inmediatas: Aplicaciones web y móvil Sistema de Reservaciones Inmediatas Glosario de Términos Versión 1.0

75 Glosario de Términos Fecha: Historial de Revisiones Fecha Versión Descripción Autor Versión final y revisada del glosario del proyecto David Antunes Confidencial,

76 Glosario de Términos Fecha: Índice de Contenidos 1. Introducción Propósito Alcance Referencias Síntesis 5 2. Definiciones Proyecto y ámbito empresarial Sistema de Reservaciones Inmediatas SRI Hotel Posada Hotelero Posadero Venezuelatuya.com VenezuelaTuya Agente Net2Client N2C Herramientas, tecnologías y metodologías HTML CSS PHP JavaScript jquery Modelo Vista Controlador MVC Framework Zend Framework RUP UML Caso de Uso Stakeholder Software como servicio Sql Injection 9 Confidencial,

77 Glosario de Términos Fecha: Introducción Glosario de Términos 1.1 Propósito El presente documento establece la terminología adherente al dominio que abarca el Sistema de Reservaciones Inmediatas; términos que serán usados a lo largo de toda la documentación del sistema. Permite poner en contexto a cualquier persona interesada sobre el enfoque del sistema y los conceptos que definen su desarrollo. 1.2 Alcance Este documento incluye conceptos sobre las entidades tomadas en cuenta en la elaboración del sistema, además de especificar las definiciones de tecnologías y metodologías usadas durante su desarrollo. 1.3 Referencias Para la elaboración del glosario se tomaron en cuenta las conversaciones realizadas con los directores y empleados de las empresas y VenezuelaTuya, las que abarcaron el dominio del problema y el enfoque con el que fue inicialmente desarrollado el Sistema de Reservaciones Inmediatas, su alcance y las metas que pretenden alcanzarse con su implementación. De igual forma, fueron consultados los manuales de usuario y de desarrollo del sistema en su versión actual, los cuales se encuentran en línea y muestran información sobre las especificaciones y requerimientos del proyecto. Por otro lado, algunos de los conceptos fueron tomados de referencias electrónicas y del material entregado a los estudiantes de los cursos de Sistema de Información de la Universidad Simón Bolívar. Para conocer más información sobre el enfoque del proyecto y las necesidades para su creación, puede leerse el Documento de Visión del sistema. Algunas de las referencias electrónicas que se tomaron en cuenta son: : Quiénes Somos. Disponible en Internet: consultado el 08 de Confidencial,

78 Glosario de Términos Fecha: Septiembre de Wikipedia jquery. Disponible en Internet: consultado el 15 de Enero de Wikipedia HTML. Disponible en Internet: consultado el 20 de Enero de Wikipedia MVC. Disponible en Internet: consultado el 25 de Agosto de Wikipedia Software como servicio. Disponible en Internet: consultado el 15 de Enero de Wikipedia Stakeholders. Disponible en Internet: consultada el 10 de Septiembre de VenezuelaTuya - SRI. Guía de Usuario del SRI. Disponible en Internet: consultado el 10 de Septiembre de VenezuelaTuya - SRI. Sitio de Desarrollo del SRI. Disponible en Internet: consultado el 25 de Septiembre de Real Academia Española. Diccionario de la Real Academia Española 22º edición. Disponible en Internet: consultado el 15 de Enero de IngenieroSoftware. UML: Casos de uso. Disponible en Internet: consultado el 15 de Enero de W3C. Guía breve de CSS. Disponible en Internet: consultado el 20 de Enero de Síntesis En las siguientes páginas se definen los términos y conceptos organizados de acuerdo a las siguientes categorías: proyecto y ámbito empresarial; herramientas, tecnologías y metodologías. Confidencial,

79 Glosario de Términos Fecha: Definiciones 2.1 Proyecto y ámbito empresarial Sistema de Reservaciones Inmediatas Es el sistema que se está desarrollando y redefiniendo en este proyecto. Fue creado para ofrecer al público un medio donde pudieran realizar reservaciones en los hoteles de su preferencia a través de Internet; y por otro lado facilitar a posaderos y hoteleros un servicio donde pudiesen administrar de forma privada las reservaciones y la disponibilidad de habitaciones de su establecimiento SRI Siglas del Sistema de Reservaciones Inmediatas Hotel Establecimiento que ofrece, principalmente, servicios de alojamiento a huéspedes y viajeros Posada Ídem a la definición Hotelero Dueño y administrador principal de un hotel al que se le ofrece el SRI Posadero Dueño y administrador principal de una posada al que se le ofrece el SRI Venezuelatuya.com Portal web que muestra información de los destinos, tradiciones y cultura de Venezuela a todo el mundo; además comparte información de hoteles y posadas, permitiendo a los usuarios realizar reservaciones electrónicas que serán administradas directamente por el establecimiento a través del SRI. Confidencial,

80 Glosario de Términos Fecha: VenezuelaTuya Empresa que administra el portal venezuelatuya.com y el SRI, además de ofrecer servicios de agencia de viajes y contacto a hoteles Agente Es un asesor de servicios de VenezuelaTuya que presta asesoría al público sobre viajes y paquetes turísticos y también da soporte a los hoteleros en el manejo del SRI Empresa desarrolladora de software que presta asesoría a otras empresas para generar estrategias que potencien la forma en que realizan negocios en Internet. Se encarga del desarrollo y mantenimiento del portal venezuelatuya.com y del SRI Net2Client Es una herramienta web creada por la empresa que interactúa con el manejador de base de datos MySQL y que permite a sus usuarios crear bases de datos relacionales ajustadas a los modelos y procesos de negocio de sus empresas N2C Acrónimo de Net2Client. 2.2 Herramientas, tecnologías y metodologías HTML Siglas de HyperText Markup Language ó Lenguaje de Marcado de HiperTexto. Es el lenguaje de marcado predominante que se utiliza para definir la estructura y el contenido de una página web CSS Siglas de Cascading Style Sheets u Hojas de Estilo en Cascada. Es un mecanismo para dar estilo a documentos HTML, separando el contenido de la presentación. Confidencial,

81 Glosario de Términos Fecha: PHP Lenguaje de programación orientado a objetos originalmente diseñado para el ambiente de desarrollo web y la creación de páginas web con contenido dinámico JavaScript Es un lenguaje de programación interpretado, ofrecido del lado del cliente que permite crear páginas web dinámicas y mejoras en las interfaces de usuario jquery Es un framework de desarrollo para JavaScript, de código abierto, que ofrece numerosas funcionalidades para expandir las ya ofrecidas por dicho lenguaje y permite construir páginas web dinámicas de carácter avanzado escribiendo mucho menos código Modelo Vista Controlador Patrón de diseño de software que separa la lógica de datos de una aplicación, la interfaz de usuario y la lógica de negocio en tres componentes distintos. Esto permite estructurar el código fuente para que pueda ser reusable y mantenible MVC Acrónimo del Modelo Vista Controlador Framework Es una estructura conceptual y tecnológica de soporte definida que puede ser utilizada en un proyecto para organizar y llevar a cabo su desarrollo. Provee una metodología de trabajo que facilita, básicamente, el desarrollo de software Zend Framework Es un framework de desarrollo web para PHP, open source y orientado a objetos completamente. Utiliza el patrón de diseño MVC para separar la lógica de negocio, la interfaz de usuario y el modelo de datos RUP El Proceso Unificado de Rational (Rational Unified Process, cuyas siglas forman RUP) es una metodología de desarrollo de software que constituye la metodología estándar para el análisis, implementación y documentación de sistemas orientados a objetos. Confidencial,

82 Glosario de Términos Fecha: UML UML deriva de Unified Modeling Language o Lenguaje Unificado de Modelado, es el lenguaje de modelado de sistemas de software más conocido y utilizado actualmente. Es un lenguaje gráfico que permite visualizar, especificar, construir y documentar un sistema Caso de Uso Es una técnica de captura de requisitos que forma parte de los estándares de UML. Consta de un diagrama y una tabla que en conjunto especifican la interacción del sistema con el usuario Usuario Es cualquier persona que utiliza un programa, sistema operativo, servicio o cualquier sistema informático. El término usuario también se pueda aplicar a dispositivos o programas, los cuales también pueden interactuar con otros sistemas informáticos Stakeholder Término inglés que se refiere a aquella persona o grupo que afecta o puede ser afectado por un proyecto en particular. En otras palabras, es el público interesado o involucrado en el proyecto cuyas necesidades deben tomarse en cuenta para la planificación y desarrollo del mismo Software como servicio Es un software que se despliega en internet donde la compañía que lo desarrolla se encarga del mantenimiento, operación diaria, hospedaje y soporte del mismo, en vez de delegarle dichas operaciones al usuario final. Al ser desplegado en internet puede ser accedido desde cualquier computadora a través de un navegador web Sql Injection Es una técnica que aprovecha las vulnerabilidades de un sistema, mediante la cual personas no autorizadas pueden acceder a datos privados utilizando ciertos comandos para interactuar con el manejador de base de datos. Se origina principalmente debido a malas prácticas de programación que dejan huecos de seguridad en el sistema. Confidencial,

83 Glosario de Términos Fecha: KISS Acrónimo de Keep It Simple and Stupid o Keep It Simple and Short. Es un principio que establece que la simplicidad debe ser un objetivo para el diseño de algún proyecto o actividad, y que la complejidad innecesaria debe ser evitada User Agent En español significa Agente de Usuario y representa la aplicación cliente usada para un protocolo de red particular, aunque es particularmente usado para refererirse a los que acceden a la Internet, también llamados web user agents. Éstos pueden ser navegadores, arañas de los buscadores, teléfonos celulares, entre otros. Confidencial,

84 APÉNDICE B DOCUMENTO DE VISIÓN

85 Reingeniería del Sistema de Reservaciones Inmediatas: Aplicaciones web y móvil Sistema de Reservaciones Inmediatas Documento de Visión Versión 1.0

86 Documento de Visión Fecha: Historial de Revisiones Fecha Versión Descripción Autor Versión final y revisada del documento de visión del proyecto David Antunes Confidencial,

87 Documento de Visión Fecha: Índice de Contenidos 1. Introducción Propósito Alcance Definiciones, Acrónimos y Abreviaturas Referencias Síntesis 7 2. Posicionamiento Oportunidades de Negocio Declaración del Problema Declaración del Posicionamiento del Producto 9 3. Descripciones de los Stakeholders y Usuarios Demografía del Mercado Resumen de los Stakeholders o Interesados Resumen de los Usuarios Ambiente de Usuarios Perfil de los Stakeholders o Interesados Hoteleros y posaderos de Venezuela VenezuelaTuya Perfiles de Usuario Hotelero Público Agente Necesidades de los Stakeholders y Usuarios Alternativas y Competencia Descripción del Sistema Perspectiva del Sistema Resumen de Capacidades Suposiciones y Dependencias Costos y Precios Licencias e Instalación Características del Sistema Características a nivel de software Características a nivel de funcionalidad Restricciones Rangos de Calidad Precedencia y Prioridad Otros Requerimientos del Sistema Estándares Aplicables Requerimientos del Sistema 24 Confidencial,

88 Documento de Visión Fecha: Requerimientos de Desempeño Requerimientos de Ambiente Requerimientos de Documentación Manual de Usuario y Ayuda en Línea Guías de Instalación, configuración y archivos Readme Etiquetas y Paquetes 25 Confidencial,

89 Documento de Visión Fecha: Documento de Visión 3. Introducción 3.1 Propósito El propósito de este documento consiste en recoger, analizar y definir las razones que conllevan a realizar la reingeniería del Sistema de Reservaciones Inmediatas. Se exponen las necesidades de alto nivel por parte de los usuarios finales (clientes), las características del sistema, los requerimientos generales y las metas que se desean alcanzar con su futura implantación en el mercado. 3.2 Alcance Este documento abarca principalmente los elementos que conforman la visión del proyecto de Reingeniería del Sistema de Reservaciones Inmediatas: aplicaciones web y móvil. También se incluyen algunos aspectos de los proyectos encargados del desarrollo del portal VenezuelaTuya y del Sistema de Reservaciones Inmediatas en su versión previa. 3.3 Definiciones, Acrónimos y Abreviaturas La terminología usada en este documento proviene del Glosario del proyecto. Sin embargo, a continuación se mencionan los términos más importantes que serán usados a lo largo del Documento de Visión: Sistema de Reservaciones Inmediatas: es el sistema que se está desarrollando y redefiniendo en este proyecto. Fue creado para ofrecer al público un medio donde pudieran realizar reservaciones en los hoteles de su preferencia a través de Internet; y por otro lado facilitar a posaderos y hoteleros un servicio donde pudiesen administrar de forma privada las reservaciones y la disponibilidad de habitaciones de su establecimiento. SRI: siglas del Sistema de Reservaciones Inmediatas. Venezuelatuya.com: portal web que muestra información de los destinos, tradiciones y cultura de Venezuela a todo el mundo; además comparte información de hoteles y posadas, permitiendo a los usuarios realizar reservaciones electrónicas que serán administradas directamente por el establecimiento a través del SRI. VenezuelaTuya: empresa que administra el portal venezuelatuya.com y el SRI, además de ofrecer servicios de agencia de viajes y contacto a hoteles. Confidencial,

90 Documento de Visión Fecha: : empresa desarrolladora de software que presta asesoría a otras empresas para generar estrategias que potencien la forma en que realizan negocios en Internet. Se encarga del desarrollo y mantenimiento del portal venezuelatuya.com y del SRI. Modelo Vista Controlador: patrón de diseño de software que separa la lógica de datos de una aplicación, la interfaz de usuario y la lógica de negocio en tres componentes distintos. Esto permite estructurar el código fuente para que pueda ser reusable y mantenible. MVC: acrónimo del Modelo Vista Controlador. Framework: es una estructura conceptual y tecnológica de soporte definida que puede ser utilizada en un proyecto para organizar y llevar a cabo su desarrollo. Provee una metodología de trabajo que facilita, básicamente, el desarrollo de software. Zend Framework: es un framework de desarrollo web para PHP, open source y orientado a objetos completamente. Utiliza el patrón de diseño MVC para separar la lógica de negocio, la interfaz de usuario y el modelo de datos. Stakeholder: término inglés que se refiere a aquella persona o grupo que afecta o puede ser afectado por un proyecto en particular. En otras palabras, es el público interesado o involucrado en el proyecto cuyas necesidades deben tomarse en cuenta para la planificación y desarrollo del mismo. Software como servicio: es un software que se despliega en internet donde la compañía que lo desarrolla se encarga del mantenimiento, operación diaria, hospedaje y soporte del mismo, en vez de delegarle dichas operaciones al usuario final. Al ser desplegado en internet puede ser accedido desde cualquier computadora a través de un navegador web. 3.4 Referencias Para la elaboración de este documento se tomaron en cuenta las múltiples opiniones obtenidas durante entrevistas con posaderos y hoteleros realizadas por el equipo de y VenezuelaTuya, así como las estrategias de negocio planificadas a partir de dichas opiniones. De igual forma, se utilizó todo el material entregado a los estudiantes de los cursos de Sistema de Información de la Universidad Simón Bolívar, que abarca, entre otras cosas, los procesos y técnicas de obtención de datos para los documentos de Visión, Arquitectura, Pruebas y Glosario. La información descrita en este documento puede ser completada con las notas contenidas en el Glosario de términos y el Documento de Requerimientos de Software. Confidencial,

91 Documento de Visión Fecha: También se tomó en consideración los datos de las siguientes referencias bibliográficas y electrónicas: Rivas, L., Documento de Visión del Sistema, Universidad Simón Bolívar, Departamento de Procesos y Sistemas : Quiénes Somos. Disponible en Internet: consultado el 08 de Septiembre de Wikipedia MVC. Disponible en Internet: consultada el 25 de Agosto de Wikipedia Stakeholders. Disponible en Internet: consultada el 10 de Septiembre de VenezuelaTuya - SRI. Guía de Usuario del SRI. Disponible en Internet: consultado el 10 de Septiembre de VenezuelaTuya - SRI. Sitio de Desarrollo del SRI. Disponible en Internet: consultado el 25 de Septiembre de Carles Güell. Webs multidispositivo. Disponible en Internet: consultado el 20 de Noviembre de Síntesis El documento de visión se encuentra estructurado en 10 secciones, entre las cuales cabe mencionar: posicionamiento del proyecto; identificación de usuarios y stakeholders; definición y características del sistema; identificación de requerimientos; entre otras. Confidencial,

92 Documento de Visión Fecha: Posicionamiento 4.1 Oportunidades de Negocio A pesar del auge tecnológico que está viviendo Venezuela en los últimos años, son muchas las regiones de la nación que aún no disfrutan de las bondades que ofrece la red de redes o Internet. En el ámbito hotelero, muchos hoteles y posadas se encuentran ubicados en zonas retiradas que poseen acceso limitado o poco fiable a Internet. Incluso, en el peor de los casos, no poseen cobertura alguna. Esta situación priva a los dueños de los establecimientos la posibilidad de utilizar los servicios que ofrece la Internet para automatizar los procesos de sus negocios, además de limitar las formas de comunicación a las cuales estamos acostumbrados y que son necesarias hoy en día. Un estudio realizado por revela que son muchos los posaderos y hoteleros que en vista de esta limitación, recurren a la tecnología móvil para conectarse a Internet y realizar la mayoría de las tareas que realizan en sus computadoras de escritorio a través de sus dispositivos móviles, además de poder administrar su establecimiento sin necesidad de estar presente en el mismo. De igual forma, dicho estudio mostró que no existe actualmente en Venezuela ningún servicio o aplicación para tecnología móvil que permita automatizar los procesos de negocio concernientes a los hoteles y posadas. Para ayudar a los hoteleros y posaderos en la tarea de administrar sus establecimientos, desarrolló inicialmente el Sistema de Reservaciones Inmediatas o SRI, el cual fue desarrollado bajo tecnología web para computadoras de escritorio. Consta de dos secciones: una sección de acceso privado orientada a los hoteleros y posaderos, donde éstos puedan administrar las reservaciones y la situación de ocupación de su establecimiento; y una sección de acceso público dedicada a cualquier usuario, en la que podrán realizar reservaciones de habitaciones que posteriormente serán administradas por los hoteleros. Sin embargo, dicho sistema no fue diseñado bajo un esquema de abstracción por capas, por lo que contiene la lógica de negocio y las rutinas de acceso a datos fuertemente ligadas con la capa de presentación visual. Dentro de la empresa, este inconveniente genera un nivel alto de dificultad a la hora de realizar mantenimiento o implementar nuevas funcionalidades. En vista de la creciente demanda de uso de dispositivos móviles por parte de los hoteleros y posaderos, y tomando en cuenta la situación del SRI en su versión actual, se realizará primero una reingeniería del mismo considerando el patrón de diseño MVC que garantice la reestructuración del código fuente y a su vez facilite la mantenibilidad del sistema para futuros desarrollos. Para efectos del proyecto, sólo se realizará la reingeniería de la sección orientada a los hoteleros y posaderos. Una vez finalizado este proceso, el nuevo sistema servirá de base para llevar a cabo el desarrollo de una versión móvil que será denominada Sistema de Reservaciones Inmediatas Móvil o SRI Móvil, con miras a expandir el servicio ofrecido por el SRI y satisfacer la demanda previamente descrita. Confidencial,

93 Documento de Visión Fecha: Declaración del Problema El problema de Afecta a Cuyo impacto es Una solución exitosa sería El acceso limitado o nulo a Internet que se da en algunas regiones de Venezuela, así como la ausencia de un sistema que permita automatizar los procesos de negocio de hoteles y posadas. Hoteleros y posaderos del país La ineficiencia en los procesos de administración de reservaciones y disponibilidad de habitaciones de sus establecimientos; limitar las posibilidades de comunicación a nivel web. Implementar un sistema de interfaz amigable y fácil uso orientado a los paradigmas web y móvil, que facilite las tareas comunes de administración de hoteles y posadas, y potencie la productividad de las mismas. 4.3 Declaración del Posicionamiento del Producto Para Quién El Sistema de Reservaciones Inmediatas Que Cualquier hotelero o posadero de Venezuela Actualmente no cuente con una conexión a internet fiable y/o tampoco posea una herramienta que le permita automatizar la administración de habitaciones de su negocio de forma electrónica Es un sistema web de fácil uso e interfaz amigable, que permite visualizar y administrar las reservaciones y disponibilidad de habitaciones de un establecimiento, de manera rápida y segura. Constará de dos enfoques o versiones: la primera orientada a computadoras de escritorio y la segunda enfocada a telefonía móvil. Permitirá a los hoteleros y posaderos administrar sus establecimientos. En el caso de la versión móvil, los hoteleros podrán administrar su negocio desde sus teléfonos móviles, sin necesidad de estar presente en el mismo. En ambas versiones podrán realizarse actividades como por ejemplo: Visualizar de forma rápida la situación de ocupación y reservaciones diarias, esto es, el número de habitaciones y personas que ocupan el establecimiento, así como el número de reservaciones realizadas en ese día. Confidencial,

94 Documento de Visión Fecha: Registrar nuevas reservaciones y controlar las ya existentes; visualizar los datos de los clientes y verificar el status de pago asociado. Consultar y controlar la disponibilidad de cupos para reservaciones en una fecha indicada. Generar reportes dinámicos de ocupación y reservaciones organizados por: tipos de habitación del establecimiento; personas; fechas, entre otros criterios. En general, permitirá a los dueños de los establecimientos agilizar y facilitar la toma de decisiones que realizarán diariamente para administrar su negocio. A diferencia de Nuestro producto Cualquier otro sistema, el Sistema de Reservaciones Inmediatas es un sistema único e innovador, es pionero en el uso de tecnología móvil dentro del ámbito hotelero venezolano. Se ajusta a las necesidades y procesos de negocio de los hoteleros y posaderos de Venezuela, presentando información de forma resumida y oportuna para que éstos puedan tomar decisiones rápidas y acertadas. Adicionalmente, es un sistema multidispositivo, esto es, puede utilizarse desde cualquier computadora de escritorio o desde cualquier dispositivo móvil, conservando siempre una interfaz amigable, de fácil uso y de carácter intuitivo. 5. Descripciones de los Stakeholders y Usuarios 5.1 Demografía del Mercado El SRI está orientado al ambiente hotelero de Venezuela, esto es, a todos aquellos clientes propietarios de hoteles y posadas venezolanos. Gracias a la gran aceptación que ha recibido el portal venezuelatuya.com y al auge de la tecnología móvil en los últimos años, este es el momento ideal para desarrollar y lanzar al mercado nuestro producto enfocado al entorno móvil. Siendo este paradigma la tendencia de hoy en día, esta versión del sistema permitirá capturar a una gran cantidad de hoteleros y posaderos que encontrarán en el mismo una herramienta que complementará y facilitará las actividades diarias en su negocio. Confidencial,

95 Documento de Visión Fecha: Resumen de los Stakeholders o Interesados Nombre Descripción Responsabilidades Hoteleros y posaderos de Venezuela VenezuelaTuya Son los clientes a los cuales está dirigido el sistema, y cuyas necesidades y tendencias determinan como se desarrollará el mismo. Son propietarios de hoteles y/o posadas. Empresa desarrolladora de software encargada del diseño, implementación e implantación del sistema Empresa que administra el portal venezuelatuya.com y ofrece los servicios del SRI Administran sus establecimientos apoyándose de las funcionalidades del sistema. Aportar feedback a los desarrolladores a través de sus opiniones y necesidades crecientes. Recoger requerimientos y necesidades de los usuarios finales. Analizar y diseñar la arquitectura del sistema. Implementar e implantar el sistema Garantizar su mantenibilidad. Monitorear que las necesidades de los usuarios se satisfagan efectivamente. Garantizar que el sistema esté a la vanguardia tecnológica. Captar a los clientes hoteleros y posaderos que necesiten el sistema. Administrar las cobranzas del sistema a los clientes registrados. Analizar las necesidades crecientes de los clientes y comunicárselas a los desarrolladores de. 5.3 Resumen de los Usuarios Nombre Descripción Responsabilidades Representado por Hotelero Dueño y administrador principal de un hotel o posada. Administrador del sistema, posee todos los privilegios sobre el mismo. Utiliza el SRI para administrar su establecimiento. Consulta las situaciones de ocupación y de reservaciones diarias. Consulta los datos y el status de pago de sus huéspedes. Realiza reservaciones de nuevos huéspedes. Genera reportes dinámicos de reservaciones y ocupación de habitaciones. Hoteleros y posaderos de Venezuela Confidencial,

96 Documento de Visión Fecha: Agente Asesor de servicios de VenezuelaTuya. Es el super usuario del sistema, administra todas las cuentas de todos los hoteles registrados al SRI. Vende y presta asesoría al Público sobre viajes y paquetes turísticos. Presta soporte a los Hoteleros sobre el manejo del SRI. Administra y supervisa las cuentas de los Hoteleros registrados en caso de fallas o errores reportados. Genera reportes sobre las necesidades crecientes del Público y los Hoteleros. VenezuelaTuya Público Es cualquier persona que realiza una reservación a un hotel utilizando el servicio de Reservaciones Inmediatas de venezuelatuya.com. Su reservación será administrada en el SRI por los hoteleros Visita el portal venezuelatuya.com para buscar información de Venezuela y planes de viaje y hospedaje. Realiza reservaciones en cualquier hotel que preste el servicio de Reservaciones Inmediatas de VenezuelaTuya 5.4 Ambiente de Usuarios El SRI en sus dos versiones se ofrecerá como un SAAS ó Software As A Service (Software como Servicio), es decir, se desplegará en internet pudiendo accederse al mismo desde cualquier parte, sin que la empresa que adquiere el servicio tenga que invertir en costos de mantenimiento. Ambas versiones serán desarrolladas con tecnologías web. En el caso de la versión móvil, ésta podrá accederse desde cualquier teléfono móvil que posea un navegador web. La sección privada del SRI, dedicada a los hoteleros y posaderos, estará integrada al ambiente público donde los usuarios podrán realizar sus reservaciones. Específicamente, compartirán la estructura de datos pero no la lógica de negocio, de tal forma que las reservaciones hechas por los usuarios en el portal serán las mismas que administrarán los hoteleros en la sección privada del SRI. Confidencial,

97 Documento de Visión Fecha: Perfil de los Stakeholders o Interesados Hoteleros y posaderos de Venezuela Representatividad Descripción Tipo Responsabilidades Dueños de hoteles y posadas de Venezuela Empresarios que administran los establecimientos hoteleros, tanto a nivel económico como a nivel organizativo. Expertos en el área turística venezolana. Saben cómo atender a los clientes y organizan estrategias para captar futuros huéspedes, sus establecimientos están preparados para satisfacer las diversas necesidades de sus clientes Administrar sus establecimientos utilizando las funcionalidades del sistema. Aportar feedback a los desarrolladores a través de sus opiniones y necesidades crecientes. Criterios de Éxito Nivel de Participación Si la realización de sus procesos de negocio puede lograrse en menos tiempo y con mayor efectividad utilizando el sistema. Es el stakeholder de mayor importancia, ya que el sistema está diseñado a la medida de sus procesos de negocio y sus necesidades. A medida que vayan evolucionando las exigencias de los hoteleros y posaderos, será necesario adaptar el sistema para garantizar su éxito Representatividad Descripción Tipo Responsabilidades Socios, desarrolladores de software y demás empleados de la empresa Empresa desarrolladora de software que se encarga del diseño, implementación e implantación del SRI en sus dos versiones. Especialistas en el área de desarrollo web y en la concepción de aplicaciones para otras empresas que les permitan encontrar formas efectivas de realizar negocios a través de la red Recoger requerimientos y necesidades de los usuarios finales. Analizar y diseñar la arquitectura del sistema. Implementar e implantar el sistema. Confidencial,

98 Documento de Visión Fecha: Garantizar su mantenibilidad. Monitorear que las necesidades de los usuarios se satisfagan. Garantizar que el sistema esté a la vanguardia tecnológica. Criterios de Éxito Nivel de Participación Entregables Que el producto se consolide a nivel nacional como una de las mejores herramientas para automatizar y ayudar a los hoteleros en la administración de sus negocios y se satisfagan las necesidades de los mismos. El nivel participativo es elevado, puesto que la empresa se encargará del diseño, desarrollo, implantación y mantenimiento del sistema. Se elaborarán adicionalmente los siguientes documentos de acuerdo a la metodología RUP: Glosario, Documento de Requerimientos de Software (ERS), Documento de Arquitectura y Plan de Pruebas VenezuelaTuya Representatividad Descripción Tipo Responsabilidades Criterios de Éxito Socios y empleados de la empresa Empresa que administra el portal venezuelatuya.com y el servicio del SRI. Profesionales en el ámbito turístico de Venezuela: conocen sus destinos, regiones, costumbres y cultura. También son expertos en ventas y asesoría de planes turísticos, reservaciones, hoteles, etc. Captar a los clientes hoteleros y posaderos que necesiten el sistema. Administrar las cobranzas del sistema a los clientes registrados. Analizar las necesidades crecientes de los clientes y comunicárselas a los desarrolladores de. Si se alcanza un mayor nivel de calidad en los servicios prestados a hoteleros y posaderos. Si aumenta el número de hoteles que contratan servicios con VenezuelaTuya, en especial aquellos que elijan el servicio del SRI. Si el producto se consolida a nivel nacional como una de las Confidencial,

99 Documento de Visión Fecha: mejores herramientas para automatizar y ayudar a los hoteleros en la administración de sus negocios y se satisfagan las necesidades de los mismos. Nivel de Participación VenezuelaTuya se encargará de asignar agentes de viajes y delegarles las actividades de asesoría de viajes y paquetes a usuarios del portal, así como brindar soporte a los hoteleros que utilicen el SRI. 5.6 Perfiles de Usuario Hotelero Representatividad Descripción Tipo Responsabilidades Criterios de Éxito Nivel de Participación Otros Aspectos Dueños de hoteles y posadas de Venezuela Empresarios que administran los establecimientos hoteleros, tanto a nivel económico como a nivel organizativo. Es el Administrador del sistema, posee todos los privilegios sobre el mismo. Expertos en el área turística venezolana. Saben cómo atender a los clientes y organizan estrategias para captar futuros huéspedes, sus establecimientos están preparados para satisfacer las diversas necesidades de sus usuarios Utiliza el SRI para administrar su establecimiento. Consulta las situaciones de ocupación y de reservaciones diarias. Consulta los datos y el status de pago de sus huéspedes. Realiza reservaciones de nuevos huéspedes. Genera reportes dinámicos de reservaciones y ocupación de habitaciones. Si la realización de sus procesos de negocio puede lograrse en menos tiempo y con mayor efectividad utilizando el sistema Al ser administrador del sistema, puede realizar todas las operaciones y funcionalidades del mismo. Sus opiniones darán feedback a los agentes sobre qué aspectos son efectivos para el usuario y cuáles aspectos no se encuentran presentes y deben tomarse en consideración para futuras versiones. Puede solicitar ayuda y soporte a los agentes de VenezuelaTuya en caso de cualquier inquietud que se le presente. Confidencial,

100 Documento de Visión Fecha: Público Representatividad Descripción Tipo Responsabilidades Criterios de Éxito Nivel de Participación Otros aspectos Usuarios en general Es cualquier persona que realiza una reservación a un hotel dentro del portal venezuelatuya.com. Su reservación será administrada en la sección privada del SRI por parte de los hoteleros. No debe tener ninguna experiencia en particular Visita el portal venezuelatuya.com para buscar información de Venezuela y planes de viaje y hospedaje. Realiza reservaciones en cualquier hotel que ofrezca el servicio de Reservaciones Inmediatas de VenezuelaTuya Si logra realizar efectivamente una reservación Aportan al sistema sus datos personales y los datos de control de las reservaciones efectuadas. Estos datos serán los mismos que administre un Hotelero a través de la sección privada del SRI No puede acceder a la sección privada del SRI ni tampoco tiene contacto directo con el mismo Agente Representatividad Descripción Tipo Responsabilidades Agentes de viaje de VenezuelaTuya Es la persona encargada de dar asesoría y soporte a los usuarios que contratan servicios con VenezuelaTuya. Es el super usuario del sistema, administra todas las cuentas de todos los hoteles registrados al SRI. Profesionales en el ámbito turístico de Venezuela: conocen sus destinos, regiones, costumbres y cultura. También son expertos en ventas y asesoría de planes turísticos, reservaciones, hoteles, etc. Vende y presta asesoría al Público General sobre viajes y paquetes turísticos. Presta soporte a los Hoteleros y sus empleados sobre el manejo del SRI. Administra y supervisa las cuentas de los Hoteleros registrados en caso de fallas o errores reportados. Genera reportes sobre las necesidades crecientes del Público general y los Hoteleros. Confidencial,

101 Documento de Visión Fecha: Criterios de Éxito Nivel de Participación Si se alcanza un mayor nivel de calidad en los servicios prestados a hoteleros y posaderos. Si aumenta el número de hoteles que contratan servicios con VenezuelaTuya, en especial aquellos que elijan el servicio de Reservaciones Inmediatas. Si el producto se consolida a nivel nacional como una de las mejores herramientas para automatizar y ayudar a los hoteleros en la administración de sus negocios y se satisfagan las necesidades de los mismos. Utiliza el sistema de manera constante: para administrar las cuentas de los usuarios del SRI; supervisar los datos en caso de confusiones, errores y/o fallas reportadas; dar soporte y ayuda a los usuarios Hoteleros, entre otras actividades. 5.7 Necesidades de los Stakeholders y Usuarios Necesidad Prioridad Preocupación Solución Actual Soluciones propuestas Disponer de una herramienta que les permita a los hoteleros administrar de forma eficiente sus establecimientos Alta Ineficiencia en las actividades de administración de habitaciones de un hotel Llevar el registro de sus operaciones manualmente en agendas o programas electrónicos no dedicados Desarrollar y ofrecer el SRI para ayudar a los hoteleros a automatizar sus procesos de negocio Ofrecer a los hoteleros la capacidad de controlar su establecimiento sin estar presente en el mismo Alta El hotelero siempre debe estar presente en su establecimiento para atender nuevas reservaciones y para tomar decisiones que afecten sus actividades diarias Existen soluciones limitadas, como atender llamadas a celular y anotarlas en una agenda, pero luego habría que pasarlas al entorno donde se administran. Esto no aplica para verificar la disponibilidad de su establecimiento Elaborar una versión móvil del sistema que permita a los hoteleros administrar la situación de su hotel desde cualquier lugar sin estar presente físicamente en el mismo El sistema debe poder usarse desde cualquier parte y desde cualquier plataforma de hardware y software Alta Muchos establecimientos no tienen un servicio de internet confiable y además utilizan sistemas operativos distintos. De esta forma, existe una demanda de usuarios que aún queda por satisfacer El SRI en su versión actual es un sistema multiplataforma web que puede ser visitado mediante cualquier navegador web. No obstante depende de un buen servicio de Internet y del uso de un dispositivo de escritorio, como una computadora personal o una laptop El SRI móvil permitirá que el sistema pueda ser usado desde cualquier dispositivo de telefonía móvil, permitiendo a los hoteleros usar el sistema desde cualquier lugar y sin necesidad de estar afiliado a un servicio de acceso a internet Confidencial,

102 Documento de Visión Fecha: Alternativas y Competencia Los competidores de nuestro sistema no se encuentran en Venezuela. El Sistema de Reservaciones Inmediatas es un producto fresco en el mercado venezolano que pretende innovar la forma en que los hoteleros administran sus establecimientos. Otras alternativas al uso del SRI consisten en llevar en un registro manual, ya sea en una agenda o en un programa electrónico de procesamiento de datos (como Microsoft Excel, OpenOffice Spreadsheet o Google Spreadsheet), las reservaciones de los clientes. Sin embargo, este método tiene algunos aspectos en contra: no permite generar reportes ni resúmenes de una forma sencilla; es ineficiente a la hora de realizar búsquedas por fecha o por huésped; entre otros. 6. Descripción del Sistema Esta sección proporciona una visión de alto nivel de las capacidades del sistema, su interrelación con otras aplicaciones y su configuración. 6.1 Perspectiva del Sistema El SRI consta de dos secciones: una sección privada dedicada a los hoteleros en la que podrán administrar la situación de reservaciones y ocupación de sus establecimientos; y una sección pública orientada al público en general, donde podrán realizar reservaciones de habitaciones en hoteles que cuenten con el servicio de Reservas Inmediatas, de tal forma que sus reservaciones serán atendidas posteriormente por los hoteleros. El proyecto comprende únicamente la reingeniería de la sección privada del sistema, por lo que los requerimientos para su rediseño e implementación estarán enfocados principalmente en las necesidades y procesos de negocio de los hoteleros y posaderos. La sección pública del sistema también requerirá realizar un proceso de reingeniería para lograr acoplarla adecuadamente a la sección privada, sin embargo, no forma parte del alcance del proyecto. 6.2 Resumen de Capacidades Beneficios Descripción Incremento del número de clientes potenciales El sistema será desarrollado bajo tecnología web. Contará con una versión para computadoras de escritorio y una versión para teléfonos móviles, de tal forma que sea un sistema multiplataforma y multidispositivo. De esta forma se expande el alcance del sistema a muchos más usuarios, en especial a aquellos que no posean un servicio de Internet confiable Confidencial,

103 Documento de Visión Fecha: Automatización de procesos de negocio Facilidad de uso Mayor accesibilidad Reducción de los costos de soporte y mantenimiento El hotelero podrá automatizar sus procesos de negocio, llevando por sí mismo la administración de las situaciones de ocupación y reservaciones de su establecimiento. La interfaz gráfica del sistema será sencilla y de carácter intuitivo; poseerá un menú de navegación para organizar los distintos procesos de negocio y facilitar el aprendizaje de las funcionalidades del sistema El SRI será desplegado en Internet como un SAAS y será mantenido por. De esta forma, podrá ser accedido desde cualquier parte. En el caso de la versión móvil, está podrá ser accedida por Internet o alternativamente a través de la red del proveedor de telefonía móvil Gracias al enfoque SAAS, la contratación del servicio del SRI no necesitará de ninguna instalación ni tampoco invertir en costos de mantenimiento por parte del usuario hotelero Además, el sistema contará con un manual de usuario en línea creado bajo el servicio de Google Sites, que permite la navegación por hiperlinks y provee del motor de búsquedas de Google 6.3 Suposiciones y Dependencias El sistema debe poseer una interfaz gráfica sencilla y de fácil uso. Debe poder accederse y visualizarse correctamente desde cualquier navegador web de cualquier dispositivo y/o sistema operativo. El usuario que use el sistema deberá tener conexión a Internet o un teléfono móvil con acceso a Internet usando la red de la compañía móvil asociada. Se desarrollará tomando en cuenta los procesos de negocio de hoteleros y posaderos. Estará implementado bajo el lenguaje de programación PHP 5.0. Su diseño e implementación seguirán el patrón MVC utilizando Zend Framework 1.10 para PHP. A nivel visual, se utilizarán los lenguajes de maquetación HTML y CSS. De igual forma se empleará el lenguaje JavaScript y su framework JQuery 1.4 El manejador de base datos será MySQL 5.1. La base de datos se administrará principalmente utilizando N2C o Net2Client, una herramienta creada por la empresa que permite a sus usuarios crear bases de datos relacionales ajustadas a los modelos y procesos de negocio de sus empresas. Confidencial,

104 Documento de Visión Fecha: Costos y Precios Las actividades de diseño, implementación e implantación del sistema serán llevadas a cabo por el pasante y desarrollador David Antunes, y comprenderán un período de 20 semanas. Cada día abarcará un costo aproximado de 8 horas-hombre, para un total de 1120 horas-hombre de trabajo. Por otro lado, la empresa se reserva la divulgación de información sobre los precios de venta del producto a los clientes hoteleros. 6.5 Licencias e Instalación No se contempla el uso de licencias ni la instalación del sistema. El SRI se ofrecerá como SAAS ó Software As A Service (Software como Servicio), esto es, el sistema se desplegará en Internet y los usuarios que deseen utilizarlo deberán realizar previamente un proceso de registro con los agentes de VenezuelaTuya. Posteriormente, podrán acceder al sistema desde cualquier lugar usando cualquier dispositivo. 7. Características del Sistema 7.1 Características a nivel de software Multidispositivo: el SRI dispondrá de una versión web para computadoras personales y una versión para teléfonos móviles. Multiplataforma: es independiente del sistema operativo y del hardware del dispositivo que se usa para visitarlo; las únicas condiciones son tener un navegador web con el cual poder acceder al sistema y disponer cualquier acceso a la red Internet. Monousuario: el sistema temporalmente ofrecerá la creación y acceso de un solo usuario por hotel. Para futuros desarrollos se implementará la funcionalidad para que el sistema sea multiusuario y los hoteleros administradores puedan asignar a otros usuarios y configurar sus permisos sobre el sistema. Portable: gracias al uso de PHP y la estructura de diseño planteada por Zend Framework bajo el patrón MVC, el sistema puede ser fácilmente migrado a otro ambiente sin inconvenientes. Alta cohesión, bajo acoplamiento: la filosofía de Zend Framework permite desacoplar las clases de tal forma que estén lo menos relacionadas posible y que funcionalidades con objetivos comunes sean agrupadas en clases. Confidencial,

105 Documento de Visión Fecha: Mantenibilidad: futuras mejoras del sistema serán más fáciles de realizar gracias al bajo acoplamiento conseguido debido al uso de Zend Framework. 7.2 Características a nivel de funcionalidad. Versiones web y móvil: el sistema comprenderá una versión para computadoras personales y una versión móvil. Ambas versiones podrán ser utilizadas por el usuario de acuerdo a sus necesidades sin ninguna restricción, una vez que contrate el servicio con VenezuelaTuya. Acceso desde cualquier parte: el sistema será desplegado en Internet, proveyendo a los usuarios acceso desde cualquier lugar de Venezuela. Visualizar las situaciones de reservaciones y ocupación: el SRI proveerá al hotelero la capacidad de observar la situación completa de su establecimiento apenas ingrese al sistema. En la versión para computadoras personales se mostrará la situación de reservaciones del presente y los últimos 15 días así como la situación de ocupación del mes en curso. En la versión móvil, debido a las limitaciones de ancho de pantalla, ambas situaciones se presentarán para el día en curso y el día anterior. Configuración y personalización del sistema: el hotelero podrá configurar los datos que conciernen a su establecimiento y a su lógica de negocios: datos del hotel, tipos de habitaciones, planes y temporadas, tarifas, entre otras. Administración de cupos: el hotelero podrá consultar y controlar el número de cupos destinados a reservaciones online por medio del portal venezuelatuya.com y el número de cupos de reservaciones que serán realizadas dentro del establecimiento. Administración de reservaciones: el usuario hotelero podrá administrar sus reservaciones de manera rápida y sencilla. En la versión de escritorio podrán hacerlo desde un panel dinámico que organiza sus habitaciones por tipos de habitación y en cual podrá hacer operaciones de consulta y control: consultar los datos de un cliente; crear nuevas reservaciones y consultar, modificar y eliminar las ya existentes; verificar el status de pago de las reservaciones de los clientes; entre otras. En la versión móvil, la interfaz gráfica será más sencilla pero con las mismas operaciones. Generación de reportes dinámicos de reservaciones y ocupación: el sistema dispondrá una funcionalidad para generar reportes de reservaciones y ocupación que podrán ser organizados de acuerdo a los siguientes criterios: por período de fechas, por tipo de habitación, por clientes, entre otros. Control de Pagos: funcionalidad que permitirá al hotelero llevar el control de pagos de las reservaciones de sus clientes y un historial de los cobros ya realizados que pueda servirle para generar estadísticas posteriores. Confidencial,

106 Documento de Visión Fecha: Restricciones El proyecto abarcará solamente la reingeniería de la sección privada del SRI, es decir, la sección orientada a los hoteleros y posaderos, contemplando únicamente los módulos de visualización de las situaciones de reservaciones y ocupación; administración de cupos y generación de reportes. Los módulos mencionados anteriormente serán implementados tanto para la versión para computadoras personales como para la versión móvil. Se dejarán montadas las bases para el desarrollo posterior de los otros módulos y futuras funcionalidades. El sistema se desarrollará utilizando el lenguaje PHP 5.0. Su diseño e implementación se realizarán bajo el enfoque MVC utilizando Zend Framework A nivel visual, se utilizarán los lenguajes de maquetación HTML y CSS. De igual forma se empleará el lenguaje JavaScript y su framework JQuery 1.4 El manejador de base de datos será MySQL 5.1. La base de datos se administrará principalmente utilizando Net2Client. El sistema podrá ser usado únicamente por aquellos hoteleros registrados al servicio por los agentes de VenezuelaTuya. Toda la documentación del sistema, tanto de código fuente como de documentos de RUP, deben regirse bajo los estándares y estar disponible en línea a través de la página privada Google Sites dedicada al sistema, para su futura consulta y uso de otros miembros de la empresa. Confidencial,

107 Documento de Visión Fecha: Rangos de Calidad Interfaz gráfica sencilla y de fácil uso: debe poseer una interfaz gráfica intuitiva y amigable, organizada de tal forma que los usuarios puedan aprender rápido a utilizarlo y se sientan cómodos. La interfaz debe ser tal que permita al usuario sentirse identificado y motivado a usar el sistema como su herramienta diaria. Seguridad: el sistema debe garantizar el acceso de solamente aquellos usuarios que estén registrados, y que efectivamente los datos presentados correspondan al usuario que se identifica en el mismo. De igual forma, la modelación de las consultas a la base de datos deben seguir los estándares y técnicas para evitar ataques del estilo sql injection, para evitar la filtración de datos o que caigan en manos indebidas. Tolerante a fallas: el sistema debe estar preparado para identificar fallas y/o excepciones y capturarlas apropiadamente. Si la falla se presenta en el entorno del usuario, debe ponerse en contexto al usuario acerca de la misma, ya sea mediante un mensaje o cualquier otro método utilizado. Tiempo de respuesta: las funcionalidades implementadas deben ser depuradas apropiadamente para que los tiempos de respuesta de las operaciones no se prolonguen mucho tiempo. El sistema debe ser efectivo y tener tiempos de respuesta adecuados, de tal forma que permita agilizar las actividades del usuario hotelero. Documentación clara y precisa: el sistema debe ser documentado totalmente, tanto a nivel de código fuente como en los de documentos que analicen. Debe expresar de forma concreta, clara y precisa la arquitectura de diseño del sistema, así como las funcionalidades que implementa. 10. Precedencia y Prioridad El SRI en su versión actual debe primero pasar por una etapa de reingeniería bajo el enfoque MVC de Zend Framework, para obtener un producto donde las capas de presentación, de lógica de negocio y de acceso a datos estén totalmente separadas. Una vez implementado el SRI bajo el enfoque de Zend, se procederá al desarrollo de la versión móvil. Esta versión aunque se desarrollará en segundo lugar, tiene la mayor prioridad dentro de los objetivos del proyecto. Confidencial,

108 Documento de Visión Fecha: Otros Requerimientos del Sistema 11.1 Estándares Aplicables Se aplicarán los estándares de programación y documentación especificados para PHP 5.0 y para Zend Framework Requerimientos del Sistema Las siguientes son características que deben estar presentes en los servidores que utiliza la empresa para el correcto funcionamiento del SRI: Disponer de un dominio público y un hosting web. El hosting debe ser un hosting dedicado con el sistema operativo Linux y que cuente con las aplicaciones Apache Server 2.0 (o mayor) y PHP 5.0 (o mayor). Debe también permitir la configuración inicial de ambas aplicaciones, requisito primordial para instalar y configurar Zend Framework. Instalar y configurar correctamente Zend Framework en su última versión (actualmente 1.11). El servicio de hosting debe tener al menos 4 Gb de RAM y una tasa mínima de 1 TB (1 Terabyte) de ancho de banda Requerimientos de Desempeño El sistema debe ser rápido y efectivo. Los tiempos de respuesta de sus operaciones deben ser adecuados para permitir la agilización de las actividades del usuario hotelero Requerimientos de Ambiente El sistema debe poder ser accedido desde cualquier navegador web de cualquier sistema operativo, especialmente en los más conocidos: Firefox, Internet Explorer, Google Chrome y Safari en sus versiones más actuales. El usuario que utilice el sistema debe tener acceso a Internet, ya sea a través de un servicio contratado o a través de un teléfono móvil que utilice la red la compañía para ingresar en la red. Confidencial,

109 Documento de Visión Fecha: Requerimientos de Documentación 12.1 Manual de Usuario y Ayuda en Línea Tanto el Manual de Usuario como la Ayuda en Línea ya están elaborados actualmente. El primero se encuentra en formato PDF y la segunda está disponible en una página dedicada a través del servicio Google Sites. Sin embargo, una vez culminada la reingeniería e implementación del SRI bajo el enfoque de Zend Framework, es necesario realizar una revisión de los mismos y añadir las descripciones y explicación de las funcionalidades de la versión móvil Guías de Instalación, configuración y archivos Readme El sistema no necesitará ninguna de estas guías. El SRI se ofrecerá como SAAS (refiérase al Glosario de Términos), por lo tanto no se instalará en los servidores o infraestructura de los clientes. La configuración y mantenimiento del sistema dependen únicamente de la empresa Etiquetas y Paquetes El sistema tendrá un logotipo apropiado que identifique a VenezuelaTuya como la empresa que ofrece el servicio del Sistema de Reservaciones Inmediatas. Confidencial,

110 APÉNDICE C ESPECIFICACIONES DE REQUERIMIENTOS DEL SOFTWARE

111 Reingeniería del Sistema de Reservaciones Inmediatas: Aplicaciones web y móvil Sistema de Reservaciones Inmediatas Especificaciones de Requerimientos del Software Versión 1.0

112 Especificaciones de Requerimientos del Software Fecha: Historial de Revisiones Fecha Versión Descripción Autor Elaborados los Requerimientos Funcionales y los No Funcionales Versión final y revisada del Documento de Requerimientos del Software o ERS David Antunes David Antunes Confidencial,

113 Especificaciones de Requerimientos del Software Fecha: Índice de Contenidos 1. Introducción Alcance Definiciones, Acrónimos y Abreviaturas Referencias 5 2. Especificaciones Funcionales Consultar las situaciones de reservaciones y ocupación Configuración del sistema Administración de Cupos Administración de Reservaciones Reportes dinámicos de reservaciones y ocupación Control de Pagos 8 3. Casos de Uso Resumen de Casos de Uso y Actores Casos de uso comunes Casos de uso de la Versión de Escritorio Casos de uso de la Versión Móvil Especificaciones de Casos de Uso Casos de uso comunes Casos de uso de la Versión de Escritorio Diagramas de Caso de uso Modelo de Casos de Uso Administración de Reservaciones Administración de Ocupación Administración de Cupos Administración de Sesiones Administración Cartelera Informativa Especificaciones No Funcionales Usabilidad Interfaces de usuario apropiadas según el dispositivo Interfaz de usuario sencilla y de fácil uso Confiabilidad Tolerante a errores y fallas Desempeño Tiempos de respuesta Mantenibilidad Alta cohesión, bajo acoplamiento Estándares de codificación y documentación Estructura de directorios definida Documentación clara y precisa Seguridad Acceso restringido Seguridad de datos Restricciones de Diseño Alcance del proceso de Reingeniería Lenguajes de programación y maquetación Patrón de diseño y framework de desarrollo Manejo de datos 33 Confidencial,

114 Especificaciones de Requerimientos del Software Fecha: Requerimientos de Sistema Hosting dedicado y dominio público Configuraciones Requerimientos de Ambiente Disponible en cualquier navegador Acceso por parte del usuario Requerimientos de Documentación en Línea y de Sistemas de Ayuda Manual de usuario y Ayuda en línea Documentación en línea 34 Confidencial,

115 Especificaciones de Requerimientos del Software Fecha: Especificaciones de Requerimientos del Software 1. Introducción Este documento detalla los requerimientos de software para el Sistema de Reservaciones Inmediatas, según tres grandes aspectos claves para su desarrollo: las Especificaciones Funcionales, el modelo de los Casos de Uso, tanto en diagrama como en narrativa, y las Especificaciones suplementarias o No Funcionales. Toda esta información establece los lineamientos y las restricciones que debe considerar el equipo de desarrollo del proyecto para el desarrollo del sistema. 1.1 Alcance El alcance de este documento es la Especificación de los Requerimientos de Software (ERS) para el Sistema de Reservaciones Inmediatas. Como bien se establece en el Documento de Visión en el apartado 6 (Restricciones) sólo se realizará la reingeniería de la sección privada del sistema, abarcando la implementación de los módulos de visualización de situación de reservaciones y ocupación; administración de cupos y generación de reportes. De esta forma, sólo se especificarán los casos de uso para los aspectos previamente mencionados. Sin embargo, se exponen las Especificaciones Funcionales y No Funcionales que afectarán a todos los módulos del sistema que serán desarrollados en este proyecto y también a los módulos que se implementarán posteriormente. 1.2 Definiciones, Acrónimos y Abreviaturas Para los códigos de las Especificaciones Funcionales se utilizará la abreviatura EF-NN, donde NN es un número natural. El resto de las definiciones, acrónimos y abreviaciones asociadas a este proyecto están especificadas en el Documento de Visión y el Glosario del Proyecto. 1.3 Referencias Antunes, David. Sistema de Reservaciones Inmediatas: Glosario Antunes, David. Sistema de Reservaciones Inmediatas: Documento de Visión Confidencial,

116 Especificaciones de Requerimientos del Software Fecha: Especificaciones Funcionales 2.1 Consultar las situaciones de reservaciones y ocupación Característica Asociada: Visualizar las situaciones de reservaciones y ocupación (tomado del punto 5.2 del Documento de Visión del sistema) ID requerimiento: EF-01 Nombre del Requerimiento: Consultar la situación de reservaciones El SRI debe permitir al usuario chequear la situación global de su establecimiento, específicamente las situaciones de reservaciones y ocupación del mismo. Es la actividad en la que mayormente los usuarios invertirán su tiempo y debe implementarse como pantalla inicial. La versión para computadoras personales (versión de escritorio) debe aprovechar las ventajas de las tecnologías web de última generación, mientras que la versión móvil debe ser simplificada, práctica y sencilla. Atributo: Prioridad ( X ) Alta ( ) Media Alta ( ) Media ( ) Media Baja ( ) Baja 2.2 Configuración del sistema Característica Asociada: Configuración y personalización del sistema (tomado del punto 5.2 del Documento de Visión del sistema) ID requerimiento: EF-02 Nombre del Requerimiento: Configuración del sistema El sistema debe proveer una funcionalidad para que los hoteleros y posaderos puedan establecer los datos concernientes a la lógica de negocio de su establecimiento, además de aquella información que ofrecerá a sus futuros huéspedes: datos del hotel, tipos de habitaciones, planes y temporadas, tarifas, entre otros. Atributo: Prioridad ( ) Alta ( ) Media Alta ( ) Media ( ) Media Baja ( X ) Baja 2.3 Administración de Cupos Característica Asociada: Administración de cupos (tomado del punto 5.2 del Documento de Visión del sistema) ID requerimiento: EF-03 Nombre del Requerimiento: Administración de cupos Confidencial,

117 Especificaciones de Requerimientos del Software Fecha: Debe implementarse la capacidad para que el hotelero pueda administrar los cupos de su establecimiento. El sistema debe presentar por separado la cantidad de cupos destinados a reservaciones online por medio del portal venezuelatuya.com y el número de cupos de reservaciones realizadas dentro del establecimiento Atributo: Prioridad ( ) Alta ( X ) Media Alta ( ) Media ( ) Media Baja ( ) Baja 2.4 Administración de Reservaciones Característica Asociada: Administración de reservaciones (tomado del punto 5.2 del Documento de Visión del sistema) ID requerimiento: EF-04 Nombre del Requerimiento: Administración de reservaciones Los usuarios del sistema deben poder administrar sus reservaciones de forma sencilla y eficiente. En la versión de escritorio podrán hacerlo desde un panel dinámico que organiza sus habitaciones por tipos de habitación y en cual podrá hacer operaciones de consulta y control: consultar los datos de un cliente; crear nuevas reservaciones y consultar, modificar y eliminar las ya existentes; verificar el status de pago de las reservaciones de los clientes; entre otras. En la versión móvil, la interfaz gráfica será más sencilla pero con las mismas operaciones. Atributo: Prioridad ( ) Alta ( X ) Media Alta ( ) Media ( ) Media Baja ( ) Baja 2.5 Reportes dinámicos de reservaciones y ocupación Característica Asociada: Generación de reportes dinámicos de reservaciones y ocupación (tomado del punto 5.2 del Documento de Visión del sistema) ID requerimiento: EF-05 Nombre del Requerimiento: Reportes dinámicos de reservaciones y ocupación El SRI permitirá generar reportes de reservaciones y ocupación que sirvan a los hoteleros para llevar un registro que puedan utilizar para generar estadísticas. Estos reportes deben poder organizarse de acuerdo a los siguientes criterios: por período de fechas, por tipo de habitación, por clientes, entre otros. Atributo: Prioridad ( ) Alta ( ) Media Alta ( X ) Media ( ) Media Baja ( ) Baja Confidencial,

118 Especificaciones de Requerimientos del Software Fecha: Control de Pagos Característica Asociada: Control de pagos (tomado del punto 5.2 del Documento de Visión del sistema) ID requerimiento: EF-06 Nombre del Requerimiento: Control de pagos Funcionalidad que permitirá al hotelero llevar el control de pagos de las reservaciones de sus clientes y un historial de los cobros ya realizados que pueda servirle para generar estadísticas posteriores. Atributo: Prioridad ( ) Alta ( ) Media Alta ( ) Media ( ) Media Baja (X ) Baja Confidencial,

119 Especificaciones de Requerimientos del Software Fecha: Casos de Uso Esta sección cumple con las especificaciones mencionadas en el alcance del presente documento. Por lo tanto, sólo se especificarán los casos de uso de los módulos implementados durante el proyecto. 3.1 Resumen de Casos de Uso y Actores Para efectos del proyecto, los casos de uso serán organizados de acuerdo a las dos versiones del sistema, teniendo tres grupos distintos: casos de uso comunes, casos de uso de la versión de escritorio y casos de uso de la versión móvil. Por otro lado, los casos de uso serán agrupados de acuerdo a sus funcionalidades en paquetes siguiendo los estándares de UML 2.0. De esta forma, funcionalidades con objetivos comunes serán agrupados en el mismo paquete Casos de uso comunes Paquete: Administración de Reservaciones Caso de Uso Consultar Situación Reservaciones Consultar Reporte de Reservaciones Consultar Reporte por Persona Consultar Reporte por Tipo de Habitación Listar Reservaciones Actor Hotelero, Agente Hotelero, Agente Hotelero, Agente Hotelero, Agente Hotelero, Agente Paquete: Administración de Ocupación Caso de Uso Consultar Situación de Ocupación Consultar Reporte de Ocupación Consultar Reporte por Persona Consultar Reporte por Tipo de Habitación Listar Ocupación Actor Hotelero, Agente Hotelero, Agente Hotelero, Agente Hotelero, Agente Hotelero, Agente Confidencial,

120 Especificaciones de Requerimientos del Software Fecha: Paquete: Administración de Cupos Caso de Uso Consultar Cupos Actualizar Cupos Listar Cupos Actor Hotelero, Agente Hotelero, Agente Hotelero, Agente Paquete: Administración de Sesiones Caso de Uso Iniciar Sesión Cerrar Sesión Verificar Datos Actor Hotelero, Agente Hotelero, Agente Hotelero, Agente Casos de uso de la Versión de Escritorio Paquete: Administración Cartelera Informativa Caso de Uso Consultar Cartelera Informativa Actualizar Cartelera Informativa Actor Hotelero, Agente Hotelero, Agente Casos de uso de la Versión Móvil Son aquellos especificados en el apartado Casos de uso comunes. La versión móvil no contendrá casos de uso particulares en el presente proyecto, sin embargo no se descarta la posibilidad de que existan para futuras implementaciones. Confidencial,

121 Especificaciones de Requerimientos del Software Fecha: Especificaciones de Casos de Uso Al igual que en la sección anterior, las especificaciones de los casos de uso se agruparán de acuerdo a la versión del sistema y en paquetes de UML Casos de uso comunes Paquete: Administración de Reservaciones Caso de uso: Consultar Situación de Reservaciones Descripción: El usuario consulta la situación de reservaciones de su establecimiento Requerimiento: Cubre los requerimientos EF-01 y EF-04 Precondición: El usuario debe estar autenticado. Flujo Básico: Actor 1 El usuario solicita la situación de reservaciones de su establecimiento 4 El usuario observa la situación de reservaciones de su establecimiento Sistema 2 El sistema busca la información de las reservaciones asociadas al usuario 3 El sistema lista la información de las reservaciones (include Listar Reservaciones), y seguidamente las organiza por fecha y persona Postcondición: El sistema presenta la información de la situación de reservaciones asociada al usuario autenticado, organizándola por fecha y persona Puntos de extensión: No tiene Confidencial,

122 Especificaciones de Requerimientos del Software Fecha: Caso de uso: Consultar Reporte de Reservaciones Descripción: El usuario consulta el reporte principal de reservaciones de su establecimiento Requerimiento: Cubre el requerimiento EF-05 Precondición: El usuario debe estar autenticado. Flujo Básico: Actor 1 El usuario solicita el reporte de reservaciones principal de su establecimiento Sistema 2 El sistema busca la información de las reservaciones asociadas al usuario 3 El sistema lista la información de las reservaciones (include Listar Reservaciones), presentando un reporte de las mismas organizadas por fecha 4 El usuario observa el reporte de reservaciones principal de su establecimiento 5 El usuario puede realizar una de las acciones indicadas en los puntos de extensión Postcondición: El sistema presenta el reporte principal de reservaciones con la información asociada al usuario autenticado, organizando las reservaciones por fecha Puntos de extensión: -Consultar Reporte por Persona: el usuario consulta el reporte de reservaciones organizado por nombre de persona. -Consultar Reporte por Tipo de Habitación: el usuario consulta el reporte de reservaciones organizado por de tipo de habitación. Confidencial,

123 Especificaciones de Requerimientos del Software Fecha: Caso de uso: Consultar Reporte por Persona Descripción: El usuario consulta el reporte de reservaciones de su establecimiento organizado según el nombre de las personas que realizaron alguna reservación Requerimiento: Cubre el requerimiento EF-05 Precondición: El usuario debe estar autenticado. Flujo Básico: Actor Sistema 1 El usuario solicita el reporte de reservaciones por persona de su establecimiento 2 El sistema busca la información de las reservaciones asociadas al usuario 3 El sistema lista la información de las reservaciones (include Listar Reservaciones), presentando un reporte de las mismas organizadas por nombre de persona 4 El usuario observa el reporte de reservaciones por persona de su establecimiento Postcondición: El sistema presenta el reporte de reservaciones con la información asociada al usuario autenticado, organizando las reservaciones por nombre de persona Puntos de extensión: No tiene Confidencial,

124 Especificaciones de Requerimientos del Software Fecha: Caso de uso: Consultar Reporte por Tipo de Habitación Descripción: El usuario consulta el reporte de reservaciones de su establecimiento organizado según los tipos de habitación del mismo Requerimiento: Cubre el requerimiento EF-05 Precondición: El usuario debe estar autenticado. Flujo Básico: Actor 1 El usuario solicita el reporte de reservaciones por tipo de habitación de su establecimiento Sistema 2 El sistema busca la información de las reservaciones asociadas al usuario 3 El sistema lista la información de las reservaciones (include Listar Reservaciones), presentando un reporte de las mismas organizadas por tipo de habitación 4 El usuario observa el reporte de reservaciones por tipo de habitación de su establecimiento Postcondición: El sistema presenta el reporte de reservaciones con la información asociada al usuario autenticado, organizando las reservaciones por tipo de habitación Puntos de extensión: No tiene Confidencial,

125 Especificaciones de Requerimientos del Software Fecha: Paquete: Administración de Ocupación Caso de uso: Consultar Situación de Ocupación Descripción: El usuario consulta la situación de ocupación (disponibilidad) de su establecimiento Requerimiento: Cubre el requerimiento EF-01 Precondición: El usuario debe estar autenticado. Flujo Básico: Actor 1 El usuario solicita la situación de ocupación de habitaciones de su establecimiento Sistema 2 El sistema busca la información de la ocupación de habitaciones asociadas al usuario 3 El sistema lista la información de la disponibilidad de habitaciones (include Listar Ocupación), y organiza dichos datos según el número de habitaciones ocupadas y el número de habitaciones desocupadas 4 El usuario observa la situación de ocupación de habitaciones de su establecimiento Postcondición: El sistema presenta la información de la situación de ocupación de habitaciones asociada al usuario autenticado, organizándola según el número de habitaciones ocupadas y desocupadas Puntos de extensión: No tiene Confidencial,

126 Especificaciones de Requerimientos del Software Fecha: Caso de uso: Consultar Reporte de Ocupación Descripción: El usuario consulta el reporte principal de ocupación de su establecimiento Requerimiento: Cubre el requerimiento EF-05 Precondición: El usuario debe estar autenticado. Flujo Básico: Actor 1 El usuario solicita el reporte de ocupación de habitaciones principal de su establecimiento Sistema 2 El sistema busca la información de la ocupación de habitaciones asociadas al usuario 3 El sistema lista la información de la disponibilidad de habitaciones (include Listar Ocupación), presentando un reporte con dichos datos organizados por fecha 4 El usuario observa el reporte de ocupación de habitaciones de su establecimiento 5 El usuario puede realizar una de las acciones indicadas en los puntos de extensión Postcondición: El sistema presenta el reporte principal de ocupación de habitaciones con la información asociada al usuario autenticado, organizando los datos por fecha Puntos de extensión: -Consultar Reporte por Persona: el usuario consulta el reporte de ocupación de habitaciones organizado por nombre de persona. -Consultar Reporte por Tipo de Habitación: el usuario consulta el reporte de reservaciones organizado por tipo de habitación. Confidencial,

127 Especificaciones de Requerimientos del Software Fecha: Caso de uso: Consultar Reporte por Persona Descripción: El usuario consulta el reporte de ocupación de su establecimiento organizado según el nombre de las personas que realizaron alguna reservación Requerimiento: Cubre el requerimiento EF-05 Precondición: El usuario debe estar autenticado. Flujo Básico: Actor Sistema 1 El usuario solicita el reporte de ocupación de habitaciones por persona de su establecimiento 2 El sistema busca la información de la ocupación de habitaciones asociadas al usuario 3 El sistema lista la información de la disponibilidad de habitaciones (include Listar Ocupación), presentando un reporte con dichos datos organizados por nombre de persona 4 El usuario observa el reporte de ocupación de habitaciones por persona de su establecimiento Postcondición: El sistema presenta el reporte de ocupación de habitaciones con la información asociada al usuario autenticado, organizando los datos por nombre de persona Puntos de extensión: No tiene Confidencial,

128 Especificaciones de Requerimientos del Software Fecha: Caso de uso: Consultar Reporte por Tipo de Habitación Descripción: El usuario consulta el reporte de ocupación de su establecimiento organizado según los tipos de habitación del mismo Requerimiento: Cubre el requerimiento EF-05 Precondición: El usuario debe estar autenticado. Flujo Básico: Actor 1 El usuario solicita el reporte de ocupación de habitaciones por tipo de habitación de su establecimiento Sistema 2 El sistema busca la información de la ocupación de habitaciones asociadas al usuario 3 El sistema lista la información de la disponibilidad de habitaciones (include Listar Ocupación), presentando un reporte con dichos datos organizados por tipo de habitación 4 El usuario observa el reporte de ocupación de habitaciones por tipo de habitación de su establecimiento Postcondición: El sistema presenta el reporte de ocupación de habitaciones con la información asociada al usuario autenticado, organizando los datos por tipo de habitación Puntos de extensión: No tiene Confidencial,

129 Especificaciones de Requerimientos del Software Fecha: Paquete: Administración de Cupos Caso de uso: Consultar Cupos Descripción: El usuario consulta los cupos asignados para reservar las habitaciones de su establecimiento correspondientes al mes en curso, diferenciándolos entre cupos locales (otorgados para reservaciones realizadas dentro del establecimiento) y cupos internet (otorgados para reservaciones efectuadas por internet). El usuario también puede consultar los cupos asignados para otros meses del año. Requerimiento: Cubre el requerimiento EF-03 Precondición: El usuario debe estar autenticado. Flujo Básico: Actor 1 El usuario solicita la información de los cupos de su establecimiento para el mes en curso Sistema 2 El sistema busca la información de los cupos asociadas al usuario para el mes seleccionado 3 El sistema lista la información de los cupos (include Listar Cupos), y organiza dichos datos por tipo de habitación y por semana del mes seleccionado 4 El usuario observa la información de los cupos de su establecimiento para el mes seleccionado Flujo Alterno Seleccionar un mes 1 El usuario selecciona el mes para el cual desea consultar la información de los cupos de su establecimiento Postcondición: El sistema presenta la información de los cupos asociada al usuario autenticado para algún mes en particular, organizándola por tipo de habitación y por semana Puntos de extensión: No tiene Confidencial,

130 Especificaciones de Requerimientos del Software Fecha: Caso de uso: Actualizar Cupos Descripción: El usuario actualiza los cupos asignados para reservar las habitaciones de su establecimiento correspondientes al mes en curso, diferenciándolos entre cupos locales (otorgados para reservaciones realizadas dentro del establecimiento) y cupos internet (otorgados para reservaciones efectuadas por internet). El usuario también puede actualizar los cupos asignados para otros meses del año. Requerimiento: Cubre el requerimiento EF-03 Precondición: El usuario debe estar autenticado. Flujo Básico: Actor 1 El usuario solicita la información de los cupos de su establecimiento para el mes en curso 4 El usuario modifica los datos de los cupos presentados 5 El usuario solicita guardar los cambios efectuados 7 El usuario observa el mensaje de éxito y confirma que sus cambios fueron salvados Sistema 2 El sistema busca la información de los cupos asociadas al usuario para el mes seleccionado 3 El sistema lista la información de los cupos (include Listar Cupos), y organiza dichos datos por tipo de habitación y por semana del mes seleccionado 6 El sistema guarda los cambios realizados por el usuario y envía un mensaje de éxito al mismo Flujo Alterno Seleccionar un mes 1 El usuario selecciona el mes para el cual desea consultar la información de los cupos de su establecimiento Flujo Alterno Error al guardar los cambios 6 El sistema informa al usuario del error producido 7 El usuario observa el mensaje de error Postcondición: El sistema guarda los cambios efectuados por el usuario sobre los datos de los cupos e informa al usuario sobre el éxito de dicha operación Confidencial,

131 Especificaciones de Requerimientos del Software Fecha: Puntos de extensión: No tiene Paquete: Administración de Sesiones Caso de uso: Iniciar Sesión Descripción: El usuario solicita el acceso al sistema y se autentica en el sistema introduciendo sus datos personales Requerimiento: No cubre requerimientos funcionales. Sin embargo, cubre el requerimiento no funcional de seguridad Precondición: El usuario debe estar registrado en el sistema Flujo Básico: Actor Sistema 1 El usuario introduce su nombre de usuario y contraseña 2 El usuario envía sus datos y solicita su autenticación en el sistema 3 El sistema verifica los datos enviados (include Verificar Datos) 4 El sistema aprueba la validez de los datos y genera una sesión para el usuario 5 El sistema redirige al usuario a la página de inicio del mismo Flujo Alterno Datos de acceso inválidos 4 El sistema detecta la invalidez de los datos y envía un mensaje de error al usuario 5 El usuario observa el mensaje de error Postcondición: El sistema genera una sesión para el usuario y lo redirige a la página de inicio del mismo Puntos de extensión: No tiene Confidencial,

132 Especificaciones de Requerimientos del Software Fecha: Caso de uso: Cerrar Sesión Descripción: El usuario solicita el cierre de su sesión en el sistema Requerimiento: No cubre requerimientos funcionales. Sin embargo, cubre el requerimiento no funcional de seguridad Precondición: El usuario debe estar autenticado. Flujo Básico: Actor 1 El usuario solicita el cierre de su sesión Sistema 2 El sistema busca los datos asociados a la sesión del usuario y destruye la sesión 3 El sistema redirige al usuario a la página de inicio de sesión del mismo Postcondición: El sistema elimina la sesión del usuario y lo redirige a la página de inicio de sesión del mismo Puntos de extensión: No tiene Confidencial,

133 Especificaciones de Requerimientos del Software Fecha: Casos de uso de la Versión de Escritorio Paquete: Administración Cartelera Informativa Caso de uso: Consultar Cartelera Informativa Descripción: El usuario consulta el mensaje de la cartelera informativa de su establecimiento Requerimiento: Cubre el requerimiento EF-02 Precondición: El usuario debe estar autenticado. Flujo Básico: Actor 1 El usuario solicita el mensaje de la cartelera informativa de su establecimiento Sistema 2 El sistema busca el mensaje de la cartelera informativa asociado al usuario 3 El sistema despliega el mensaje encontrado 4 El usuario observa el mensaje de la cartelera informativa de su establecimiento Postcondición: El sistema presenta el mensaje de la cartelera informativa solicitado Puntos de extensión: No tiene Confidencial,

134 Especificaciones de Requerimientos del Software Fecha: Caso de uso: Actualizar Cartelera Informativa Descripción: El usuario actualiza el mensaje de la cartelera informativa de su establecimiento Requerimiento: Cubre el requerimiento EF-02 Precondición: El usuario debe estar autenticado. Flujo Básico: Actor 1 El usuario solicita el mensaje de la cartelera informativa de su establecimiento 4 El usuario modifica el mensaje de la cartelera informativa 5 El usuario solicita guardar los cambios efectuados 7 El usuario observa el mensaje de éxito y confirma que sus cambios fueron salvados Sistema 2 El sistema busca el mensaje de la cartelera informativa asociado al usuario 3 El sistema despliega el mensaje encontrado 6 El sistema guarda los cambios realizados por el usuario y envía un mensaje de éxito al mismo Flujo Alterno Error al guardar los cambios 6 El sistema informa al usuario del error producido 7 El usuario observa el mensaje de error Postcondición: El sistema guarda los cambios efectuados por el usuario sobre el mensaje de la cartelera informativa e informa al usuario sobre el éxito de dicha operación Puntos de extensión: No tiene Confidencial,

135 Especificaciones de Requerimientos del Software Fecha: Diagramas de Caso de uso Los diagramas de casos de uso contemplan el enfoque de agrupación por paquetes de UML 2.0. De esta forma, se presenta en primer lugar un diagrama del Modelo de Casos de Uso completo con todos los paquetes desarrollados para el proyecto; posteriormente se muestra un diagrama de caso de uso por cada uno de los paquetes Modelo de Casos de Uso Confidencial,

136 Especificaciones de Requerimientos del Software Fecha: Administración de Reservaciones Confidencial,

137 Especificaciones de Requerimientos del Software Fecha: Administración de Ocupación Confidencial,

138 Especificaciones de Requerimientos del Software Fecha: Administración de Cupos Confidencial,

139 Especificaciones de Requerimientos del Software Fecha: Administración de Sesiones Confidencial,

140 Especificaciones de Requerimientos del Software Fecha: Administración Cartelera Informativa Confidencial,

141 Especificaciones de Requerimientos del Software Fecha: Especificaciones No Funcionales 4.1 Usabilidad Interfaces de usuario apropiadas según el dispositivo El sistema debe estar capacitado para detectar el dispositivo que utiliza el usuario para utilizar el sistema (ya sea una computadora de escritorio o un dispositivo móvil) y presentar una interfaz adecuada al mismo. En particular, debe tomarse en cuenta la resolución que soporte el dispositivo y las capacidades tecnológicas que soporta el explorador web que se utilice, tales como: despliegue de imágenes, reconocimiento y uso de JavaScript, Ajax, CSS, entre otras Interfaz de usuario sencilla y de fácil uso La interfaz que manejarán los usuarios en ambas versiones del sistema debe ser intuitiva, sencilla y amigable, organizada de tal manera que los mismos pueda aprender a usarlo rápidamente y se sientan cómodos. La meta es lograr que el hotelero se sienta identificado con el sistema y motivado a usarlo como su herramienta diaria. 4.2 Confiabilidad Tolerante a errores y fallas El sistema siempre debe mantenerse en funcionamiento, y estar preparado para identificar fallas y/o excepciones que puedan presentarse; éstas deben ser capturadas apropiadamente para evitar el colapso del sistema. En caso de algún error que venga del entorno del usuario, debe ponerse en contexto al mismo acerca de dicho error, ya sea mediante un mensaje o cualquier otro método utilizado. 4.3 Desempeño Tiempos de respuesta Las funcionalidades implementadas deben ser depuradas apropiadamente para que los tiempos de respuesta de las operaciones y peticiones de los usuarios nunca lleguen a contabilizarse por encima de los 30 segundos. En general, el sistema debe ser rápido y efectivo, generando tiempos de respuesta adecuados que permitan agilizar las actividades del usuario hotelero. Confidencial,

142 Especificaciones de Requerimientos del Software Fecha: Mantenibilidad Alta cohesión, bajo acoplamiento Debe seguirse la filosofía de trabajo de Zend Framework, la cual permite desacoplar las clases de tal forma que estén lo menos relacionadas posible y que funcionalidades con objetivos o tareas comunes sean agrupadas en clases Estándares de codificación y documentación De igual manera, se aplicarán los estándares de programación y documentación que han sido especificados para PHP 5.0 y Zend Framework 1.11, permitiendo así agilizar el desarrollo de funcionalidades posteriores Estructura de directorios definida Los archivos deben ubicarse según la estructura de directorios del enfoque MVC de Zend Framework. Esto es necesario para que el sistema pueda ejecutarse correctamente y contribuye a posibilitar el bajo acoplamiento Documentación clara y precisa Cada archivo, clase, método y función deben ser documentadas de forma clara y precisa. Los comentarios deben incluir pequeñas descripciones de lo que realiza el código; nunca deben ser redundantes y no debe abusarse su uso. 4.5 Seguridad Acceso restringido Debe garantizarse el acceso de solamente aquellos usuarios que estén registrados, y que al utilizar el sistema los datos correspondan efectivamente al usuario que se autentica Seguridad de datos Los datos nunca deben ser comprometidos, debe evitarse la filtración de información. De esta forma las consultas a la base de datos deben seguir los estándares y buenas prácticas para evitar cualquier ataque, especialmente aquellos generados mediante sql injection. Confidencial,

143 Especificaciones de Requerimientos del Software Fecha: Restricciones de Diseño Alcance del proceso de Reingeniería El proyecto abarcará solamente la reingeniería de la sección privada del SRI, contemplando únicamente los módulos de visualización de situación de reservaciones y ocupación; administración de cupos y generación de reportes. Dichos módulos serán implementados en ambas versiones del sistema y dejarán las bases para el desarrollo de nuevos módulos Lenguajes de programación y maquetación El SRI se desarrollará utilizando el lenguaje de programación PHP en su versión 5.0. A nivel visual, se utilizarán los lenguajes de maquetación HTML y CSS. De igual forma se empleará el lenguaje JavaScript y su framework JQuery Patrón de diseño y framework de desarrollo. Su diseño e implementación se realizarán bajo el enfoque del patrón de diseño de software MVC utilizando Zend Framework Manejo de datos El manejador de base de datos que se utilizará debe ser MySQL 5.1. Por otro lado, los datos se administrarán principalmente utilizando N2C, la cual se conectará con MySQL 5.1 para presentar y facilitar el manejo de los datos. 4.7 Requerimientos de Sistema Hosting dedicado y dominio público El sistema debe disponer de un hosting web y un dominio de acceso público. El hosting debe ser dedicado bajo el sistema operativo Linux y contar con las aplicaciones Apache Server 2.0 (o mayor) y PHP 5.0 (o mayor). La memoria RAM debe ser de al menos 4 Gb y la tasa mínima de ancho de banda mensual debe ser de 1 Tb (1 Terabyte). De igual forma, el hosting debe permitir el acceso por consola y SSH, además de permitir la configuración de cualquier aplicación existente y la posibilidad de instalar nuevas aplicaciones Configuraciones Para el correcto funcionamiento del SRI deben configurarse adecuadamente el servidor de Apache y PHP 5.0, además de adecuar la configuración de Zend Framework al entorno donde será hospedado el sistema. Confidencial,

144 Especificaciones de Requerimientos del Software Fecha: Requerimientos de Ambiente Disponible en cualquier navegador El SRI debe poder ser accedido desde cualquier navegador web de cualquier sistema operativo, especialmente en los más conocidos: Firefox, Internet Explorer, Google Chrome y Safari en sus versiones más actuales Acceso por parte del usuario El usuario que utilice el sistema debe tener acceso a Internet, ya sea a través de un servicio contratado o a través de un teléfono móvil que utilice la red la compañía para ingresar en la red. 4.9 Requerimientos de Documentación en Línea y de Sistemas de Ayuda Manual de usuario y Ayuda en línea Aunque los Manuales de usuario y la Ayuda en línea ya fueron creados, es importante que se actualicen para reflejar los cambios que generen la reingeniería y la implementación de la versión móvil Documentación en línea Toda la documentación del sistema, tanto de código fuente como de documentos de RUP, deben regirse bajo los estándares y estar disponibles en línea a través de la página privada Google Sites dedicada al sistema, para su futura consulta y uso de otros miembros de la empresa. Confidencial,

145 APÉNDICE D DOCUMENTO DE ARQUITECTURA DEL SOFTWARE

146 Reingeniería del Sistema de Reservaciones Inmediatas: Aplicaciones web y móvil Sistema de Reservaciones Inmediatas Documento de Arquitectura del Software Versión 1.0