Proyecto de Grado_ Sisrececo

UNIVERSIDAD TECNOLÓGICA BOLIVIANA INGENIERÍA DE SISTEMAS

PROYECTO DE GRADO SISTEMA INFORMÁTICO DE CONTROL DE PLANILLAS DE PAGO (RECONOCIMIENTO ECONÓMICO – D.S. 282)

UNIDAD EJECUTORA DE LUCHA INTEGRAL CONTRA EL NARCOTRÁFICO “U.E.L.I.C.N.”

POSTULANTE

:

Edwin Estrada Vargas

TUTOR

:

Lic. Juan Mario Eguivar Guerra

LA PAZ – BOLIVIA

I

Dedicatoria. Con mucho cariño dedico este proyecto a quien un día me dijo; “Mira que te mando que te esfuerces y seas valiente. No temas, ni desmayes; porque yo, tu Dios, estaré contigo donde quiera que vayas”.

A mi papas Alberto y Rosa, quienes con amor y comprensión coadyuvaron siempre en los objetivos trazados.

A Jacqueline, Camila, Fanny, Carlos Alberto y Samy, agradecerles eternamente su comprensión.

Especialmente a mi hijo Joaquín, que cada día lo siento más cerca que lejos, en un allá que es siempre es aquí.

II

Agradecimientos Contar con el conocimiento, experiencia y consejos de mi tutor, fue fundamental para el desarrollo de este proyecto, las instrucciones y consejos brindados alinearon el rumbo correcto para la conclusión de este proyecto, gracias Lic. Juan Mario Eguivar Guerra.

El principio de una realidad son los sueños; la oportunidad y confianza que me brindaron hicieron de este principio una realidad Lic. Vivian Flores, gracias por abrirme las puertas de la “U.E.L.I.C.N.”; Lic. Ximena Berdeja, gracias por su confianza y por brindarme día a día sus conocimientos impartidos; Lic. Juan Carlos Peralta, gracias por compartir su experiencia laboral, consejos y sobre todo su amistad. Hermosos recuerdos, experiencias y nuevas oportunidades son el resultado de lo vivido con todo el personal de la Unidad Ejecutora de Lucha Integral Contra el Narcotráfico “U.E.L.I.C.N.”

III

RESUMEN “La administración de recursos humanos no constituye un fin en sí misma, sino un medio para alcanzar la eficacia y eficiencia de las organizaciones a través del trabajo de personas y para establecer condiciones favorables que les permitan conseguir los objetivos individuales”. La Unidad Ejecutora de Lucha Integral Contra el Narcotráfico “U.E.L.I.C.N.”, es una institución gubernamental dependiente del Ministerio de Gobierno del estado Plurinacional de Bolivia, con la misión específica de gestionar los recursos asignados al Programa de Administración Integral de Lucha Contra el Narcotráfico, con destino a las labores de interdicción del tráfico de drogas, racionalización y erradicación de cultivos de coca.

El presente proyecto pretende coadyuvar a este fin, a través de la implementación del SISTEMA INFORMÁTICO DE CONTROL DE PLANILLAS DE PAGO (RECONOCIMIENTO ECONÓMICO – D.S. 282), el cual permite la automatización de procesos referentes a la administración de recursos provenientes del Tesoro General del Estado, facilitando el control, del cumplimiento de normas y reglamentos vigentes en la institución, además de registro de una base de datos de los efectivos reconocidos en el D.S. 0282, ofreciendo información ordenada completa, oportuna para una correcta toma de decisiones, intuitivo y de fácil acceso.

De

esta

manera

el

sistema

denominado

SISRECECO,

SISTEMA

DE

RECONOCIMIENTO ECONÓMICO; aporta de manera significativa a una administración transparente, eficiente, eficaz y moderna, el mismo fue desarrollado utilizando recursos y herramientas de tecnología informática, basada en metodología XP.

A ÍNDICE

INTRODUCCIÓN .................................................................................................. 1

1. 1.1

ANTECEDENTES .................................................................................................. 2

1.2

LA LUCHA CONTRA EL NARCOTRÁFICO EN NUESTRO MEDIO .............. 2

1.3

UNIDAD

EJECUTORA

DE

LUCHA

INTEGRAL

CONTRA

EL

NARCOTRÁFICO “U.E.L.I.C.N.” ......................................................................... 4 1.4

BASE LEGAL ......................................................................................................... 4

1.5

ESTRUCTURA ORGANIZACIONAL DE LA “U.E.L.I.C.N.” ............................ 6

1.6

PAGO DE RECONOCIMIENTO ECONÓMICO .................................................. 8

1.7

PROBLEMÁTICA ................................................................................................ 10

1.8

OBJETIVOS .......................................................................................................... 11

1.9

JUSTIFICAR ......................................................................................................... 12

1.10 ALCANCES Y LIMITES ..................................................................................... 13

B

1.11 METODOLOGÍA .................................................................................................. 15 MARCO TEÓRICO .............................................................................................. 17

2. 2.1

MARCO CONCEPTUAL ..................................................................................... 18

2.2

CONTROL DE PERSONAL ................................................................................ 18

2.3

HISTORIA DE LA MODERNA ADMINISTRACIÓN DE PERSONAL ........... 18

2.4

DEFINICIÓN DE CONTROL DE PERSONAL .................................................. 18

2.5

IMPORTANCIA DEL CONTROL DE PERSONAL ........................................... 19

2.6

PLANILLAS DE PAGO ....................................................................................... 19

2.7

TIPOS DE PLANILLAS DE PAGO ..................................................................... 20

2.8

INGENIERÍA DE SOFTWARE ........................................................................... 20

2.9

PROCESO DE DESARROLLO DE SOFTWARE............................................... 20

2.10 MODELO EVOLUTIVO DEL PROCESO DE SOFTWARE ............................. 21 2.11 INGENIERÍA DE REQUISITOS ......................................................................... 22 2.12 PRINCIPIO DE PARETO ..................................................................................... 24 2.13 ALCANCE VARIABLE ....................................................................................... 25 2.14 TECNOLOGÍA UTILIZADA ............................................................................... 26 2.15 REQUERIMIENTOS TÉCNICOS........................................................................ 27 2.16 ANÁLISIS ............................................................................................................. 28 2.17 DISEÑO DE BASE DE DATOS .......................................................................... 28 2.18 BASE DE DATOS RELACIONAL ...................................................................... 30 2.19 MODELADO DE DATOS .................................................................................... 30

C 2.20 NORMALIZACIÓN DE BASE DE DATOS ....................................................... 32 2.21 FORMAS NORMALES ........................................................................................ 32

2.22 DIAGRAMA ENTIDAD RELACIÓN ................................................................. 34 2.23 DISEÑO................................................................................................................. 35 2.24 PROCESO DE DISEÑO DE OBJETOS ............................................................... 36 2.25 DISEÑO DE ALGORITMOS Y ESTRUCTURA DE DATOS ........................... 37 2.26 METODOLOGÍA DE DESARROLLO DE SOFTWARE ................................... 37

D 2.27 IMPLEMENTACIÓN ........................................................................................... 52 2.28 PRUEBAS DE CAJA NEGRA ............................................................................. 52 2.29 PRUEBAS METODOLOGIA XP......................................................................... 57

2.30 SEGURIDAD ........................................................................................................ 58 2.31 CIFRADO AES - 256 ............................................................................................ 59 2.32 CIFRADO DE BASE DE DATOS ....................................................................... 59

MARCO DE DESARROLLO .............................................................................. 61

3. 3.1

INTRODUCCIÓN ................................................................................................. 62

3.2

RECOPILACIÓN DE NECESIDADES ............................................................... 62

3.3

MAPA DE PROCESOS ACTUAL – “U.E.L.I.C.N.” ......................................... 64

3.4

MATRIZ DE PROCESOS .................................................................................... 65

3.5

CEDIMIENTO RECONOCIMIENTO ECONÓMICO ........................................ 66

3.6

IDENTIFICACIÓN DE ACTORES Y CASOS DE USO .................................... 72

E 3.7

ANÁLISIS DEL DOMINIO ................................................................................. 77

3.8

NECESIDADES DEL SISTEMA ......................................................................... 77

3.9

IDENTIFICACIÓN DEL PRODUCTO ................................................................ 78

3.10 ¿QUE HARÁ EL SISTEMA? ............................................................................... 78 3.11 BENEFICIOS DEL SISTEMA ............................................................................. 78 3.12 ANÁLISIS ............................................................................................................. 79

3.13 REPRESENTACION DE ACTIVIDADES .......................................................... 91

3.14 DIAGRAMAS DE CLASE ................................................................................. 101 3.15 SECUENCIA DE SISTEMA .............................................................................. 102 3.16 ANÁLISIS Y DISEÑO ....................................................................................... 106

F 3.17 INTERFAZ GRAFICA DEL USUARIO ............................................................ 107 CALIDAD DE SOFTWARE .............................................................................. 110

4. 4.1

INTRODUCCIÓN ............................................................................................... 111

4.2

CONFIABILIDAD .............................................................................................. 113

4.3

FACILIDAD DE USO ........................................................................................ 115

4.4

FUNCIONALIDAD ............................................................................................ 116

4.5

CALIDAD WEB ................................................................................................. 119

4.6

WEBDIRECT ...................................................................................................... 121 COSTO BENEFICIO .......................................................................................... 123

5. 5.1

INTRODUCCIÓN ............................................................................................... 124

5.2

ANÁLISIS DE COSTO BENEFICIO ................................................................. 125

5.3

MÉTODOS PARA EL ANÁLISIS DE COSTO/BENEFICIO ........................... 127

5.4

MODELO COCOMO.......................................................................................... 128

5.5

JUSTIFICACIÓN DE LOS VALORES.............................................................. 132 CONCLUSIONES Y RECOMENDACIONES .................................................. 135

6. 6.1

INTRODUCCIÓN ............................................................................................... 136

6.2

CONCLUSIONES ............................................................................................... 136

6.3

RECOMENDACIONES ..................................................................................... 138 ANEXOS ............................................................................................................ 140

7. 7.1

ÁRBOL DE PROBLEMAS ................................................................................ 141

7.2

ÁRBOL DE OBJETIVOS ................................................................................... 142

G 7.3

MATRIZ – MARCO LÓGICO ........................................................................... 143

7.4

ENTREVISTAS .................................................................................................. 145

8.

BIBIOGRAFÍA ................................................................................................... 146

9.

HISTORIAS DE USUARIO ............................................................................... 149

H

ÍNDICE DE TABLAS

Tabla 1: Actividades de la Ingeniería de Requisitos ........................................................... 23 Tabla 2 : Requerimiento de Hardware - Servidor ................................................................ 27 Tabla 3: Requerimiento de Hardware - Terminal ................................................................ 27 Tabla 4: Matriz de Procesos ................................................................................................ 65 Tabla 5: Tabla de Procedimientos por Tiempo.................................................................... 69 Tabla 6: Actor - Enlace de Planillas .................................................................................... 80 Tabla 7: Actor - Responsable de Planillas ........................................................................... 81 Tabla 8: Enlace en la Unidad Reconocida en el D.S. 0282 ................................................. 83 Tabla 9: Archivo y Kardex - "U.E.L.I.N.C." ....................................................................... 83 Tabla 10: Responsable "U.E.L.I.C.N." ............................................................................... 84 Tabla 11: Autentificación de Usuario .................................................................................. 84 Tabla 12: Registro y Administración de Beneficiarios ...................................................... 85 Tabla 13: Registro de Cuenta Bancaria ............................................................................... 85 Tabla 14: Registro de Nivel y Cargo ................................................................................... 86 Tabla 15: Registro de Proyecto ............................................................................................ 86 Tabla 16: Elaboración de Planilla Preliminar ..................................................................... 87 Tabla 17: Elaboración de Planilla Preliminar ..................................................................... 87 Tabla 18: Generación de Reportes ....................................................................................... 88 Tabla 19: Chequeo de Seguridad ......................................................................................... 88 Tabla 20: Verificación de al Información ............................................................................ 89 Tabla 21: Generación de Planilla Consolidadas .................................................................. 90 Tabla 22: Generación del Archivo Plano............................................................................. 91 Tabla 23: Factores de Salida .............................................................................................. 114 Tabla 24: Valores de Facilidad de Uso (Porcentajes) ........................................................ 115 Tabla 25: Cálculo de Puntos de Función .......................................................................... 116 Tabla 26: Valores de Ajuste .............................................................................................. 117

I Tabla 27: Parámetro LDC/PF ............................................................................................ 129 Tabla 28: Modelo de Desarrollo ........................................................................................ 130 Tabla 29: Factores de Ajuste de Esfuerzo ......................................................................... 131 Tabla 30: Resumen de Resultados Obtenidos ................................................................... 138

J ÍNDICE DE FIGURAS

Figura 1: Organigrama "U.E.L.I.C.N." ................................................................................ 7 Figura 2: Triángulos de Hierro ........................................................................................... 26 Figura 3: Diagrama Entidad Relación ................................................................................ 34 Figura 4: Traducción del Modelo de Requerimiento al Modelo de Diseño ....................... 35 Figura 5: Características Metodología XP ....................................................................... 43 Figura 6: Ciclo de Vida Proyecto XP ................................................................................. 44 Figura 7: Complementación de Prácticas ........................................................................... 49 Figura 8: Comparación de Metodologías de Desarrollo Agiles ......................................... 50 Figura 9: Historias de Usuario ............................................................................................ 51 Figura 10: Imagen de Caja Negra ....................................................................................... 53 Figura 11: Prueba de Aceptación ........................................................................................ 58 Figura 12: Proceso de Pago de Reconocimiento Económico ............................................. 64 Figura 13 Flujo de Procedimientos - Reconocimiento Económico .................................... 71 Figura 14: Interpretación del Sistema Actual ..................................................................... 79 Figura 15: Censo de Módulos - Nuevo Sistema ............................................................... 82 Figura 16: Esquema Actividades ........................................................................................ 92 Figura 17: Actividad – Autentificación de Usuario ............................................................ 93 Figura 18: Actividad – Registro de Cuenta Bancaria ......................................................... 94 Figura 19: Actividad – Registro y Administración de Beneficiario ................................... 95 Figura 20: Actividad – Registro de Niveles y Cargos ........................................................ 96 Figura 21: Actividad – Registro de Proyectos .................................................................... 97 Figura 22: Actividad – Elaboración de Planilla Preliminar ................................................ 98 Figura 23: Actividad – Registro de Descuentos ................................................................. 99 Figura 24: Actividad – Elaboración Planilla Preliminar ................................................... 100 Figura 25: Diagrama de Clase .......................................................................................... 101 Figura 26: Secuencia General de Sistema ........................................................................ 102 Figura 27: Secuencia de Sistema - Enlace ........................................................................ 103

K Figura 28: Secuencia de Sistema - Chequeo..................................................................... 104 Figura 29: Secuencia de Sistema - Responsable............................................................... 105 Figura 30: Modelo Relacional .......................................................................................... 106 Figura 31: Ventana de Control de Accesos al Sistema ..................................................... 107 Figura 32: Ventana Menú Principal .................................................................................. 107 Figura 33: Ventana Enlace - Registro de Beneficiarios .................................................... 108 Figura 34: Ventana de Registro de Cuentas, Niveles y Proyectos ................................... 108 Figura 35: Ventana de Chequeo de Seguridad ................................................................ 109 Figura 36: Ventana de Registro de Descuentos ................................................................ 109 Figura 37: Diagrama de Transferencia ............................................................................ 114

1

1. INTRODUCCIÓN

2 1.1

ANTECEDENTES

Los principales retos de la modernización integral de la Administración Pública del Estado Plurinacional de Bolivia son implantar un nuevo modelo de gestión pública, reconocido por su efectividad y su apertura hacia la participación social, mejorando día a día la calidad de los servicios que se prestan a la población y por consecuencia elevando la eficiencia de los procesos, reduciendo los tiempos de respuesta y eliminando paulatinamente requisitos innecesarios de manera que vinculen a la sociedad con la administración pública estatal de forma más sencilla, directa y transparente.

A partir de 1962, Bolivia ha ido combatiendo el tráfico de sustancias controladas, por medio de diferentes leyes, las cuales tipificaban en forma clara y precisa las sanciones a la fabricación, transporte o venta de sustancias prohibidas.

1.2

LA LUCHA CONTRA EL NARCOTRÁFICO EN NUESTRO MEDIO

Debido a diferentes factores sociales y económicos por los cuales atravesó nuestro país, entre 1977 - 1984, el trópico Cochabambino se convierte en zona productora de la hoja de coca, la migración minera que luego de la promulgación del D.S. 21060 y la correspondiente relocalización, engrosan y transforman las filas de cocaleros y de grupos sociales como “Los Sin Tierra”, quienes masivamente, extienden nuevas zonas productoras de coca.

Bolivia por su morfología geográfica con exuberante flora de montes inhóspitos, provee de lugares mimetizados en la naturaleza los cuales son adaptados para montar pozas de maceración de hoja de coca.

3 La facilidad con que se adquiere la materia prima, es un factor que se constituye en el caldo de cultivo para la fabricación de cocaína, debido a los controles que se implantaron, los narcotraficantes han emigrado de las ciudades a los paraísos tropicales como también a los ricos suelos del altiplano y los valles, donde las hermosas campiñas, quebradas, ríos de agua cristalina que llevan agua fresca a las comunas más alejadas, son contaminadas con residuos químicos, que a su paso envenenan la tierra y con esta, la flora y fauna natural, además de los hombres y mujeres que recogen agua para su diaria subsistencia.

Los diferentes gobiernos de turno, implementaron diversas formas de lucha contra el narcotráfico, estando principalmente financiados por ayuda externa.

El favor de países como E.E.U.U. fue preponderante, el asentamiento de oficinas como la DIVISIÓN DE ASUNTOS ANTINARCÓTICOS DE LOS ESTADOS UNIDOS, “N.A.S.”; coadyuvaron específicamente en la reducción de los delitos internacionales relacionados con drogas y otros de distinta índole, mejorando las habilidades de las fuerzas del orden y las autoridades judiciales bolivianas, identificando, disuadiendo y procesando los delitos relacionados con drogas y otros, por medio del fomento de la cooperación multilateral contra el crimen.

La cooperación ofrecida por el gobierno americano mediante la “N.A.S.” cubría específicamente la dotación de uniformes, capacitación, alimentación, seguro de vida, combustible, pago de reconocimiento económico y todo lo que logísticamente requerían, el personal de la FELCN, DIABLOS NEGROS, ROJOS, AZULES, VERDES, FTC_MILITAR, FTC-POLICIAL, UPE Y DIGPROCOCA; gestores directos de la lucha contra el narcotráfico en Bolivia.

4 Sin embargo, en la gestión 2009 el gobierno de los Estados Unidos a través de la “N.A.S.”, empezó a restringir periódicamente la ayuda económica ofrecida a Bolivia para la Lucha Contra el Narcotráfico, afectando específicamente a la Dirección General de Control de Coca e Industrialización (DIGCOIN), la Policía Boliviana (FELCN), Fuerzas Armadas de Bolivia (FTCMilitar, Diablos Negros, Azules, Rojos y Verdes), Dirección General de Desarrollo Integral de las Regiones Productoras de Coca (DIPROCOCA) y otras instancias.

1.3

UNIDAD EJECUTORA DE LUCHA INTEGRAL CONTRA EL NARCOTRÁFICO “U.E.L.I.C.N.”

El Estado se organiza por medio de instituciones, a las cuales se les asignan ciertos propósitos que surgen de la voluntad de la sociedad civil expresada en la Constitución Política del Estado, para que se encarguen de satisfacer necesidades colectivas ciudadanas y hacer efectivos aquellos derechos de la población.

La Unidad Ejecutora de Lucha Integral Contra el Narcotráfico, en su origen tiene la misión de Administrar los recursos asignados al Programa de Integral de Lucha Contra el Narcotráfico. Para cumplir con ella, requiere de instrumentos que coadyuven a una eficiente y eficaz labor que optimicen el apoyo a las unidades operativas que luchan contra ese flagelo de la humanidad.

1.4

BASE LEGAL

La Unidad Ejecutora de Lucha Integral Contra el Narcotráfico, fue creada mediante Resolución Multiministerial N° 035/2009 de 13 de abril de 2009, la misma contiene como atribución central la de administrar los recursos destinados a la Lucha Contra el Narcotráfico.

5 Asimismo de acuerdo a la Resolución Multiministerial CONALTID N° 002/2012 se aprueba la ampliación de la estructura organizacional de la “U.E.L.I.C.N.”, estableciendo la creación de Áreas Organizacionales Administrativas Regionales y Distritales.

En ese marco legal y en sujeción a las disposiciones nacionales, la “U.E.L.I.C.N.” como entidad del sector público en aplicación de la Ley 1178 de 20 de junio de 1990, Ley de Administración y Control Gubernamentales (SAFCO), en función de sus objetivos y la naturaleza de sus actividades, debe implementar, los sistemas de administración y control.

Por otra parte de acuerdo a lo señalado en el Decreto Supremo 23318-A de 3 de noviembre de 1992, Decreto Supremo N° 26237, de 29 de junio de 2001 modificatorio al Reglamento de la Responsabilidad por la Función Pública que determina entre otros, los conceptos de eficacia, economía, eficiencia, desempeño transparente de funciones, la finalidad, atribuciones, funciones, facultades y deberes, aplicables a la gestión pública, debe establecer la línea de mando por el cual todo servidor público debe responder ante sus superiores jerárquicos.

Las políticas y objetivos a cumplir por la “U.E.L.I.C.N.” están contenidos en el Plan Nacional de Desarrollo aprobado mediante Decreto Supremo Nº 29272 de 12 de septiembre de 2007, basados en los pilares de “Bolivia Digna, Soberana, Productiva y Democrática para Vivir Bien”.

BOLIVIA DIGNA, erradicación de la pobreza y la inequidad; BOLIVIA DEMOCRÁTICA, construcción de una sociedad y Estado plurinacional y socio – comunitario, donde el pueblo ejerce el poder social y comunitario y es corresponsable de las decisiones sobre su propio desarrollo y del país; BOLIVIA PRODUCTIVA, orientada hacia la transformación, el cambio

6 integrado y diversificación de la matriz productiva y BOLIVIA SOBERANA, constitución del Estado en un actor internacional, soberano, auto-determinado, con identidad propia, mediante una política exterior que oriente la acción política y diplomática con presencia de los pueblos y defensa sostenible de los recursos naturales y de la biodiversidad. (CIENCIA Y TECNOLOGÍA - MINISTERIO DE EDUCACIÓN, s.f.)

La Unidad Ejecutora de Lucha Integral Contra el Narcotráfico está sujeta al Decreto Supremo Nº 29894 de 7 de febrero de 2009 que define la estructura organizativa del Órgano Ejecutivo del Estado Plurinacional.

