Participar en la Fase de Inicio, Elaboración y Construcción en el Proyecto Referente a la Solución de Software para el Apoyo en el Proceso de Gestión de Nómina en la Universidad Distrital

PARTICIPAR EN LA FASE DE INICIO, ELABORACIÓN Y CONSTRUCCIÓN EN EL PROYECTO REFERENTE A LA SOLUCIÓN DE SOFTWARE PARA EL

APOYO EN EL PROCESO DE GESTIÓN DE NÓMINA EN LA UNIVERSIDAD DISTRITAL

AUTORES:

Julián David Torres Salgado 20102020116

Andrey Duvan Sarmiento Sarmiento 20102020111

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA

INGENIERÍA DE SISTEMAS Bogotá D.C.

PARTICIPAR EN LA FASE DE INICIO, ELABORACIÓN Y CONSTRUCCIÓN EN EL PROYECTO REFERENTE A LA SOLUCIÓN DE SOFTWARE PARA EL

APOYO EN EL PROCESO DE GESTIÓN DE NÓMINA EN LA UNIVERSIDAD DISTRITAL

AUTORES:

Julián David Torres Salgado 201020116

Andrey Duvan Sarmiento Sarmiento 20102020111

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

DIRECTOR:

Ing. CARLOS ENRIQUE MONTENEGRO MARIN

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA

INGENIERÍA DE SISTEMAS Bogotá D.C.

TABLA DE CONTENIDO

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

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

CAPÍTULO 3. OBJETIVOS ... 5

3.1. Objetivo general ... 5

3.2. Objetivos específicos ... 5

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

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

5.1. El Proceso OPENUP/OAS ... 9

5.1.1. Generalidades ... 9

5.1.2. El Método de Trabajo ... 12

5.1.3. Proceso de Desarrollo ... 23

5.2. La nómina: estructura, partes y elementos básicos. ... 32

5.3. Régimen salarial de la universidad distrital ... 34

CAPÍTULO 6. METODOLOGÍA ... 37

CAPÍTULO 7. DESARROLLO DEL PROYECTO ... 41

7.1. Listado de artefactos de software ... 41

7.2. Requerimientos no funcionales ... 49

7.3. Glosario ... 50

7.4. Arquitectura del Sistema ... 55

7.4.1 Diagramas de componentes ... 55

7.4.2 Estructura General del Sistema TITÁN... 56

7.5. Plan general de trabajo del sistema TITAN. ... 57

7.6. Manejo de la persistencia general del sistema TITAN. ... 60

7.6.1. Schema Persona ... 60

7.7.1 Gestión Persona. ... 70

7.7.2 Gestión Parámetros. ... 70

7.7.3 Gestión Conceptos. ... 83

7.7.4 Gestión de Novedades. ... 84

7.7.5 Gestión de Liquidación. ... 91

7.7.6 Gestión Reportes. ... 97

CAPÍTULO 8. RESULTADOS ... 103

CAPÍTULO 9. CONCLUSIONES ... 105

CAPÍTULO 10. BIBLIOGRAFÍA ... 107

Índice de Figuras

Figura 1. Método de trabajo. ... 12

Figura 2. Proceso de desarrollo OpenUP/OAS. ... 17

Figura 3. Estructura del equipo de desarrollo OpenUP/OAS. ... 19

Figura 4. Ficha desarrollo de solución proceso OpenUP/OAS. ... 23

Figura 5. Subproceso de desarrollo OPENUP/OAS. ... 24

Figura 6. Diagrama de componentes general del sistema TITAN. ... 56

Figura 7. Estructura general del sistema TITAN. ... 57

Figura 8. Flujo de trabajo. ... 58

Figura 9. Plan de iteraciones proyecto TITAN. ... 59

Figura 10. Seguimiento control de cambios del proyecto TITAN-Primera parte. ... 59

Figura 11. Seguimiento control de cambios del proyecto TITAN-Segunda parte. ... 60

Figura 12. Arquitectura de datos schema Persona. ... 61

Figura 13. Arquitectura de datos schema Parámetro. ... 62

Figura 14. Arquitectura de datos schema Nómina. ... 63

Figura 15. Arquitectura de datos schema Concepto. ... 64

Figura 16. Arquitectura de datos schema Novedad-Primera parte. ... 65

Figura 17. Arquitectura de datos schema Novedad-Segunda parte ... 66

Figura 18. Arquitectura de datos schema Liquidación ... 67

Figura 19. Arquitectura de datos schema Reporteador. ... 68

Figura 20. Arquitectura de datos schema Otro. ... 69

Figura 21. Clasificación pertenencia de artefactos de software. ... 69

Figura 22. Artefactos de software Gestión Persona. ... 70

Figura 23. Artefactos de software Gestión Parámetros. ... 71

Figura 24. Vista principal submódulo EPS ... 71

Figura 25. Registro EPS... 72

Figura 26. Vista principal submódulo ARL. ... 73

Figura 27. Registro ARL. ... 74

Figura 28. Vista principal submódulo Ley, Decreto o Norma. ... 75

Figura 29. Registro Ley, Decreto o Norma. ... 76

Figura 30. Vista principal submódulo acto administrativo. ... 76

Figura 31. Registro acto administrativo. ... 77

Figura 32. Vista principal submódulo tipo de vinculación... 78

Figura 33. Registro tipo de vinculación. ... 79

Figura 34. Vista principal submódulo parámetros de liquidación. ... 79

Figura 35. Registro parámetro de liquidación. ... 80

Figura 36. Vista principal submódulo actividad económica. ... 82

Figura 37. Registro actividad económica. ... 83

Figura 38. Artefactos de software Gestión Conceptos. ... 83

Figura 39. Artefactos de software Gestión de novedades. ... 84

Figura 40. Vista principal submódulo actividad económica. ... 85

Figura 41. Registro vinculación persona natural. ... 86

Figura 42. Vista principal submódulo generador novedad. ... 87

Figura 43. Persistencia generador de novedad. ... 88

Figura 45. Registro generador novedad-Segunda parte. ... 89

Figura 46. Registro generador novedad-Tercera parte. ... 89

Figura 47. Registro generador novedad-Cuarta parte. ... 90

Figura 48. Artefactos de software Gestión de Liquidación. ... 91

Figura 49. Vista principal submódulo Tipo Nómina. ... 92

Figura 50. Vista principal tipo nómina... 92

Figura 51. Persistencia tipo nómina. ... 93

Figura 52. Registro tipo nómina. ... 93

Figura 53. Vista principal submódulo asociación de conceptos. ... 94

Figura 54. Registro asociación de conceptos. ... 95

Figura 55. Vista principal submódulo Preliquidación. ... 96

Figura 56. Persistencia Preliquidación. ... 96

Figura 57. Registro Preliquidación. ... 97

