• No se han encontrado resultados

Implementación de un sistema de licitaciones cero papeles para el consorcio médico Biodimed-Biodilab

N/A
N/A
Protected

Academic year: 2020

Share "Implementación de un sistema de licitaciones cero papeles para el consorcio médico Biodimed-Biodilab"

Copied!
152
0
0

Texto completo

(1)

UNIVERSIDAD TECNOLÓGICA EQUINOCCIAL

FACULTAD DE CIENCIAS DE LA INGENIERÍA

CARRERA DE INGENIERÍA INFORMÁTICA Y

CIENCIAS DE LA COMPUTACIÓN

IMPLEMENTACIÓN DE UN SISTEMA DE LICITACIONES

CERO PAPELES PARA EL CONSORCIO MÉDICO BIODIMED –

BIODILAB

TRABAJO PREVIO A LA OBTENCIÓN DEL TÍTULO

DE INGENIERO EN INFORMÁTICA Y CIENCIAS DE LA COMPUTACIÓN

OSWALDO XAVIER LARREA AGUILAR

DIRECTOR: ING. VÍCTOR HUGO GÁLVEZ

(2)

DERECHOS DE AUTOR

(3)

DECLARACIÓN

Yo OSWALDO XAVIER LARREA AGUILAR, declaro que el trabajo aquí descrito es de mi autoría; que no ha sido previamente presentado para ningún grado o calificación profesional; y, que he consultado las referencias bibliográficas que se incluyen en este documento.

La Universidad Tecnológica Equinoccial puede hacer uso de los derechos correspondientes a este trabajo, según lo establecido por la Ley de Propiedad Intelectual, por su Reglamento y por la normativa institucional vigente.

_________________________ Oswaldo Xavier Larrea Aguilar

(4)

CERTIFICACIÓN

Certifico que el presente trabajo que lleva por título “Implementación De Un Sistema De Licitaciones Cero Papeles Para El Consorcio Médico BIODIMED – BIODILAB”, que, para aspirar al título de Ingeniero En Informática Y Ciencias De La Computación fue desarrollado por Oswaldo Xavier Larrea Aguilar, bajo mi dirección y supervisión, en la

Facultad de Ciencias de la Ingeniería; y cumple con las condiciones requeridas por el reglamento de Trabajos de Titulación artículos 18 y 25.

___________________

VICTOR HUGO GALVEZ CAZA DIRECTOR DEL TRABAJO

(5)

DEDICATORIA

A mi esposa Andrea quien me apoyo y alentó para continuar, cuando parecía que me iba a rendir.

Para mis padres por su apoyo, consejos, comprensión, amor, ayuda en los momentos difíciles, y por ayudarme con los recursos necesarios para estudiar. Me han dado todo lo que soy como persona, mis valores, mis principios, mi carácter, mi empeño, mi perseverancia, mi coraje para conseguir mis objetivos.

A mis hermanos por estar siempre presentes, acompañándome para poderme realizar.

A todos los que me apoyaron para escribir y concluir esta tesis.

Para ellos es esta dedicatoria de tesis, pues es a ellos a quienes se las debo por su apoyo incondicional.

(6)

AGRADECIMIENTOS

A la Universidad Tecnológica Equinoccial y a todos sus docentes que con su conocimiento, técnica y liderazgo han logrado sembrar e inculcar en mí la investigación y autoformación, características esenciales que me han servido para un excelente desempeño durante la carrera y vida profesional.

(7)

ÍNDICE DE CONTENIDO

PÁGINA

RESUMEN ... xvii 

ABSTRACT ... xviii 

1.  INTRODUCCIÓN ... 2 

1.1.  OBJETIVO GENERAL ... 3 

1.2.  OBJETIVOS ESPECÍFICOS ... 3 

2.  MARCO TEÓRICO ... 5 

2.1.  OFICINA SIN PAPELES ... 5 

2.1.1.  BENEFICIOS DE LA OFICINA SIN PAPELES ... 8 

2.2.  DOCUMENTO ... 9 

2.2.1.  DOCUMENTO ARCHIVISTICO ... 10 

2.2.2.  TIPOS DOCUMENTALES ... 10 

2.2.2.1.  TIPO DOCUMENTAL SIMPLE ... 10 

2.2.2.2.  TIPO DOCUMENTAL COMPUESTO ... 10 

2.2.3.  CICLO DE VIDA DE UN DOCUMENTO ... 10 

2.2.4.  CICLO VITAL DEL DOCUMENTO ... 11 

2.2.5.  DOCUMENTO INFORMATICO O ELECTRONICO ... 13 

2.2.5.1.  IMPRESOS DIGITALIZADOS ... 13 

2.2.5.2.  DIGITALES PARA IMPRIMIR ... 14 

2.2.5.3.  DIGITALES MULTIMEDIATICOS ... 14 

(8)

2.3.1.  ASPECTOS DE LA GESTION DOCUMENTAL ... 16 

2.4.  SISTEMAS INFORMATICOS DE GESTION DOCUMENTAL ... 17 

2.5.  PROCESO ... 20 

2.6.  WORKFLOW ... 23 

2.6.1.  OBJETIVOS DEL WORKFLOW ... 24 

2.6.2.  SISTEMAS DE FLUJO DE TRABAJO ... 24 

2.7.  INGENIERIA DE SOFTWARE ... 24 

2.7.1.  AREAS DEL SOFTWARE ... 26 

2.8.  CICLO DE VIDA DEL SOFTWARE ... 28 

2.8.1.  ETAPAS ... 28 

2.8.1.1.  CICLO DE VIDA CLASICO DEL SOFTWARE ... 28 

2.9.  METODOLOGIA RUP (RATIONAL UNIFIED PROCESS) ... 31 

2.9.1.  CARACTERISITICAS DE RUP ... 32 

2.9.2.  CICLO DE VIDA RUP ... 33 

2.9.3.  FASES DE LA METODOLOGIA ... 34 

2.10.  LENGUAJE UNIFICADO DE PROCESOS UML ... 37 

2.10.1.  TIPOS DE DIAGRAMAS EN UML ... 37 

2.11.  MODELO VISTA CONTROLADOR (MVC) ... 38 

2.11.1.  RESPONSABILIDAD DEL MODELO ... 39 

2.11.2.  RESPONSABILIDAD DEL CONTROLADOR ... 40 

2.11.3.  RESPONSABILIDAD DE LA VISTA ... 40 

2.12.  SOFTWARE DE DESARROLLO ... 41 

2.12.1.  FASES PARA EL DESARROLLO DE SOFTWARE ... 42 

(9)

2.13.1.  INTERFAZ GRÁFICA DE LAS APLICACIONES WEB ... 43 

2.13.2.  DEFINICIÓN DE FRAMEWORK PARA APLICACIONES WEB 44  2.14.  APLICACIONES MÓVILES ... 44 

2.15.  BASE DE DATOS ... 46 

2.16.  SERVIDOR WEB APACHE ... 46 

2.16.1.  GESTOR DE BASE DE DATOS ... 48 

2.16.2.  LENGUAJE DE PROGRAMACION ... 49 

3.  METODOLOGÍA ... 52 

3.1.  ALCANCE ... 54 

3.2.  HERRAMIENTAS / TECNICAS ... 54 

3.3.  METODOS ... 54 

4.  ANÁLISIS DE RESULTADOS ... 56 

4.1.  FASE INICIAL – ANALISIS ... 56 

4.1.1.  INTRODUCCION ... 56 

4.1.1.1.  PROPOSITO ... 57 

4.1.1.2.  ALCANCE ... 58 

4.1.2.  VISTA GENERAL DEL PROYECTO ... 58 

4.1.2.1.  FUNCIONES DEL PRODUCTO ... 58 

4.1.2.2.  ORGANIZACIÓN DEL PROYECTO ... 59 

4.1.2.3.  SUPOSICIONES Y RESTRICCIONES ... 59 

4.1.2.4.  ROLES Y RESPONSABILIDADES ... 60 

4.1.3.  REQUISITOS ESPECIFICOS ... 61 

(10)

4.1.3.1.1.  DIGITALIZAR DOCUMENTOS ... 61 

4.1.3.1.2.  HOJAS DE VIDA ... 62 

4.1.3.1.3.  PORTAFOLIOS DE SERVICIOS ... 63 

4.1.3.1.4.  FUTURAS COMPETENCIAS ... 63 

4.1.3.1.5.  CALCULADORA DE POSIBLES PRECIOS A OFERTAR 63  4.1.3.1.6.  REPORTES ESTADÍSTICOS ... 64 

4.1.3.1.7.  PLIEGOS DE LICITACIONES ... 64 

4.1.3.1.8.  LICITACION ... 64 

4.1.3.2.  REQUISITOS NO FUNCIONALES ... 65 

4.1.3.2.1.  PROPIEDAD INTELECTUAL ... 65 

4.1.3.2.2.  ACCESO UNICO ... 65 

4.1.3.2.3.  SISTEMA DE SEGURIDAD ... 65 