1.5

ESTRUCTURA ORGANIZACIONAL DE LA “U.E.L.I.C.N.”

La estructura organizacional de “U.E.L.I.C.N.” comprende un área sustantiva denominada Coordinación General y tres áreas administrativas de apoyo, denominadas Unidades, con dependencias clasificadas en divisiones y secciones.

FUENTE: Planificación “U.E.L.I.C.N.”

Figura 1: Organigrama "U.E.L.I.C.N."

7

El organigrama de la “U.E.L.I.C.N.” es el siguiente:

8 Objetivos Generales de la “U.E.L.I.C.N.” ”Ejecutar tareas administrativas a los recursos económicos y financieros a través de una unidad especializada para garantizar la eficiencia y eficacia operativa de la lucha contra el narcotráfico”

Misión de la “U.E.L.I.C.N.” ”Administrar los recursos asignados al Programa de Administración Integral de Lucha Contra el Narcotráfico, con destino a las labores de interdicción del tráfico de drogas, racionalización y erradicación de cultivos de coca, con el compromiso de calidad, competencia e innovación, para lograr una eficiente, eficaz y transparente gestión pública”

Visión de la “U.E.L.I.C.N.” ”La “U.E.L.I.C.N.” aspira a consolidarse, en el ejercicio de la administración de recursos, como una unidad efectiva y de vanguardia en el proceso de consolidación de una gestión pública responsable, honesta y productiva val servicio del interés nacional y a la Política del Estado Plurinacional de encarar la Lucha Integral Contra el Narcotráfico y Delitos Conexos con dignidad, soberanía, sin injerencia de organismos ni potencias extranjeras”

1.6

PAGO DE RECONOCIMIENTO ECONÓMICO

De los antecedentes se establece que la “U.E.L.I.C.N.”, es la encargada de procesar las Planillas de Reconocimiento Económico mensual para aproximadamente 3000 efectivos distribuidos en 9 unidades, siendo los beneficiarios sujetos al pago del Reconocimiento Económico: La Fuerza Especial de Lucha Contra el Narcotráfico – “F.E.L.C.N.”. Fuerza de Tarea - Diablos Verdes (Ejército). Fuerza de Tarea - Diablos Rojos (Fuerza Aérea). Fuerza de Tarea - Diablos Negros (Fuerza Aérea).

9 Fuerza de Tarea - Diablos Azules (Armada Boliviana). Fuerza de Tarea Conjunta - Componente Militar. Fuerza de Tarea Conjunta - Componente Policial. Fuerza de Tarea Conjunta - Unidad de Policía Ecológica. Dirección Nacional de Desarrollo Integral de las Regiones Productoras de Coca (DIGPROCOCA).

La cancelación, se realiza de acuerdo a escalas según nivel jerárquico, cargo funcional y responsabilidad profesional, en estricto cumplimiento al Decreto Supremo Nº 282 de 09 de abril de 2009; (LEXIVOX, 2009).

El Pago de Reconocimiento Económico, no es un salario, sino, una COMPENSACIÓN ECONÓMICA, por tanto los montos establecidos en la “Escala de Reconocimiento Económico” incluyen el Régimen Complementario al Impuesto al Valor Agregado (RC-IVA), en consecuencia el pago está sujeto a los descuentos de Ley del 13% (trece 00/100) por concepto de impuestos.

Los beneficiarios se encuentran distribuidos en todo el territorio nacional, los comandos están estratégicamente asentados en el trópico, valle, altiplano, fronteras, y ciudades capitales de nuestro país, esta distribución exige contar con un Enlace, responsabilidad que recae en una persona que está encargada de controlar los movimientos de altas, bajas, cambios y todo los referente al proceso previo de planillas en las unidades, quienes posteriormente remiten la información a la “U.E.L.I.C.N.” establecida en la ciudad de La Paz, para el chequeo de seguridad, consistencia de la información y pago correspondiente.

El Pago del Reconocimiento Económico se efectúa a través de cajeros, para lo cual la Unidad Ejecutora de Lucha Integral Contra el Narcotráfico “U.E.L.I.C.N.”, contrató los servicios de personal, a quienes se les remite las planillas y las correspondientes remesas para el pago.

10 1.7

PROBLEMÁTICA

Cualquier manejo de recursos económicos, conlleva a determinados riegos, acrecentándose los inconvenientes si los dineros recursos asignados son provenientes del Tesoro General de la Nación.

Problema Principal

El proceso del Pago de Planillas de Reconocimiento Económico, en la actualidad, no otorga las garantías necesarias que una cancelación de recursos elevados debería tener, el traslado constante de importantes sumas de dinero (remesas) a distintos puntos del territorio nacional, motivan la urgente necesidad de contar con una nueva forma de pago, que garantice y transparente este proceso.

La conmoción crece significativamente, al analizar antecedentes pasados como los ocurridos con las remesas de Calamarca (1961), (Murillo Estrada, s.f.); Prosegur (2001), (Mendoza, 2010); Sinchi Wayra (2014), (La Prensa, 2014) y otros.

Asimismo, el proceso de planillas en la actualidad es prácticamente artesanal, la materia prima es generada por 9 enlaces, quienes remiten la información a la “U.E.L.I.C.N.”, esta información carece de una estandarización, los campos como unidades, escalas, regionales, grados, cargos, etc. son manejados de acuerdo a criterio y necesidad de cada Unidad, originando inconsistencia de la información, asimismo la distribución que se realiza no ofrece la seguridad que debería tener, ya que los archivo Excel son fácilmente vulnerables. La “U.E.L.I.C.N.” aspira a consolidarse, en el ejercicio de la administración de recursos, como una unidad efectiva y de vanguardia en el proceso de consolidación de una gestión pública responsable, honesta y productiva val servicio del interés nacional y a la Política del Estado Plurinacional de encarar la Lucha Integral Contra el Narcotráfico y Delitos Conexos con dignidad, soberanía, sin injerencia de organismos ni potencias extranjeras”

11 Problemas Secundarios

Independientemente del traslado de remesas, se establece que los tiempos de pago de Planillas de Reconocimiento Económico varían notoriamente, producto de no tener un procedimiento establecido para el pago, menos existe una ruta definida lo que obviamente repercute enormemente en las fechas de pago de este beneficio, originando una problemática social.

1.8

OBJETIVOS

Un proceso que maneja gran cantidad de recursos económicos estatales, tiene la necesidad de contar con una herramienta informática que elabore las planillas y genere un archivo plano, que pueda ser utilizado en la gestión de depósitos en cuentas, a fin de minimizar riesgos y ofrecer un servicio oportuno, fiable y transparente

Objetivo General

Desarrollar un sistema informático de control de planillas para automatizar el proceso de pago de Reconocimiento Económico para el Ministerio de Gobierno – “U.E.L.I.C.N.”

Objetivos Específicos  Analizar y Diseñar una base de datos para el proceso y posterior pago de Planillas de Reconocimiento Económico.  Desarrollar un sistema de uso WEB, que proporcione información oportuna, fiable y transparente, de código seguro, que genere reportes y garantice los pagos a los beneficiarios del Reconocimiento Económico D.S. 0282.  Generar el mecanismo de intercambio de información entre la “U.E.L.I.C.N.”; las Fuerzas y Direcciones Reconocidas en el D.S. 0282 y las Entidades Bancarias.

12

 Aplicar la metodología de desarrollo de software PROGRAMACION EXTREMA (XTREME PROGRAMMING, XP)

1.9

JUSTIFICAR

La administración moderna de recursos económicos, exige el implemento de prácticas y herramientas de gestión que permitan un mejor provecho de los mismos, prestando un mejor servicio, motivando y satisfaciendo a los efectivos que están en la lucha contra el narcotráfico. El factor eficiencia debe convertirse en un elemento, que indique la forma de percibir la vida organizacional de la “U.E.L.I.C.N.”.

Justificación Económica

Mediante la Resolución Multi - Ministerial No.035/2009 de 13 de abril de 2009 se dispone la creación de la “U.E.L.I.C.N.”, con la atribución principal de administrar la asignación presupuestaria realizada con recursos proveniente del Tesoro General de la Nación (TGN) de Bs.140.000.000,00 (ciento cuarenta millones de 00/100 bolivianos), de los cuales Bs. 75.000.000,00 (setenta y cinco millones 00/100 de bolivianos) están destinados al pago del Reconocimiento Económico.

En el artículo 4to. del Decreto Supremo Nº 0282 de 02 de diciembre de 2009 se autoriza al Ministerio de Gobierno, a través de la “U.E.L.I.C.N.”, efectuar el pago de un Reconocimiento Económico con el objeto de compensar los esfuerzos, riesgos y presión del personal militar, policial y civil que trabaja de forma directa en la lucha integral contra el narcotráfico y delitos conexos.

Las

elevadas sumas que representa el pago de reconocimiento económico argumenta la

necesidad de contar con una herramienta que coadyuve con el proceso de pago.

13 Desarrollar un sistema informático de control de planillas para automatizar el proceso de pago de Reconocimiento Económico para el Ministerio de Gobierno – “U.E.L.I.C.N.”

Justificación Técnica En la “U.E.L.I.C.N.” urge la necesidad de promover y desarrollar una herramienta que permita administrar de mejor manera los recursos del estado de manera eficaz, equitativa y transparente, para alcanzar el bien común y satisfacer los fines para los cuales fue creado. El Sistema Informático de Control de Planillas de Pago de Reconocimiento Económico presenta una interfaz interactiva que permitirá un mejor control y seguimiento al proceso de pago, realizando los abonos en cuentas bancarias. El proyecto se justifica porque en la “U.E.L.I.C.N.” existen equipos de computación actualizados y estos cumplen los requisitos mínimos de hardware y software para la implementación del sistema, tanto en la unidad de computo de la “U.E.L.I.C.N.” como en las diferentes Direcciones y Comandos reconocidos en el D.S. 0282; (LEXIVOX, 2009).

Justificación Social

La seguridad y rapidez con que procesará las Planillas de Reconocimiento Económico, favorecerá de manera sustancial a los efectivos beneficiarios de esta compensación, el mismo permitirá contar con el pago hasta el 5 de cada mes, siendo que en la actualidad se realiza el pago hasta el día 25 inclusive.

1.10 ALCANCES Y LIMITES

La Unidad Ejecutora de Lucha Integral Contra el Narcotráfico, tiene un presupuesto de 140.000.000,00 millones de bolivianos, su ejecución esta prorrateada en función a la solicitud que realizan las diferentes unidades inmersas en la lucha contra el narcotráfico y en estricto cumplimiento a la Ley 1178.

14 Alcances La “U.E.L.I.C.N.” en la actualidad otorga al personal militar policial y civil, los insumos necesarios como dotación de uniformes, alimentación, combustible, mantenimiento de vehículos, seguros de vida y otros materiales necesarios para lucha integral contra el narcotráfico, sin embargo, alrededor del 50% del presupuesto asignado a esta unidad (75.000.000,00 de bolivianos), está destinado al pago de Reconocimiento Económico.

En ese sentido, el presente trabajo, está dirigido, única y exclusivamente a optimizar el Proceso de Pago del Reconocimiento Económico.

El sistema cuenta con los módulos descritos a continuación:  Registro de Beneficiario, Este módulo permite tener el registro completo referente al beneficiario.  Registro de Cuenta Bancaria, este módulo permite registrar la cuenta bancaria asignada al beneficiario por la entidad financiera correspondiente.  Registro de Nivel y Cargo, modulo que asigna al beneficiario el correspondiente nivel y cargo en cumplimiento a las escalas del reglamento de pago de reconocimiento económico en actual vigencia.  Registro de Proyecto (unidad), modulo que asigna el proyecto o unidad de destino al cual el beneficiario pertenece.  Registro de Chequeo de Seguridad, modulo que realiza el control de documentación y avala la idoneidad y probidad de los beneficiarios del pago de reconocimiento económico.

15  Proceso de Planillas, modulo que genera las planillas de pago de reconocimiento económico  Generación del archivo plano, en cumplimiento a requerimientos técnicos del Fondo Financiero Privado PRODEM y Banco Unión, el sistema generara los archivos planos para los abonos en cuenta correspondientes.  Reportes, el sistema genera reportes correspondientes.

Límites

El Pago de Reconocimiento Económico, no es un salario, sino, una COMPENSACIÓN ECONÓMICA, por tanto el SISTEMA INFORMÁTICO DE CONTROL DE PLANILLAS DE PAGO, realizara procesos relacionados con el RECONOCIMIENTO ECONOMICO (D.S. 282;) y no de salarios.

1.11 METODOLOGÍA

La presente investigación se enmarco dentro de una metodología de investigación proyectiva, lo que permitió la elaboración y diseño de una propuesta, un plan, un programa o un modelo, como solución al pago del reconocimiento económico, ocupándose de cómo deberían ser las cosas, para alcanzar los fines para los cuales fue creada la “U.E.L.I.C.N.”. (JACQUELINE, 2008)

Para el desarrollo del Sistema Informático de Control de Planillas de Pago, se aplicara la metodología de desarrollo de software PROGRAMACIÓN EXTREMA (EXTREME PROGRAMMING, XP).

La herramienta para el desarrollo de software será el FILEMAKER PRO V13 para Windows, Mac, IPod, con publicación WEB.

16 El método de prueba de software utilizado fue el de la Caja Negra; basado en la técnica de la Partición de Equivalencia, al ser esta una de las más efectivas pues nos permitió examinar los valores válidos e inválidos de las entradas existentes en el software, descubriendo de forma inmediata clases de errores.

17

2. MARCO TEÓRICO

18 2.1

MARCO CONCEPTUAL

En este apartado daremos a conocer y conceptualizar las herramientas y metodologías que se emplearan en el presente proyecto, tanto para el desarrollo como para la implementación del mismo.

2.2

CONTROL DE PERSONAL

La administración de recursos humanos, es el proceso administrativo aplicado al acrecimiento y conservación del esfuerzo, las experiencias, la salud, los conocimientos, las habilidades, etc. en beneficio del individuo, la organización y del país en general. Proceso que permite ayudar a los empleados a alcanzar niveles de desempeño y una calidad de conducta personal y social que cubra sus necesidades y compense los esfuerzos, riesgos y presión permanente.

2.3

HISTORIA DE LA MODERNA ADMINISTRACIÓN DE PERSONAL

El origen de la administración de recursos humanos va estrechamente complementado con los derechos laborales, la administración científica y otras disciplinas. Nos referimos al derecho laboral como una exigencia de la clase trabajadora a fin de que se reglamente el trabajo no bastando aplicar los preceptos legales de forma fría, sino por el contrario buscar principios basados en el estudio y entendimiento comprendiendo que se hablaba de conceptos relativos a sueldos, prestaciones, contrataciones, primas, bonos, reconocimientos, etc.

Asimismo los principios de Taylor y Fayol pusieron las bases de la administración a través de la coordinación y dirección, buscando el mejor empleo de los recursos humanos que intervienen en el trabajo.

2.4

DEFINICIÓN DE CONTROL DE PERSONAL

Dada la importancia que la Administración de Recursos Humanos tiene para la organización existen diversos conceptos que tratan de explicar en qué consiste.

19  Es un esfuerzo sistemático para fijar niveles de desempeño con objetivos de planeación para diseñar los sistemas de retroalimentación de la información para comparar el desempeño real con esos niveles predeterminados, para establecer si hay desviaciones y medir su importancia, para tomar las medidas tendientes a garantizar que todos los recursos de la empresa se utilicen en la forma más eficaz y eficiente posible en la obtención de los objetivos organizacionales; (Arango, 1996).  Incorporación de tecnología para facilitar la recopilación de información para que pueda validar que realmente existe una orden de búsqueda y que responde a las especificaciones definidas; (Mondy & Noe, 2005).

Concluyendo que la administración y control de recursos humanos es aquella que tiene que ver con el aprovechamiento y mejoramiento de las capacidades y habilidades de las personas y en general con los factores que le rodean dentro de la organización con el objeto de lograr el beneficio individual, la organización y el país en su conjunto.

2.5

IMPORTANCIA DEL CONTROL DE PERSONAL

El registro y control de personal constituye una fuente importante de consulta sobre datos personales del empleado, la asistencia, puntualidad, vacaciones, permisos, ascensos y promociones, bajas médicas, etc. Mismos que desembocaran en el proceso de planillas de pago.

2.6

PLANILLAS DE PAGO

Las planillas de pago son un registro contable, brinda elementos que permiten demostrar de manera transparente, ante la autoridad competente la relación laboral del trabajador con la empresa, su remuneración y los demás beneficios complementarios, pudiéndose llevar estos registros en libros, hojas sueltas o micro formas.

20 También se la puede definir como registros que presentan un listado de todos los trabajadores del mes, especificando los días que trabajaron, la cantidad de mano de obra, las unidades a pagar y su costo, los descuentos, el líquido pagable y finamente la forma de pago.

2.7

TIPOS DE PLANILLAS DE PAGO

Se pueden elaborar y llevar las planillas de pago en cualquiera de las siguientes modalidades:  Libros  Hojas sueltas (estas deberán estar enumeradas).  Micro formas (estas permiten el uso de tecnologías avanzadas en materia de archivos de documentos).

2.8

INGENIERÍA DE SOFTWARE

Según la RAE, el software es un conjunto de programas, instrucciones y reglas informáticas que permiten ejecutar distintas tareas en una computadora; a partir de ello podemos indicar que la Ingeniería de Software es:

"El establecimiento y uso de principios de Ingeniería bien fundados (y de métodos) para obtener software fiable, económico y que funcione en máquinas reales"; (Cortes Morales, 2005). “La aplicación de un enfoque sistemático, disciplinado y cuantificable para el desarrollo, operación y mantenimiento del software” (Pressman, 1997)

2.9

PROCESO DE DESARROLLO DE SOFTWARE

Un Proceso de Desarrollo de Software, es un conjunto de actividades y resultados asociados que producen un producto de software, estas actividades son llevadas a cabo por los Ingenieros de

21 Software. Existen cuatro actividades fundamentales que son comunes para todos los procesos de software, las cuales son; (Pressman, 1997):  Especificación de Software, en esta actividad los clientes o ingenieros definen el software a producir y las restricciones sobre su operación. Es decir, durante la definición, el que desarrolla el software intenta identificar qué información ha de ser procesada, que función y rendimiento se desea, que comportamiento del sistema, que interfaces van a ser establecidas, que restricciones de diseño existen, y que criterios de validación se necesitan para definir un sistema correcto.  Desarrollo de Software, es la actividad donde el software se diseña y se programa. Es decir, durante el desarrollo, un Ingeniero de Software, intenta definir cómo han de diseñarse las estructuras de datos, cómo ha de implementarse una función dentro de una arquitectura de software, cómo han de implementarse los detalles procedimentales, cómo han de caracterizarse interfaces, cómo ha de traducirse el diseño en el lenguaje de programación y cómo ha de realizarse la prueba.  Validación de Software, en esta etapa, el software se valida, para asegurar que los requerimientos del cliente hayan sido satisfechos. Se realizan pruebas al sistema acerca de las funciones que el cliente necesita.  Evolución de Software, en esta actividad se realizan las tareas de corrección, adaptación, mejora y prevención. Las adaptaciones requeridas serán a medida que evoluciona el entorno del software y a cambios debidos a las mejoras producidas por los requisitos cambiantes del cliente.

2.10 MODELO EVOLUTIVO DEL PROCESO DE SOFTWARE

Los modelos evolutivos son iterativos. Se caracterizan por la forma en que permiten a los ingenieros del software desarrollar versiones cada vez más complejas del software. Existen dos tipos de desarrollo evolutivo, el desarrollo exploratorio y el de prototipos desechables, donde el

22 objetivo de este último es el de comprender los requerimientos del cliente y desarrollar prototipos para los requerimientos que no se comprenden con mucha precisión.

El modelo incremental es un proceso evolutivo, es mucho más efectivo que un enfoque cascada, puesto que se adapta a los requerimientos cambiantes del cliente.

El modelo incremental se centra en la entrega de un producto operacional con cada incremento, donde el primer incremento a menudo es un producto esencial. Según, el modelo incremental es útil cuando la dotación de personal no está disponible para una implementación completa.

2.11 INGENIERÍA DE REQUISITOS

La ingeniería de requisitos, según Pressman; (Pressman, 1997), es un conjunto de procesos, tareas y técnicas que permiten la definición y gestión de los requisitos de un producto de un modo sistemático. En definitiva, facilita los mecanismos adecuados para comprender las necesidades del cliente, analizando sus necesidades, confirmando su viabilidad, negociando una solución razonable, especificando la solución sin ambigüedad, validando la especificación y gestionando los requisitos para que se transformen en un sistema operacional. Los requisitos tienen un papel importante en el desarrollo de cualquier sistema, de ellos depende el fracaso o éxito del mismo. La Ingeniería de Requisitos llamada a veces Ingeniería de Requerimientos, trata de estandarizas las actividades que deben realizarse para poder recolectar información, analizarla, documentarla y clasificarla, todo esto para poder definir de forma clara y precisa las funciones que el sistema debe implementar.

La Ingeniería de Requisitos facilita el mecanismo apropiado para comprender lo que quiere el cliente, analizando necesidades, confirmando su viabilidad, negociando una solución razonable, especificando la solución sin ambigüedad, validando la especificación y gestionando los requisitos para que se transformen en un sistema operacional. Las actividades y tareas que se deben realizar en la Ingeniería de requisitos se muestran en la tabla.

23 Tabla 1: Actividades de la Ingeniería de Requisitos Actividad Tareas Obtención de Requisitos  Realizar entrevistas a usuarios

Análisis de Requisitos

Validación Requisitos

de



Observación al entorno



Encuestas a usuarios



Documentar requisitos encontrados



Clasificar requisitos encontrados



Identificar requisitos imposibles



Eliminar requisitos inconsistente



Revisión de los requisitos por ingenieros y usuarios



Aclarar e interpretar términos. Fuente: Elaboración Propia

Desde un punto de vista conceptual, las actividades que se deben desarrollar en la ingeniería de Requisitos, son de tres tipos, las cuales desarrollaremos a continuación:

a)

Obtención de requisitos

La identificación de requisitos puede parecer una tarea simple, tal vez se piense que preguntando a los usuarios sobre lo que desean que el sistema realice sea suficiente, por el contrario la identificación de requisitos es algo más complicado. La obtención de requisitos puede presentar los siguientes problemas.  Problemas de alcance, se da cuando el límite del sistema está mal definido, se suele confundir los objetivos del sistema.  Problemas de comprensión, sucede cuando clientes/usuarios no están completamente seguros de lo que necesitan, a menudo no tienen comprensión de la capacidades y limitaciones de una computadora, se reservan cierta información que a su vista puede resultar obvia.

24  Problemas de volatilidad, los requisitos cambian con el tiempo.

