CAPITULO I MARCO REFERENCIAL 1.

INTRODUCCION La administracin o gestin de personal dentro de un hotel supone en la actualidad una labor cada vez ms compleja, dotada de mayores desafos para quien esta a cargo de tal funcin. En bsqueda de que un hotel sea eficaz y eficiente en sus propsitos, organizar adecuadamente el departamento de personal se vuelve una imperiosa necesidad. En tal sentido, disponer de informacin precisa referida al manejo de personal de un hotel constituye una herramienta de primer orden. As como es imprescindible que un hotel disponga de un sistema de informacin de administracin de recursos humanos con el que pueda acumular informacin actualizada que le permita tomar decisiones gerenciales en esta rea, adems que sea soporte de cualquier toma de decisin pertinente a la gestin de personal y a su organizacin dentro de la empresa hotelera. Informatizar el procesamiento de la informacin sistematizada de recursos humanos de la empresa permite acumular en un mismo software una serie de insumos pertinentes al manejo del personal y su modo de organizarlo en funcin de las metas y objetivos que el hotel se haya trazado. Dicho software de manejo de recursos humanos opera en conjunto a una base de datos del personal con toda la informacin referida a los empleados de que dispone el hotel en todos sus niveles organizacionales. 2. PROBLEMA FORMULACION DEL PROBLEMA El sistema de administracin de recursos humanos podr cubrir las necesidades de informacin que consistira: otorgar consultas interactivas que faciliten la generacion de informes de salarios, faltas y descuentos, y as poder permitir al administrador de recursos humanos tener los datos precisos y actualizados del personal del hotel? 3. OBJETIVO GENERAL Implementar un sistema de informacin para la administracin de recursos humanos incluyendo las nuevas necesidades detectadas, ayudando as en la administracin de personal; adems contar con consultas interactivas que faciliten la generacin de informes 4. OBJETIVOS ESPECIFICOS Implementar un sistema de informacin para mejorar la administracin de recursos humanos del hotel. Elaborar una gestin integral del personal con el que cuenta el hotel, enfatizando en aspectos de eficacia, eficiencia y rentabilidad. Obtener una informacin actualizada y permanente de todo lo relacionado con el manejo de los recursos humanos del hotel, con respaldo informtico en tiempo real.

Reducir al mximo el material impreso en reportes de empleados.

5. JUSTIFICACION 5.1. SOCIAL Las tareas que desempean tanto el administrador de recursos humanos del hotel y el empleado se vern estimuladas cuando existen medios que hacen ms fciles las actividades de los empleados y por ende surge una mayor productividad es decir beneficiara a los usuarios que accedan a los servicios de hotelera del Hotel Gloria. 5.2. ECONOMICA La reduccin del tiempo en la administracin manual de recursos humanos y material de escritorio utilizado por el administrador para los reportes de los empleados en el desempeo de actividades cotidianas la cual establece una nueva forma de trabajo teniendo ms beneficios por menos costo. TECNOLOGICA Permitir la mejora de la administracin de recursos humanos del hotel proporcionara respuestas rpidas a las necesidades de los clientes, empleados y administrador de recursos humanos para la toma de decisiones. Adems de servirse de los adelantos de la tecnologa computacional y de sistemas para mejorar su desempeos y operatividad, brindado de esta manera un mejor servicio integral a la estructura organizacional del hotel. 6. ALCANCES Se implementara un sistema de informacin al rea de administracin de recursos humanos que brinde informacin til y oportuna, para el apoyo en la toma de decisiones al administrador de recursos humanos y gerencia. Se capacitara al administrador de recursos humanos quien ser el directo responsable de las operaciones y manejo del sistema. Contando con consultas interactivas con una interfaz amigable para el usuario. Enmarcara los siguientes mdulos: Control de usuarios Registro del personal Descripcin de cargos Planilla de contratos Registro de seguros Registro de asistencia Registro y control de la capacitacin al personal Ubicacin personal

Calculo de horas trabajadas Control de solicitudes de salida permiso o licencia

Generar reportes y consultas de acuerdo al usuario: nomina del personal, ficha personal, permisos o licencias, capacitacin del personal, horas trabajadas. Todos los informes deben ser mensuales, trimestrales y anuales.

7. MARCO TEORICO 7.1. INSTITUCION El Hotel Gloria es una empresa privada cuya funcin principal es el hospedaje, est ubicado en calle potos nmero 909, cuenta con 90 habitaciones (simples, dobles, matrimoniales y suite) se encuentra cerca de las principales atracciones tursticas ubicado en el centro de la ciudad de La Paz. El hotel ofrece todas las habitaciones con bao privado como tambin ofrece restaurante internacional, nacional y vegetariano, tv cable, desayuno, bufete, parqueo y casa de cambio. ORGANIGRAMA GERENTE GENERAL

ADMINISTRADOR DE RECURSOS HUMANOS CONTABILIDAD RECEPCION BOTONES JEFE DE RESTAURANTE JEFE DE ALMACEN GOBERNANCIA JEFE DE MANTENIMIENTO

Administrador de recursos humanos: encargado del manejo, control y administracin de todos los empleados del hotel. Gobernanta: encargada del control de limpieza de las habitaciones (Personal de limpieza) Jefe de Mantenimiento: encargado del mantenimiento y refaccin de las habitaciones Jefe restaurante: encargado de la administracin del restaurante y de los servicios de comidas y bebidas. Jefe de almacn: encargado del control y administracin del almacn del hotel. Recepcionistas: encargado del recibimiento, registro y asignacin de habitaciones y todo el movimiento de huspedes.

Botones: encargado de cargar el equipaje de los huspedes. 7.2. ADMINISTRACION DE RECURSOS HUMANOS 7.2.1. Objetivo La administracin de recursos humanos consiste en planear, organizar, desarrollar, coordinar y controlar tcnicas capaces de promover el desempeo eficiente del personal, al mismo tiempo que la organizacin representa el medio que permite a las personas que colaboran en ella alcanzar los objetivos individuales relacionados directa o indirectamente con el trabajo. 7.2.2. Polticas La poltica de recursos humanos se refiere a la manera como las organizaciones aspiran a trabajar con sus miembros para alcanzar por intermedio de ellos los objetivos organizacionales. Estas varan enormemente, segn la organizacin. 7.2.3. Componentes La administracin de recursos humanos est constituida por subsistemas interrelacionados; mediante el cual los recursos humanos son captados, empleados, mantenidos, desarrollados y controlados por la organizacin. Varan de acuerdo con la situacin y dependen de factores ambientales, organizacionales, tecnolgicos y humanos.

