UNIVERSIDAD REGIONAL AUTÓNOMA DE LOS...
Transcript of UNIVERSIDAD REGIONAL AUTÓNOMA DE LOS...
UNIVERSIDAD REGIONAL AUTÓNOMA DE LOS ANDES
“UNIANDES - IBARRA”
FACULTAD DE SISTEMAS MERCANTILES
CARRERA DE SISTEMAS
PROYECTO DE EXAMEN COMPLEXIVO PREVIO LA OBTENCIÓN DEL
TITULO DE INGENIERA EN SISTEMAS E INFORMÁTICA
TEMA:
IMPLEMENTACIÓN DEL MÓDULO DE RECURSOS HUMANOS AL
SISTEMA DE PLANIFICACIÓN DE RECURSOS EMPRESARIALES ODOO
VERSIÓN 8.0 PARA LA EMPRESA VIRTUALSAMI CIA. LTDA.
AUTORA: MAFLA IBUJES AMANDA SILVANA
ASESOR: ING. MARTÍNEZ CAMPAÑA CARLOS EDUARDO.
AMBATO – ECUADOR
2016
APROBACIÓN DEL ASESOR DEL TRABAJO DE TITULACIÓN
CERTIFICACIÓN:
Quien suscribe, legalmente CERTIFICA QUE: El presente Trabajo de Titulación
realizado por la señorita Mafla Ibujes Amanda Silvana, estudiante de la Carrera de
Sistemas, Facultad de Sistemas Mercantiles, con el tema “IMPLEMENTACIÓN DEL
MÓDULO DE RECURSOS HUMANOS AL SISTEMA DE PLANIFICACIÓN DE
RECURSOS EMPRESARIALES ODOO VERSIÓN 8.0 PARA LA EMPRESA
VIRTUALSAMI CIA. LTDA”, ha sido prolijamente revisado, y cumple con todos los
requisitos establecidos en la normativa pertinente de la Universidad Regional Autónoma
de los Andes -UNIANDES-, por lo que apruebe su presentación.
Ambato, Julio de 2016
ING. MARTÍNEZ CAMPAÑA CARLOS EDUARDO.
ASESOR
DECLARACIÓN DE AUTENTICIDAD
Yo, Mafla Ibujes Amanda Silvana, estudiante de la Carrera de Sistemas, Facultad de
Sistemas Mercantiles, declaro que todos los resultados obtenidos en el presente trabajo
de investigación, previo a la obtención del título de INGENIERA EN SISTEMAS E
INFORMÁTICA, son absolutamente originales, auténticos y personales; a excepción de
las citas, por lo que son de mi exclusiva responsabilidad.
Atentamente,
Ambato, Julio de 2016
MAFLA IBUJES AMANDA SILVANA
C.I. 0401501044
AUTORA
DERECHOS DE AUTOR
Yo, Mafla Ibujes Amanda Silvana, declaro que conozco y acepto la disposición constante
en el literal d) del Art. 85 del Estatuto de la Universidad Regional Autónoma de Los
Andes, que en su parte pertinente textualmente dice: El Patrimonio de la UNIANDES,
está constituido por: La propiedad intelectual sobre las Investigaciones, trabajos
científicos o técnicos, proyectos profesionales y consultaría que se realicen en la
Universidad o por cuenta de ella;
Ambato, Julio de 2016
MAFLA IBUJES AMANDA SILVANA
C.I. 0401501044
AUTORA
DEDICATORIA
El presente trabajo, en el cual va reflejado mi sacrificio, esfuerzo y constancia para
alcanzar el anhelado deseo, se lo dedico con todo cariño a:
A mi Padre David Mafla por darme su fortaleza e inspiración, por su sencillez y espíritu
guerrero, por nunca darse por vencido por más difícil que parezca el camino, por el amor
y valor demostrado, va por ti héroe.
A mi Madre María Teresa Ibujés por su dulzura y amor incondicional, por su persistencia,
por creer en mí con fe ciega, por su perseverancia en verme con un futuro sólido y ser yo
la ofrenda que ella hace a Dios para la sociedad, le dedico a usted querida Mamita
Adorada.
A mi hijo David Alejandro por ser la eterna motivación que Dios me ha dado, por hacerme
sentir que los sacrificios, son algo fácil, solo a cambio de recibir tu dulce sonrisa, es el
premio que yo como tu madre, me hace sentir la mujer más feliz de este planeta.
A mis hermanos Brenda, Franklin, y mis sobrinos Sebastián, Gabrielito y mi cuñada
Adriana portadores del ánimo y apoyo incondicional en todos los aspectos, porque son
ellos quienes han estado presentes en los momentos más difíciles.
Por último y no menos importante a mí esposo, Alcides Rivera Posso por su sabiduría y
paciencia por creer en mi capacidad, que con su apoyo constante y amor incondicional ha
sido compañero y amigo inseparable.
Amanda Mafla I.
AGRADECIMIENTO
Al terminar este trabajo, quiero elevar mi más profundo agradecimiento a mi amigo Jesús
y a María Madre Santísima, que han estado conmigo de la mano en las buenas y en las
malas, por cada camino que he escogido ir y nunca me han abandonado, por ser
incondicionales y aceptarme con mis defectos y virtudes, por otorgarme el privilegio de
la vida, y por haberme permitido formarme académicamente con altura pero con mucha
humildad en el corazón
A la Universidad Regional Autónoma de los Andes, en cuyas aulas recibí valiosos
conocimientos que me ayudaron a formar mi perfil profesional.
Además un agradecimiento especial a los Ingenieros Carlos Martínez y Alcides Rivera,
distinguido catedrático y esposo respectivamente, quienes con entrega ejemplar,
sacrificio y nobleza orientaron en forma desinteresada la realización de este trabajo
Amanda Mafla I.
ÍNDICE GENERAL
PORTADA
APROBACIÓN DEL ASESOR DEL TRABAJO DE TITULACIÓN
DECLARACIÓN DE AUTENTICIDAD
DERECHOS DE AUTOR
DEDICATORIA
AGRADECIMIENTO
ÍNDICE GENERAL
ÍNDICE DE TABLAS
ÍNDICE DE GRÁFICOS
RESUMEN EJECUTIVO
1 CAPÍTULO I ............................................................................................................................. 1
INTRODUCCIÓN ........................................................................................................................ 1
1.1 ANTECEDENTES DE LA INVESTIGACIÓN ...................................................... 1
1.2 PLANTEAMIENTO DEL PROBLEMA ................................................................ 2
1.3 FORMULACIÓN DEL PROBLEMA ..................................................................... 3
1.4 DELIMITACIÓN DEL PROBLEMA ..................................................................... 3
1.5 OBJETIVOS DE INVESTIGACIÓN Y CAMPO DE ACCIÓN ........................... 3
1.5.1 OBJETIVO DE INVESTIGACIÓN ........................................................................ 3
1.5.2 CAMPO DE ACCIÓN ............................................................................................ 4
1.6 IDENTIFICACIÓN DE LA LÍNEA DE INVESTIGACIÓN ................................ 4
1.7 OBJETIVOS .............................................................................................................. 4
1.7.1 GENERAL .............................................................................................................. 4
1.7.2 ESPECÍFICOS ........................................................................................................ 4
1.8 IDEA A DEFENDER................................................................................................. 5
1.9 JUSTIFICACIÓN DE LA NECESIDAD, ACTUALIDAD IMPORTANCIA ..... 5
1.10 METODOLOGÍA DE LA INVESTIGACIÓN CIENTÍFICA .............................. 6
1.11 RESUMEN DE LA ESTRUCTURA DEL PROYECTO ....................................... 6
1.12 ELEMENTOS DE NOVEDAD, APORTE TEÓRICO Y SIGNIFICACIÓN
PRÁCTICA ............................................................................................................................. 8
1.12.1 ELEMENTO DE NOVEDAD ............................................................................ 8
1.12.2 APORTE TEÓRICO. .......................................................................................... 8
1.12.3 SIGNIFICACIÓN PRÁCTICA .......................................................................... 8
CAPITULO II ............................................................................................................................... 9
2 MARCO TEÓRICO ................................................................................................................... 9
2.1 ANTECEDENTES ..................................................................................................... 9
2.1.1 PROYECTO ............................................................................................................ 9
2.1.2 RECURSOS HUMANOS ....................................................................................... 9
2.2 ARQUITECTURA MODELO VISTA CONTROLADOR ................................. 10
2.2.1 DEFINICIÓN ........................................................................................................ 11
2.2.2 ESTRUCTURA ..................................................................................................... 11
2.2.2.1 MODELO ..................................................................................................... 12
2.2.2.2 PERSISTENCIA ........................................................................................... 13
2.2.2.3 VISTA........................................................................................................... 14
2.2.2.4 CONTROLADOR ........................................................................................ 15
2.3 POSTGRESQL ........................................................................................................ 16
2.3.1 REQUISITOS DE POSTGRESQL ....................................................................... 17
2.4 PYTHON .................................................................................................................. 18
2.5 FRAMEWORK DE DESARROLLO OPENERP ................................................ 19
2.5.1 ARQUITECTURA DE ODOO ............................................................................. 19
2.6 PROCESOS DEL MODULO DE RECURSOS HUMANOS EN
VIRTUALSAMI. ................................................................................................................... 20
2.6.1 MISIÓN ................................................................................................................. 20
2.6.2 VISIÓN ................................................................................................................. 21
2.6.3 PRODUCTOS Y SERVICIOS QUE OFRECE: ................................................... 21
2.6.4 EQUIPO DE TRABAJO ....................................................................................... 21
2.7 PROCESO DE CONVOCATORIA, RECLUTAMIENTO, SELECCIÓN Y
CONTRATACIÓN ............................................................................................................... 23
2.7.1 CONVOCATORIA ............................................................................................... 24
2.7.2 RECLUTAMIENTO ............................................................................................. 25
2.7.3 SELECCIÓN ......................................................................................................... 26
2.7.4 CONTRATACIÓN................................................................................................ 28
2.8 PROCESO DE GENERACIÓN DE NÓMINA .................................................... 29
2.8.1 ROLES DE PAGO ................................................................................................ 30
2.8.2 ASIENTOS CONTABLES DE NÓMINA............................................................ 32
2.9 CONTROL DE ASISTENCIA DE PERSONAL .................................................. 32
2.9.1 ASISTENCIA ........................................................................................................ 32
2.10 DESVINCULACIÓN............................................................................................... 33
2.10.1 LIQUIDACIÓN DE PERSONAL .................................................................... 33
2.10.2 CONTROL DE ACTIVOS FIJOS .................................................................... 34
2.10.3 SALDO EN PRÉSTAMOS............................................................................... 34
2.11 CONCLUSIONES PARCIALES DEL CAPITULO ............................................ 35
CAPITULO III ........................................................................................................................... 36
3 ................................................................................................................................ PROPUESTA
..................................................................................................................................................... 36
3.1 METODOLOGÍA DE DESARROLLO SCRUM ................................................. 36
3.1.1 ARTEFACTOS ..................................................................................................... 37
3.1.1.1 PILA DEL PRODUCTO (PRODUCT BACKLOG) .................................... 37
3.1.1.2 PILA DEL SPRINT (SPRINT BACKLOG) ................................................ 37
3.1.1.3 SPRINT......................................................................................................... 37
3.1.1.4 INCREMENTO ............................................................................................ 38
3.1.1.5 GRÁFICA DE PRODUCTO (BURN UP) ................................................... 39
3.1.1.6 GRáFICa DE AVANCE (BURN DOWN) ................................................... 40
3.1.2 REUNIONES EN SCRUM ................................................................................... 42
3.1.2.1 REUNIÓN DE INICIO DE SPRINT ............................................................ 43
3.1.2.2 REUNIÓN TÉCNICA DIARIA (DAILY SCRUM) .................................... 43
3.1.2.3 REUNIÓN DE CIERRE DE SPRINT Y ENTREGA INCREMENTO ...... 43
3.2 DESARROLLO DE LA PROPUESTA ................................................................. 44
3.2.1 INTRODUCCIÓN ................................................................................................. 44
3.2.1.1 PROPÓSITO DE ESTE DOCUMENTO ..................................................... 44
3.2.1.2 ALCANCE ................................................................................................... 44
3.2.2 DESCRIPCIÓN GENERAL DE LA METODOLOGÍA SCRUM ....................... 45
3.2.2.1 FUNDAMENTACIÓN ................................................................................. 45
3.2.2.2 VALORES DE TRABAJO ........................................................................... 45
3.2.3 PERSONAS Y ROLES DEL PROYECTO .......................................................... 46
3.2.4 ARTEFACTOS ..................................................................................................... 46
3.2.4.1 PILA DE PRODUCTO ................................................................................. 47
3.2.4.2 PILA DEL SPRINT ...................................................................................... 49
3.2.4.3 SPRINT......................................................................................................... 51
3.2.4.4 INCREMENTO ............................................................................................ 51
3.2.4.5 GRÁFICA DE PRODUCTO (BURN up) .................................................... 51
3.2.4.6 GRÁFICA DE AVANCE (BURN DOWN) ................................................. 57
3.2.4.7 REUNIÓN DE INICIO DE SPRINT ............................................................ 60
3.2.4.8 REUNIÓN TÉCNICA DIARIA ................................................................... 61
3.2.4.9 REUNIÓN DE CIERRE DE SPRINT Y ENTREGA INCREMENTO ....... 62
CONCLUSIONES
RECOMENDACIONES
BIBLIOGRAFÍA Y LINOGRAFÍA
ANEXOS
ÍNDICE DE TABLAS
Tabla 1: Límite de PosgresSQL _________________________________________________ 17
Tabla 2: Tipos de Contracción__________________________________________________ 28
Tabla 3: Personas y roles de SCRUM ____________________________________________ 46
Tabla 4: Pila del Producto _____________________________________________________ 48
Tabla 5: Planificación de los Sprints _____________________________________________ 49
ÍNDICE DE GRÁFICOS
Ilustración 1: Diagrama vista controlador ________________________________________ 11
Ilustración 2: Definición ______________________________________________________ 11
Ilustración 3: Modelo Vista Controlador __________________________________________ 12
Ilustración 4: Manejo de la persistencia __________________________________________ 13
Ilustración 5: Vista Controlador ________________________________________________ 15
Ilustración 6: Arquitectura de ODOO ____________________________________________ 19
Ilustración 7: Procesos de Selección _____________________________________________ 23
Ilustración 8: Convocatoria ____________________________________________________ 24
Ilustración 9: Reclutamiento del personal _________________________________________ 25
Ilustración 10: Selección personal _______________________________________________ 26
Ilustración 11: Diagrama de Flujo Nomina________________________________________ 29
Ilustración 12: Rol de pagos de ejemplo __________________________________________ 31
Ilustración 13: Diagrama desvinculación o cese de funciones _________________________ 34
Ilustración 14: Baja con préstamos ______________________________________________ 34
Ilustración 15: Diagrama de la Metodología SCRUM _______________________________ 36
Ilustración 16: Modelo Evolutivo Iterativo ________________________________________ 38
Ilustración 17: Gráfica de Producto _____________________________________________ 39
Ilustración 18: Gráfica de Avance ideal de un Sprint ________________________________ 41
Ilustración 19: Gráfica de Avance Normal de un Sprint ______________________________ 41
Ilustración 20: Gráfica de Avance de un Sprint Subestimado __________________________ 42
Ilustración 21: Gráfica de Avance de un Sprint Sobrestimado _________________________ 42
Ilustración 22: Reuniones en SCRUM ____________________________________________ 43
Ilustración 23: Tablero de Trabajo Sprint 0 _______________________________________ 50
Ilustración 24: Tablero de Trabajo Sprint 1 _______________________________________ 50
Ilustración 25: Tablero de Trabajo Sprint 2 _______________________________________ 50
Ilustración 26: Tablero de Trabajo Sprint 3 _______________________________________ 51
Ilustración 27: Avance Sprint 0 _________________________________________________ 53
Ilustración 28: Gráfica de Seguimiento Sprint 0 ____________________________________ 53
Ilustración 29: Avance Sprint 1 _________________________________________________ 54
Ilustración 30: Grafica de Seguimiento Sprint 1 ____________________________________ 54
Ilustración 31: Avance Sprint 2 _________________________________________________ 55
Ilustración 32: Gráfica de Seguimiento Sprint 2 ____________________________________ 55
Ilustración 33: Avance Sprint 3 _________________________________________________ 56
Ilustración 34: Gráfica de Seguimiento Sprint 3 ____________________________________ 56
Ilustración 35: Alcance, Tipo de Trabajo: Codificación Sprint 0 _______________________ 57
Ilustración 36: Reporte Resumen Sprint 0 _________________________________________ 58
Ilustración 37: Alcance, Tipo de Trabajo: Codificación Sprint 1 _______________________ 58
Ilustración 38: Reporte Resumen Sprint 1 _________________________________________ 58
Ilustración 39: Alcance, Tipo de Trabajo: Codificación Sprint 2 _______________________ 59
Ilustración 40: Reporte Resumen Sprint 2 _________________________________________ 59
Ilustración 41: Alcance, Tipo de Trabajo: Codificación Sprint 3 _______________________ 60
Ilustración 42: Reporte Resumen Sprint 3 _________________________________________ 60
RESUMEN EJECUTIVO
El cuerpo del informe está organizado en introducción, tres capítulos, conclusiones,
recomendaciones, bibliografía y anexos.
En la introducción se analiza los antecedentes que fundamentan la pertinencia de la
investigación, el planteamiento del problema científico, la idea a defender, el objetivo
general, objetivos específicos, los métodos empleados en la recolección y análisis de los
datos, así como la novedad científica del Proyecto de Investigación.
En el Capítulo l, se analiza el marco teórico, en este se aborda la justificación del tema de
investigación, la parte conceptual sobre el módulo de recursos humanos de la empresa
VIRTUALSAMI CIA. LTDA, así como los procesos de este departamento.
En el Capítulo II, se realiza la metodología de trabajo, que consta de objetivos, etapa de
inicio del proyecto, flujo de trabajo y reportes.
En el Capítulo III, se presenta la propuesta de IMPLEMENTACIÓN DEL MÓDULO DE
RECURSOS HUMANOS AL SISTEMA DE PLANIFICACIÓN DE RECURSOS
EMPRESARIALES ODOO VERSIÓN 8.0 PARA LA EMPRESA VIRTUALSAMI
CLA. LTDA.
Finalmente se expone las conclusiones y recomendaciones generales de la investigación,
anexos, así como también las fuentes bibliográficas que han servido para el desarrollo del
presente Proyecto de Investigación.
La bibliografía es amplia, actualizada y pertinente con el tema de investigación. El aporte
del trabajo de investigación es de naturaleza teórica y práctica aplicable en la Empresa
VIRTUALSAMI CIA LTDA.
ABSTRACT
This research is based on the introduction, chapter I, chapter II, chapter III, conclusions,
recommendations, bibliography and annexes.
In the introduction, it is analyzed the records that support the development of the current
research. It is also mentioned the approach of the problem, the thesis statements to
support, the general and specific objectives, the methodology and techniques used to carry
on this research and the analysis on the data. Furthermore, scientific news and evidences
were revealed.
In chapter I, it was analyzed the theoretical framework as well as the justification for
research which mainly gives strong data to develop this work. Moreover, it is shown
theoretical descriptions of the proposal to be deployed at the company “VIRTUALSAMI
CIA. LTDA”. Given that it is also stated the processes developed in mentioned enterprise
in order to propose a module for the human resources department.
In chapter II, IT is determined the methodology used in this research. It is also presented
the beginning stage of the proposal, objectives, workflow analysis and reports.
Chapter III basically presents the proposal whose name is “Deployment of a human
resources’ module to the planning system at business resources with ODOO 8.0 in the
company VIRTUALSAMI CIA. LTDA”.
Finally, conclusions, recommendations annexes, and bibliographical sources used within
this research are presented.
1
CAPÍTULO I
INTRODUCCIÓN
1.1 ANTECEDENTES DE LA INVESTIGACIÓN
La Gestión del Talento Humano ha venido avanzando en la misma medida en que lo ha
hecho el conocimiento y las nuevas tecnologías de la información, inmersas en el actual
proceso globalizador del aparato económico mundial. Desde este contexto, la actividad
que conlleva la Gestión de los Recursos Humanos, se encuentra enmarcada en un esfuerzo
colectivo con el único propósito de lograr agenciar objetivos estratégicos tales como:
confianza, compromiso, creatividad inventiva y solidaridad en pocas palabras lo
intangible del Talento Humano.
La Gestión del Talento Humano supone en su contexto evolutivo la aplicación de
Modelos Gerenciales que mejoren su efectividad en el logro de los objetivos. Por ello,
hoy por hoy la Gerencia de Talento Humanos enfrenta diversos desafíos en el logro y
seguimiento de los objetivos organizacionales, estos pueden resumirse en la búsqueda
permanente de la consecución de objetivos propios de la organización, en el equilibro que
debe existir entre el contexto social interno y externo en el cual se desarrollan.
En general, es destacable que la Gerencia como acción practica proponga programas,
prácticas, procesos y modelos gerenciales para los distintos subsistemas que conforman
las organizaciones, a fin de desarrollar en los Recursos Humanos que integran las
empresas las características que propicien mejores resultados y mayor rapidez al dar
respuestas requeridas para el buen funcionamiento de la organización.
Para el logro de estas actividades, el seguimiento por parte de las organizaciones debe
estar enmarcado en la Gerencia de Recurso Humanos como una pieza esencial para que
esta inversión tenga alcances materiales, económicos y sociales.
2
Significa entonces, que al crear estos dispositivos para el área gerencial y entrelazarlos
con la estrategia empresarial, se concreta la creación de una unidad de Recursos Humanos
que haga énfasis para que sus actores se transformen en los principales activos de la
organización y sean a su vez en la medida, los que aporten con sus competencias el logro
de la misión, visión y metas organizacionales del pensamiento futuro en un mundo
globalizado y competitivo.
1.2 PLANTEAMIENTO DEL PROBLEMA
VIRTUALSAMI CIA. LTDA. Actualmente los procesos de recursos humanos los realiza
de la siguiente manera:
Convocatoria, reclutamiento, selección y contratación: Se convoca mediante redes
sociales y medios de control como la página de socio empleo del Ministerio de Trabajo,
las hojas de vida se las recibe en el correo electrónico de la institución al igual que de
forma física, las evaluaciones en hojas impresas, entrevistas y la tabulación se la realiza
en hojas de cálculo. El contrato lo realiza en un procesador de texto basadas en las
plantillas que provee el Ministerio de Trabajo.
Nómina: Los procesos de nómina se realizan mediante hojas de cálculo, se generan los
roles de pago y los asientos contables en forma manual en el Sistema Informático de la
empresa.
Asistencia: La asistencia se controla mediante firmas en hojas de control y la tabulación
se las realiza mediante hojas de cálculo.
Desvinculación: Los procesos de liquidación del personal que finaliza la relación laboral
por cualquier motivo se realiza de forma manual en hojas de cálculo en las cuales se
generan los valores para el finiquito.
Se requiere una solución que implemente:
3
Reclutamiento, selección y contratación: Se convoca mediante redes sociales, los
candidatos deberán registrarse en la plataforma web (Sistema Informático), el Jefe de
Recursos Humanos ingresa la evaluación y entrevista en el sistema, con horarios de
apertura y cierre. La tabulación y el contrato los deberán generar automáticamente.
Nómina: Los roles de pago y asientos contables se deberán generar de forma automática,
estos roles de pago se enviarán al correo electrónico de cada empleado.
Asistencia: La asistencia se controlará mediante Relojes Biométricos y la información
deberá transmitirse online al sistema informático.
Desvinculación: Los valores por concepto de finiquito se deberán generar de forma
automática en el sistema informático.
1.3 FORMULACIÓN DEL PROBLEMA
¿Cómo mejorar los procesos de Gestión de Recursos Humanos, selección, contratación,
manejo de nómina, asistencia, etc. mediante un sistema informático en la Empresa
VIRTUALSAMI CIA. LTDA.?
1.4 DELIMITACIÓN DEL PROBLEMA
El trabajo de investigación será realizado en la empresa VIRTUALSAMI CIA. LTDA.,
la misma que será parte indispensable en nuestro objeto de estudio y está ubicada en la
provincia de Imbabura, Cantón Ibarra, en las calles Carlos Elías Almeida 7-29 y Gabriela
Mistral.
1.5 OBJETIVOS DE INVESTIGACIÓN Y CAMPO DE ACCIÓN
1.5.1 OBJETIVO DE INVESTIGACIÓN
Sistema de Información
4
1.5.2 CAMPO DE ACCIÓN
Módulo de Recursos Humanos
1.6 IDENTIFICACIÓN DE LA LÍNEA DE INVESTIGACIÓN
Desarrollo de Software Libre
1.7 OBJETIVOS
1.7.1 GENERAL
Implementar el módulo de Gestión de Recursos Humanos al Sistema de
Planificación de Recursos Empresariales ODOO versión 8.0 en la empresa
VIRTUALSAMI CIA. LTDA.
1.7.2 ESPECÍFICOS
Estudiar los procesos actuales dentro del Departamento de Recursos Humanos de
la empresa VIRTUALSAMI CIA. LTDA.
Fundamentar teóricamente y bibliográficamente los procesos de Gestión de
Recursos Humanos dentro de la empresa.
Desarrollar dentro del módulo de Recursos Humanos de ODOO los procesos de
reclutamiento, evaluación, asistencia, contratos y gastos de sus empleados; y que
su vez sirva como plantilla para futuras ejecuciones por parte de VIRTUALSAMI
CIA. LTDA. en sus clientes.
Validar la propuesta.
Liberar en el sistema de versionamiento GitHub la solución desarrollada.
5
1.8 IDEA A DEFENDER
Mejorará los procesos de selección, contratación, gestión, manejo de nómina y asistencia
en la empresa VIRTUALSAMI CIA LTDA a través del módulo de Gestión de Recursos
Humanos.
1.9 JUSTIFICACIÓN DE LA NECESIDAD, ACTUALIDAD IMPORTANCIA
En el 2008 Virtual SAMI abre sus puertas como una empresa de consultoría, diseño de
software e investigación que pretende responder a la necesidad de nuevos mecanismos,
más seguros, confiables y económicos, que permitan implementar nuevas tecnologías
para las crecientes necesidades en el ámbito de la investigación y educación y de la vida
cotidiana en un marco más extenso.
En el 2012 por decisión de los dueños Virtual SAMI pasa a convertirse en lo que es hoy
VIRTUALSAMI CIA. LTDA. Una empresa con personería jurídica y con un mercado
ganado a base de sacrificio entregando productos de gran calidad y con un alto nivel de
soporte técnico.
Los Sistemas de Información han jugado un rol cada vez más visible en la mejora de la
competitividad de los negocios a lo largo de los últimos años. No son sólo herramientas
para manejar tareas repetitivas, sino que se están usando para guiar y promover todas las
actividades diarias de una compañía. Un software de gestión integrada es un recurso clave
que otorga una ventaja competitiva significativa.
La respuesta habitual de una empresa a las necesidades de agilidad, fiabilidad y respuesta
a expectativas que crecen rápidamente es crear una organización basada en
departamentos, con una estructura lineal integrada alrededor de sus procesos operativos.
Para aumentar la eficiencia entre la gente de ventas, los contadores, el personal de
logística y todos los demás, la empresa debería tener un entendimiento común de sus
problemas.
6
Para esto se necesita un lenguaje común que permita compartir las referencias, las
políticas y la comunicación en la organización. Un sistema ERP (por Enterprise Resource
Planning, Planificación de Recursos Empresariales) constituye la plataforma ideal para
este punto de referencia común.
1.10 METODOLOGÍA DE LA INVESTIGACIÓN CIENTÍFICA
Modalidad:
o Cuali - Cuantitativo. Que permitirá analizar la incidencia en el módulo de
Gestión de Recursos Humanos, para mejor los procesos dentro de la
empresa.
Tipo de Investigación:
o Por su diseño:
Descriptiva. Para precisar todo lo referente a la problemática
planteada y su alcance correlacional de la investigación a la gestión
de recursos humanos.
Métodos:
o Inducción-deducción. Para el análisis de la información proporcionada por
las técnicas de la encuesta y entrevista.
1.11 RESUMEN DE LA ESTRUCTURA DEL PROYECTO
Procesos de Gestión de Recursos Humanos, el cambio organizacional se describe como
“cambio profundo” que combina modificaciones internas de los valores de la gente, sus
aspirantes y conductas, con “variables externas” en procesos, estrategias, prácticas y
sistemas.
ODOO (Antes OpenERP), es una suite moderna de Aplicaciones de Negocios, publicada
bajo la licencia AGPL, y con CRM, RRHH, Ventas, Contabilidad, Producción, Gestión
de Almacenes, Gestión de Proyectos, y más.
7
Se basa en un desarrollo rápido de aplicaciones modular, escalable e intuitiva (RAD)
Marco de Trabajo escrito en Python.
ODOO cuenta con una caja de herramientas completa y modular para la construcción
rápida de aplicaciones: Mapeo de Objeto Relacional (ORM), una generación de informes,
interfaces y plantillas basada en el Modelo-Vista-Controlador (MVC) sistema, la
internacionalización automatizada, y mucho más.
Python, es un lenguaje de programación dinámico de alto nivel, ideal para RAD,
combinando el poder con una sintaxis clara.
PostgreSQL, el motor de base de datos de ODOO es un potente desarrollo libre dirigido
por una comunidad de desarrolladores y organizaciones comerciales.
Mako, es una biblioteca de plantillas escrito en Python. Proporciona una sintaxis familiar,
no XML que compila en módulos de Python para el máximo rendimiento. Sintaxis y la
API de Mako toma prestado de las mejores ideas de muchos otros, incluyendo Django y
plantillas Jinja2, Guepardo, Poderoso, y Genshi. Conceptualmente, Mako es un Python
incrustado (es decir Python Server Page) el lenguaje, que refina las ideas familiares de
diseño en componentes y la herencia para producir uno de los modelos más sencillos y
flexibles disponibles, manteniendo al mismo tiempo estrechos vínculos con Python
llamada y de alcance semántica.
Nginx, (pronunciado en inglés “engine X”) es un servidor web/proxy inverso ligero de
alto rendimiento y un proxy para protocolos de correo electrónico (IMAP/POP3).
Es software libre y de código abierto, licenciado bajo la Licencia BSD simplificada. Es
multiplataforma, por lo que corre en sistemas tipo (Unix GNU/Linux, BSD, Solaris, Mac
OS X, etc.) y Windows.
8
1.12 ELEMENTOS DE NOVEDAD, APORTE TEÓRICO Y SIGNIFICACIÓN
PRÁCTICA
1.12.1 ELEMENTO DE NOVEDAD
Los procesos de convocatoria, reclutamiento, selección, contratación, nómina, asistencia
y desvinculación que se lleva a cabo en la empresa se administra de forma manual al
igual que sus documentos, nuestra propuesta se encamina en ofrecer módulo integrado de
Recursos Humanos para automatizar todos los procesos y ofrecer una información segura
y confiable.
1.12.2 APORTE TEÓRICO.
La fundamentación teórica de herramientas y metodologías de desarrollo de software
permitirá actualizar el conocimiento y aplicarlos a la implementación de sistemas de
información seguros, robustos y escalables.
1.12.3 SIGNIFICACIÓN PRÁCTICA
Radica en la implementación del módulo de recursos humanos en el sistema ODDO
versión 8.0, consiguiendo con esto la agilidad en estos procesos convocatorios,
reclutamiento, selección, contratación, nomina, asistencia y desvinculación.
9
CAPITULO II
MARCO TEÓRICO
1.13 ANTECEDENTES
(Alles, 2013) “Implica un deseo de ayudar o servir a los clientes, de comprender y
satisfacer sus necesidades, aún aquellas no expresadas. Implica esforzarse por conocer
y resolver los problemas del cliente, tanto del cliente final a quien van dirigidos los
esfuerzos de la empresa como los clientes de los propios clientes y todos aquellos que
cooperen en la relación empresa-cliente, como el personal ajeno a la organización”.
1.13.1 PROYECTO
Este Proyecto puede ser considerado como un conjunto de tareas y actividades que:
Tiene un objetivo específico que debe ser cumplido dentro de ciertas
especificaciones
Tiene fechas definidas de inicio y fin
Posee recursos económicos limitados (Si el mismo aplica)
Consume recursos humanos y no humanos
Son multifuncionales
1.13.2 RECURSOS HUMANOS
En la etapa actual de desarrollo de la humanidad, el campo de la dirección, las
organizaciones se ven sometidas a retos, desafíos y presiones a los cuales tienen que
responder con alto grado de creatividad y realismo a las empresas en nuestro caso
VIRTUALSAMI CIA. LTDA., los principales retos están dados por la dinámica de la
aplicación de los logros científico-técnicos, la rápida aparición y aceptación de nuevos
productos, cada vez mayores restricciones de Recursos Humanos (RH).
10
(Izquierdo, 2012) materiales y financieros, mercados más agresivos y dinámicos en el
ámbito internacional, pero el crecimiento de las demandas sociales y la revolución de la
informática y las comunicaciones. En este proceso seleccionamos a una persona o un
grupo de personas con actitudes específicas para cumplir funciones específicas dentro de
una determinada empresa.
(Izquierdo, 2012) “En la administración de empresas, se denomina recursos humanos
(RR. HH.) al trabajo que aporta el conjunto de los empleados o colaboradores de una
organización.” Pero lo más frecuente es llamar así al sistema o proceso de gestión que
se ocupa de seleccionar, contratar, formar, emplear y retener al personal de la
organización”
Dentro de este proceso se tendría en cuenta las diferentes fases como son:
Convocatoria
Reclutamiento
Selección
Contracción
Nómina
Asistencia
Desvinculación
1.14 ARQUITECTURA MODELO VISTA CONTROLADOR
La arquitectura MVC (Modelo Vista Controlador) fue introducida como parte de la
versión Smalltalk-8032 del lenguaje de programación Smalltalk en 1979 por Tryge
Reenskaug en los laboratorios de investigación de Xerox. Fue diseñada para reducir el
esfuerzo de programación necesario en la implementación de sistemas múltiples y
sincronizados de los mismos datos. Sus características principales son que el Modelo, las
Vistas y los Controladores se tratan como entidades separadas; esto se hace que cualquier
cambio producido en el Modelo se refleje automáticamente en cada una de las Vistas.
11
En la ilustración número siguiente, vemos la arquitectura MVC en su forma más general.
Hay un Modelo, múltiples Controladores que manipulan ese Modelo, y hay varias Vistas
de los datos del Modelo, que cambian cuando cambia el estado de ese Modelo.
Ilustración 1: Diagrama vista controlador
Fuente: Propia
1.14.1 DEFINICIÓN
A continuación se muestra en la ilustración siguiente la relación existente entre el modelo,
la vista y el controlador en donde las líneas solidas indican una asociación directa, y las
punteadas una indirecta.
Ilustración 2: Definición
Fuente: Propia
La idea fundamental de MVC es construir una aplicación separando de forma clara las
capas de Modelo (Datos), Vista (Presentación) y Controlador (Funciones, métodos…)
para reducir el acoplamiento entre la lógica de negocio y la presentación.
1.14.2 ESTRUCTURA
El Modelo Vista Controlador es un patrón estructural usado en la ingeniería de software,
donde se tiene datos separados (modelo), una interfaz de usuario y un componente
intermedio que interactúa con los dos que es el controlador.
12
Ilustración 3: Modelo Vista Controlador
Fuente: Propia
1.14.2.1 MODELO
ORM (MAPEO OBJETO – RELACIONAL)
Es el componente clave de ODOO, el ORM es una capa completa de Mapeo Objeto
Relacional, liberando a los desarrolladores de tener que escribir la plomería básica SQL.
Los Objetos de Negocios se declaran como clases de Python que heredan de la clase
model.Model, lo que hace que mágicamente persistieron por la capa ORM.
La interacción con los modelos y los registros se realiza a través de registros, un conjunto
ordenado de los registros de un mismo modelo.
PostgreSQL, el motor de base de datos de ODOO es un potente desarrollo libre dirigido
por una comunidad de desarrolladores y organizaciones comerciales.
13
1.14.2.2 PERSISTENCIA
Acción de preservar la información de un objeto de forma permanente (guardar), pero a
su vez también se refiere a poder recuperar la información del mismo (leer) para que
pueda ser nuevamente utilizada.
La persistencia permite al programador almacenar, transferir y recuperar el estado de los
objetos. Para esto tenemos las siguientes técnicas:
Serialización: Es el proceso de codificación de un objeto en un medio de
almacenamiento (archivo o buffer de memoria).
Motor de persistencia: Traduce entre los dos formatos de datos de registros a
objetos y de objetos a registros.
Ilustración 4: Manejo de la persistencia
Fuente: (Palasí Lallana, 2015)
La situación se ejemplifica en la ilustración anterior, cuando el programa quiere grabar
un objeto llama al motor de persistencia que traduce el objeto a registros y llama a la base
de datos para que guarde estos registros.
14
1.14.2.3 VISTA
Es el objeto que maneja la presentación visual Interfaz Gráfica de Usuario de los datos
representados por el Modelo. Genera una representación visual del Modelo y muestra los
datos al usuario. Interactúa con el Modelo a través de una referencia al propio Modelo.
QWEB es el principal motor de plantillas utilizado por OpenERP 2. Se trata de un motor
de plantillas XML1 y utiliza sobre todo para generar fragmentos de HTML y páginas.
Las vistas son responsables de:
Recibir datos del modelo y la muestra al usuario.
Tener un registro de su controlador asociado (normalmente porque además lo
instancia).
Pueden dar el servicio de “Actualización()”, para que sea invocado por el
controlador o por el modelo (cuando es un modelo activo que informa de los
cambios en los datos producidos por otros agentes) .
La capa de la vista también puede aprovechar la separación de código. Las páginas web
suelen contener elementos que se muestran de forma idéntica a lo largo de toda la
aplicación: cabeceras de las páginas, pie de página y su navegación global. Normalmente
solo se cambia el interior de la página.
Muchas interfaces gráficas de usuario, como Swing o MFC, hacen innecesario el uso de
un controlador ya que definen su propio flujo de control y manejan los eventos
internamente; integran así la vista y el controlador. A esta variante se la suele denominar
Document – View.
1 Es similar en que a Genshi (es una biblioteca de Python que proporciona un conjunto integrado de
componentes para el análisis, generación y procesamiento de HTML, XML u otro contenido textual para
la generación de la salida en la web), aunque no utiliza (y no tiene soporte para) espacios de nombres XML
15
1.14.2.4 CONTROLADOR
Es el objeto que proporciona significado a las órdenes del usuario, actuando sobre los
datos representados por el Modelo. Cuando se realiza algún cambio, entra en acción, bien
sea por cambios en la información del Modelo o por alteraciones de la Vista. Interactúa
con el Modelo a través de una referencia al propio Modelo.
La unión entre la capa de presentación y capa de negocio conocido como el paradigma de
la Programación por capas representaría la integración entre Vista y su correspondiente
Controlador de eventos y acceso a datos. El flujo que sigue el control es el siguiente como
se muestra la siguiente ilustración:
Ilustración 5: Vista Controlador
Fuente: (TuFuncion, 2008)
a) El usuario con la interfaz de usuario interactúa de alguna forma (el usuario pulsa
un botón, enlace, etc.)
b) El controlador recibe (por parte de la interfaz – vista) la notificación de la acción
solicitada por el usuario. El controlador gestiona el evento que llega,
frecuentemente a través de un gestor de eventos (handler) o callback
c) El controlador accede al modelo, actualizándolo, posiblemente modificándolo de
forma adecuada a la acción solicitada por el usuario (por ejemplo, el controlador
actualiza el carrito de compra del usuario). Los controladores complejos están a
menudo estructurados en un patrón de comando que encapsula las acciones y
simplifica su extensión.
16
d) El controlador delega a los objetos de la vista la tarea de desplegar la interfaz de
usuario. La vista obtiene sus datos del modelo para generar la interfaz apropiada
para el usuario donde se reflejan los cambios en el modelo (por ejemplo, produce
un listado del contenido del carrito de compra).
El modelo no debe tener conocimiento directo sobre la vista. Sin embargo, el
patrón de observador puede ser utilizado para proveer cierta dirección entre el
modelo y la vista, permitiendo al modelo notificar a los interesados de cualquier
cambio. Un objeto vista puede registrarse con el modelo y esperar a los cambios,
pero aun así el modelo en sí mismo sigue sin saber nada de la vista. El controlador
no pasa objetos de dominio (el modelo) a la vista aunque puede dar la orden a la
vista para que se actualice.
Nota: En algunas implementaciones la vista no tiene acceso directo al modelo,
dejando que el controlador envíe los datos del modelo a la vista.
e) La interfaz de usuario espera nuevas interacciones del usuario, comenzando el
ciclo nuevamente.
1.15 POSTGRESQL
PostgreSQL es un sistema de gestión de base de datos relacional orientada a objetos y
libre, publicado bajo la licencia BSD. Es el gestor de base de datos de código abierto más
potente del mercado y las últimas versiones no tienen nada que envidiar a las bases de
datos comerciales.
(Izquierdo, 2012) PostgreSQL utiliza un modelo cliente/servidor y usa multiprocesos en
vez de multihilos para garantizar la estabilidad del sistema. Un fallo en uno de los
procesos no afectará el resto y el sistema continuará funcionando.
Entre las características más importantes que soporta PostgreSQL están: que es una base
de datos 100% ACID (Atomicidad, Consistencia, Integridad, Durabilidad), permite
realizar replicación asincrónica/sincrónica, copias de seguridad en caliente, posee juegos
17
de caracteres internacionales, control de concurrencia (MVCC) en la mayoría de casos no
requiere bloqueos, múltiples métodos de autentificación, acceso encriptado vía SSL,
documentación completa, licencia BSD, permite programar procedimientos almacenados
en numerosos lenguajes de programación, maneja eventos (triggers), tiene APIs para
programar en C/C++, Java, .Net, Perl, Python, Ruby, Tcl, ODBC, PHP, Lisp, Scheme,
Qt; y está disponible para Linux y UNIX en todas sus variantes, y Windows. Los límites
de PostgreSQL se describen en la siguiente tabla:
Tabla 1: Límite de PosgresSQL
Limite Valor
Máximo Tamaño de base de datos No hay límite.
Máximo tamaño de tabla 32 TB.
Máximo tamaño de fila 1.6 TB.
Máximo tamaño de columna 1 GB.
Número de filas por tablas Determinado por el tamaño de la fila.
Número de columnas por tabla 250 – 1600.
Número de índices por tabla No hay límite.
Fuente: Propia
1.15.1 REQUISITOS DE POSTGRESQL
En realidad PostgreSQL no tiene requerimientos específicos de hardware. Se considera
suficiente con satisfacer los requerimientos recomendados para instalar el sistema
operativo que se vaya a utilizar.
Los mínimos requerimientos para el sistema operativo, no garantizan precisamente una
mayor rapidez por parte de PostgreSQL, por lo tanto si se necesita mayor rapidez y/o
mayor almacenamiento de datos, es necesario mejorar el hardware.
18
1.16 PYTHON
Python es un lenguaje de programación flexible y muy potente que permite el desarrollo
de aplicaciones web como es el caso de ODOO. No necesita un compilador para
ejecutarlo ya que es interpretado y orientado a objetos.
Es necesario utilizar la versión 2.7.9 de Python para ODOO, las versiones anteriores no
son recomendables y las versiones 3.x no son compatibles con ODOO.
Un módulo de ODOO es también un paquete de Python con un archivo __init__.py, que
contiene instrucciones de importación para diversos archivos de Python en el módulo.
El uso de Pylint2 puede ayudar a mostrar la sintaxis y semántica, advertencias o errores.
El código fuente de OpenERP trata de respetar el estándar de Python, pero pueden ser
ignorados los siguientes:
E501: line too long (Demasiadas líneas de código)
E301: expected 1 blank line, found 0 (Se esperaba 1 línea en blanco, se encontró
0)
E302: expected 2 blank lines, found 1 (Se esperaba 2 líneas en blanco, se encontró
1)
E126: continuation line over-indented for hanging indent (continuación de línea
de sangría en off para pasar tabulación)
E123: closing bracket does not match indentation of opening bracket's line
(corchete de cierre no coincide con la sangría de la apertura de la línea corchetes)
E127: continuation line over-indented for visual indent (continuación de línea de
sangría en off para la tabulación visual)
2 Pylint es una herramienta que comprueba los errores en el código Python, trata de hacer cumplir un
estándar de codificación y observa los “back code smells” (Es cualquier síntoma en el código fuente de un
programa que posiblemente indica un problema más profundo). El estilo de codificación predeterminada
utilizada por Pylint está cerca de PEP 008 (también conocido como libro de estilo de Guido’s).
19
E128: continuation line under-indented for visual indent (línea de continuación de
baja de sangría para la tabulación visual)
E265: block comment should start with '# ' (comentario de bloque debe empezar
con '#')
1.17 FRAMEWORK DE DESARROLLO OPENERP
1.17.1 ARQUITECTURA DE ODOO
Ilustración 6: Arquitectura de ODOO
Fuente: Documento Técnico Memento de ODOO
ODOO es un Sistema de Planificación de Recursos Empresariales, Software Libre que
permite la integración de todos los módulos, posibilita la toma de decisiones de forma
más rápida y segura, reduce los costos de implementación y automatiza los procesos.
ODOO utiliza el paradigma cliente-servidor muy conocido: el cliente se ejecuta como
una aplicación de Javascript en su navegador, la conexión con el servidor se la realiza
mediante el Protocolo JSON-RPC a través de HTTP(S). Clientes Ad-hoc también pueden
ser fácilmente escritos y conectarse al servidor utilizando XML-RPC o JSON-RPC.
20
Multiplataforma.- La interfaz web de ODOO le permite acceder desde cualquier
ordenador independientemente del sistema operativo (GNU/Linux, Mac OS X o
Windows), e incluso tablets y smartphones con Android o iOS. La versión “mobile”
simplifica las vistas y lo hace más agradable y sencillo de manejar desde pantallas de
tamaño reducido.
1.18 PROCESOS DEL MODULO DE RECURSOS HUMANOS EN
VIRTUALSAMI.
(VirtualSAMI Cia. Ltda., 2016)“En el 2008 Virtual SAMI abre sus puertas como una
empresa de consultoría, diseño de software e investigación que pretende responder a la
necesidad de nuevos mecanismos, más seguros, confiables y económicos, que permitan
implementar nuevas tecnologías para las crecientes necesidades en el ámbito de la
investigación y educación y de la vida cotidiana en un marco más extenso”.
(VirtualSAMI Cia. Ltda., 2016)“En el 2012 por decisión de los dueños Virtual SAMI pasa
a convertirse en lo que es hoy VIRTUALSAMI CIA. LTDA. Una empresa con personería
jurídica y con un mercado ganado a base de sacrificio y de entregar productos de gran
calidad y con un alto nivel de soporte técnico”.
1.18.1 MISIÓN
(VirtualSAMI Cia. Ltda., 2016) “Somos una empresa imbabureña que hace de las
necesidades sociales y empresariales, soluciones tecnológicas que contribuyan con la
evolución de la humanidad a través del software libre y del desarrollo, aplicando a las
necesidades específicas de cada empresa o persona ofreciéndole soluciones integrales
con la finalidad de fabricar o desarrollar software de fácil uso, que tenga sobresalientes
niveles de rentabilidad, calidad, presencia e influencia en el mercado laboral”.
21
1.18.2 VISIÓN
(VirtualSAMI Cia. Ltda., 2016)“Seremos en el 2018 una empresa icono del norte del
país, una empresa de reconocido prestigio nacional por su excelencia en la fabricación
y desarrollo de software, fomentando el empoderamiento del software libre, ser un sello
de calidad el entorno informático y que brinde un producto y servició de excelente
calidad donde el mejoramiento continuo en todas las áreas sean de agrado de nuestros
clientes”.
1.18.3 PRODUCTOS Y SERVICIOS QUE OFRECE:
Consultorías en Tecnología, Contabilidad y Avalúos y Catastros
Sistema de Automatizado de Gestión y Control de Estacionamiento Rotativo y
Tarifado VIRTUALSAGA
Sistema de Administración Deportiva VIRTUALSPORT
Implementaciones de ODOO (Antes OpenERP)
Implementaciones de Comprobantes Electrónicos Integrado con Sistemas de
Terceros
1.18.4 EQUIPO DE TRABAJO
Amanda Silvana Mafla Ibujés, Tecnóloga Analista de Sistemas de la Universidad
Regional Autónoma de los Andes “UNIANDES”, con más de diez años de
experiencia, ha trabajado en varias empresas del sector público y privado, fue Jefa
de Sistemas de la Empresa de Agua Potable y Alcantarillado de Espejo, forma
parte de las comunidades de Software Libre: Asociación de Software Libre del
Ecuador ASLE, PostgreSQL User Group Ecuador y ODOO-Ecuador, actualmente
se desempeña como Gerente General de VIRTUALSAMI CIA. LTDA.
22
Alcides Neptalí Rivera Posso, Ingeniero en Sistemas Computacionales de la
Universidad Técnica del Norte con más de diez años de experiencia se ha
desempeñado como Docente en la Facultad de Ingeniería en Ciencias Aplicadas
de la Universidad Técnica del Norte y de la Carrera de Tecnología en Análisis de
Sistemas del Instituto Tecnológico Superior “Liceo Aduanero” ha trabajado en
varias empresas del sector público y privado en el Área de Desarrollo de Software,
posee una Certificación Internacional en “PostgreSQL Database Administración”
otorgado por 2nd Quadrant Professional PostgreSQL, Oxford OX4 2JZ, Reino
Unido, forma parte de las comunidades de Software Libre: Asociación de
Software Libre del Ecuador ASLE, PostgreSQL User Group Ecuador y ODOO-
Ecuador, actualmente se desempeña como Presidente Ejecutivo de
VIRTUALSAMI CIA. LTDA.
Juan Carlos López Jácome, Ingeniero en Sistemas Computacionales de la
Universidad Técnica del Norte, con más de cinco años de experiencia, ha
trabajado en varias empresas del sector público y privado, actualmente se
desempeña como Programador Senior en VIRTUALSAMI CIA. LTDA.
Diego Alfonso Acosta Bastidas Doctor en Ciencias Jurídicas y Sociales, con más
de 20 años de experiencia se ha desempeñado como Secretario Abogado Externo
de Coactivas en la Corporación Nacional de Telecomunicaciones CNT – EP,
Secretario Jurídico de la Asociación de Software Libre del Ecuador, Asesoría
Jurídica en marcas, registros sanitarios extranjería y negocios, con especialidad
en procesos de negociación comercial internacional y en desarrollo de proyectos
productivos de PYMES y microempresas, actualmente se desempeña como
Asesor Jurídico de VIRTUALSAMI CIA. LTDA.
Lucía Verónica Ruiz González, Ingeniera en Contabilidad y Auditoría de la
Universidad Técnica del Norte, con más de diez años de experiencia, ha trabajado
en varias empresas del sector público y privado, fue Tesorera General del
Gobierno Autónomo Descentralizado Municipal de Antonio Ante, actualmente se
desempeña como Contadora de VIRTUALSAMI CIA. LTDA.
23
Jannine Maribel Cadena Necpas, Tecnóloga en Sistemas del Instituto Tecnológico
Superior “Ibarra” ITSI, con más de tres años de experiencia, actualmente se
desempeña como Programador Junior en VIRTUALSAMI CIA. LTDA.
Carlos Beno Buele Vásquez, Egresado de la Carrera de Ingeniería en
Agronegocios Avalúos y Catastros de la Universidad Técnica del Norte con más
de 2 años de experiencia en el campo profesional, ha sido parte de equipos de
trabajo de estudios en Generación Cartográfica y/o Topografía, actualmente se
desempeña como Experto en Avalúos y Catastros en VIRTUALSAMI CIA.
LTDA.
La Empresa VIRTUALSAMI CIA. LTDA., se encontraba con múltiples aplicaciones
conectadas, vinculadas o sin conectar, por lo cual se volvió complicado tener un control
total de sus proyectos, al tener varias fases con diferentes herramientas y recursos
humanos en diferentes localizaciones del país. Con la implementación de la herramienta
OPENERP en VIRTUALSAMI CIA. LTDA., podemos tener una única aplicación,
logrando una automatización y centralización de todas sus tareas dentro de los proyectos.
1.19 PROCESO DE CONVOCATORIA, RECLUTAMIENTO, SELECCIÓN Y
CONTRATACIÓN
Ilustración 7: Procesos de Selección
Fuente: Propia
24
Los procesos de Convocatoria, Reclutamiento, Selección y Contratación, se desglosarán
en el presente documento de acuerdo a los métodos manuales que se los viene realizando
en la empresa específicamente en el departamento de Talento Humano, falencia, errores
propios de este método.
1.19.1 CONVOCATORIA
Ilustración 8: Convocatoria
Fuente: Propia
(Belen Ana Ventura Susana Delgado, 2013) Una recomendación adicional es aprovechar
la inversión en publicidad durante el reclutamiento para posicionar a la empresa como
una institución seria. Los anuncios que indica “empresa seria solicita personal” suelen
ser sospechosas para quienes buscan personal y para el público en general.
Como primer paso dentro de la convocatoria se deberían responder las siguientes
interrogantes:
¿Qué actividades deberá realizar?
¿Necesita experiencia?
¿Qué habilidades?
¿Qué conocimientos técnicos?
¿Valores?
¿Capacidad de trabajo en equipo? ¿Trabajo bajo presión?
¿Nivel de estudio?
¿Tendrá contacto con extranjeros? (Por el tema de multilenguaje).
Principales actividades, responsabilidades, etc
25
Una vez analizado el o los requerimientos se procede al segundo paso que es la
publicación del reclutamiento, utilizando diferentes opciones como: anuncios o avisos,
recomendaciones, agencias de empleo, la competencia, consultoras en recursos humanos,
promoción interna y archivos o bases de datos.
1.19.2 RECLUTAMIENTO
Ilustración 9: Reclutamiento del personal
Fuente: Propia
(Eduadordo, 2004) El proceso de reclutamiento se inicia con la búsqueda de candidatos
y termina cuando se reciben solicitudes de empleo. Este proceso permite adquirir un
conjunto de solicitantes de trabajo, del cual se seleccionara después nuevos empleados.
26
Una vez analizado el requerimiento se procede al reclutamiento siendo este el proceso
que recoge a los candidatos capacitados para desenvolverse en la vacante solicitada y
cubrir con las necesidades laborales de las empresas, tomando en cuenta algunos aspectos
como son: disponibilidad interna y externa de recursos humanos, políticas de la compañía,
planes de recursos humanos, prácticas de reclutamiento y requerimientos del puesto.
El departamento de recursos humanos debe considerar la opción de buscar una alternativa
de selección como el pago de horas extras a los trabajadores si se trata de un alto volumen
temporal de trabajo (época de navidad) o de un contratación eventual (en caso de que la
vacante sea por gravidez).
1.19.3 SELECCIÓN
Ilustración 10: Selección personal
Fuente: Propia
La selección de personal es una comparación entre las cualidades de cada candidato con
las exigencias del cargo, y es una elección entre los candidatos comparados; para
entonces, se hace necesaria la aplicación de técnicas de selección de personal:
1. Entrevista preliminar.- Se pretende descubrir las características más
sobresalientes de los candidatos y su relación con las necesidades del puesto.
27
2. Solicitud de empleo.- Permite realizar juicios sobre asuntos de vital importancia
para el puesto, así como sacar conclusiones sobre los procesos y crecimiento del
aspirante.
3. Investigación de referencias.- Consiste en verificar las referencias que el
candidato presenta, esto se lo hace vía correo o telefónicamente, con el fin de
confirmar la información presentada.
4. Entrevista formal.- La entrevista es una reunión o comunicación oral y personal
entre el postulante y el reclutador con el propósito de investigar aspectos de
interés, como los aspectos de actitud, gestos, poses y otros más y no solo de
palabras del entrevistador, para obtener mayor posibilidad de elementos, aunque
más tarde se los debe investigar y valorar.
5. Pruebas de empleo.- Una vez concluido las entrevistas y los primeros filtros se
procede a la toma de las diferentes pruebas en las cuales se califica la actitud
(imaginación, memoria, habilidad manual) y temperamento.
6. Examen Médico.- Este es el antepenúltimo paso antes de la contratación donde
se identifica si el postulante tiene alguna enfermedad que le incapacite trabajar en
el puesto requerido y otros asuntos más.
7. Entrevista Final.- En algunas ocasiones es necesario que el jefe inmediato realice
también una entrevista con el candidato, con la finalidad de conocerlo y aprobar
la selección.
8. Contratación.- Una vez que se ha decidido la aceptación de un candidato, es
necesario completar sus datos, para integrar su expediente de trabajo; entre estos
se encuentran: fotografías y datos que faltara en la hoja de vida inicial y abrir el
expediente dentro de la empresa.
28
1.19.4 CONTRATACIÓN
Tabla 2: Tipos de Contracción
Fuente: propia
Es formalizar con apego a la ley, la futura relación de trabajo para garantizar los intereses,
derechos y deberes tanto del trabajador como de la empresa. Lo anterior, se hará
mediante un contrato de trabajo en el cual, se establecen las obligaciones,
responsabilidades y las condiciones bajo las cuales se prestará la actividad a desempeñar;
además se especificarán las prestaciones a las que tendrá derecho el nuevo colaborador
como son: sueldo, jornada laboral, vacaciones, primas vacacionales, aguinaldo, demás
remuneraciones, beneficios y otros. Identificando el tipo de contrato que se le va a
legalizar de la siguiente lista:
Expreso o tácito Por tarea
Por tiempo fijo A destajo
Por tiempo indefinido Por enganche
De temporada Individual
Eventual De grupo o por equipo
Ocasional Por horas
A prueba Nombramiento
30
Secuencia de actividades que permiten de una manera ordenada, realizar el pago de salarios a
los empleados conforme lo establecen las normas sustanciales y procedimentales del Trabajo
en Ecuador, así como proporcionar información administrativa y contable, tanto para la empresa
como para los entes encargados de regular las relaciones laborales.
1.20.1 ROLES DE PAGO
(Contabilidadactual, 2013) Lleve el control de los pagos y descuentos que debe realizar a sus
empleados cada mes con una excelente y transparente asesoría y manejo.
También denominado nómina, es un documento global que realiza toda empresa para llevar el
control de la información del costo total mensual unificado que se cancela a cada trabajador o
empleado por sus servicios en la empresa. En este documento se consideran dos secciones, una
para registrar los ingresos como sueldos, horas extras, comisiones, bonos, etc. y otra para
registrar los descuentos como aportes para el seguro social, cuotas por préstamos concedidos
por la compañía, anticipos, etc.
En la subdivisión de este proceso se considera Ingresos y Egresos teniendo cada uno de estos
los rubros designados que a continuación se detalla:
EGRESOS O DESCUENTOS
o Aporte al seguro: En Ecuador esto se refiere al aporte al IESS (Instituto
Ecuatoriano de Seguridad Social) y su aporte es del 9,45%. Este valor se calcula
del total de ingresos (sueldo base + horas extras + comisiones + bonos)
o Préstamos quirografarios: El IESS envía a las empresas las planillas para el
descuento de los empleados que tengan obligaciones con esa institución (IESS)
o Anticipos de sueldo: Es el anticipo que se les entrega a los empleados (por
ejemplo las quincenas) y este valor se debe descontar en roles.
o Comisariato: Son las obligaciones del empleado con estas dependencias y de
igual forma se le debe descontar el consumo mensual.
o Retenciones Judiciales: Son los valores a descontar por orden de un Juez (por
ejemplo para el cuidado de un hijo).
31
o Impuesto a la renta: Es el valor que se debe descontar en el rol al empleado que
haya llegado a la base desgravada. En Ecuador estos valores los emite el S.R.I.
(Servicio de Rentas Internas). La base desgravada según la tabla emitida en el
2008 es de 7.850. El impuesto a la renta grava a los ingresos de las personas
naturales y personas jurídicas, cuyo procedimiento de determinación es diferente
para los dos casos.
INGRESOS
o Sueldo Base: Es la remuneración mensual que percibe el empleado por
aplicación de la ley, o por acuerdo entre las partes (empleador y empleado)
o Comisiones: Es el porcentaje que recibe el empleado por ventas realizadas.
o Bonos: Son los valores por aniversarios, premios, etc.
o Horas Extras: Son horas adicionales de trabajo que realizan los empleados, y
según la jornada serán horas extras del 50% y horas extras del 100% Para el
detalle del cálculo de las horas extras visita el post “Cálculo de las horas extras”
Ilustración 12: Rol de pagos de ejemplo
Fuente: Archivos de la empresa VIRTUALSAMI CIA. LTDA.
32
1.20.2 ASIENTOS CONTABLES DE NÓMINA
Dentro de esta categoría se encuentran aquellos asientos relacionados con la contabilización de
las distintas situaciones que se producen dentro del departamento de recursos humanos de una
empresa, como son:
Pago de nóminas de trabajadores
Contabilización de honorarios de trabajadores autónomos
Liquidación de los seguros sociales
1.21 CONTROL DE ASISTENCIA DE PERSONAL
1.21.1 ASISTENCIA
Dentro de algunas organizaciones donde el pago de los empleados se calcula mediante el
número de horas trabajadas, incluyendo el pago de horas extras; es importante tener un registro
exacto de las entradas y salidas del personal, sin embargo, dichas asistencias actualmente se
manejan por medio de hojas de control donde se registra tanto la hora de entrada como de salida,
prolongando el proceso de verificación de asistencias y horas trabajadas, lo que genera
demasiados cálculos manuales, que originan problemas por la pérdida de hojas y cálculos
erróneos, lo cual provoca atrasos en la información. El problema se agrava si son demasiados
empleados lo que lleva a contratar más personal para realizar el proceso.
Una vez que se genere el proceso en un sistema informativo se observarán ciertos cambios
dentro de la empresa al contar con un reloj biométrico conectado directamente al sistema de
gestión de recursos humanos:
Aceleración del proceso.
Registros automáticos de entradas y salidas.
Cálculos automáticos y exactos del número de horas trabajadas.
Evitará la contratación de personal extra para el proceso.
33
1.22 DESVINCULACIÓN
1.22.1 LIQUIDACIÓN DE PERSONAL
(Caguana, 2012) Parte del ciclo de trabajo de un empleado es la salida de éste de la compañía,
ya sea porqué renuncio de manera voluntaria o porqué fue despedida su salida genera bastante
trabajo para el área de Recursos Humanos.
La desvinculación laboral es el proceso mediante el cual se procede a despedir o finalizar el
contrato que se tiene con la empresa, ya sea de una o más personas que cumplen alguna labor
dentro de una organización, considerando los siguientes aspectos:
No retardar el anuncio de la desvinculación
Hacerlo en forma planificada, justificada y personalizada
Es importante otorgar un período de preaviso, esto disminuirá el impacto emocional
por un lado y por otro le dará tiempo de comenzar su etapa de reinserción laboral.
Notificación del despido
Elaboración de criterios de despido
Comunicación con el empleado
Los motivos de la separación o desvinculación laboral pueden ser por varias opciones las cuales
originan en razones disciplinarias, económicas, personales y otras más:
Renuncias
Las renuncias voluntarias y la situación interna del empleo
Suspensión de relaciones laborables
Terminación de contrato de trabajo
Prevención de la separación
34
Ilustración 13: Diagrama desvinculación o cese de funciones
Fuente: Propia
1.22.2 CONTROL DE ACTIVOS FIJOS
Para seguir con la liquidación dentro de la empresa se procede al último requerimiento en este
caso la entrega de los activos fijos siendo estos de sujetos a control y de larga duración,
redactando una acta la cual lleva las firma de los responsables del departamento de activos, una
vez hecho esto se da el visto bueno para continuar al pago de sus remuneraciones.
1.22.3 SALDO EN PRÉSTAMOS
Ilustración 14: Baja con préstamos
Fuente: Propia
En este caso el exempleado procede a pagar o no pagar la deuda de préstamos adquiridos en la
empresa siendo explicado este proceso en la ilustración anterior.
35
1.23 CONCLUSIONES PARCIALES DEL CAPITULO
El desarrollo del módulo de Recursos Humanos, se orientada a satisfacer las necesidades
relacionadas a los procesos de una empresa siendo de vital importancia debido a los beneficios
que logramos se materializan con la implementación, consiguiendo el sustento para el
crecimiento y el correcto desempeño de las empresas.
La adecuada aplicación de la metodología de desarrollo SCRUM garantiza la calidad de la
aplicación, el mismo que en cada una de sus etapas nos permitirá ir programando y evaluando
la calidad del producto, para las satisfacción del cliente.
Para el desarrollo del Módulo de Recursos Humanos se ha empleado las herramientas de
software de ODOO como son Python y PostgreSQL y los estándares que se describen en el
documento oficial Memento de OpenERP.
La implementación del módulo de Recursos Humanos permite una gestión eficiente de la
información y procesos del personal de la organización, e integra toda esta información y
procesos tanto con los demás módulos de ODOO como con posibles aplicaciones externas.
36
CAPITULO III
PROPUESTA
1.24 METODOLOGÍA DE DESARROLLO SCRUM
SCRUM es una metodología de desarrollo muy simple, que requiere trabajo duro porque no se
basa en el seguimiento de un plan, sino en la adaptación continua a las circunstancias de la
evolución del proyecto. Comparte del manifiesto por el desarrollo ágil de software y sus
principios.
Su funcionamiento está marcado por los siguientes roles/responsabilidades, artefactos y
reuniones: inicia el Gestor de Producto (Rol) creando una lista de requerimientos priorizados
llamada Pila de Producto (Artefacto). Durante la planificación del Sprint (Reunión), se elabora
la Pila del Sprint (Artefacto), que es un bloque de requerimientos de la Pila del Producto, y se
decide cómo implantar esas piezas.
Ilustración 15: Diagrama de la Metodología SCRUM
Fuente: (UPA CHALUPA Wiki, 2016)
Es aquí donde empieza el sprint, y el equipo (Rol) tiene una cantidad de tiempo para completar
su trabajo, que suele ser de dos a cuatro semanas, pero se reúnen cada día (Reunión) para evaluar
37
su progreso. Durante todo este trayecto, el Coordinador de Scrum (Rol de Scrum Manager),
mantiene al equipo enfocado en su objetivo. Al final del Sprint, el trabajo debe ser
potencialmente productivo, como para poner en manos del cliente, o mostrar a las partes
interesadas.
El sprint se completa con una revisión del Sprint (Reunión) donde se muestra el incremento y
una retrospectiva del Sprint para mejorar lo necesario. En el siguiente Sprint que empieza, el
equipo elige otro bloque de la pila de producto y comienza a trabajar de nuevo. El ciclo se repite
hasta que suficientes elementos de la pila de productos se hayan completado.
1.24.1 ARTEFACTOS
1.24.1.1 PILA DEL PRODUCTO (PRODUCT BACKLOG)
Es un documento de alto nivel para todo el proyecto. Contiene las descripciones genéricas de
todos los requerimientos, funcionalidades deseables, etc. Priorizadas según su valor para el
negocio (Business Value).
Al comenzar el proyecto incluye los requisitos inicialmente conocidos y mejor entendidos, y
conforme avanza el desarrollo, y evoluciona el entorno en el que será usado, se va
desarrollando.
1.24.1.2 PILA DEL SPRINT (SPRINT BACKLOG)
Es el conjunto de elementos tomados de la Pila del Producto (Product Backlog) que fueron
priorizados, medidos y aceptados en las reuiones de Sprint Planning (Planificación de los
Sprint). Estos, en conjunto con sus respectivas Historias de Usuario (User Stories), forman
oficialmente los requerimientos a elaborar en cada uno de los Sprints que tendrá el proyecto.
1.24.1.3 SPRINT
38
Es el ciclo de tiempo en el que se desarrolla cada incremento iterativo del producto, en función
de las características del proyecto y el criterio del equipo, lo habitual es realizar Sprints de
duración no inferior a una semana ni mayor de un mes. Cada sprint produce un incremento.
Ilustración 16: Modelo Evolutivo Iterativo
Fuente: (Scrum Manager, 2016)
1.24.1.4 INCREMENTO
Es la parte de producto producida en un Sprint, y tiene como característica el estar
completamente terminada y operativa, en condiciones de ser entregada al cliente.
No se deben considerar como incremento a prototipos, módulos o submódulos, ni partes
pendientes de pruebas o integración.
Idealmente en SCRUM:
Cada elemento de la Pila de Producto se refiere a funcionalidades entregables, no a
trabajos internos del tipo “Diseño de la base de datos”.
Se produce un “Incremento” en cada iteración.
Sin embargo es una excepción frecuente el primer Sprint. En el que objetivos del tipo
“Contrastar la plataforma y el diseño” pueden resultar necesarios, e implican trabajos de diseño
39
o desarrollo de prototipos para contrastar las expectativas de la plataforma o tecnología que se
va a emplear.
Si el proyecto o el sistema requiere documentación, o procesos de validación y verificación
documentados, o con niveles de independencia que implican procesos con terceros, éstos
también tienen que estar realizados para considerar que el incremento esta “hecho (done)”.
1.24.1.5 GRÁFICA DE PRODUCTO (BURN UP)
Es una herramienta de planificación propia del Propietario de Producto, que presenta
visualmente la evolución previsible del producto. Proyecta en el tiempo la construcción del
producto, en base a la velocidad del equipo.
La proyección se realiza sobre un diagrama cartesiano que representa en el eje ordenadas el
esfuerzo estimado para construir las diferentes historias de la pila del producto, y en el de las
abscisas el tiempo medido en sprints.
Ilustración 17: Gráfica de Producto
Fuente: (Scrum Manager, 2016)
Los puntos de corte que marca esta posición con las líneas de velocidad del equipo (pesimista,
realista y optimista) proyectan en el eje horizontal la fecha o Sprint en el que se completara la
versión.
40
Esta es una herramienta para desarrollo ágil. Proyecta la previsión de la Pila de Producto, que
es un documento vivo cuya evolución preestablece la del producto. Como herramienta ágil no
debe considerarse para representar planes estables, sino las previsiones tras cada evolución de
la Pila de Producto.
1.24.1.6 GRáFICa DE AVANCE (BURN DOWN)
Es una gráfica mostrada públicamente que mide la cantidad de requisitos en la Pila de Producto
del proyecto pendientes al comienzo de cada Sprint. Dibujando una línea que conecte los puntos
de todos los Sprints completados, podremos ver el progreso del proyecto.
Se actualiza en las reuniones de seguimiento del Sprint, para monitorizar el ritmo de avance, y
detectar de forma temprana posibles desviaciones sobre la previsión que pudieran comprometer
la entrega al final del Sprint.
La estrategia ágil para el seguimiento de los proyectos se basa en:
Medir el esfuerzo que falta, el no realizado.
Realizar un seguimiento muy cercano (Diario de ser posible).
Este gráfico debe ser actualizado diariamente, y se registra:
En el eje Y se registra el trabajo que aún falta por realizar.
En el eje X se registran los días del sprint.
El equipo dispone en la Pila del Sprint, de la lista de tareas que va a realizar, y en cada uno
figura el esfuerzo pendiente. Esto es: el primer día, en la pila de tareas figura para cada tarea el
esfuerzo que se ha estimado, puesto que aún no se ha trabajado en ninguna de ellas.
Día a día, cada miembro del equipo actualiza en la Pila del Sprint el tiempo que queda a las
tareas que va desarrollando, hasta que se terminan y van quedando en cero los tiempos
pendientes.
41
Con esta información de la pila del sprint se actualiza el gráfico poniendo cada día el esfuerzo
pendiente total de todas las tareas que aún no se han terminado. El avance ideal de un Sprint
estaría representado por la diagonal que reduce el esfuerzo pendiente de forma continua y
gradual hasta terminarlo en el último día del Sprint.
Ilustración 18: Gráfica de Avance ideal de un Sprint
Fuente: (Scrum Manager, 2016)
Las gráficas de diagonal perfecta no son lo habitual, y la siguiente ilustración es un ejemplo
de un patrón de avance más normal.
Ilustración 19: Gráfica de Avance Normal de un Sprint
Fuente: (Scrum Manager, 2016)
El siguiente sería el aspecto de la gráfica en un “Sprint subestimado”
42
Ilustración 20: Gráfica de Avance de un Sprint Subestimado
Fuente: (Scrum Manager, 2016)
La estimación que realizó el equipo en la reunión de inicio del Sprint es inferior al esfuerzo real
que están requiriendo las tareas. Y el siguiente sería el patrón de gráfica de un “Sprint
Sobrestimado”.
Ilustración 21: Gráfica de Avance de un Sprint Sobrestimado
Fuente: (Scrum Manager, 2016)
1.24.2 REUNIONES EN SCRUM
43
Ilustración 22: Reuniones en SCRUM
Fuente: (Scrum.org, 2016)
1.24.2.1 REUNIÓN DE INICIO DE SPRINT
Al inicio del ciclo Sprint (Cada 15 o 30 días), una “Reunión de Inicio de Sprint” se lleva a cabo
en la cual se selecciona el trabajo que se realizara y tiene ocho horas como límite.
1.24.2.2 REUNIÓN TÉCNICA DIARIA (DAILY SCRUM)
Esta reunión debe llevarse a cabo todos los días a la misma hora y en la misma ubicación y es
utilizada para que cada miembro del equipo conteste las siguientes preguntas:
1) ¿Qué has hecho desde ayer?
2) ¿Qué es lo que estás planeando hacer hoy?
3) ¿Has tenido algún problema que te haya impedido alcanzar tu objetivo?
1.24.2.3 REUNIÓN DE CIERRE DE SPRINT Y ENTREGA DEL INCREMENTO
Permite revisar el trabajo que fue completado y no completado; y presentar el trabajo a los
interesados tiene cuatro horas como límite.
44
1.25 DESARROLLO DE LA PROPUESTA
1.25.1 INTRODUCCIÓN
Este documento describe la implementación de la metodología de trabajo SCRUM en
VIRTUALSAMI CIA. LTDA. para la gestión del desarrollo del proyecto
“IMPLEMENTACIÓN DEL MÓDULO DE RECURSOS HUMANOS AL SISTEMA DE
PLANIFICACIÓN DE RECURSOS EMPRESARIALES ODOO VERSIÓN 8.0”. Incluye
junto con la descripción de este ciclo de vida iterativo e incremental para el proyecto, los
artefactos o documentos con los que se gestionan las tareas de adquisición y suministro:
requisitos, monitorización y seguimiento del avance, así como las responsabilidades y
compromisos de los participantes en el proyecto.
1.25.1.1 PROPÓSITO DE ESTE DOCUMENTO
Facilitar la información de referencia necesaria a las personas implicadas en el desarrollo del
proyecto “IMPLEMENTACIÓN DEL MÓDULO DE RECURSOS HUMANOS AL
SISTEMA DE PLANIFICACIÓN DE RECURSOS EMPRESARIALES ODOO VERSIÓN
8.0”.
1.25.1.2 ALCANCE
Personas y procedimientos implicados en el desarrollo del proyecto “IMPLEMENTACIÓN
DEL MÓDULO DE RECURSOS HUMANOS AL SISTEMA DE PLANIFICACIÓN DE
RECURSOS EMPRESARIALES ODOO VERSIÓN 8.0”
45
1.25.2 DESCRIPCIÓN GENERAL DE LA METODOLOGÍA SCRUM
1.25.2.1 FUNDAMENTACIÓN
Las principales razones del uso de un ciclo de desarrollo iterativo e incremental de tipo SCRUM
para la ejecución de este proyecto son:
Sistema modular. Las características del SISTEMA DE PLANIFICACIÓN DE
RECURSOS EMPRESARIALES ODOO VERSIÓN 8.0 permiten desarrollar una base
funcional mínima y sobre ella ir incrementando las funcionalidades o modificando el
comportamiento o apariencia de las ya implementadas.
Entregas frecuentes y continuas al cliente de los módulos terminados, de forma que puede
disponer de una funcionalidad básica en un tiempo mínimo y a partir de ahí un incremento
y mejora continua del sistema.
Previsible inestabilidad de requisitos:
Es posible que el sistema incorpore más funcionalidades de las inicialmente
identificadas.
Es posible que durante la ejecución del proyecto se altere el orden en el que se desean
recibir los módulos o historias de usuario terminadas.
Para el cliente resulta difícil precisar cuál será la dimensión completa del módulo, y su
crecimiento puede continuarse en el tiempo suspenderse o detenerse.
1.25.2.2 VALORES DE TRABAJO
Los valores que deben ser practicados por todos los miembros involucrados en el desarrollo y
que hacen posible que la metodología SCRUM tenga éxito son:
Autonomía del equipo.
Respeto en el equipo.
Responsabilidad y auto – disciplina.
46
Foco en la tarea.
Información transparencia y visibilidad.
1.25.3 PERSONAS Y ROLES DEL PROYECTO
Tabla 3: Personas y roles de SCRUM
Persona Contacto Rol
Amanda Mafla [email protected] Coodinador/
Scrum Master
Ing. Alcides Rivera [email protected] Gestor de Producto /
Product Owner
Amanda Mafla [email protected] Equipo técnico/
Team
Fuente: Propia
1.25.4 ARTEFACTOS
Documentos
Pila de producto o Product Backlog
Pila de sprint o Sprint Backlog
Sprint
Incremento
Gráficas para registro y seguimiento del avance
Gráfica de producto o Burn Up
Gráfica de avance o Burn Down
Comunicación y presentación de informes directo
Reunión de inicio de sprint
Reunión técnica diaria
47
Reunión de cierre de sprint y entrega del incremento
1.25.4.1 PILA DE PRODUCTO
Es el equivalente a los requisitos del sistema o del usuario (Con-Ops) en esta metodología.
El gestor de producto de su correcta gestión, durante todo el proyecto.
El gestor de producto puede recabar las consultas y asesoramiento que pueda necesitar para su
redacción y gestión durante el proyecto al Scrum Manager de este proyecto.
Responsabilidades del Gestor de Producto:
Registrar en la lista de pila del producto, las historias de usuario que definen el sistema.
Mantenimiento actualizado de la pila del producto durante toda la ejecución del proyecto.
Orden en el que se desea recibir terminada cada historia de usuario.
Incorporación/eliminación y modificaciones de las historias o de su orden de prioridad.
Disponibilidad: Las historias de usuario se presentan en proyector y se envían mediante
correo institucional al Scrum Manager para su actualización.
Responsabilidades del Scrum Manager:
Supervisión de la pila de producto, y comunicación con el gestor del producto para
pedirle aclaración de las dudas que pueda tener, o asesorarle para la subsanación de las
deficiencias que observe.
Responsabilidades del Equipo Técnico:
Comprensión y conocimiento actualizado de la pila del producto.
Resolución de dudas o comunicación de sugerencias con el Gestor del Producto.
Responsabilidades del resto de implicados:
Comprensión y conocimiento actualizado de la pila del producto.
48
Resolución de dudas o comunicación de sugerencias con el Scrum Manager.
Tabla 4: Pila del Producto
ID PRIORIDAD DESCRIPCIÓN ESTIMACIÓN ASIGNADO
Recursos Humanos en ODOO 37
Reclutamiento, selección y contratación 11 AM
Registro de Candidatos 3
1 Alta Diseño de la Plataforma 1 AM
2 Media Formulario de Registro 2 AM
Evaluación del Candidato 2
3 Media Evaluación de Candidato 2 AM
Entrevista 2
4 Descripción Entrevista 2 AM
Contratos 4
5 Media Parametrización 1 AM
6 Alta Ingreso de Información del Empleado 1 AM
7 Alta Generación del Contrato 2 AM
Nomina 8
Roles de Pago 4
8 Media Parametrización 1 AM
9 Muy Alta
Registro Mensual Valores de Horas
Extras, Suplementarias y otros 2 AM
10 Alta Envío al Correo Electrónico 1 AM
Asientos Contables 4
11 Muy Alta
Generación Automática de los
Asientos Contables 4 AM
Asistencia 10
Reloj Biométrico 7
12 Alta Configuración del Reloj Biométrico 3 AM
13 Muy Alta Conexión con el Sistema 4 AM
Reportes de Asistencia 3
14 Alta Reportes de Asistencia 3 AM
Desvinculación 8
Activos Fijos 4
15 Media Parametrizacion 1 AM
16 Media Ingreso de Activos 2 AM
17 Alta Registro del Custodio 1 AM
Desvinculación 4
18 Media Parametrización 1 AM
19 Media Ingreso Información Desvinculación 2 AM
20 Alta Generación del Acta de Finiquito 1 AM Fuente: Propia
49
1.25.4.2 PILA DEL SPRINT
Es el documento de registro de los requisitos detallados o tareas que van a desarrollar el equipo
técnico en la iteración (actual o que está preparándose para comenzar)
Responsabilidades del Gestor de Producto
Presencia en las reuniones en las que el equipo elabora la pila del sprint.
Resolución de dudas sobre las historias de usuario que se descomponen en la pila del
sprint.
Responsabilidades del Scrum Manager
Supervisión y asesoría en la elaboración de la pila de la pila del sprint.
Responsabilidades del Equipo Técnico
Elaboración de la pila del sprint.
Resolución de dudas o comunicación de sugerencias sobre las historias de usuario con
el gestor del producto.
Tabla 5: Planificación de los Sprints
Nombre Sprint Fecha de
Inicio Fecha Final Días
Totales: 37
Reclutamiento, selección y contratación 23 Ene 2016 04 Feb 2016 11
Nómina 05 Feb 2016 13 Feb 2016 8
Asistencia 15 Feb 2016 25 Feb 2016 10
Desvinculación 26 Feb 2016 05 Mar 2016 8 Fuente: Autor
50
SPRINT 0: RECLUTAMIENTO, SELECCIÓN Y CONTRATACIÓN
Ilustración 23: Tablero de Trabajo Sprint 0
Fuente: Autor
SPRINT 1: NÓMINA
Ilustración 24: Tablero de Trabajo Sprint 1
Fuente: Autor
SPRINT 2: ASISTENCIA
Ilustración 25: Tablero de Trabajo Sprint 2
Fuente: Autor
51
SPRINT 3: DESVINCULACIÓN
Ilustración 26: Tablero de Trabajo Sprint 3
Fuente: Autor
1.25.4.3 SPRINT
Cada una de las iteraciones del ciclo de vida iterativo Scrum. La duración de cada sprint: puede
ser de 5 a de 15 días laborables, y su duración se determinará al inicio del mismo en la
planificación del Sprint.
1.25.4.4 INCREMENTO
Parte o subsistema que se produce en un sprint y se entrega al gestor del producto
completamente terminado y operativo.
1.25.4.5 GRÁFICA DE PRODUCTO (BURN up)
Representación gráfica del plan de producto previsto por el Gestor de Producto. Es una gráfica
que representa los temas o epics del sistema en el orden que se desean, y el tiempo en el que se
prevé su ejecución.
Responsabilidades del gestor de producto
Confección
Mantenimiento actualizado en todo momento durante la ejecución del proyecto:
52
Orden en el que desea disponer de los temas o “epics” del sistema, e hitos del producto
(versiones).
Incorporación/eliminación y modificaciones de los temas, o de su orden de prioridad,
estimaciones o hitos.
Disponibilidad: Las temas se presentan en proyector y se envían mediante correo
institucional al Scrum Manager para su actualización.
Responsabilidades del Scrum Manager
Supervisión del gráfico de producto, y comunicación con el Gestor de Producto para
pedirle aclaración de las dudas que pueda tener, o asesorarle para la subsanación de las
deficiencias que observe.
Responsabilidades del Equipo Técnico
Comprensión y conocimiento actualizado del plan del producto.
Resolución de dudas o comunicación de sugerencias con el Gestor de Producto.
Responsabilidades del resto de implicados
Comprensión y conocimiento actualizado del plan del producto.
Resolución de dudas o comunicación de sugerencias con el Scrum Manager.
53
SPRINT 0: RECLUTAMIENTO, SELECCIÓN Y CONTRATACIÓN
Ilustración 27: Avance Sprint 0
Fuente: Autor
Ilustración 28: Gráfica de Seguimiento Sprint 0
Fuente: Autor
54
SPRINT 1: NÓMINA
Ilustración 29: Avance Sprint 1
Fuente: Autor
Ilustración 30: Grafica de Seguimiento Sprint 1
Fuente: Autor
55
SPRINT 2: ASISTENCIA
Ilustración 31: Avance Sprint 2
Fuente: Autor
Ilustración 32: Gráfica de Seguimiento Sprint 2
Fuente: Autor
56
SPRINT 3: DESVINCULACIÓN
Ilustración 33: Avance Sprint 3
Fuente: Autor
Ilustración 34: Gráfica de Seguimiento Sprint 3
Fuente: Autor
57
1.25.4.6 GRÁFICA DE AVANCE (BURN DOWN)
Gráfico que muestra el estado de avance del trabajo del sprint en curso.
Responsabilidades del Gestor de Producto
Sin responsabilidades específicas, más allá de mantenerse regularmente informado del
avance del sprint y disponible para atender decisiones para la resolución de opciones en
sprints sobrevalorados o infravalorados (la gráfica de avance predice una entrega
anterior o posterior a la fecha prevista)
Responsabilidades del Scrum Manager
Supervisión de la actualización diaria por parte del equipo.
Responsabilidades del Equipo Técnico
Actualización diaria del gráfico de avance.
SPRINT 0: RECLUTAMIENTO, SELECCIÓN Y CONTRATACIÓN
Ilustración 35: Alcance, Tipo de Trabajo: Codificación Sprint 0
Fuente: Autor
58
Ilustración 36: Reporte Resumen Sprint 0
Fuente: Autor
SPRINT 1: NÓMINA
Ilustración 37: Alcance, Tipo de Trabajo: Codificación Sprint 1
Fuente: Autor
Ilustración 38: Reporte Resumen Sprint 1
Fuente: Autor
59
SPRINT 2: ASISTENCIA
Ilustración 39: Alcance, Tipo de Trabajo: Codificación Sprint 2
Fuente: Autor
Ilustración 40: Reporte Resumen Sprint 2
Fuente: Autor
60
SPRINT 3: DESVINCULACIÓN
Ilustración 41: Alcance, Tipo de Trabajo: Codificación Sprint 3
Fuente: Autor
Ilustración 42: Reporte Resumen Sprint 3
Fuente: Autor
1.25.4.7 REUNIÓN DE INICIO DE SPRINT
Reunión para determinar las funcionalidades o historias de usuario que se van a incluir en el
próximo incremento.
Responsabilidades del Gestor de Producto
Asistencia a la reunión.
Exposición y explicación de las historias que necesita para la próxima iteración y
posibles restricciones de fechas que pudiera tener.
61
Responsabilidades del Scrum Manager
Moderación de la reunión
Responsabilidades del equipo técnico
Confección de la pila del sprint.
Auto-asignación del trabajo.
1.25.4.8 REUNIÓN TÉCNICA DIARIA
Puesta en común diaria del equipo con presencia del Coordinador del proyecto o Scrum
Manager de duración máxima de 15 minutos.
Responsabilidades del Scrum Manager
Supervisión de la reunión y anotación de las necesidades o impedimentos que pueda
detectar el equipo.
Gestión para la solución de las necesidades o impedimentos detectados por el equipo.
Responsabilidades del Equipo Técnico
Comunicación individual del trabajo realizado el día anterior y el previsto para día
actual.
Actualización individual del trabajo pendiente.
Actualización del gráfico de avance para reflejar el estado de avance
Notificación de necesidades o impedimentos previstos u ocurridos para realizar las
tareas asignadas.
62
1.25.4.9 REUNIÓN DE CIERRE DE SPRINT Y ENTREGA DEL INCREMENTO
Reunión para probar y entregar el incremento al Gestor de Producto.
Características.
Prácticas: sobre el producto terminado, no sobre simulaciones o imágenes.
De tiempo acotado máximo de 2 horas.
Responsabilidades del Gestor de Producto
Asistencia a la reunión.
Recepción del producto o presentación de reparos.
Responsabilidades del Scrum Manager
Moderación de la reunión
Responsabilidades del Equipo Técnico
Presentación del incremento.
CONCLUSIONES
1. La implementación del módulo de Gestión de Recursos Humanos en la empresa
VirtualSAMI Cía. Ltda. mejoró los procesos de:
a. Selección: Mayor cantidad de aspirantes, implementación de evaluaciones:
psicológicas, psicométricas y de conocimientos, cálculo y publicación de
resultados en el sistema informático.
b. Contratación: Generación automática de la hoja de vida empresarial y de su
respectivo contrato.
c. Gestión: Eficiencia en la generación de roles de pago y ahorro de papel con el
envío del mismo al respectivo correo electrónico del empleado. Generación
automática de los valores por concepto de finiquito.
d. Manejo de Nómina: Automatización de la generación del asiento contable de
nómina.
e. Asistencia: Mejor control de la asistencia mediante Relojes Biométrico y el
envío de la información online al sistema informático.
2. Realizar el estudio de los procesos actuales dentro del Departamento de Recursos
Humanos de la empresa VirtualSAMI Cía. Ltda. Permitió y realizar su aplicación en el
sistema informático.
3. La fundamentación teórica los procesos de Gestión de Recursos Humanos dentro de la
empresa posibilito conocer sus fortalezas y debilidades para tomar los correctivos
necesarios.
4. Luego de efectuar la implementación dentro del módulo de Recursos Humanos de
ODOO los procesos de reclutamiento, evaluación, asistencia, contratos y gastos de sus
empleados; se obtuvo la plantilla indispensable para las futuras implementaciones por
parte de VirtualSAMI Cía. Ltda. en sus clientes.
5. La validación de la propuesta proporcionó los lineamientos necesarios para la
implementación del sistema informático.
6. Liberar en el sistema de versionamiento GitHub la solución desarrollada permitirá que
desarrolladores a nivel mundial mejorar y corregir bugs de la aplicación.
RECOMENDACIONES
1. Las empresas en general deben implementar un Sistema Informáticos ERP como es el
ODOO ya que al ser una solución modular permite la integración con el resto de los
miembros de la cadena de valor, lo que no se lograría al tener varios sistemas como islas
por más eficientes que estos sean.
2. Todas las microempresas deben establecer una UTH unidad de talento humano que
permita entre otras cosas el fortalecimiento del conocimiento técnico necesario para el
mejor desempeño de las actividades laborales, y así aumentar la productividad de los
trabajadores.
3. Recomendar a la Universidad el establecimiento de una normativa que permita que
todos los proyectos informáticos se puedan publicar en un repositorio de software libre
para que se de impulso a dichos proyectos.
4. Para los proyectos de software se debe utilizar metodología SCRUM ya que el cliente
puede comprobar de manera regular si se van cumpliendo sus expectativas, da feedback,
ya que desde el inicio del proyecto puede tomar decisiones informadas a partir de
resultados objetivos y dirigir estos resultados del proyecto, iteración a iteración, hacia
su meta. Se ahorra esfuerzo y tiempo al evitar hipótesis.
5. En el desarrollo de aplicaciones se debe utilizar modelos de desarrollo rápido RAD que
permiten la utilización de técnicas de cuarta generación. En lugar de crear software con
lenguajes de programación de tercera generación, se trabaja para volver a utilizar
componentes de programas ya existentes (cuando es posible) o a crear componentes
reutilizables (cuando sea necesario). En todos los casos se utilizan herramientas para
facilitar la construcción de software.
BIBLIOGRAFÍA Y LINOGRAFÍA
ABC, D. (09 de 03 de 2016). Definición de Lluvia de Ideas. Recuperado el 09 de 03 de 2016,
de http://www.definicionabc.com/comunicacion/lluvia-de-ideas.php
Alles, M. (2013). Dirección Estratégica de Recursos Humanos. Madrid: Paraninfo.
Arias, F. G. (2012). El proyecto de Investigación (Sexta ed.). Caracas, Venezuela: EPISTEME
C.A.
Belen Ana Ventura Susana Delgado. (2013). Recursos Humanos y Responsabilidad Social
Corporativa. Mexico: Paraninfo.
blog.espol.edu.ec. (01 de 07 de 2011). Teoría de Sistemas. Obtenido de
http://blog.espol.edu.ec/cesary/2011/07/01/teoria-de-sistemas/
Blogger. (04 de 10 de 2014). Fases del modelo Cascada. Obtenido de
http://fasesmodelocascada.blogspot.com/
Bonilla, M., & Gilles, C. (2001). Internet y sociedad en América Latina y el Caribe,
investigaciones para sustentar el diálogo. Quito, Pichincha, Ecuador: FLACSO, Sede
Ecuador.
Caguana, L. (31 de 10 de 2012). 6tocontabilida.blogspot.com. Obtenido de
http://6tocontabilida.blogspot.com/2012/10/v-behaviorurldefaultvmlo_31.html
Contabilidadactual. (10 de 08 de 2013). contabilidadactual.com. Obtenido de
http://www.contabilidad-actual.com.mx/2013/08/10/reclutamiento-selecci%C3%B3n-
contrataci%C3%B3n-inducci%C3%B3n-y-capacitaci%C3%B3n-de-personal/
Definicionabc. (2007). www.definicionabc.com. Obtenido de
http://www.definicionabc.com/derecho/contratacion.php
Drake, J. D. (2009). Postgre. Recuperado el 20 de 01 de 2015, de Postgre:
http://www.postgresql.org/
Eduadordo, R. C. (2004). Sistema de Administración Salarial. Mexico: Trillas.
Eoi.es. (09 de 04 de 2013). uso de cookies. Obtenido de
https://www.eoi.es/blogs/mintecon/2013/04/09/como-hacer-un-proceso-de-
reclutamiento-y-de-seleccion-de-personal-efectivo/
es.wikipedia.org. (13 de 03 de 2016). es.wikipedia.org. Obtenido de
https://es.wikipedia.org/wiki/Portal_(Internet)
Gallego, M. T. (2013). Gestión de proyectos Informáticos . Recuperado el 05 de 2015, de
http://openaccess.uoc.edu/
Garcia Rivas, C. G. (15 de 04 de 2008). MAESTRIA EN TECNOLOGIA DE LA
CONSTRUCCION: TRABAJO INDIVIDUAL Nº 01: METODO DEDUCTIVO Y
METODO INDUCTIVO. Obtenido de
http://colbertgarcia.blogspot.com/2008/04/metodo-deductivo-y-metodo-inductivo.html
Guzdial, M. J., & Ericson, B. (2013). Introducción a la computación y programación con
Phyton. Pearon Educación.
Izquierdo, S. (2012). www.openerpweb.es. Obtenido de http://www.openerpweb.es/recursos-
humanos-openerp/
Juan, F. M. (2012). APLICACIONES WEB. CFGM. España: RA-MA EDITORIAL.
Knowlton, J. (2009). Python. ANAYA Multimedia.
Maristany, J. (1993). Tratado de Recursos Humanos. Madrid: CDN CIENCIAS DE LA
DIRECCION.
Martinez, R. (2009-2013). PostgreSql-ES. Recuperado el 05 de 2015, de
http://www.postgresql.org.es/
Mejía, M. O. (10 de 06 de 2015). Teoría de la contingencia empresarial. Obtenido de
http://www.gestiopolis.com/teoria-contingencia-empresarial/
Mondy, R. W. (2011). Administración de recursos humanos. Bogota: Pearson.
Montalbán, I. L. (2012). Bases de Datos. Bogota: Garceta.
Mountain Goat Software. (2010). Mountain Goa. Recuperado el 01 de 2015, de Mountain Goa:
http://www.mountaingoatsoftware.com/agile/scrum
Odoo. (15 de 10 de 2000). Open Source ERP and CRM. Recuperado el 05 de 2015, de
https://www.odoo.com/es_ES/
Odoo SA. (2010). Odoo. Recuperado el 18 de 01 de 2015, de Odoo: http://apps.openerp.com
Palacio, J. (2014). Gestiónde proyectos Scrum Manager. Scrum Manager® .
Palasí Lallana, V. R. (01 de 01 de 2015). Motores de Persistencia. Obtenido de Sitio Web de
Universidad Francisco Gavidia:
http://www.ufg.edu.sv/ufg/theorethikos/Julio04/mdp6.html
Perez, X. J. (10 de 01 de 2013). es.slideshare.net. Obtenido de
http://es.slideshare.net/jonathanperezxavier/rol-depagos
ProgramaciónDesarrollo. (11 de 03 de 2011). Qué es un entorno de desarrollo integrado, IDE?
Obtenido de http://programaciondesarrollo.es/que-es-un-entorno-de-desarrollo-
integrado-ide/
Python Software Foundation. (01 de 16 de 2008). Python. Recuperado el 05 de 01 de 2015, de
Python: http://www.python.org/doc/
Sabana Mendoza, M. (2006). PhP con postgreSQL 8. Megabyte.
Scrum Manager. (20 de 01 de 2016). Scrum Manager Body Of Konwledge. Obtenido de Gráfico
de Avance o Burn Down:
http://www.scrummanager.net/bok/index.php?title=Gr%C3%A1fico_de_avance
Scrum Manager. (20 de 01 de 2016). Scrum Manager Body Of Konwledge. Obtenido de Modelo
Evolutivo Iterativo :
http://www.scrummanager.net/bok/index.php?title=File:Modelo_evolutivo_iterativo.p
ng
Scrum.org. (20 de 01 de 2016). Scrum.org. Obtenido de Bienvenido a la documentación de
SCRUM: http://metodologiascrum.readthedocs.io/en/latest/index.html
Smetoolkit. (2008). mexico.smetoolkit.org. Obtenido de
http://mexico.smetoolkit.org/mexico/es/content/es/3616/Contrataci%C3%B3n-de-
personal-
symfony.es. (02 de 06 de 2016). symfony.es. Obtenido de http://symfony.es/pagina/que-es-
symfony/
THINK&SELL. (27 de 03 de 2012). Sistemas de Gestión Normalizados, 7.7.1.0. Recuperado
el 09 de 03 de 2016, de http://thinkandsell.com/servicios/consultoria/software-y-
sistemas/sistemas-de-gestion-normalizados/
Trimarchi, S. (Dirección). (2011). OpenERP - Employees and Contract (Empleados y
Contratos) [Película]. Obtenido de https://www.youtube.com/watch?v=mvvinL3yEe4
TuFuncion. (09 de 07 de 2008). Los orígenes del modelo vista controlador. Obtenido de Sitio
Web de TuFuncion: http://www.tufuncion.com/mvc
UPA CHALUPA Wiki. (20 de 01 de 2016). UPA CHALUPA Wiki. Obtenido de Diagrama-
proceso-scrum.gif: http://es.upachalupa.wikia.com/wiki/Archivo:Diagrama-proceso-
scrum.gif
VirtualSAMI Cia. Ltda. (19 de 02 de 2016). VirtualSAMI. Obtenido de VirtualSAMI:
www.virtualsami.com.ec
Wikipedia. (30 de 10 de 2013). Servicio de Anteción al Cliente. Obtenido de
https://es.wikipedia.org/wiki/Servicio_de_atenci%C3%B3n_al_cliente
Wikipedia. (18 de 01 de 2014). Red de Área Amplia. Obtenido de
https://es.wikipedia.org/wiki/Red_de_%C3%A1rea_amplia
Wikipedia. (13 de 06 de 2016). Aplicación Web. Obtenido de
https://es.wikipedia.org/wiki/Aplicaci%C3%B3n_web
Wikipedia. (23 de 06 de 2016). Base de Datos. Obtenido de
https://es.wikipedia.org/wiki/Base_de_datos?oldid=91875554
wikipedia. (10 de 05 de 2016). Desarrollo en Cascada. Obtenido de
https://es.wikipedia.org/wiki/Desarrollo_en_cascada
Wikipedia. (27 de 05 de 2016). Lenguaje de Programación. Obtenido de
https://es.wikipedia.org/wiki/Lenguaje_de_programaci%C3%B3n
Wikipedia. (16 de 05 de 2016). Teoría X y teoría Y. Obtenido de
https://es.wikipedia.org/wiki/Teor%C3%ADa_X_y_teor%C3%ADa_Y
www.ecured.cu. (19 de 04 de 2016). ecured.cu. Obtenido de
http://www.ecured.cu/Aplicaci%C3%B3n_web
www.portgresql.org.es. (02 de 10 de 2010). Sobre postgreSQL. Obtenido de
http://www.postgresql.org.es/sobre_postgresql
ANEXOS
DESCRIPCIÓN UBICACIÓN
Código Fuente de OpenERP y todos sus
componentes CD adjunto
Código Fuente de Base de Datos (scripts de
base de datos) CD adjunto
Modelo físico de base de datos CD adjunto
Diccionario de datos CD adjunto
Scripts de base de Base de datos CD adjunto
Manuales de Usuario CD adjunto
Manual de instalación CD adjunto
Manual de Configuración CD adjunto
Manual de Administración CD adjunto