ANÁLISIS Y GESTIÓN DE REQUERIMIENTOS Y REQUISITOS DE …

ANÁLISIS Y GESTIÓN DE REQUERIMIENTOS Y REQUISITOS DE LASOLUCIÓN DE SOFTWARE PARA APOYAR EL PROCESO DE GESTIÓN DE

NÓMINA EN LA UNIVERSIDAD DISTRITAL, SIGUIENDO LOS LINEAMIENTOSDEL PROCESO DE DESARROLLO OPENUP/OAS EN SUS FASES DE INICIO,

ELABORACIÓN Y CONSTRUCCIÓN.

AUTOR:

SERGIO DAVID ORJUELA VELÁSQUEZ

PROYECTO DE GRADO PARA OPTAR AL TÍTULO DE INGENIERO DESISTEMAS

ALEJANDRO PAOLO DAZADIRECTOR

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS

FACULTAD DE INGENIERÍA

INGENIERÍA DE SISTEMAS

BOGOTÁ D.C. 2015

TABLA DE CONTENIDO

CAPÍTULO 1. INTRODUCCIÓN................................................................................6

CAPÍTULO 2. PLANTEAMIENTO DEL PROBLEMA................................................7

CAPÍTULO 3. OBJETIVOS........................................................................................9

3.1. Objetivo General.............................................................................................9

3.2. Objetivos Específicos......................................................................................9

CAPÍTULO 4. JUSTIFICACIÓN...............................................................................10

CAPÍTULO 5. MARCO TEÓRICO...........................................................................11

5.1. El Proceso OPENUP/OAS............................................................................11

5.1.1. Generalidades........................................................................................11

5.1.2. El método de trabajo..............................................................................14

5.1.3. Subprocesos OPENUP/OAS..................................................................18

5.2. Ingeniería de Requerimientos y Requisitos..................................................21

5.2.1. Generalidades........................................................................................21

5.2.2. Gestión de requerimientos y requisitos..................................................21

5.2.3. Los requerimientos y requisitos..............................................................22

5.2.4. ¿Cómo detallar un requerimiento?.........................................................23

5.2.5. Definición de requisitos..........................................................................24

5.2.6. Técnicas de capturas de requerimientos...............................................24

5.2.7. Casos de Uso.........................................................................................25

5.3. La Nómina: estructura, partes y elementos básicos.....................................26

5.3.1. Retribución bruta: conceptos que conforman el salario bruto...............27

5.3.2. Descuentos en la nómina.......................................................................28

5.3.3. Procesos de liquidación para docentes de vinculación especial en laUniversidad Distrital..........................................................................................28

5.3.4. Procesos de liquidación para contratistas en la Universidad Distrital. . .32

CAPÍTULO 6. METODOLOGÍA...............................................................................35

CAPÍTULO 7. DESARROLLO.................................................................................40

7.1. Modelo De Gestión De Nómina....................................................................43

2

7.2. Modelo BPMN - Gestión De Nómina............................................................44

7.3. Requerimientos No Funcionales...................................................................52

7.4. Requerimientos Funcionales Identificados...................................................54

7.5. Sistema De Gestión De Nómina (TITAN-Descripción por Módulo)..............64

7.5.1. Módulo: Parámetros Del Sistema...........................................................65

7.5.2. Módulo: Gestión Persona.......................................................................70

7.5.3. Módulo: Gestión Conceptos...................................................................72

7.5.4. Módulo: Gestión De Novedades............................................................78

7.5.5. Módulo: Gestión De Liquidación............................................................87

7.5.6. Módulo: Gestión De Reportes................................................................90

CAPITULO 8. RESULTADOS Y TRABAJO A FUTURO..........................................92

CAPITULO 9. CONCLUSIONES.............................................................................93

CAPÍTULO 10. BIBLIOGRAFÍA...............................................................................95

ANEXOS..................................................................................................................97

Especificaciones De Caso De Uso:.....................................................................97

3

ÍNDICE DE ILUSTRACIONES

Ilustración 1 Mapa de Subprocesos OPENUP/OAS...............................................18Ilustración 2 Equipo de Desarrollo del Proceso OPENUP/OAS.............................20Ilustración 3 Metodología de Trabajo......................................................................38Ilustración 4 Metodología Subproceso de "Gestión de Requerimientos yRequisitos"...............................................................................................................39Ilustración 5 Flujo de Trabajo Proyecto TITAN........................................................41Ilustración 6 Artefacto Plan General de Ejecución del Proyecto.............................42Ilustración 7 Artefacto de Control de Cambios........................................................42Ilustración 8 Modelo de Dominio.............................................................................44Ilustración 9 Diagrama BPM (Gestión Persona).....................................................45Ilustración 10 Diagrama BPM (Gestión Vinculación Persona Natural)...................46Ilustración 11 Diagrama BPM (Gestión de Parámetros).........................................47Ilustración 12 Diagrama BPM (Gestión de Conceptos)...........................................47Ilustración 13 Diagrama BPM (Gestión de Novedades 1)......................................48Ilustración 14 Diagrama BPM (Gestión de Novedades 2)......................................49Ilustración 15 Diagrama BPM (Pre liquidación).......................................................50Ilustración 16 Diagrama BPM (Liquidación)............................................................51Ilustración 17 Diagrama BPM (Gestión de Plantilla)...............................................51Ilustración 18 Diagrama BPM (Gestión de Plantilla)...............................................52Ilustración 19 Diagrama de Caso Uso (Parámetro Actividades Económicas)........66Ilustración 20 Diagrama de Caso Uso (Parámetro Fondo de Pensiones)..............67Ilustración 21 Diagrama de Caso Uso (Parámetro Tipo de Vinculación)................68Ilustración 22 Diagrama de Caso Uso (Parámetro de Liquidación)........................69Ilustración 23 Diagrama de Caso Uso (Gestión de Categorías de Parámetros deLiquidación)..............................................................................................................70Ilustración 24 Diagrama de Caso Uso (Gestión Persona)......................................71Ilustración 25 Fases de Registro y Modificación de un Concepto..........................73Ilustración 26 Diagrama de Caso Uso (Registro de Concepto)..............................73Ilustración 27 Diagrama de Caso Uso (Actualización de Concepto)......................74Ilustración 28 Diagrama de Caso Uso (Inactivación y Consulta de Concepto)......75Ilustración 29 Diagrama de Caso Uso (Gestión Categorías de Conceptos)...........76Ilustración 30 Diagrama de Caso Uso (Gestión de Asociación de Conceptos)......78Ilustración 31 Fases de Registro y Modificación de Novedad................................80Ilustración 32 Diagrama de Caso Uso (Generar Novedad)....................................80Ilustración 33 Diagrama de Caso Uso (Editar Novedad)........................................81Ilustración 34 Diagrama de Caso Uso (Consultar e Inactivar Novedad)................82Ilustración 35 Diagrama de Caso Uso (Asociar Novedad a Empleado).................83

4

Ilustración 36 Diagrama de Caso Uso (Modificar Novedad Asociada)...................84Ilustración 37 Diagrama de Caso Uso (Consultar e Inactivar Novedad Asociada).84Ilustración 38 Diagrama de Caso Uso (Vinculación Persona Natural)....................86Ilustración 39 Diagrama de Caso Uso (Registro y Gestión de Hoja de Vida).........87Ilustración 40 Diagrama de Caso Uso (Gestión de Nómina)..................................88Ilustración 41 Diagrama de Caso Uso (Gestión de Pre liquidaciones)...................89Ilustración 42 Diagrama de Caso Uso (Gestión Liquidaciones)..............................90

ÍNDICE DE TABLAS

Tabla 1 Actividades y Tareas Fase de Inicio............................................................14Tabla 2 Actividades y Tareas Fase de Elaboración.................................................16Tabla 3 Subproceso de “Gestión de Requerimientos y Requisitos” del Proceso deDesarrollo OPENUP/OAS........................................................................................19Tabla 4 Roles del Proceso OPENUP/OAS..............................................................20Tabla 5 Factor Categoría Docentes de Vinculación Especial.................................30Tabla 6 Tabla de Descuentos Docentes de Vinculación Especial...........................30Tabla 7 Tabla de Impuestos.....................................................................................31Tabla 8 Honorarios Mensuales................................................................................32Tabla 9 Impuestos y Descuentos Contratistas........................................................33Tabla 10 Requerimientos No Funcionales del Sistema...........................................53Tabla 11 Listado Maestro de Requerimientos Funcionales....................................55

5

CAPÍTULO 1. INTRODUCCIÓN

La Universidad Distrital Francisco José de Caldas es un ente autónomo deEducación Superior cuya misión se centra en las funciones básicas de docencia,investigación y extensión. Para poder desempeñar su labor como instituciónacadémica y pública requiere de la vinculación de personas naturales y jurídicas(contratistas, docentes de planta, docentes de vinculación especial,administrativos, etc.) quienes a través de sus habilidades y talentos apoyan eldesarrollo de todas las actividades que la Universidad debe llevar a cabo; dichasvinculaciones implican el cumplimiento de un conjunto de requisitos legales, entrelos cuales destaca la nómina, la cual hace referencia a la retribución monetariaque se ofrece a una organización o persona por sus servicios.

Sin importar el tipo de vinculación contractual que una persona natural tenga conla Universidad, se debe realizar periódicamente una gestión de nómina, procesoen el cual se liquidan los honorarios, prestaciones y aportes patronales, seguridadsocial, parafiscales y prestaciones sociales según sea el caso y de acuerdo a lasconsideración establecidas por la ley.

Actualmente la Institución cuenta con un proceso de gestión de nómina que secondiciona y se altera de acuerdo al tipo de vinculación contractual existente. Enconsecuencia, la Universidad cuenta con algunas herramientas informáticas quesoportan dichos procesos, que van desde hojas de cálculos de Excel hastasoluciones más robustas soportadas en bases de datos Oracle. Sin embargo elcomún denominador de estos procesos es la baja flexibilidad a nuevosrequerimientos legales o tributarios del entorno externo o institucional, así como labaja interoperabilidad con otros componentes de software requeridos paraefectuar los pagos y causaciones financieras.

Teniendo en cuenta lo anterior, la Oficina Asesora de Sistemas (OAS) de lainstitución tiene como proyecto analizar, diseñar y construir una solución desoftware integral y escalable que permita apoyar los procesos relacionados a lagestión de nóminas. Con este fin, el proyecto que se describe a lo largo de estedocumento (gestión y análisis de requerimientos) hace parte del proyectopropuesto por la OAS que busca solucionar los problemas planteados.

6

CAPÍTULO 2. PLANTEAMIENTO DEL PROBLEMA

La Universidad Distrital debe realizar periódicamente la gestión de nómina detodas las personas vinculadas a la institución, pero las herramientas informáticasque se utilizan actualmente son obsoletas para soportar la información y losprocesos que la liquidación de nómina implica.

Esto, sumado a la poca interoperabilidad de las herramientas con otroscomponentes de software a nivel interno y externo genera poca confianza, laescaza disponibilidad e integridad de los datos, las demoras en los pagos dehonorarios o sueldos, los traumatismos en los procesos internos de la división derecursos financieros y recursos humanos, la revelación inadecuada y pocofidedigna de la información financiera y la falta de información oportuna para lapresentación de informes a los diferentes entes de control convergen enresultados incompletos, no confiables y que no soportan adecuadamente losprocesos involucrados en la nómina, en consecuencia con lo anteriormentenombrado los procesos dentro de la institución en lo que a gestión nominarespecta no son óptimos.

Adicionalmente, dentro de la institución existen diferentes tipos de vinculación(como los profesores de planta, profesores de vinculación especial, contratistas,administrativos y pensionados) que se someten a procesos de liquidación denómina diferentes, por lo que la gestión de nómina en la Universidad Distrital esuna tarea compleja que implica más que un simple software ofimático o de bajaadaptabilidad. Lo anteriormente mencionado hace evidente la falta de cohesión yel aislamiento de los procesos de gestión de nómina de acuerdo a los diferentestipos de vinculación.

Por ejemplo, los procesos relacionados a la nómina de los docentes de vinculaciónespecial y los contratistas son críticos, debido al tratamiento especial que se debeaplicar en cado uno de los casos, razón por lo cual es necesario el análisis y laidentificación de los procedimientos de gestión de nómina particulares de estosdos tipos de vinculación. Otro de los factores a tener en cuenta es la hoja de vidacomo una de las unidades fundamentales de la vinculación y gestión de nóminapara la cual también se hace necesario la generación de un meta modelo de hojade vida que se pueda generalizar en todas las vinculación existentes.

7

CAPÍTULO 3. OBJETIVOS

3.1. Objetivo General

Realizar el análisis y la gestión de requerimientos y requisitos de una soluciónmodular, integral y escalable que permita apoyar los procesos relacionados a lagestión de nóminas de la Universidad Distrital, soportado en tecnologías libres,siguiendo el proceso de desarrollo OPENUP/OAS.

3.2. Objetivos Específicos

● Caracterizar el modelo de operación del sistema con el fin de definir losrequerimientos funcionales y no funcionales que deben considerarse en lasolución de software.

● Comprender las interacciones entre los usuarios y el sistema a desarrollarpartiendo de los requerimientos y los diálogos con los interesados, con elfin de aclarar el conjunto de casos de uso requeridos en la solución alproblema planteado.

● Generar los artefactos establecidos por el proceso de desarrolloOPENUP/OAS en el subproceso de “Gestión de Requerimientos yRequisitos”, que serán base del proceso de desarrollo.

● Realizar los modelos gráficos de los procesos involucrados en la gestiónde nóminas en las Universidad Distrital utilizando notación estandarizada ynotación de procesos BPMN.

9

CAPÍTULO 4. JUSTIFICACIÓN

Debido a que la Universidad Distrital no cuenta con un sistema integral, unificado yescalable que permita soportar el proceso de gestión de nómina en la Instituciónde las personas naturales que tiene algún vínculo contractual con la Universidad,se hace necesario el análisis, diseño y desarrollo de una solución de software.

Esto permite unificar los diferentes tipos de nóminas existentes en un solosistemas de información web, cuyas características sea una alta interoperabilidadcon otros componentes de software, adaptable a los cambios normativos y legalesdel entorno interno o externo y que cumpla requisitos de alta calidad encapacidades de usabilidad, fiabilidad, rendimiento y mantenimiento del software.

Aunque la Universidad Distrital es formadora de profesionales de alta calidad,reconocidos en el entorno laboral por su buen desempeño en los campos dondeaplican sus saberes, en últimos años el trabajo conjunto entre los futurosprofesionales y la institución ha decaído.

Debido a esto, la Oficina Asesora de Sistemas tiene como objetivo vincular a losestudiantes de últimos semestres de ingeniería de sistemas al desarrollo de losproyectos vigentes, proceso que afianzará y fortalecerá los conocimientos y lashabilidades de los futuros profesionales y permitirá que estos últimos aporten através de sus competencias al crecimiento de la institución superior.

El desarrollo a través del trabajo conjunto de los estudiantes y la Oficina Asesorade Sistemas de la Universidad de una solución integral de software permitiráreducir el tiempo invertido en el proceso de la liquidación de la nómina encualquier tipo de vinculación contractual en la Universidad y consecuentementepagos oportunos a los funcionarios, docentes y contratistas de la Institución.

Por otro lado, por ser un sistema interoperable permitirá lograr una sincronizaciónprecisa de datos con otros sistemas proveedores o destinatarios y armonizar lainformación organizacional.

10

CAPÍTULO 5. MARCO TEÓRICO

5.1. El Proceso OPENUP/OAS.