ADMINISTRACION DE RECURSOS HUMANOS

SUBSISTEMA DE DOTACION DE RECURSOS HUMANOS

SUBSISTEMA APLICACIN DE RECURSOS HUMANOS

SUBSISTEMA DE DESARROLLO DE RECURSOS HUMANOS

SUBSISTEMA DE SEGUIMIENTO O CONTROL DE RECURSOS HUMANOS

Proceso de reclutamiento Seleccin del personal

Socializacin organizacional Diseo y descripcin de cargos Evaluacin del desempeo humano

Entrenamiento o capacitacin Permisos o licencias

Registro de personal Registro de asistencia Ubicacin personal Registros laborales Proceso de transferencia de personal

Administracin de recursos humanos y sus subsistemas

Subsistema dotacin de recursos humanos Por lo general se rene informacin con respecto a los requisitos humanos del puesto como ser los conocimientos o habilidades relacionados con el mismo (educacin, capacitacin, experiencia laboral, etc.), as como los atributos personales (aptitudes, personalidad, intereses, etc.) que se requieren.

Proceso de reclutamiento El reclutamiento de personal procura atraer candidatos potencialmente calificados y capaces de ocupar cargos dentro de la organizacin. Se realiza mediante las convocatorias internas y externas

Proceso de seleccin personal En la seleccin estn los candidatos reclutados aquellos que tengan mayores probabilidades de adaptarse al cargo ofrecido y desempearlo bien.

Subsistema de aplicacin de recursos humanos Es emplear la fuerza de trabajo en la organizacin. Significa que las personas despus de reclutadas y seleccionadas, deben ser integradas en la organizacin, destinados a sus cargos y evaluado en cuanto a su desempeo. Proceso socializacin organizacional La socializacin organizacional procura establecer, junto con el nuevo miembro, las bases de funcionamiento de la organizacin y cual ser su colaboracin en este aspecto. La organizacin trata de inducir la adaptacin y comportamiento del individuo a sus necesidades y objetivos dando a conocer sus caractersticas con firmeza. Proceso de diseo y descripcin de los cargos El diseo consiste en determinar los elementos que componente un cargo y que lo hacen distintos de otros existentes en la entidad. La descripcin del cargo es un proceso que consiste en enumerar las tareas o funciones del cargo. Bsicamente son los elementos que conforman un rol de trabajo que debe cumplir el ocupante del cargo. Proceso evaluacin del desempeo humano La evaluacin del desempeo es un proceso permanente que mide el grado del cumplimiento de su rol en la organizacin. Se elabora preguntas de acuerdo a su cargo y su desempeo, como su participacin en diferentes actividades. Subsistema de desarrollo de recursos humanos Proceso de capacitacin Es un beneficio para el personal, ya que adquieren conocimientos, actitudes y habilidades que les ayuda a fortalecer su conocimiento practico y terico, para su mejor contribucin en el cumplimiento de sus funciones. Esta capacitacin es mediante instruccin asistida por el administrador de recursos humanos. Proceso de permiso o licencia El permiso es una ausencia eventual del puesto de trabajo por un periodo inferior a una jornada, cuya autorizacin es responsabilidad del coordinador de unidad en la que trabaja el personal. La concesin no exceder de dos veces al mes y de

cuatro horas durante dicho periodo, debiendo comunicarse a la administracin para su respectivo registro. La licencia es la inasistencia del trabajo, autorizado por las coordinaciones de unidad a la que pertenece. La licencia puede ser reenumerada o no . Subsistema seguimiento o control de recursos humanos Lo importante es que dentro de la organizacin exista una base de datos de los recursos humanos, capaz de abastecer un sistema de informacin sobre el personal. Proceso registro personal El registro de datos es la actualizacin de la informacin generado por el sistema de administracin personal, que permitir mantener, optimizar y controlar el funcionamiento del sistema, con los siguientes objetivos: Registrar informacin para la actualizacin del sistema, que permitir evaluar las acciones de trabajo. Disponer de una base de datos que permita obtener informacin laboral de cada funcionario. Generar informes individuales del personal Proceso registro asistencia La asistencia del personal de acuerdo al reglamento interno, todo el personal del Hotel Gloria, a excepcin del administrador de recursos humanos, tiene la obligacin de registrar su ingreso y salida, a la organizacin, entrando al sistema a travs de una pc colocada en recepcin . Para verificar jornada de trabajo, horas de trabajo, tolerancia, atrasos, multas por atrasos, faltas y sanciones por faltas. Atrasos Multas por atrasos 16 30 minutos 1/6 de sueldo de un da 31 45 minutos 2/6 de sueldo de un da 45 360 minutos 1 da de falta Proceso de ubicacin personal en las unidades La movilidad del personal en la administracin del momento que forma parte de la organizacin hasta su retiro no es permanente en la funcin que fue asignada, puesto que est sujeto a los cambios que dispone la organizacin: segn a la evaluacin de su desempeo, su adecuacin a las especificaciones del nuevo puesto y segn las demandas de la institucin, procediendo en lo siguiente: Transferir al funcionario de una unidad de trabajo, a otra unidad en puestos afines. Proceso de retiro, en funcin del contrato que puede ser producido por diferentes causas. Promocin del personal, es el movimiento vertical u horizontal implica mayor facultad y remuneracin.