4.1.3.2.4.  DISPONIBILIDAD ... 65 

4.1.3.2.5.  MANTENIBILIDAD ... 66 

4.1.3.2.6.  PORTABILIDAD ... 66 

4.1.3.3.  REQUISITOS FUNCIONALES ... 66 

4.1.3.3.1.  DIAGRAMAS GENERALES ... 66 

4.1.3.3.1.1.  ACCESO AL SISTEMA ... 66 

4.1.3.3.1.2.  MODELO DE NEGOCIO ... 68 

4.1.3.3.1.3.  DIGITALIZACION DE DOCUMENTOS ... 69 

4.1.3.3.1.4.  REGISTRO DE HOJAS DE VIDA ... 70 

4.1.3.3.1.5.  REGISTRO DE SERVICIOS ... 72 

(11)

4.1.3.3.1.7.  REGISTRO DE LICITACION ... 75 

4.1.3.3.1.8.  ARMAR LICITACION ... 76 

4.1.3.3.1.9.  REGISTRAR APROBACION LICITACION ... 78 

4.1.4.  DIAGRAMA DE ESTEREOTIPOS ... 79 

4.1.4.1.  REGISTRO DE SERVICIOS... 79 

4.1.4.1.1.  REGISTRAR ESPECIALIDAD ... 79 

4.1.4.1.2.  INGRESAR SERVICIO ... 80 

4.1.4.2.  REGISTRO BIEN / MUEBLE ... 80 

4.1.4.2.1.  CONTABILIZAR BIEN / MUEBLE ... 80 

4.1.4.3.  REGISTRO PORTAFOLIOS EMPRESAS ... 81 

4.1.4.3.1.  REGISTRAR EMPRESA ... 81 

4.1.4.4.  ARMAR LICITACION ... 82 

4.1.4.4.1.  SELECCIONAR HOJA DE VIDA ... 82 

4.1.4.4.2.  SELECCIONAR PORTAFOLIO ... 82 

4.1.4.4.3.  SELECCIONAR BIEN / MUEBLE ... 83 

4.1.4.4.4.  SELECCIONAR DOCUMENTOS LEGALES ... 83 

4.1.4.4.5.  CALCULADORA DE PRECIOS ... 84 

4.1.4.5.  REGISTRAR APROBACION DE LICITACION ... 84 

4.1.4.5.1.  VISUALIZAR LICITACION ... 84 

4.1.5.  DIAGRAMA DE SECUENCIAS ... 85 

4.1.5.1.  REGISTRO DE SERVICIOS... 85 

4.1.5.1.1.  REGISTRAR ESPECIALIDAD ... 85 

4.1.5.1.2.  INGRESAR SERVICIO ... 86 

(12)

4.1.5.2.1.  CONTABILIZAR BIEN / MUEBLE ... 87 

4.1.5.3.  REGISTRO PORTAFOLIOS EMPRESAS ... 88 

4.1.5.3.1.  REGISTRAR EMPRESA ... 88 

4.1.5.3.2.  REGISTRAR CONTACTO ... 88 

4.1.5.4.  ARMAR LICITACION ... 89 

4.1.5.4.1.  SELECCIONAR HOJA DE VIDA ... 89 

4.1.5.4.2.  SELECCIONAR PORTAFOLIO ... 90 

4.1.5.4.3.  SELECCIONAR BIEN / MUEBLE ... 90 

4.1.5.4.4.  SELECCIONAR DOCUMENTOS LEGALES ... 91 

4.1.5.4.5.  CALCULADORA DE PRECIOS ... 91 

4.1.5.5.  REGISTRAR APROBACION DE LICITACION ... 92 

4.1.5.5.1.  VISUALIZAR LICITACION ... 92 

4.1.6.  DIAGRAMAS DE ESTADO ... 92 

4.1.6.1.  INGRESO DE LICITACION ... 92 

4.1.7.  DIAGRAMA DE ACTIVIDADES ... 93 

4.1.7.1.  MODULO ACCESO AL SISTEMA ... 93 

4.1.7.2.  MODULO APROBACION DE LICITACION ... 93 

4.2.  FASE DE ELABORACION - DISEÑO ... 94 

4.2.1.  ARQUITECTURA DEL SISTEMA ... 94 

4.2.1.1.  PATRON DE DISEÑO ... 95 

4.2.2.  DIAGRAMA GLOBAL DE PAQUETES ... 96 

4.2.2.1.  MODULO DE REGISTRO ... 96 

4.2.2.2.  MODULO DE ARMADO DE LICITACION ... 96 

(13)

4.2.3.1.  DIAGRAMA DE CLASES ... 97 

4.2.3.2.  DIAGRAMA DE BASE DE DATOS ... 98 

4.3.  FASE DE CONSTRUCCION ... 99 

4.3.1.  MAQUETACION ... 99 

4.3.1.1.  PAGINA DE LOGIN ... 99 

4.3.1.2.  PAGINA DE INICIO ... 100 

4.3.1.3.  REGISTRO Y ACTUALIZACION DE DOCUMENTOS .... 101 

4.3.1.4.  VISTA DE PERSONAL RRHH ... 102 

4.3.1.5.  REGISTRO DE PERSONAL RRHH ... 103 

4.3.1.6.  VISTA DE SERVICIOS ... 104 

4.3.1.7.  REGISTRO DE SERVICIOS... 105 

4.3.1.8.  VISTA DE BIEN MUEBLE ... 106 

4.3.1.9.  REGISTRO DE BIEN MUEBLE ... 107 

4.3.1.10.  VISTA DE LICITACIONES ... 108 

4.3.1.11.  REGISTRO DE EMPRESA ... 109 

4.3.1.12.  REGISTRO DE LICITACION ... 110 

4.3.2.  ELABORACION DE PROTOTIPOS ... 110 

4.3.2.1.  INGRESO AL SISTEMA ... 111 

4.3.2.2.  MENU PRINCIPAL (PAGINA DE INICIO) ... 111 

4.3.2.3.  OPCION DE LICITACIONES ... 112 

4.3.2.4.  OPCION DOCUMENTOS ... 112 

4.3.2.5.  OPCION RRHH (HOJAS DE VIDA) ... 113 

4.3.2.6.  OPCION SERVICIOS ... 113 

(14)

4.4.  FASE DE TRANSICION ... 114 

4.4.1.  INGRESO AL SISTEMA ... 114 

4.4.2.  MENU PRINCIPAL ... 115 

4.4.3.  OPCION DE LICITACIONES ... 116 

4.4.3.1.  REGISTRO DE EMPRESA ... 117 

4.4.3.2.  REGISTRO DE LICITACION ... 117 

4.4.3.3.  COMPLETAR LICITACION ... 118 

4.4.4.  OPCION DOCUMENTOS ... 118 

4.4.4.1.  AGREGAR DOCUMENTOS ... 119 

4.4.5.  SERVICIOS ... 119 

4.4.5.1.  AGREGAR SERVICIOS ... 120 

4.4.6.  RECURSOS HUMANOS ... 120 

4.4.6.1.  AGREGAR HOJAS DE VIDA ... 121 

4.4.7.  BIENES Y MUEBLES ... 122 

4.4.7.1.  AGREGAR BIENES Y MUEBLES ... 122 

5.  CONCLUSIONES Y RECOMENDACIONES ... 124 

5.1.  CONCLUSIONES ... 124 

5.2.  RECOMENDACIONES ... 125 

(15)

ÍNDICE DE TABLAS

PÁGINA

Tabla 1. Aspectos de la Gestión Documental (Ekontsulta, 2008). ... 16 

Tabla 2. Características de las Plataformas Móviles Seleccionadas (Unión Internacional de Telecomunicaciones, 2009). ... 45 

Tabla 3. Comparación Entre Servidores Apache e IIS (Netrunning, 2013). . 47 

Tabla 4. Comparación de Gestores de BDD. ... 48 

Tabla 5. Comparación Lenguajes de Programación (Villalobos, 2010). ... 49 

Tabla 6. Plan de Etapas ... 57 

Tabla 7. Roles y Responsabilidades. ... 60 

(16)

ÍNDICE DE FIGURAS

PÁGINA

Figura 1. Qué es Cero Papel (Gobierno en Línea, 2012). ... 7 

Figura 2. Ciclo de Vida de un Documento (Vivo, 2014). ... 11 

Figura 3. Ciclo Vital del Documento (Ramirez, 2010). ... 12 

Figura 4. Gestión Documental (Camore, 2010). ... 15 

Figura 5. Representación de un Proceso en un Diagrama (Muro, 2010). .... 21 

Figura 6. Ciclo de Vida Clásico del Software (Jaramillo Villegas, 2012). ... 29 

Figura 7. Fases de Iteraciones de la Metodología RUP (Instituto Superior de Apatzigán, 2010). ... 33 

Figura 8. Flujo General del MVC (Universidad de Alicante, 2013). ... 40 

Figura 9. Comparativa de Usabilidad (Villarreal, 2013). ... 48 

Figura 12. Módulos del Sistema de Licitaciones Cero Papeles. ... 56 