La obtención de requisitos debe realizarse mediante entrevistas a cada usuario, grupos de discusión, realizando encuestas, etc. En toda actividad realizada debe tomarse en cuenta los problemas mencionados anteriormente.

b)

Análisis de Requisitos

Una vez recopilados los requisitos, el producto obtenido configura la base de análisis de requisitos. Los requisitos se agrupan por categorías y se organizan en subconjuntos, se estudia cada requisito en relación con el resto, se examinan los requisitos en su consistencia, completitud y ambigüedad, y se clasifican en base a las necesidades de los clientes/usuarios.

Al realizar el análisis de requisitos se debe detectar y corregir las falencias comunicativas, transformando los requisitos obtenidos en entrevistas, en condiciones apropiadas para ser tratados por el diseño, utilizando un procedimiento iterativo, se irán eliminando requisitos, se irán cambiando y/o modificando para conseguir satisfacer los objetivos planteados.

c)

Validación de requisitos

La validación de requisitos se encarga de la revisión técnica formal de los requisitos encontrados, se debe identificar cuáles de los requisitos no serán abordados por el sistema. El equipo de revisión debe incluir a ingenieros del sistema, clientes, usuarios y otros intervinientes que examinan la especificación del sistema buscando errores en el contenido o en la interpretación, áreas donde se necesitan aclaraciones, información incompleta, inconsistencias, requisitos contradictorios, o requisitos imposibles o inalcanzables.

2.12 PRINCIPIO DE PARETO

Wilfredo Pareto, reconocido ingeniero, sociólogo, economista, político y filósofo en uno de sus estudios más reveladores, dejó al descubierto que el 80% de las tierras de Italia pertenecían el

25 20% de la población. A partir de ese descubrimiento, varios matemáticos y economistas derivaron esas observaciones y las verificaron en otros ámbitos. (Alaimo, 2013)

Joseph Juran, quien en 1941 planteó el Principio de Pareto (o regla del 80/20) aplicado a la calidad: el 80% de los efectos son producidos por el 20% de las causas. Esta ley también se conoció como el principio de “los pocos vitales (el 20% principal que genera el 80% importante) y los muchos triviales (el 80% restante que genera el 20% remanente)”. (Alaimo, 2013)

Aplicando este principio al desarrollo de software, podemos decir que el 20% de las características de un sistema resuelven el 80% de la necesidad de negocio que le da origen. Y, de manera recursiva, el 20% del 80% restante de las características, resuelven el 80% del 20% restante de negocio. Podemos representar esta relación, recursiva, mediante el siguiente gráfico. (Alaimo, 2013)

2.13 ALCANCE VARIABLE

Debido a que asumimos que no nos es posible conocer de manera anticipada y con un nivel muy fino de detalle todas las características del producto que pretendemos construir, sino que es un viaje de descubrimiento que emprendemos junto con el cliente, los requerimientos son un elemento vivo que muta a través del tiempo, al ritmo que vamos aprendiendo sobre el mismo con las entregas iterativas y el feedback frecuente.

Si bien, tradicionalmente, el alcance se ha intentado fijar desde el comienzo de un proyecto, y así manejar el costo y el tiempo como los elementos variables, desde la agilidad, esta ecuación se invierte: el tiempo y el costo son los componentes fijos del proyecto, mientras que el alcance es el componente variable.

26 Figura 2: Triángulos de Hierro

Fuente: (Alaimo, 2013)

2.14 TECNOLOGÍA UTILIZADA

FileMaker Pro es una aplicación multiplataforma (Windows y Mac) de base de datos relacional de FileMaker Inc. (una subsidiaria de Apple Inc.). FileMaker integra el motor de la base de datos con la interfaz, lo que permite a los usuarios modificar la base de datos al arrastrar elementos (campos, pestañas, botones...) a las pantallas o formas que provee la interfaz.

FileMaker evolucionó de una aplicación de MS-DOS, que se desarrolló primariamente para Apple Macintosh. Desde 1992 está disponible para Microsoft Windows y se puede utilizar como un ambiente heterogéneo. FileMaker está disponible para desktop, servidor y configuraciones web.

FileMaker en su concepto es orientado a objetos, un paradigma de análisis, proyecto y programación de sistemas basado en la interacción de diversas unidades de Software llamadas objetos. De hecho, el paradigma que el producto Pro FileMaker promueve es la “orientación a objeto”, tiene bases conceptuales y origen en el campo de estudio de la cognición, que influenció el área de la inteligencia artificial y lingüística, en el campo de abstracción de conceptos del mundo real.

27 En la calidad de método de modelaje, es la mejor estrategia para eliminar el “Gap semántico”, dificultad recurrente en el proceso de modelar el mundo real del domino del problema en un conjunto de componentes de software que sea más fiel a su representación de este domino.

2.15 REQUERIMIENTOS TÉCNICOS

Entendemos como Dominio del Producto al hardware y entornos operativos sobre los cuales el Sistema Informático de Control de Planillas de pago de Reconocimiento Económico garantiza su funcionamiento. Tabla 2 : Requerimiento de Hardware - Servidor Hardware recomendado: Intel Core 2 Quad 2.6 GHz (o equivalente) con 4GB de RAM, Mouse, Monitor SVGA, placa de red de 1000 Mb, 100 GB de espacio disponible (o libre) en disco (este espacio no incluye volumen de datos), conexión a Internet.

Hardware mínimo: Intel Core 2 Duo 1.86 GHz (o equivalente) con 2 GB de RAM, Mouse, Monitor SVGA, placa de red de 100 Mb, 50 GB de espacio disponible (o libre) en disco (este espacio no incluye volumen de datos), conexión a Internet.

Software: Windows XP Professional 32 Bits (Service Pack 3 o superior), Windows 2003 Server 32 Bits (Service Pack 2 o superior), Windows Vista 32 Bits (Versiones Business y Ultimate), Windows 2008 Server (32Bits y 64Bits), Windows 7 32 y 64 Bits (versiones Professional, Enterprise y Ultimate), Windows 8.1 32 y 64 bits (Versiones Windows 8 PRO y Windows 8 Enterprise), Windows 2012 (versiones Fundations, Essentials y Standard). Fuente: Elaboración Propia

Tabla 3: Requerimiento de Hardware - Terminal Hardware recomendado: Intel Core 2 Duo 2.13 GHz (o equivalente) con 2 GB de RAM, Mouse, Monitor SVGA, placa de red de 100 Mb, 3 GB de espacio disponible (o libre) en disco.

Hardware mínimo: Intel Core 2 1.86 GHz (o equivalente) con 1 GB de RAM, Mouse, Monitor SVGA, placa de red de 100 Mb, 1 GB de espacio disponible (o libre) en disco.

Software: Windows XP Professional 32 Bits (Service Pack 3 o superior), Windows 2003 Server 32 Bits (Service Pack 2 o superior), Windows Vista 32 Bits (versiones Business y Ultimate), Windows 2008 Server (32Bits y 64Bits), Windows 7 32 y 64 Bits (Versiones Professional, Enterprise y Ultimate), Windows 8.1 32 y 64 bits (versiones Windows 8 PRO y Windows 8 Enterprise), Windows 2012 R2 (Versiones Fundations, Essentials y Standard). Fuente: Elaboración Propia

28 2.16 ANÁLISIS

En todo desarrollo de software, la fase de análisis trata de definir de manera formal las tareas que el software debe realizar, las respuestas que se espera por parte del sistema, que dependerán de las acciones del usuario. En la fase de análisis se debe definir de manera clara, todos los módulos que formarán todo el sistema.

Para crear una aplicación software hay que describir el problema y las necesidades o requerimientos, en qué consiste el conflicto y que debe hacerse. El análisis se centra en la investigación del problema, no en la manera de definir la solución (LARMAN, 2002).

La abstracción de un sistema real y representado de tal forma que pueda ser integrado en un sistema computarizado, se denomina análisis orientado a objetos. La tarea de Análisis Orientado a Objetos es definir todos los objetos que participan en un sistema, cuáles de estos son relevantes, como se comportan los objetos en el contexto del sistema, todo esto para poder construir modelos que servirán para el desarrollo del sistema.

2.17 DISEÑO DE BASE DE DATOS

El diseño de una base de datos no es un proceso sencillo, habitualmente, la complejidad de la información y la cantidad de requisitos de los sistemas de información hacen que sea complicado. Por este motivo, cuando se diseñan bases de datos es interesante aplicar la vieja estrategia de dividir para vencer.

Por lo tanto, conviene descomponer el proceso del diseño en varias etapas; en cada una se obtiene un resultado intermedio que sirve de punto de partida de la etapa siguiente, y en la última etapa se obtiene el resultado deseado. De este modo no hace falta resolver de golpe toda la problemática que plantea el diseño, sino que en cada etapa se afronta un solo tipo de sub problema. Así se divide el problema y, al mismo tiempo, se simplifica el proceso.

29 Descompondremos el diseño de bases de datos en tres etapas:

1. Etapa del diseño conceptual: en esta etapa se obtiene una estructura de la información de la futura BD independiente de la tecnología que hay que emplear. No se tiene en cuenta todavía qué tipo de base de datos se utilizará – relacional, orientada a objetos, jerárquica, etc.; en consecuencia, tampoco se tiene en cuenta con qué SGBD ni con qué lenguaje concreto se implementará la base de datos. Así pues, la etapa del diseño conceptual nos permite concentrarnos únicamente en la problemática de la estructuración de la información, sin tener que preocuparnos al mismo tiempo de resolver cuestiones tecnológicas.

2. El resultado de la etapa del diseño conceptual se expresa mediante algún modelo de datos de alto nivel. Uno de los más empleados es el modelo entidadinterrelación (entity-relationship), que abreviaremos con la sigla ER.

3. Etapa del diseño lógico: en esta etapa se parte del resultado del diseño conceptual, que se transforma de forma que se adapte a la tecnología que se debe emplear. Más concretamente, es preciso que se ajuste al modelo del SGBD con el que se desea implementar la base de datos. Por ejemplo, si se trata de un SGBD relacional, esta etapa obtendrá un conjunto de relaciones con sus atributos, claves primarias y claves foráneas.

4. Esta etapa parte del hecho de que ya se ha resuelto la problemática de la estructuración de la información en un ámbito conceptual, y permite concentrarnos en las cuestiones tecnológicas relacionadas con el modelo de base de datos.

Más adelante explicaremos cómo se hace el diseño lógico de una base de datos relacional, tomando como punto de partida un diseño conceptual expresado con el modelo ER; es decir, veremos cómo se puede transformar un modelo ER en un modelo relacional.

30

Etapa del diseño físico: en esta etapa se transforma la estructura obtenida en la etapa del diseño lógico, con el objetivo de conseguir una mayor eficiencia; además, se completa con aspectos de implementación física que dependerán del SGBD.

2.18 BASE DE DATOS RELACIONAL

La mayoría de los sistemas software grandes utilizan bases de datos de gran tamaño. Una parte importante del modelado de sistemas es la definición de la forma lógica de los datos procesados por el sistema. La técnica del modelado de datos más ampliamente utilizada es el modelado Entidad-Relación (ER), que muestra las entidades de datos, sus atributos asociados y las relaciones entre estas entidades. Puesto que en el modelo ER se pueden definir, súper tipos y sub tipos, lo que se denomina generalización, es fácil implementar una base de datos OO utilizando el modelo ER.

UML no incluye una notación específica para el modelado de base de datos, pero se puede usar para representar un modelo semántico de datos. Se pueden pensar en las entidades de un modelo ER, como clases de objetos simplificadas (sin operaciones), los atributos como atributos de la clase y las denominadas asociaciones entre clases como relaciones. El diagrama de clases UML se puede usar para modelar algunos aspectos del diseño de bases de datos relacionales, pero no cubre toda la semántica involucrada en el modelo relacional, mayoritariamente la noción de atributos clave que relacionan entre sí las tablas unas con otras. Para capturar esta información, un diagrama Entidad-Relación se recomienda como extensión a UML.

2.19 MODELADO DE DATOS

Existen varias formas de almacenar información en las computadoras, lo que genera distintos modelos de organización de Bases de Datos: Jerárquico, Red, Relacional y orientada a objetos. Los distintos relacionales son muy importantes, por que ofrecen muchos tipos de procesos de datos como: simplicidad y generalidad, facilidad de uso para el personal final, periodos cortos de aprendizaje y las consultas de información se especifican de forma sencilla.

31 Una base de datos relacional parte del “modelo relacional de base de datos”, por tanto es un conjunto de relaciones normalizadas. Para representar el esquema de una base de datos relacional se debe dar el nombre de sus relaciones, los atributos de estas, los dominios sobre los que se definen estos atributos, las claves primarias y claves foráneas.

MODELO ENTIDAD RELACIÓN

El modelo ER es uno de los enfoques de modelización de datos que más se utiliza actualmente por su simplicidad y legibilidad. Su legibilidad se ve favorecida porque proporciona una notación diagramática muy comprensiva.

Es una herramienta útil tanto para ayudar al diseñador a reflejar en un modelo conceptual los requisitos del mundo real de interés como para comunicarse con el usuario final sobre el modelo conceptual obtenido y, de este modo, poder verificar si satisface sus requisitos.

Cuando se quiere utilizar el modelo ER para comunicarse con el usuario, es recomendable emplear una variante del modelo que incluya sólo sus elementos más simples – entidades, atributos e interrelaciones– y, tal vez, algunas construcciones adicionales, como por ejemplo entidades débiles y dependencias de existencia. Éstos eran los elementos incluidos en el modelo original propuesto por Chen.

En cambio, para llevar a cabo la tarea de modelizar propiamente dicha, suele ser útil usar un modelo ER más completo que incluya construcciones más avanzadas que extienden el modelo original.

Un modelo de datos tiene en cuenta tres aspectos de los datos: la estructura, la manipulación y la integridad. Sin embargo, el modelo ER habitualmente se utiliza para reflejar aspectos de la estructura de los datos y de su integridad, pero no de su manipulación.

32 2.20 NORMALIZACIÓN DE BASE DE DATOS

El proceso de normalización de bases de datos consiste en aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo entidad-relación al modelo relacional. Las bases de datos relacionales se normalizan para:  Evitar la redundancia de los datos.  Disminuir problemas de actualización de los datos en las tablas.  Proteger la integridad de los datos.

En el modelo relacional es frecuente llamar tabla a una relación, aunque para que una tabla sea considerada como una relación tiene que cumplir con algunas restricciones:  Cada tabla debe tener su nombre único.  No puede haber dos filas iguales. No se permiten los duplicados.  Todos los datos en una columna deben ser del mismo tipo.

2.21 FORMAS NORMALES

Las formas normales son aplicadas a las tablas de una base de datos. Decir que una base de datos está en la forma normal N es decir que todas sus tablas están en la forma normal N. En general, las primeras tres formas normales son suficientes para cubrir las necesidades de la mayoría de las bases de datos. El creador de estas 3 primeras formas normales (o reglas) fue Edgar F. Codd.1

33 Primera forma normal (1FN)

Una tabla está en Primera Forma Normal si:

Todos los atributos son atómicos. Un atributo es atómico si los elementos del dominio son indivisibles, mínimos.  La tabla contiene una clave primaria única.  La clave primaria no contiene atributos nulos.  No debe existir variación en el número de columnas.  Los Campos no clave deben identificarse por la clave (Dependencia Funcional)  Debe Existir una independencia del orden tanto de las filas como de las columnas, es decir, si los datos cambian de orden no deben cambiar sus significados  Una tabla no puede tener múltiples valores en cada columna.  Los datos son atómicos (a cada valor de X le pertenece un valor de Y y viceversa).  Esta forma normal elimina los valores repetidos dentro de una Base de Datos.

Segunda Forma Normal (2FN)

Dependencia Funcional. Una relación está en 2FN si está en 1FN y si los atributos que no forman parte de ninguna clave dependen de forma completa de la clave principal. Es decir que no existen dependencias parciales. (Todos los atributos que no son clave principal deben depender únicamente de la clave principal).

34 Tercera Forma Normal (3FN)

La tabla se encuentra en 3FN si es 2FN y si no existe ninguna dependencia funcional transitiva entre los atributos que no son clave.

2.22 DIAGRAMA ENTIDAD RELACIÓN

El Diagrama Entidad Relación (DER), fue propuesto originalmente por Peter Chen para el diseño de sistemas de bases de datos relacionales y ha sido ampliado por otros. Se identifica un conjunto de componentes primarios para el DER: objetos de datos, atributos, relaciones y varios indicadores tipo. El propósito primario del DER es representar objetos de datos y sus relaciones.

Los objetos de datos son representados por un rectángulo etiquetado. Las relaciones se indican mediante una línea etiquetada conectando objetos. En algunas variaciones del DER, la línea de conexión contiene un rombo que se etiqueta con la relación. Las conexiones entre objetos de datos y relaciones se establecen mediante una variedad de símbolos especiales que indican cardinalidad del modelado de sistemas es la definición de la forma lógica de los datos.

Figura 3: Diagrama Entidad Relación

Fuente: Elaboración Propia

35

2.23 DISEÑO

Lo fundamental en la capa de diseño es traducir la tarea de análisis, a un modelo de implementación, debe centrarse en el diseño de subsistemas, que implementan funciones principales de sistemas. Según [Pressman, 2003], el diseño Orientado a Objetos, se divide en dos grandes actividades, el diseño del sistema y el diseño de objetos. En la siguiente figura se representa la relación entre el Análisis Orientado a Objetos y el Diseño Orientado a Objetos, la pirámide del diseño consta de cuatro capas, la capa de subsistema, capa de clases y objetos, capa de mensajes y la capa de responsabilidades. Figura 4: Traducción del Modelo de Requerimiento al Modelo de Diseño

Fuente: [Pressman, 1999]

El diseño del sistema comprende la arquitectura básica, en esta fase se tomarán decisiones estratégicas. El proceso de diseño del sistema abarca las siguientes actividades:

36

 Partición del modelo de análisis en subsistemas.  Identificar la concurrencia dictada por el problema.  Asignar subsistemas a procesadores y tareas.  Desarrollar un diseño para la interfaz de usuario.  Elegir una estrategia básica para implementar la administración (gestión) de datos.  Identificar recursos globales y los mecanismos de control requeridos para su acceso.  Diseñar un mecanismo de control apropiado para el sistema, incluyendo administración de tareas.  Considerar como deben manejarse las condiciones de frontera.

2.24 PROCESO DE DISEÑO DE OBJETOS

El diseño de objetos tiene que ver con el diseño detallado de objetos y sus interacciones. Se completa dentro de la arquitectura global, definida durante el diseño del sistema y de acuerdo con las reglas y protocolos de diseño aceptados. El diseño del objeto está relacionado en particular con la especificación de los tipos de atributos, cómo funcionan las operaciones y como los objetos se enlazan con otros objetos.

Se definen las estructuras de datos locales (para atributos), y se diseñan los algoritmos (para operaciones), para esto se debe hacer una descripción de objetos y un diseño de algoritmos y estructuras de datos.

37

2.25 DISEÑO DE ALGORITMOS Y ESTRUCTURA DE DATOS

Las representaciones contenidas en el modelo de análisis y el diseño de sistemas, proveen una especificación para todas las operaciones y atributos necesarios para la especificación de algoritmos y estructuras de datos.

Se deben crear algoritmos para implementar la especificación para cada operación. En muchas ocasiones, el algoritmo es una simple secuencia computacional o procedural. Sin embargo, si la especificación de la operación es compleja, será necesario modularizar la operación.

La estructura de datos se diseña al mismo tiempo que los algoritmos. Ya que las operaciones manipulan los atributos de una clase, el diseño de estructuras de datos, que reflejan mejor los atributos, tendrá un fuerte sentido en el diseño algorítmico de las operaciones correspondientes.

Aunque existen muchos tipos diferentes de operaciones, normalmente se pueden dividir en tres grandes categorías: operaciones que manipulan los datos de alguna manera (por ejemplo: agregando, eliminando, reformateando, seleccionando), operaciones que ejecutan cálculos y operaciones que monitorizan o supervisan (por ejemplo, operaciones que devuelven valores tipo booleano) al objeto para la ocurrencia de un suceso controlado.

2.26 METODOLOGÍA DE DESARROLLO DE SOFTWARE Un proceso de software detallado y completo suele denominarse “Metodología”. Las metodologías se basan en una combinación de los modelos de proceso genéricos (cascada, evolutivo, incremental, espiral entre otros). Adicionalmente una metodología debería definir con precisión los artefactos, roles y actividades involucrados, junto con prácticas y técnicas recomendadas, guías de adaptación de la metodología al proyecto, guías para uso de herramientas de apoyo, etc. Habitualmente se utiliza el término “método” para referirse a técnicas, notaciones y guías asociadas, que son aplicables a una (o algunas) actividades del proceso de desarrollo, por ejemplo, suele hablarse de métodos de análisis y/o diseño.

38 La comparación y/o clasificación de metodologías no es una tarea sencilla debido a la diversidad de propuestas y diferencias en el grado de detalle, información disponible y alcance de cada una de ellas. A grandes rasgos, si tomamos como criterio las notaciones utilizadas para especificar artefactos producidos en actividades de análisis y diseño, podemos clasificar las metodologías en dos grupos: Metodologías Estructuradas y Metodologías Orientadas a Objetos. Por otra parte, considerando su filosofía de desarrollo, aquellas metodologías con mayor énfasis en la planificación y control del proyecto, en especificación precisa de requisitos y modelado, reciben el apelativo de Metodologías Tradicionales (o también denominadas Metodologías Pesadas, o Peso Pesado). Otras metodologías, denominadas Metodologías Ágiles, están más orientadas a la generación de código con ciclos muy cortos de desarrollo, se dirigen a equipos de desarrollo pequeños, hacen especial hincapié en aspectos humanos asociados al trabajo en equipo e involucran activamente al cliente en el proceso.

Metodologías Agiles

El desarrollo de software no es una tarea fácil. Prueba de ello es que existen numerosas propuestas metodológicas que inciden en distintas dimensiones del proceso de desarrollo. Por una parte tenemos aquellas propuestas más tradicionales que se centran especialmente en el control del proceso, estableciendo rigurosamente las actividades involucradas, los artefactos que se deben producir, y las herramientas y notaciones que se usarán. Estas propuestas han demostrado ser efectivas y necesarias en un gran número de proyectos, pero también han presentado problemas en otros muchos. Una posible mejora es incluir en los procesos de desarrollo más actividades, más artefactos y más restricciones, basándose en los puntos débiles detectados. Sin embargo, el resultado final sería un proceso de desarrollo más complejo que puede incluso limitar la propia habilidad del equipo para llevar a cabo el proyecto. Otra aproximación es centrarse en otras dimensiones, como por ejemplo el factor humano o el producto software. Esta es la filosofía de las metodologías ágiles, las cuales dan mayor valor al individuo, a la colaboración con el cliente y al desarrollo incremental del software con iteraciones muy cortas. Este enfoque está mostrando su efectividad en proyectos con requisitos muy cambiantes y cuando se exige reducir drásticamente los tiempos de desarrollo pero manteniendo una alta calidad. Las metodologías ágiles están revolucionando la manera de producir software,