2.2. METODOLOGA 2.2.1. METODOLOGIA EXTREME PROGRAMMING (XP) La programacin extrema es una metodologa de desarrollo ligero (o gil) basada en una serie de valores y de prcticas de buenas maneras que persigue el objetivo de aumentar la productividad a la hora de desarrollar programas. Este modelo de programacin se basa en una serie de metodologas de desarrollo de software en la que se da prioridad a los trabajos que dan un resultado directo y que reducen la burocracia que hay alrededor de la programacin. Una de las caractersticas principales de este mtodo de programacin, es que sus ingredientes son conocidos desde el principio de la informtica. Los autores de XP han seleccionado aquellos que han considerado mejores y han profundizado en sus relaciones y en cmo se refuerzan los unos con los otros. El resultado de esta seleccin ha sido esta metodologa nica y compacta. Por esto, aunque no est basada en principios nuevos, s que el resultado es una nueva manera de ver el desarrollo de software. El objetivo que se persegua en el momento de crear esta metodologa era la bsqueda de un mtodo que hiciera que los desarrollos fueran ms sencillos. Aplicando el sentido comn. Principios bsicos La Programacin Extrema se basa en 12 principios bsicos agrupados en cuatro categoras: Retroalimentacin a escala fina 1. El principio de pruebas: se tiene que establecer un perodo de pruebas de aceptacin del programa (llamado tambin perodo de caja negra) donde se definirn las entradas al sistema y los resultados esperados de estas entradas. Es muy recomendable automatizar estas pruebas para poder hacer varias simulaciones del sistema en funcionamiento. Para hacer estas simulaciones automatizadas, se pueden utilizar Ambientes de Prueba (Unit testing frameworks). Un buen ejemplo de un ambiente de prueba es el JUnit para Java Otros ambientes de pruebas para otros lenguajes como C, C++, JavaScript, XML y servicios Web. 2. Proceso de planificacin: en esta fase, el usuario tendr que escribir sus necesidades, definiendo las actividades que realizar el sistema. Se crear un documento llamado Historias del usuario (User Stories) y tareas de ingeniera. Entre 20 y 80 historias (todo dependiendo de la complejidad del problema) se consideran suficientes para formar el llamado Plan de Liberacin, el cual define de forma especfica los tiempos de entrega de la aplicacin para recibir retroalimentacin por parte del usuario. Por regla general, cada una de las Historias del usuario suelen necesitar de una a tres semanas de desarrollo. Son muy importantes y tienen que ser una constante las reuniones peridicas durante esta fase de planificacin. Estas pueden ser a diario, con todo el equipo de desarrollo para identificar problemas, proponer soluciones y sealar aquellos puntos a los que se les ha de dar ms importancia por su dificultad o por su punto crtico. HISTORIA DE USUARIO

Historia de Usuario Nmero: Nombre Historia de Usuario:

Modificacin (o extensin) de Historia de Usuario (Nro. y Nombre): Usuario: Prioridad en Negocio: (Alta / Media / Baja) Riesgo en Desarrollo: (Alto / Medio / Bajo) Descripcin: Iteracin Asignada: Puntos Estimados:

Puntos Reales:

Observaciones: FICHA TAREA DE INGENIERIA Tarea de Ingeniera Nmero Tarea: Nombre Tarea: Tipo de Tarea : Desarrollo / Correccin / Mejora / Otra Puntos Estimados: (especificar) Fecha Inicio: Programador Responsable: Descripcin: Fecha Fin: Historia de Usuario (Nro. y Nombre):

3. El cliente en el sitio: se le dar poder para determinar los requerimientos, definir la funcionalidad, sealar las prioridades y responder las preguntas de los programadores. Esta fuerte interaccin cara a cara con el programador disminuye el tiempo de comunicacin y la cantidad de documentacin, junto con los altos costes de su creacin y mantenimiento. Este representante del cliente estar con el equipo de trabajo durante toda la realizacin del proyecto. 4. Programacin en parejas: uno de los principios ms radicales y en el que la mayora de gerentes de desarrollo pone sus dudas. Requiere que todos los programadores XP escriban su cdigo en parejas, compartiendo una sola mquina. De acuerdo con los experimentos, este principio puede producir aplicaciones ms buenas, de manera consistente, a iguales o menores costes. Aunque el pair-programming puede no ser para todo el mundo. Proceso continuo en lugar de por lotes 1. Integracin continua: permite al equipo hacer un rpido progreso implementando las nuevas caractersticas del software. En lugar de crear builds (o versiones) estables de acuerdo a un cronograma establecido, los equipos de programadores XP pueden reunir su cdigo y reconstruir el sistema varias veces al da. Esto reduce los problemas de integracin comunes en proyectos largos y estilo cascada. 2. Refactorizacin: permite a los equipos de programadores XP mejorar el diseo del sistema a travs de todo el proceso de desarrollo. Los programadores evalan continuamente el diseo y recodifican lo necesario. La finalidad es mantener un sistema enfocado a proveer el valor de negocio mediante la minimizacin del cdigo duplicado y/o ineficiente. 3. Entregas pequeas: colocan un sistema sencillo en produccin rpidamente que se actualiza de forma rpida y constante permitiendo que el verdadero valor de negocio del producto sea evaluado en un ambiente real. Estas entregas no pueden pasar las 2 o 3 semanas como mximo.

Entendimiento compartido 1. Diseo simple: se basa en la filosofa de que el mayor valor de negocio es entregado por el programa ms sencillo que cumpla los requerimientos. Simple Design se enfoca en proporcionar un sistema que cubra las necesidades inmediatas del cliente, ni ms ni menos. Este proceso permite eliminar redundancias y rejuvenecer los diseos obsoletos de forma sencilla. 2. Metfora: desarrollada por los programadores al inicio del proyecto, define una historia de cmo funciona el sistema completo. XP estimula historias, que son breves descripciones de un trabajo de un sistema en lugar de los tradicionales diagramas y modelos UML (Unified Modeling Language). La metfora expresa la visin evolutiva del proyecto que define el alcance y propsito del sistema. Las tarjetas CRC (Clase, Responsabilidad y Colaboracin) tambin ayudarn al equipo a definir actividades durante el diseo del sistema. Cada tarjeta representa una clase en la programacin orientada a objetos y define sus responsabilidades (lo que ha de hacer) y las colaboraciones con las