Figura 13. CU: Ingreso al sistema. ... 66 

Figura 14. CU: Modelo de negocio. ... 68 

Figura 15. CU: Digitalización de documentos. ... 69 

(17)

Figura 17. CU: Registro de Servicios. ... 72 

Figura 18. CU: Registrar Bien / Mueble. ... 73 

Figura 19. CU: Registro de Licitación. ... 75 

Figura 20. CU: Armar Licitación. ... 76 

Figura 21. CU: Registrar Aprobación de Licitación. ... 78 

Figura 22. DE: Registrar Especialidad. ... 79 

Figura 23. DE: Ingresar Servicio. ... 80 

Figura 24. DE: Contabilizar Bien / Mueble. ... 80 

Figura 25. DE: Registrar Empresa. ... 81 

Figura 26. DE: Seleccionar Hoja de Vida. ... 82 

Figura 27. DE: Seleccionar Portafolio. ... 82 

Figura 28. DE: Seleccionar Bien / Mueble. ... 83 

Figura 29. DE: Seleccionar Documentos Legales. ... 83 

Figura 30. DE: Calculadora de Precios. ... 84 

Figura 31. DE: Visualizar Licitación. ... 84 

Figura 32. DS: Registrar Especialidad. ... 85 

(18)

Figura 34. DS: Contabilizar Bien / Mueble. ... 87 

Figura 35. DS: Registrar Empresas. ... 88 

Figura 36. DS: Registrar Contacto. ... 88 

Figura 37. DS: Seleccionar Hoja de Vida. ... 89 

Figura 38. DS: Seleccionar Portafolio ... 90 

Figura 39. DS: Seleccionar Bien / Mueble. ... 90 

Figura 40. DS: Seleccionar Documentos Legales. ... 91 

Figura 41. DS: Calculadora de Precios. ... 91 

Figura 42. DS: Visualizar Licitación. ... 92 

Figura 43. DDE: Ingreso de Licitación. ... 92 

Figura 44. DA: Modulo Acceso al Sistema. ... 93 

Figura 45. DA: Modulo Aprobación de Licitación. ... 93 

Figura 46. Esquema de Arquitectura. ... 94 

Figura 47. La arquitectura MVC (Potencier, 2013). ... 95 

Figura 48. DP: Modulo de Registro. ... 96 

Figura 49. DP: Modulo Armado de Licitación. ... 96 

(19)

Figura 51. DBB: Diagrama de BDD. ... 98 

Figura 52. M: Login ... 99 

Figura 53. M: Inicio ... 100 

Figura 54. M: Registro y actualización de Documentos. ... 101 

Figura 55. M: Listado de Personal RRHH. ... 102 

Figura 56. M: Registro de Personal RRHH. ... 103 

Figura 57. M: Lista de Servicios. ... 104 

Figura 58. M: Registro de Servicios Nuevos. ... 105 

Figura 59. M: Vista de los Bienes Muebles. ... 106 

Figura 60. M: Registro de Bien Mueble ... 107 

Figura 61. M: Vista de licitaciones. ... 108 

Figura 62. M: Registro de empresa. ... 109 

Figura 63. M: Registro de licitación. ... 110 

Figura 64. Captura de Pantalla Ingreso al Sistema Web Prototipo. ... 111 

Figura 65. Captura de Pantalla Menú Principal Prototipo. ... 111 

Figura 66. Captura de Pantalla Opción de Licitaciones Prototipo. ... 112 

(20)

Figura 68. Captura de Pantalla Opción RRHH Prototipo. ... 113 

Figura 69. Captura de Pantalla Opción Servicios Prototipo. ... 113 

Figura 70. Captura de Pantalla Opción Bienes y Muebles Prototipo. ... 114 

Figura 71. Ingreso al Sistema. ... 114 

Figura 72. Menú Principal de Opciones. ... 115 

Figura 73. Registro de Licitaciones. ... 116 

Figura 74. Registro de Empresa. ... 117 

Figura 75. Registro de Licitación ... 117 

Figura 76. Completar Licitación ... 118 

Figura 77. Registro de Documentos. ... 118 

Figura 78. Agregar Nuevo Documento. ... 119 

Figura 79. Registro de Servicios. ... 119 

Figura 80. Ingreso de Servicios. ... 120 

Figura 81. Registro de Hojas de Vida. ... 120 

Figura 82. Ingreso de Hojas de Vida. ... 121 

Figura 83. Registros de Bienes y Muebles. ... 122 

(21)

RESUMEN

(22)

ABSTRACT

(23)
(24)

2

1.

INTRODUCCIÓN

BIODIMED – BIODILAB es un consorcio médico que provee servicios confiables en atención médica ambulatoria especializada, salud ocupacional, diagnóstico en imagen y laboratorio clínico de la mejor calidad, poniendo especial énfasis en la mejor tecnología, en la seguridad y salud en el trabajo, protección de su talento humano, elementos esenciales para el alcance de los objetivos.

Las licitaciones son uno de los puntos más importantes dentro del consorcio médico BIODIMED – BIODILAB, aquí, por medio de una puja electrónica una empresa intenta ganar las licitaciones o contratos de atención médica, ofertando calidad, buen servicio, precios competitivos en el mercado y resultados a tiempo. Las licitaciones son un conjunto de pasos que se los tienen que cumplir previa a la puja electrónica. Estos pasos son documentos que se los tiene que presentar en papel.

Los documentos que conforman las licitaciones son actas de calibraciones de los equipos médicos, equipos de laboratorio, equipos de rayos X, hojas de vida y documentos legales, los mismos que están en las distintas sucursales en forma física con riesgo a que se llegaran a extraviar, traspapelar, buscar o romper. Documentos con mucho valor para la empresa y que están expuestos al deterioro por la continua manipulación de los mismos.

(25)

3 registro del número de hojas a presentar. Para realizar este trabajo tienen un plazo de presentación, que en ocasiones se dificulta cumplirlo por los detalles antes mencionados.

El análisis de los procesos que maneja la empresa es fundamental, ya que basados en ellos se realizara el desarrollo para el aplicativo y en el caso que no existan ciertos procesos se creara el proceso.

Este proyecto propone agilitar el trabajo del personal de licitaciones, por medio de una aplicación web, que almacenara en un servidor toda la documentación en formato digital y permitirá armar la licitación de acuerdo a los pliegos entregados por la empresa que requiere de los servicios del consorcio médico BIODIMED - BIODILAB.

1.1. OBJETIVO

GENERAL

Desarrollar un sistema web de licitaciones cero papeles en el consorcio médico BIODIMED - BIODILAB, con herramientas de software libre, para evitar la manipulación de documentos físicos y agilitando el armado de las licitaciones.

1.2. OBJETIVOS

ESPECÍFICOS

 Analizar los procesos del negocio del consorcio medico BIODILAB – BIODIMED.

 Realizar el modelamiento de los procesos del negocio para el área de licitaciones.

 Implementar el sistema web cero papeles para el consorcio medico BIODILAB – BIODIMED.

(26)
(27)

5

2.

MARCO TEÓRICO

2.1. OFICINA SIN PAPELES

En un intento de poner las nuevas tecnologías al servicio del medio ambiente existe un concepto novedoso que se integra dentro de la administración electrónica que es la denominada "Oficina sin papeles".

El concepto Oficina sin papeles resulta novedoso y de difícil comprensión en un mundo que sigue utilizando el papel como soporte de múltiples actividades sociales, de comunicación, publicitario, educativo, etc. Este hábito tan arraigado en nuestra cultura se ha acrecentado en las últimas décadas con la introducción y la mayor disponibilidad de las nuevas tecnologías, que lejos de disminuir el uso del papel ha disparado su consumo. El impacto del uso de las TIC es más evidente en el entorno laboral, público o privado, que ha informatizado la mayoría de sus procesos, consiguiendo la mejora de sus gestiones y de sus productos o servicios en favor de sus clientes, pero sin reducir de manera significativa el consumo de papel. Las causas son muchas y variadas, el desconocimiento de las nuevas tecnologías, su uso inadecuado, el rechazo inicial al cambio, la costumbre de imprimir, la creencia de que un documento impreso es más valioso que uno digital, etc. (Sánchez Zaplana, 2013).

Oficinas Cero Papel u oficina sin papel se relaciona con la reducción ordenada del uso del papel mediante la sustitución de los documentos en físico por soportes y medios electrónicos (Ministerio de Tecnologías de la Información y las Comunicaciones, 2014).

(28)

6 documentos electrónicos ya que la institución no puede negar a sus clientes, organizaciones y empresas la utilización de medios físicos o en papel (Ministerio de Tecnologías de la Información y las Comunicaciones, 2014). Una forma de representar el paso de un modelo basado en papel a un modelo electrónico es el siguiente:

Fase 1: Uso exclusivo de papel, toda la administración es manual.

Fase 2: Uso exclusivo de papel, la administración se apoya en aplicaciones de tecnología.

Fase 3: Combinación de papel con documentos digitalizados y electrónicos, la administración se apoya en aplicaciones de tecnología.