Figura 58. Artefactos de software Gestión de Reportes. ... 97

Figura 59. Persistencia gestión reportes. ... 98

Figura 60. Vista Principal plantilla de reporte. ... 99

Figura 61. Registro plantilla de reporte-Primera Parte. ... 99

Figura 62. Registro plantilla de reporte-Segunda Parte. ... 100

Figura 63. Registro plantilla de reporte-Tercera Parte. ... 100

Figura 64. Vista principal reportes. ... 101

Figura 65. Registro reportes. ... 101

Figura 66. Registro grupal reportes. ... 102

Índice de Tablas

Tabla 2. Actividades Fase de elaboración OpenUP/OAS ... 14

Tabla 3. Fases de Subprocesos OpenUP/OAS ... 17

Tabla 4. Roles en el proceso OpenUP/OAS ... 20

Tabla 5. Artefactos del proceso OPENUP/OAS. ... 21

Tabla 6. Listado de Artefactos de Software ... 42

Tabla 7. Requerimientos no funcionales en desarrollo. ... 49

Tabla 8. Glosario ... 50

Tabla 9. Persistencia EPS. ... 72

Tabla 10. Persistencia ARL. ... 74

Tabla 11. Persistencia Ley, decreto o norma. ... 75

Tabla 12. Persistencia acto administrativo. ... 77

Tabla 13. Persistencia tipo de vinculación. ... 78

Tabla 14.Persistencia Parámetros de liquidación. ... 80

Tabla 15. Persistencia Actividad económica. ... 82

Tabla 16. Persistencia vinculación persona natural. ... 86

Tabla 17. Persistencia asociación concepto. ... 94

1 docentes, administrativos y contratistas, quienes deben tener una vinculación contractual con la Institución para que puedan ser retribuidos monetariamente por sus servicios.(misión universidad distrital, s.f.). Cualquiera que sea la vinculación contractual que tenga una persona natural con la Universidad debe efectuarse un proceso periódico de gestión de nómina integral, de liquidación de salarios, honorarios, prestaciones y aportes patronales, seguridad social y parafiscal y prestaciones sociales según sea el caso.

Actualmente en la Institución se cuenta con varios procesos de gestión de nómina de acuerdo al tipo de vinculación contractual existente y consecuentemente con diferentes herramientas informáticas que soportan dichos procesos, que van desde hojas de cálculos de Excel hasta soluciones más robustas soportadas en bases de datos Oracle, teniendo como común denominador la baja flexibilidad a nuevos requerimientos legales o tributarios del entorno externo o institucional, así como la baja interoperabilidad con otros componentes de software requeridos para efectuar los pagos y causaciones financieras.

3

CAPÍTULO 2. PLANTEAMIENTO DEL PROBLEMA

Dentro del manejo interno de cualquier empresa en el día a día se posee de un registro y control de actividades a nivel de nómina de aquellos trabajadores, que a partir de sus prestaciones de servicio realizadas en la misma, remuneran dichas actividades; por ellos se hace necesario un software que contemple de manera adaptable, eficaz y eficiente todos aquellos procesos pertenecientes a la gestión de nómina de una organización.

De esta manera la universidad distrital en sus deberes de gestión de nómina de sus respectivos trabajadores, se rige mediante diferentes leyes, acuerdos, decretos y resoluciones que definen los tipos de vinculación contractual para los procesos indicados para la presente gestión.

Bajo el estudio realizado por la oficina asesora de sistemas (OAS) en el año 2013, identificando inconvenientes en la gestión de nómina en la universidad distrital, se obtiene que el problema radica en el que se cuenta con una gran variedad de procesos y herramientas informáticas obsoletas para soportar la liquidación de nóminas a las personas naturales que tienen algún vínculo contractual con la Universidad, sumado a la baja interoperabilidad de las herramientas con otros componentes de software proveedores o destinatarios. Además, la forma en la que se realiza la gestión actual de nómina de la universidad distrital afecta el control de la misma, ya que los tipos de vinculación contractual de funcionarios, docentes de vinculación especial y contratistas se controlan cada uno de forma independiente, lo cual no permite la unicidad en la información y así un control global de nómina en el ente institucional; en el presente proyecto se abarca en la unificación del control de nómina para los funcionarios (Administrativos , docentes y pensionados), debido a que dicha gestión se hace extensa de acuerdo al tipo de vinculación, inicialmente se realizara la solución para la gestión de nómina de funcionarios anteriormente descritos.

5

CAPÍTULO 3. OBJETIVOS

3.1. Objetivo general

Desarrollar una solución modular, integral y escalable, que permita apoyar los procesos relacionados a la gestión de nóminas de la Universidad Distrital, basado en los resultados obtenidos de la gestión de requerimientos y arquitectura, y que esté soportado en tecnologías libres siguiendo el proceso de desarrollo OPENUP/OAS en su fases de inicio, elaboración y construcción

3.2. Objetivos específicos

● Desarrollar módulos para el sistema de nómina de la Universidad Distrital, que estén acordes con las especificaciones de caso de uso y la arquitectura definida para cumplir con los lineamientos de cada iteración en las etapas de inicio, elaboración y construcción siguiendo los lineamientos del proceso de desarrollo OPENUP/OAS.

● Realizar la documentación técnica de la funcionalidad y el proceso llevado a cabo en el desarrollo del software, con base en los requerimientos y en la arquitectura planteadas en el proceso de desarrollo en curso, para cumplir con el proceso de retroalimentación de la metodología propuesta.

● Complementar los requerimientos y la arquitectura, desde el punto de vista del programador, mediante sesiones de trabajo colaborativo con los analistas y arquitectos con el fin de contribuir a la gestión de cambios necesarios en el sistema.

7

CAPÍTULO 4. JUSTIFICACIÓN

Debido a que la Universidad Distrital no cuenta con un sistema integral, unificado y escalable que permita soportar el proceso de gestión de nómina en la Institución de las personas naturales que tiene algún vínculo contractual con la Universidad, se hace necesario el análisis, diseño arquitectónico y desarrollo de una solución de software que permita unificar los diferentes tipos nóminas existentes en una sola herramienta web, cuyas características sea una alta interoperabilidad con otros componentes de software, adaptable a los cambios normativos y legales del entorno interno o externo y cumpla requisitos de alta calidad en capacidades de usabilidad, fiabilidad, rendimiento y mantenimiento del software.

La solución integral de software permitirá reducir el tiempo invertido en el proceso de la liquidación de la nómina en cualquier tipo de vinculación contractual en la Universidad y consecuentemente pagos oportunos a los funcionarios, docentes y contratistas de la Institución. Por otro lado y por ser un sistema altamente interoperable permitirá lograr una sincronización precisa de datos con otros sistemas proveedores o destinatarios y armonizar la información organizacional.