otras clases (cmo se comunica con ellas). 3. Propiedad colectiva del cdigo: un cdigo con propiedad compartida. Nadie es el propietario de nada, todos son el propietario de todo. Este mtodo difiere en mucho a los mtodos tradicionales en los que un simple programador posee un conjunto de cdigo. Los defensores de XP argumentan que mientras haya ms gente trabajando en una pieza, menos errores aparecern. 4. Estndar de codificacin: define la propiedad del cdigo compartido as como las reglas para escribir y documentar el cdigo y la comunicacin entre diferentes piezas de cdigo desarrolladas por diferentes equipos. Los programadores las han de seguir de tal manera que el cdigo en el sistema se vea como si hubiera estado escrito por una sola persona. Bienestar del programador. 1. La semana de 40 horas: la programacin extrema sostiene que los programadores cansados escriben cdigo de menor cualidad. Minimizar las horas extras y mantener los programadores frescos, generar cdigo de mayor calidad. Como dice Beck, est bien trabajar tiempos extra cuando es necesario, pero no se ha de hacer durante dos semanas seguidas. PROCESO DE DESARROLLO La programacin extrema parte del caso habitual de una compaa que desarrolla software normalmente a medida, en la que hay diferentes roles: un equipo de gestin (o diseo), uno de desarrollo y los clientes finales. La relacin entre el equipo de diseo, los que desarrollan el software y clientes es totalmente diferente al que se ha producido en las metodologas tradicionales, que se basaba en una fase de captura de los requisitos previa al desarrollo, y de una fase de validacin posterior al mismo. 1. Interaccin con el cliente. En este tipo de programacin el cliente pasa a ser parte implicada en el equipo de desarrollo. Su importancia es mxima en el momento de tratar con los usuarios y en efectuar las reuniones de planificacin. Tiene un papel importante de interaccin con el equipo de programadores, sobre todo despus de cada cambio, y de cada posible problema localizado, mostrando las prioridades, expresando sus sensaciones... En este tipo de programacin existirn pruebas de aceptacin de la programacin que ayudarn a que su labor sea lo ms provechosa posible. Al fin y al cabo, el cliente se encuentra mucho ms cerca del proceso de desarrollo. Se elimina la fase inicial de recopilacin de requerimientos, y se permite que stos se vayan cogiendo a lo largo del proyecto, de una manera ordenada. De esta forma se posibilita que el cliente pueda ir cambiando de opinin sobre la marcha, pero a cambio han de estar siempre disponibles para solucionar las dudas del equipo de desarrollo. En XP aparece un nuevo concepto llamado Historia de usuario. Se trata de una lista de caractersticas que el cliente necesita que existan en el producto final. Estas constan de dos fases: o En la primera fase, el cliente describe con sus propias palabras las caractersticas y, es el responsable del equipo, el encargado de informarlo de las dificultades tcnicas de cada una de ellas y de su coste. A consecuencia de este dilogo, el cliente deja por escrito un conjunto de historias y las ordena en funcin de la prioridad que tienen pera l. De esta manera ya es posible definir unas fechas aproximadas para ellos. o En la segunda fase, el cliente coger las primeras historias a implementar y las dividir

en trabajos a realizar. El cliente tambin participa, pero hay ms peso por parte del equipo de desarrolladores, esto dar como resultado una planificacin ms exacta. Este mtodo se repetir para cada historia. A diferencia de otras tcnicas, como puede ser UML, en el caso de XP, se exige que sea el cliente el encargado de escribir los documentos con las especificaciones de lo que realmente quiere, como un documento de requisitos de usuario. En esta fase, el equipo tcnico ser el 'encargado de catalogar las historias del cliente y asignarles una duracin. La norma es que cada historia de usuario tiene que poder ser realizable en un espacio entre una y tres semanas de programacin. Las que requieran menos tiempo sern agrupadas, y las que necesiten ms sern modificadas o divididas. Finalmente decir que las historias de los usuarios sern escritas en tarjetas, lo que facilitar que el cliente pueda especificar la importancia relativa entre las diferentes historias de usuario, as como el trabajo de los programadores que podrn catalogarlas correctamente. Este formato tambin es muy til en el momento de las pruebas de aceptacin. PLANIFICACIN DEL PROYECTO En este punto se tendr que elaborar la planificacin por etapas, donde se aplicarn diferentes iteraciones. Para hacerlo ser necesaria la existencia de reglas que se han de seguir por las partes implicadas en el proyecto para que todas las partes tengan voz y se sientan realmente partcipes de la decisin tomada. Las entregas se tienen que hacer cuanto antes mejor, y con cada iteracin, el cliente ha de recibir una nueva versin. Cuanto ms tiempo se tarde en introducir una parte esencial, menos tiempo se tendr para trabajar con ella despus. Se aconseja muchas entregas y muy frecuentes. De esta manera un error en la parte inicial del sistema tiene ms posibilidades de detectarse rpidamente. Una de las mximas a aplicar es, los cambios, no han de suponer ms horas de programacin para el programador, ya que el que no se termina en un da, se deja para el da siguiente. Se ha de tener asumido que en el proceso de planificacin habrn errores, es ms, sern comunes, y por esto esta metodologa ya los tiene previstos, por lo tanto se establecern mecanismos de revisin. Cada tres o cinco iteraciones es normal revisar las historias de los usuarios, y renegociar la planificacin. Cada iteracin necesita tambin ser planificada, es lo que se llama planificacin iterativa, en la que se anotarn las historias de usuarios que se consideren esenciales y las que no han pasado las pruebas de aceptacin. Estas planificaciones tambin se harn en tarjetas, en las que se escribirn los trabajos que durarn entre uno y tres das. Es por esto que el diseo se puede clasificar como continuo. Aade agilidad al proceso de desarrollo y evita que se mire demasiado hacia delante, desarrollando trabajos que an no han estado programados. Este tipo de planificacin en iteraciones y el diseo iterativo, hace que aparezca una prctica que no exista en la programacin tradicional. Se trata de las discusiones diarias informales, para fomentar la comunicacin, y para hacer que los desarrolladores tengan tiempo de hablar de los problemas a los que se enfrentan y de ver cmo van con sus trabajos. DISEO, DESARROLLO Y PRUEBAS El desarrollo es la parte ms importante en el proceso de la programacin extrema. Todos