Fase 4: Combinación de papel y documentos digitalizados con documentos electrónicos, administración apoyada en aplicaciones de tecnología.

Fase 5: Uso exclusivo de documentos electrónicos, toda la administración utiliza únicamente aplicaciones de tecnología (Ministerio de Tecnologías de la Información y las Comunicaciones, 2014).

La Oficina sin Papeles debe favorecer que las empresas avancen hacia el cumplimiento de las normativas de sostenibilidad medioambiental. Esta ofrece un impulso a las prácticas respetuosas con el medio ambiente como son: • Reducción del consumo de papel.

• Se disminuye la tala de árboles. • Reducción del gasto de energía.

• Reducción de consumibles (tóner, fotocopias, etc.).

• Reduce los gastos asociados al mantenimiento de documentos en papel. • Ayuda a reducir costos de impresión.

• Se reducen los productos de desecho (papel y consumibles) para el reciclado.

(29)

7 • Se ahorra otros recursos (petróleo, agua, etc.) al disminuir la producción

de materiales.

En todo este proceso es indispensable que se apliquen correctamente los principios de gestión documental, de tal forma que pueda garantizarse la autenticidad, fiabilidad, inalterabilidad y disponibilidad de la información bajo las condiciones y durante el tiempo que las normas vigentes lo requieran.

Figura 1. Qué es Cero Papel (Gobierno en Línea, 2012).

Seguridad de la información

Con la implementación de una oficina cero papeles no existe pérdida de documentos, tras papeleos, sean dados por negligencia o desastres tales como un incendio o una inundación. Al evitar estos casos de pérdidas de documentos, nunca más se perderá información valiosa de la empresa.

(30)

8 Evitar la información redundante

Se llega a eliminar la copia del documento físico o la impresión de actualizaciones del mismo documento, ya que es necesario que esa información esté en múltiples departamentos sea para su aprobación, estudio o análisis, ven necesario la copia del documento.

Con la implementación de un sistema cero papeles no existe esto, ya que la información estará disponible para la gente que necesite poder revisar, aprobar o realizar algún tipo de cambio en el documento.

2.1.1. BENEFICIOS DE LA OFICINA SIN PAPELES

Aumento de la productividad: la localización y búsqueda de los documentos es más rápida y precisa. El usuario trabaja directamente con el documento en pantalla, eliminado así los tiempos de localización, recuperación, re-archivo y sus costos asociados. Además, al facilitar el procesamiento paralelo de la información contenida en los documentos, el usuario no debe esperar a que otra persona termine con ellos para consultarlos (Ornates Jiménez, Zavala Galindo, & Vázquez Álvarez, 2014).

Mejor aprovechamiento de los espacios: el espacio necesario para el almacenamiento de documentos físicos se reduce drásticamente. Aquellos originales en papel menos consultados pueden escanearse y enviarse en custodia a una empresa especializada (un CD-ROM puede almacenar unas 15.000 páginas escaneadas). Como consecuencia de estos cambios organizativos, la oficina sin papel se presenta como una solución eficaz en la que se puede ahorrar hasta un 20% de la superficie (Ornates Jiménez, Zavala Galindo, & Vázquez Álvarez, 2014).

(31)

9 minutos diarios en acomodar su área. Una oficina ordenada y sin papeles permite encontrar la información que se necesita en el momento en que se necesita. Mejor acceso a la información: una oficina ordenada disminuye las posibilidades de que se pierdan documentos. Además, se puede controlar el acceso al archivo por niveles de seguridad preestablecidos (Ornates Jiménez, Zavala Galindo, & Vázquez Álvarez, 2014).

2.2. DOCUMENTO

Del latín documentum, un documento es una carta, diploma o escrito que ilustra acerca de un hecho, situación o circunstancia. También se trata del escrito que presenta datos susceptibles de ser utilizados para comprobar algo (Araujo, 2012).

Muchas son las clasificaciones que se realizan de los documentos, no obstante, una de las más frecuentes es aquella que tiene como criterio fundamental para desarrollarse el soporte en el que se encuentran los mismos. De ahí que básicamente se establecen dos grandes grupos: documentales textuales, que son los que se realizan en papel, y documentos no textuales, que son aquellos que utilizan cualquier otro tipo de soporte para guardar una información concreta. Como ejemplos de este último tipo están los documentos que se hallan en un pen drive, en un disco compacto, en una grabación sonora, en un vídeo, etc.

(32)

10 2.2.1. DOCUMENTO ARCHIVISTICO

Es aquel que es producido, recibido y conservado por una institución y contiene información relativa al ejercicio exclusivo de las actividades y competencias que esta institución desarrolla (Aurazo Díaz, 2004).

2.2.2. TIPOS DOCUMENTALES

Son unidades de información contenidas en los documentos y estos se clasifican en:

2.2.2.1. TIPO DOCUMENTAL SIMPLE

Formado por un solo tipo documental, cuyo contenido mantiene una unidad de información. Ejemplos: el oficio, la carta, el memorando, un libro de registro, un libro de caja, recibo, etc.

2.2.2.2. TIPO DOCUMENTAL COMPUESTO

Formado por dos o más tipos documentales que se sustentan entre si y cuyo contenido mantiene una unidad de información. Se le conoce comúnmente como “expediente”. Ejemplos: el comprobante de pago, trámites para licencias, etc. (Galeano, 2014).

2.2.3. CICLO DE VIDA DE UN DOCUMENTO

(33)

11 eliminación o selección para su custodia permanente, generalmente por su valor histórico” (Hansman, 2008).

Figura 2. Ciclo de Vida de un Documento (Vivo, 2014).

2.2.4. CICLO VITAL DEL DOCUMENTO

(34)

12 Figura 3. Ciclo Vital del Documento (Ramirez, 2010).

Archivo de Trámite

Los que conservan que por su propia naturaleza requieren de una consulta constante, de asunto en movimiento y cuya consulta es necesaria para la toma de decisiones.

Archivo de Concentración

Son los que se conservan la documentación de asunto concluidos o que ya no requieren trámite frecuente.

Archivo Histórico

(35)

13 Selección Documental Preliminar

Es la técnica que permite identificar, separar y eliminar los documentos duplicados y/o de nulo valor administrativo, de los expedientes de trámite concluido existentes en los archivos de gestión, antes de realizar su transferencia a un archivo de concentración.

Selección Documental Final

Se le llama a la técnica que permite identificar y separar dentro de un conjunto de documentos, los que deben conservarse por el valor de su información de aquellos que deben eliminarse por su irrelevancia, una vez concluido su tiempo de conservación precaucional.

2.2.5. DOCUMENTO INFORMATICO O ELECTRONICO

Al hablarse de documentos informáticos o electrónicos se alude a casos en que el lenguaje magnético constituye la acreditación, materialización o documentación de una voluntad quizás ya expresada en las formas tradicionales, y en que la actividad de un computador o de una red sólo comprueban o consignan electrónica, digital o magnéticamente un hecho, una relación jurídica o una regulación de intereses preexistentes. Se caracterizan porque sólo pueden ser leídos o conocidos por el hombre gracias a la intervención de sistemas o dispositivos traductores que hacen comprensibles las señales digitales (TICS en America Latina, 2012).

Existen tres tipos de documentos electrónicos:

2.2.5.1. IMPRESOS DIGITALIZADOS

(36)

14 de imagen a un código que electrónicamente represente letras y palabras, estos programas reciben el nombre de “Reconocimiento Óptico de caracteres”. De esto resultará una copia digital del documento impreso.

2.2.5.2. DIGITALES PARA IMPRIMIR

Un documento digital puede ser elaborado de forma directa en un medio electrónico, con programa como los “procesadores de palabras” tales como “Word” de Microsoft, con el objetivo de imprimirlo posteriormente; a su vez, este tipo de documento cumple con las características de un documento electrónico y podría además ser consultado en línea. Aunque históricamente estos programas hayan sido creados para sustituir las máquinas de escribir y facilitar la producción de documentos impresos.

2.2.5.3. DIGITALES MULTIMEDIATICOS

Son documentos concebidos con el fin de ser consultados en una computadora u ordenador, donde se aprovechan características como el “hipertexto” y la “multimedia” que les da su condición electrónica para dar forma a una nueva manera de comunicación, dentro de éstos se encuentran los contratos, pagos y firmas electrónicas. Este tipo de documentos son especialmente importantes porque dan origen o forman parte de las “Páginas Web” que componen el internet (Falcon, 2012).

2.3. GESTION

DOCUMENTAL

(37)

15 y asegurar la conservación indefinida de los documentos más valiosos, aplicando principios de racionalización y economía” (Wikipedia, 2010).

Figura 4. Gestión Documental (Camore, 2010).

Estos documentos a diferencia de la información almacenada en un ERP no tienen una organización clara de contenido, es lo que técnicamente se denomina como información desestructurada. Las organizaciones empresariales tienen que manejar en su gestión diaria, gran cantidad de información de este tipo. Además a efectos legales y de funcionamiento interno, muchas veces son necesarios este tipo de documentos. El objetivo principal de la gestión documental es racionalizar dentro de lo posible el uso de este tipo de información (Camore, 2010).