39 y a la vez generando un amplio debate entre sus seguidores y quienes por escepticismo o convencimiento no las ven como alternativa para las metodologías tradicionales. En este trabajo se presenta resumidamente el contexto en el que surgen las metodologías ágiles, sus valores, principios y comparaciones con las metodologías tradicionales. Además se describe con mayor detalle Programación Extrema (eXtreme Programming, XP) la metodología ágil más popular en la actualidad (Patricio Letelier & Mª Carmen Penadés, 2006).

Xtreme Programming (XP)

La programación extrema o Xtreme Programming (XP) es un enfoque de la ingeniería de software formulado por Kent Beck, autor del primer libro sobre la materia, Extreme Programming Explained: Embrace Change (1999). Es el más destacado de los procesos ágiles de desarrollo de software. Al igual que éstos, la programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad. Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos.

Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos. Es una metodología ágil centrada en potenciar las relaciones interpersonales como clave para el éxito en desarrollo de software, promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en realimentación continua entre el cliente y el equipo de desarrollo, comunicación fluida entre todos los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los cambios. XP se define como especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo técnico. Manifiesto Ágil En una reunión celebrada en febrero de 2001 en Utah-EEUU, nace el término "ágil" aplicado al desarrollo de software. En esta reunión participan un grupo de 17 expertos de la industria del

40 software, incluyendo algunos de los creadores o impulsores de metodologías de software. Su objetivo fue esbozar los valores y principios que deberían permitir a los equipos desarrollar software rápidamente y respondiendo a los cambios que puedan surgir a lo largo del proyecto. Se pretendía ofrecer una alternativa a los procesos de desarrollo de software tradicionales, caracterizados por ser rígidos y dirigidos por la documentación que se genera en cada una de las actividades desarrolladas. Varias de las denominadas metodologías ágiles ya estaban siendo utilizadas con éxito en proyectos reales, pero les faltaba una mayor difusión y reconocimiento. Tras esta reunión se creó The Agile Alliance3, una organización, sin ánimo de lucro, dedicada a promover los conceptos relacionados con el desarrollo ágil de software y ayudar a las organizaciones para que adopten dichos conceptos. El punto de partida es fue el Manifiesto Ágil, un documento que resume la filosofía "ágil". (Patricio Letelier & Mª Carmen Penadés, 2006)

Según el Manifiesto Ágil se valora:  Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas. La gente es el principal factor de éxito de un proyecto software. Es más importante construir un buen equipo que construir el entorno. Muchas veces se comete el error de construir primero el entorno y esperar que el equipo se adapte automáticamente. Es mejor crear el equipo y que éste configure su propio entorno de desarrollo en base a sus necesidades.  Desarrollar software que funciona más que conseguir una buena documentación. La regla a seguir es “no producir documentos a menos que sean necesarios de forma inmediata para tomar un decisión importante”. Estos documentos deben ser cortos y centrarse en lo fundamental.  La colaboración con el cliente más que la negociación de un contrato. Se propone que exista una interacción constante entre el cliente y el equipo de desarrollo. Esta colaboración entre ambos será la que marque la marcha del proyecto y asegure su éxito.  Responder a los cambios más que seguir estrictamente un plan. La habilidad de responder a los cambios que puedan surgir a los largo del proyecto (cambios en los requisitos, en la

41 tecnología, en el equipo, etc.) determina también el éxito o fracaso del mismo. Por lo tanto, la planificación no debe ser estricta sino flexible y abierta.

Los valores anteriores inspiran los doce principios del manifiesto. Son características que diferencian un proceso ágil de uno tradicional. Los dos primeros principios son generales y resumen gran parte del espíritu ágil. El resto tienen que ver con el proceso a seguir y con el equipo de desarrollo, en cuanto metas a seguir y organización del mismo.

Los principios son:

I.

La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de software que le aporte un valor.

II.

Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una ventaja competitiva.

III.

Entregar frecuentemente software que funcione desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre entregas.

IV.

La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto.

V.

Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo.

VI.

El diálogo cara a cara es el método más eficiente y efectivo para comunicar información dentro de un equipo de desarrollo.

VII.

El software que funciona es la medida principal de progreso.

42 VIII.

Los procesos ágiles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios deberían ser capaces de mantener una paz constante.

IX.

X.

La atención continua a la calidad técnica y al buen diseño mejora la agilidad.

XI.

La simplicidad es esencial.

Las mejores arquitecturas, requisitos y diseños surgen de los equipos organizados por sí mismos.

XII.

En intervalos regulares, el equipo reflexiona respecto a cómo llegar a ser más efectivo, y según esto ajusta su comportamiento.

Características

La programación extrema o XP tiene las siguientes características:  Desarrollo iterativo e incremental: pequeñas mejoras, unas tras otras.  Pruebas unitarias continuas, frecuentemente repetidas y automatizadas, incluyendo pruebas de regresión. Se aconseja escribir el código de la prueba antes de la codificación.  Programación en parejas: recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. Se supone que la mayor calidad del código escrito de esta manera -el código es revisado y discutido mientras se escribe es más importante que la posible pérdida de productividad inmediata.  Frecuente integración del equipo de programación con el cliente o usuario. Recomienda que un representante del cliente trabaje junto al equipo de desarrollo.  Corrección de todos los errores antes de añadir nueva funcionalidad. Hacer entregas frecuentes.

43  Refactorización del código, es decir, rescribir ciertas partes del código para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorización no se ha introducido ningún fallo.  Propiedad del código compartida: en vez de dividir la responsabilidad en el desarrollo de cada módulo en grupos de trabajo distintos, este método promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresión garantizan que los posibles errores serán detectados.  Simplicidad en el código: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podrá añadir funcionalidad si es necesario. La programación extrema apuesta que es más sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizás nunca utilizarlo, la simplicidad y la comunicación son extraordinariamente complementarias. Con más comunicación resulta más fácil identificar qué se debe y qué no se debe hacer. Cuanto más simple es el sistema, menos tendrá que comunicar sobre éste, lo que lleva a una comunicación más completa, especialmente si se puede reducir el equipo de programadores. Figura 5: Características Metodología XP

FUENTE: Programación Extrema – Universidad Técnica de Manabi – 2012

44 Ciclo de vida de XP Figura 6: Ciclo de Vida Proyecto XP

Evolución de los ciclos largos de desarrollo en cascada a) A ciclos más cortos b) La combinación concluye en el método XP c)

Objetivos Método XP  Establecer las mejores prácticas de Ingeniería de Software en los desarrollos de proyectos.  Mejorar la productividad de los proyectos.  Garantizar la Calidad del Software desarrollando, haciendo que este supere las expectativas del cliente.

Contexto XP  Cliente bien definido

45  Los requisitos pueden (y van a) cambiar  Grupo pequeño y muy integrado (máximo 12 personas)  Equipo con formación elevada y capacidad de aprender

Valores XP  Simplicidad XP propone el principio de hacer la cosa más simple que pueda funcionar, en relación al proceso y la codificación. Es mejor hacer hoy algo simple, que hacerlo complicado y probablemente nunca usarlo mañana.  Comunicación, algunos problemas en los proyectos tienen origen en que alguien no dijo algo importante en algún momento. XP hace casi imposible la falta de comunicación.  Realimentación concreta y frecuente del cliente, del equipo y de los usuarios finales da una mayor oportunidad de dirigir el esfuerzo eficientemente.  Coraje, el coraje (valor) existe en el contexto de los otros 3 valores. (si funciona…mejóralo).

Estilo XP  Está orientada hacia quien produce y usa el software  Reduce el costo del cambio en todas las etapas del ciclo de vida del sistema.  Combina las que han demostrado ser las mejores prácticas para desarrollar software, y las lleva al extremo.

46 Prácticas Básicas de Programación Extrema

Para que funcione la programación extrema, esta se basa en doce "prácticas básicas" que deben seguirse al pie de la letra. Dichas prácticas están definidas de acuerdo al siguiente detalle:

a) Equipo completo: Forman parte del equipo todas las personas que tienen algo que ver con el proyecto, incluido el cliente y el responsable del proyecto.

b) Planificación: Se hacen las historias de usuario y se planifica en qué orden se van a hacer y las mini-versiones. La planificación se revisa continuamente.

c) Test del cliente: El cliente, con la ayuda de los desarrolladores, propone sus propias pruebas para validar las mini-versiones.

d) Versiones pequeñas: Las mini-versiones deben ser lo suficientemente pequeñas como para poder hacer una cada pocas semanas. Deben ser versiones que ofrezcan algo útil al usuario final y no trozos de código que no pueda ver funcionando.

e) Diseño simple: Hacer siempre lo mínimo imprescindible de la forma más sencilla posible. Mantener siempre sencillo el código.

f) Pareja de programadores: Los programadores trabajan por parejas (dos delante del mismo ordenador) y se intercambian las parejas con frecuencia (un cambio diario).

g) Desarrollo guiado por las pruebas automáticas: Se deben realizar programas de prueba automática y deben ejecutarse con mucha frecuencia. Cuantas más pruebas se hagan, mejor. h) Integración continua: Deben tenerse siempre un ejecutable del proyecto que funcione y en cuanto se tenga una nueva pequeña funcionalidad, debe recompilarse y probarse. Es un error mantener una versión congelada dos meses mientras se hacen mejoras y luego

47 integrarlas todas de golpe. Cuando falle algo, no se sabe qué es lo que falla de todo lo que hemos metido.

i) El código es de todos: Cualquiera puede y debe tocar y conocer cualquier parte del código. Para eso se hacen las pruebas automáticas.

j) Normas de codificación: Debe haber un estilo común de codificación, de forma que parezca que ha sido realizado por una única persona.

k) Metáforas: Hay que buscar unas frases o nombres que definan cómo funcionan las distintas partes del programa, de forma que sólo con los nombres se pueda uno hacer una idea de qué es lo que hace cada parte del programa. Un ejemplo claro es el "recolector de basura" de java. Ayuda a que todos los programadores (y el cliente) sepan de qué estamos hablando y que no haya mal entendidos.

l) Ritmo sostenible: Se debe trabajar a un ritmo que se pueda mantener indefinidamente. Esto quiere decir que no debe haber días muertos en que no se sabe qué hacer y que no se deben hacer un exceso de horas otros días. Al tener claro semana a semana lo que debe hacerse, hay que trabajar duro en ello para conseguir el objetivo cercano de terminar una historia de usuario o mini-versión.

Roles  El jefe de proyecto tiene como responsabilidad la dirección y organización de las reuniones que se realizan durante el proyecto.  El usuario o cliente determina qué se va a construir en el sistema, además de decidir el orden en que se entregarán cada segmento del proyecto.  En el grupo de los programadores se encuentran además los diseñadores y los analistas. Los programadores son quienes construyen el sistema y realizan las pruebas correspondientes a cada módulo o unidad de código.

48

 El tester o quien realiza las pruebas, colabora en la realización de las pruebas de aceptación y es quien muestra los resultados de las mismas.  El rastreador (tracker) tiene como tarea observar la realización del sistema. Varias veces por semana cuestiona a los integrantes del equipo para anotar sus logros y avances.

Ventajas  Programación organizada.  Menor taza de errores.  Satisfacción del programador.

Las metodologías livianas o ágiles, como XP, están orientadas a las personas más que a los procesos. Hay que tener en cuenta que en el desarrollo del software, el diseño es la actividad predominante (en XP el diseño es una actividad diaria). XP supone que:  Las personas son claves en los procesos de desarrollo de software.  Los programadores son profesionales responsables, no requieren de supervisión.  Los procesos se aceptan y acuerdan, no se imponen.  Desarrolladores y gerentes comparten el liderazgo del proyecto.  El trabajo de los desarrolladores con las personas que tienen la experiencia en el negocio es regular, no eventual.

49 Conviene recordar que ninguna metodología hará el trabajo por uno, porque ninguna metodología trabaja sola.

Figura 7: Complementación de Prácticas

FUENTE: Encuesta de Aceptación de XP realizada por IBM

La tabla siguiente compara las distintas aproximaciones ágiles en base a tres parámetros: vista del sistema como algo cambiante, tener en cuenta la colaboración entre los miembros del equipo y características más específicas de la propia metodología como son simplicidad, excelencia técnica, resultados, adaptabilidad, etc. También incorpora como referencia no ágil el Capability Madurity Model (CMM) – (Modelo de Evaluación de Procesos de una Organización).

50 Figura 8: Comparación de Metodologías de Desarrollo Agiles ADAPTABILIDAD – TRABAJO EN EQUIPO - SIMPLICIDAD

FUENTE: (Luna Tellez, 2012)

Como se observa en la anterior Tabla todas las metodologías ágiles tienen una significativa diferencia del índice de agilidad respecto a CMM y entre ellas destacan ASD, Scrum y XP como las más ágiles