En el marco de la resolución 461 de Rectoría del 29 de Julio de 2011 1, laUniversidad Distrital Francisco José de Caldas avaló el método de desarrolloOPENUP/OAS, como el marco de trabajo institucional en el análisis, diseño,desarrollo e implementación de productos de software al interior de la Universidad.A continuación se describen sus principales directrices y fundamentos.

5.1.1. Generalidades

El proceso OPENUP/OAS es un método de trabajo que involucra un conjuntomínimo de prácticas tendientes a guiar a un equipo de trabajo pequeño en elanálisis, diseño, desarrollo y despliegue de un producto de software. Los objetivosque persigue son:

● Promover la colaboración y compartir conocimientos alineando interesesdel equipo de trabajo y los usuarios.

● Ayudar al equipo a enfocarse en la arquitectura de forma rápida, de talmanera que se minimicen los riesgos y se organice el desarrollo.

● Ayudar al equipo a balancear prioridades en conflicto para maximizar elvalor obtenido por los interesados en el proyecto.

● Ayudar al equipo en la evolución continua del producto para obtenerretroalimentación constante y fomentar el mejoramiento.

● Permitir a los administradores del proyecto realizar seguimientos a losavances basados en metas e indicadores.

● Permitir que los integrantes del equipo entiendan rápidamente comorealizar el trabajo para alcanzar los objetivos y metas proyectadas.

1COLOMBIA. UNIVERSIDAD DISTRITAL FRANSISCO JOSE DE CALDAS.Resolución No 461. (29, Julio, 2011). Por medio de la cual se adopta el método delproceso de desarrollo OPENUP/OAS como marco de trabajo Institucional en elanálisis, diseño, desarrollo e implantación de productos de software al interior dela Universidad Distrital Francisco José de Caldas. SISGRAL Bogotá D.C.

11

Los principios en que se enmarcan en el método de trabajo OPENUP/OAS son:

a. Conocer a los Interesados: Se deben identificar a los grupos de interés ytrabajar de cerca con ellos para asegurarse que sus necesidades son claramentedefinidas e incrementalmente satisfechas a medida que se evoluciona en eldesarrollo de la solución.

b. Separar el Problema de la Solución: Se debe estar seguro que se conoce elproblema (o una parte de él) antes de definir una solución (o una parte de ella).

c. Crear un conocimiento compartido del dominio: Se debe fomentar unambiente de intercambio y trabajo en el que todos los involucrados puedanobtener constantemente la información adecuada para lograr tener una visióncompartida de lo que se debe hacer, el por qué hacerlo y cómo se está haciendo.

d. Usar escenarios y casos de uso para capturar requerimientos: Hacer usode escenarios y casos de uso para capturar los requerimientos funcionales delsistema.

e. Establecer y mantener contratos de prioridades: Se deben priorizar losrequisitos y requerimientos de implementación basados en un trabajo continuo conlos grupos de interés y tomar decisiones que lleven a que el sistema siempreincremente los beneficios ofrecidos y reduzca los riesgos.

f. Realizar negociaciones que maximicen el beneficio obtenido: Lasnegociaciones costo beneficio dentro del proyecto no pueden ser independientesde la arquitectura. Los requisitos y requerimientos establecen los beneficios quese deben alcanzar al implementar el sistema mientras que la arquitectura es unamedida base para calcular el costo del mismo. El costo asociado con un beneficiopuede influenciar en gran medida la percepción del usuario acerca del valor realobtenido.

g. Gestionar el entorno: El cambio es inevitable, y aunque presentaoportunidades para mejorar los beneficios dados a los grupos de interés, unentorno incontrolado de cambios fácilmente decantará en sistemas deficientes. Sedebe gestionar los cambios manteniendo contratos específicos con los grupos deinterés.

h. Conocer cuándo se debe parar: Sobre recargar de características un sistemano sólo es una pérdida de tiempo y recursos sino que conduce a sistemasinnecesariamente complejos. El desarrollo debe parar cuando la calidad esperadadel sistema se alcanza.

13

i. Mantener un entendimiento común: Ser proactivo comunicándose ycompartiendo información con los participantes del proyecto y no asumir que todosencontrarán justo lo que ellos necesitan saber o que cada persona tiene la mismacomprensión del proyecto que todos los demás.

j. Aprender continuamente: Desarrollar continuamente las habilidades técnicas einterpersonales, aprender de los ejemplos de los colegas, aprovechar laoportunidad, tanto de ser un estudiante de sus colegas, así como maestro deellos.

k. Organizar alrededor de la arquitectura: La comunicación entre los miembrosdel equipo empieza a ser compleja incrementalmente. Por consiguiente, espertinente organizar el equipo alrededor de la arquitectura, el vocabulario y elmodelo mental compartido del sistema.

l. Desarrollar el proyecto en iteraciones: Dividir el proyecto en una serie deiteraciones encajadas en el tiempo y planear el proyecto iterativamente.

m. Gestionar los riesgos: Atacar tempranamente los riesgos que pudieran poneren riesgo el proyecto. Es necesario identificar y priorizar los riesgos para idearestrategias y mitigarlos.

n. Adoptar y gestionar el cambio: Adoptar los cambios ayuda a construir unsistema que se encamina a suplir las necesidades de los interesados. Manejar loscambios permite reducir costos y mejorar la predicción de éstos.

o. Medir el progreso objetivamente: Si no se conoce objetivamente cómo estáprogresando el proyecto, no se sabrá si éste falla o tiene éxito. La incertidumbre ylos cambios a un proyecto de software en progreso dificultan medirloobjetivamente.2

2UNIVERSIDAD DISTRITAL FRANSISCO JOSE DE CALDAS. Guía Rápida Proceso deDesarrollo OPENUP/OAS. Primera Edición. Bogotá, 2011. p. 1-3.

14

5.1.2. El método de trabajo

El OPENUP/OAS es un proceso iterativo e incremental que se distribuye a travésde cuatro fases: Inicio, Elaboración, Construcción y Transición en las cuales sedesarrollan transversalmente una serie de subprocesos entendiéndose estosúltimos como un conjunto de actividades, personas (Roles), prácticas (Guías) yproductos de trabajo (Artefactos) que orientan el desarrollo de software a travésdel tiempo.

Cada fase puede tener tantas iteraciones como se requiera, dependiendo delgrado de complejidad y desconocimiento del dominio, la tecnología a ser usada, lacomplejidad arquitectónica y el tamaño del proyecto, por nombrar algunosfactores3.

5.1.2.1. Fases del proceso OPENUP/OAS

Fase de Inicio: En esta, los interesados (stakeholders) y los integrantes delequipo de desarrollo, colaboran para determinar el ámbito del proyecto, susobjetivos y determinar si el proyecto es viable.

Las iteraciones de esta fase enfocan el esfuerzo de trabajo en las siguientesactividades y resultados:

Tabla 1 Actividades y Tareas Fase de Inicio

Actividad Resultados

Iniciar el proyecto *Elaborar el documento Visión.*Elaborar el Plan General del Proyecto.*Elaborar el documento de Análisis deriesgo.

3Ibíd., p. 4.

15

Planear y gestionar la iteración *Elaborar el Plan de Iteración.*Elaborar el documento de evaluación de laiteración.*Elaborar el documento de valoración deresultados de la iteración.

Identificar y refinar losrequerimientos y requisitos

*Elaborar la especificación de casos de uso*Elaborar el documento de requisitos desoporte*Elaborar el documento casos de prueba

Llegar a un acuerdo sobre elenfoque técnico

Elaborar el documento Bloc de Notas de laArquitectura

Tomada de Guía Rápida Proceso de Desarrollo OPENUP/OAS. Primera Edición. Bogotá,2011. p. 4-5.

Al final de esta fase, como mínimo, en el proyecto:

● Se ha definido el ámbito.● Se tiene un estimado inicial de los costos y el cronograma.● Se ha definido y priorizado un conjunto inicial de requerimientos

funcionales y no funcionales.● Se han identificado un conjunto de riesgos y ha propuesto las estrategias

de mitigación.● Se han identificado un conjunto de interesados.● Se ha creado un bosquejo de arquitectura.

Fase de Elaboración: La segunda fase dentro del ciclo de vida del proyecto. Enella los riesgos significativos que influyen en la arquitectura son identificados yconsiderados.

En esta fase:

● Se obtiene un entendimiento más detallado de los requerimientos yrequisitos.

● Se diseña, implementa válida y establece la línea base de la arquitectura.● Se mitigan los riesgos esenciales.● Se produce un cronograma detallado.● Se realiza una mejor estimación de costos.

16

Las iteraciones de esta fase enfocan su esfuerzo de trabajo en las siguientesactividades y resultados:

Tabla 2 Actividades y Tareas Fase de Elaboración

Actividad Tareas/Resultados

Planear y gestionar la iteración

*Elaborar el Plan de Iteración.*Elaborar el documento de evaluación de la iteración.*Elaborar el documento de valoración de resultados de la iteración.

Identificar y refinar los requerimientos

*Actualizar, depurar y aumentar el contenido de laespecificación de casos de uso.*Actualizar, depurar y aumentar el contenido del documento de Requerimientos de soporte.*Actualizar, depurar y aumentar el contenido del documento Casos de prueba.

Desarrollar la arquitectura *Agregar las vistas de arquitectura al documento Bloc de Notas de la Arquitectura.

Desarrollar un incremento en la solución

*Actualizar, depurar y aumentar el contenido del documento Especificación de Diseño.*Actualizar, depurar y aumentar el contenido del documento Pruebas efectuadas por el Realizador.*Obtener el código fuente que realiza uno o varioselementos de diseño.*Elaboración de una Construcción del Sistema que integre nuevos elementos (componentes desarrollados, clases, etc.).*Elaborar el artefacto Registro de Pruebas que contenga los resultados de la ejecución de las pruebas hechas por el realizador.

Probar la Solución Construida Elaborar el artefacto Script de Prueba.Elaborar el artefacto Registro de Pruebas que contenga los resultados de la ejecución de las pruebas.

17

Gestionar las peticiones decambio

Actualizar, depurar y aumentar el contenido del documento Lista de Unidades de Trabajo.


Fase de Construcción: La tercera fase se enfoca en detallar los requisitos yrequerimientos, diseñar, implementar y probar el grueso del software y completarel desarrollo del sistema basado en la arquitectura.

En esta fase:

Se describen los requisitos y requerimientos restantes Se completan en detalles los diseños, la implementación y las pruebas del

software. Se libera la primera versión operativa del software (beta) del sistema.

Las actividades de esta fase son:

Planificación y gestión de la iteración. Identificar y refinar requisitos y requerimientos. Desarrollar un incremento de solución. Probar la solución construida.

Fase de Transición: La última fase se enfoca en la transición del producto desoftware a la plataforma tecnológica del cliente logrando que los interesadosconvengan en que el desarrollo del producto cumple con los requerimientosplanteados.

Los objetivos a alcanzar en esta fase son:

● La prueba beta valida que satisfaga las expectativas del usuario. Esto,típicamente, requiere algunas actividades de afinamiento, tales comodepuración de errores y mejora del desempeño y la usabilidad.

● El consentimiento de los interesados en que el desarrollo está completo.Esto puede involucrar varios niveles de pruebas para la aceptación delproducto, incluyendo pruebas formales e informales y pruebas beta.

● Mejorar el desempeño en futuros proyectos a través de leccionesaprendidas.

18

● Documentar las lecciones aprendidas y mejorar el ambiente de losprocesos y las Herramientas para el proyecto.4

5.1.3. Subprocesos OPENUP/OAS

Como se había señalado anteriormente, un subproceso es el conjunto deactividades desarrolladas por personas con unos roles determinados, las cualesse guían por medio de una serie de prácticas o guías para obtener ciertosproductos de trabajo denominados Artefactos, que permiten cumplir y direccionarlas fases y actividades propuestas en las cuatro fases del proceso de desarrollo desoftware OPENUP/OAS.

Estos subprocesos se relacionan entre sí, siendo unas entradas o insumosiniciales para que otros subprocesos se puedan desarrollar.5

Ilustración 1 Mapa de Subprocesos OPENUP/OAS

Tomada de Guía Rápida Proceso de Desarrollo OPENUP/OAS. Primera Edición. Bogotá,2011. p. 7.

4Ibíd., p. 4-7.

5Ibíd., p. 7-9.

19

Teniendo en cuenta que el proyecto se fundamenta en el análisis y la gestión derequerimientos el subproceso de interés principal es el de Gestión deRequerimientos y Requisitos.

Tabla 3 Subproceso de “Gestión de Requerimientos y Requisitos” del Proceso de DesarrolloOPENUP/OAS

Subproceso Objetivo Artefactos de Salida

Gestión de Requerimientos yRequisitos

Recolectar, analizar, aprobar y seguir la evolución de los requerimientos funcionales del Cliente o interesado y los requisitos del software a través de la vida del productoy/o servicio.

*Documento Visión.*Especificaciones de Casos de Uso.*Glosario.*Requisitos de Soporte.*Actas de Trabajo.*Listado de requerimientos funcionales y no funcionales.


5.1.2.3. Roles OPENUP/OAS

Los productos de software los crean personas con diferentes intereses ycompetencias. Un ambiente de grupo saludable potencia la colaboración efectivarequiriendo una cultura compartida que fomente la creatividad y el cambio positivo.

Los roles son el rostro humano del proceso de desarrollo de software.Dependiendo del número de personas que conforman el equipo de trabajo y lascondiciones del proyecto una persona puede asumir uno o varios roles.6

6Ibíd., p. 9-10.

20

Ilustración 2 Equipo de Desarrollo del Proceso OPENUP/OAS


Tabla 4 Roles del Proceso OPENUP/OAS

Rol Función Principal

Analista Realizar tareas de relevamiento, análisis y diseño delos requerimientos y requisitos en el proyecto.


21

5.2. Ingeniería de Requerimientos y Requisitos

5.2.1. Generalidades

¿Qué es?

De acuerdo a lo expuesto por Roger Pressman en su libro de “Ingeniería deSoftware”, la ingeniería de requisitos ayuda a los ingenieros de software aentender mejor el problema en cuya solución trabajarán, cuenta con un conjuntode actividades que ayuda a comprender, la lógica de negocio, ¿qué es lo que elcliente quiere?, y ¿cómo interactúan los usuarios finales con el software?

¿Quién lo hace?

Los encargados de realizar la ingeniería de requisitos y requerimientos, son losingenieros de software, también denominados ingenieros de requerimientos,ingenieros de sistemas o analistas junto con los interesados del proyecto comousuarios finales o clientes.

¿Por qué es importante?

Su relevancia es dada por la necesidad de comprender qué es lo que realmentequiere el cliente a fin de desarrollar una solución acertada y que se ajuste a lasnecesidades formuladas por los interesados.

¿Cuál es el producto obtenido?

El objetivo es presentar a través de artefactos como documentos, actas, glosarios,etc., la explicación del problema a solucionar.7

5.2.2. Gestión de requerimientos y requisitos

A continuación, y teniendo en cuenta que el proyecto a desarrollar vincula alestudiante al rol de Ingeniero de Requerimientos, se hace necesario profundizaren los conceptos, técnicas y metodologías que este trabajo implica.

7PRESSMAN, Roger. Ingeniería del Software: Un Enfoque Práctico, Sexta Edición. McGraw-Hill, 2005.p 155-156.

22

5.2.3. Los requerimientos y requisitos

Los requerimientos son la base para iniciar el desarrollo de cualquier proyecto desoftware. Éstos permiten identificar las necesidades de los interesados ydeterminar lo que se debe incluir en el sistema para satisfacer dichasnecesidades, pero no solo se limitan a ello, también ayudan a administrar lasexpectativas, priorizar y asignar el trabajo, verificar y validar el sistema yadministrar el ámbito del proyecto.