Los sistemas de gestión documental han de ofrecer medios de almacenamiento, seguridad, capacidad de recuperación e indexación. Los documentos han de estar siempre disponibles que se necesiten de manera rápida y sencilla.

(38)

16 documentación solamente a las personas autorizadas. Respecto a la indexación, solamente hay que decir que los documentos han de ser recuperables fácilmente por los usuarios, ya sea por jerarquías, búsqueda por texto o mediante sistemas de carpetas, para que se emplee el mínimo tiempo posible en este tipo de tareas. (OneGolive Services S.L., 2012)

2.3.1. ASPECTOS DE LA GESTION DOCUMENTAL

La gestión documental puede abarcar muchos grados de complejidad, dependiendo de la cantidad de documentación que haya, y el grado de eficiencia con el que se quiera gestionar. No obstante, existen unos aspectos básicos, o unos criterios que hay que tener en cuenta para gestionar documentos, y cuando se implanta un sistema de gestión documental.

Tabla 1. Aspectos de la Gestión Documental (Ekontsulta, 2008).

Localización Dónde se almacenarán los documentos. Cómo se accederá a ellos.

Clasificación Cómo se organizarán. Qué métodos se usarán para guardarlos de manera que luego sean fácilmente recuperables. Los sistemas de gestión documental se sirven de bases de datos.

Recuperación Cómo se encuentran los documentos. Existencia de algún tipo de buscador. Relacionado con la clasificación Seguridad Políticas de seguridad que definan cómo proteger los

documentos de personal no autorizado, y los distintos niveles de autorización

Recuperación de desastres

Políticas de protección contra desastres, y recuperación de la información en caso de que estos sucedan.

Custodia Qué documentos conservar y durante cuánto tiempo. Qué documentos se pueden eliminar.

Distribución Cómo se distribuyen los documentos para quienes los necesitan. Qué sistema de distribución se elige.

(39)

17 seguro y cumpla las normas de seguridad de los documentos.

Creación Cómo se crean documentos en un entorno colaborativo, controlando las versiones y niveles de autorización. Autenticación Validación de la autenticidad de los documentos.

2.4. SISTEMAS

INFORMATICOS DE GESTION DOCUMENTAL

“Se puede decir que un Sistema de Gestión Documental se ocupa del procesado, almacenamiento, búsqueda, recuperación y distribución de documentos a un conjunto de usuarios que operan en el mismo” (Lawn, 2012).

Los sistemas informáticos de gestión documental suelen integrar una serie de elementos comunes a todos ellos, a continuación detallare alguno de ellos:

Metadatos

Al margen de la información contenida en el documento, conviene almacenar información del propio documento: fecha de creación, autor, tamaño, propiedades, compañía, materia que trata… Actualmente prácticamente cualquier aplicación informática que genere documentos es capaz de almacenar todos estos metadatos (Ekontsulta, 2008).

Integración

(40)

18 Captura

Posibilidad de obtener y digitalizar documentos como imágenes, o textos que se tienen en papel u otros formatos, escaneándolos. Esto incluye funcionalidad OCR, (reconocimiento de texto), que al escanear texto lo traslada a documento de texto, en vez de documento de imagen. Una vez digitalizados es posible integrarlos en el sistema de gestión informático (Ekontsulta, 2008).

Indexación

Consiste en poner identificadores únicos a los documentos de forma que sean más sencillos de localizar. Además de esto, cuando el volumen de documentos es grande conviene utilizar otras técnicas como categorización y agrupaciones de índices para que se puedan hacer búsquedas en árbol y no sea necesario recorrer todos los elementos en una búsqueda (Ekontsulta, 2008).

Almacenamiento

Almacenamiento de los documentos electrónicos, en una base de datos. Contemplará funcionalidad para definir cuánto tiempo se mantienen, cómo hacer migraciones a otro sistema de almacenamiento, sistema de copias de seguridad, para recuperar en caso de fallo del primer sistema (Ekontsulta, 2008).

Recuperación

(41)

19 como tamaño, autor, etc., pudiendo hacer búsquedas más eficientes (Ekontsulta, 2008).

Distribución

La aplicación deberá proporcionar un canal de distribución de los archivos, en caso de que estos deban ser distribuidos (Ekontsulta, 2008).

Seguridad

La aplicación debe garantizar que los documentos tengan el nivel de seguridad adecuado. Habrá documentos con información sensible que no deberían poder ser accedidos más que por el personal indicado. Además, debe aportar seguridad frente a posibles intrusiones externas a la organización (Ekontsulta, 2008).

Workflow

El flujo de transmisión de los documentos se define por parte de la organización, por ejemplo: un empleado crea un documento técnico, un supervisor debe aprobarlo, y después alguien de administrador debe firmarlo. En caso de que la revisión no sea válida el documento debe volver al redactor. La aplicación debe ser capaz de manejar los flujos definidos por la organización y seguirlos de forma automática. En el ejemplo anterior, cuando el empleado da por terminado el documento, la aplicación lo pone listo para revisión, y según la revisión finaliza, la aplicación gestiona a quién debe llegarle (Ekontsulta, 2008).

Colaboración

(42)

20 proporcionar un soporte para que las actualizaciones que se hacen sobre un documento no se alteren mutuamente, es decir, que dos personas no puedan, por ejemplo, editar la misma parte de un documento simultáneamente. Esto se suele conseguir con el bloqueo de documentos, cuando una persona está trabajando sobre un documento nadie más puede utilizarlo (Ekontsulta, 2008).

Control de versiones

Como muchas personas pueden trabajar sobre el mismo documento, es necesario llevar un control de versiones del mismo. Las aplicaciones de gestión documental suelen integrar esto, de forma que cada vez que un documento se modifica se guarda un histórico con el autor y los cambios realizados. Este histórico, además del control, permite volver a versiones anteriores, en caso de que una nueva modificación no sea aceptada (Ekontsulta, 2008).

2.5. PROCESO

Un proceso es un conjunto de actividades mutuamente relacionadas o que al interactuar juntas en los elementos de entrada, los convierten en resultados (Finch Stoner, Freeman, Gilbert, & Mascaró Sacristán, 2015).

En informática un proceso puede informalmente entenderse como un programa en ejecución. Formalmente un proceso es "Una unidad de actividad que se caracteriza por la ejecución de una secuencia de instrucciones, un estado actual, y un conjunto de recursos del sistema asociados" (Stallings, 2005)

(43)

21 y “resultados”, es decir, producto/servicio con valor para el cliente del proceso (Muro, 2010).

Figura 5. Representación de un Proceso en un Diagrama (Muro, 2010).

Este grafico contiene 5 elementos los cuales se resumen en:

Entradas: Con unas características definidas de antemano que permite aceptarlas o rechazarlas.

Salidas: Producto/Servicio destinado al cliente interno/externo. Es fundamental, que cumpla con la calidad exigida por el proceso, caso contrario no aportará el valor añadido esperado por el cliente. Es habitual que la salida de un proceso sea la entrada del siguiente, si la entrada del siguiente proceso no cumple con la calidad esperada es seguro que la salida tampoco, provocando una cadena que desemboca en el cliente final.

Recursos o factores del proceso:

(44)

22

 Materiales: Con qué lo hace. En término de materias primas o semielaboradas. No pensemos únicamente en materiales físicos, ya que por ejemplo en empresas de servicio la información también es una materia prima.

 Infraestructura: Con que herramientas. Instalaciones, maquinaria, hardware, software, etc.

 Método: Quién hace qué, cómo lo hace y cuando lo hace. Procedimiento, instrucción de trabajo.

Sistema de control: Formado por los indicadores, sus objetivos y los cuadros de mando resultantes para la toma de decisiones. Es fundamental para evaluar la marcha del proceso, corregir deficiencias y mejorar continuamente.

Los procesos pueden ser industriales (en los que entran y salen materiales) o de gestión (en los que entra y sale información). Existen en cualquier organización aunque nunca se hayan identificado ni definido, prácticamente cualquier actividad o tarea puede ser encuadrada en algún proceso.

La gestión por Procesos conlleva:

 Una estructura coherente de procesos que representa el funcionamiento de la organización

 Un sistema de indicadores que permita evaluar la eficacia y eficiencia de los procesos tanto desde el punto de vista interno (indicadores de rendimiento) como externo (indicadores de percepción).

(45)

23

2.6. WORKFLOW

El flujo de trabajo (workflow en inglés) es el estudio de los aspectos operacionales de una actividad de trabajo: cómo se estructuran las tareas, cómo se realizan, cuál es su orden correlativo, cómo se sincronizan, cómo fluye la información que soporta las tareas y cómo se le hace seguimiento al cumplimiento de las tareas. Generalmente los problemas de flujo de trabajo se modelan con redes de Petri (Wikipedia, 2015).