los trabajos tienen como objetivo que se programen lo ms rpidamente posible, sin interrupciones y en direccin correcta. Tambin es muy importante el diseo, y se establecen los mecanismos, para que ste sea revisado y mejorado de manera continuada a lo largo del proyecto, segn se van aadiendo funcionalidades al mismo. La clave del proceso de desarrollar XP es la comunicacin. La mayora de los problemas en los proyectos son por falta de comunicacin en el equipo. En XP, aparece un nuevo concepto llamado Metfora. Su principal objetivo es mejorar la comunicacin entre todos los integrantes del equipo, al crear una visin global y comn de lo que se quiere desarrollar. La metfora tiene que ser expresada en trminos conocidos por los integrantes del equipo, por ejemplo comparando el sistema que se desarrollar con alguna cosa de la vida real. Antes de empezar a codificar se tienen que hacer pruebas unitarias, es decir: Cada vez que se quiere implementar una parte de cdigo, en XP, se tiene que escribir una prueba sencilla, y despus escribir el cdigo para que la pase. Una vez pasada se ampla y se contina. En XP hay una mxima que dice "Todo el cdigo que puede fallar tiene que tener una prueba". Con estas normas se obtiene un cdigo simple y funcional de manera bastante rpida. Por esto es importante pasar las pruebas al 100%. Respecto a la integracin del soft, en XP se ha de hacer una integracin continua, es decir, cada vez se tienen que ir integrando pequeos fragmentos de cdigo, para evitar que al finalizar el proyecto se tenga que invertir grandes esfuerzos en la integracin final. En todo buen proyecto de XP, tendra que existir una versin al da integrada, de manera que los cambios siempre se realicen en esta ltima versin. Otra peculiaridad de XP es que cada programador puede trabajar en cualquier parte del programa. De esta manera se evita que haya partes "propietarias de cada programador". Por esto es tan importante la integracin diaria. Para terminar, otra peculiaridad que tiene la XP. La de fomentar la programacin en parejas, es decir, hacer que los programadores no trabajen en solitario, sino que siempre estarn con otra persona. Una pareja de programadores ha de compartir el teclado, el monitor y el ratn. El principio fundamental de este hecho es realizar de manera continua y sin parar el desarrollo de cdigo. Las parejas tienen que ir cambiando de manera peridica, para hacer que el conocimiento se difunda en el grupo. Est demostrado que de esta manera el trabajo es ms eficaz y tambin se consigue ms y mejor cdigo.

2.2.3. UML

UML [UML] es un lenguaje para especificar, construir, visualizar y documentar los artefactos de un sistema de software orientado a objetos (OO). Un artefacto es una informacin que es utilizada o producida mediante un proceso de desarrollo de software. UML se quiere convertir en un lenguaje estndar con el que sea posible modelar todos los componentes del proceso de desarrollo de aplicaciones. Sin embargo, hay que tener en cuenta un aspecto importante del modelo: no pretende definir un modelo estndar de desarrollo, sino nicamente un lenguaje de modelado. Otros mtodos de modelaje como OMT (Object Modeling Technique) o Booch s definen procesos concretos. En UML los

procesos de desarrollo son diferentes segn los distintos dominios de trabajo; no puede ser el mismo el proceso para crear una aplicacin en tiempo real, que el proceso de desarrollo de una aplicacin orientada a gestin, por poner un ejemplo. Las diferencias son muy marcadas y afectan a todas las faces del proceso. El mtodo del UML recomienda utilizar los procesos que otras metodologas tienen definidos. Modelado de objetos El UML es una tcnica de modelado de objetos y como tal supone una abstraccin de un sistema para llegar a construirlo en trminos concretos. El modelado no es ms que la construccin de un modelo a partir de una especificacin. Un modelo es una abstraccin de algo, que se elabora para comprender ese algo antes de construirlo. El modelo omite detalles que no resultan esenciales para la comprensin del original y por lo tanto facilita dicha comprensin. Los modelos se utilizan en muchas actividades de la vida humana: antes de construir una casa el arquitecto utiliza un plano, los msicos representan la msica en forma de notas musicales, los artistas pintan sobre el lienzo con carboncillos antes de empezar a utilizar los leos, etc. Unos y otros abstraen una realidad compleja sobre unos bocetos, modelos al fin y al cabo. La OMT, por ejemplo, intenta abstraer la realidad utilizando tres clases de modelos OO: el modelo de objetos, que describe la estructura esttica; el modelo dinmico, con el que describe las relaciones temporales entre objetos; y el modelo funcional que describe las relaciones funcionales entre valores. Mediante estas tres fases de construccin de modelos, se consigue una abstraccin de la realidad que tiene en s misma informacin sobre las principales caractersticas de sta.

UML utiliza parte de este planteamiento obteniendo distintos puntos de vista de la realidad que modela mediante los distintos tipos de diagramas que posee. Con la creacin del UML se persigue obtener un lenguaje que sea capaz de abstraer cualquier tipo de sistema, sea informtico o no, mediante los diagramas, es decir, mediante representaciones grficas que contienen toda la informacin relevante del sistema. Un diagrama es una representacin grfica de una coleccin de elementos del modelo, que habitualmente toma forma de grafo donde los arcos que conectan sus vrtices son las relaciones entre los objetos y los vrtices se corresponden con los elementos del modelo. Los distintos puntos de vista de un sistema real que se quieren representar para obtener el modelo se dibuja d forma que se resaltan los detalles necesarios para entender el sistema. Artefactos para el Desarrollo de Proyectos Un artefacto es una informacin que es utilizada o producida mediante un proceso de desarrollo de software. Pueden ser artefactos un modelo, una descripcin o un software. Los artefactos de UML se especifican en forma de diagramas, stos, junto con la documentacin sobre el sistema constituyen los artefactos principales que el modelador puede observar.

Se necesita ms de un punto de vista para llegar a representar un sistema. UML utiliza los diagramas grficos para obtener estos distintos puntos de vista de un sistema:

Diagramas de Implementacin. Diagramas de Comportamiento o Interaccin. Diagramas de Casos de uso. Diagramas de Clases. Diagramas de componentes Muestra la dependencia entre los distintos componentes de software, incluyendo componentes de cdigo fuente, binario y ejecutable. Un componente es un fragmento de cdigo software (un fuente, binario o ejecutable) que se utiliza para mostrar dependencias en tiempo de compilacin. Diagrama de plataformas o despliegue Muestra la configuracin de los componentes hardware, los procesos, los elementos de procesamiento en tiempo de ejecucin y los objetos que existen en tiempo de ejecucin. En este tipo de diagramas intervienen nodos, asociaciones de comunicacin, componentes dentro de los nodos y objetos que se encuentran a su vez dentro de los componentes. Un nodo es un objeto fsico en tiempo de ejecucin, es decir una mquina que se compone habitualmente de, por lo menos, memoria y capacidad de procesamiento, a su vez puede estar formado por otros componentes. Diagramas de Interaccin o Comportamiento Muestran las interacciones entre objetos ocurridas en un escenario (parte) del sistema. Hay varios tipos: Diagrama de secuencia. Diagrama de colaboracin. Diagrama de estado. Diagrama de actividad. Diagrama de secuencia Muestran las interacciones entre un conjunto de objetos, ordenadas segn el tiempo en que tienen lugar. En los diagramas de este tipo intervienen objetos, que tienen un significado parecido al de los objetos representados en los diagramas de colaboracin, es decir son instancias concretas de una clase que participa en la interaccin. El objeto puede existir slo durante la ejecucin de la interaccin, se puede crear o puede ser destruido durante la ejecucin de la interaccin. Un diagrama de secuencia representa una forma de indicar el perodo durante el que un objeto est desarrollando una accin directamente o a travs de un procedimiento. Diagrama de colaboracin Muestra la interaccin entre varios objetos y los enlaces que existen entre ellos. Representa las interacciones entre objetos organizadas alrededor de los objetos y sus vinculaciones. A diferencia de un diagrama de secuencias, un diagrama de