Los requerimientos de un proyecto se pueden presentar de varias formas, comotexto estructurado o no estructurado, casos de uso, escenarios o la combinaciónde todos ellos.

Adicionalmente existen requerimientos que presentan un comportamientoespecifico del sistema y a estos se les denomina requisitos, como los requisitoslegales, atributos de calidad (confiabilidad, desempeño, etc.), requisitos de interfazo restricciones de diseño (compatibilidad). Estos requisitos deben ser capturados yregistrados en un documento de especificaciones de soporte, donde se almacenala información de cada uno de ellos.

En síntesis, los requerimientos describen el comportamiento del sistema y lo quese espera del él. Los denominados requerimientos funcionales son capturados enlos caso de uso y los no funcionales (también denominados requisitos) sonregistrados en el artefacto “especificaciones de soporte”. Sin embargo en muchoscasos algunos requisitos están fuertemente relacionados con algunos casos deuso, lo cual conlleva a capturarlos directamente dentro de estos últimos con el finde simplificar la comunicación y el mantenimiento.

A los requerimientos y requisitos se les puede asignar un conjunto de atributos conel fin de ayudar la gestión del proyecto, estos atributos presentan característicasadicionales como:

● Prioridad: declara la importancia relativa del requerimiento o requisito.● Asignado a: quien es el encargado de asegurarse que el requerimiento o

requisito se está cumpliendo● Iteración: la iteración en la cual se pretende implementar el requerimiento

o requisito.● Estimación del tamaño: brindar una estimación de alto nivel que dé cuenta

del esfuerzo requerido parta implementar y verificar el requerimiento orequisito y su solución.

23

● Esfuerzo faltante: Un estimativo del esfuerzo que falta para implementar yverificar el requerimiento o requisito y su implementación.

● Estado: Marca el progreso en la implementación de un requerimiento orequisito.

● Fuente: Persona, documento u otro origen del requerimiento. ● Comentarios: Comentarios hechos a un requerimiento o requisito por parte

de los revisores o escritores.● Dificultad: Un indicador del nivel de esfuerzo requerido para implementar

el requerimiento (Alto, medio, bajo).● Riesgo: Medida confidencial acerca de la probabilidad real de cumplir o no

un requerimiento o requisito.● ID de prueba: Identificación de una prueba específica u otro método de

verificación que pueda ser aplicado al requerimiento o requisito.8

5.2.4. ¿Cómo detallar un requerimiento?

Un requerimiento o requisito debe ser escrito en una sola frase conformada por unsujeto y un predicado. El sujeto representa a un actor que puede ser un usuario,un sistema o una entidad de diseño relacionada con el requerimiento; el predicadopor su parte especifica la acción o el resultado esperado, que se realizada por,para o con el sujeto, normalmente incluye condiciones y criterios de desempeño.

Ejemplo:

El módulo de nómina debe ser capaz de generar la nómina de 2000 empleadosuna vez por mes.

En los requerimientos o requisitos de los interesados se recomienda usar la frase“debería ser capaz de”, la cual expresa que el interesado puede realizar algo perono necesariamente debe hacerlo, por otra parte en el caso de los requerimientosdel sistema se recomienda usar la frase “deberá ser capaz de”, lo que implica quees obligatorio que se cumpla la acción.

Nota: Se recomienda adicionalmente no usar palabras que conduzcan a laambigüedad tales como “todos”, “algunos” o “todo” y evitar la conjunciones (y/o),

8UNIVERSIDAD DISTRITAL FRANSISCO JOSE DE CALDAS. Capítulo 6 "Gestiónde Requerimientos y Requisitos", Proceso de Desarrollo OPENUP/OAS. PrimeraEdición. Bogotá, 2011. p. 8-10.

24

identificar el usuario y la acción resultante y utilizar frases sencillas y directas conun lenguaje no muy especializado.9

5.2.5. Definición de requisitos

Los requisitos de sistema son parte fundamental de la ingeniería derequerimientos. Por lo general, los interesados no tienen dominio de tema y porende se les hace difícil identificar estas características, estos requisitos se tienenen cuenta cuando se considera todo el ámbito del sistema y están asociados conlas características de calidad o las restricciones. Estos se clasifican en:

● Características de uso e interacción con el usuario.● Confiabilidad.● Desempeño.● Capacidad del sistema para ser mantenido.● Restricciones.● Interfaz a sistemas o dispositivos externos.● Reglas de Negocio.10

5.2.6. Técnicas de capturas de requerimientos

El proceso de levantamiento de requerimientos debe contar con las fuentes deinformación adecuadas, esto colaborara a una ingeniería de requerimientosexitosa. Afortunadamente, estas fuentes son fáciles de hallar y no implicanmayores costos.

Según OPENUP/OAS, las fuentes primarias de requerimientos son losinteresados, por ende es necesario identificar:

Clientes Usuarios Administradores Equipo de Mantenimiento Asociados

9Ibíd., p. 11-13.

10Ibíd., p. 13-18.

25

Sin embargo existen otras fuentes, que las pueden dar los mismos interesadoscomo otros interesados o documentos en archivo, se recomienda indagar respectoa posibles fuentes adicionales:

Expertos en el dominio de interés como jefes de dependencias,

empleados antiguos, pensionados, entre otros. Analistas en el tema de la educación y la administración educativa. Información acerca de Instituciones de Educación Superior o en general

del área de interés.

Cuando las fuentes de información han sido identificadas se procede a realizar lacaptura de requerimientos utilizando generalmente las siguientes técnicas:

Sesiones de tormentas de ideas. Entrevistas. Trabajar en el ambiente objetivo. Estudio de sistemas análogos. Análisis de sugerencias y reportes de problemas y fallos. Charlas con los equipos de soporte. Estudiar las mejoras realizadas por los usuarios. Búsqueda de usuarios no considerados. Conducir sesiones de trabajo en grupo y talleres. Mostrar los prototipos a los interesados.11

5.2.7. Casos de Uso

Los casos de uso son herramientas fundamentales dentro del proceso de gestiónde requerimientos y requisitos, pues son descripciones textuales y gráficas de lainteracción entre un sistema y su entorno. Éstas muestran la forma básica decomo un sistema interactúa con los actores externos los cuales pueden serusuarios, otros sistemas, o pueden presentarse como eventos u otro tipo decomponentes.

En síntesis los casos de uso de descripción textual describen la interacción entrealgunos actores externos y el sistema computacional y los casos de uso gráficosrepresentan las relaciones entre actores y casos de uso y casos de uso con otroscasos de uso.

11Ibíd., p. 18-22.

26

Normalmente, los casos de uso de descripción textual y gráfica se complementany para su generación se utiliza un lenguaje fácil de interpretar y entendible para losusuarios no especializados.12

5.3. La Nómina: estructura, partes y elementos básicos

La nómina es el sistema contable de la empresa, utilizada para mantener unregistro con el salario, cargo, deducciones, así como otros gastos yrendimientos que genera cada uno de sus empleados. La nómina es eldocumento que se entrega mensualmente a todos los trabajadores en el queaparece el detalle del salario que recibe, junto con las deducciones que se lepractican de dicho salario, bien sea por descuentos obligatorios marcados porla legislación vigente, por otro tipo de descuentos como anticipos, odeducciones para seguros de salud.13

El formato estándar de una nómina está regulado por la legislación vigente yse marca una estructura y contenido mínimo que se debe respetar en todocaso. El contenido mínimo de la nómina debe incluir:

Datos identificativos de la empresa, dirección del centro de trabajo y

código cuenta cotización en el que está el trabajador incluido. Datos básicos del trabajador, tipo de contrato, categoría, antigüedad

en la empresa. Periodo de liquidación al que corresponde dicha nómina. Detalle de las percepciones salariales y extra salariales que

componen la retribución bruta del trabajador. Detalle de las deducciones que se le practican al salario bruto, bien

marcadas por la legislación vigente, por otro tipo de deducciones quehaya que aplicarle a la nómina, como anticipos o, embargos en lanómina.

Líquido a percibir, dado que la nómina tiene consideración de

documento acreditativo del pago de salarios cerrando los pagospendientes al trabajador para el periodo estipulado.

12KULAK Daryl, GUINEY Eamonn. Use Cases: Requirements in Context,Segunda Edicion, Addison-Wesley Professional, 2004. p.34-35.

13[Citado el 03 de Septiembre de 2015] Disponible en <http://financialred.com/ >.

27

Detalle de las bases de cotización de la nómina Lugar de emisión y firma y sello por la empresa y trabajador.13

Es importante resaltar que aunque estos elementos sean mínimos, existenalgunas excepciones como el caso de la firma del trabajador. No es necesariadicha firma si el pago de la nómina se ha realizado por medios bancarios quepuedan demostrar la percepción salarial por parte del trabajador.

5.3.1. Retribución bruta: conceptos que conforman el salario bruto

La suma total de todos los conceptos que hay que abonar al trabajador danorigen a la retribución bruta mensual. La nómina tiene por norma generalperiodos de liquidación mensuales con las siguientes excepciones:

Entrada o salida del trabajador de la empresa, sin que estas fechas

correspondan con el mes natural. Nóminas de paga extra.

Dentro de las percepciones que se suman para dar lugar al salario brutotenemos dos grupos diferenciados:

Percepciones salariales: que lo conforman todos aquellos conceptos queestán fijados por el convenio colectivo de aplicación en la empresa.

Percepciones extra salariales: en el que se incluyen conceptos que no tienenla consideración pura de salario, como pueden ser dietas, gastos delocomoción o pluses por retribuciones en especie como el plus por desgastede herramientas.14

5.3.2. Descuentos en la nómina

Tal y como hemos explicado anteriormente, en la nómina podemos encontrardos tipos de descuento diferentes, que son los descuentos obligatorios por leyo bien los descuentos que se deban aplicar por cualquier otro tipo denormativas.

14Ibíd.

28

En el caso de los descuentos por ley, tenemos dos grupos de deduccionesdiferentes, que se destinan al pago de la seguridad social a cargo deltrabajador, como los pagos a cuenta que el propio trabajador tiene querealizar por impuestos u otros conceptos.

La liquidación de nómina, los descuentos y los diferentes factores que se tieneen cuenta dependen directamente del tipo de vinculación que tenga lapersona natural o jurídica con el empleador. Particularmente, en laUniversidad Distrital existen varios tipos de vinculación entre los cualesdestacan los docentes de vinculación especial y los contratistas, módulos quese desarrollaran en este proyecto.

5.3.3. Procesos de liquidación para docentes de vinculación especial en laUniversidad Distrital

Dentro de la Universidad Distrital existen varios tipos de vinculación para losdocentes, como los docentes de vinculación especial, que de acuerdo con elDecreto No. 1003 DE 2013 “Por el cual se dictan disposiciones en materia salarialy prestacional para los empleados públicos docentes y administrativos de lasUniversidades Estatales u Oficiales” y regulado en la institución bajo la ResoluciónNo.352 del 24 de junio de 2013 “por medio de la cual se acoge y aplica el Decreto1003 de 21 de mayo de 2013 a los docentes de Vinculación Especial HoraCátedra, Medio tiempo Ocasional y Tiempo Completo Ocasional en Pregrado en lopertinente únicamente al valor del punto” pertenecen a un tipo de vinculaciónparticular y deben cumplir con ciertos requisitos en el proceso de liquidación denómina.15

En consideración con el Decreto 1279 de 2002, los profesores de hora cátedra deUniversidades estatales a excepción de la Universidad Nacional de Colombia noson empleados públicos y por ende este decreto no aplica para ellos, porconsiguiente sus condiciones salariales y prestacionales están regidas bajo lanormatividad interna de la Universidad en la cual laboren.

La Universidad Distrital, teniendo en cuenta lo descrito, mediante el Acuerdo 11 de2002 establece las siguientes reglas y parámetros para este tipo de docentes y la

15OFICINA ASESORA DE SISTEMAS, (OAS). Modelo de negocio Nómina de Docentes deVinculación Especial, Primera Edición. OAS, 2013.p 2-3.

29

vinculación contractual que sostienen con la Universidad “Son docentes devinculación especial aquellos que, sin pertenecer a la carrera docente, estánvinculados temporalmente a la Universidad”.16

Los docentes de vinculación especial se clasifican así:a) Ocasionales: Tiempo completo y medio tiempo.b) De Hora cátedrac) Visitantesd) Expertos

El valor del punto para el cálculo del valor de la hora de los docentes en lamodalidad de vinculación especial en los programas de posgrados, es el fijado porel Gobierno Nacional. Dicho valor está determinado para la presente vigenciamediante Decreto 1003 de 2013 en la suma de $10.438.oo, el cual fue acogido porla Resolución No.352 de 2013. Adicionalmente, la Universidad ha contratadoalgunos docentes a los cuales se les cancelan los factores salariales mediante lamodalidad de honorarios.17

En consecuencia los pagos a docentes de vinculación especial se realizan através de honorarios y hora cátedra así:

1. Hora Cátedra: El valor del contrato está dado por la siguiente formula:

Valor Total del Contrato= VSMLV * Factor * Total_Horas_Semestre

Donde VSMLV: Valor Salario Mínimo Legal Vigente, y el factor está dado por lacategoría respectiva.

Tabla 5 Factor Categoría Docentes de Vinculación Especial

Categoría %Asistente 0.13

Asistente UD 0.16Asociado 0.17

Asociado UD 0.19Titular 0.20

16Ibíd., p. 4.

17Ibíd., p. 5

30

Titular UD 0.22Tomada de OFICINA ASESORA DE SISTEMAS, (OAS). Modelo de negocio Nómina de

Docentes de Vinculación Especial, Primera Edición. OAS, 2013.p 4.

La liquidación mensual de los docentes se realiza de la siguiente manera:

Valor del contrato / número de meses = valor mensual del contratoValor Mensual del contrato - Descuentos = Neto a pagar

Y los descuentos que se aplican son: Tabla 6 Tabla de Descuentos Docentes de Vinculación Especial

Descuento % Docente % Universidad

Salud Valor Mensual delContrato * 4%

Valor Mensual delContrato * 8.5%

Pensión Valor Mensual delContrato * 4%

Valor Mensual delContrato * 8.5%

Fondo de Solidaridad Valor Mensual delContrato * 1%

Retefuente Valor total

Tomada de OFICINA ASESORA DE SISTEMAS, (OAS). Modelo de negocio Nómina deDocentes de Vinculación Especial, Primera Edición. OAS, 2013.p 4.

Otros descuentos:

Asociaciones: ADE, ASPU-UD,ASPO-VINES.

Sindicatos: SIPRUD.

Embargos: Juzgados.

Cooperativas: Seguros Colpatria, Medicina preparada, Cooproser,

Coefectivo, Canapro, Compensar, etc.

Universidad: descuento generado por préstamo de la Universidad para

cursos (ILUD).

Incapacidades: Valor generado por incapacidad generada por la EPS.

31

El valor de estos descuentos deben estar soportados con una solicitud por

parte del docente donde deberá autorizar la realización del mismo y lafirma a la cual se le consignarán los respectivos dineros.18

2. Honorarios: En este caso, se siguen los mismo lineamientos sin embargo los descuentos aplicados por la ley son los siguientes.

Tabla 7 Tabla de Impuestos

Impuesto Porcentaje

Retención en la Fuente Según la norma

ICA Reglamentación SecretariaDistrital de Hacienda.

Estampilla UD 1%

Estampilla Pro-adultoMayor

0.5%

Estampilla Pro-Cultura 0.5%

Tomada de OFICINA ASESORA DE SISTEMAS, (OAS). Modelo de negocio Nómina deDocentes de Vinculación Especial, Primera Edición. OAS, 2013.p 9.