Si bien el concepto de flujo de trabajo no es específico a la tecnología de la información, una parte esencial del software para trabajo colaborativo (groupware) es justamente el flujo de trabajo.

Una aplicación de flujos de trabajo automatiza la secuencia de acciones, actividades o tareas utilizadas para la ejecución del proceso, incluyendo el seguimiento del estado de cada una de sus etapas y la aportación de las herramientas necesarias para gestionarlo

Se pueden distinguir tres tipos de actividad:

 Actividades colaborativas: Un conjunto de usuarios trabajan sobre un mismo repositorio de datos para obtener un resultado común. Tiene entidad el trabajo de cada uno de ellos en sí mismo.

 Actividades cooperativas: Un conjunto de usuarios trabajan sobre su propio conjunto particular, estableciendo los mecanismos de cooperación entre ellos. No tiene entidad el trabajo de ninguno de ellos si no es visto desde el punto de vista global del resultado final.

(46)

24 2.6.1. OBJETIVOS DEL WORKFLOW

 Reflejar, mecanizar y automatizar los métodos y organización en el sistema de información.

 Establecer los mecanismos de control y seguimiento de los procedimientos organizativos.

 Independizar el método y flujo de trabajo de las personas que lo ejecutan.

 Facilitar la movilidad del personal.

 Soportar procesos de reingeniería de negocio.

 Agilizar el proceso de intercambio de información y agilizar la toma de decisiones de una organización, empresa o institución.

 Adicionalmente optimizar el servicio (Wikipedia, 2015).

2.6.2. SISTEMAS DE FLUJO DE TRABAJO

El propósito de los sistemas de flujo de trabajo, (o BPMS, business process management systems), es acercar personas, procesos y máquinas, con el objeto de reducir tiempo y acelerar la realización de un trabajo. Estos sistemas permiten trabajar en equipo desde diferentes lugares físicos. Los sistemas de flujo de trabajo facilitan la automatización de los flujos de trabajo entre procesos y permiten integrar los procesos de la empresa.

2.7. INGENIERIA DE SOFTWARE

La ingeniería de software es una disciplina formada por un conjunto de métodos, herramientas y técnicas que se utilizan en el desarrollo de los programas informáticos (Ponce, 2010).

(47)

25 encarga de toda la gestión del proyecto para que éste se pueda desarrollar en un plazo determinado y con el presupuesto previsto.

La ingeniería de software, por lo tanto, incluye el análisis previo de la situación, el diseño del proyecto, el desarrollo del software, las pruebas necesarias para confirmar su correcto funcionamiento y la implementación del sistema.

Cabe destacar que el proceso de desarrollo de software implica lo que se conoce como ciclo de vida del software, que está formado por cuatro etapas: concepción, elaboración, construcción y transición.

La concepción fija el alcance del proyecto y desarrolla el modelo de negocio; la elaboración define el plan del proyecto, detalla las características y fundamenta la arquitectura; la construcción es el desarrollo del producto; y la transición es la transferencia del producto terminado a los usuarios.

Una vez que se completa este ciclo, entra en juego el mantenimiento del software. Se trata de una fase de esta ingeniería donde se solucionan los errores descubiertos (muchas veces advertidos por los propios usuarios) y se incorporan actualizaciones para hacer frente a los nuevos requisitos. El proceso de mantenimiento incorpora además nuevos desarrollos, para permitir que el software pueda cumplir con una mayor cantidad de tareas.

(48)

26 La primera de todas las etapas del trabajo que realizan los ingenieros de software consiste en estudiar minuciosamente las características que se creen necesarias para el programa a desarrollar, y es éste el punto en el cual deben encontrar un equilibrio (cada vez más difícil de alcanzar) entre las demandas excesivas de los malos consumidores y las posibilidades de la compañía. El tiempo es dinero, y las empresas del mundo informático lo saben muy bien.

Cada función de un programa, cada rasgo que lo vuelva más cómodo, más inteligente, más accesible, se traduce en una cantidad determinada de tiempo, que a su vez acarrea los sueldos de todas las personas involucradas en su desarrollo. Pero además del costo de producción necesario para realizar cada una de las piezas de un programa, la ingeniería de software debe decidir cuáles de ellas tienen sentido, son coherentes con el resto y son necesarias para comunicar claramente la esencia y los objetivos de la aplicación (Mancilla, 2014).

2.7.1. AREAS DEL SOFTWARE

Según Roger Pressman, en su libro Ingeniería del software un enfoque práctico, al software se lo puede clasificar de la siguiente manera:

Software de sistemas: El software de sistemas es un conjunto de programas que han sido escritos para servir a otros programas. Algunos programas de sistemas (por ejemplo: compiladores, editores y utilidades de gestión de archivos) procesan estructuras de información complejas pero determinadas (Pressman, 2010).

(49)

27

Software de gestión: Las aplicaciones en esta área reestructuran los datos existentes para facilitar las operaciones comerciales o gestionar la toma de decisiones. Además de las tareas convencionales de procesamientos de datos, las aplicaciones de software de gestión también realizan cálculo interactivo (por ejemplo: el procesamiento de transacciones en puntos de ventas) (Pressman, 2010).

Software de ingeniería y científico: Se caracterizado por los algoritmos de manejo de números como por ejemplo astronomía, vulcanología, etc.

Software empotrado: Reside en memoria de sólo lectura y se utiliza para controlar productos y sistemas de los mercados industriales y de consumo. El software empotrado puede ejecutar funciones muy limitadas y curiosas (por ejemplo: el control de las teclas de un horno de microondas) o suministrar una función significativa y con capacidad de control (por ejemplo: funciones digitales en un automóvil, tales como control de la gasolina, indicadores en el salpicadero, sistemas de frenado, etc.).

Software de computadoras personales: El procesamiento de textos, las hojas de cálculo, los gráficos por computadora, multimedia, entretenimientos, gestión de bases de datos, aplicaciones financieras, de negocios y personales y redes o acceso a bases de datos externas son algunas de los cientos de aplicaciones.

(50)

28

Software de inteligencia artificial: Hace uso de algoritmos no numéricos para resolver problemas complejos para los que no son adecuados el cálculo o el análisis directo.

2.8. CICLO DE VIDA DEL SOFTWARE

Es la forma mediante la cual se describen los diferentes pasos que se deben seguir para el desarrollo de un software, partiendo desde una necesidad hasta llegar a la puesta en marcha de una solución y su apropiado mantenimiento. El ciclo de vida para un software comienza cuando se tiene la necesidad de resolver un problema, y termina cuando el programa que se desarrolló para cumplir con los requerimientos, deja de ser utilizado.

Existen varias versiones del ciclo de vida del software entre las cuales se destacan: el ciclo de vida clásico o en cascada, el modelo en espiral, el desarrollo de prototipos, el modelo por incrementos y el modelo extremo (Jaramillo Villegas, 2012).

2.8.1. ETAPAS

2.8.1.1. CICLO DE VIDA CLASICO DEL SOFTWARE

(51)

29 Figura 6. Ciclo de Vida Clásico del Software (Jaramillo Villegas, 2012).

INGENIERÍA DE SISTEMAS: En esta etapa el analista luego de un minucioso y detallado estudio de los sistemas de una organización, detecta un problema o una necesidad que para su solución y/o satisfacción es necesario realizar un desarrollo de software.

ANÁLISIS: En esta etapa se debe entender y comprender de forma detallada cual es la problemática a resolver, verificando el entorno en el cual se encuentra dicho problema, de tal manera que se obtenga la información necesaria y suficiente para afrontar su respectiva solución. Esta etapa es conocida como la del QUÉ se va a solucionar.

DISEÑO: Una vez que se tiene la suficiente información del problema a

(52)

30 IMPLEMENTACIÓN: Partiendo del análisis y diseño de la solución, en esta etapa se procede a desarrollar el correspondiente programa que solucione el problema mediante el uso de una herramienta computacional determinada.

PRUEBAS: Los errores humanos dentro de la programación de los computadores son muchos y aumentan considerablemente con la complejidad del problema. Cuando se termina de escribir un programa de computador, es necesario realizar las debidas pruebas que garanticen el correcto funcionamiento de dicho programa bajo el mayor número de situaciones posibles a las que se pueda enfrentar.

DOCUMENTACIÓN: Es la guía o comunicación escrita en sus diferentes formas, ya sea en enunciados, procedimientos, dibujos o diagramas que se hace sobre el desarrollo de un programa. La importancia de la documentación radica en que a menudo un programa escrito por una persona, es modificado por otra. Por ello la documentación sirve para ayudar a comprender o usar un programa o para facilitar futuras modificaciones (mantenimiento).

La documentación se compone de tres partes:

a) Documentación Interna: Son los comentarios o mensajes que se añaden al código fuente para hacer más claro el entendimiento de los procesos que lo conforman, incluyendo las precondiciones y las poscondiciones de cada función.

b) Documentación Externa: Se define en un documento escrito con los siguientes puntos:

 Descripción del Problema

 Datos del Autor

 Algoritmo (diagrama de flujo o Pseudocódigo)

 Diccionario de Datos