9

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, la Universidad Distrital Francisco José de Caldas avaló el método de desarrollo OPENUP/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.

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

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

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

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

● Permitir a los administradores del proyecto realizar seguimientos a las avances basados en metas e indicadores

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

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

10

b. Separar el Problema de la Solución: Se debe estar seguro que se conoce el problema (o una parte de él) antes de definir una solución (o una parte de ella). Al separar claramente el problema (que necesita el cliente - no que necesita el equipo de desarrollo) de la solución (el sistema que tiene que hacer), es fácil mantener un enfoque y encontrar vías alternativas para solucionar el problema.

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

d. Usar escenarios y casos de uso para capturar requerimientos: Hacer uso de escenarios y casos de uso para capturar los requerimientos funcionales del sistema permiten que los interesados alcancen rápidamente un consenso acerca de sus necesidades e intereses.

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

f. Realizar negociaciones que maximicen el beneficio obtenido: Las negociaciones costo beneficio dentro del proyecto no pueden ser independientes de la arquitectura. Los requisitos y requerimientos establecen los beneficios que se deben alcanzar al implementar el sistema mientras que la arquitectura es una medida base para calcular el costo del mismo. El costo asociado con un beneficio puede influenciar en gran medida la percepción del usuario acerca del valor real obtenido.

g. Gestionar el entorno: El cambio es inevitable, y aunque presenta oportunidades para mejorar los beneficios dados a los grupos de interés, un entorno incontrolado de cambios fácilmente decantará en sistemas deficientes, sobredimensionados y que no satisfacen las necesidades reales de los clientes. Se debe gestionar los cambios manteniendo contratos específicos con los grupos de interés.

11

i. Mantenga un entendimiento común: Sea proactivo comunicando y compartiendo información con los participantes del proyecto y no asuma que todos y cada uno encontrarán justo lo que ellos necesitan saber o que cada persona tiene la misma comprensión del proyecto que todos los demás.

j. Aprender continuamente: Desarrolle continuamente sus habilidades técnicas e interpersonales, aprenda de los ejemplos de sus colegas, aproveche la oportunidad, tanto de ser un estudiante de sus colegas, así como maestro de ellos. Siempre incremente su habilidad personal para sobrellevar su propio antagonismo hacia otros miembros del equipo.

k. Organice alrededor de la arquitectura: La comunicación entre los miembros del equipo empieza a ser compleja incrementalmente. Por consiguiente, organice el equipo alrededor de la arquitectura, el vocabulario y el modelo mental compartido del sistema.

l. Desarrolle su proyecto en iteraciones: Divida su proyecto en una serie de iteraciones encajadas en el tiempo y planee su proyecto iterativamente. Esta estrategia iterativa lo habilita para entregar capacidades incrementalmente, como un conjunto ejecutable, subconjunto utilizable de requisitos y requerimientos probados e implementados, que pueden ser evaluados por los interesados al final de cada iteración.

m. Gestione los riesgos: Ataque tempranamente los riesgos que atacarán el proyecto. Continuamente identifique y priorice los riesgos y entonces idee estrategias para mitigarlos.

n. Adopte y gestione el cambio: Adoptar los cambios ayuda a construir un sistema que se encamina a las necesidades de los interesados y manejar los cambios permite reducir costos y mejorar la predicción de estos cambios. Los cambios hechos tempranamente en el proyecto se pueden hacer usualmente a bajo costo. A medida que usted avanza en el proyecto, los cambios pueden empezar a incrementarse en términos de costos.

12 5.1.2. El Método de Trabajo

Para la implementación de la solución de software bajo el proceso OPENUP/OAS se contemplan los respectivos subprocesos bajo cierta intensidad por cada una de ellas en la fase en la que se está ejecutando como se puede evidenciar en la Figura 1.

Figura 1. Método de trabajo.

Fuente: Oficina Asesora de Sistemas, “Guía rápida proceso de desarrollo OpenUP/OAS,” Universidad Distrital Francisco José de Caldas, 2011.

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

13 5.1.2.1. Fases del Proceso OpenUP/OAS

Fase de Inicio: Primera fase del proceso, donde los interesados (stakeholders) y los integrantes del equipo de desarrollo, colaboran para determinar el ámbito del proyecto, sus objetivos y determinar si el proyecto es viable.

En la Tabla 1, se puede evidenciar las iteraciones de esta fase enfocan el esfuerzo de trabajo en las actividades y resultados

Tabla 1. Actividades de fase de inicio OpenUP/OAS

Actividad Resultados

Iniciar

el proyecto

*Elaborar el documento Visión

*Elaborar el Plan General del Proyecto *Elaborar el documento de Análisis de riesgo

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 y requisitos

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

Llegar a un acuerdo

sobre el enfoque técnico

Elaborar el documento Bloc de Notas de la Arquitectura

Fuente: Oficina Asesora de Sistemas, “Guía rápida proceso de desarrollo OpenUP/OAS,” Universidad Distrital Francisco José de Caldas, 2011.

Al final de esta fase, como mínimo, el proyecto: ● Ha definido el ámbito

● Tiene un estimado inicial de los costos y el cronograma

● Ha definido y priorizado un conjunto inicial de requerimientos funcionales y no funcionales

● Ha identificado un conjunto de riesgos y haya propuesto las estrategias de mitigación.

14

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

En esta fase:

● Se obtiene un entendimiento más detallado de los requerimientos y requisitos

● 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.

Las iteraciones de esta fase enfocan el esfuerzo de trabajo en las actividades y resultados contemplados en la tabla 2, especificando tareas para cada una de las actividades.

Tabla 2. Actividades Fase de elaboración OpenUP/OAS

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 la especificació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

15

Actividad Tareas/Resultados

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 varios

elementos 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.

Gestionar las peticiones de cambio

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

Fuente : Oficina Asesora de Sistemas, “Guía rápida proceso de desarrollo OpenUP/OAS,” Universidad Distrital Francisco José de Caldas, 2011.

Fase de Construcción: Esta es la tercera fase del proceso, se enfoca en detallar los requisitos y requerimientos, diseñar, implementar y probar el grueso del software y completar el desarrollo del sistema basado en la arquitectura.

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

1. Planificación y gestión de la iteración

2. Identificar y refinar requisitos y requerimientos 3. Desarrollar un incremento de solución

16 Fase de Transición

Es la cuarta fase del proceso. Se enfoca en la transición del producto de software a la plataforma tecnológica del cliente logrando que los interesados convengan que el desarrollo del producto cumple con los requerimientos planteados.

Los objetivos de esta fase son lograr:

● La prueba beta valida que satisfaga las expectativas del usuario. Esto típicamente requiere algunas actividades de afinamiento, tales como depuració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 del producto, incluyendo pruebas formales e informales y pruebas beta.

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

● Documentar las lecciones aprendidas y mejorar el ambiente de los procesos y las Herramientas para el proyecto.