La liquidación de docentes de vinculación especial comprende un conjunto ampliode variables y parámetros que en este capítulo no fueron tenidos en cuenta peroque se encuentran debidamente registrados en la legislación de la Universidad yen los documentos otorgados por la OAS.

5.3.4. Procesos de liquidación para contratistas en la Universidad Distrital

La Universidad Distrital puede celebrar contratos siempre y cuando estos serealicen bajo el marco legal vigente, en la resolución 014 del 5 de febrero de 2004se establece que la institución puede contratar mediante orden de prestación deservicios la prestación de servicios directos de servicios profesionales, técnicos o

18Ibíd., p. 4-8.

32

asistenciales, los pagos en dichos contratos se llevaran a cabo a través dehonorarios y se aumentaran en conformidad con el aumento anual salarial. En laresolución 049 de 2011, se ajusta el procedimiento para la contratación deórdenes de prestación de servicios (OPS) y se dictan otras disposiciones.19

Determinación de la asignación mensual

En la resolución de rectoría No.04 de 2006, se establecen los requisitos para larespectiva contratación y los honorarios respectivos, estos se presentan en lasiguiente tabla:

El cálculo se realizó teniendo en cuenta el Salario Mínimo Legal Vigente (SMLV)de 2015: 644.350 pesos.

Tabla 8 Honorarios Mensuales

PERFIL LABORAL HONORARIOSMENSUALES

VALORES 2015 (en pesos)

Servicios Profesionales Especializados 6.0 SMMLV 3.866.100

Servicios Profesionales 4.6 SMMLV 2.964.010

Servicios Asistenciales 3.0 SMMLV 1.933.050

Servicios Asistenciales 2.3 SMMLV 1.482.005

OFICINA ASESORA DE SISTEMAS, (OAS). Modelo de negocio Nómina de Contratistas,Primera Edición. OAS, 2013.p 4.

Aportes seguridad social y riesgos profesionales

Salud y Pensiones: el contratista deberá estar afiliado al Sistema General deSeguridad Social en Pensiones y al Sistema General de Seguridad Social enSalud, y el contratante (Universidad Distrital), debe verificar la afiliación y el pagode aportes. Los porcentajes de cotización se calcularan de acuerdo al ingresobase mensual devengado y corresponden al 12.5% (Salud) y 16% (Pensiones), sedebe tener en cuenta que no se puede cotizar sobre un base inferior a 1 SMLV nisuperior a 25 SMLV.

19OFICINA ASESORA DE SISTEMAS, (OAS). Modelo de negocio Nómina deContratistas, Primera Edición. OAS, 2013.p 2.

33

Riesgo: la cotización del trabador independiente se realizará teniendo en cuentael riesgo de la actividad que desempeña y el riesgo del centro de trabajo de laempresa contratista, la cotización no podrá ser inferior al 0.348% (en riesgo I) nisuperior al 8.7% (en riesgo V) del ingreso base de la cotización que correspondeal 40% del valor neto de los honorarios, se debe tener en cuenta que no se puedecotizar sobre un base inferior a 1 SMLV ni superior a 25 SMLV.20

Descuentos

En consideración con la ley vigente del país y la reglamentación interna de laUniversidad21, en este tipo de contratación se deben aplicar los siguientesdescuentos:

Tabla 9 Impuestos y Descuentos Contratistas

IMPUESTO PORCENTAJE

Retención en la Fuente Nueva Reforma Tributaria.

Retención de IVA (Si el trabajadorindependiente factura IVA)

16% del valor del IVA facturado.

Reteica Tabla de actividad comercial.

Estampilla UD 1%

Estampilla Proadulto Mayor 0.5%

Estampilla Procultura 0.5%

OFICINA ASESORA DE SISTEMAS, (OAS). Modelo de negocio Nómina de Contratistas,Primera Edición. OAS, 2013.p 6.

La tabla y la información presentada previamente contiene la descripción somerade los descuentos realizados en la liquidación de nómina de contratistas, en losdocumentos oficiales de reglamentación de la Universidad Distrital se encuentranestipulados los demás aspectos y consideraciones a tener en cuenta.

20Ibíd., p. 5-6.

21Ibíd., p. 6-10.

34

CAPÍTULO 6. METODOLOGÍA

El método a aplicar en este proyecto es el proceso de desarrollo OPENUP/OAS,que se encuentra debidamente aprobado en la Universidad Distrital FranciscoJosé de Caldas, mediante la Resolución de Rectoría número 461 de 2011.Esteproceso contempla un subproceso denominado “Gestión de Requerimientos yrequisitos”, el cual define el objetivo y las actividades que se deben llevar acaboen el proyecto.

El objetivo del subproceso de “Gestión de Requerimientos y requisitos” es“Recolectar, analizar, aprobar y seguir la evolución de los requerimientosfuncionales del cliente o el interesado y los requisitos de software a través de lavida del producto y/o servicio”.

El desarrollo del subproceso iniciaran una vez aprobado el proyecto y se llevara acabo en un plazo máximo de 6 meses, tiempo en el cual se realizaran reunionessemanalmente (los días sábado), en las cuales se evaluara el trabajo realizado enla semana, se asignaran nuevas tareas y se establecerán nuevas metas.

En consecuencia, se realizarán 24 reuniones, donde se llevará el control de lasiteraciones planeadas (cabe recordar que una iteración equivale a una semana).El proceso OPENUP define un conjunto de artefactos que se deben entregar amedida que avance el análisis y la gestión de los requerimientos y requisitos delos módulos establecidos (Hoja de vida y procedimientos de liquidación dedocentes de vinculación especial y contratistas). Dichos artefactos son:

Documento visión. Especificación de requisitos. Casos de uso. Glosario. Listas de Requerimientos. Actas de trabajo.

Los artefactos que se mencionan están ligados a un conjunto de actividades quese van a realizar iterativamente en el desarrollo del proyecto y que sonresponsabilidad explicita de los analistas, a continuación se describen dichasactividades:

35

Actividad 1: Definir o Ajustar Necesidad(s).Descripción: Una necesidad es una demanda que expresa una(s) persona(s),dependencia(s) o instancia(s) con respecto a una situación problemática y quepuede ser solucionada a través de una aplicación informática. Encargados: Analista e Interesados.Documento, entregable o artefacto: Solicitud de Necesidad.

Actividad 2: Elaboración o actualización de la lista maestra derequerimiento(s).Descripción: Un requerimiento es la descripción precisa y clara de unanecesidad funcional en términos de lo que debe hacer el sistema. Unanecesidad puede descomponerse en varios requerimientos dependiendo de lamanera como se haya definido.Encargados: Analista.Documento, entregable o artefacto: Lista Maestra de requerimientos.

Actividad 3: Elaboración y actualización del documento Visión.Descripción: Con base en las necesidades de los interesados, losrequerimientos y los requisitos de alto nivel definidos por el analista se planteala situación problemática y la posible solución informática para los interesados.Encargados: Analista.Documento, entregable o artefacto: Construcción del documento.

Actividad 4: Elaboración y actualización documento glosarioDescripción: A medida que se definen y ajustan las necesidades yrequerimientos de los interesados, se construye y unifican cierta terminologíaentre los interesados y el equipo de trabajo con el fin de que exista una buenacomunicación entre los mismos. Entregables: Analista e Interesados.Documento, entregable o artefacto: Glosario.

Actividad 5: Elaboración y actualización del documento “Especificación deRequisitos”Descripción: un requerimiento responde a una necesidad funcional delsistema, mientras que un requisito representa una necesidad técnica entérminos de usabilidad, confiabilidad, disponibilidad y seguridad del sistema.Encargados: Analista.Documento, entregable o artefacto: Especificación de requisitos.

36

Actividad 6: Aprobación de la VisiónDescripción: Luego de una revisión de la visión por parte de los interesados,estos evalúan si aprueba o no la definición o solución al problema planteado,en caso de que no se apruebe se debe ajustar el documento yconsecuentemente las necesidades planteadas.Encargados: Interesados.Documento, entregable o artefacto: Acta.

Actividad 7: Aprobación de los RequerimientosDescripción: Al igual que con el documento visión, los interesados deben darsu aval cuando se define un requerimiento y en caso de que no se apruebendeberán ser ajustados para su futura aprobación.Encargados: InteresadosDocumento, entregable o artefacto: Acta

Actividad 8: Elaborar modelos, casos y especificaciones de usoDescripción: Con base en los requerimientos aprobados, se procede adetallarlo mediante diagramas, casos y especificaciones de casos de uso.Encargados: Analistas Documento, entregable o artefacto: Modelo de casos de uso.Caso de uso de alto nivel.Especificación de caso de uso.

Actividad 9: Control de Cambios.Descripción: A medida que surgen los cambios propios del proceso dedesarrollo (Análisis, diseño, desarrollo, despliegue), es necesario ajustar ladocumentación propia de la gestión de requerimientos y requisitos, como lavisión, el glosario, los casos de uso de alto nivel, las especificación derequisitos y lista maestra de requerimientos.Encargado: AnalistaDocumento, entregable o artefacto:Visión.Lista Maestra de Requerimientos.Especificación de requisitos.Modelo, caso de uso de alto nivel y especificaciones de casos de uso.

De acuerdo a los alcances definidos, el proyecto tiene como fin realizar las 3primeras fases de la metodología OPENUP (Inicio, Elaboración y Construcción),

37

en las cuales se deben realizar iterativamente las actividades descritas y losartefactos ligados a ellas. En la imagen que se presenta a continuación sevisualiza la metodología de trabajo establecida por OPENUP para cada uno de losroles y en cada una de las fases, es importante recalcar que el rol que sedesempeñara es el de Analista en el subproceso de “Gestión de Requerimientos yRequisitos”

Tomada

de Guía Rápida Proceso de Desarrollo OPENUP/OAS. Primera Edición. Bogotá, 2011. p. 4.

Las guías de respaldo para realizar las actividades están definidas en eldocumento oficial del proceso de desarrollo y son:

● Los requerimientos y requisitos.● Definición de requisitos.● Técnicas de captura de requerimientos y requisitos.● Errores comunes en la definición de los requerimientos y requisitos.● Construcción de casos de uso.● Construcción de los modelos de caso de uso.● Construcción del documento “Especificación de Requisitos de Soporte”

38

Ilustración 3 Metodología de Trabajo

● Construcción del glosario.

La figura que se muestra a continuación resume la metodología del subproceso de“gestión de requerimientos y requisitos”.

Ilustración 4 Metodología Subproceso de "Gestión de Requerimientos y Requisitos"

Tomada de Capítulo 6 "Gestión de Requerimientos y Requisitos", Proceso de DesarrolloOPENUP/OAS. Primera Edición. Bogotá, 2011. p. 4.

39

CAPÍTULO 7. DESARROLLO

Siguiendo la metodología OPEN/UP definida por la Oficina Asesora de Sistemas(OAS) se llevó a cabo el desarrollo de la versión inicial del sistema de gestión deNómina de la Universidad Distrital, denominado “TITAN”. En el proyectoparticiparon 9 pasantes de ingeniería de sistemas divididos en 3 grupos de lasiguiente manera:

Gestión de Requerimientos (3 pasantes) Arquitectura (2 pasantes) Desarrollo (4 pasantes)

Este proyecto se desarrolló en el área de la gestión de requerimientos, siguiendoestrictamente los lineamientos establecidos en la metodología ya mencionada. Deacuerdo con lo proyectado en las fases iniciales se realizaron 24 iteracionessemanales, respaldadas por reuniones que facilitaban la retroalimentación de losavances en el proyecto y el control y seguimiento del mismo.

El subproceso de gestión de requerimientos está debidamente respaldado en elrepositorio documental de Google Drive a través de los artefactos establecidos, loscuales son:

Documento visión. Especificación de requisitos. Casos de uso. Glosario. Listas de Requerimientos. Actas de trabajo.

Las primeras iteraciones del ciclo se destinaron a la capacitación y documentacióndel analista en lo que respecta al modelo de negocio genérico de una nómina,manejo y estándar BPMN (Business Process Model and Notation) , procesos detrabajo asociados a la metodología utilizada y procesos internos propios utilizadosen la OAS para llevar a cabo el seguimiento de los pasantes, los formatos pre-establecidos en la oficina y en general las reglas condiciones y demás parámetrosque un entorno laboral presenta.

En el caso particular del análisis, pocos días después de iniciada la pasantía seempezó la generación de diagramas BPMN que posteriormente guiaron el proceso

40

de desarrollo de especificaciones y diagramas de casos de uso, transversalmentese realizaba el levantamiento de actas de inicio, documento de visión, actas detrabajo, glosario entre otros. A medida que se obtenían los primeros productos,estos se retroalimentaban y compartían con los arquitectos quienes realizaban lamisma tarea con los desarrolladores, estos últimos se encargaban de plasmar ladocumentación en producto. Este modelo de trabajo se utilizó durante todo elproyecto y fue parte fundamental del éxito de la primera versión de TITAN.

En resumen el flujo de trabajo implementado se ilustra en la siguiente imagen.

Ilustración 5 Flujo de Trabajo Proyecto TITAN

Adicionalmente se llevaron documentos que respaldan y facilitan la gestión delplan de trabajo y los controles de cambios, la imágenes 6 y 7 muestran laestructura de estos artefactos respectivamente.

41

En los anexos del proyecto se adjuntan los demás documentos soportes querespaldan el trabajo realizado a lo largo del periodo de pasantía como lo son elacta de inicio, las especificaciones de caso de uso, las actas de trabajo, glosario,etc. Cabe recordar que todos estos elementos se encuentran en google drivedebidamente respaldados.

Ilustración 6 Artefacto Plan General de Ejecución del Proyecto

Tomada de: Repositorio Proyecto TITAN Oficina Asesora de Sistemas (OAS)

Ilustración 7 Artefacto de Control de Cambios

42


7.1. Modelo De Gestión De Nómina

Un sistema de gestión de nómina aborda un sinnúmero de procesos condiferentes grados de complejidad que se ciñen a dos factores en particular, por unlado el modelo legal establecido por los entes estatales o gubernamentales dondeel sistema se desplegará y un modelo de negocio que, de acuerdo al tamaño de laorganización, condiciona en mayor o menor medida la tareas que se debenrealizar. Para el caso de la Universidad Distrital, la nómina representa un reto paratodo sistema de software, ya que dada la diversidad de reglas que la componen,basta con observar el número de vinculaciones que la institución debe liquidarmensualmente (Docentes de planta, Docentes de vinculación especial horacátedra, Docentes de vinculación especial Honorarios, Pensionados, Contratistas,entre otros).

Adicional a esto, se pueden presentar clasificaciones adicionales que alteran elproceso normal del cálculo de nómina como la división de los algunosadministrativos y docentes en Empleados públicos o Trabajadores públicos,categorización que agrega más relevancia y dificultad al sistema.

Sin embargo TITAN se quiso estructurar como un sistema genérico que apliquepara la nómina de cualquier modelo de negocio y que adicionalmente otorgueherramientas para el manejo de algunos procesos que pueden ser complejos, por

43

ende, la versión inicial del sistema se desligo de algunas de las condicionesimpuestas por el modelo de negocio de la Universidad. Esto, sin duda, facilitó elavance dado el plazo que la pasantía establece.

En primera instancia, se desarrolló un modelo de dominio que expone losprincipales módulos del sistema y las relaciones entre los mismos, este diagramapermite transmitir a los interesados de manera acertada la idea visualizada por losanalistas.

En el diagrama se presentan a grandes rasgos los componentes del sistema. Esposible apreciar el módulo de personas o de vinculación los cuales, como bienrefieren sus nombres, se desarrollaron para soportar el proceso de vinculación depersonas naturales y jurídicas al sistema.