(53)

31 c) Manual de Usuario: Describe paso a paso la manera cómo funciona el programa, con el fin de que el usuario lo pueda manejar para que obtenga el resultado deseado.

MANTENIMIENTO: Una vez instalado un programa y puesto en marcha para realizar la solución del problema previamente planteado o satisfacer una determinada necesidad, es importante mantener una estructura de actualización, verificación y validación que permitan a dicho programa ser útil y mantenerse actualizado según las necesidades o requerimientos planteados durante su vida útil. Para realizar un adecuado mantenimiento, es necesario contar con una buena documentación del mismo.

2.9. METODOLOGIA

RUP

(RATIONAL UNIFIED PROCESS)

RUP (Proceso de Desarrollo Unificado) Forma disciplinada de asignar tareas y responsabilidades en una empresa de desarrollo (quién hace qué, cuándo y cómo)

El proceso unificado conocido como RUP, es un modelo de software que permite el desarrollo de software a gran escala, mediante un proceso continuo de pruebas y retroalimentación. “Es un marco de trabajo genérico que puede especializarse para una gran variedad de sistemas de software, para diferentes áreas de aplicación, diferentes tipos de organizaciones, diferentes niveles de aptitud y diferentes tamaños de proyecto” (Booch, Jacobson, & Rumbaugh, 2000)

(54)

32 El proceso de desarrollo constituye un marco metodológico que define en términos de metas estratégicas, objetivos, actividades y artefactos (documentación) requerido en cada fase de desarrollo. Esto permite enfocar esfuerzo de los recursos humanos en términos de habilidades, competencias y capacidades a asumir roles específicos con responsabilidades bien definidas (Instituto Superior de Apatzigán, 2010).

2.9.1. CARACTERISITICAS DE RUP

Manejado por casos de uso: Un caso de uso es parte de la funcionalidad del sistema que proporciona al usuario un resultado, los casos de uso representan los requisitos funcionales y el conjunto de ellos constituyen el modelo de casos de uso que describe la funcionalidad total del sistema. Los casos de uso reemplazan la antigua especificación funcional tradicional y constituyen la guía fundamental establecida para las actividades a realizar durante todo el proceso de desarrollo incluyendo el diseño, la implementación y las pruebas del sistema (Booch, Jacobson, & Rumbaugh, 2000).

(55)

33 Iterativo e Incremental: Para hacer más manejable un proyecto se recomienda dividirlo en ciclos. Para cada ciclo se establecen fases de referencia, cada una de las cuales debe ser considerada como un mini proyecto cuyo núcleo fundamental está constituido por una o más iteraciones de las actividades principales básicas de cualquier proceso de desarrollo, las iteraciones deben estar controladas para una efectividad máxima. En concreto RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en número variable según el proyecto y en las que se hace un mayor o menor hincapié en las distintas actividades.

2.9.2. CICLO DE VIDA RUP

La estructura del ciclo de vida del proceso de desarrollo unificado se repite a lo largo de una serie de ciclos que constituye la vida del software. Cada ciclo concluye con una versión del sistema.

(56)

34 2.9.3. FASES DE LA METODOLOGIA

FASE 1: INICIO

Antes de iniciar un proyecto es conveniente plantearse algunas cuestiones: “¿Cuáles son las principales funciones del sistema para sus usuarios más importantes? ¿Cómo podría ser la arquitectura del sistema? ¿Cuál es el plan del proyecto y cuanto costara desarrollar el producto?” (Booch, Jacobson, & Rumbaugh, 2000). La fase de inicio trata de responder a estas preguntas y a otras más. Todo esto con el fin de explorar el problema y decidir si vamos a continuar o a dejarlo. Generalmente no debe durar mucho más de una semana. En esta etapa se llega a realizar la comprensión del problema y la tecnología, la delimitación del ámbito del proyecto y la eliminación de los riesgos críticos. Durante esta fase se hace más hincapié en las actividades del modelo de negocio y de requerimientos.

Al concluir con la fase de inicio se lograra tener una arquitectura inicial o arquitectura candidata, también se abra realizado el análisis de los riesgos críticos lo cual nos permitirá saber si es factible la construcción del sistema y por ultimo tendremos el análisis del modelo del negocio, con la aprobación de todos los involucrados, para poder comenzar la segunda fase.

FASE 2: ELABORACION

(57)

35 de construcción, costosa y arriesgada. Es por esto que la fase de elaboración es de gran importancia.

Se debe lograr un 80% de los casos de uso, identificación de actores y abordar los riesgos que influyan en la construcción del objetivo lo cual nos permitirá tener una línea base de la arquitectura, una vez concluida esta fase se tendrá la información necesaria para poder continuar con la fase de construcción (Booch, Jacobson, & Rumbaugh, 2000).

También, uno de los objetivos de esta fase es avanzar con el desarrollo de los modelos de análisis y diseño, los cuales nos permitirán tener la línea para la arquitectura. Se puede realizar la elaboración de un prototipo del sistema con el fin de que las personas involucradas puedan ver que es factible el desarrollo del producto, pero este prototipo no nos serviría como base para la construcción del producto, ya que sería solo un bosquejo del mismo.

Para el desarrollo de la arquitectura base se tiene que dar prioridad a los casos de uso y se realiza actividades de análisis diseño e implementación a nivel de arquitectura. Se realizan actividades de diseño, analizando las clases y paquetes, y se diseñan las clases y subsistemas. Se debe tener una lista de riesgos actualizada, así como el plan del proyecto para las fases de construcción y transición.

FASE 3: CONSTRUCCION DE PROTOTIPO

(58)

36 La finalidad principal de esta fase es alcanzar la capacidad operacional del producto de forma incremental a través de las sucesivas iteraciones. Durante esta fase todos los componentes, características y requisitos, que no se ha realizado hasta ahora, han de ser implementados, integrados y testeados, obteniéndose una versión del producto que se pueda poner en manos de los usuarios (una versión beta).

El desarrollo tiene que ser guiado por los casos de uso y la arquitectura elegida, realizando continuas iteraciones. Al construir el software en incrementos pequeños se hace más manejable, ya que se reduce el análisis, diseño, implementación y pruebas al número de observaciones encontradas dentro de un incremento individual.

En el caso de no haber encontrado todos los casos de uso y actores en las dos etapas anteriores, aquí se tienen que detallar al cien por ciento. También se tiene que realizar una o varias interfaces de usuario beta, dependiendo del tipo de software que se está construyendo. También se pueden realizar cambios a nivel de casos de uso siempre y cuando estos no hayan sido desarrollados. Cada caso de uso que se aumente implica la realización de los modelos de análisis y diseño (Booch, Jacobson, & Rumbaugh, 2000).

FASE 4: TRANSICION

(59)

37 Algunos objetivos que se llegan a cumplir en esta fase es haber cumplido con los requisitos establecidos en las fases anteriores, hasta la satisfacción de los usuarios. Las pruebas de aceptación es responsabilidad del cliente, aunque en algunos casos, la empresa puede contratar los servicios de una empresa especializada en realizar estas pruebas. Dependiendo de la magnitud del proyecto y el número de usuario que manejara el sistema se puede definir la instalación del sistema en algunos usuarios (beta), o en una máquina. La realización de estas pruebas es con el fin de verificar si el sistema cumple con las expectativas de los usuarios, descubrir riesgos inesperados, encontrar problemas o errores no resueltos, eliminar ambigüedades en la documentación del usuario y observar el manejo del usuario en el sistema para poder realizar refuerzos en el uso del software de ser necesario.

La fase de transición finaliza con el lanzamiento del producto y con la satisfacción del cliente (Booch, Jacobson, & Rumbaugh, 2000).

2.10. LENGUAJE UNIFICADO DE PROCESOS UML

UML son las siglas de “Unified Modeling Language” Se trata de un estándar que se ha adoptado a nivel internacional por numerosos organismos y empresas para crear esquemas, diagramas y documentación relativa a los desarrollos de software (programas informáticos) (Krall, 2009).

Se sostiene sobre tres ideas básicas que son los casos de uso, arquitectura y el desarrollo iterativo incremental.

2.10.1. TIPOS DE DIAGRAMAS EN UML

(60)

38 Diagramas de casos de uso: representan a los actores y casos de uso (procesos principales) que intervienen en un desarrollo de software.

Diagramas de clases: para UML una clase es una entidad, no una clase software. Un diagrama de clases UML puede ser un diagrama del dominio o representación de conceptos que intervienen en un problema, o también un diagrama de clases software. El sentido de un diagrama UML se lo da la persona que lo construye.

Diagramas de secuencia: suelen usarse para representar objetos software y el intercambio de mensajes entre ellos, representando la aparición de nuevos objetos de izquierda a derecha.

Diagramas de colaboración: suelen usarse para representar objetos o clases y la forma en que se transmiten mensajes y colaboran entre ellos para cumplir un objetivo.

Diagramas de estados: suelen usarse para representar cómo evoluciona un sistema (cómo va cambiando de estado) a medida que se producen determinados eventos.