5.1.2.2. Subprocesos OPENUP/OAS

Como se había señalado anteriormente un subproceso es un conjunto de actividades desarrolladas por personas con unos roles determinados, las cuales se guían por medio de una serie de prácticas o guías para obtener unos productos de trabajo denominados Artefactos y que permiten cumplir direccionar las fases y actividades propuestas en las cuatro fases del proceso de desarrollo de software openup/oas.

17

Figura 2. Proceso de desarrollo OpenUP/OAS.

Fuente: Oficina Asesora de Sistemas, “Guía rápida proceso de desarrollo OpenUP/OAS,” Universidad Distrital Francisco José de Caldas, 2011.

En la Tabla 3, se evidencia en detalle cada uno de los subprocesos pertenecientes a OpenUp/OAS, junto con sus objetivos y artefactos a destinar:

Tabla 3. Fases de Subprocesos OpenUP/OAS

Subproceso Objetivo Artefactos de Salida

Gestión de Requerimiento s y Requisitos

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 producto y/o servicio.

-Visión

- Especificaciones de Casos de Uso

-Glosario

-Requisitos de Soporte -Actas de Trabajo

-Listadode requerimientos funcionales y no

18 resultados de un proyecto de software. relevancia, prevención, mitigación, control y respuesta a posibles

Transformar los requerimientos y requisitos significativos en una arquitectura que describa su estructura e identifique los componentes del software.

Implementar una solución técnica que cumpla con la arquitectura

definida y soporte los

requerimientos de los grupos interesados.

Código Fuente

Gestión de Pruebas

Diseñar, implementar, ejecutar y evaluar pruebas en cada uno de solicitudes de cambios generadas en un proceso de desarrollo de software.

Control de Cambios

Implantación Planificar y llevar a cabo la producción de una solución de software mediante el alineamiento

de las necesidades de

19 5.1.2.3. Roles OPENUP/OAS

Los productos de software los crean personas con diferentes intereses y competencias. Un ambiente de grupo saludable potencia la colaboración efectiva requiriendo 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 las condiciones del proyecto una persona puede asumir uno o varios roles, Figura 3.

Figura 3. Estructura del equipo de desarrollo OpenUP/OAS.

Fuente: Oficina Asesora de Sistemas, “Guía rápida proceso de desarrollo OpenUP/OAS,” Universidad Distrital Francisco José de Caldas, 2011.

20

Tabla 4. Roles en el proceso OpenUP/OAS

Rol Función Principal

Director del Proyecto Este rol garantiza la continuidad del proyecto al gestionar los recursos necesarios y mantener el interés institucional en el proyecto.

Jefe de Proyecto Este rol se encarga de la supervisión y dirección directa de las actividades y resultados de cada uno de los miembros del equipo de desarrollo.

Líder del Proyecto Lidera la planeación del proyecto, coordina interacciones con los interesados y conserva el equipo del proyecto enfocado en alcanzar los objetivos del proyecto

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

Arquitecto

Responsable de diseñar la arquitectura del software, la cual incluye tomar las principales decisiones técnicas que condicionan globalmente el diseño y la

Inspector de Pruebas Identificar, definir, implementar y dirigir las pruebas necesarias, así como verificar y analizar sus

resultados.

Fuente: Oficina Asesora de Sistemas, “Guía rápida proceso de desarrollo OpenUP/OAS,” Universidad Distrital Francisco José de Caldas, 2011.

5.1.2.4. Artefactos del Proceso OPENUP/OAS

21

Tabla 5. Artefactos del proceso OPENUP/OAS.

Nombre Descripción

Plan General del Proyecto

Este artefacto define los parámetros para realizar el direccionamiento y seguimiento al proyecto. Especifica los objetivos de alto nivel de las iteraciones y sus correspondientes hitos.

Plan de Iteración Comunica los objetivos, la asignación de tareas y los criterios de evaluación para una iteración dada.

Unidades de Trabajo Diarias

Contiene una lista de los trabajos programados diariamente y que responden a los objetivos definidos en la Iteración y en el proyecto

Cierre de iteración Este documento registra los resultados de una iteración

Visión Contiene los lineamientos de los requerimientos nucleares visionados del sistema, especificado las necesidades y características claves de los Interesados.

Requisitos de

Captura la secuencia de acciones que un sistema realiza y que genera un resultado observable que es de valor para aquellos que interactúan con el sistema.

Glosario Este artefacto define términos importantes usados en el proyecto interesados y el equipo de desarrollo

22

Nombre Descripción

Bloc de notas de la Arquitectura

Contiene las decisiones, razonamientos, asunciones, explicaciones e implicaciones sobre la arquitectura en formación.

Documento de Diseño

Artefacto documenta las especificaciones técnicas en cuanto al diseño del software y se complementa con diagramas de clases, diagramas de colaboración, diagramas de secuencia entre otros.

Control de Cambios

Este artefacto es utilizado para documentar las solicitudes de cambio de los diferentes subprocesos que surgen al interior del proyecto por parte de los interesados o miembros del equipo del proyecto.

Caso de prueba

Son la especificación de un conjunto de pruebas de entradas, condiciones de ejecución y resultados esperados, los cuales son identificados para el propósito de realizar una evaluación de una aspecto particular en un escenario

específico.

Registro de

Pruebas Este artefacto recolecta los resultados de la ejecución de

una o más pruebas en un ciclo completo de pruebas.

23 5.1.3. Proceso de Desarrollo

5.1.3.1. Ficha de Caracterización de Subproceso

En la Figura 4. Se presenta la respectiva ficha de caracterización de subproceso, referente al desarrollo de la solución:

Figura 4. Ficha desarrollo de solución proceso OpenUP/OAS.

Fuente: Oficina Asesora de Sistemas, “Guía rápida proceso de desarrollo OpenUP/OAS,” Universidad Distrital Francisco José de Caldas, 2011.

24

Figura 5. Subproceso de desarrollo OPENUP/OAS.

Fuente : Oficina Asesora de Sistemas, “Guía rápida proceso de desarrollo OpenUP/OAS,” Universidad Distrital Francisco José de Caldas, 2011.

5.1.3.2. Actividades de desarrollo

Se especifica el conjunto de actividades a desarrollar por el rol desarrollador teniendo en cuenta el proceso de desarrollo OPENUP/OAS, como se describen a continuación:

Identificar las oportunidades de reutilización de código: esta actividad consiste en identificar módulos de código existente u otros elementos que puedan ser utilizados en el proceso de desarrollo del sistema, lo cual es importante para tener un manejo adecuado del diseño y desarrollo. Se debe tener siempre en consideración elementos de software libre o de propiedad de la institución manteniendo un especial cuidado por el respeto de las normas y legislación relacionada con el derecho de autor.