Por otro lado, encontramos los módulos de conceptos, parámetros de liquidación,novedades, pre liquidación, liquidación, asociación de conceptos, etc.,componentes que permiten llevar a cabo el registro, el cálculo y la posterior preliquidación y liquidación de los valores que cada uno de los empleados devengano deduce dentro del sistema. Adicional a ellos se encuentran módulos comoparámetros, leyes o reporteador que complementan el proceso previamentemencionado y que serán detallados en el siguiente capítulo.

Ilustración 8 Modelo de Dominio

44


7.2. Modelo BPMN - Gestión De Nómina

Los diagramas BPMN son una notación gráfica que describe la lógica de los pasosde un proceso de negocio. Estos diagramas permiten comprender y coordinar lasecuencia de los procesos y los mensajes que fluyen entre los participantes de lasdiferentes actividades. En consideración con lo descrito los BPMN presentaron lasbases para el modelamiento del sistema de gestión de nómina.

Es de suma importancia comprender a través de estos el funcionamiento generalde la nómina y adicionalmente brindar a terceros e involucrados en el proyectouna descripción gráfica sencilla y precisa de las actividades, flujos y procesos quese involucran en TITAN.

En la nómina, antes de llevar a cabo el cálculo, pre liquidación y liquidación de losvalores que lo empleados devengan y deducen, es importante realizar lavinculación de estos últimos. Para ello en TITAN se contempló y desarrollo un

45

módulo que gestiona la información de las personas naturales y jurídicas queparticipan de una u otra manera en la liquidación de la nómina.

Ilustración 9 Diagrama BPM (Gestión Persona)


En el diagrama anterior se puede apreciar el flujo de información y las actividadesque se realizan cuando se va a registrar una persona en el sistema deinformación, para ello un ordenador del gasto realiza la solicitud de creación depersona, dicha solicitud se puede modificar, inactivar y consultar. Posteriormentela dependencia de contabilidad se encarga de aprobar la solicitud.

Si cumple con los requisitos establecidos, se asignar el estado modificable a lasolicitud con el fin de que el ordenador del gasto realice actualizaciones sobre lasolicitud y esta sea evaluada de nuevo o rechazarla en caso de no ser viable.

Dentro del proceso de registro de persona natural se realiza la gestión de la hojade vida, que implica el registro de la información básica, académica, laboral, etc.Este proceso se pensó inicialmente para personas naturales y jurídicas, sinembargo por cuestión de tiempo se determinó enfocar los esfuerzos solo para laspersonas naturales.

Cuando la persona es registrada correctamente en el sistema, el paso a seguir esrealizar la vinculación de la misma a la nómina. Teniendo en cuenta la variedad devinculaciones que se pueden presentar en una organización, es necesario asociar

46

la persona a uno o más tipos de vinculación. El tipo de vinculación es fundamentalen el momento de liquidar una nómina, pues este parametriza las característicasde liquidación de un grupo de personas y facilita llevar a cabo el proceso. Eldiagrama BPMN que se presenta a continuación ilustra el proceso de vinculaciónde personas naturales.

Ilustración 10 Diagrama BPM (Gestión Vinculación Persona Natural)


El BPMN permite apreciar los detalles del proceso de vinculación de personanatural, el cual implica otros subprocesos como registrar persona natural oregistrar tipo de vinculación. También se exponen los pasos para llevar a cabo lavinculación, la selección de la persona y el tipo de vinculación, el ingreso de lainformación propia de cada vinculación y la gestión sobre las vinculaciones.

Como se ha podido evidenciar, la cantidad de información que se maneja esconsiderable y a su vez parametrizable, por lo que se hizo necesario la gestión deparámetros, pensando no solo en el modelo de negocio también en la facilidadque esto otorgaría al futuro sistema de información.

Ilustración 11 Diagrama BPM (Gestión de Parámetros)

47


Este proceso sobresale por su simplicidad e ilustra concretamente el flujo deinformación y las actividades involucradas en proceso (entiéndase comoparámetro aquella información que complementa uno o más módulos y la cual espertinente dejar gestionable a nivel de usuario). Dentro de este módulo secontemplan la gestión de leyes, nóminas, tipos de vinculación, etc. procesos baseen el core del sistema cálculo de conceptos, pre liquidación y liquidación.

Los conceptos son aquellos valores que rigen legalmente una entidad estatal através de la legislación o una organización dentro de sus políticas internas y quese reflejan en las deducciones y devengos de una nómina, realizar el cálculo deestos conceptos es uno de los procesos principales en la nómina.

Ilustración 12 Diagrama BPM (Gestión de Conceptos)


48

Un concepto no se puede tomar a la ligera, la anterior ilustración muestra lacomplejidad que puede llegar a implicar la definición y gestión de un concepto, unconcepto se define a través de una fórmula compuesta por parámetros deliquidación, condiciones, otros conceptos y variables.

Dentro del modelo de negocio se presentan conceptos de dos naturaleza, los queson fijos, determinados por una ley y que periódicamente se deben liquidar a todoslos empleados y tipos de vinculación de la empresa y por otro lado los que actúancomo novedades que pueden liquidarse a uno o a un grupo pero no a todos losempleados. En el primer de los casos tenemos conceptos como: salario básico,concepto por salud o por pensión, auxilio de transporte, etc. En el segundo casoconceptos como incapacidades, horas extra, ausentismo, préstamos, etc.

La diferencia entre estos dos conceptos debe ser clara, lo cual nos llevó a desligarel cálculo de los conceptos de tipo uno expuesto en el diagrama BMPN (figura 12)y los del tipo dos (figura 13), los cuales no serán más denominados conceptossino novedades.

Ilustración 13 Diagrama BPM (Gestión de Novedades 1)


Las novedades, como ya se mencionó previamente, tienen un comportamientoparticular. La ilustración 13 nos muestra el proceso que se realiza para registrar lainformación básica, la información particular y la información de cálculo de lanovedad. Sin embargo, en este no se contempla la asociación de la novedad con

49

el o los empleados, este último proceso de negocio se presenta en el siguientediagrama.

Ilustración 14 Diagrama BPM (Gestión de Novedades 2)


En esta ilustración se observa el paso a paso para vincular una persona a unanovedad y se evidencia dentro del mismo el sub-proceso presentando en eldiagrama anterior. A grandes rasgos, se define y registra la información y laestructura de la novedad inicialmente en el proceso denominado “Generación deNovedades”.

Posteriormente en “Gestión de Novedades” se relaciona la novedad con elempleado o el grupo de empleados y se registra la información particular de larelación novedad-empleado, procedimiento que se expondrá de manera detalladaen capítulos posteriores.

La vinculación de los empleados a la nómina, la gestión de parámetros, conceptosy novedades son el principio del proceso de liquidación, el siguiente paso es la preliquidación en esta se define qué novedades y conceptos se liquidarán, a quepersonas o grupos de personas (tipos de vinculación, dependencias, etc.) y en quéperiodo se realizará.

50

Ilustración 15 Diagrama BPM (Pre liquidación)


La pre liquidación es el proceso más importante en lo que respecta a la nómina,pus en este se involucran todos los procesos mencionados anteriormente y tienecomo fin presentar un resumen de los valores que las personas seleccionadosdevengan y deducen en determinado periodo de tiempo; el cálculo de la nóminaes el resultado obtenido. Sin embargo no el definitivo, dado que es necesariorealizar una inspección de los valores obtenidos y del conglomerado deinformación final presentado, hasta que el usuario no lo considere pertinente unapre liquidación no se transforma en liquidación.

El administrador de nómina puede llevar a cabo varias pre liquidaciones, condiferentes conceptos, diferentes personas y en diferentes periodos de tiempo,cuando estas estén debidamente calculadas el mismo usuario se encarga deregistrar un liquidación con base en el registro previo de una pre liquidación.

51

Ilustración 16 Diagrama BPM (Liquidación)


El diagrama BPM de liquidación es simple, solo se verifica que la pre liquidaciónesté registrada y se genera la liquidación. La liquidación representa el paso finaldel cálculo de la nómina, pero para realizar la presentación de los datos a unusuario es necesario determinar formatos o plantillas que estandaricen yparametricen los resultados de la liquidación, en consecuencia es necesarioconsiderar los procesos que se involucran en la generación de plantillas,certificados y reportes.

La gestión de reportes se dividió en dos procesos: gestión de plantillas y gestiónde reportes. En el primero se realiza la gestión de las plantillas, se define qué tipode plantilla es y su respectiva estructura. En el segundo se relaciona la plantillacon la persona o con el grupo de personas del cual se obtendrá el reporte, esto seexplicara al detalle en capítulos posteriores.

Ilustración 17 Diagrama BPM (Gestión de Plantilla)


52

La generación de plantillas permite seleccionar entre certificado o tabla. En amboscasos existe una información general, en donde cada una tiene un fin diferente,por un lado los certificados permiten la generación de cartas o certificacionesdonde el usuario que define la plantilla tiene la opción de escoger e incluirinformación de una persona o su vinculación.

Por otro lado, encontramos las tablas, que son reportes donde se puedeseleccionar que conceptos o novedades, qué información de los conceptos o lasnovedades, como realizar la agrupación de datos en el reporte, suma desubtotales, la información de la vinculación, etc. Este último ofrece dinamismo enla definición de reportes de liquidación de nómina.

Ilustración 18 Diagrama BPM (Gestión de Plantilla)


La gestión de reportes incluye como sub proceso la gestión de plantillas y tienecomo fin la asociación de un reporte o certificado a una persona o a un grupo depersonas, el anterior BPM ilustra esta descripción.

7.3. Requerimientos No Funcionales

La metodología en el subproceso referente a la ingeniería de requerimientoscontempla el levantamiento de requisitos y requerimientos funcionales y nofuncionales del sistema, respaldados por listas maestras de requerimientos quelos analistas están encargados de realizar. Para el caso de los requerimientos nofuncionales, la tabla que se presenta a continuación ilustra los requerimientos deesta naturaleza identificados.

53

Tabla 10 Requerimientos No Funcionales del Sistema

TIPO DE REQUERIMIENTO DESCRIPCIÓN

AUDITORÍA Es necesario llevar un registro de los cambios ymovimientos que realicen los usuarios dentro delsistema de gestión de nómina, considerando el tipode información y los procesos que se llevan a caboes pertinente llevar una control de auditoría queregistre el acceso y la alteración de los datos quecada uno de los usuarios del sistema lleve a caboen todos los módulos de este.

SEGURIDAD La información que se presente y sea visible parael cliente tiene que estar debidamente oculta oencriptada, la información de la nómina no se debetomar a la ligera y su indebida exposición podríatraer graves consecuencias. Se debeadicionalmente validar la información registradapor el usuario en el lado del servidor esto con el finde evitar ataques a la seguridad como la inyecciónsql.

DESEMPEÑO En los procesos de liquidación de nóminaparticularmente, se debe optar por estructuras dedatos y prácticas de desarrollo que optimicen eldesempeño de la aplicación en cálculos dondepueden involucrarse 20000 registros o más.

DISPONIBILIDAD Se debe proyectar un sistema estable tanto a nivelde software como hardware, que esté disponible24/7 que no dificulte ni entorpezca los procesos denómina.

ALMACENAMIENTO DEINFORMACIÓN

Es importante contar con un motor de base dedatos robusto que ofrezca las característicasnecesarias para el buen funcionamiento delsistema.

USABILIDAD Siempre pensar en el usuario antes, los casos deuso que se exponen en los requerimientosfuncionales, deben ser siempre respaldados en lo

54

que respecta a usabilidad, el sistema buscafacilitar y no dificultar los procesos de nómina.

OPEN-SOURCE Cualquier desarrollo, entorno o programa que seutilice debe estar libre de licencias, es decir debeser código estrictamente abierto.

7.4. Requerimientos Funcionales Identificados

Con los diagramas BPM establecidos y la comprensión del flujo de los pasos y lainformación de los procesos del modelo de negocio, se inició la etapa de gestiónde requerimientos. El grupo de analistas en compañía con los gestores delproyecto identificaron los requerimientos funcionales del sistema, desde lasolicitud de vinculación de una persona natural o jurídica hasta los reportes finalesde la liquidación de nómina. A lo largo de esta labor se definieron lo módulospadres de las funcionalidades que los requerimientos describen, dichos módulosson:

Módulo Gestión Personas: Este módulo comprende las funcionalidadesreferentes a la gestión de personas naturales y jurídicas. La solicitud deregistros de estas últimas por parte de los ordenadores del gasto, suevaluación y finalmente su aceptación o rechazo por parte de lasdependencias pertinentes.

Módulo Novedades - Funcionario: Este módulo, como su nombre loindica, contiene las funcionalidades relacionadas con la gestión denovedades de información de funcionarios, está ligado a la gestión de hojade vida de los empleados vinculados al sistema de nómina.

Módulo de Parámetros: Lo comprenden todos los parámetros utilizadosen el sistema de información y su respectiva gestión, es de vitalimportancia en el funcionamiento de TITAN. Administra informaciónsencilla pero fundamental para el funcionamiento de los demás módulos.

Módulo de Novedades: En este se encuentran las funcionalidades quegestionan las novedades del sistema a través del generador de novedadesy el sub módulo de gestión de novedades.

Módulo de Liquidación: Junto con novedades representan los módulosmás importantes del sistema, en este se hallan las funcionalidades quecomprenden la liquidación de la nómina como lo son el cálculo deconceptos y la gestión de pre liquidaciones y liquidaciones.

Módulo de Reportes: Se diseñó para realizar la gestión de reportes,certificados e informes; lo submódulos que lo comprenden son:Gestionador de Plantillas y Gestionador de Reportes.

55

A continuación se presentan los requerimientos funcionales identificados, surespectivo módulo padre y una breve descripción. Este listado maestro presentatodos los requerimientos levantados para el desarrollo del sistema de información.Sin embargo, en este trabajo se realizó el análisis y el desarrollo de diagramas yespecificaciones de casos de uso de algunos de los de los expuestos acontinuación y lo cuales particularmente se detallarán posteriormente en estedocumento.

Tabla 11 Listado Maestro de Requerimientos Funcionales

REQUERIMIENTO MÓDULO DESCRIPCIÓN

R1: Solicitud Registro Persona Natural.

Gestión Persona Registro de la solicitud de registrode persona natural.

R2: Consultar Solicitud Registro Persona Natural.

Gestión Persona Consulta de la solicitud de registro de persona natural-

R3: Modificar Solicitud Registro Persona Natural.

Gestión Persona Actualización de información de la solicitud de registro de la persona natural.

R4: Inactivar Solicitud Registro Persona Natural.

Gestión Persona Cambio de estado de la solicitud de registro de persona natural a inactiva.

R5: Solicitud Registro Persona Jurídica.

Gestión Persona Registro de la solicitud de registrode persona Jurídica.

R6: Consultar Solicitud Registro Persona Jurídica.

Gestión Persona Consulta de la solicitud de registro de persona Jurídica

R7: Modificar Solicitud Registro Persona Jurídica.

Gestión Persona Actualización de información de la solicitud de registro de la persona Jurídica.

R4: Inactivar Solicitud Registro Persona.

Cambio de estado de la solicitud de registro de persona Jurídica a inactiva.

R8: Aprobar Solicitud. Gestión Persona Proceso para la revisión y aprobación de las solicitudes de

56

registro de personas naturales o jurídicas.

R9: Consultar Aprobaciones.

Gestión Persona Funcionalidad que permite consultar las solicitudes aprobadas.

R10: Modificar Aprobaciones.

Gestión Persona Actualización de datos e información de las solicitudes aprobadas.

R11: Registrar Hoja de Vida.

Novedades-Funcionario

Lleva a cabo el registro de hoja de vida de las personas que ya han sido vinculadas al sistema como terceros a través de las solicitudes.