No existe una metodología universal para hacer frente con éxito a cualquier proyecto de desarrollo de software. Toda metodología debe ser adaptada al contexto del proyecto (recursos técnicos y humanos, tiempo de desarrollo, tipo de sistema, etc. (Luna Tellez, 2012).

Historias de Usuario Características: Independientes unas de otras: Cada una tiene un resultado, deberán ser autónomas una de otra historia.

51 Negociables: La discusión con los usuarios debe permitir esclarecer su alcance y éste debe dejarse explícito bajo la forma de pruebas de validación. Valoradas por los clientes o usuarios: Cada historia debe ser importante para los usuarios más que para el desarrollador. Estimables: Un resultado de la discusión de una historia de usuario es la estimación del tiempo que tomará completarla. Short - Small (cortas-pequeñas): Generalmente se recomienda la consolidación de historias muy cortas en una sola historia. Testeable: Las historias de usuario cubren requerimientos funcionales, por lo que generalmente son verificables. Figura 9: Historias de Usuario

FUENTE: Elaboración Propia

52 2.27 IMPLEMENTACIÓN

En esta fase se debe implementar el diseño, hasta ahora, todos los modelos fueron construidos en forma independiente de la plataforma de implementación, en esta fase se tiene en cuenta el entorno particular en el cual se va a correr la aplicación.

Al llegar a esta fase, el primer paso que debe realizar el diseñador es definir los ítems de información que son parte del dominio del problema. Debe identificar también, cómo son organizados los ítems de acuerdo con el perfil del usuario y su tarea, decidir qué interfaz debería ver y como debería comportarse a fin de implementar todo en su entorno web, el diseñador debe decidir además qué información debe ser almacenada.

2.28 PRUEBAS DE CAJA NEGRA

Las pruebas de Caja Negra, permiten obtener un conjunto de condiciones de entrada que ejerciten completamente todos los requisitos funcionales de un programa. En ellas se ignora la estructura de control, concentrándose en los requisitos funcionales del sistema y ejercitándolos. La prueba de Caja Negra es un enfoque complementario que intenta descubrir diferentes tipos de errores. Muchos autores consideran que estas pruebas permiten encontrar:  Funciones incorrectas o ausentes.  Errores de interfaz.  Errores en estructuras de datos o en accesos a las Bases de Datos externas.  Errores de rendimiento.  Errores de inicialización y terminación.

53 Figura 10: Imagen de Caja Negra

Fuente: (Pressman, 1997)

Para preparar los casos de pruebas hacen falta un número de datos que ayuden a la ejecución de los estos casos y que permitan que el sistema se ejecute en todas sus variantes, pueden ser datos válidos o inválidos para el programa según si lo que se desea es hallar un error o probar una funcionalidad. Los datos se escogen atendiendo a las especificaciones del problema, sin importar los detalles internos del programa, a fin de verificar que el programa corra bien.

Para desarrollar la prueba de caja negra existen varias técnicas, entre ellas están:

Técnica de la Partición de Equivalencia: esta técnica divide el campo de entrada en clases de datos que tienden a ejercitar determinadas funciones del software.

Técnica del Análisis de Valores Límites: esta Técnica prueba la habilidad del programa para manejar datos que se encuentran en los límites aceptables.

Técnica de Grafos de Causa-Efecto: es una técnica que permite al encargado de la prueba validar complejos conjuntos de acciones y condiciones.

Dentro del método de Caja Negra la técnica de la Partición de Equivalencia es una de las más efectivas pues permite examinar los valores válidos e inválidos de las entradas existentes en el software, descubre de forma inmediata una clase de errores que, de otro modo, requerirían la

54 ejecución de muchos casos antes de detectar el error genérico. La partición equivalente se dirige a la definición de casos de pruebas que descubran clases de errores, reduciendo así en número de clases de prueba que hay que desarrollar.

Con la aplicación de esa técnica se obtiene un conjunto de pruebas que reduce el número de casos de pruebas y nos dicen algo sobre la presencia o ausencia de errores. A menudo se plantea que las pruebas a los software nunca terminan, simplemente se transfiere del desarrollador al cliente. Cada vez que el cliente usa el programa está llevando a cabo una prueba. Aplicando el diseño de casos de pruebas al software en cuestión se puede conseguir una prueba más completa y descubrir y corregir el mayor número de errores antes de que comiencen las “pruebas del cliente”.

Procedimientos de prueba

Un procedimiento de prueba específica como realizar uno o varios casos de prueba o parte de estos. Por ejemplo un procedimiento de prueba puede ser una instrucción para un individuo sobre como se realizará un caso de prueba manualmente, o puede ser una especificaron de cómo interaccionar manualmente con una herramienta de automatización de pruebas para crear componentes ejecutables de pruebas.

Componentes de prueba

Un componente de prueba automatiza uno o varios procedimientos de prueba o parte de ellos. Los componentes de pruebas pueden ser desarrollados utilizando lenguaje de guiones o un lenguaje de programación o pueden ser grabados con una herramienta de automatización de pruebas.

Los componentes de pruebas se utilizan para probar los componentes en el modelo de implementación proporcionando entradas de prueba, controlando y monitorizando la ejecución de los componentes a probar y, posiblemente informando de los resultados de las pruebas.

55 Plan de Prueba

El propósito del plan de pruebas es dejar de forma explícita el alcance, el enfoque, los recursos requeridos, el calendario, los responsables y el manejo de riesgos de un proceso de pruebas. Está constituido por un conjunto de pruebas. Cada prueba debe:

Dejar claro qué tipo de propiedades se quieren probar (corrección, robustez, fiabilidad, amigabilidad,...).

Dejar claro cómo se mide el resultado.

Especificar en qué consiste la prueba (hasta el último detalle de cómo se ejecuta). Definir cuál es el resultado que se espera (identificación, tolerancia,...). ¿Cómo se decide que el resultado es acorde con lo esperado?

Las pruebas carecen de utilidad, tanto, sí no se sabe exactamente lo que se quiere probar, sí no se está claro cómo se prueba, o si el análisis del resultado se hace a simple vista. Estas mismas ideas se suelen agrupar diciendo que un caso de prueba consta de 3 bloques de información:  El propósito de la prueba.  Los pasos de ejecución de la prueba.  El resultado que se espera.

Todos y cada uno de esos puntos deben quedar perfectamente documentados. El plan de pruebas señala el enfoque, los recursos y el esquema de actividades de prueba, así como los elementos a probar, las características, las actividades de prueba, el personal responsable y los riesgos.

56 Una estrategia de prueba propone movernos hacia afuera en una espiral, de manera que primero se prueban las unidades más pequeñas del diseño del software (clases o módulos) y después como se integran los componentes en los cuales están contenidas estas unidades.

XP propone definir casos de prueba de integración para verificar que los componentes interaccionan entre sí de forma apropiada.

A partir de un caso de uso se pueden realizar pruebas de caja negra, obteniéndose varios casos de prueba que permiten:  Verificar el resultado de la interacción entre los actores y el sistema.  Comprobar que se satisfagan las precondiciones y postcondiciones del caso de uso.  Comprobar que se siga la secuencia de acciones especificado por el caso de uso.

También se pueden realizar pruebas de caja blanca a partir de la realización de un caso de prueba que permiten obtener casos de prueba en los que se verifica la integración ante los componentes que implementan dicho caso de uso.

Como conclusión se podría decir que se pueden definir múltiples casos de prueba de integración para cada caso de uso en dependencia de las condiciones de prueba que se tengan en cuenta.

Las pruebas del sistema se usan para probar que el sistema funciona correctamente como un todo.

Defecto

Un defecto es una anomalía del sistema, como por ejemplo un síntoma de una fallo software o un problema descubierto en una revisión. Un defecto puede ser utilizado para localizar cualquier cosa que los desarrolladores necesitan registrar como síntoma de un problema en el sistema que ellos necesitan controlar y resolver

57 Evaluación de prueba

Una evaluación de prueba es una evaluación de los resultados de los esfuerzos de prueba, tales como la cobertura del caso de prueba, la cobertura del código y el estado de los defectos.

2.29 PRUEBAS METODOLOGIA XP

Pruebas Unitarias

Estas pruebas se aplican a todos los métodos no triviales de todas las clases del proyecto con la condición que no se liberará ninguna clase que no tenga asociada su correspondiente paquete de pruebas. Uno de los elementos más importantes en estas es que idealmente deben ser construidas antes que los métodos mismos, permitiéndole al programador tener máxima claridad sobre lo que va a programar antes de hacerlo, así como conocer cada uno de los casos de prueba que deberá pasar, lo que optimizará su trabajo y su código será de mejor calidad.

Pruebas de Aceptación

Las pruebas de aceptación, también llamadas pruebas funcionales son supervisadas por el cliente basándose en los requerimientos tomados de las historias de usuario. En todas las iteraciones, cada una de las historias de usuario seleccionadas por el cliente deberá tener una o más pruebas de aceptación, de las cuales deberán determinar los casos de prueba e identificar los errores que serán corregidos.

58 Figura 11: Prueba de Aceptación

Fuente: (Patricio Letelier & Mª Carmen Penadés, 2006)

2.30 SEGURIDAD

Desde un punto de vista de la seguridad informática, una red debe entenderse como un entorno de cómputo con más de un ordenador independiente. No obstante, la introducción de las redes informáticas no modifica tan solo cuantitativamente el problema de seguridad, sino que supone un incremento cualitativo del mismo. No se trata tan solo de que debamos proteger un mayor número de ordenadores de un mayor número de atacantes potenciales, sino que se introducen toda una nueva serie de técnicas y herramientas para protegernos de ellas.

59 2.31 CIFRADO AES - 256

El estándar de cifrado (encriptación) avanzado AES, Advanced Encryption Standard (AES), es uno de los algoritmos más seguros y más utilizados hoy en día - disponible para uso público.

Está clasificado por la Agencia de Seguridad Nacional, National Security Agency (NSA), de los Estados Unidos para la seguridad más alta de información secreta “Top Secret”. Su historia de éxito comenzó 1997, cuando el Instituto Nacional de Estándares y Tecnología, National Institute of Standards and Technology (NIST), anunció la búsqueda de un sucesor para el estándar de cifrado DES. Un algoritmo llamado "Rijndael", desarrollado por los criptólogos belgas Joan Daemen y Vincent Rijmen, fue destacado en seguridad, así como en el rendimiento y la flexibilidad. Este algoritmo le gano a varios competidores, y fue oficialmente presentado como el nuevo estándar de cifrado AES en el 2001 y se transformó en estándar efectivo en el 2002. El algoritmo se basa en varias sustituciones, permutaciones y transformaciones lineales, ejecutadas en bloques de datos de 16 bytes - por lo que se le llama blockcipher. Estas operaciones se repiten varias veces, llamadas "rondas". En cada ronda, un único “roundkey” se calcula de la clave de encriptación, y es incorporado en los cálculos. Basado en esta estructura de bloque de AES, el cambio de un solo bit, ya sea en la clave, o en los bloques de texto simple y claro, resulta en un bloque de texto cifrado/encriptado completamente diferente - una clara ventaja sobre cifrados de flujo tradicionales. La diferencia entre AES-128, AES-192 y AES-256, es la longitud de la clave: 128, 192 o 256 bits - todos drásticamente mejorados en comparación con la clave DES de 56 bits. A modo de ejemplo: Descifrar una clave de 128 bits AES con una supercomputadora estándar del momento, llevaría más tiempo que la presunta edad del universo (Boxcryptor, S/A).

2.32 CIFRADO DE BASE DE DATOS

FileMaker Server 13 admite la nueva función de cifrado de base de datos AES de 256 bits. Por lo tanto, independientemente de la ubicación de los datos, estarán protegidos de acceso no autorizado, ya estén alojados en FileMaker Server 13 o en un cliente local de FileMaker. Para activar el cifrado en todas las bases de datos, es necesario utilizar FileMaker Pro 13 Advanced.

60 Indicador de Estado de Cifrado

El indicador de estado de cifrado que aparece cuando se está realizando una conexión segura a FileMaker Server 13 desde FileMaker Pro 13 también es nuevo. Cuando la conexión es validada por un certificado de terceros, el indicador se volverá verde.

Gestión Mejorada de Certificado SSL

En FileMaker Server 13 es incluso más fácil aumentar la seguridad en sus bases de datos. Si se utiliza una instalación de equipo único, sólo se necesita un certificado SSL para admitir a todos los clientes: FileMaker Pro, FileMaker Go y FileMaker WebDirect.

61

3. MARCO DE DESARROLLO

62 3.1

INTRODUCCIÓN

Se establece que el tratamiento documental utilizando elementos propios del análisis de información, facilita el acceso y utilización de la información contenida en los documentos archivados en la “U.E.L.I.C.N.”. En cada fase del tratamiento documental, se apeló al análisis de información, en particular, en aquellos procesos relacionados con el pago específicamente

De la praxis del análisis documental, fueron representados sistemática y sintéticamente los documentos originales, facilitando su interpretación ante cualquier consulta; siendo consideradas estas como fuente de documento primario asegurando de esta manera que, tanto el tratamiento documental como el análisis de información, permitieron ganar en eficacia y eficiencia a momento de emprender el presente proyecto ya que el análisis de información como el tratamiento documental surgieron, también, con fines de orientación científica e informativa

Asimismo, identificados los problemas, basados en el trabajo de campo realizado por medio de entrevistas con el personal involucrado en el proceso de planillas se establecen requerimientos del producto, desarrollo, construcción, implementación, pruebas, actividades de mantenimiento y métricas del sistema.

3.2

RECOPILACIÓN DE NECESIDADES

Se considera necesario optimizar la elaboración de planillas de pago, con el fin de que el responsable en procesar esta tarea, utilice el menor tiempo posible, sin riesgos de cometer errores en el prorrateo de días trabajados, producto de vacaciones, permisos, comisiones de estudios, pre natal, post natal y otros.

Los enlaces, encargados de elaborar las planillas en cada Dirección y/o Fuerza reconocida en D.S. 0282, elevarán a la “U.E.L.I.C.N.”

las planillas preliminares mensuales de pago,

especificando montos solicitados, número de casos, altas, bajas, cambios de niveles, comisiones de estudios, bajas médicas, vacaciones, permisos, cambios de cuentas y otros con la respectiva

63 justificación documental y principalmente remitirá todas las planillas y anexos en medio digital(cd-dvd), mismas que deberá guardar estrecha relación con la información documental.

En la UELICN se procederá a la realización del chequeo de seguridad, procedimiento que permitirá validar la documentación de las solicitudes de altas así como la idoneidad de los mismos a partir de la verificación de antecedentes en estricto cumplimiento al reglamento de pago del Reconocimiento Económico.

Por su parte el responsable de la elaboración de planilla de Pago del Reconocimiento Económico de la “U.E.L.I.C.N.”, validará la información documental y digital remitida, realizando la consistencia de la información, afectando los pagos individualmente en caso de que los mismos no se encontrasen enmarcados en el reglamento específico de Pago de Reconocimiento Económico.

Las planillas de Pago de Reconocimiento Económico deberán ser generadas automáticamente, complementariamente el sistema generará un archivo plano de acuerdo a parámetros solicitados por la entidad financiera contratada, permitiendo de esta manera realizar el pago mediante cuentas bancarias a nivel nacional, optimizando costos y garantizando la seguridad que el caso amerita.

La escalabilidad del sistema a un posible cambio de la norma en actual vigencia repercutirá de manera sustancial en el sistema, por tanto dependerá del grado de modificación de la misma.

64 3.3

MAPA DE PROCESOS ACTUAL – “U.E.L.I.C.N.”

FUENTE: Elaboración Propia

Figura 12: Proceso de Pago de Reconocimiento Económico

De las herramientas de relevamiento de la información se establece el siguiente mapa de procesos

65 3.4

MATRIZ DE PROCESOS Tabla 4: Matriz de Procesos MATRIZ DESCRIPTIVA DEL PROCESO RESPONSABLE(S) DEL

NOMBRE DEL PROCESO

OBJETIVO DEL PROCESO

PROCESO

Administrar

Pago Reconocimiento Económico



Responsable

de

Reconocimiento Económico

destinado

el al

Económico

presupuesto reconocimiento

garantizando

el

cumplimiento de objetivos de la institución.

PROVEEDORES DEL PROCESO 

FELCN, FTC-CEO, Diablos Negros,

Azules,

Rojos,

UPE,

PARÁMETROS DE

ENTRADAS DEL PROCESO

Verdes, CP

Y

DICPROCOCA



Solicitudes



Planillas



Descargos

SALIDAS DEL PROCESO

CLIENTES DEL PROCESO



Planillas de Pago





Conciliaciones de gasto



Informes de pago aprobados



CONTROL DEL PROCESO 

Ejecución de Fondos.



Planillas de pago.

RECURSOS HUMANOS PARA EL PROCESO

Enlaces de Interdicción y

Profesional

en

el

Erradicación

administrativa/financiera

FTC

sistemas

área

MAQUINARIA Y EQUIPOS

INFRAESTRUCTURA

AMBIENTE DE TRABAJO

REQUERIDOS POR EL

NECESARIA PARA EL

REQUERIDO POR EL

PROCESO

PROCESO

PROCESO

Equipamiento asignado

y

mobiliario

(Equipos

Computación,

de

Impresoras,

y

Condiciones ergonómicas y 

Oficinas adecuadas

antropométricas óptimas para los involucrados

Escáneres, etc.).

INTERRELACIONES DEL PROCESO 

Procesos de conciliación.



Procesos contables. FUENTE: ELABORACIÓN PROPIA

66 3.5

CEDIMIENTO RECONOCIMIENTO ECONÓMICO Objetivos del Procedimiento

Cumplir con lo establecido en el D.S. 282/2009, referido al reconocimiento económico mensual, al personal policial, militar y civil que trabaja en la lucha integral contra el narcotráfico, con la finalidad de compensar los esfuerzos, riesgos y presión permanente a los que está expuesto el personal comprometido en la lucha contra este delito de lesa humanidad.

Marco Legal / Normativo  Decreto Supremo N° 282/2009 (LEXIVOX, 2009).  Resolución Multi-Ministerial Nº 001/2013 – Reglamento de Pago de Reconocimiento Económico.  Ley Nº 1178 de Administración y Control Gubernamentales  Resolución Suprema Nº 225557 – NB SPO  Resolución Suprema Nº 225558 – NB SP

Siglas y Abreviaturas “U.E.L.I.C.N.”: Unidad Ejecutora de Lucha Integral Contra el Narcotráfico.

MEFP: Ministerio de Economía y Finanzas Públicas

TGN: Tesoro General de la Nación.

67 “F.E.L.C.N.”: Fuerza Especial de Lucha Contra el Narcotráfico “F.T.C.”: Fuerza de Tarea Conjunta. “C.E.O.”: Comando Estratégico Operacional “F.T.E.”: Fuerza de Tarea Especial “DI.G.PRO.COCA”: Dirección General de Desarrollo Integral de las Regiones productoras de Coca “U.P.E.”: Unidad de Policía Ecológica. “C.P”: Componente Policial

Registro, Formularios o Impresos de Entrada

Planilla de personal beneficiario del Reconocimiento Económico.

3.5.4.1 PROVEEDORES - ENLACES  FELCN  FTC – CEO  FTC – COMPONENTE POLICIAL  DIABLOS ROJOS  DIABLOS NEGROS

68  DIABLOS AZULES  DIABLOS VERDES  UPE  DIGPROCOCA

3.5.4.2 Registros, Formularios Impresos de Salida  Planilla de Pago.  Comprobantes de Contabilidad

3.5.4.3 Responsables del Procedimiento  Responsable de Reconocimiento Económico  Archivo y Kardex (Chequeo de Seguridad)  Responsable de Enlace Interdicción - Erradicación  Responsable de Presupuesto  Responsable de Contabilidad  Responsable del Tesorería  Jefe de Unidad de Apoyo Logístico Financiero

69 3.5.4.4 TIEMPO ESTIMADO DEL PROCEDIMIENTO

 30 días Tabla 5: Tabla de Procedimientos por Tiempo

Fuente: Elaboración Propia

3.5.4.5 RECURRENCIA  Mensual Actividades y Responsables

Nº

Paso 1

Paso 2

ACTIVIDADES

RESPONSABLES

Solicitud de pago de reconocimiento económico adjuntado listado de

FELCN, FTC, FTE

personal policial, civil y militar.

La Coordinación General, revisa la solicitud e instruye a la Unidad de Apoyo Logístico Financiero realizar los desembolsos

DIGPROCOCA

Coordinador/a General

Responsable de

Paso 3

Realiza la verificación de la documentación si la misma contiene los elementos necesarios procede con la elaboración de planillas de pago

Reconocimiento Económico – CHEQUEO DE SEGURIDAD

70

Paso 4

Se elaboran las planillas y se remite las mismas a los enlaces de

Responsable de

interdicción y erradicación de Pago para su revisión. Luego se deriva

Reconocimiento

a Jefe de Unidad Apoyo financiero Revisa y Paso 6

firmadas

Económico.

las planillas de pago, (que estén convenientemente por

Responsable

de

Enlace

y

Responsable

de

Jefe Unidad Apoyo

Reconocimiento Económico y remite las mismas para su aprobación

Logístico Financiero

a Coordinación General

Paso 7

Revisa y Aprueba las Planillas de Pago y devuelve las mismas a la Unidad de Apoyo Logístico Financiero

Deriva la Documentación al Responsable de Presupuesto y Paso 8

Contabilidad para el proceso de pago elaboran el comprobante C-31 (presupuesto).Comprobante contable (contabilidad)

Paso 9

Elabora Cheques y remite a cajeros

Coordinador/a General

Jefe Unidad Apoyo Logístico Financiero

Tesorería

FUENTE: Elaboración Propia

Figura 13 Flujo de Procedimientos - Reconocimiento Económico

71

FUENTE: Elaboración Propia

72

3.6

IDENTIFICACIÓN DE ACTORES Y CASOS DE USO

Identificación de Actores

Los actores identificados en el sistema son los que se mencionan a continuación:  Beneficiarios, efectivos policiales, militares y personal civil que está en la lucha integral contra el narcotráfico, reconocidos mediante D.S. 0282.  Responsable de Pago, administrador del control y posterior pago de Reconocimiento Económico, funcionario de la Unidad Ejecutora de Lucha Integral Contra el Narcotráfico “U.E.L.I.C.N.”, encargado de realizar el control de calidad del procedimiento de chequeo de seguridad y planillas de pago.  Enlace de unidad, encargado de realizar las planillas preliminares en las Direcciones y/o Fuerza reconocida en el D.S. 0282. Su designación es realizada mediante memorándum y luego de cumplir con el perfil que requiere el cargo, en la actualidad se tiene 9 enlaces con los que se viene coordinando el trabajo. Es atribución privativa de cada MAE su designación.  Archivo y Kardex, funcionario responsable de realizar el Chequeo de Seguridad, Registrar, Revisar, Organizar y Archivar la documentación de los efectivos beneficiarios del Pago de Reconocimiento Económico, de las Fuerzas y Direcciones, reconocidas en el D.S. 0282. Funcionario Público que fue contratado por la “U.E.L.I.C.N.”

73

IDENTIFICACIÓN.

I. Nombre del Puesto: Jefe Inmediato Superior: Supervisa a: Nivel: Categoría: Área a la que pertenece: Unidad a la que pertenece:

TÉCNICO EN ARCHIVO Y KÁRDEX Responsable de Reconocimiento Económico Ninguno 11 Técnico IV Financiera Unidad de Apoyo Logístico Financiero

II.

DESCRIPCIÓN

Apoyar en la Administración de la documentación remitida, y las actividades de archivo,

Objetivo

considerando las normas y procedimientos establecidos para el efecto, coadyuvando de manera periódica la pago de planillas de Reconocimiento Económico

Normas

a

cumplir

Constitución Política el Estado, Ley 1178, Ley del Estatuto del Funcionario Público y su reglamento, Reglamento de la Responsabilidad por la Función Pública, Normativa aplicable al ejercicio de sus funciones

Resultados

Funciones específicas 1

Registrar, revisar, organizar y archivar la

Registros de archivos. 30

documentación que se le encarga en custodia Procesar el chequeo de seguridad en base a

2

%

antecedentes

solicitados

a

Chequeo de seguridad aprobado

instancias

5

correspondientes

3 4

5

Diseñar elaborar y actualizar los calendarios de

Registros de archivo y transferencia

permanencia y conservación de documentos.

documental

Ejecutar procesos de clasificación ordenamiento,

Registros contables procesados y

valoración y selección documental.

consolidados

Facilitación de préstamo previa orden escrita u

Archivo ordenados y registros de

verbal del superior jerárquico, no pudiendo ser de

préstamo documental

5

30

10

oficio

6

Implementación de medidas de protección y

Mecanismos

de

salvaguarda

seguridad de los archivos y documentación que

documental implementados

10

eviten perdidas, alteraciones, deterioro en perjuicio de la integridad de la información

7

Administrar y actualizar las bases de datos de

Base

de

archivos documentales.

Actualizados

Datos

de

Archivos

10

74

III.

REQUISITOS PERSONALES

Trabajo en equipo, transparencia, integridad, desarrollo personal, compromiso organizacional,

Cualidades orientación hacia el resultado, atención oportuna, relaciones interpersonales, disciplina, responsabilidad.

NIVEL

PROFESIÓN

TIPO

Básico Téc. Superior Licenciatura



ÁREA

Técnico Superior o egresado en Ciencias Sociales o Económicas

Maestría Doctorado

Esencial Deseable

EXPERIENCIA

AÑOS

TIPO

General

En la administración pública

2

Esencial

Específica

En el área de Archivo y kárdex

1

Esencial

 Responsable de pago de Reconocimiento Económico, “U.E.L.I.C.N.”, procesa planillas consolidadas de Pago de Reconocimiento Económico de la “U.E.L.I.C.N.”

IDENTIFICACIÓN.

I. Nombre del Puesto: Jefe Inmediato Superior: Supervisa a: Nivel: Categoría: Área a la que pertenece: Unidad a la que pertenece:

RESPONSABLE DE RECONOCIMIENTO ECONÓMICO Jefe de la Unidad de Apoyo Logístico Financiero Técnico kárdex Reconocimiento Económico 5 Responsable III Reconocimiento Económico Unidad de Apoyo Logístico Financiero

II.

DESCRIPCIÓN

Efectivización del Decreto Supremo Nº 282 de 2 de septiembre de 2009;

Objetivo

Reconocimiento económico mensual, al personal policial, militar y civil que trabaja en la lucha integral contra el narcotráfico, con la finalidad de compensar los esfuerzos riesgos presión permanente a los que está

75

expuesto el personal comprometido en la lucha contra este delito de lesa humanidad

Normas

Constitución Política el Estado, Ley 1178, Ley del Estatuto del Funcionario

a

Público y su reglamento, Reglamento de la Responsabilidad por la

cumplir

Función Pública, Normativa aplicable al ejercicio de sus funciones

Funciones específicas Registrar y revisar la documentación

Informes

derivada por los responsables de

Solicitud

unidades beneficiarias, planillas de la

reconocimiento económico

DG-FELCN,

1

Resultados

las

Fuerzas

de

de

Aprobación

de

pago

% de de

Tarea

Conjunta, Unidad Móvil de Patrullaje

30

Rural UMOPAR, Diablos Verdes FTDV, Diablos Rojos FTDR, Diablos Negros FTDN y Diablos Azules FTDA, la Fuerza de

Tarea

Conjunta:

Componente

Militar, Policial y Civil (DIGEPROCOCA) Procesar el pago y transferencia de

Planillas de pago

2 recursos de acuerdo a las planillas

20

aprobadas Actualizar la base de datos de registro

Base de Datos Actualizada

3 de acuerdo al movimiento de Altas y

10

Bajas. Controlar

4

la

documentación

de

Files completos y actualizados

respaldo de los files de los efectivos beneficiarios

del

10

Reconocimiento

Económico Controlar el Chequeo de seguridad en

5 Coordinación del Técnico de Archivo y kardex

Cheque de seguridad realizado y aprobado

5

76

Implementar

6

mecanismos

de

Instrumentos

seguridad de acuerdo a la normativa

implementados

legal

aprobados

vigente

referida

a

los

de

seguridad e

informes

5

desembolsos y pagos realizados

7

Realizar informes periódicos de la

Informes aprobados de control

evolución del traspaso y pago de

de pagos y transferencias

reconocimiento consolidando remitiendo

económico, la

la

información misma

10

y

para

su

aprobación

8

Realizar el control y seguimiento a las

Registros

contables,

balances

cuentas contables que afectan el

financieros y estados financieros.

balance general, proponiendo los

10

ajustes contables que se requieran para su depuración y su presentación de los estados financieros de la UELICN

III. Cualidades

REQUISITOS PERSONALES

Trabajo en equipo, transparencia, integridad, desarrollo personal, compromiso organizacional, orientación hacia el resultado, atención oportuna, relaciones interpersonales, disciplina, responsabilidad.

NIVEL Básico Téc. Superior Licenciatura Maestría Doctorado

PROFESIÓN



ÁREA

TIPO

Ing. Sistemas, Lic. Informáticas o afines Administración y Gerencia Publica

EXPERIENCIA

Esencial Deseable

AÑOS

TIPO

General

En la administración pública

5

Esencial

Específica

En el área de Contabilidad

3

Esencial

77

3.7

ANÁLISIS DEL DOMINIO

Descripción de actividades relacionadas con el Pago del Reconocimiento Económico, puntualizando las principales operaciones y funciones que desempeñan los actores descritas a continuación:  Registro de los datos personal de los beneficiarios nuevos de acuerdo a su file personal.  Registro de los cuentas bancarias de los beneficiarios  Registro de niveles de los usuarios  Registro de Proyectos de los usuarios  Chequeo de Seguridad, análisis de idoneidad de los beneficiarios.  Elaboración de planillas preliminares.  Elaboración de descuentos.  Elaboración de planillas consolidadas,  Generación del Archivo Plano, en base a parámetros establecidos generar el archivo plano que será remitido al Entidad Financiera.

3.8

NECESIDADES DEL SISTEMA

Posterior al estudio preliminar, se identificó demora en la elaboración de planillas, asimismo se evidencia elevados márgenes de error por el proceso manual que no proporciona la información

78

veraz, útil y oportuna. Sin embargo se considera que el mayor beneficio será observado al garantizar los dineros del Estado, evitando envío de grandes cantidades de dinero (remesas), proponiendo

el

SISTEMA

INFORMÁTICO

DE

CONTROL

Y

PAGO

DE

RECONOCIMIENTO ECONÓMICO, que mejore y garantice la administración correcta de los dineros del Estado.

3.9

IDENTIFICACIÓN DEL PRODUCTO

El software tiene el nombre de SISTEMA INFORMÁTICO DE CONTROL DE PLANILLAS DE PAGO.

3.10 ¿QUE HARÁ EL SISTEMA? El sistema desarrollado permite registrar y administrar beneficiarios, niveles y cargos, cuentas bancarias, proyectos, realizará de manera exhaustiva realizara el chequeo de seguridad, generará planillas preliminares, planillas consolidadas y archivo plano. El sistema procesará automáticamente los cálculos de pago a partir de los días trabajados, asimismo realizara los descuentos correspondientes de ley (RC-IVA 13%).

3.11 BENEFICIOS DEL SISTEMA El software propuesto garantizará la correcta administración de los recursos provenientes del TGN, proporcionando información veraz, útil y oportuna, terciando servicios con entidades financieras, quienes realizaran los pagos correspondientes a partir de abonos masivos en cuentas.

79

3.12 ANÁLISIS

Análisis del Sistema Actual

Con el fin de obtener una visión completa de cómo se ejecuta el trabajo, se consideró necesario realizar una descripción de cada uno de los procesos que se realiza en las unidades involucradas en el proceso de planillas de Pago de Reconocimiento Económico.

Comprensión del Sistema Actual

Con el fin de obtener una visión completa de cómo se ejecuta el trabajo, se consideró necesario realizar una descripción de cada uno de los procesos que se realiza en las unidades involucradas en el proceso de planillas de Pago de Reconocimiento Económico. En la actualidad los actores que intervienen en el actual sistema son los siguientes:

Figura 14: Interpretación del Sistema Actual

Encargado de planillas preliminares en la unidades reconocidas en el D.S. 0282.

SISTEMA

C

ACTUAL

J

A

E R O S

Encargado

de

consolidar

las

planillas

de

pago

de

Reconocimiento Económico.

FUENTE: Elaboración Propia

80

La técnica utilizada para recopilar la información acerca del funcionamiento actual fue la entrevista directa a los enlaces de las Direcciones y Fuerzas reconocidas en el D.S. 0282; el responsable de consolidar la información en la “U.E.L.I.C.N.” y los cajeros de la cancelación a nivel nacional, siendo estos actores los principales fuentes información cualitativa y cuantitativa.

A continuación se detalla el funcionamiento del sistema actual de acuerdo a las entrevistas realizadas.

Tabla 6: Actor - Enlace de Planillas ACTOR: ENLACES DE PLANILLAS PRELIMINARES

Descripción: Es el encargado de controlar todo el movimiento relacionado con el Pago de Reconocimiento Económico en la Dirección y/o Fuerza Reconocida en el D.S. 0282. Realiza las altas, bajas y movimientos del personal de su Dirección y/o Fuerza. Realiza las altas de cuentas, proyectos, y niveles y cargos. Realiza los descuentos correspondientes. Proporciona la información a sus inmediatos superiores y a todos los beneficiarios de su Dirección y/o Fuerza. Remite con las firmas correspondientes las planillas preliminares a la “U.E.L.I.C.N.”.

TODAS LAS TAREAS DESCRITAS SON REALIZADAS MANUALMENTE CON LA AYUDA DE LA HOJA ELECTRÓNICA EXCEL. ACTOR: ENCARGADO DE PLANILLAS PRELIMINARES (9 ENCARGADOS A NIVEL NACIONAL) Fuente: Elaboración Propia

81

Tabla 7: Actor - Responsable de Planillas ACTOR: RESPONSABLE DE CONSOLIDAR LAS PLANILLAS DE PAGO DE RECONOCIMIENTO ECONÓMICO

Descripción: Es el responsable de controlar las planillas preliminares y validar las mismas. 

Coordina y supervisa el trabajo de los encargados en las 9 unidades beneficiarias verificando los la documentación respaldatoria.



Verifica la idoneidad del personal considerado como alta.



Consolida y procesa las planillas mensuales de R.E.



Remite las planillas de R.E. a la unidad contable, para el proceso de comprobantes de egreso y correspondientes cheques.



Remite las planillas de R.E. a los cajeros a nivel nacional para el pago correspondiente

TODAS LAS TAREAS DESCRITAS SON REALIZADAS MANUALMENTE CON LA AYUDA DE LA HOJA ELECTRÓNICA EXCEL. ACTOR: RESPONSABLE DE CONSOLIDAR PLANILLAS (U.E.L.I.C.N.)

Fuente: Elaboración Propia

82

Análisis del Nuevo Sistema

Figura 15: Censo de Módulos - Nuevo Sistema uc Actors

AUTENTIFICACION DE USUARIO

REGISTRO Y ADMINISTRACION DE BENEFICIARIOS

REGISTRO DE CUENTAS BANCARIAS «include»

«include» REGISTRO DE NIVELES Y CARGOS VERIFICACION DE INFORMACION

«include»

RESPONSABLE_UELICN

«include» REGISTRO DE PROYECTOS «include» «include»

ENLACE ELABORACION DE PLANILLAS PRELIMINARES

CONTROL DE DESCUENTOS

«include» GENERACION PLANILLA CONSOLIDADA

«include»

«include»

«EXTENDED»

«include»

GENERACION REPORTES

GENERACION DE REPORTES

CHEQUEO DE SEGURIDAD CHEQUEO DE SEGURIDAD_UELICN

«include»

GENERACION DE REPORTES

FUENTE: Elaboración Propia

«include»

«include»

GENERACION ARCHIVO PLANO

83

Definición de Actores

Tabla 8: Enlace en la Unidad Reconocida en el D.S. 0282 ACTOR: ENLACE EN LA UNIDAD RECONOCIDA EN EL D.S. 0282

Descripción: Enlace Encargado de Registrar y Administrar movimientos de los beneficiarios, 

Registra altas, bajas y movimientos de beneficiarios



Registra números cuentas



Registra niveles y cargos



Registra proyectos



Procesa planillas preliminares de pago del R.E



Procesa descuentos



Remite las planillas de R.E. preliminares a la “U.E.L.I.C.N.” Actor: Encargado de Planillas Preliminares (9 Encargados a Nivel Nacional)

Tabla 9: Archivo y Kardex - "U.E.L.I.N.C." ACTOR: ARCHIVO Y KARDEX “U.E.L.I.C.N.”

Descripción: Encargado de controlar la idoneidad de los beneficiarios del R.E 

Controla la documentación de todos beneficiarios del R.E.



Realiza el Chequeo de seguridad, controlando la idoneidad de los beneficiarios del R.E. (revisa antecedentes policiales,



Coadyuva con el Responsable “U.E.L.I.C.N.” ACTOR: Encargado de Archivo y Kardex

84

Tabla 10: Responsable "U.E.L.I.C.N." ACTOR: RESPONSABLE “U.E.L.I.C.N.”

Descripción: Responsable de supervisar y procesar las planillas de pago del R.E 

Verifica y supervisa toda la información generada por los encargados en las 9 unidades beneficiarias del R.E.



Verifica y supervisa toda la información generada en el chequeo de seguridad



Consolida y procesa las planillas mensuales de R.E.



Genera archivo plano e interactúa con las entidades bancarias para realizar los abonos de pago correspondientes ACTOR: Responsable de elaboración de planillas en la “U.E.L.I.C.N.” Fuente: Elaboración Propia

Descripciones y Funcionalidades

Tabla 11: Autentificación de Usuario Nombre de Evento: “Autentificación del Usuario” Actores: Enlace Unidades; Archivo y Kardex “U.E.L.I.C.N.” y Responsable “U.E.L.I.C.N.”. Flujo de Eventos Eventos del Actor

Eventos del Sistema

1. Los actores ingresan su nombre de usuario y logín.

3. El sistema muestra la interfaz gráfica correspondiente.

2. Los usuarios autenticados realizan las opciones que el sistema le muestra y le permite Precondiciones: Los usuario deben estar registrados Postcondición: El usuario es reconocido por la aplicación Descripción autentificación de usuario

85

Fuente: Elaboración Propia

Tabla 12: Registro y Administración de Beneficiarios Nombre de Evento: “Registro y Administración de Beneficiarios” Actor: Enlace de Unidad Flujo de Eventos Eventos del Actor

Eventos del Sistema

1. El enlace de la unidad, registra

altas,

modificaciones,

bajas de

y los

beneficiarios.

2. El

sistema valida

y administra la

información introducida 3. El

sistema

consolida

los

cambios

realizados. 4. El sistema muestra la interfaz gráfica correspondiente.

Precondiciones: La información documental Descripción de caso de uso “Registro y Administración de Beneficiarios” Fuente: Elaboración Propia

Tabla 13: Registro de Cuenta Bancaria Nombre de Evento: “Registro de Cuenta Bancaria” Actor: Enlace de Unidad Flujo de Eventos Eventos del Actor

Eventos del Sistema

1. El enlace de la unidad, registra la cuenta bancaria del beneficiario.

2. El

sistema

valida

y administra

la

información introducida 3. El

sistema

consolida

los

cambios

realizados. 4. El sistema muestra la interfaz gráfica correspondiente. Precondiciones: Existencia de beneficiario, información documental Descripción de caso de uso “Registro de Cuenta Bancaria” Fuente: Elaboración Propia

86

Tabla 14: Registro de Nivel y Cargo Nombre de Evento: “Registro de Nivel y Cargo” Actor: Enlace de Unidad Flujo de Eventos Eventos del Actor

Eventos del Sistema

1. El enlace de la unidad, registra el nivel y cargo del beneficiario.

2. El

sistema valida

y administra la

información introducida 3. El

sistema

consolida

los

cambios

realizados. Precondiciones: Existencia de beneficiario, información documental Descripción de caso de uso “Registro de Nivel y Cargo” Fuente: Elaboración Propia

Tabla 15: Registro de Proyecto Nombre de Evento: “Registro de Proyecto” Actor: Enlace de Unidad Flujo de Eventos Eventos del Actor

Eventos del Sistema

1. El enlace de la unidad, registra el proyecto al cual pertenece el beneficiario.

2. El

sistema valida

y administra la

información introducida 3. El

sistema

consolida

realizados. Precondiciones: Existencia de beneficiario, información documental Descripción de caso de uso “Registro de Proyecto” Fuente: Elaboración Propia

los

cambios

87

Tabla 16: Elaboración de Planilla Preliminar Nombre Evento: “Elaboración de Planillas Preliminares” Actor: Responsable “U.E.L.I.C.N.” Flujo de Eventos Eventos del Actor

Eventos del Sistema

1. El enlace genera la planilla preliminar.

3. El

sistema

realiza

los

cálculos

correspondientes por 30 días pagados

2. El enlace establece periodo de pago.

descontando el correspondiente 13% (IVA) per cápita. 4. El sistema consolida los cambios

Precondiciones: Chequeo de Seguridad y el beneficiario tendrá condición de “vigente”. Descripción de caso de uso Elaboración de Planillas Preliminares Fuente: Elaboración Propia

Tabla 17: Elaboración de Planilla Preliminar Nombre de Evento: “Registro de Descuentos” Actor: Enlace de Unidad Flujo de Eventos Eventos del Actor

Eventos del Sistema

1. El Enlace, elige la opción

4. El sistema muestra la interfaz gráfica que

buscar, con el fin de

le

identificar al beneficiario

pertinentes.

al que será sujeto a los

permite

realizar

los

5. El sistema almacena los cambios.

descuentos. 2. El enlace, realizará los descuentos del mes. 3. El

enlace,

descuentos

guardará

cambios. Precondiciones: Planilla Preliminar Descripción de caso de uso Registro de Descuentos – Fuente Propia

88

Tabla 18: Generación de Reportes Nombre de Evento: “Generación de reportes” Actor: Enlace de Unidad Flujo de Eventos Eventos del Actor 1. Los

Eventos del Sistema

actores eligen las

2. El sistema muestra la interfaz gráfica que

opciones correspondientes

les permite procesar reportes.

para generar reportes. Precondiciones: información almacenada Descripción de caso de uso Generación de reportes Fuente: Propia

Tabla 19: Chequeo de Seguridad Nombre de Evento: “Chequeo de Seguridad” Actor: Archivo y Kardex “U.E.L.I.C.N.” Flujo de Eventos Eventos del Actor

Eventos del Sistema

1. El responsable de Archivo y

2. El sistema muestra la interfaz gráfica que

Kardex de la “U.E.L.I.C.N.”

le

procede

correspondientes.

a

validar

los

permite

validar

los

requisitos establecidos en el Reglamento de Pago de Reconocimiento Económico Precondiciones: El beneficiario tiene que estar dentro la base de datos. Descripción de caso de uso Chequeo de Seguridad Fuente: Propia

requisitos

89

Tabla 20: Verificación de al Información Nombre de Evento: “Verificación de Información” Actor: Responsable “U.E.L.I.C.N.” Flujo de Eventos Eventos del Actor 1. El

responsable

Eventos del Sistema de

la

3. El sistema muestra la interfaz gráfica que

“U.E.L.I.C.N.”, procede a

le

verificar toda la información

información

previa que realizó el enlace y

permite

dar

consistencia

a

4. El sistema almacena los cambios.

Archivo y Kardex de la “U.E.L.I.C.N.” de manera continua. 2. Ante

cualquier

inconsistencia

de

la

información el responsable tiene

los

correspondientes realizar

las

privilegios para enmiendas

correspondientes Precondiciones: El Beneficiario estará en condición de vigente en la base de datos Descripción de caso de uso Verificación de Información Fuente: Propia

la

90

Tabla 21: Generación de Planilla Consolidadas Nombre del caso de uso: “Generación de Planillas Consolidadas ” Actor: Responsable “U.E.L.I.C.N.” Flujo de Eventos Eventos del Actor 1. El

Eventos del Sistema

responsable

de

la

“U.E.L.I.C.N.” realizará la consistencia

de

la

información de la planilla

4. El

sistema

realiza

5. El

sistema

establece

realizados.

descuentos procesados por el enlace de la unidad. 2. Ante cualquier eventualidad observada en las planillas preliminares, el responsable podrá realizar los ajustes

privilegios

teniendo para

los este

cometido. 3. Ajustadas

las

planillas

preliminares y descuentos, el responsable

generará

cálculos

los

cambios

correspondientes.

preliminar y los respectivos

pertinentes,

los

las

planillas consolidadas. Precondiciones: Planilla Preliminar Descripción de caso de uso Generación de Planilla Consolidada Fuente: Elaboración Propia

91

Tabla 22: Generación del Archivo Plano Nombre de Evento: “Generación del Archivo Plano” Actor: Responsable “U.E.L.I.C.N.” Flujo de Eventos Eventos del Actor 1. El

responsable

“U.E.L.I.C.N.”, opción

Generar

Eventos del Sistema de

la

3. El sistema muestra la interfaz gráfica que

elige

la

le permite generar el archivo plano.

Archivo

Plano. 2. El responsable genera los reportes finales. Precondiciones: Planilla Consolidada Descripción de caso de uso Generación del Archivo Plano” Fuente: Propia

3.13 REPRESENTACION DE ACTIVIDADES

Para resolver el problema y construir una solución se aplica la estrategia de alto nivel, el cual nos permite generar las actividades del sistema, los cuales funcionaran como base para el desarrollo del sistema.

El sistema a desarrollarse tendrá los módulos de registro de beneficiarios, registro de niveles y cargos, registro de cuentas, registro de proyectos, chequeo de seguridad, generación de planillas.

Según Elizondo 2005, las actividades al ser en esencia detalle de flujos, con algunos elementos adicionales, permiten expresar conceptos como la concurrencia y división de trabajo

Las actividades proporcionan información en relación a como se ejecuta el trabajo, facilitando una descripción detallada de cada uno de los actos que se realizan para el control y proceso de pago de las planillas de Pago de Reconocimiento Económico.

92

ESQUEMA DE ACTIVIDADES Figura 16: Esquema Actividades act Diagrama de Activ idades ENLACE

RESPONSABLE UELICN

ARCHIVO Y KARDEX

ActivityInitial ActivityInitial

ActivityInitial

ACCEDER AL SISTEMA

AUTENTIFICACIÓN

CARGAR INTERFAZ ENLACE

REGISTRO Y ADMINISTRACION DE BENEFICIARIOS

CARGAR INTERFAZ DE RESPONSABLE

CARGAR INTERFAZ CHEQUEO DE SEGURIDAD

VERIFICAR DOCUMENTACION

VALIDACION DE INFORMACIÓN

VERIFICAR PLANILLAS PRELIMINARES CONSOLIDAR INFORMACION

CONSOLIDAR INFORMACIÓN

ActivityFinal

ActivityFinal

GENERAR PLANILLA FINAL

GENERAR ARCHIVO PLANO

ActivityFinal

ActivityFinal

FINAL

FUENTE: Elaboración Propia

Actividad - Autentificación de Usuario

93

Figura 17: Actividad – Autentificación de Usuario act AUTENTIFICACION DE USUARIO USUARIO

SISRECECO

Inicio de Actividad

Solicitar Ingreso a SISRECECO

Abrir SISRECECO

Autentificar Usuario

Introducir Usuario

Introducir Passw ord

Continuación de Flujo

Validar Usuario

[False]

[True] Ingresar a Modulo(Enlace, Chequeo o Responsable)

Final de Actividad

FUENTE: Elaboración Propia

94

Actividad - Registro de Cuenta Bancaria Figura 18: Actividad – Registro de Cuenta Bancaria act Registro de Cuenta Bancaria ENLACE

SISRECECO

Inicio de Actividad

Autentificar en SISRECECO

Ingresar al Módulo Enlace

Ingresar al Módulo Buscar

Solicitar Datos de Beneficiario

Solicitar Registro de Cuenta

[True]

Definir Nuev o Registro de Cuenta Bancaria

Verificar Existencia

Ir al Módulo Cuenta Bancaria

Crear Nuev a Cuenta Bancaria

En el Campo Cedula de Identidad - CTRL+V

Final de Actividad

Llenar datos requeridos por SISRECECO

FUENTE: Elaboración Propia

[False]

Mensaj e "No existe el Beneficiario Solicitado"

95

Actividad - Registro y Administración de Beneficiarios Figura 19: Actividad – Registro y Administración de Beneficiario act Registro y Administracion de Beneficiarios SISRECECO

ENLACE Inicio de Actividad

Solicitar Alta de Beneficiario

Autentificar en SISRECECO

Verificar Unicidad Ingresar a Módulo ENLACE

[False]

Mensaj e "Debe Existir un Unico Benenficiario"

[False]

Mensaj e "No existe el Beneficiario Solicitado"

[T rue] Registro de Benenficiario

Establecer Alta

Final de Flujo

Modificación de Datos Beneficiario

Buscar Beneficiario

Verificar Existencia

[T rue] Modificación de Campos

Final de Flujo

Eliminación Física de Beneficiario

Buscar Benenficiario

Verificar Existencia

[T rue] Eliminacion Física

Final de Flujo

FUENTE: Elaboración Propia

[False]

Mensaj e "Beneficiario no Encontrado"

96

Actividad - Registro de Niveles y Cargos Figura 20: Actividad – Registro de Niveles y Cargos act Activ idad Registro de Niv eles y Cargos ENLACE

SISRECECO

Inicio de Actividad

Autentificar en SISRECECO

Ingresar al Modulo Enlace

Ingresar Módulo Buscar

Solicitar Registro de Cuenta

Definir Nuev o Registro de Niv el y Cargo

Solicitar Datos del Beneficiario

[True]

Verificar Existencia

[False]

Ir al Módulo Niv el y Cargo

Crear Nuev o Niv el y Cargo

En el Campo Cédula de Identidad - CTRL + V

Final de Actividad

Llenar datos requeridos por SISRECECO

FUENTE: Elaboración Propia

Mensaj e "No Existe Beneficiario Solicitado"

97

Actividad - Registro de Proyectos Figura 21: Actividad – Registro de Proyectos act Activ idad Registro de Proyecto SISRECECO

ENLACE Inicio de Actividad

Autentificar en SISRECECO

Ingresar al Módulo Enlace

Ingresar al Modulo Buscar

Solicitar Registro de Proyecto

Definir Nuev o Proyecto

Solicitar Datos de Benenficiario

[True]

Verificar Existencia

Ir al Módulo Proyecto

Crear Nuev o Proyecto

En el Campo Cédula de Identidad - CTRL + V

Final de Actividad

Llenar datos requeridos por SISRECECO

FUENTE: Elaboración Propia

[False]

Mensaj e "No existe Beneficiario Solicitado"

98

Actividad - Elaboración de Planilla Preliminar Figura 22: Actividad – Elaboración de Planilla Preliminar act Activ idad Elaboracion de Planillas Preliminares SISRECECO

ENLACE Inicio de Actividad

Autentificar en SISRECECO

Ingresar al Módulo Enlace

Ingresar al Módulo Genera Planilla Preliminar

Elaborar Planilla

Crear Nuev a Planilla

Validar datos requeridos por SISRECECO

Verificar datos de Planilla Preliminar

Generar Planilla

Final de Actividad

FUENTE: Elaboración Propia

Mensaj e "El periodo de Pago Requerido ya fue Procesado"

99

Actividad – Registro de Descuentos Figura 23: Actividad – Registro de Descuentos act Activ idad Control de Descuentos ENLACE

SISRECECO

Inicio de Actividad

Autentificar en SISRECECO

Ingresar al Módulo Enlace

Solicitar Periodo de Descuento

Ingresar a Módulo Filtro de Descuento

Detallar Mes de Pago

Activ ar Trigger Descuentos (Enter)

Solicitar Beneficiario para Descuentos Ingresar a Módulo Buscar Beneficiario

Introducir Datos de Beneficiario

Verificar Existencia

[False]

[True] Activ ar Trigger Descuentos (Enter)

Procesar Descuentos

Activ ar Trigger Nuev o Descuento

Final de Actividad

LLenar datos requeridos por SISRECECO

FUENTE: Elaboración Propia

Mensaj e "No Existe Benenficiario Requerido"

100

Actividad - Elaboración de Planilla Preliminar Figura 24: Actividad – Elaboración Planilla Preliminar act Activ idad Chequeo de Seguridad ENLACE

SISRECECO

Inicio de Actividad

Autentifica ren SISRECECO

Ingresar a Módulo CHEQUEO

Buscar Benenficiario

Verificar Existencia

[True]

Requerir Chequeo de Seguridad

Completar datos de Chequeo solicitado por SISRECECO

Final de Actividad

FUENTE: Elaboración Propia

[False]

Mensaj e "No hay registros que coincidan con estos criterios de busqueda"

101

3.14 DIAGRAMAS DE CLASE

Cada clase será definida mediante un fichero de cabecera propio y otro fichero con la definición de sus métodos.

El siguiente diagrama de clases contiene la información suficiente para realizar el desarrollo. Figura 25: Diagrama de Clase class CLASES SISRECECO

CHEQUEO

CUENTA

NIVEL + + +

cargo: Char nivel: Integer rec_eco: Decimal

+ + +

actualizar_nivel(integer) : void agregar_nivel(integer) : void eliminar_nivel(integer) : void

-

ci: int cuenta: int

+ +

actualizar() : int agregar_cuenta(integer) : void 1

+ + + + + + +

ci: Integer cta_ban: Char felcc: Char felcn: Char fot_pos: Char rejap: Char tribunal: Char

+ + +

actualizar_ci(integer) : void agregar_ci(integer) : void eliminar_ci(integer) : void

*

1 1

1 BENEFICIARIO

PROYECTO + + + + + +

cod_pro: Char cupo: Integer proyecto: Char

1

+ 1 + + + + + +

cargo: Integer ci: Integer cod_pro: Char fec_nac: Date grado: Char nivel: Integer nombre_completo: Char

+ + 1 +

actualizar_ci(integer) : void agregar_ci(integer) : void eliminar_ci(integer) : void

1

PLANILLA *

actualizar cod_uni(integer) : void agregar cod_uni(integer) : void eliminar cod_uni(integer) : void

FUENTE: Elaboración Propia

+ + + + + + + +

cargo: Char ci: Integer codigo: Integer iva: Decimal liq_pag: Decimal nivel: Integer observ: String proyecto: Char rec_eco: Decimal tot_gan: Decimal

+ + +

actualizar_planilla(integer) : void eliminar_ planilla(integer) : void generar_planilla(integer) : void

102

3.15 SECUENCIA DE SISTEMA

Cada clase será definida mediante un fichero de cabecera propio y otro fichero con la definición de sus métodos Figura 26: Secuencia General de Sistema sd Control

ENLACE

MODULO ENLACE (interfaz) INGRESA AL MODULO()

ARCHIVO Y KARDEX UELICN (CHEQUEO)

MODULO CHEQUEO (interfaz)

RESPONSABLE UELICN

MODULO RESPONSABLE (interfaz)

ALTAS, BAJAS, MODIFICACIONES, VALIDACIONES()

INGRESA AL MODULO() CHEQUEO DE SEGURIDAD()

INGRESA AL MODULO()

VERIFICAR, VALIDAR, CONTROLAR, GENERAR()

GENERA REPORTES()

GENERA REPORTES() INFORMACION VALIDAD (RETROALIMENTACION)

GENERA REPORTES()

(from Actors)

INFORMACION VALIDADA (RETROALIMENTACION)

FUENTE: Elaboración Propia

103

Figura 27: Secuencia de Sistema - Enlace sd Enlace MODULO ENLACE (interfaz) ENLACE

MODULO BUSQUEDA (interfaz)

MODULO DE CUENTA (interfaz)

MODULO NIVEL (interfaz)

MODULO PROYECTO (interfaz)

GENERADOR DE PLANILLA PRELIMINAR (interfaz)

PROCESO DE DESCUENTOS (interfaz)

GENERACION DE REPORTES

INGRESAR AL MODULO()

BUSQUEDA DE BENEFICIAIRO()

BENEFICIARIO ENCONTRADO()

IR AL REGISTRO RELACIONADO()

IR AL REGISTRO RELACIONADO()

IR AL REGISTRO RELACIONADO()

INFORMACION PROCESADA()

GENERAR PLANILLA PRELIMINAR()

PROCESAR DESCUENTOS()

IMPRESION DE REPORTES()

CERRAR()

FUENTE: Elaboración Propia

104

Figura 28: Secuencia de Sistema - Chequeo sd Chequeo

ARCHIVO Y KARDEX UELICN

MODULO BUSQUEDA

MODULO CHEQUEO (interfaz)

REALIZAR BUSQUEDA()

IR A REGISTRO RELACIONADO()

COMPLETAR INFORMACION VALIDADA()

GENERAL REPORTES ()

INFORMACION VALIDADA RETROALIMENTACION()

(from Actors)

FUENTE: Elaboración Propia

105

Figura 29: Secuencia de Sistema - Responsable sd RESPONSABLE

RESPONSABLE

MODULO RESPONSABLE (interfaz)

MODULO ENLACE

MODULO CHEQUEO

MODULO CONSOLIDACION DE PLANILLAS

INGRESA AL MODULO()

SUPERVISA A ENLACE()

CONSISTENCIA DE INFORMACION()

SUPERVISA CHEQUEO()

CONSISTENCIA DE INFORMACION()

CONSOLIDA PLANILLA DE PAGO()

PLANILLAS DEPURADAS()

GENERACION DE ARCHIVO PLANO - ENTIDAD BANCARIA()

CERRAR()

FUENTE: Elaboración Propia

GENERACION DE ARCHIVO PLANO

106

3.16 ANÁLISIS Y DISEÑO

Figura 30: Modelo Relacional

FUENTE: Elaboración Propia

107

3.17 INTERFAZ GRAFICA DEL USUARIO

Figura 31: Ventana de Control de Accesos al Sistema

Figura 32: Ventana Menú Principal

108

Figura 33: Ventana Enlace - Registro de Beneficiarios

Figura 34: Ventana de Registro de Cuentas, Niveles y Proyectos

109

Figura 35: Ventana de Chequeo de Seguridad

Figura 36: Ventana de Registro de Descuentos

110

4.CALIDAD DE SOFTWARE

111 4.1

INTRODUCCIÓN

La medición de la calidad de software se realiza a través de métricas de control de calidad, para medir aspectos del software como ser: Funcionalidad, Instalación Mantenibilidad y su portabilidad, los cuales se detalla a continuación

FACTORES DE CALIDAD ISO 9126

Normas de gestión ISO 17799. - La norma NB-ISO/IEC 17799 define la seguridad de la información como la preservación de:  Confidencialidad - Solo quienes estén autorizados pueden acceder a la información.  Integridad.- La información y sus métodos de proceso son exactos y completos.  Disponibilidad.- Los usuarios autorizados tienen acceso a la información y a sus activos asociados cuando lo requieran.

Entre los aspectos fundamentales de la calidad de las aplicaciones Web destacamos:  La medición y evaluación del producto software  El control del proceso de desarrollo

Entre los estándares y modelos de evaluación y mejora de los procesos software que están relacionados con la calidad, en cualquiera de los términos analizados. Tenemos a ISO 9001

El estándar ISO 9126 ha sido desarrollado en un intento de identificar los atributos clave de calidad para el software. El estándar identifica seis atributos clave de calidad:

112 i.

Funcionalidad. El grado en que el software satisface las necesidades indicadas por los siguientes sub-atributos: idoneidad, corrección, interoperabilidad, conformidad y seguridad

ii.

Confiabilidad. Cantidad de tiempo que el software está disponible para su uso. Esta referido por los siguientes sub-atributos: madurez, tolerancia a fallos y facilidad de recuperación.

iii.

Usabilidad. Grado en que el software es fácil de usar. Viene reflejado por los siguientes atributos: facilidad de comprensión, facilidad de aprendizaje y operatividad.

iv.

Eficiencia. Grado en que el software hace óptimo el uso de los recursos del sistema. Esta indicado por los siguientes sub atributos: tiempo de uso y recursos utilizados.

v.

Facilidad de mantenimiento. La facilidad con que una modificación puede ser realizada. Está indicada por los siguientes sub atributos: facilidad de análisis, facilidad de cambio, estabilidad y facilidad de prueba.

vi.

Portabilidad. La facilidad con que el software puede ser llevado de un entorno a otro. Esta referido por los siguientes sub atributos: facilidad de instalación, facilidad de ajuste, facilidad de adaptación al cambio

Los factores ISO 9126 no necesariamente son utilizados para medidas directas. En cualquier caso, facilitan una valiosa base para medidas indirectas y una excelente lista para determinar la calidad de un sistema

FACTORES DE CALIDAD ISO 9001 ISO 9001 — Calidad.- Es un modelo para conseguir la calidad total en el diseño, desarrollo, producción, instalación y servicio post-venta.

113 4.2

CONFIABILIDAD

La confiabilidad del sistema es directamente proporcional a la calidad de sus componentes

Dónde: R(t)

= Función de confiabilidad de un componente en el tiempo t

s

= Tasa constante de fallo

T

= Periodo de operación de tiempo

Teorema 1. Si n componentes, funcionan independientemente conectados en serie y el iesimo componente tiene confiabilidad Rj(T), entonces la confiabilidad total está dada por.

R(t)= R1(t)*R2(t)*R3(t)... . Rn(t)

Teorema 2. Si n componente, funcionan independientemente y actúan en paralelo y el i- esimo componente tiene confiabilidad Rj(t), entonces la confiabilidad total está dada por.

R(t)= 1-[1- R1(t)]* [1- R2(t)]* [1- R3(t)]*.......* [1- Rn(t)]

De donde se tiene el siguiente diagrama de transferencia.

114 Figura 37: Diagrama de Transferencia

CHEQUEO DE SEGURIDAD

R3

GENERACIÓN DE PLANILLAS

R4

ALTA DE BENEFICIARIOS

R1

CONSOLIDACIÓN DE PLANILLAS

ALTAS DE NIVEL, PROYECTO Y CUENTAS

R5

R2

REPORTES

R7

GENERACION DE ARCHIVO PLANO

R6 Fuente: [Elaboración Propia]

Luego obtenemos la siguiente salida tabla Tabla 23: Factores de Salida

Rj ()

-s * t

T(semanas)

s

e

R1 ( )

0,01

10

0,9990

R2 ( )

0,005

10

0,9995

R3 ( )

0,01

10

0,9990

R4 ( )

0,01

10

0,9990

R5 ( )

0,01

10

0,9990

R6 ( )

0,01

10

0,9990

R7 ( )

0,01

10

0,9990

Fuente: Elaboración Propia

115 Utilizando los teoremas 1 y 2 calculamos

R(t)= [{1-[1- 0,99(t)]* [1- 0,99(t)]* [1- 0,99(t)]} * 0,99*0,99*0,99] R(t)= 0,97

Confiabilidad = R(t) * 100 = 97%

4.3

FACILIDAD DE USO

Las métricas de usabilidad son:  Entendibilidad  Aprendibilidad  Operatividad  Atractivo  Conformidad de la Usabilidad

Tabla 24: Valores de Facilidad de Uso (Porcentajes) USUARIOS

FACILIDAD

DE FACILIDAD

DE FACILIDAD

COMPRENSIÓN

APRENDIZAJE

OPERACIÓN

Enlace 1

99%

98%

98%

Enlace 2

98%

98%

97%

Enlace 3

97%

97%

97%

Chequeo

99%

99%

98%

Responsable

99%

99%

99%

PROMEDIO

98,4%

98.2%

97.8%

Fuente: Elaboración Propia

DE

116 Por tanto, de acuerdo a los resultados obtenidos, se puede apreciar que se tuvo una facilidad de uso del sistema de 98% 4.4

FUNCIONALIDAD

La funcionalidad de un sistema se mide según la complejidad del mismo, cuanto más complejo sea un sistema, es mejor funcional y viceversa. Estas consideraciones se toman desde el punto de vista del usuario.

La funcionalidad de un sistema no puede ser medido directamente, entonces corresponde derivar, mediante otras medidas como el Punto Función, para esto se tiene la siguiente relación PF = Cuenta_Total x [0,65 + 0, 01 x ∑(Fi)]

PARÁMETROS DE MEDICIÓN ENTRADAS DE USUARIO SALIDAS

DE

USUARIO PETICIONES DE USUARIO NUMERO

DE

ARCHIVOS NUMERO INTERFACES

DE

Tabla 25: Cálculo de Puntos de Función CUENTA FACTOR DE PESO TOTAL SIMPLE MEDIO COMPLEJO 11

3

4

6

44

5

4

5

7

25

11

3

4

6

66

11

7

10

15

77

4

5

7

10

28

TOTAL

240 Fuente: Elaboración Propia

∑(Fi) puede ser de 1 — 14 los valores de ajuste de la complejidad según las respuestas a las siguientes preguntas.

117

Esencial

Significativo

Medio

Moderado

Prudente

Sin

ESCALA

importancia

Tabla 26: Valores de Ajuste

Requiere el sistema copias de seguridad y de recuperación fiables

√

Se requiere comunicación de datos

√

Existen funciones de procesamiento √

distribuido Es crítico el rendimiento

√ Se ejecutará el sistema en un entorno operativo

existente

y

fuertemente √

utilizado Requiere el sistema entrada de datos

√

interactiva Requiere la entrada de datos interactiva que las transacciones

de entrada se

lleven a cabo sobre múltiples pantallas u √

operaciones Se actualizan los archivos maestros de √

forma interactiva Son complejas las entradas, las salidas, los archivos o las peticiones Es complejo el procesamiento interno

√ √

Se ha diseñado el código para ser reutilizable

√

118 Están

incluidas

en

el

diseño

la √

conversión y la instalación’ Se ha

diseñado

el

sistema

para

soportar múltiples instalaciones en √

diferentes organizaciones Se ha diseñado la aplicación para facilitar

los

cambios

y

para

ser

fácilmente utilizada por el usuario

√

FUENTE: ELABORACIÓN PROPIA

Cada una de las preguntas anteriores es respondida usando una escala con rangos desde 0 (no importante o aplicable) hasta 5 (absolutamente esencial). ∑(Fi) = 1=5;2=5;3=4;4=3;5=5;6=4;7=4;8=5;9=3;10=4;11=3;12=3;13=3;14=5 ∑(Fi) = 5+5+4+3+5+4+4+5+3+4+3+3+3+5 = 56

Por tanto PF = Cuenta_Total x [0,65 + 0, 01 x ∑(Fi)] PF = 240 x [0,65 + 0, 01 x 56] PF = 290.40 Si consideramos el máximo valor de ajuste de complejidad como ∑(Fi), se tiene

PF = 240 x [0,65 + 0, 01 x 70] PF = 324 De donde se ∑(Fi) es considerada el 100%, la relación obtenida ente los puntos será:

PF = 290.40/324 = 0.90 PF = 90% Estableciendo finalmente una funcionalidad del sistema en 90% a partir del punto fusión máximo.

119 4.5

CALIDAD WEB

La calidad web se incorpora en una aplicación web como consecuencia de un buen diseño. El sistema fue evaluado aplicando una serie de revisiones técnicas que valoran elementos del modelo de diseño, conjuntamente procesos de prueba de acuerdo al siguiente contexto:

Contenido, fue evaluado desde el punto de vista sintáctico y semántico; valorando el primero, desde la aplicación del vocabulario utilizado, puntuación y gramática para los documentos que están basados en textos, la valoración semántica fue realizada paralela a la corrección de errores, a partir de las pruebas de consistencia minimizando ambigüedades, pretendiendo en todo momento que la información almacenada sea precisa, concisa, puntual.

Función, se realizaron pruebas a fin de dar conformidad a los requerimientos de los clientes/usuarios, minimizando la inestabilidad del sistema.

Estructura, valoración que fue utilizada a fin de garantizar que el sistema entrega adecuadamente el contenido y la función de la aplicación, precautelando de que sea escalable y adaptable a cambios.

Usabilidad, se realizaron pruebas a fin de que la interfaz permita al usuario aprender y asimilar el funcionamiento del sistema en todo su contexto. La prueba de interfaz siguió reglas de diseño, estática y contenido visual, cuidando características que incluyen tipo de fuente, uso de color, marcos, imágenes, bordes, tablas, etc. Fueron probados los menús, ventanas pop-up,

Navegabilidad, se realizaron pruebas a efecto de asegurar que toda la semántica de navegación se ejecuta correctamente eliminando errores de navegación buscando vínculos muertos, inadecuados y erróneos.

Rendimiento, las pruebas fueron realizadas a en condiciones prácticas y operativas, elevando las cargas a fin de que el sistema responda a las carga extrema sin degradación operativa.

120 Prueba de carga Fueron realizadas estas pruebas a fin de determinar como responderá el sistema y su entorno a diversas condiciones de carga para lo cual fueron utilizadas las siguientes variables;

N: número de usuarios concurrentes

T: número de transacciones en línea por unidad de tiempo

D, carga de datos procesados por el servidor en casa transacción

Determinando de esta manera el rendimiento global P:

P

=

[N x T x D] / 60

En el caso de que el sistema tenga conectado al doble de los 9 enlaces de las Direcciones y Fuerzas reconocidas en el D.S. 0282 se tendría al valor N=18

Si las transacciones fuera solicitadas una vez cada 2 minutos se tendría T= 0,5

En una situación optimista que cada transacción signifique 3Kb de longitud se tendría El siguiente rendimiento global

P

=

[18 x 0,5 x 3] / 60

=

0.43 Kbytes/s

Concluyendo que en un servicio de internet con bajada de 4.81 Mbytes y subida de 0.80 Mbytes de subida; el rendimiento será el más óptimo. Compatibilidad, se realizaron pruebas con distintas configuraciones asegurando su funcionamiento en distintas plataformas como Windows XP, Windows Seven e inclusive Windows Ocho, tanto en el anfitrión, cliente y servidor, asimismo se realizaron evaluación con navegadores con Firefox, Safari, Chrome.

121 Interoperabilidad, las pruebas que se llevaron a cabo garantizar que la Webapp tiene la interfaz adecuada en relación a otras aplicaciones.

Seguridad, el sistema cumple todos los objetivos de la moderna criptografía al evidenciar los siguientes acápites:  Confidencialidad: Sólo personal autorizado puede acceder a la lectura de datos o mensajes u obtener información sobre sus contenidos.  Protección contra el cambio: El destinatario de los datos o del mensaje puede verificar si éstos han cambiado desde que fueron generados.  Protección contra falsificaciones: Los remitentes del mensaje o sus editores serán claramente identificables.  Naturaleza vinculante: El editor del mensaje o remitente no podrán negar la autoría de dichos datos o mensaje.

4.6

WEBDIRECT

FileMaker Pro V13, combina la potencia de una aplicación de escritorio con la simplicidad de un navegador web gestionando y compartiendo información, esta herramienta innovadora ejecuta soluciones personalizadas de negocio directamente en un navegador web desde su ordenador de sobremesa o portátil. FileMaker WebDirect parece y se comporta como una aplicación de escritorio, lo que le aportó funcionalidades importantes en el SISRECECO como las expuestas a continuación:  Interacción al estilo de escritorio, fueron utilizados, los temas, estilos, tablas, menús, y mucho más. Permitiendo interactuar con las en herramientas contenedores.

122  Actualizaciones en tiempo real, fue comprobado el acceso instantáneo a los cambios en sus datos o en la solución sin necesidad de actualizar el navegador.  Procesos automatizados, fueron utilizados guiones, cálculos y formatos condicionales para validar datos y facilitar el flujo de trabajo.

123

5. COSTO BENEFICIO

124 5.1

INTRODUCCIÓN

Como se conoce, una de las tareas de mayor importancia en la planificación de proyectos de software es la estimación, la cual consiste en determinar, con cierto grado de certeza, los recursos de hardware y software, costo, tiempo y esfuerzo necesarios para el desarrollo de los mismos.

La estimación de costos de software tiene dos usos en la administración de proyectos:  Durante la etapa de planeamiento: Permite decidir cuantas personas son necesarias para llevar a cabo el proyecto y establecer el cronograma adecuado.  Para controlar el proceso del proyecto: es esencial evaluar si el proyecto esta evolucionado de acuerdo al cronograma y tomar las acciones correctivas si fuera necesario. Para esto se requiere contar métricas que permitan medir el nivel de cumplimiento del desarrollo del software.

En el ámbito de la ingeniería de software la estimación de costos radica básicamente en estimar la cantidad de personas necesarias para desarrollar el producto. A diferencia de otras disciplinas de la ingeniería, en las cuales, el costo de los materiales es el principal componente a ser estimado.

La estimación de costos de software posibilita relacionar conceptos generales y técnicas del análisis económico en el mundo particular de la ingeniería de software.

Aunque no es una ciencia exacta no podemos prescindir de ella puesto que hoy en día un error en las predicciones puede conducir a resultados adversos.

Es importante reconocer la fuerte relación entre costo, cronograma y calidad. Estos tres aspectos están íntimamente relacionados y controlados entre sí. De 3esta manera, se hace difícil incrementar la calidad sin aumentar el costo y/o el cronograma de software a desarrollar.

125

Similarmente, el cronograma de desarrollo no puede reducirse dramáticamente sin deteriorar la calidad del producto de software y/o incrementar el costo de desarrollo.

Muchas organizaciones desarrollan sistemas simplemente para satisfacer requerimientos obligatorios de gobierno (por ejemplo, sistemas de reporte para oficinas de trabajo, o nuevos sistemas para manejar la cambiante legislación de impuestos). Desde luego, incluso en estos casos, cuando no existe beneficio derivable del sistema (más que el lujo de evitarse multas o poder permanecer en el negocio), la administración usualmente desconoce el costo del sistema, motivo por el cual se considera que todo proyecto debe contener las distintas actividades de estimación y costo.

5.2

ANÁLISIS DE COSTO BENEFICIO

El método de Análisis Costo Beneficio está basado en la razón de los beneficios a los costos asociada con un proyecto en particular. Se considera que un proyecto es atractivo, cuando los beneficios derivados de su implementación exceden sus costos asociados. Por tanto, el primer paso en un análisis de costo beneficios es determinar cuáles de los elementos son beneficios y costos.

Para la identificación de los costos de beneficios del proyecto que son convenientes para su evaluación, es necesario definir una situación base o situación sin proyecto; la comparación de lo que sucede con proyecto versus lo que hubiera sucedido sin proyecto, definirá los costos y beneficios del mismo

126 ¿QUE ES?

El análisis costo/beneficio es el proceso de colocar cifras en dólares en los diferentes costos y beneficios de una actividad, al utilizarlo, podemos estimar el impacto financiero acumulado de lo que queremos lograr.

¿CUANDO SE UTILIZA?

Se debe utilizar el análisis costo/beneficio al comparar los costos y beneficios de las diferentes decisiones. Un análisis de costo/beneficio por si solo puede no ser una guía clara para tomar una buena decisión. Existen otros puntos que deben ser tomados en cuenta por ejemplo: la moral de los empleados, seguridad, obligaciones legales y satisfacciones del cliente.

¿COMO SE UTILIZA?

El análisis de costo beneficio involucra los siguientes seis pasos:

i.

Reunir todos los datos provenientes de factores importantes relacionados con cada una de sus decisiones.

ii.

Determinar los costos relacionados con cada factor. Algunos costos como la mano de obra, serán exactos mientras que otros serán estimados.

iii.

Sumar los costos totales para cada decisión propuesta.

iv.

Determinar los beneficios en dólares para cada decisión.

v.

Poner las cifras de los costos y beneficios totales de manera que haya una relación donde los beneficios son el numerador y los costos el denominador.

vi.

Comparar las relaciones beneficios a costos para las diferentes decisiones.

127

Para determinar el costo total del proyecto se tomará en cuenta los siguientes costos.  Costo del software.  Costo de la implementación del sistema.  Costo de la elaboración del proyecto.

5.3

MÉTODOS PARA EL ANÁLISIS DE COSTO/BENEFICIO

El método de Análisis Costo Beneficio está basado en la razón de los beneficios referenciando al costo Diferentes métodos pueden ser analizados para calcular la relación costo/beneficio. Los métodos más sofisticados consideran el tiempo-valor del dinero como parte del análisis costo/beneficio. El tiempo-valor del dinero conocido también como el factor de descuento, es simplemente un método utilizado para convertir el valor presente (dólares futuros a dólares presentes).

Los métodos comunes para el análisis del costo/beneficio incluyen:  Punto de Equilibrio  Periodo de devolución  Valor presente neto (VAN)  Tasa interna de retorno (TIR)

Uno de los métodos más comunes para el cálculo de costos es el Cocomo, es por esta razón que emplearemos este modelo.

128 5.4

MODELO COCOMO

Entre los distintos métodos de estimación de costos de desarrollo de software, el modelo Cocomo (COnstructive COst, MOdel) desarrollado por Barry M Boehm, se engloba en el grupo de los modelos algorítmicos que tratan de establecer una relación matemática la cual permite estimar el esfuerzo y tiempo requerido para desarrollar un producto.

Por un lado Cocomo define tres modos de desarrollo o tipos de proyectos  Orgánico: proyectos relativamente sencillos, menores de 50 KDLC líneas de código, en los cuales se tiene experiencia de proyectos similares y se encuentran en entornos estables.  Semi-acoplado: proyectos intermedios en complejidad y tamaño (menores de 300 KDLC), donde la experiencia en este tipo de proyectos es variable, y las restricciones intermedias.  Empotrado: proyectos complejos, en los que apenas se tiene experiencia y se engloban en un entorno de gran innovación técnica. Además se trabaja con unos requisitos muy restrictivos y de gran volatilidad.

Por otro lado existen diferentes modelos que define COCOMO:  Modelo básico: Se basa exclusivamente en el tamaño expresado en LDC.  Modelo intermedio: Además del tamaño del programa incluye un conjunto de medidas subjetivas llamadas conductores de costes.  Modelo avanzado: Incluye todo lo del modelo intermedio además del impacto de cada conductor de coste en las distintas fases de desarrollo.

129 Para el presente trabajo fue utilizado el modelo intermedio a fin de obtener las estimaciones con bastante precisión.

1)

Costo del software

E = Esfuerzo = a KLDC e * FAE (persona x mes)

T = Tiempo de duración del desarrollo = c Esfuerzo d (meses)

P= Personal = E/T (personas)

Tabla 27: Parámetro LDC/PF

FUENTE: (TRIBUNAL DE TASACIONES DE LA NACION, 2007)

Para calcular el Esfuerzo, necesitaremos hallar la variable KDLC (Kilo-líneas de código), del capítulo anterior se evidencia los PF son 290,40 (dato conocido) y las líneas por cada PF equivalen a 20 según vemos en la tabla que se ilustra a continuación:

KLDC= (PF * Líneas de código por cada PF)/1000

KLDC = (290,40*20)/1000= 5808,00

130 Para el presente proyecto se utilizara el modelo de tipo orgánico por ser el más apropiado ya que el número de líneas de código no supera los 50 KLDC (miles), y además el proyecto no es muy complejo, por consiguiente, los coeficientes que usaremos serán los siguientes: Tabla 28: Modelo de Desarrollo Proyecto Software Orgánico Semi-acoplado Empotrado

a

b

c

d

3,2

1,05

2,5

0,38

3

1,12

2,5

0,35

2,8

1,2

2,5

0,32

Fuente: (Pressman, 1997)

A partir de la tabla anterior donde se muestran los tipos de proyectos de software, elegimos el proyecto de software orgánico ya que las líneas de código obtenidos son menores a 50 KLDC (miles).

Por otro lado debemos hallar la variable FAE (Factor de Ajuste del Esfuerzo), la cual se obtendrá mediante la multiplicación de los valores evaluados en los diferentes 15 conductores de coste que se observan en la siguiente tabla:

131 Tabla 29: Factores de Ajuste de Esfuerzo VALORACIÓN CONDUCTORES DE COSTE

MUY BAJO

BAJO NOMINAL ALTO

MUY

EXTRA

ALTO ALTO

ATRIBUTOS DE SOFTWARE Fiabilidad requerida del software 0,75

0,88

0

1,15

1,4

0

Tamaño de la base de datos

0

0,94

1

1,08

1,16

0

Complejidad del producto

0,7

0,85

1

1,15

1,3

1,65

0

0

1

1,11

1,3

1,66

0

0

1

1,06

1,21

1,56

0

0,87

1

1,15

1,3

0

0

0,87

1

1,07

1,15

0

Capacidad del analista

1,46

1,19

1

0,86

0,71

0

Experiencia en la aplicación

1,29

1,13

1

0,91

0,82

0

Capacidad de los programadores

1,42

1,17

1

0,86

0,7

0

Experiencia en el S.O. utilizado

1,21

1,1

1

0,9

0

0

1,14

1,07

1

0,95

0

0

1,24

1,1

1

0,91

0,82

0

1,24

1,1

1

0,91

0,83

0

1,23

1,08

1

1,04

1,1

0

ATRIBUTOS DE HARDWARE Restricciones

del

tiempo

de

ejecución Restricciones de almacenamiento principal Volatilidad de la máquina virtual Tiempo

de

respuesta

del

ordenador ATRIBUTOS DE PERSONAL

Experiencia en el lenguaje de programación ATRIBUTOS DE PROYECTO Prácticas

de

programación

moderna Utilización de herramientas de software Limitaciones de planificación

FUENTE: (Pressman, 1997)

132 FAE = [1,15*1,08*1*1,11*1,06*1,00*1,07*0,86*0,91*0,86*1,00*0,95*0,91*0,91*1,00]

FAE = [0,82790194]

5.5

JUSTIFICACIÓN DE LOS VALORES

Atributos de Software  Fiabilidad requerida del software: Si se produce un fallo por el pago de un pedido, o fallo en alguna reserva, etc... puede ocasionar grandes pérdidas a la empresa (Valoración Alta).  Tamaño de la base de datos: La base de datos de nuestro producto será de tipo estándar (Valoración Nominal).  Complejidad del producto: La aplicación no va a realizar cálculos complejos (Valoración Baja).

Atributos de Hardware  Restricciones del tiempo de ejecución: En los requerimientos se exige alto rendimiento (Valoración Alta).  Restricciones del almacenamiento principal: No hay restricciones al respecto (Valoración Nominal).  Volatilidad de la máquina virtual: Se usarán sistemas de la “Familia Windows” (Valoración Nominal).  Tiempo de respuesta del ordenador: Deberá ser interactivo con el usuario (Valoración Alta).

133 Atributos del personal  Capacidad del analista: Capacidad alta relativamente, debido a la experiencia en análisis en proyecto similar (Valoración Alta)  Experiencia en la aplicación: Se tiene cierta experiencia en aplicaciones de esta envergadura (Valoración muy alta).  Capacidad de los programadores: Teóricamente deberá tenerse una capacidad muy alta por la experiencia en anteriores proyectos similares (Valoración muy alta).  Experiencia en S.O. utilizado: Con Windows Seven Professional la experiencia es a nivel usuario (Valoración Nominal).  Experiencia en el lenguaje de programación: Es relativamente alta, dado que se controlan las nociones básicas y las propias del proyecto (Valoración Alta).

Atributos del proyecto  Prácticas de programación modernas: Se usarán prácticas de programación mayormente convencional (Valoración Nominal).  Utilización de herramientas software: Se usarán herramientas estándar que no exigirán apenas formación, de las cuales se tiene cierta experiencia (Valoración Alta).  Limitaciones de planificación del proyecto: Existen pocos límites de planificación. (Valoración Baja).

134 Cálculo del esfuerzo del desarrollo:

E

= a KLDC e * FAE

E

= 3,2 * (5,808)^1,05 * 0,82790194 = 16,80 ≈ 17 personas /mes

Cálculo tiempo de desarrollo: T = c Esfuerzo d =

T = 2,5 * (16,80)^0,38 = 7,30 meses

Productividad:

PR = LDC/Esfuerzo

PR = 5808/16,80 = 345 ,71 LDC/personas mes

Personal promedio:

P = E/T

P = 16,80/7,30 = 2,30 personas

Según estas cifras será necesario un equipo de 3 personas trabajando alrededor de 7 meses, pero puesto que el desarrollo del proyecto debe realizarse en un plazo 3 meses, incrementaremos a 6 personas el número de personas del equipo de proyecto (ya que 16,80/3 nos da alrededor de este resultado).

Así se tendrá un equipo formado por 1 Jefe de proyecto, 2 Analistas, 2 programadores y 1 Responsable de Calidad.

135

6. CONCLUSIONES Y RECOMENDACIONES

136 6.1

INTRODUCCIÓN

Este acápite no permite detallar las conclusiones y recomendaciones que contiene el presente trabajo. Se considera necesario indicar que para llevar a cabo el presente trabajo se recabo información exhaustiva del proceso de desarrollo de software, así como los relacionados con las áreas de conocimiento de ingeniería de sistemas y otras disciplinas dentro de la informática, utilizando de base proyectos de grado similares y páginas web relacionadas con el tema.

6.2

CONCLUSIONES

Una primera conclusión es que los objetivos que se propusieron al inicio del presente proyecto se han logrado de manera satisfactoria.

Se ha desarrollado e implementado una herramienta de software para el control del personal y planillas de pago en la Unidad Ejecutora de Lucha Integral Contra el narcotráfico siendo importante resaltar los siguientes puntos:  La utilización de la metodología XP permitió optimizar el tiempo de desarrollo, siendo esta metodología flexible, logrando organizar de manera directa los flujos de trabajo, requerimientos, análisis, diseño, implementación y las respectivas pruebas.  Ninguna práctica funciona bien por si sola (con la excepción de las pruebas). Requieren las otras prácticas para equilibrarse.  La XP brinda no solo ventajas en cuanto a rapidez, sino que promueve habilidades sociales como la comunicación, el trabajo en equipo y disciplina.  En XP la comunicación es vital tanto entre el grupo de desarrollo como con el cliente, el cual debe formar parte del equipo para mantener una comunicación fluida y poder de esta forma, evacuar cualquier tipo de duda que surja con los requerimientos.

137  Es claro que no existe una metodología única para garantizar el éxito de cualquier proyecto de desarrollo de software, y esto aplica también a XP. Toda metodología requiere de cierta adaptación al proyecto, al cliente y a la idiosincrasia de la empresa desarrolladora.  XP propone una metodología ágil y concreta, aunque requiere de una nueva menara de pensar, ver y hacer las cosas, tanto por parte de los gerentes (responsables de la rentabilidad general del proyecto), como de los desarrolladores y también del cliente. La aplicabilidad de ésta metodología a cada proyecto debería ser analizada en cada caso, teniendo en cuenta el tamaño y tipo de proyecto, así como sus ventajas y desventajas.  Los recursos obtenidos en internet fueron de gran ayuda para enriquecer la información y el desarrollo del presente proyecto.  Se cuenta con un sistema de información que permite el registro de personal control y elaboración de planilla de pago de los efectivos reconocidos en el D.S. 0282 que apoyan en la lucha contra delitos de lesa humanidad.  Los beneficios que trajo la implementación del sistemas son: información centralizada en un servidor, tiempo de respuesta oportuna (consultas, reportes, etc.) historial del número de cuentas, proyectos, niveles y cargos al amparo del Reglamento de Pago de Reconocimiento Económico, control detallado de las planillas de pago, resaltando la generación de los archivos planos a efecto de realizar los abonos en Cuenta Bancaria.  Los pagos que se realizan cuentas bancarias garantizan la administración adecuada de los Recursos del Estado minimizando los riesgos de remitir remesas.

138 Tabla 30: Resumen de Resultados Obtenidos REQUERIMIENTO

SITUACIÓN ANTERIOR

Registro de personal Variaba de 10 a 15 minutos Comunicación de Variaba de 5 a 10 altas, bajas y días modificaciones Generación de Variaba de entre 5 planillas a efectivos a 10 días reconocidos en D.S. 0282 Control de cambios Variaba de entre 5 de Cuenta a 10 días

SITUACIÓN ACTUAL

Varia de 3 a 5 minutos Cambios que son evidenciados en línea Varia de 30 a 45 minutos

Cambios que evidenciados línea Control de cambios Variaba de entre 5 Cambios que de Proyecto a 10 días evidenciados línea Control de Cambios Variaba de entre 5 Cambios que de Nivel y Cargo a 10 días evidenciados línea Generación de No existía Procedimiento archivo plano evidenciados línea

PARAMETRIZACIÓN

Reduce un 33% tiempo de registro Reduce un 99% tiempos comunicación Reduce un 99% tiempo de trabajo

son Reduce un 99% en tiempos comunicación son Reduce un 99% en tiempos comunicación son Reduce un 99% en tiempos comunicación Optimización en 100%.

de los de de

los de los de los de del

FUENTE: Elaboración Propia

6.3

RECOMENDACIONES

El software está desarrollado y orientado a uso de los enlaces de las Direcciones y Fuerzas reconocidas en el D.S. 0282; en quienes recae la responsabilidad de alimentar el sistema; asimismo la información deberá ser complementada por el Encargado de Archivo y Kardex de la unidad de Reconocimiento Económico de la “U.E.L.I.C.N.”, quien complementara la información a partir de la realización del CHEQUEO DE SEGURIDAD; asimismo, el responsable de Pago de Reconocimiento Económico de la “U.E.L.I.C.N.” realizará la consistencia de la información correspondiente siendo necesaria tomar en cuenta las siguientes recomendaciones:  Es necesario realizar el mantenimiento periódico del sistema precautelando su correcto funcionamiento.

139

 La información introducida es base de los pagos de Reconocimiento Económico, por tanto la documentación de sustento deberá contar con los recaudos respectivos de privacidad y almacenamiento, coadyuvando de esta manera con integridad de la información digital.  Con el fin de alcanzar los altos niveles de expectativa que genero el presente trabajo, se recomienda que los equipos los cuales se conecten al servidor del SISTEMA INFORMÁTICO DE CONTROL DE PLANILLAS DE PAGO, cumplan con los requisitos técnicos mínimos especificados en el punto 2.13 (Requerimientos Técnicos).  De lo experimentado durante el último periodo en la ciudad de La Paz, se debe prever la redundancia del proveedor de acceso a Internet (ISP).  Teniendo en cuenta que la información es sustento del pago de Reconocimiento Económico, se considera necesario complementar el presente trabajo con la digitalización de la documentación de los files de los beneficiarios.

140

7. ANEXOS

141 7.1

ÁRBOL DE PROBLEMAS

EFECTOS Los pagos de recursos

Retraso en la

económicos del Estado,

elaboración de

no ofrece las garantías

Planillas. Cambio

necesarias.

permanente de Enlaces

Falta de coordinación

Elevada inconsistencia

Inadecuado Registro de

entre los actores del

de la información,

Descuentos por

pago de R.E.

carencia de

vacaciones, permisos,

parametrización.

bajas médicas, etc.

Baja productividad operativa, falta de sistematización, carencia de un registro único de beneficiarios, inadecuado método de pago.

CAUSAS

EL proceso de planillas

Carencia de un banco

se realiza manualmente

de datos adecuado

El acceso a la información tiene excesiva demora

No se cuenta con un sistema que registre, controle y administre la información

142 7.2

ÁRBOL DE OBJETIVOS

OBJETIVOS

Garantizar el manejo de

Disponer de

Automatizar el control,

recursos del Estado

información, verás, útil

y pago de

y oportuna.

Reconocimiento Económico

Garantizar el manejo de

Analizar, diseñar, e implementar un sistema informático, que automatice los

procedimientos de registro, control y elaboración de planillas de pago de Reconocimiento Económico, proporcionando reportes digitales e impresos.

MEDIOS

Garantizar el manejo de

El sistema permite el

El sistema elabora las

recursos del Estado

control de asistencias,

respectivas planillas de

permisos, vacaciones, bajas

pago de los funcionarios

médicas, etc.

reconocidos en D.S. 0282

Garantizar el manejo de

143 7.3

MATRIZ – MARCO LÓGICO

RESUMEN NARRATIVO DE OBJETIVOS FIN Administrar los recursos del estado de manera eficaz, equitativa y transparente, para alcanzar el bien común.

PROPÓSITOS

IDENTIFICADORES VERIFICABLES OBJETIVAMENTE MEDIDAS DE LOGROS DEL FIN La “U.E.L.I.C.N.”, brinda toda la documentación referida al registro, control y planillas de pago de R.E.

CONDICIONES QUE INDIQUEN QUE EL PROPÓSITO DE HA LOGRADO

Desarrollar un sistema  informático de control de planillas para automatizar el proceso de pago de Reconocimiento  Económico para lo cual se Analizará, diseñará, e implementará un sistema informático que  automatice los procedimientos de registro, control de personal, elaboración de planillas de pago, generación de reportes estadísticos. PRODUCTO Un software implementado en acorde a las necesidades de la “U.E.L.I.C.N.” Una base de datos con información de los efectivos reconocidos por el D.S. 0282.

Información exacta sobre registro de personal. Disponibilidad de reportes e información complementaria.

MEDIOS DE VERIFICACIÓN

SUPUESTOS

El software, el reglamento y los manuales son atribuidos al responsable de la “U.E.L.I.C.N.”, los enlaces y encargado de realizar el chequeo de seguridad.

Se cuenta con todo el material y herramientas para el desarrollo de las actividades y todas las direcciones y Fuerzas reconocidas en el D.S. 0282 están comprometidas con la automatización

DE RESULTADOS PROYECTO.

LOS DE

Informe de conformidad emitidos por el Responsable de pago de R.E., Enlaces y Encargado de Chequeo de Seguridad,

Personal dispuesto y capacitado para adoptar el nuevo sistema.

Se realizan pruebas de consistencia con los involucrados

Se implementará un sistema con los siguientes módulos:

El personal involucrado en el pago de R.E, cuenta con información veraz, útil y oportuna.

Se harán seguimiento a las historias de usuarios. En la operatividad de los sistemas serán comprobados la calidad, la funcionalidad, la interfaz y todo lo relacionado al mismo.

Aplicación correcta del reglamento de pago de Reconocimiento Económico

  

Personal capacitado para el uso y operación del sistema.

 

Registro de Beneficiario. Registro de Cuenta Bancaria. Registro de Niveles y Cargos. Registro de Proyecto (unidad). Registro de Chequeo de Seguridad.

144 

PLAN ACTIVIDADES

Proceso de Planillas de pago de Reconocimiento Económico.  Generación del archivo plano  Generación de Reportes. RIESGOS

DE

Analizar y diseñar una aplicación informática.



Informes entrevistas.

Desarrollar el sistema bajo plataforma FileMaker Pro V13.



Compulsa del sistema a desarrollar con los resultados a obtener.



Control del avance del sistema.



Aprobación de las pruebas de funcionamiento.

Realizar las pruebas de consistencia. Elaboración de manuales de usuario y operación del sistema. Capacitación del personal.

y

INSUMOS Para cumplir con las actividades necesarias se requiere:

Demoras no previstas.

RIESGOS Designación de Enlaces con memorándum y certificado académico

No se encuentra personal suficientemente cualificada y motivada

Verificación in situ

Los equipos se encuentran ocupados realizando otras tareas.

RR.HH Designación de enlaces con perfil de operador en computadoras. TECNOLÓGICOS Equipos de computación, Impresoras, scanners,

145 7.4

ENTREVISTAS

El término "entrevista" proviene del francés "entrevoir", que significa "verse uno al otro", en sus orígenes fue una técnica exclusivamente periodística y por tanto se le ha definido como la visita que se le hace a una persona para interrogarla sobre ciertos aspectos (para después, informar al público). Sin embargo, la entrevista se ha convertido en una herramienta utilizada en muchos campos profesionales, por lo que se ha utilizado con el propósito de desarrollar un intercambio de ideas significativo encaminado a una mutua ilustración. (ALEJANDRO ACEVEDO IBAÑEZ Y ALBA FLORENCIA LOPEZ, 2000)

ENTREVISTAS

146

8. BIBIOGRAFÍA

147 

Alaimo, D. M. (2013). Proyectos ágiles con Scrum. Cdad. Autónoma de Buenos Aires, 1049, Argentina: Ediciones Kleer – http://www.kleer.la.



ALEJANDRO ACEVEDO IBAÑEZ Y ALBA FLORENCIA LOPEZ, A. (2000). EL PROCESO DE LA ENTREVISTA CONCEPTO Y MODELOS. MEXICO .D.F: ED. LIMUSA.



Arango, D. A. (1996). Control de Gestion. Bogota: Interconed.



Boxcryptor. (S/D de S/M de S/A). Cifrado AES y RSA. Recuperado el 18 de 04 de 2014, de boxcryptor: https://www.boxcryptor.com/es/cifrado



CIENCIA Y TECNOLOGÍA - MINISTERIO DE EDUCACIÓN. (s.f.). CIENCIA Y TECNOLOGÍA. Recuperado

el

2014

de

04

de

17,

de

http://www.cienciaytecnologia.gob.bo/vcyt2012/uploads/boliviaplan_desarrollo_nac _ds_29272.pdf 

Cortes Morales, R. (2005). Introducción Al Análisis de Sistemas y La Ingeniería de Software. s/c: Editorial Universidad Estatal a Distancia.



ECURED. (22 de 03 de 2014). Recuperado el 17 de 05 de 2014, de http://www.ecured.cu/index.php/Pruebas_de_caja_negra



JACQUELINE, H. D. (2008). Metodología de la investigación, una comprensión holística. CARACAS: EDCIONES QUIRON - SYPAL. Recuperado el 12 de 04 de 2014, de http://investigacionholistica.blogspot.com/2008/02/la-investigacin-proyectiva.html



La Prensa. (2014 de 04 de 2014). Millonaria Robo a Sinchi Wayra. Potosi, Porco, Bolivia.



LARMAN, C. (2002). UML Y PATRONES. MADRID: PEARSON EDUCACION S.A.



LEXIVOX. (02 de 09 de 2009). Bolivia: Decreto Supremo Nº 282, 2 de septiembre de 2009. Recuperado el 21 de 04 de 2014, de Portal Juridico Lexivox: http://www.lexivox.org/norms/BO-DS-N282.xhtml



Luna Tellez, L. (28 de 04 de 2012). Metodologías ágiles vs tradicionales. Recuperado el 15 de 04 de 2014, de Scribd: http://es.scribd.com/doc/91676941/Metodologiasagiles-vs-tradicionales



Martin,

F.

(Mayo

de

2004).

martinfowler.

Obtenido

de

http://translate.google.com.bo/translate?hl=es&sl=en&u=http://martinfowler.com/a rticles/designDead.html&prev=search

148 

Mendoza, L. (12 de 06 de 2010). El 14 diciembre de 2001 la banda del ex coronel Blas Valencia mató a 3 personas y se llevó más de medio millón de dólares de Prosegur. Recuperado el 2014 de 04 de 21, de eju.tv: http://eju.tv/2010/06/prosegur-testigoclave-se-mat-poco-antes-de-declarar-un-caso-que-involucr-a-generales-de-la-polica/



Mondy, W., & Noe, R. M. (2005). Administracion de Recursos Humanos. Naucaupan de Juarez: Pearson Educación.



Murillo Estrada, E. (s.f.). Calamarca un oscuro caso. Recuperado el 14 de 04 de 2014, de Blog de EMEBOL: http://emebol.com/blog.php?val=2800



Patricio Letelier & Mª Carmen Penadés. (15 de 01 de 2006). Métodologías ágiles para el desarrollo de software: eXtreme Programming (XP). (B. A. Técnica Administrativa, Ed.)

Recuperado

el

15

de

Abril

de

2014,

de

http://www.cyta.com.ar/ta0502/v5n2a1.htm 

Pressman, R. (1997). Ingenieria de Software - Un Enfoque Práctico. Mikel Angoar.



TRIBUNAL DE TASACIONES DE LA NACION. (06 de 12 de 2007). TRIBUNAL DE TASACIONES

DE

LA

NACION.

Recuperado

http://www.ttn.gov.ar/normas/norma_24_0.htm

el

14

de

04

de

2014, de

149

9. HISTORIAS DE USUARIO