La mejor manera de lograr que un equipo encuentre oportunidades de reciclaje es ejercitar buenas prácticas de generación de código y diseño. Entre las consideraciones a tener en cuenta se encuentra que las clases deben ser pequeñas, cohesivas y fáciles de entender para poder ofrecer oportunidades de reutilización. Se deben tener clases separadas cuando se encuentre funcionalidad que pueda ser separada, entre otras.

25

librerías de terceros, Librerías construidas dentro del lenguaje, ejemplos de código de tutoriales, libros, colegas, código de sistemas existentes, productos de software libre (asegurando que se siguen todos los acuerdos de licencia aplicables).

Transformar el diseño en puesta en funcionamiento: Es importante utilizar herramientas de modelado sofisticadas que permiten obtener gran cantidad de código fuente directamente de la transformación de los modelos, agregando tareas de programación sobre el código generado para completar la puesta en funcionamiento.

Existen varias técnicas para que de forma automática se transforme el diseño en artefactos de puesta en funcionamiento:

● Se pueden aplicar patrones estándar para generar elementos de puesta en producción y de diseño a partir de artefactos relacionados. Por ejemplo, un patrón de transformación estándar puede ser aplicado sobre tablas de datos para crear clases Java que permiten acceder a tales tablas. Otro ejemplo consiste en utilizar marcos de trabajo tales como el Eclipse Modeling Framework para generar código que almacene datos de acuerdo al modelo y que además cree interfaces de usuario para poblar tales estructuras de datos. Un motor de patrones o de transformación puede ser usado para crear la puesta en funcionamiento, o la puesta en funcionamiento puede ser hecha de forma no automatizada. Los motores de patrones son fáciles de emplear y ofrecen mayor confiabilidad. En todo caso escribir código que implemente un determinado patrón tendrá menos errores que aquel código que implemente técnicas novedosas o diseños únicos.

● Los modelos pueden ser detallados y utilizados para generar una puesta en funcionamiento. Tanto los diagramas de estructura (diagramas de clases y diagramas de paquetes) como los de comportamiento (diagramas de colaboración, diagramas de estado y diagramas de actividades) pueden ser utilizados para generar código ejecutable. Estas versiones generadas podrán ser refinadas de acuerdo a las necesidades. ● El diseño debe ser independiente, en varios grados, de la plataforma en

la cual se implementa. Modelos de diseño específicos para una plataforma o aún el código ejecutable pueden ser generados si se aplican diferentes reglas de transformación a abstracciones de alto nivel. Este es el enfoque de la Arquitectura Conducida por Modelos que propone el Object Management Group (OMG).

26

más adelante (“a mano”) con código no especificado en el diseño o que no haya podido ser transformado.

En todos los casos algunas abstracciones de diseño (clases, componentes, etc) deben ser detalladas para poder ser transformadas en puesta en funcionamiento.

Escribir el código fuente: Escribir el código fuente para hacer una puesta en funcionamiento que cumpla con el diseño y el comportamiento esperado. Teniendo en cuenta los siguientes aspectos:

● Examinar los requerimientos: como no toda la información de los requerimientos se puede colocar en los modelos, se debe verificar lo que no se cumple en la implementación, para depurar a través de la programación directa

● Reconstruir el código para mejorar el diseño, por medio de re-adaptación, que es una técnica con la que se mejora la calidad del código a partir de pequeños, y seguros cambios

● Afine los resultados de implementaciones existentes mejorando el desempeño, la interfaz de usuario, la seguridad y otras áreas no funcionales.

Estas consideraciones se deben poner en práctica teniendo en cuenta estándares que describen varias convenciones acerca de cómo escribir el código fuente. Su principal tarea es asegurar la consistencia, calidad y una puesta en funcionamiento fácil de entender.

El uso de los estándares para la escritura de código es una de las prácticas más extendidas en la práctica de realización de software y se vuelve imperativa cuando se labora en ámbitos de alta colaboración. Los grupos de desarrollo deben tener una forma estándar para nombrar y dar formato a las cosas de tal manera que el código fuente se pueda entender rápidamente y la propiedad del mismo pueda ser cambiada sin detrimento de la calidad.

Idealmente los estándares para la escritura de código debe ser el resultado de un consenso entre el equipo de trabajo ya que esta tarea ayuda a la rápida adopción de los estándares.

Los estándares mencionados pueden cubrir áreas como:

27

● Organización de los archivos: Incluye convenciones para colocar nombres a los archivos y cómo éstos deben ser organizados dentro del árbol de directorios del sistema.

● Estándares para los comentarios: Poner demasiado énfasis en los

● Convenciones para la escritura de código: Aplicación de convenciones específicas a nivel de código.

● Espacio en blanco: Aunque algunos autores lo consideran como de menor impacto es un hecho que el manejo adecuado de los espacios en blanco, los saltos de línea, las sangrías y las líneas en blanco facilitan la lectura del código.

Evaluar la implementación: verificar que el funcionamiento de lo implementado este en concordancia con el propósito por el cual fue construido. Es un paso fundamental para evaluar la calidad del producto.

Esto se dará a medida que se realicen las respectivas pruebas funcionales y no funcionales que permitan tener un acercamiento a la calidad del software implementado en concordancia con las especificaciones del usuario, teniendo en cuenta que dichas pruebas harán parte de la gestión de cambios del proyecto y especificado en el proceso de desarrollo OPENUP/OAS.

Comunicar decisiones importantes: Comunicar rápidamente el impacto de cambios no esperados en el diseño o los requerimientos. Los problemas y restricciones que no se hayan tenido en consideración deben ser comunicados al equipo de desarrollo. El impacto de problemas descubiertos durante la puesta en funcionamiento debe ser incorporado para las decisiones futuras.

28 5.1.3.3. Guías

5.1.3.3.1. Integración Continua

La integración continua introduce la práctica de integrar continuamente los conjuntos de cambios para reducir el esfuerzo requerido para mezclar desarrollos en paralelo y para encontrar fallos de forma temprana. Con este concepto se conduce el trabajo colaborativo.

La integración continua es una práctica de puesta en funcionamiento donde los integrantes del equipo integran su trabajo con los trabajos de otros realizadores de software y lo prueban de forma local antes de hacer su trabajo disponible. Esto habilita la detección de errores de integración al determinar errores de compilación, notificaciones del sistema o fallos reportados por las herramientas de pruebas. Idealmente la integración se realiza de forma automática antes de elevar los cambios al siguiente nivel de operación

La integración continua provee los siguientes beneficios:

1. Mejora la retroalimentación. La integración continua muestra un progreso constante y demostrable.

2. Mejora la detección de errores. La integración continua permite que los errores se detecten de forma temprana muchas veces a los pocos minutos después de que se han inyectado dentro del producto. Para aumentar la efectividad de la integración se recomienda el uso de herramientas para la realización de pruebas.