R12: Modificar Hoja de Vida.


Actualización de información y datos de la hoja de vida de un tercero o vinculado.

R13: Consultar Hoja de Vida.


Consulta de hoja de vida de terceros o vinculados.

R14: Registrar Tipo de Vinculación.

Parámetros Permite el registro de tipos de vinculación al sistema de información.

R15: Modificar Tipo de Vinculación.

Parámetros Actualización de información de los tipos de vinculación.

R16: Inactivar Tipo de Vinculación.

Parámetros Cambio de estado de los tipos de vinculación a inactivos.

R17: Consultar Tipo de Vinculación.

Parámetros Consulta de tipos de vinculación.

R18: Registrar Nómina. Parámetros Permite el registro de nóminas.

R19: Modificar Nómina. Parámetros Actualización de información de las nóminas.

R20: Inactivar Nómina. Parámetros Cambio de estado de las nóminas

57

a inactivo.

R21: Consultar Nómina. Parámetros Consulta de nóminas.

R22: Registrar Parámetrosde Liquidación.

Parámetros Lleva a cabo el proceso de registro de parámetros de liquidación que se involucrarán enel cálculo de conceptos y novedades.

R23: Modificar Parámetrosde Liquidación.

Parámetros Actualización de información de los parámetros de liquidación.

R24: Inactivar Parámetros de Liquidación.

Parámetros Cambio de estado de los parámetros de liquidación a inactivos.

R25: Consultar Parámetros de Liquidación.

Parámetros Consulta de parámetros de liquidación.

R26: Registrar Ley, Decreto o Norma.

Parámetros Lleva a cabo el proceso de registro de leyes, decretos o normas que se involucran de manera transversal en varios procesos de del sistema de nómina.

R27: Modificar Ley, Decreto o Norma.

Parámetros Actualización de información de las leyes, decretos o normas.

R28: Inactivar Ley, Decreto o Norma.

Parámetros Cambio de estado de las leyes, decretos o normas a inactivas.

R29: Consultar Ley, Decreto o Norma.

Parámetros Consulta de las leyes, decretos o normas.

R30: Registrar Fondo de Pensión.

Parámetros Registro de fondo de pensiones.

R31: Modificar Fondo de Pensión.

Parámetros Actualización de información de fondos de pensión.

58

R32: Inactivar Fondo de Pensión.

Parámetros Cambio de estado de fondos de pensiones a inactivos.

R33: Consultar Fondo de Pensión.

Parámetros Consulta de fondos de pensiones.

R34: Registrar EPS Parámetros Registro de EPS.

R35: Modificar EPS Parámetros Actualización de información de EPS.

R36: Inactivar EPS Parámetros Cambio de estado de EPS a inactivo.

R37: Consultar EPS Parámetros Consulta de EPS.

R38: Registrar ActividadesEconómicas

Parámetros Registro de Actividades Económicas.

R39: Modificar ActividadesEconómicas

Parámetros Actualización de información de Actividades Económicas.

R40: Inactivar Actividades Económicas

Parámetros Cambio de estado de Actividades Económicas a inactivas.

R41: Consultar Actividades Económicas

Parámetros Consulta de Actividades Económicas.

Registrar Acto Administrativo

Parámetros Registro de Actos Administrativos.

Modificar Acto Administrativo

Parámetros Actualización de información de Actos Administrativos.

Inactivar Acto Administrativo

Parámetros Cambio de estado de Actos Administrativos a inactivos.

Consultar Acto Administrativo

Parámetros Consulta de Actos Administrativos.

R42: Registrar Caja de Compensación

Parámetros Registro de Cajas de Compensación.

R43: Modificar Caja de Parámetros Actualización de información de

59

Compensación Cajas de Compensación.

R44: Inactivar Caja de Compensación

Parámetros Cambio de estado de Cajas de Compensación a inactivas.

R45: Consultar Caja de Compensación

Parámetros Consulta de Cajas de Compensación.

R46: Registrar ARL Parámetros Registro de ARL.

R47: Modificar ARL Parámetros Actualización de información de ARL.

R48: Inactivar ARL Parámetros Cambio de estado de ARL a inactivo.

R: Consultar ARL Consulta de ARL.

R49: Registrar Banco Parámetros Registro de Banco.

R50: Modificar Banco Parámetros Actualización de información de Banco.

R51: Inactivar Banco Parámetros Cambio de estado de Banco a inactivo.

R52: Consultar Banco Parámetros Consulta de Banco.

R53: Registrar Cargo Parámetros Registro de Cargo.

R54: Modificar Cargo Parámetros Actualización de información de Cargo.

R55: Inactivar Cargo Parámetros Cambio de estado de Cargo a inactivo.

R56: Consultar Cargo Parámetros Consulta de Cargo.

R57: Registrar Nivel de Cargo

Parámetros Registro de Nivel de Cargo.

R58: Modificar Nivel de Cargo

Parámetros Actualización de información de Nivel de Cargo.

R59: Inactivar Nivel de Parámetros Cambio de estado de Nivel de

60

Cargo Cargo a inactivo.

R60: Consultar Nivel de Cargo

Parámetros Consulta de Nivel de Cargo.

R61: Registrar VinculaciónPersona Natural

Vinculación Persona

Proceso que lleva a cabo la vinculación de una persona natural a través de un tipo de vinculación al sistema de nómina.

R62: Modificar VinculaciónPersona Natural


Actualización de información y datos de la vinculación de la persona natural.

R63: Inactivar Vinculación Persona Natural


Cambio de estado de la vinculación de una persona natural a inactiva.

R64: Consultar Vinculación Persona Natural


Consulta de una o varias vinculaciones de personas naturales.

R65: Carga Masiva Vinculación Persona Natural


Funcionalidad que permite el registro masivo de vinculaciones.

R66: Registrar Traslado Novedades- Traslados y Retiros

Registro de un traslado y su respectiva información.

R67: Consultar Traslado Novedades- Traslados y Retiros

Consulta de uno o varios traslados.

R68: Inactivar Traslado Novedades- Traslados y Retiros

Cambio de estado de un traslado a inactivo.

R69: Registrar Retiro Novedades- Traslados y Retiros

Registro de un retiro y su respectiva información.

R70: Consultar Retiro Novedades- Consulta de uno o varios retiros.

61

Traslados y Retiros

R71: Inactivar Retiro Novedades- Traslados y Retiros

Cambio de estado de un retiro a inactivo.

R72: Registrar Concepto de Nómina

Liquidación Lleva a cabo el registro de la información básica, la fórmula y las condiciones de un concepto.

R73: Modificar Concepto de Nómina

Liquidación Actualización de la información básica, formula o condiciones de un concepto.

R74: Inactivar Concepto de Nómina

Liquidación Cambio de estado de un concepto a inactivo.

R75: Consultar Concepto de Nómina

Liquidación Consulta de un conceptos y sus respectiva información.

R76: Registrar Categoría de Concepto

Liquidación Registro de categoría de concepto.

R77: Modificar Categoría de Concepto

Liquidación Actualización de la información de una categoría de concepto.

R78: Inactivar Categoría de Concepto

Liquidación Cambio de estado de una categoría de concepto a inactiva.

R79: Consultar Categoría de Concepto

Liquidación Consulta de una o varias categorías de concepto.

R80: Registrar Categoría de Parámetro de Liquidación

Parámetros Registro de categoría de parámetro de liquidación.

R81: Modificar Categoría de Parámetro de Liquidación

Parámetros Actualización de la información de una categoría de parámetro deliquidación.

R82: Inactivar Categoría de Parámetro de

Parámetros Cambio de estado de una categoría de parámetro de

62

Liquidación liquidación a inactiva.

R83: Consultar Categoría de Parámetro de Liquidación

Parámetros Consulta de una o varias categorías de parámetro de liquidación.

R84: Registrar Novedad (Generador de Novedades)

Novedades Realizar el registro la información básica, el formulario, la fórmula y las condiciones de un novedad.

R85: Modificar Novedad (Generador de Novedades)

Novedades Actualización de la información básica, el formulario, la fórmula y las condiciones de un novedad.

R86: Inactivar Novedad (Generador de Novedades)

Novedades Cambio de estado de una novedad a inactiva.

R87: Consultar Novedad (Generador de Novedades)

Novedades Consulta de una o varias novedades.

R88: Registrar Novedad (Gestión de Novedades)

Novedades Registro de novedad que asocia la persona con la novedad previamente creada.

R89: Modificar Novedad (Gestión de Novedades)

Novedades Actualización de registro de asociación de novedad y persona.

R90: Inactivar Novedad(Gestión de Novedades)

Novedades Inactivación de la asociación entre novedad y persona.

R91: Consultar Novedad (Gestión de Novedades)

Novedades Consulta de una o varias novedades asociadas.

Asociar concepto

Conceptos Realiza la vinculación entre los conceptos nóminas y tipos de vinculación.

Modificar conceptos Conceptos Actualiza la vinculación de los

63

asociados conceptos con las nóminas.

Consultar conceptos asociados

Conceptos Consulta de conceptos asociadosa nómina.

Inactivar conceptos asociados

Conceptos Cambio de estado de los conceptos asociados.

R92: Registrar Pre liquidación

Liquidación El proceso de registro de pre liquidación implica el cálculo de los conceptos definidos y asociados a las personas a la cuales se les calculará la nómina.

R93: Modificar Pre liquidación

Liquidación Actualización de la información que permite llevar a cabo el cálculo.

R94: Consultar Pre liquidación

Liquidación Consulta de una o varias pre liquidaciones.

R95: Registrar Liquidación Liquidación Lleva a cabo el registro de una liquidación a través del cálculo previo de una pre liquidación.

R96: Modificar Estado Liquidación

Liquidación Cambia el estado de una liquidación de pendiente ha pagada o viceversa.

R97: Consultar Liquidación

Liquidación Consulta de una o varias liquidaciones.

R98: Registrar Plantilla Reportes Registro de estructura de plantillas (Certificados y ReportesGenerales).

R99: Modificar Plantilla Reportes Actualización de la estructura de plantillas (Certificados y ReportesGenerales).

R100: Inactivar Plantilla Reportes Cambio de estado a inactivo de laplantilla.

64

R101: Consultar Plantilla Reportes Consulta de una o varias plantilla.

R102: Registrar Reporte Reportes Realizar la generación de reportes a través de la vinculación entre las plantillas y elo los empleados.

R103: Consultar Reporte Reportes Consultar los reportes realizados.

7.5. Sistema De Gestión De Nómina (TITAN-Descripción por Módulo)

A lo largo del anterior y el presente capítulo se han discutido los detalles generalesdel sistema de gestión de nómina TITAN, teniendo en cuenta la tabla derequerimientos presentada previamente se explicaran y detallaran por módulo losrequerimientos y casos de uso en los cuales se trabajó a lo largo del periodo de lapasantía y se realizará un descripción más detallada de los módulos del sistemade información con el objetivo de comprender lo que hasta este punto se hadescrito y el trabajo realizado dentro del proyecto.

7.5.1. Módulo: Parámetros Del Sistema

Dentro de la mayoría de los sistemas de información es común destinar ciertasfuncionalidades a la gestión de los parámetros, dependiendo del modelo denegocio estos módulos pueden llegar a tener mayor o menor relevancia.Particularmente, y teniendo en cuenta las características del modelo de negocio,en TITAN se diseña un módulo padre destinado a gestionar todos los parámetrosque el sistema de nómina necesite para su correcto funcionamiento.

Llevar a cabo la gestión de una nómina no es un trabajo fácil, no solo por lacomplejidad en la lógica o los cálculos matemáticos, sino por la cantidad deinformación que se debe administrar.

En el proceso de registro de una persona natural o jurídica al sistema deinformación se debe registrar cierta información como actividades económicas,EPS, caja de compensación, bancos, cargos, etc. Todos estos datos requieren nosolo su registro si no su debida gestión.

En consecuencia, es pertinente crear un módulo para que los usuarios de lanómina registren, actualice y modifique dichos parámetros dentro del sistema, loque otorga flexibilidad y dinamismo en el manejo de este tipo de información. Pero

65

los parámetros no solo se limitan a información básica de una vinculación tambiénestán presentes en los procesos de liquidación o gestión de conceptos ynovedades.

Las leyes en una nómina son de vital importancia dada la naturaleza de losprocesos que se pueden llevar a cabo en el cálculo de una liquidación,Normalmente dichos cálculos están regulados por legislaciones nacionales,gubernamentales, estatales, etc. e incluso decretos propios de una determinadaorganización

Éstas leyes también aplican a procesos de vinculación y para el caso de TITAN segestionan como parámetros del sistema. Algunos ejemplos adicionales son losactos administrativos, las ARLs, entro otros.

Para el módulo de gestión de parámetros se trabajó en los siguientes submódulos:

Submódulo Gestión de Actividades Económicas: Las actividades económicasson los procesos mediante los cuales se crean los bienes y servicios a partir defactores de producción que satisfacen las necesidades de los consumidores. Elobjetivo de este submódulo es realizar la gestión de la información de lasactividades económicas permitir su inserción, actualización y cambio de estados22.

Ilustración 19 Diagrama de Caso Uso (Parámetro Actividades Económicas)

22[Citado el 02 de Junio de 2016] Disponible en<http://www.actividadeseconomicas.org/2012/05/que-son-las-actividades-economicas.html/ >.

66


Submódulo Gestión de Fondos de Pensión: Los planes pensionales son underecho fundamental de todo empleado, establecido y regulado legalmente por lasinstituciones pertinentes. Para poder llevar a cabo la liquidación acorde con loestablecido en la legislación pensional es necesario realizar la gestión de lasentidades privadas y/o públicas que se encarga administrar este tipo de planes.Para ello, se desarrolló el submódulo de parámetros de fondos pensionales, elcual incluye las funcionalidades de registrar, modificar consultar e inactivar.

Ilustración 20 Diagrama de Caso Uso (Parámetro Fondo de Pensiones)

67


Submódulo de Gestión de Tipos de Vinculación: Cuando una persona natural ojurídica establece una relación contractual con cualquier empresa, se realiza bajociertos términos legales. Dentro de estos se exige especificar qué tipo devinculación se establecerá entre las dos partes, si es una vinculación comoempleado de planta, como contratista por prestación de servicios, etc. El objetivode este sub-módulo es gestionar los tipos de vinculación que la nómina puedallegar a manejar y su correspondiente información.

Ilustración 21 Diagrama de Caso Uso (Parámetro Tipo de Vinculación)

68


Submódulo de Gestión de Parámetros de Liquidación: Para poder comprenderlo que es un parámetro de liquidación, es necesario comprender que es unconcepto, el cual se define como “La Razón por la cual se suma o se resta unvalor en el proceso de liquidación de una nómina”.

El cálculo de dicho concepto se define a través de una fórmula compuesta porparámetros de liquidación, variables u otros conceptos y se realiza en elsubmódulo de conceptos que se encuentra alojado en el módulo padre liquidación.

En conclusión, se puede afirmar que un parámetro de liquidación puede ser unconcepto o parte del cálculo de un concepto y se define formalmente como losvalores constantes que están determinados por las políticas internas de laempresa y la legislación del país o el lugar donde labora la empresa.

Algunos ejemplos, son el valor del salario mínimo legal vigente, valor del auxilio detransporte, etc. Cabe aclarar que algunos de estos parámetros pueden variaranualmente o periódicamente y se debe llevar control sobre ello.

Ilustración 22 Diagrama de Caso Uso (Parámetro de Liquidación)

69


Submódulo de Gestión de categorías de Parámetros de Liquidación: Estesubmódulo y sus similares, también presentes en novedades y conceptos, sedesarrollaron pensando en la facilidad de uso del usuario.