colaboraciones muestra las relaciones entre los objetos, no la secuencia en el tiempo en que se producen los mensajes. Los diagramas de secuencias y los diagramas de colaboraciones expresan informacin similar, pero en una forma diferente. Formando parte de los diagramas de colaboracin nos encontramos con objetos, enlaces y mensajes. Un objeto es una instancia de una clase que participa como una interaccin, existen objetos simples y complejos. Un objeto es activo si posee un thread o hilo de control y es capaz de iniciar la actividad de control, mientras que un objeto es pasivo si mantiene datos pero no inicia la actividad.

Diagramas de actividad Son similares a los diagramas de flujo de otras metodologas OO. En realidad se corresponden con un caso especial de los diagramas de estado donde los estados son estados de accin (estados con una accin interna y una o ms transiciones que suceden al finalizar esta accin, o lo que es lo mismo, un paso en la ejecucin de lo que ser un procedimiento) y las transiciones vienen provocadas por la finalizacin de las acciones que tienen lugar en los estados de origen. Siempre van unidos a una clase o a la implementacin de un caso de uso o de un mtodo (que tiene el mismo significado que en cualquier otra metodologa OO). Los diagramas de actividad se utilizan para mostrar el flujo de operaciones que se desencadenan en un procedimiento interno del sistema. Diagramas de estado Representan la secuencia de estados por los que un objeto o una interaccin entre objetos pasa durante su tiempo de vida en respuesta a estmulos (eventos) recibidos. Representa lo que podemos denominar en conjunto una mquina de estados. Un estado en UML es cuando un objeto o una interaccin satisface una condicin, desarrolla alguna accin o se encuentra esperando un evento.

Diagramas de Casos de Uso Unos casos de uso es una secuencia de transacciones que son desarrolladas por un sistema en respuesta a un evento que inicia un actor sobre el propio sistema Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al mostrar como reacciona una respuesta a eventos que se producen en el mismo. En este tipo de diagrama intervienen algunos conceptos nuevos: un actor es una entidad externa al sistema que se modela y que puede interactuar con l; un ejemplo de actor podra ser un usuario o cualquier otro sistema. Las relaciones entre casos de uso y actores pueden ser las siguientes:

Un actor se comunica con un caso de uso. Un caso de uso extiende otro caso de uso. Un caso de uso usa otro caso de uso

Diagramas de Clases Los diagramas de clases representan un conjunto de elementos del modelo que son estticos, como las clases y los tipos, sus contenidos y las relaciones que se establecen entre ellos.

Algunos de los elementos que se pueden clasificar como estticos son los siguientes: Paquete: Es el mecanismo de que dispone UML para organizar sus elementos en grupos, se representa un grupo de elementos del modelo. Un sistema es un nico paquete que contiene el resto del sistema, por lo tanto, un paquete debe poder anidarse, permitindose que un paquete contenga otro paquete. Clases: Una clase representa un conjunto de objetos que tienen una estructura, un comportamiento y unas relaciones con propiedades parecidas. Describe un conjunto de objetos que comparte los mismos atributos, operaciones, mtodos, relaciones y significado. En UML una clase es una implementacin de un tipo. Los componentes de una clase son: Atributo. Se corresponde con las propiedades de una clase o un tipo. Se identifica mediante un nombre. Existen atributos simples y complejos. Operacin. Tambin conocido como mtodo, es un servicio proporcionado por la clase que puede ser solicitado por otras clases y que produce un comportamiento en ellas cuando se realiza. Las clases pueden tener varios parmetros formales, son las clases denominadas plantillas. Sus atributos y operaciones vendrn definidas segn sus parmetros formales. Las plantillas pueden tener especificados los valores reales para los parmetros formales, entonces reciben el nombre de clase parametrizada instanciada. Se puede usar en cualquier lugar en el que se podra aparecer su plantilla. Relacionando con las clases nos encontramos con el trmino utilidad, que se corresponde con una agrupacin de variables y procedimientos globales en forma de declaracin de clase, tambin puede definirse como un estereotipo (o nueva clase generada a partir de otra ya existente) de un tipo que agrupa variables globales y procedimientos en una declaracin de clase. Los atributos y operaciones que se agrupan en una utilidad se convierten en variables y operaciones globales. Una utilidad no es fundamental para el modelado, pero puede ser conveniente durante la programacin. Metaclase: Es una clase cuyas instancias son clases. Sirven como depsito para mantener las variables de clase y proporcionan operaciones (mtodo de clase) para inicializar estas variables. Se utilizan para construir metamodelos (modelos que se utilizan para definir otros modelos). Tipos: Es un descriptor de objetos que tiene un estado abstracto y especificaciones de operaciones pero no su implementacin. Un tipo establece una especificacin de comportamiento para las clases. Interfaz: Representa el uso de un tipo para describir el comportamiento visible externamente de cualquier elemento del modelo. Relacin entre clases: Las clases se relacionan entre s de distintas formas, que marcan los tipos de relaciones existentes: Asociacin: Es una relacin que describe un conjunto de vnculos entre clases. Pueden ser binarias o narias, segn se implican a dos clases o ms. Las relaciones de asociacin vienen identificadas por los roles, que son los nombres que indican el comportamiento que tienen los tipos o las clases, en el caso del rol de asociacin (existen otros tipos de roles segn la relacin a la que identifiquen). Indican la informacin ms importante de las asociaciones. Composicin: Es un tipo de agregacin donde la relacin de posesin es tan fuerte como para marcar otro tipo de relacin. Las clases en UML tienen un tiempo de vida determinado, en las relaciones de composicin, el tiempo de vida de la clase que es parte del todo (o agregado) viene determinado por el tiempo de vida de la clase que representa el todo, por tanto es