3. Mejora la colaboración. La integración continua facilita que los integrantes del equipo trabajen colaborativamente de forma segura. Fomenta la realización de cambios, la integración local y la detección temprana de conflictos en el código.

4. Mejora la integración del sistema. Cada uno de los realizadores se cerciora que el sistema puede ser integrado mitigando la posibilidad de error asociada a esta actividad.

5. Reduce el número de cambios – a partir de trabajos paralelos – que necesitan ser mezclados y verificados.

6. Reduce el número de errores encontrados durante las pruebas al sistema ya que todos los conflictos son resueltos antes de hacer disponible el conjunto de cambios.

7. Reduce los riesgos técnicos. Siempre se podrá contar con un sistema actualizado frente al cual realizar las pruebas.

29

5.1.3.3.2. Reconstrucción

Este concepto explica los mecanismos para mejorar el diseño de código existente de tal forma que no se afecte -si no es necesario su comportamiento externo.

La reconstrucción es una vía disciplinada para reestructurar el código cuando pequeños cambios se han realizado para mejorar el diseño. Un aspecto importante es que se mejora el diseño pero sin cambiar el comportamiento. Una reconstrucción no adiciona ni remueve funcionalidad.

La reconstrucción fomenta la evolución del código a través del tiempo con un enfoque iterativo e incremental hacia la puesta en funcionamiento.

Estos son los tipos de reconstrucción:

1. Reconstrucción de código. Consiste en la reconstrucción del código fuente fruto de la programación. Algunos ejemplos pueden incluir el renombrado de métodos, la encapsulación de campos, la extracción de clases, la introducción de comentarios y la reestructuración de métodos. 2. Reconstrucción de bases de datos. Son cambios a los esquemas de la

base de datos que mejoran el desempeño mientras que mantienen la semántica en la información y el desempeño. Ejemplos incluyen renombrar columnas, dividir una tabla, mover algún método, reestructurar procedimientos almacenados, reemplazar LOB con Table, agregar restricciones a las columnas y utilizar fuentes de datos oficiales.

3. Reconstrucción de Interfaz de Usuario (IU). La reconstrucción de IU consiste en realizar cambios simples en la interfaz gráfica mientras se mantiene su semántica. Ejemplos incluyen la reacomodación de campos en los formularios, aplicar estilos, etc.

5.1.3.2.3. Transformar el diseño en Puesta en Funcionamiento

30

5.1.3.3.4. Elevar los Cambios al Siguiente Nivel de Operación

Durante el desarrollo iterativo de software los grupos de trabajo crean numerosos conjuntos de Cambio que son agrupados en una Construcción. Una construcción se inicia combinando el trabajo completado por uno o más realizadores y resolviendo los conflictos que pueden existir entre los diversos cambios. Idealmente, la construcción es después sometida a una completa batería de pruebas para poder determinar si tiene la calidad suficiente que le permita moverse al ambiente de producción.

A medida que los cambios progresan desde el desarrollo a la producción es benéfico conocer en la presente construcción:

Ámbito de pruebas– identificar los elementos y las versiones que deben ser verificadas.

● Qué cambios se tienen (unidades de trabajo completas)

● Qué cambios se han implementado parcialmente (unidades de trabajo que se han implementado parcialmente)

31

5.1.3.3.6. Estándares para la Escritura de Código

Son estándares que describen varias convenciones acerca de cómo escribir el código fuente. Su principal tarea es asegurar la consistencia, calidad y una puesta en funcionamiento fácil de entender.

Los estándares mencionados pueden cubrir áreas como:

● Estándares para asignación de nombres: Esto incluye la forma en que se le da nombre a todos los elementos dentro del código. Cuando se cubren elementos de gran escala pueden solapar los estándares de diseño. ● Organización de los archivos: Incluye convenciones para colocar nombres

a los archivos y como éstos deben ser organizados dentro del árbol de específicas a nivel de código.

● Espacio en blanco: Aunque algunos autores lo consideran como de menor impacto es un hecho que el manejo adecuado de los espacios en blanco, los saltos de línea, las sangrías y las líneas en blanco facilitan la lectura del código.

5.1.3.3.7. Puesta en Funcionamiento

La puesta en funcionamiento es una versión funcional del sistema o una parte del sistema que implementa un subconjunto de las capacidades que proveerá el producto final.

Entregar productos, incrementando cada vez la funcionalidad, con valor para los usuarios y los clientes. Proveer un artefacto que pueda ser probado.

32

pueden ser construidas que representan las partes “físicas” que hacen que el sistema sea construido y organizado en una forma que sea fácil de entender y administrar.

Este artefacto es una combinación de uno o más de estos elementos: ● Archivos de código fuente

● Archivos de datos ● Scripts de construcción

● Otros archivos que son creados como ejecutables dentro del sistema.

5.2. La nómina: estructura, partes y elementos básicos.

La nómina es el sistema contable de la empresa para mantener un registro con el salario, cargo, deducciones, así como otros gastos y rendimientos que genera cada uno de sus empleados. La nómina es el documento que se entrega mensualmente a todos los trabajadores en el que aparece el detalle del salario que recibe, junto con las deducciones que se le practican de dicho salario, bien sea por descuentos obligatorios marcados por la legislación vigente, bien sea por otro tipo de descuentos como anticipos, o deducciones para seguros de salud.

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

■ 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 extrasalariales 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, bien por otro tipo de deducciones que haya que aplicarle a la nómina, como anticipos o, embargos en la nómina.

■ Líquido a percibir, dado que la nómina tiene consideración de documento acreditativo del pago de salarios cerrando los pagos pendientes al trabajador para el periodo estipulado. ■ Detalle de las bases de cotización de la nómina

■ Lugar de emisión y firma y sello por la empresa y trabajador.

33

5.2.1. Retribución bruta; conceptos que conforman el salario bruto

La suma total de todos los conceptos que hay que abonar al trabajador dan origen a la retribución bruta mensual. La nómina tiene por norma general periodos 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 bruto tenemos dos grupos diferenciados:

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

Percepciones extrasalariales; en el que se incluyen conceptos que no tienen la consideración pura de salario, como pueden ser dietas, gastos de locomoción o pluses por retribuciones en especie como el plus por desgaste de herramientas

- Percepciones salariales

Tal y como hemos definido anteriormente, la cantidad de conceptos que se pueden incluir dentro de las percepciones salariales es muy amplia y no es genérica, porque cada empresa tiene un convenio colectivo distinto y cada uno de estos textos incluyen una distribución distinta de los pagos que hay que realizar.

Normalmente, nos podemos encontrar con conceptos como:

■ Salario Base, que corresponde al pago mensual mínimo que se tiene que realizar para un trabajador dentro de la categoría en la que está encuadrado.