Cuando un parámetro de liquidación se crea, se especifica a que categoríapertenece. Estas categorías serán definidas por el usuario y gestionadas en elpresente submódulo.La categorización de parámetros de liquidación permite realizar una agrupación deestos últimos y cuando el usuario desee realizar consultas se facilita la generaciónde filtros. Para ejemplificar cuando se esté creando un concepto (procesoanalizado posteriormente) se hace uso de los parámetros de liquidación. Sinembargo, presentar una lista con todos ellos no sería óptimo y adicionalmentetedioso para el usuario. Para ello, el usuario puede gestionar la categoría,agrupando los parámetros como le parezca conveniente.De esta manera, antes de seleccionar el parámetro el usuario selecciona lacategoría y está filtra solo los que estén asociados a ella. La figura 23 ilustra eldiagrama de caso de uso de la gestión de categorías de parámetros deliquidación.

Ilustración 23 Diagrama de Caso Uso (Gestión de Categorías de Parámetros de Liquidación)

70


7.5.2. Módulo: Gestión Persona

Cuando una persona, ya sea natural o jurídica, se va a vincular a la nómina, debeexistir previamente como un tercero dentro del sistema. El módulo GestiónPersona se diseñó para cumplir esa tarea.

En la Universidad Distrital, un ordenador del gasto solicita inicialmente el registrouna persona natural o jurídica a través de una solicitud que está compuesta por lainformación básica de la persona.

Posterior al registro de la solicitud, se realiza la validación de los datossuministrados en el proceso anterior por parte de la dependencia gestora depersonas con el fin de determinar si la ya mencionada solicitud es aceptada,rechazada o modificable. Se debe notificar el resultado de la validación y en caso

71

de que sea modificable debe ser posible indicar que ajusten debe realizarse a lasolicitud de registro.

En este módulo se trabajó en los submódulos de gestión de solicitudes depersonas naturales y jurídicas y se abordaron 8 requerimientos:

Solicitud Registro Persona Natural y Jurídica. Modificar Solicitud Registro Persona y Jurídica. Consultar Solicitud Registro Persona y Jurídica. Inactivar Solicitud Registro Persona y Jurídica.

La solicitud de Registro de persona comprende el registro de la información deidentificación, datos básicos personales o empresariales, comercial, de contacto,actividades económicas, documentos soportes, etc. En la siguiente ilustración sepuede apreciar el diagrama de caso de uso de estas funcionalidades en particular.

Ilustración 24 Diagrama de Caso Uso (Gestión Persona)


72

7.5.3. Módulo: Gestión Conceptos

Junto con novedades son los módulos principales del sistema de gestión denómina, este se compone de los siguientes submódulos:

Submódulo de Gestión de Conceptos: Como se mencionó en el módulo deparámetros de liquidación un concepto se define como la “Razón por la cual sesuma o se resta un valor en el proceso de liquidación de una nómina”. Como loindica la definición anterior un concepto es un devengo o una deducción dentro deuna nómina.

Periódicamente una empresa u organización lleva a cabo la liquidación de nóminaa sus empleados o a las personas con las cuales ha establecido un vínculocontractual. Dichas liquidaciones se componen de valores que suman o restan yque finalmente determinar un valor total a liquidar al empleado y otros valores aliquidar a instituciones como fondos de pensión, entidades de salud, cajas decompensación, etc.

Estos valores son hallados a través de fórmulas establecidas por legislacióngubernamental o reglamentación propia de la empresa, Aunque el cálculo dedichos valores no es trivial y puede ir desde un único valor como el cálculo delsalario básico hasta cálculos con valores condicionados por diferentes factorescomo una prima por antigüedad en la cual el valor estará ligado al número de añosque una persona lleve vinculada a la entidad.

En algunos casos un concepto puede ser calculado a partir de otros conceptos oparámetros de liquidación y estos a su vez pueden ser parte del cálculo de otroconcepto.

La gestión de conceptos es uno de los procesos más complicados en la nómina.Para ello se desarrolló este submódulo que comprende dentro de los procesos deregistro y modificación de conceptos tres fases fundamentales: La primeradestinada a la captura o modificación de la información básica del concepto(nombre, naturaleza, legislación, descripción, categoría, etc.), la segundacomprende la definición de la fórmula de cálculo del concepto.

En esta fase se puede hacer uso de los parámetros de liquidación, variables yotros conceptos y la última en la cual en caso de ser necesario se estructuran lascondiciones que rigen el concepto (figura 25).

73

Los diagramas de casos de uso presentados en las siguientes ilustracionesmuestran de manera clara y perceptible para el lector lo previamente descrito,observe la ilustración 26.

Ilustración 25 Fases de Registro y Modificación de un Concepto

Ilustración 26 Diagrama de Caso Uso (Registro de Concepto)


La figura 26 presenta el diagrama de caso de uso del registro de un concepto, endonde se pueden apreciar las interacciones que el usuario realiza con el sistemapara realizar el proceso.

74

De acuerdo con las fases definidas, el usuario inicialmente registra la informacióngeneral del concepto, posteriormente, y haciendo uso de los parámetros deliquidación del sistema, de la variables (entiéndase variable como un parámetroque difiere en cada empleado y depende del tipo de vinculación y las condicionescontractuales preestablecidas) y de otros conceptos define la fórmula de cálculodel concepto, en caso de ser necesario, el usuario puede registrar las condicionesdel concepto haciendo uso de los mismos factores mencionados en la segundafase.

En el caso de la modificación el proceso es similar al registro, se llevan a cabo lasmismas fases, con la diferencia que se realiza un control de auditoría que gestionalos cambios hechos en la actualización (figura 27) y la información del usuario queedita la información del concepto, este último control también se realiza cuando elusuario inactiva un concepto (figura 28).

La consulta de conceptos es sencilla y se resumen en el diagrama de caso de usopresentando en la figura 28.

Ilustración 27 Diagrama de Caso Uso (Actualización de Concepto)


75

Ilustración 28 Diagrama de Caso Uso (Inactivación y Consulta de Concepto)


Submódulo Gestionar Categorías de Conceptos: Este submódulo, y sussimilares también presentes en novedades y parámetros de liquidación, sedesarrollaron pensando en la facilidad de uso.

Cuando un concepto se crea en la primera fase de registro se especifica a quecategoría pertenece. Estas categorías serán definidas por el usuario y gestionadasen el presente submódulo. La categorización de conceptos permite realizar unaagrupación de estos últimos y cuando el usuario desee realizar consultas sefacilita la generación de filtros.

Para ejemplificar en la segunda fase de la creación del concepto el usuario puedehacer uso de otros conceptos, sin embargo, presentar una lista con todos losconceptos no sería óptimo y adicionalmente tedioso para el usuario. Para ello elusuario puede gestionar la categoría, agrupando los conceptos como le parezcaconveniente.

De esta manera, antes de seleccionar el concepto el usuario selecciona lacategoría y está filtra solo los conceptos que estén asociados a ella, solucionandolos problemas resaltados anteriormente.

76

Observe la figura 29 la cual presenta el diagrama de caso de uso de la gestión decategorías de conceptos.

Ilustración 29 Diagrama de Caso Uso (Gestión Categorías de Conceptos)


Submódulo de Gestión de Asociación de Conceptos: Los tipos de vinculaciónson gestionados en el módulo de parámetros junto con la nómina, la cual sedefine como “Un grupo de conceptos que se liquidan periódica oesporádicamente”.

Normalmente, una empresa realiza liquidaciones mensuales a los empleadosdonde se refieren conceptos como el salario básico, porcentaje de seguridadsocial y salud, subsidio de transporte, etc. Adicional a estas liquidacionesmensuales surgen liquidaciones adicionales que tiene como fin el cálculo de otrosconceptos prestacionales que la entidad está obligada a pagar a sus empleados o

77

a las instituciones correspondientes, como las vacaciones, cesantías, primas ydemás prestaciones y conceptos legales establecidos.

Con el fin de parametrizar el modelo de negocio del sistema de nómina, a estosgrupos de conceptos, que se liquidan en determinados periodos en años y queagrupan cierto número de conceptos que difieren se les denominó nóminas. Lagestión de estas se lleva a cabo en el módulo de parámetros.

Las nóminas están ligadas al tipo de vinculación, pues en el caso de un contratistavinculado por orden de prestación de servicios, solo se generaría una nóminamensual, pero por otro lado, si se trata de un empleado de planta surgirán varias.

El submódulo de Asociación de Conceptos tiene como fin realizar la asociaciónentre conceptos, nóminas y tipos de vinculación un paso previo y fundamentalantes de realizar una pre liquidación.

Después de que los conceptos, la nómina y los tipos de vinculaciones han sidocreados el usuario vincula cada concepto a una nómina y la nómina al tipo devinculación, esto garantiza que todos los conceptos puedan asociarse a variasnóminas y tipos de vinculación.

En el siguiente paso, cuando se genere la pre liquidación se selecciona el tipo devinculación y la nómina que se liquidará. A continuación se ilustra el diagrama decaso de uso de este submódulo en particular.

El submódulo presenta las funcionalidades para asociar conceptos a nóminas, elusuario selecciona el concepto, selecciona el tipo de vinculación que, para el casoen particular, funciona como filtro para los tipos de nóminas registrados yvinculados y asocia el concepto.

Posteriormente, si desea realizar una modificación en la asociación, el sistemaofrece los medios para realizarlo. También se pueden llevar a cabo consultas einactivaciones. La actualización y la inactivación se respaldan por un control deauditoría que registra los cambios realizados en los estados y en la información delas asociaciones.

78

Ilustración 30 Diagrama de Caso Uso (Gestión de Asociación de Conceptos)


7.5.4. Módulo: Gestión De Novedades

En las descripciones previas se mencionaron las novedades como un tipo deconceptos que por cuestiones de estructura y comportamiento en la liquidación.Ahora, es pertinente desligarse del módulo propio de conceptos, pues unanovedad es un concepto que aplica a uno o a un grupo pero no a todos losempleados involucrados en una liquidación de nómina.

Como su nombre lo indica la novedad es un acontecimiento esporádico que lesucede o que un empleado realiza, como es el caso de una incapacidad, un

79

ausentismo, una licencia, laborar horas extra, realización de préstamos a laempresa, el embargo de un porcentaje de sueldo, una bonificación etc.

Se comprende entonces que no todos los empleados laboran horas extra o seenferman en los mismos periodos de tiempo, por ello la particularidad del trato quese le da a las novedades.

Las novedades, sin embargo, exigen el registro de información particular en cadauno de los casos, es decir para el registro de una bonificación se solicitainformación diferente que para las horas extra o las licencias, adicionalmente elcálculo del valor de la novedad dependen de los datos propios de que cadanovedad que se registre. Por estas razones el módulo de novedad cuenta con dossubmódulos orientados a la gestión de novedades.

Dentro de este módulo existe adicionalmente un submódulo desarrollado pararealizar las vinculaciones de personas naturales al sistema de gestión de nómina,cuando una persona está registrada en el sistema no se le liquidará nómina hastaque no esté vinculada, a continuación se detallaran lo mencionados submódulos.

Submódulo Generador de Novedades: TITAN ofrece al usuario la funcionalidadpara generar formatos de novedad y definir la fórmula de cálculo bajo lainformación que se captura en dicho formato. Dada la similitud con el concepto eninformación general, la primera fase para crear una novedad, es realizar el registrode la información básica (nombre, descripción, naturaleza, categoría, ley, etc.), acontinuación se define la estructura del formato de datos de la novedad.

El usuario está en la capacidad de crear formularios de manera dinámica, es decirpodrá diseñar la estructura para el ingreso de los datos de la novedad, para ellopuede crear n número de campos especificando, el tipo (entradas de texto onúmeros o fechas, tablas, listas desplegables, entre otras), que informaciónsolicita este campo (títulos para los campos ), estructurar la naturaleza del campo(tamaño de entrada, longitud de datos ingresados, es requerido o no, etc.),

Se podrá especificar cuáles de los campos participan en el cálculo del valor de lanovedad, contextualizando si usuario generó el formulario de ausentismo y definióuno de los campos para capturar el número de días de ausentismos, el valorcapturado en dicho campo se debe utilizar para definir la fórmula que determina elvalor definitivo a descontar por esta novedad al empleado.

Esta estructura ofrece versatilidad en el momento de diseñar, crear y registrar unanovedad, la fórmula de la novedad se define de la misma manera que la fórmula

80

del concepto utilizando parámetros de liquidación, otros conceptos en caso de sernecesario y los campos creados en el formulario y marcados como participantesen el cálculo de la fórmula.

Las fases involucradas en este proceso y en el de modificación se puedenapreciar a continuación.

Ilustración 31 Fases de Registro y Modificación de Novedad

Este submódulo gestiona la modificación (ilustración 32), la consulta y lainactivación (ilustración 33) de novedades, en el caso de la actualización se sigueel mismo esquema que el registro pero adicionalmente y junto con la inactivaciónse realiza un control de auditoría que registra los cambios sobre los datos y lainformación del usuario que los altera.

Ilustración 32 Diagrama de Caso Uso (Generar Novedad)


81

Ilustración 33 Diagrama de Caso Uso (Editar Novedad)


La anterior ilustración presenta el diagrama de caso de uso de la modificación dela novedad, como se apreciar es muy similar al registro, cabe aclarar que “AsociarCampo Novedad” hace referencia al campo del formulario que participa en elcálculo de la fórmula.

82

Ilustración 34 Diagrama de Caso Uso (Consultar e Inactivar Novedad)


Submódulo de Gestión de Novedades: Después de realizar el registro de unanovedad, es necesario gestionar las novedades ya creadas en lo respecta a laasociación de la mismas con los empleados vinculados a la nómina.

En submódulo anterior se registra la novedad y el formulario asociado a estaúltima, posteriormente cuando los usuarios quieran reportar ha determinadoempleado un novedad debe hacer uso de este submódulo, para ello se seleccionael empleado y la novedad que asociaron cuando la novedad es seleccionada elsistema presenta el formulario definido en el “Generador de Novedades”, seregistra la información que se especifique en el formulario propia de la novedaddel empleado en particular y se finaliza la asociación (figura 35).

83

Dicha asociación se puede modificar en caso de ser necesario (figura 36), einactivar cuando la situación lo amerite (figura 37), la actualización es similar alregistro más sin embargo se lleva a cabo la pertinente auditoría de los datosalterados, procedimiento que también aplica para la inactivación, en el caso de laconsulta el usuario podrá ver todas la novedades asociadas a un empleado ydeterminar si están activas para liquidar o no.

En las figuras que se presentan a continuación se exponen los casos de la gestiónde novedades.

Ilustración 35 Diagrama de Caso Uso (Asociar Novedad a Empleado)


84

Ilustración 36 Diagrama de Caso Uso (Modificar Novedad Asociada)


Ilustración 37 Diagrama de Caso Uso (Consultar e Inactivar Novedad Asociada)


Submódulo de Vinculación Persona Natural: El proceso de vinculaciónespecifica el tipo de vinculación contractual, la fecha de inicio y finalización decontrato (en caso de estar definida), la sede o dependencia donde la personanatural prestará su labor como funcionario, entre otras. Una aseveración

85

importante es que este submódulo permite determinar si la vinculación está ligadaa condiciones particulares del modelo de negocio o se realiza de manera general.

En la Universidad Distrital en particular, se presentan varios tipos de vinculación,pero en algunos casos la vinculación varía considerablemente, al punto de influiren el modelo de liquidación.