equivalente a un atributo, aunque no lo es porque es una clase y puede funcionar como tal en otros casos. Generalizacin: Cuando se establece una relacin de este tipo entre dos clases, una es una Superclase y la otra es una Subclase. La subclase comparte la estructura y el comportamiento de la superclase. Puede haber ms de una clase que se comporte como subclase. Dependencia: Una relacin de dependencia se establece entre clases (u objetos) cuando un cambio en el elemento independiente del modelo puede requerir un cambio en el elemento dependiente. INVESTIGACIN CALIDAD DEL SOFTWARE La calidad del software es el grado con el que un sistema, componente o proceso cumple los requerimientos especificados y las necesidades o expectativas del cliente o usuario. [IEEE, Std 610-1900] Concordancia del software producido con los requerimientos explcitamente establecidos, con los estndares de desarrollo prefijados y con los requerimientos implcitos no establecidos formalmente, que desea el usuario. [Pressman, 1998]

COSTOS DE BENEFICIOS Radio Beneficio/Costo B/CR = Beneficio/Costo Es una medida de cuanto dinero se obtiene por usar una estrategia de costo determinada. B/C 1:1 cada dlar gastado recibe otro Todo gratis, pague una comida y le devuelven el dinero B/C 0.5:1 Por cada dlar se retorna 0.50 Si pago 20 dlares por llenar el tanque de mi carro y me devuelven 10 dlares B/C 2:1 Por cada dlar invertido se reciben 2 En proyectos de software pueden obtener radios de hasta 1000:1 SEGURIDAD La seguridad informtica, es el rea de la informtica que se enfoca en la proteccin de la infraestructura computacional y todo lo relacionado con sta (incluyendo la informacin contenida). Para ello existen una serie de estndares, protocolos, mtodos, reglas, herramientas y leyes concebidas para minimizar los posibles riesgos a la infraestructura o a la informacin. La seguridad informtica comprende software, bases de datos, metadatos, archivos y todo lo que la organizacin valore (activo) y signifique un riesgo si sta llega a manos de otras personas. Este tipo de informacin se conoce como informacin privilegiada o confidencial.. TECNOLOGIAS DE SOFTWARE El lenguaje programacin para el desarrollo del sistema es SQL y PHP que presentan un entorno de desarrollo netamente visual, el entorno de desarrollo de SQL es simple, flexible y potente al mismo tiempo contando con un gran nmero de componentes prefabricados que simplificaran de forma notable la creacin de cualquier aplicacin.

CAPITULO III MARCO APLICATIVO La metodologa agil de desarrollo de software enfatiza ms: Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas Desarrollar software que funciona mas que conseguir una buena documentacin. La colaboracin con el cliente mas que la negociacin de un contrato Responder a los cambios mas que seguir estrictamente un plan.

3.1. FASES DE DESARROLLO DEL SOFTWARE El trabajo de desarrollo de software se facilita y se agiliza ya que se adopto la METODOLOGIA AGIL y de la metodologa gil se escogi el modelo de desarrollo de

software XP (PROGRAMACION EXTREMA) y se tomaron en cuenta las siguientes fases: Planificacin Diseo Codificacin Pruebas

3.1.2 PLANIFICACION De acuerdo con el modelo de programacin extrema (XP) de la metodologa gil el proceso de planeacin se lo debe realizar con el cliente in situ ( en su rea de trabajo) y es ah donde se determinaron los procesos y actividades ms importantes, estos fueron plasmados en HISTORIAS DE USUARIO junto con las descripciones de interfaz que propuso el usuario y los mismos fueron ordenados por niveles de prioridad. El inicio de las actividades del hotel tiene una sola persona que se encarga de la administracin del personal como tambin en la parte operativa. Parte administrativa Evala y prioriza la contratacin de nuevo personal

Parte operativa Verifica vencimiento de contratos Realiza cambios de personal Realiza el pago al personal

Es por este motivo que la nica persona con que mas se interacta es con el administrador del personal del hotel con la cual se determinaron las historias de usuario en funcin de la experiencia que el posee y actividades que forman parte del hotel y que son las siguientes: PROCESO DE RECLUTAMIENTO En ese modulo se realizara mediante una seleccin de diferentes curriculums que hayan sido decepcionados por el administrador de recursos humanos, y as entrevistar a los candidatos potencialmente calificados . PROCESO DE REGISTRO DE NUEVO PERSONAL HISTORIA DE USUARIO Numero:1 Usuario/area de trabajo: Administracion Nombre de historia: Altas, Bajas, Consulta de datos del personal Prioridad: (Alta/Media/Baja) Riesgo en desarrollo: (Alta/Media/Baja) Puntos estimados: Iteracion asignada: 3 Programador responsable:

Descripcin segn cliente: este modulo debe tener la finalidad de registrar, la informacin del personal como ser: Nombre, C.I, Fecha de nacimiento, edad, nacionalidad, estado civil, sexo, telfono y direccin. Observaciones: NO CONFIRMADO CON EL CLIENTE PROCESO DE CAPACITACION En este proceso se da un tiempo mximo de 2 das para fortalecer el conocimiento prctico con una instruccin asistida por el jefe de rea. PROCESO DE PERMISOS Y LICENCIAS HISTORIA DE USUARIO Numero:2 Usuario/area de trabajo: Administracion Nombre de historia: Altas, Bajas, Consulta de datos del personal Prioridad: (Alta/Media/Baja) Riesgo en desarrollo: (Alta/Media/Baja) Puntos estimados: Iteracion asignada: 3 Programador responsable: Descripcin segn cliente: este modulo debe tener la finalidad de registrar, la informacin de los permisos y licencias del personal como ser: tipo de permiso, fecha salida, fecha retorno, hora salida, hora retorno, motivo Observaciones: NO CONFIRMADO CON EL CLIENTE PROCESO DE EVALUACION DEL DESEMPEO HUMANO HISTORIA DE USUARIO Numero:2 Usuario/area de trabajo: Administracion Nombre de historia: Generacin automtica de listas de personal Prioridad: (Alta/Media/Baja) Riesgo en desarrollo: (Alta/Media/Baja) Puntos estimados: Iteracion asignada: 3 Programador responsable: Descripcin segn cliente: este modulo debe tener la finalidad de armar listas de la informacin del personal de acuerdo a las faltas y retrasos. Y sugerir a los empleados con menos faltas y retrasos para fines de inters del administrador como ser elevar de cargo o recisin de contrato de acuerdo a normas internas del hotel. Observaciones: NO CONFIRMADO CON EL CLIENTE PROCESO DE REGISTRO DE ASISTENCIA HISTORIA DE USUARIO Numero:2 Usuario/area de trabajo: Administracion Nombre de historia: Altas, Bajas, Consulta de datos del personal Prioridad: (Alta/Media/Baja) Riesgo en desarrollo: (Alta/Media/Baja) Puntos estimados: Iteracion asignada: 3 Programador responsable: Descripcin segn cliente: este modulo debe tener la finalidad de registrar, la informacin de del personal marcando con su tarjeta luego registrar la informacin: fecha de asistencia, hora de entrada, hora de salida, hora total, hora atrasada. Observaciones: NO CONFIRMADO CON EL CLIENTE