Complementos; como cantidades adicionales que complementan al salario base en el caso de que se cumplan unos determinados requisitos de productividad, cumplimiento horario, productividad, trabajos penosos, nocturnos en días festivos.

Parte proporcional de paga extra. Todos los convenios colectivos regulan el pago de una o varias pagas extras. Normalmente se abonan entre dos y cuatro pagas extras anuales y puede darse el caso de que la paga extra se encuentre prorrateada.

- Percepciones extrasalariales

34

de herramientas o cantidades indemnizatorias por cambio de centro de trabajo o de localidad.

5.2.2. Descuentos en la nómina

Tal y como hemos explicado anteriormente, en la nómina nos podemos encontrar dos tipos de descuentos diferentes, bien los descuentos obligatorios por ley o bien los descuentos que se deban aplicar por cualquier otro tipo de normativas.

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

5.3. Régimen salarial de la universidad distrital

la universidad distrital francisco José de Caldas, como entidad pública tiene la potestad de establecer su propio régimen salarial, por medio de su máximo organismo de dirección y gobierno, según lo establecido por la sala de consulta y servicio civil del consejo de estado en 1999. por lo tanto por medio del acuerdo del 2003 se fija el régimen salarial para los empleados públicos de la universidad distrital francisco josé de caldas(Acuerdo N° 003 / 2003 del consejo superior universitario “Por medio del cual se fija el régimen salarial para los Empleados Públicos de la Universidad Distrital Francisco José de Caldas”, vía web).

El régimen salarial aplicable a los empleados públicos administrados, se constituye por los siguientes conceptos:

A. asignación básica

B. gastos de representación C. prima técnica

D. auxilio de transporte E. subsidio de alimentación

F. viáticos percibidos por funcionarios en comisión cuando excedan de 180 días

G. horas extras, dominicales y festivos H. prima secretarial

I. prima semestral

J. bonificación por servicios prestados K. prima por antigüedad

Asignación básica: asignación mensual correspondiente a cada empleo, la cual está determinada por sus funciones y responsabilidades

35

Prima técnica: reconocimiento económico para atraer o mantener en el servicio del estado, a funcionarios altamente calificados. Mensualmente a los empleos que pertenezcan a los niveles; directivo, asesor, ejecutiva y profesional, en el porcentaje que para cada grado salarial determine el consejo superior universitario y se liquidaran sobre la asignación básica que devengue el funcionario.

Auxilio de transporte: subsidia los gastos que ocasiona el transporte en desarrollo de la jornada laboral ordinaria, siguiendo términos y condiciones que por decreto establezca el gobierno nacional.

Subsidio de alimentación: reconocimiento mensual o proporcional al tiempo laboral, que se hace a los empleados públicos de la universidad distrital, siguiendo términos y condiciones que por decreto establezca el gobierno nacional.

Viáticos percibidos por los funcionarios en comisión: reconocimiento que se hace a los empleados públicos de la universidad distrital, que deben viajar dentro o fuera del país, en comisión de servicios, de acuerdo a la escala que para ello determine el consejo superior universitario.

Horas extras: reconocimiento que se hace al empleado cuando sea necesario realizar trabajos en horas distintas de la jornada de labor.

Prima secretarial: reconocimiento económico mensual, que se hace para mantener el servicio del estado, a personal calificado en el desempeño del cargo de secretario.

Prima semestral: prima semestral que reconoce la universidad, establecida para el sector central del distrito capital, que equivale a 37 días de salario y que se paga los primeros 15 días de junio.

Bonificación por servicios prestados: reconocimiento que se hace al empleado, cada vez que cumpla un año continuo de labor en la entidad, equivalente al 50 % o 35% del valor conjunto de la asignación básica y de los gastos de representación, de acuerdo a los montos máximos señalados para cada porcentaje por el gobierno nacional para los empleados públicos de la rama ejecutiva del poder público

Prima por antigüedad: los empleados públicos administrados de la universidad distrital tendrán derecho al reconocimiento de prima por antigüedad. Los términos y condiciones para que proceda dicho reconocimiento serán establecidos por el consejo superior universitario

37

CAPÍTULO 6. METODOLOGÍA

La metodología aplicada a este proyecto se encuentra bajo el proceso de desarrollo OPENUP/OAS, que se encuentra debidamente aprobado en la Universidad Distrital Francisco José de Caldas, mediante la Resolución de Rectoría número 461 de 2011.

Bajo dicha metodología de solución de software al manejo de la gestión de nómina y en detalle la forma y características de trabajo dadas para la fase de desarrollo, se describe las actividades y la manera en la cual se desarrolló el sistema.

Por ende, con el fin de brindar el cumplimiento a la respectiva pasantía realizada para la construcción del gestor de nómina, se trabajaron las fases de inicio, elaboración y construcción, a continuación se nombre en detalle cada una de las fases en las cuales se trabajó:

Fase de Inicio

Como primera instancia y en el inicio del proyecto bajo las respectivas planeaciones y gestiones del proyecto junto con los levantamientos de las especificaciones de caso de uso respectivas que soportan las necesidades de construcción del sistema de gestión de nómina, se da el inicio del proyecto.

Por consiguiente, a medida en que se avanzó dichas actividades descritas anteriormente, el grupo de desarrollo se reunió en la necesidad de poseer el conocimiento del framework de desarrollo en el cual se trabajó el sistema llamado “SARA”, propio de la oficina asesora de sistemas. En este sentido se realizaron varias sesiones de capacitaciones del framework y generalidades de los respectivos lenguajes que en el mismo se manejan, como php, javascript, pl sql, ajax, etc; realizadas por el líder de desarrollo y el grupo de la misma área de la oficina asesora de sistemas, cumpliendo con la actividad del rol de desarrollo al identificar la reutilización de código a través del framework, junto con las librerías y/o plugins que en este se pueden implementar.

38

gestión de parámetros, con el fin de ir poniendo en práctica los conocimientos de programación adquiridos en las capacitaciones realizadas.

Fase de elaboración

En esta fase de manera consiguiente se empezó a construir el desarrollo de manera oportuna, atendiendo a las especificaciones de caso de uso que se definieron por la fase de análisis. Para esto fue importante como primera parte, realizar la revisión inicial de los casos de uso y especificaciones de los documentos arquitecturales para validar dichos levantamientos, o ya sea enriquecerlos, o finalmente por que requieran algún tipo de ajuste de acuerdo al punto de vista del desarrollo.

Como segunda parte, se procedió a realizar los respectivos desarrollos con las especificaciones de las fases anteriores validadas para su oportuna construcción, junto con el componente de pruebas funcionales por el mismo grupo de desarrollo (cabe destacar que todas estas actividades fueron planeadas de manera atenta por las personas encargadas de la gestión del proyecto). Seguido a esto se realizaban las entregas de los desarrollos en reuniones de los diferentes grupos y personas participantes en el proyecto, con el fin de validar el desarrollo o en dado caso que se requiera algún ajuste al mismo, tener la discusión de la observación y así mismo poseer nuevas decisiones para la realización del artefacto si era necesario.