Para contextualizar, cuando se vincula un contratista se registra el valor delcontrato principalmente. Por otro lado, si ingresa un docente de vinculaciónespecial, se debe registrar el valor del contrato, el número de semanas y horas porsemana que trabajara y los puntos por investigaciones o experiencia que estetenga. Cuando se trata de un pensionado se registra una mesada pensional entreotros datos que son completamente diferentes a las demás vinculaciones.

Es claro entonces que en este punto es pertinente dejar el sistema abierto a lascondiciones del modelo de negocio por ello cuando se registra una vinculación sele permite escoger al usuario si es de tipo general o tipo específico.

En la primera de ellas se registra datos abstractos como el cargo, la actividadesque realizará y el valor del salario en la segunda se entra a mirar que establece elentorno de negocio y se especificará la información particular de cada vinculación.

Para este submódulo se trabajaron 4 tipos de vinculaciones propias del modelo denegocio, no obstante cabe aclarar que no se profundizó mucho estas por cuestiónde tiempo y considerando que se proyectó un sistema que no estuviera del todoatado al modelo de negocio de la institución:

Vinculación Contratista. Vinculación Docente de Vinculación Especial. Vinculación Docente o Funcionario de Planta. Vinculación Pensionado.

Las funcionalidades ofrecidas permiten registrar la vinculación de persona natural,modificarla e inactivar, llevando transversalmente el control de auditoría sobre losdatos alterados particularmente para las dos últimas.

Además de poder registrar la vinculación una a una se diseñó una herramientaadicional para ejecutar cargas masivas a partir de archivo .xls, esto sin dudafacilita el proceso de vinculación en organizaciones (Figura 38).

86

Ilustración 38 Diagrama de Caso Uso (Vinculación Persona Natural)


Submódulo de Registro y Gestión de Hoja de Vida: Es un complemento de lossub-módulos de Gestión de Persona, tal y como su nombre lo establece se

87

encarga de realizar el registro y la gestión de la hoja de vida de las personasvinculadas a la nómina.

Estos procesos pueden realizarse antes o después de establecer una vinculacióna través del sub-módulo también descrito en este módulo, es decir la persona seregistra en el sistema de nómina a través del módulo que gestiona las personasnaturales y jurídicas. Posteriormente se puede realizar el registro de su hoja devida previo al proceso de vinculación de persona natural y después de dichoproceso también se pueden realizar procesos eventuales de actualización oconsulta sobre las hojas de vida de los vinculados y terceros.

Ilustración 39 Diagrama de Caso Uso (Registro y Gestión de Hoja de Vida)


7.5.5. Módulo: Gestión De Liquidación

Todos los módulos mencionados anteriormente no tendría fundamento de no serpor este, el paso final en la nómina es llevar a cabo la liquidación de la misma.Este módulo se compone de tres submódulos, dos de ellos orientados a laliquidación final y uno encargado de realizar la gestión de las nóminas asociadas alos tipos de vinculación.

Submódulo de Gestión de Nómina: La nómina como ya se citó se define como“Un grupo de conceptos que se liquidan periódica o esporádicamente” a un tipo devinculación se le pueden asociar varias nóminas, nómina mensual de salarios,nómina de primas, nómina de prestaciones sociales, nómina de vacaciones, etc.

88

(en el submódulo de Asociación de Conceptos se hizo mención de ello y se explicamás al detalle).

Este submódulo tiene como fin registrar la información de la nómina: nombre, tipo,descripción, ley en caso de existir, etc. antes de realizar el registro de nómina seselecciona el tipo de vinculación al cual se le asociará.

Dentro del submódulo se ofrecen las funcionalidades para realizar el registro, laconsulta, la modificación e inactivación de nóminas, llevando el debido controlsobre los datos alterados particularmente en las últimas dos, como se explica en lailustración 40.

Ilustración 40 Diagrama de Caso Uso (Gestión de Nómina)


Submódulo de Pre liquidación: A nivel de usuario, ofrece funcionalidadessencillas, sin embargo los cálculos que realiza a nivel lógico y de persistencia sonel core de todo el sistema. Una vez registrados los tipos de vinculación, los

89

parámetros necesarios, las personas y su posterior vinculación, las nóminas, lascategorías, los conceptos y las novedades, el usuario utiliza este módulo parallevar a cabo el paso final de la gestión de nómina la liquidación. Acorde con los expuesto hasta este punto una persona se registra en el sistema,se vincula bajo un tipo de vinculación, a este último se le registran una o másnóminas que a su vez tienen asociados conceptos o novedades que finalmenteson los que se sumarán o resta para presentar los valores finales de la liquidación.

En este submódulo el usuario registra el nombre y la descripción de la preliquidación, selecciona el tipo de vinculación y con base en el anterior filtroselecciona la nómina, adicionalmente la fecha de inicio y fin del periodo que seliquidará esto atado a las novedades puesto que permitirá determinar cuáles deellas aplican para el periodo de particular.

Cuando el usuario finaliza el proceso el sistema se encarga de ir a la nóminatomar concepto y novedad uno por uno obtener las fórmulas de cálculo de cadauno, inspeccionarlas y llevar el cálculo de estas teniendo en cuenta las variables yla información de cada empleado.

El usuario puede registrar y ver los detalles de las pre liquidaciones en esta últimaopción podrá ver los resultados finales que devengan y deducen los empleados yadicionalmente el detalle concepto por concepto que cada uno tuvo al finalizar lapre liquidación.

Se pueden registrar la cantidad de pre liquidaciones consideradas por el usuariohasta que el cálculo final sea correcto desde el punto de vista de los liquidadores,llevar a cabo consultas, modificaciones e inactivaciones (Ilustración 41).

Ilustración 41 Diagrama de Caso Uso (Gestión de Pre liquidaciones)

90


Submódulo de liquidación: cuando la pre liquidación sea exitosa en el anteriorsubmódulo, el usuario realiza la transición a través de este submódulo a unaliquidación, simplemente le da un nombre y una descripción a la liquidación yselecciona la pre liquidación.

Dentro del submódulo se puede llevar a cabo el registro, la consulta y el estado dela liquidación, dicho estado refiere al pago o no pago de la liquidación en cuestión(Ilustración 42).

Ilustración 42 Diagrama de Caso Uso (Gestión Liquidaciones)

91


7.5.6. Módulo: Gestión De Reportes

El módulo de reportes, se diseñó con el fin de presentar la información deliquidaciones o certificados de nómina bajo formatos aceptables y legibles para losusuarios finales, con el fin de ofrecer el dinamismo que tanto se trató de dar conTITAN.

Dentro del módulo se cuenta con un generador de plantillas que permite generarlas estructuras de los reportes, el usuario debe seleccionar entre reporte general ycertificado, el primero de ellos orientado a los reportes de liquidación permite laselección de información de los conceptos o las novedades en cuanto a atributospropios de cada uno, como nombre, símbolo, naturaleza, formula, etc. informaciónreferente a liquidación como estado de la vinculación, valor del contrato, fecha deinicio o fin, entre otros, se puede determinar que conceptos y novedades saldránen el reporte y cuáles no.

Por otro lado está el certificado, diseñado exclusivamente y como bien su nombrelo refiere para creación de certificados de vinculación a nómina. Dentro de estas

92

plantillas se pueden modificar los pies de página y los encabezados,funcionalidades que otorgan al usuario capacidad para el diseño y laestructuración de reportes básicos personalizados de nómina. Con este módulo nose entrará más en detalle debido a que no hizo parte del desarrollo de esteproyecto.

Nota: Dentro de los anexos se encontrarán las especificaciones de caso de usode cada una de las funcionalidades de los submódulos expuestos dentro de estecapítulo.

93

CAPITULO 8. RESULTADOS Y TRABAJO A FUTURO

Las funcionalidades y los diagramas descritos en el capítulo anterior son evidenciajunto con los anexos de este documento de todo el trabajo realizado y el esfuerzoinvolucrado en el mismo, dada la complejidad del modelo de negocio y de lanómina en sí misma no es posible entregar los artefactos de la gestión derequerimientos y requisitos en su versión final, pero se obtuvo una compilacióninicial de documentos que a futuro con el pertinente afinamiento conducirán a unsistema estable que satisfaga las necesidades identificadas y automatice losprocedimientos vigentes.

Esta versión inicial agrupa la principales funcionalidades del sistema y se enfocafundamentalmente en un sistema de gestión de nómina genérico que aborda demanera dinámica las necesidades más relevantes identificadas, el diseño de losmódulos de liquidación, novedades y conceptos y su trabajo conjunto representanel core del sistema TITAN y sin duda alguna son los componentes en los cualescentrar el trabajo a futuro.

Es importante destacar que todo trabajo futuro centrado en la Universidad Distritalestá ligado al sin número de condiciones adicionales que el modelo de gestión denómina de la institución agregara al sistema, lo cual forzará a una depuracióndetallada de la documentación levantada, identificación de nuevasfuncionalidades, rediseño y reestructuración de la arquitectura en general de losmódulos y submódulos, redefinición procesos, etc. El trabajo restante es ampliopero sin duda será satisfactorio.

94

CAPITULO 9. CONCLUSIONES

El desarrollo del sistema de información de gestión de nómina TITAN fue unaexperiencia enriquecedora en aspectos positivos y negativos, el conocimientoobtenido es una gran premio al esfuerzo, por otro lado los errores cometidos nosevidencia el sin número de cosas por mejorar en futuros proyectos, acontinuación se exponen las conclusiones más relevantes del trabajo descrito a lolargo de este documento.

La gestión de nómina involucra un gran número de procesos que están

ligados al tamaño de la organización a la cual se aplique y al modelo denegocio propio de la misma, el modelamiento de un sistema que puedenllegar a ser tan complejo como se quiera y que dependen en gran medidadel entorno donde se aplique fue un reto total, pensar en un sistemagenérico que aplique para cualquier empresa sin importar tamaño ovariables de contexto fue un gran obstáculo para el avance del sistema yse convierte con el tiempo por más insistencia y esfuerzo que se dediqueen una limitación del software, si bien es posible llegar a cierto nivel deabstracción que conlleva a un prototipo que se ajusta a lo que se buscatarde que temprano nuevas condiciones imponen fronteras. El sistemamodelado sin embargo no busca ser la solución a todas las nóminasposibles, por otro lado se enfoca en parametrizar los procesos claves de lagestión de nómina con el fin de otorgar una solución modular, integral yescalable.

La versión inicial de la documentación que respalda el análisis

desarrollado evidencia el trabajo realizado y permite comprobar que secumplieron los objetivos trazados, llevando a cabo las 24 iteracionesplanteadas bajo la metodología OPEN/UP OAS en sus fases de inicio,elaboración y construcción, la caracterización del modelo de operación delsistema, el levantamiento de requerimientos y casos de uso, los modelosgráficos de los procesos (BPM) y los demás artefactos que fueronelaborados a lo largo del periodo de pasantía, lo cual conlleva a concluirque los objetivos y alcances preestablecidos fueron cumplidosexitosamente.

El desarrollo de un sistema de software a nivel empresarial está acotado

bajo condiciones que la academia no enseña, el trabajo en equipo y lascondiciones laborales establecen nuevos paradigmas en nuestro trabajo

95

como ingenieros de sistemas, por ende la pertinente y adecuadaimplementación de una metodología de trabajo garantiza un ambienteorganizado y coordinado para todos los participantes del proyecto yorienta el producto final al éxito.

La etapa de análisis y la ingeniería de requerimientos son fundamentales

para la producción de un sistema de software exitoso, la correctainteriorización del modelo de negocio de lo que se quiere desarrollar y suposterior descripción a través de diagramas, documentos y demásartefactos implica un sin número de tareas que se alejan de la simplicidady que comprometen desde el inicio de cualquier metodología de desarrolloel resultado final, es de vital importancia comprender la relevancia de estesubproceso para el caso particular de la metodología OPENUP/OAS, sinun correcto levantamiento de requerimientos y requisitos cualquierproyecto está condenado al fracaso, pero no solo es importante resaltar lotrascendental de estas actividades adicionalmente se debe enfatizar en elgrado de dificultad y la cantidad de tiempo que estas pueden implicar y sinduda alguna la participación como analista en el desarrollo de TITAN mepermite confirmar lo ya mencionado.

96

CAPÍTULO 10. BIBLIOGRAFÍA

[1]. COLOMBIA. UNIVERSIDAD DISTRITAL FRANSISCO JOSE DE CALDAS.Resolución No 461. (29, Julio, 2011). Por medio de la cual se adopta el método delproceso de desarrollo OPENUP/OAS como marco de trabajo Institucional en elanálisis, diseño, desarrollo e implantación de productos de software al interior dela Universidad Distrital Francisco José de Caldas. SISGRAL Bogotá D.C.

[2]. PRESSMAN, Roger. Ingeniería del Software: Un Enfoque Práctico, SextaEdición. McGraw-Hill, 2005.

[3]. KULAK Daryl, GUINEY Eamonn. Use Cases: Requirements in Context,Segunda Edicion, Addison-Wesley Professional, 2004.

[4]. UNIVERSIDAD DISTRITAL FRANSISCO JOSE DE CALDAS. Capítulo 6"Gestión de Requerimientos y Requisitos", Proceso de Desarrollo OPENUP/OAS.Primera Edición. Bogotá, 2011.

[5]. UNIVERSIDAD DISTRITAL FRANSISCO JOSE DE CALDAS. Guía RápidaProceso de Desarrollo OPENUP/OAS. Primera Edición. Bogotá, 2011.

[6]. [Citado el 03 de Septiembre de 2015] Disponible en <http://financialred.com/ >.

[7] COLOMBIA. UNIVERSIDAD DISTRITAL FRANSISCO JOSE DE CALDAS.Resolución No 049. (20, Enero, 2011). Por medio de la cual se ajusta y precisa deprocedimiento para la contratación de órdenes de prestación de servicios (OPS)en la Universidad Distrital Francisco José de Caldas. SISGRAL Bogotá D.C.

[8] COLOMBIA. UNIVERSIDAD DISTRITAL FRANSISCO JOSE DE CALDAS.Resolución No 049. (24, Junio, 2013). Por medio de la cual se acoge y aplica eldecreto 1003 del 21 de Mayo de 2013 a los docentes de vinculación especial horacátedra, medio tiempo ocasional y tiempo completo ocasional en pregrado en lopertinente únicamente al valor del punto. SISGRAL Bogotá D.C.

[9] COLOMBIA. El PRESIDENTE DE LA REPUBLICA. Decreto 1279 de (19, Junio,2002). Por el cual se establece el régimen salarial y prestacional de los docentesde las Universidades Estatales.

97

[10 ] COLOMBIA. UNIVERSIDAD DISTRITAL FRANSISCO JOSE DE CALDAS.Acuerdo No 011. (15, Noviembre, 2002). Por el cual se expide el estatuto docentede la Universidad Distrital Francisco José de Caldas. SISGRAL Bogotá D.C.

[11] COLOMBIA. EL PRESIDENTE DE LA REPUBLICA. Decreto 1003 (21, Mayo,2013). Por el cual se dictan disposiciones en materia salarial y prestacional paralos empleados públicos docentes y administrativos de las Universidades Estatalesu Oficiales.

[12] OFICINA ASESORA DE SISTEMAS, (OAS). Modelo de negocio Nómina deContratistas, Primera Edición. OAS, 2013.

[13] OFICINA ASESORA DE SISTEMAS, (OAS). Modelo de negocio Nómina deDocentes de Vinculación Especial, Primera Edición. OAS, 2013.

98

ANEXOS

El documento de “Anexos” se adjunta de manera digital y el índice seexpone al inicio del mismo.

99

ANÁLISIS Y GESTIÓN DE REQUERIMIENTOS Y REQUISITOS DE …

Documents

Transcript of ANÁLISIS Y GESTIÓN DE REQUERIMIENTOS Y REQUISITOS DE …