Otros diagramas: diagramas de actividad, diagramas de paquetes, diagramas de arquitectura software, etc. (Krall, 2009).

2.11. MODELO VISTA CONTROLADOR (MVC)

(61)

39 Se trata de un modelo muy maduro y que ha demostrado su validez a lo largo de los años en todo tipo de aplicaciones, y sobre multitud de lenguajes y plataformas de desarrollo (Universidad de Alicante, 2013).

Cada uno de estos componentes se los puede definir de la siguiente manera:

El Modelo es el que contiene una representación de los datos que maneja el sistema, su lógica de negocio, y sus mecanismos de persistencia.

La Vista o interfaz de usuario, compone la información que se envía al cliente y los mecanismos interacción con éste.

El Controlador es el que actúa como intermediario entre el Modelo y la Vista, gestionando el flujo de información entre ellos y las transformaciones para adaptar los datos a las necesidades de cada uno.

2.11.1. RESPONSABILIDAD DEL MODELO

 Acceder a la capa de almacenamiento de datos. Lo ideal es que el modelo sea independiente del sistema de almacenamiento.

 Define las reglas de negocio (la funcionalidad del sistema). Un ejemplo de regla puede ser: "Si la mercancía pedida no está en el almacén, consultar el tiempo de entrega estándar del proveedor".

 Lleva un registro de las vistas y controladores del sistema.

(62)

40 2.11.2. RESPONSABILIDAD DEL CONTROLADOR

 Recibe los eventos de entrada (un clic, un cambio en un campo de texto, etc.).

 Contiene reglas de gestión de eventos, del tipo "SI Evento Z, entonces Acción W". Estas acciones pueden suponer peticiones al modelo o a las vistas. Una de estas peticiones a las vistas puede ser una llamada al método "Actualizar()". Una petición al modelo puede ser "Obtener_tiempo_de_entrega ( nueva_orden_de_venta )".

2.11.3. RESPONSABILIDAD DE LA VISTA

 Recibe datos del modelo y los muestra al usuario.

 Tienen un registro de su controlador asociado (normalmente porque además lo instancia).

 Pueden dar el servicio de "Actualización()", para que sea invocado por el controlador o por el modelo (cuando es un modelo activo que informa de los cambios en los datos producidos por otros agentes).

(63)

41 El usuario interactúa con la interfaz de usuario de alguna forma (por ejemplo, el usuario pulsa un botón, enlace, etc.). El controlador recibe (por parte de los objetos de la interfaz-vista) la notificación de la acción solicitada por el usuario. El controlador gestiona el evento que llega, frecuentemente a través de un gestor de eventos (handler) o callback. El controlador accede al modelo, actualizándolo, posiblemente modificándolo de forma adecuada a la acción solicitada por el usuario (por ejemplo, el controlador actualiza el carro de la compra del usuario). Los controladores complejos están a menudo estructurados usando un patrón de comando que encapsula las acciones y simplifica su extensión. El controlador delega a los objetos de la vista la tarea de desplegar la interfaz de usuario. La vista obtiene sus datos del modelo para generar la interfaz apropiada para el usuario donde se refleja los cambios en el modelo (por ejemplo, produce un listado del contenido del carro de la compra). El modelo no debe tener conocimiento directo sobre la vista. Sin embargo, se podría utilizar el patrón Observador para proveer cierta indirección entre el modelo y la vista, permitiendo al modelo notificar a los interesados de cualquier cambio. Un objeto vista puede registrarse con el modelo y esperar a los cambios, pero aun así el modelo en sí mismo sigue sin saber nada de la vista. El controlador no pasa objetos de dominio (el modelo) a la vista aunque puede dar la orden a la vista para que se actualice. Nota: En algunas implementaciones la vista no tiene acceso directo al modelo, dejando que el controlador envíe los datos del modelo a la vista. La interfaz de usuario espera nuevas interacciones del usuario, comenzando el ciclo nuevamente (Universidad de Alicante, 2013).

2.12. SOFTWARE DE DESARROLLO

(64)

42 El software de desarrollo comúnmente se conoce por IDE (Integrated Development Environment, por sus siglas en inglés). Se utiliza para hacer programas en diferentes lenguajes (C++, Java, Python, Lisp, etc).

2.12.1. FASES PARA EL DESARROLLO DE SOFTWARE

Planificación.

La tarea más importante en la creación de un producto de software es la extracción de los requisitos o las necesidades de análisis. Los clientes suelen tener una idea abstracta de lo que quieren como resultado final, pero no lo que el software debe hacer. Su idea suele ser incompleta, ambigua, cuando no contradictoria.

Aplicación, comprobación y documentación.

La implementación es la parte del proceso en el que los ingenieros de software realmente programan el código para el proyecto. La comprobación del software es una parte integral e importante del proceso de desarrollo de software. Esta parte del proceso asegura que los defectos se reconocen tan pronto como sea posible.

Documentar el diseño interno de software con el propósito de mantenimiento futuro y la mejora se realiza durante todo el desarrollo. Esto también puede incluir la redacción de una API, ya sea externa o interna. Es muy importante documentar todo lo que se hizo en el proyecto.

Despliegue y mantenimiento.

(65)

43 manera en un entorno de producción. Por otro lado, el mantener y mejorar el software para hacer frente a los problemas recién descubiertos o nuevos requisitos puede tomar mucho más tiempo que el desarrollo inicial del software. Puede ser necesario añadir código que no encaja en el diseño original para corregir un problema imprevisto o puede ser que un cliente solicita una mayor funcionalidad y el código se puede añadir a sus peticiones (Tipos de software, 2010).

2.13. APLICACIÓN WEB

(Web application, webapp). Una aplicación web es cualquier aplicación que es accedida vía web por una red como internet o una intranet.

En general, el término también se utiliza para designar aquellos programas informáticos que son ejecutados en el entorno del navegador (por ejemplo, un applet de Java) o codificado con algún lenguaje soportado por el navegador (como JavaScript, combinado con HTML); confiándose en el navegador web para que reproduzca (renderice) la aplicación.

Una de las ventajas de las aplicaciones web cargadas desde internet (u otra red) es la facilidad de mantener y actualizar dichas aplicaciones sin la necesidad de distribuir e instalar un software en, potencialmente, miles de clientes. También la posibilidad de ser ejecutadas en múltiples plataformas (Alegsa, 2010).

2.13.1. INTERFAZ GRÁFICA DE LAS APLICACIONES WEB

(66)

44 Prácticamente no hay limitaciones, las aplicaciones web pueden hacer casi todo lo que está disponible para aplicaciones tradicionales: acceder al mouse, al teclado, ejecutar audio o video, mostrar animaciones, soporte para arrastrar y soltar, y otros tipos de tecnologías de interacción usuario-aplicación.

2.13.2. DEFINICIÓN DE FRAMEWORK PARA APLICACIONES WEB

(Web application framework) Un framework para aplicaciones web es un framework que sirve para el desarrollo web: aplicaciones web, sitios web dinámicos y servicios web.

Los frameworks proporcionan herramientas, bibliotecas, plantillas, códigos y aplicaciones de ejemplos, etc., que facilitan el desarrollo web.

2.14. APLICACIONES MÓVILES

(67)

45 Tabla 2. Características de las Plataformas Móviles Seleccionadas

(Unión Internacional de Telecomunicaciones, 2009).

Proveedor Sistema de explotación (OS) Lenguaje de programación

Aplicaciones (fecha de

lanzamiento)

Apple iPhone OS Objective-C App Store (julio de 2008) LiMo Foundation LiMo Platform

(Linux)

Java, native

(C/C++) R2 (otoño de 2009)

Microsoft Windows Mobile Visual C#/C++ Windows Marketplace for Mobile (otoño de 2009)

Open Handset

Alliance Android (Linux) Java

Android Market (octubre de 2008)

Palm

Palm OS C/C++

Palm App catalog (junio de 2009) webOS (Linux) JavaScript, HTML

5

Qualcomm BREW C/C++ Plaza Retail (mayo de 2008) RIM BlackBerry OS Java BlackBerry App World (abril de

2009) Symbian

Foundation Symbian C++ Nokia Ovi Store (mayo de 2009)

Referencias

Documento similar

El contar con el financiamiento institucional a través de las cátedras ha significado para los grupos de profesores, el poder centrarse en estudios sobre áreas de interés

Cada menú de inicio es personalizado, pero en el menú de carpetas de la izquierda siempre existe una opción relativa a COMPRAS Y CONTRATACIÓN que,

[r]

[r]

[r]

Luis Miguel Utrera Navarrete ha presentado la relación de Bienes y Actividades siguientes para la legislatura de 2015-2019, según constan inscritos en el

Debido al riesgo de producir malformaciones congénitas graves, en la Unión Europea se han establecido una serie de requisitos para su prescripción y dispensación con un Plan

Como medida de precaución, puesto que talidomida se encuentra en el semen, todos los pacientes varones deben usar preservativos durante el tratamiento, durante la interrupción