PROCESO DE PAGOS DE SUELDOS HISTORIA DE USUARIO Numero:2 Usuario/area de trabajo: Administracion Nombre de historia: Altas, Bajas, Generacin automtica de listas de pagos al personal Prioridad: (Alta/Media/Baja) Riesgo en desarrollo: (Alta/Media/Baja) Puntos estimados: Iteracion asignada: 3 Programador responsable: Descripcin segn cliente: este modulo debe tener la finalidad de armar listas del personal por unidad con columnas que representen la cantidad de dinero acorde a sus horas trabajadas y escala salariar interna del hotel. Observaciones: CONFIRMADO CON EL CLIENTE 3.2.2. DISEO De acuerdo al modelo de desarrollo XP ( Programacion Extrema) de la metodologa agl se debe disear la solucin ms simple posible que pueda funcionar y ser implementada en funcin de interfaces propuestas por el usuario. MODELO DEL NEGOCIO Para realizar los diferentes diagramas necesitamos identificar los elementos externos e internos que interactan con el sistema IDENTIFICACION DE ACTORES Administrador de recursos humanos: persona que administra y solicita informacin personal sobre sueldos, aos de servicio, actualizaciones y otros con respeto al personal que trabaja en el hotel Personal de trabajo (Usuario): persona que requiere informacin de datos personales, seguimiento y otros.

MODELO DE CASOS DE USO DE ADMINISTRACION DE RECURSOS HUMANOS Especificaremos los casos de uso, que representan una excelente forma de mostrar el comportamiento externo del sistema, de esta manera entender las diferentes funciones del mismo. Para la representacin de los casos de uso utilizaremos la notacin UML .

Registro de datos Personales

Hoja de Vida

Administrador recursos humanos

Registro de contrato Registro Asistencia Evaluacin personal

Usuario

Caso de Uso: Registrar Personal Precondicin El administrador de recursos humanos tiene los documentos del personal a registrar Flujo de Sucesos 1.El Administrador de recursos humanos registra los datos personales. 2.El Administrador guarda los datos al sistema. 3.El Administrador elije la unidad a la que pertenece el personal 4.El administrador coloca el cargo que ocupa 5.El sistema asigna un cdigo al personal. 6.El administrador guarda todos los datos. Postcondicion la instancia del caso de uso termina con la muestra en pantalla el cdigo asignado al personal, en otro caso con el mensaje registro no guardado. Caso de Uso: Registrar contrato Precondicin El administrador de recursos humanos tiene los documentos del contrato ya firmado por el personal Flujo de Sucesos 1.El Administrador de recursos humanos registra los datos del contrato. 2.El Administrador guarda los datos al sistema. 6.El administrador guarda todos los datos. Postcondicion La instancia del caso de uso termina con la muestra en pantalla el cdigo asignado al personal, en otro caso con el mensaje registro no guardado. Caso de Uso: Registrar asistencia Precondicin El administrador debe habilitar el sistema antes de que el personal llegue a su respectivo trabajo. Flujo de Sucesos 1.El Personal coloca su c.i. al sistema 2.El Personal coloca aceptar. 5.El sistema guarda a la base de datos la fecha y hora de llegada. Postcondicion La instancia del caso de uso termina con la muestra en pantalla el cdigo asignado al personal, en otro caso con el mensaje registro no guardado. Caso de Uso: Evaluacin del personal Precondicin El administrador de recursos humanos tiene los datos registrados del todo el personal. Flujo de Sucesos

1.El Administrador de recursos humanos elije del men principal la opcin evaluacin 2.El Administrador de recursos humanos elije del men la opcin destacados o no destacados. 3.El sistema mediante bsquedas mostrara una lista del personal con informacin de inicio de contrato, registro de asistencia, unida a la que pertenece y sueldo que percibe. 3.El Administrador toma una decisin con respecto a los resultados si se requiere. Postcondicion la instancia del caso de uso termina con la opcin salir. CODIFICACION

PRUEBAS De acuerdo a la programacin Extrema de la Metodologa gil se construyo el sistema en progreso de versiones, esto obliga a los programadores como en este caso a que la ultima versin entregada cumpla y contemple todos los procesos y actividades administrativas y operativas que acontecen en el hotel en funcin a sus necesidades reales.

Esto se logro luego de varias iteraciones (entrega y progreso de versiones) realizadas con el usuario.

CRONOGRAMA Nro Nombre Comienzo Duracin 2013 Marzo Abril Mayo Junio 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4

1 2 3 4 5 6

Planificacin Diseo Codificacin Iteracin I Iteracin II Iteracin III

CAPITULO IV CONCLUSIONES Y RECOMENDACIONES CONCLUSIONES El sistema de administracin de recursos humanos cumple el objetivo descrito anteriormente El sistema cuenta con los siguientes mdulos: control de usuarios, registro de funcionarios, ubicacin personal, dotacin personal, permiso o licencia, capacitaciones, registro laboral, control asistencia y evaluaciones son procedimientos automticos que facilitan obtener informacin real para buena toma de decisiones y adems responde a los requerimientos del usuario final. Se cumpli con el objetivo principal de facilitar el flujo de informacin para la administracin de recursos humanos obteniendo resultados fiables RECOMENDACIONES Como consecuencia del presente trabajo surgen algunos tpicos que pueden ser ampliados en futuros trabajos relacionados a este tema en particular por tanto se plantea las siguientes recomendaciones. - Adicionar algn modulo e contabilidad para el control de sueldos y aportes a sus respectivos seguros.

8. FUENTES DE INFORMACIN

Sistema de informacin hotelera, proyecto de grado, Autor miguel Eduardo Cabrera. Pressman, R. 1993: Ingeniera de Software, 3ra edicin 825pp, Mc. Graw-Hill Mxico. Richard f., 1987: Ingeniera de Software 1ra. ED., 390pp., Graw-Hill Mexico Senn, J., 1992: Anlisis y Diseo de Sistemas informacin, 2da Ed., 801pp., GrawHill Mxico.