En el caso en que los artefactos de software en dichas reuniones fueran avalados a primera vista, se definieron sesiones de control de cambios en dado caso en el cual el grupo de análisis en sus pruebas de los artefactos requirieron algún ajuste o modificación del artefacto (todas estas actividades fueron respectivamente documentadas en los respectivos archivos del sistema de la oficina asesora de sistemas como control en dichos procesos), una vez cada artefacto de software luego de dichas pruebas resultara aceptado, se registraba como artefacto solucionado.

39 Fase de Construcción

En la fase de construcción del sistema de gestión de nómina se hace presente la mayor parte del desarrollo esencial del sistema, mediante el cual se brinda la finalidad del proyecto, donde de manera similar a la fase de elaboración pero con la diferencia de un mayor grado de trabajo en cuanto a desarrollo, inicialmente se realizaron las respectivas revisiones y validaciones de los casos de uso y especificaciones de arquitectura brindadas, se desarrollaron dichas especificaciones como artefactos de software en donde se realizaron las respectivas entregas del mismo bajo reuniones de trabajo semanales o por iteración, con las personas involucradas en el proyecto.

De acuerdo a los resultados obtenidos de las observaciones de las reuniones se realizaban con ajuste en la planeación los respectivos ajustes o modificaciones necesarias para satisfacer de forma efectiva los requerimientos. De igual forma se planificaron los respectivos tiempos de controles de cambios como resultados de las evaluaciones de pruebas realizadas por el grupo analista.

En esta fase en el proyecto de gestión de nómina en curso se dio solución como desarrollo de artefactos esenciales en el objetivo del sistema , como los módulos de conceptos, novedades, vinculación de personas naturales, gestión de nómina, asociación de conceptos, pre liquidación, reportes , etc., entre otros. Bajo la complejidad de dichos módulos desarrollados se realizaron actividades de comunicación inmediata con los integrantes del grupo analista y arquitectura

para solución de dudas presentes en el desarrollo.

41

CAPÍTULO 7. DESARROLLO DEL PROYECTO

El proyecto en el cual se realizó el respectivo desarrollo de acuerdo a las especificaciones y contribuciones de la fase de análisis y arquitectura respectiva comprende la gestión de nómina de la universidad Distrital, sin embargo el enfoque del proyecto se globaliza para ser independiente del modelo de negocio en el cual se ha implantado. El sistema desarrollado para tal fin y que tiene como finalidad el presente proyecto de grado tiene como nombre TITAN. Por política de nombramientos en los proyectos en la oficina asesora de sistemas de utilización de nombres de personajes de la mitología griega para sus sistemas y con el fin de desarrollar un software, el cual contenga como característica primordial el ser poderoso, ya sea por su funcionamiento o importancia vital como lo es un sistema de nómina y al igual que lo fueron los titanes en la mitología griega como una raza poderosa y gobernante en la edad de oro, se nombra el sistema de gestión de nómina como TITAN.

7.1. Listado de artefactos de software

42

Tabla 6. Listado de Artefactos de Software

Módulo del registradas, dejándolas activas o inactivas en el sistema

Modificar Persona Natural

Permite modificar los datos personas naturales ya registradas en el sistema.

Consultar Persona Natural

El sistema permite consultar todas las personas naturales registradas y buscar alguna persona en particular, para ver en detalle todo sus datos

Permite registrar personas jurídicas con sus respectivos datos y registradas, dejándolas activas o inactivas en el sistema

Modificar Persona Jurídica

Permite modificar los datos personas jurídicas ya registradas en el sistema.

Consultar Persona Jurídica

El sistema permite consultar todas las personas naturales registradas y buscar alguna persona en particular, para ver en detalle todo sus datos registrados.

Aprobación

Aprobar Solicitud Permite realizar la aprobación de una solicitud de persona natural para ingreso al sistema.

Consultar Aprobaciones

Ofrece la visualización detallada de las aprobaciones realizadas de solicitudes de personas naturales. Modificar

Aprobaciones

Permite la modificación de aprobaciones realizadas para las solicitudes de personas naturales,

Gestión Parámetros

Cargo

Registrar Cargo Permite registrar los diferentes cargos que se van a relacionar a los funcionarios.

Modificar Cargo El sistema permite modificar los datos de un determinado cargo seleccionado.

Consultar Cargo Ofrece la opción de consultar todos los cargos registrados y seleccionar alguno para ver en detalle la información del cargo

43

Módulo del

sistema Submódulo

Artefacto de

Software Descripción activas o inactivas en el sistema

Entidades Promotoras de Salud

Registrar EPS Permite registrar las diferentes EPS y sus correspondientes datos.

Modificar EPS El sistema permite modificar los datos de una determinada EPS

Permite registrar los diferentes fondos de pensión y sus los fondos de pensión y seleccionar alguno para ver en detalle la información

Inactivar Fondos de Pensión

Permite cambiar de estado a los fondos de pensión registrados, dejándolas activas o inactivas en el

Permite registrar las diferentes cajas de compensación que se van a los cargos registrados y seleccionar alguno para ver en detalle la información del cargo

Inactivar Caja de Compensación

Permite cambiar de estado a los cargos registrados, dejándolas activas o inactivas en el sistema

ARL

Registrar ARL Permite registrar administradora de riesgos laborales (ARL) con sus respectivos datos.

Modificar ARL El sistema permite consultar todas las ARL registradas y buscar alguna en particular, para ver en detalle todo sus datos registrados.

Consultar ARL Permite modificar los datos de las ARL ya registradas en el sistema. Inactivar ARL Ofrece la opción de cambiar de

44

Permite registrar leyes y decretos con sus respectivos datos y

Permite modificar los datos de leyes y decretos ya registrados en el registradas, dejándolas activas o inactivas en el sistema.

Actividades Económicas

Registrar Actividades Económicas

Permite registrar Actividades Económicas

Modificar Actividades Económicas

El sistema permite modificar los datos de una determinada actividad económica.

Consultar Actividades Económicas

Ofrece la opción de consultar todas las actividades económicas y seleccionar alguna para ver en

Permite registrar los diferentes tipo de vinculación que se van a registrados y seleccionar alguno para ver en detalle su información Inactivar Tipo de

Vinculación

Permite cambiar de estado a los cargos registrados, dejándolas activas o inactivas en el sistema

Actos

Administrativos

Registrar Actos Administrativos

Permite registrar los diferentes actos administrativos con sus respectivos datos. actos administrativos, dejándolas activas o inactivas en el sistema. Registrar Parámetros

de Liquidación