Embed Size (px)
Citation preview
UNIVERSIDAD NACIONAL EXPERIMENTAL DE GUAYANA VICERRECTORADO ACADÉMICO
COORDINACIÓN GENERAL DE PREGRADO COORDINACIÓN DEL PROGRAMA DE PASANTÍA
INGENIERÍA INFORMÁTICA
SISTEMA DE INFORMACIÓN BAJO AMBIENTE WEB PARA EL CONTROL DE GESTION EN LA COORDINACIÓN DE INFORMÁTICA DE
CORPOELEC REGIÓN BOLÍVAR
Trabajo de Pasantía presentado como requisito para optar al Título de Ingeniero en
Informática
Tutor Académico:
Ing. Andrés Caniumilla
C.I. E-82.031.740
Autor:
Tlgo. Muñoz G., Mayerlin J.
C.I. V-18.478.855
Tutor Industrial:
Ing. Rafael Rodríguez
C.I. V-9.909.776
Ciudad Guayana, Octubre del 2011
UNIVERSIDAD NACIONAL EXPERIMENTAL DE GUAYANA
COORDINACIÓN GENERAL DE PREGRADOCOORDINACIÓN DEL PROGRAMA DE PASANTÍA
Quienes suscriben, miembros del jurado
Pasantía, a los fines de evaluar el trabajo presentado por
Muñoz Guerrero, titular de la Cédula de Identidad Nº
Título de Ingeniero en Informática, correspondiente a la Fase de Ejecución de la
pasantía profesional que cumplió en la Organización Productiva:
el lapso: 01/04/2011 – 21/07
y méritos suficientes exigidos
Experimental de Guayana por lo que se da su aprobación.
_____________________
Ing. Andrés Caniumilla
C.I. E-82.031.740
Tutor Académico
UNIVERSIDAD NACIONAL EXPERIMENTAL DE GUAYANA
VICERRECTORADO ACADÉMICO COORDINACIÓN GENERAL DE PREGRADO
COORDINACIÓN DEL PROGRAMA DE PASANTÍA INGENIERÍA INFORMÁTICA
miembros del jurado asignados por la Coordinación de
asantía, a los fines de evaluar el trabajo presentado por la Tlgo. Mayerlin
, titular de la Cédula de Identidad Nº V-18.478.855, para optar al
Título de Ingeniero en Informática, correspondiente a la Fase de Ejecución de la
pasantía profesional que cumplió en la Organización Productiva: CORPOELEC
21/07/2011, considerando que la misma reúne los requisitos
exigidos por los reglamentos de la Universidad Nacional
Experimental de Guayana por lo que se da su aprobación.
_______ ____________
Ing. Andrés Caniumilla Ing. Rafael Rodríguez
C.I. V-9.909.776
Tutor Industrial
____________________
Ing. Marbella Muñoz
C.I.: V-8.881.853
Jurado
Ciudad Guayana, Octubre del 2011
UNIVERSIDAD NACIONAL EXPERIMENTAL DE GUAYANA
por la Coordinación de
Mayerlin José
, para optar al
Título de Ingeniero en Informática, correspondiente a la Fase de Ejecución de la
CORPOELEC, en
la misma reúne los requisitos
por los reglamentos de la Universidad Nacional
_____________________
Ing. Rafael Rodríguez
9.909.776
Tutor Industrial
i
DEDICATORIA
A mis padres Ginette y Omar; que siempre han sido de gran apoyo durante
el curso de mi carrera; a ti mamá que fuiste mi primera maestra, que me enseñaste
a leer y a escribir y me educaste para saber conllevar cualquier reto que me
propusiera. A ti papá, que siempre has estado allí en cada momento que te he
necesitado y me has brindado tu apoyo incondicional.
A mi hermanita María José; la luz de mis ojos, por iluminar mis días y
llenarlos de alegría y felicidad, a ti, que siempre me has apoyado, entendido y has
sido paciente cuando no he podido estar contigo por motivos académicos. Eres mi
mayor inspiración. Te amo.
A ustedes, mi familia, les dedico éste trabajo que con mucho esfuerzo y
dedicación he realizado, para alcanzar ésta meta tan importante que me he
propuesto.
Mayerlin J. Muñoz G.
ii
AGRADECIMIENTOS
A Dios todopoderoso, por haberme dado sabiduría y fortaleza para alcanzar
éste logro.
A la UNEG, la Luz de Guayana, mi alma mater, por brindarme la oportunidad
de ser una profesional y permitirme ser mejor persona.
A mis compañeros y amigos, Josibel Flores, Luisana Rondón y Nicolás
Piñero, mi grupo de estudio durante la carrera, que me brindaron esa mano amiga y
siempre estuvieron allí; junto a ustedes he pasado cinco años llenos de vivencias y
experiencias que nunca podré olvidar. Los quiero.
Al Ingeniero Alcides Bolívar, quien ha sido de gran apoyo, una persona que
me brindó su ayuda incondicional, que me supo escuchar y dar aliento en momentos
difíciles.
A los Ingenieros Alejandro Marcus y Andrés Caniumilla por haber aceptado
ser mis tutores de pasantías a nivel de tecnólogo y profesional.
A las Ingenieros Miriam Polo, Carmen García y a la Licenciada Nielisbeth
Assante quienes durante mi paso por EDELCA fueron de gran ayuda para cumplir
con mi trabajo.
A los Ingenieros Rafael Rodríguez, Maryorie Campos, y a todo mi equipo de
trabajo (Rubén, Rafa, Pedro, Mariela, Mariana y Miguel) con los cuales compartí
durante mi paso por CADAFE, que me permitieron aprender de ellos y que además
me ofrecieron su amistad.
A CORPOELEC, y sus filiales EDELCA y CADAFE, por brindarme la
oportunidad de realizar mi dos pasantías.
Muchas Gracias
iii
INDICE GENERAL
pp.
INDICE GENERAL……………………………………………………………………. iii
LISTA DE FIGURAS………………………………………………………………….. iv
LISTA DE TABLAS……………………………………………………………………. vii
INTRODUCCION……………………………………………………………………… 10
CAPITULO I: FORMULACION DEL PROBLEMA…………………………………. 12
Planteamiento del Problema……………………………………………………… 12
Justificación………………………………………………………………………… 13
Alcance……………………………………………………………………………… 14
Objetivo General…………………………………………………………………… 14
Objetivos Específicos……………………………………………………………… 14
CAPITULO II: MARCO TEORICO…………………………………………………... 15
Antecedentes de la Investigación………………………………………………... 15
Referidos a la Empresa……………………………………………………… 15
Referidos a la Investigación…………………………………………………. 23
Bases Teóricas…………………………………………………………………….. 24
Bases Legales……………………………………………………………………… 32
Herramientas Utilizadas…………………………………………………………… 33
CAPITULO III: MARCO METODOLOGICO………………………………………... 42
Tipo de Estudio…………………………………………………………………….. 42
Objeto de Estudio………………………………………………………………….. 44
Población y Muestra……………………………………………………………….. 44
Técnicas Aplicadas para la Recolección de Datos…………………………….. 45
La Observación……………………………………………………………….. 45
iv
La Entrevista………………………………………………………………….. 46
Revisión Documental………………………………………………………… 46
Problema a Resolver………………………………………….…………………… 46
Área de Interés de la Investigación……………………………………………… 46
CAPITULO IV: RESULTADOS………………………………………………………. 48
Metodología de Desarrollo de Sistemas………………………………………… 48
Descripción de Actividades Realizadas…………………………………………. 48
Cronograma de Actividades……………………………………………………… 50
Estudio de Factibilidad…………………………………………………………….. 51
Factibilidad Operativa………………………………………………………… 51
Factibilidad Técnica………………………………………...………………… 51
Descripción Conceptual de los Procesos del Sistema………………………… 52
Requerimientos de Información………………………………………………….. 53
Casos de Usos Detallados………………………………………………………... 54
Diagramas de Actividades………………………………………………………… 63
Tabla Visual de Contenidos…………………………………………………….… 84
Modelo Entidad Relación……………………………………………….………… 90
Diccionario de Datos………………………………………………………………. 91
CONCLUSIONES……………………………………………………………………... 98
RECOMENDACIONES……………………………………………………………….. 100
REFERENCIAS……………………………………………………………………….. 101
ANEXOS……………………………………………………………………………….. 103
A. Manual de Usuarios………………………………………………………….. 104
B. Decreto Presidencial 3.390………………………………………..………... 121
v
LISTA DE FIGURAS
Figura pp.
1 Esquema de regionalización aprobado (RJD 190 del 08 – 06-2006)…………. 18
2 Formato de Hoja de Cálculo…………………………………………………….… 23
3 Componentes de un Sistema de Información…………………………………… 24
4 Diagrama de Roles…………………………………………………….…………… 54
5 Diagrama General…………………………………………………….……………. 55
6 Diagrama de Gestión de Solicitudes……………………………………………... 58
7 Diagrama de Gestión de Usuarios…………………………….………………….. 59
8 Diagrama de Gestión de Técnicos………………………….…………………….. 60
9 Diagrama de Gestión de Actividades………………………..………………….… 61
10 Diagrama de Gestión de Reportes………………………….…………………… 62
11 Actividad Agregar Solicitudes……………………………………………..……... 63
12 Actividad Modificar Solicitudes……………………………………………..……. 64
13 Actividad Eliminar Solicitudes……………………………………..……………... 65
14 Actividad Agregar y Modificar Usuarios…………………………………..…….. 66
15 Actividad Agregar Unidad…………………………………………………..……. 67
16 Actividad Modificar Unidad..…………………………………………………...… 68
17 Actividad Eliminar Unidad………………………………………………………… 69
18 Actividad Agregar Ubicación………………………………………………..….… 70
19 Actividad Modificar Ubicación………………………………………………..…... 70
20 Actividad Eliminar Ubicación………………………………………………..….… 71
21 Actividad Agregar y Modificar Técnicos…………………………………..…….. 72
22 Actividad Modificar Estatus Técnicos……………………………………..……..
73
vi
23 Actividad Agregar Sistemas…..……………………………………………….…. 74
24 Actividad Modificar Sistemas……………..……………………………………… 75
25 Actividad Eliminar Sistemas………………………………………..………….…. 76
26 Actividad Agregar Subsistemas………………………………..………………… 77
27 Actividad Modificar Subsistemas……………………………...……………….… 78
28 Actividad Eliminar Subsistemas……………………………..…………………… 79
29 Actividad Agregar Actividad…………………………………..……………….…. 80
30 Actividad Modificar Actividad………………..…………………………………… 81
31 Actividad Eliminar Actividad…..……………………………………………….…. 82
32 Actividad Visualizar Reportes……………..……………………………………... 83
33 Tabla Visual General……..…………………………………………….…………. 84
34 Tabla Visual – Gestión de Solicitudes…...……………………………………… 84
35 Tabla Visual – Gestión de Usuarios – Control de Usuarios...………………… 85
36 Tabla Visual – Gestión de Usuarios – Control de Unidad………………..…… 85
37 Tabla Visual – Gestión de Usuarios – Control de Ubicación……...……..…… 86
38 Tabla Visual – Gestión de Técnicos – Control de Técnicos…………..……… 86
39 Tabla Visual – Gestión de Técnicos – Estatus Técnicos…..…………………. 87
40 Tabla Visual – Gestión de Actividades – Control de Sistemas…..…………… 87
41 Tabla Visual – Gestión de Actividades – Control de Subsistemas..…………. 88
42 Tabla Visual – Gestión de Actividades – Control de Actividades.................... 88
43 Tabla Visual – Gestión de Reportes………………………………………….... 89
44 Modelo Entidad Relación………………………………………………………..
90
vii
LISTA DE TABLAS
Tabla pp.
1 Esquema de regionalización. Muestran las regiones y los estados que la conforman estructura establecida por CORPOELEC CADAFE…………………
18
2 Cronograma de Actividades……………………………………………………….. 51
3 Diccionario de Datos – Tabla usuarios…………………………………………… 91
4 Diccionario de Datos – Claves foráneas tabla usuarios………...……………… 91
5 Diccionario de Datos – Tabla unidad……………………………………………... 92
6 Diccionario de Datos – Claves foráneas tabla unidad………………………….. 92
7 Diccionario de Datos – Tabla ubicación………………………………………….. 92
8 Diccionario de Datos – Tabla sistema……………………………………………. 93
9 Diccionario de Datos – Tabla subsistemas……………………………….……… 93
10 Diccionario de Datos – Claves foráneas tabla subsistema…..……..………… 93
11 Diccionario de Datos – Tabla soluciones…………………………………..…… 94
12 Diccionario de Datos – Claves foráneas tabla soluciones…………………..... 94
13 Diccionario de Datos – Tabla solicitud…………………………………..……… 95
14 Diccionario de Datos – Claves foráneas tabla solicitud…………………..…… 95
15 Diccionario de Datos – Tabla soluciones_solicitud………………………..…... 96
16 Diccionario de Datos – Claves foráneas tabla soluciones_solicitud…………. 96
17 Diccionario de Datos – Tabla cola……………………………………………….. 97
18 Diccionario de Datos – Claves foráneas tabla cola……...…………………….. 97
10
INTRODUCCION
En la actualidad las organizaciones han mostrado más interés en el uso de
las herramientas que brinda la tecnología debido a que ésta avanza a grandes
pasos, lo que ha permitido que las mismas realicen sus operaciones de manera más
eficiente, asegurando su subsistencia en un entorno más competitivo y cambiante.
Así mismo, el manejo de la información de manera automatizada es fundamental
para su desarrollo y buena gestión, tanto a nivel gerencial como nivel operativo e
intermedios. Tener la información rápida, integra y precisa es un valor muy
importante para la organización, por ende se busca automatizar todos aquellos
procesos que puedan mejorarse con la ayuda de un sistema de información para
lograr un mayor grado de eficiencia.
El desarrollo de sistemas dentro de una organización, es algo que debe
estar muy relacionado con los procesos y necesidades de la misma, ya que para
hacerse las mejoras deben conocerse las deficiencias, y saber en qué parte del
proceso se presentan. Este proceso es complejo, ya que se debe partir de una fase
de análisis del problema o situación actual, así también del estudio del sistema
anterior, si existe, para comprender sus debilidades y luego entrar en la fase de
diseño del sistema donde se comienza a modelar el mismo. Ya hecho el diseño,
comienza la codificación y desarrollo para luego entrar en la fase de prueba y
corrección de errores, y por último implantar el sistema.
Con la finalidad de que los empleados mejoren su desempeño laboral
gracias a los beneficios que ofrecen los diferentes sistemas informáticos, algunas
organizaciones han optado por implantar estas soluciones y una de ellas es La
Corporación Eléctrica Nacional (CORPOELEC), la cual siempre a la vanguardia y en
búsqueda del mejoramiento continuo de sus procesos ha invertido para realizar la
automatización de los mismos.
Esta empresa se encarga de suministrar servicio eléctrico de calidad a los
usuarios, llevar la administración y la operación de las empresas de electricidad
11
dependientes del Estado, en una gestión que garantice ingresos suficientes,
necesarios a la sostenibilidad financiera de la organización. La Gerencia de
Automatización Tecnologías de la Información y Telecomunicaciones (ATIT) se
encarga de prestar los servicios de asistencia técnica y soluciones de calidad a los
usuarios de la Compañía Anónima de Fomento Eléctrico (CADAFE) Zona Bolívar,
con el fin de garantizar la estabilidad y continuidad operativa, con un personal
comprometido, honesto, eficiente, e identificado con dicha empresa.
El presente trabajo de investigación tiene como propósito realizar el
desarrollo de un sistema de control de gestión que permitirá la automatización de los
procesos de administración de solicitudes y a partir de ello se podrán generar los
indicadores de gestión correspondientes a la unidad, necesarios para la elaboración
de los informes de gestión mensuales y anuales.
El presente trabajo quedó estructurado en cuatro (04) capítulos:
El Capítulo I donde se inicia con el planteamiento del problema, el desarrollo
del objetivo general y los objetivos específicos, la justificación de la investigación, el
alcance del sistema de información propuesto y las limitaciones del mismo.
El Capítulo II presenta el marco teórico, donde se especifican las bases
teóricas que le dan sustento a la investigación, tales como los antecedentes de la
investigación y lo referido a la empresa.
El Capítulo III donde se realiza una descripción de la metodología con la que
se va resolver el problema, el área objeto de estudio, el tipo de estudio, el proyecto
factible, el procedimiento de recolección de datos.
El Capítulo IV que presenta el resultado de la investigación, y finalmente las
conclusiones, recomendaciones y anexos.
12
CAPITULO I
FORMULACIÓN DEL PROBLEMA
Planteamiento del Problema.
La Corporación Eléctrica Nacional (CORPOELEC) tiene como propósito
desarrollar, proporcionar y garantizar un servicio eléctrico de calidad, eficiente,
confiable, con sentido social y sostenibilidad en todo el territorio nacional, a través
de la utilización de tecnología de vanguardia en la ejecución de los procesos de
generación, transmisión, distribución y comercialización del sistema eléctrico
nacional, integrando a la comunidad organizada, proveedores y trabajadores
calificados, motivados y comprometidos con valores éticos socialistas, para
contribuir con el desarrollo político, social y económico del país.
Así mismo, la Coordinación de Informática, adscrita a la Gerencia de
Automatización, Tecnologías de la Información y Telecomunicaciones (ATIT) Región
Bolívar, sirve de apoyo a la organización en el soporte de los procesos medulares y
es responsable de llevar a cabo la administración de solicitudes, mediante la
atención de fallas y requerimientos en el área de Informática y Telecomunicaciones
en la Zona Bolívar. Cabe destacar que dicha Unidad atiende un total de quince
oficinas comerciales, cinco distritos técnicos, dos pares de recaudación y tres
edificios administrativos, distribuidos por todo el Estado Bolívar.
En la actualidad, la Coordinación de Informática no cuenta con un
mecanismo eficiente que permita llevar de manera adecuada la carga y el control de
las solicitudes de asistencia técnica, y así mismo el seguimiento continuo de los
indicadores de gestión que se generan a partir de las soluciones de calidad que
ofrece la Unidad.
Unos de los inconvenientes mayores, se presenta cuando existen gran
cantidad de solicitudes, debido a que las mismas, se controlan a través de un
formato de hoja de cálculo de Microsoft Excel, lo que resulta poco eficiente y
efectivo, ya que no se puede llevar con exactitud la información de cada una de las
13
actividades que se realizan, y así mismo los cálculos respectivos para poder obtener
los indicadores de gestión, necesarios para efectuar los informes mensuales y
anuales de la coordinación. Además de que no se garantiza la seguridad de la
información y no existe un registro de los datos permanente en el tiempo.
Si éste problema continua, cada vez será más difícil el manejo de la
información, así como también la seguridad de los datos, debido a que la hoja de
cálculo se puede dañar. Además de que los trabajadores usan un tiempo
considerable de su labor diaria actualizando dicha hoja de cálculo, el cual podrían
usar para realizar y/o atender otras actividades.
Debido a que actualmente la Coordinación de Informática, no cuenta con un
sistema de información que permita cargar y controlar las solicitudes e indicadores
de gestión de forma automatizada, se propuso un sistema de información bajo
ambiente web que permitirá la administración de las solicitudes y a partir de ello,
obtener indicadores de gestión centralizados.
Justificación.
Este proyecto, nace de la necesidad de realizar el seguimiento y control
adecuado de cada una de las solicitudes de asistencia técnica que se llevan a cabo,
de forma tal que se puedan atender a tiempo y así contribuir a la efectividad en la
solución de las mismas, garantizando la seguridad de los datos y la obtención de las
estadísticas respectivas para generar los informes de gestión.
Teniendo en cuenta la problemática planteada, se ofrece como solución el
desarrollo de un sistema de información bajo ambiente web, el cual permitirá la
administración de las solicitudes, necesarias para llevar un eficiente control de
gestión en la Gerencia de ATIT y de esta forma contribuir en el mejoramiento
continuo de sus procesos, los cuales son muy importantes porque sirven de apoyo
en actividades medulares de la Corporación.
14
Alcance.
El desarrollo del Sistema de Información a realizarse en la empresa
CORPOELEC que va a permitir la automatización de los procesos de administración
de solicitudes, se va a ejecutar en un lapso de tiempo de16 semanas. Así mismo, el
alcance de ésta herramienta comprenderá:
• Análisis del proceso de carga y control de solicitudes.
• Definición de requerimientos.
• Elaboración del Diseño del Sistema.
• Desarrollo de la Aplicación.
Objetivo General.
Desarrollar un Sistema de Información bajo Ambiente Web para el Control de Gestión en la Coordinación de Informática de CORPOELEC Región Bolívar.
Objetivos Específicos.
• Analizar la situación actual del control de solicitudes de asistencia
técnica administradas en la Coordinación de Informática.
• Definir los requerimientos funcionales y no funcionales.
• Desarrollar el Sistema de Información.
• Instalar el Sistema de Información en la Coordinación de Informática.
15
CAPÍTULO II
MARCO TEORICO
Antecedentes de la Investigación.
Referidos a la Empresa.
En el año 1946, el Ejecutivo Nacional creó la Corporación Venezolana de
Fomento, como Instituto Autónomo adscrito al Ministerio de Fomento y le asignó
como parte de su patrimonio y calidad de aporte, las inversiones del Estado en las
instalaciones eléctricas existentes en el país.
En el año 1951, con la colaboración de especialistas venezolanos y
extranjeros, se formula el primer Plan Nacional de Electrificación y la Corporación
Venezolana de Fomento es la encargada de su ejecución.
El 27 de octubre de 1958 se constituyó la Compañía Anónima de
Administración y Fomento Eléctrico (CADAFE), como empresa de servicio eléctrico,
la cual fue fundada de acuerdo con la Resolución del Ministerio de Fomento Nº 3218
de fecha 25 de agosto de 1958. La compañía inició sus actividades con quince (15)
empresas eléctricas que eran subsidiarias de la Corporación Venezolana de
Fomento.
En junio de 1959 se acordó la fusión de esas empresas con CADAFE,
quedando ésta como la Empresa de Electricidad del Estado, encargada de crear
uniformidad en los criterios técnico - administrativos que permitiese la formulación
de programas eléctricos en una forma integral.
En el año 1990 de acuerdo con la política de reforma del Estado, el Ejecutivo
decide, en la reunión Nº 26 del Comité Operativo Sectorial de Asuntos de Política
Económica y Social realizada el 22-01-90, la creación de las Empresas Regionales
de Distribución y Comercialización, hecho aprobado por la Comisión Permanente de
Finanzas de la Cámara del Senado, según Oficio Nº 23 de fecha 11-02-93. En
16
consecuencia fueron creadas cuatro (4) Empresas Regionales de Distribución y
Comercialización a saber:
· Compañía Anónima Electricidad de Los Andes – CADELA, que prestará
servicio a los estados Táchira, Mérida, Trujillo y Barinas.
· Electricidad del Centro C.A. – ELECENTRO, que prestará servicio a los estados
Miranda, Guárico, Aragua, Apure y Amazonas.
· Electricidad de Occidente C.A. – ELEOCCIDENTE, que prestará servicio a los
estados Falcón, Portuguesa, Cojedes., Yaracuy, Carabobo y Lara
· Electricidad de Oriente C.A. – ELEORIENTE, que prestará servicio en los
estados, Anzoátegui, Sucre, Nueva Esparta, Bolívar, Monagas y Delta Amacuro.
Paralelamente a esto y continuando con la descentralización, se crea
DESURCA- Desarrollo Uribante Caparo mediante autorización del Presidente de la
República otorgada en la reunión Nº 26 del Comité Operativo Sectorial de Asuntos
de Política Económica y Social de fecha 22/01/90; debidamente avaladas por las
Comisiones.
Permanentes de Finanzas de la Cámara del Senado según Oficio S/N de
fecha 10/08/93 y por la Comisión de Finanzas de la Cámara de Diputados del
Congreso de la República según oficio Nº 225 de fecha 02/08/93. Esta empresa se
constituye como Filial de CADAFE para la ejecución del Plan Maestro que
continuará el desarrollo del proyecto Uribante - Caparo, de acuerdo a las políticas
previstas por el Ejecutivo Nacional.
En marzo de 1997, la Junta Directiva de CADAFE y el Directorio del Fondo
de Inversiones de Venezuela aprobaron el Plan de Reestructuración y Privatización
del Sector Eléctrico. En tal sentido, se inició el Proceso de Privatización del Sistema
Eléctrico del Estado Nueva Esparta (SENECA) el cual culminó satisfactoriamente en
el mes de septiembre de 1997.
17
Paralelamente, en julio de 1997, se culminó la transferencia de los activos
ubicados en el estado Lara propiedad de CADAFE y Eleoccidente a la Empresa
ENELBAR.
En Octubre 1997, la Junta Directiva de CADAFE aprobó el proceso de
reestructuración de sus Empresas Filiales, a través del cual le fueron transferidos a
éstas el Sistema de Transmisión en 115 KV y las plantas de Generación con
capacidad menor a 20 MW.
En marzo 1998 se publicó el Decreto Nº 2457 emanado del Ejecutivo
Nacional con el cual se inició el proceso de privatización del Sistema Eléctrico de los
estados Monagas y Delta Amacuro. En consecuencia, el 24 de septiembre CADAFE
y ELEORIENTE constituyeron la C.A. Sistema Eléctrico de Monagas y Delta
Amacuro (SEMDA).
En diciembre de 1998, por instrucciones del Fondo de Inversiones de
Venezuela, quedó suspendido el proceso de privatización de SEMDA, por lo que se
constituyó como una empresa filial de Distribución.
En el año 2006, la Junta Directiva de CADAFE aprobó mediante RJD Nº 133
de fecha 27.04.2006 y 2006-09-17 de fecha 17.08.2006, la Estructura Organizativa
de primer nivel de la Empresa y la nueva Regionalización, cuyo pilar fundamental es
la directriz de Reunificación de CADAFE y sus Empresas Filiales, para lo cual se
requiere crear un esquema de Regiones que permita mejorar la calidad en la
prestación del servicio eléctrico, el cual quedó conformado por nueve (9) Regiones,
como se describe a continuación:
18
REGIÓN CONFORMADA POR:
1 SUCRE - ANZOÁTEGUI
2 MONAGAS – DELTA AMACURO
3 GUÁRICO – APURE
4 ARAGUA – MIRANDA
5 PORTUGUESA – BARINAS - COJEDES
6 CARABOBO - YARACUY
7 TACHIRA – MERIDA – TRUJILLO
8 BOLIVAR - AMAZONAS
9 FALCON
Tabla 1. Esquema de regionalización. Muestran las regiones y los estados que la conforman estructura establecida por CORPOELEC CADAFE. Fuente: www.cadafe.com.ve
Figura 1. Esquema de regionalización aprobado (RJD 190 del 08 – 06-2006) Fuente: www.cadafe.com.ve
El 2 de mayo de 2007, se publicó del Decreto Nº 5.330, con rango, valor y
fuerza de Ley Orgánica de Reorganización del Sector Eléctrico, en el cual se crea la
Sociedad Anónima Corporación Eléctrica Nacional, S.A. (CORPOELEC), adscrita al
Ministerio del Poder Popular para la Energía y Petróleo, “como una empresa estatal
encargada de la realización de las actividades de generación, transmisión,
19
distribución y comercialización de potencia y energía eléctrica”. Por lo que dispone
que seis empresas (ENELVEN, ENAGEN, CADAFE, EDELCA, ENELCO Y
ENELBAR), todas del sector eléctrico, así como “todas las empresas filiales o
afiliadas a las mismas, quedan fusionadas en forma inmediata” a CORPOELEC,
por lo que “deberán transferir todos los activos y pasivos que poseen” a esta última,
la cual “será la sucesora universal de los derechos y obligaciones de aquellas”.
La fecha límite para la desaparición de las 14 empresas regionales del
sector y la creación de una empresa nacional -la Corporación Eléctrica
Nacional (Corpoelec)- era el 31 de julio de 2010 y ahora se prorrogó hasta el 31
de diciembre de 2011.
El 8 de octubre de 2007, se aprobó mediante Gaceta Oficial Nº 38.785 la
reorganización territorial para el ejercicio de la actividad de distribución de potencia
y energía eléctrica, se crean las siguientes regiones operativas:
� Región Noroeste que comprende los Estados (Zulia, Falcón, Lara y
Yaracuy).
� ·Región Norcentral que comprende los Estados (Carabobo, Aragua,
Miranda, Vargas y Distrito Capital).
� Región Oriental que comprende los Estados (Anzoátegui, Monagas,
Sucre, Nueva Esparta y Delta Amacuro).
� Región Central que comprende los Estados (Guárico, Cojedes,
Portuguesa, Barinas y Apure).
� Región Andina que comprende los Estados (Mérida, Trujillo y Táchira).
� Región Sur que comprende los Estados (Bolívar y Amazonas).
De acuerdo a la reorganización territorial aprobada en la Gaceta Oficial Nº
38.785, CADAFE es responsable de la administración de estas Regiones, sin
embargo se instruye a la Compañía Anónima Energía Eléctrica de Barquisimeto
(ENELBAR) para que opere y mantenga las instalaciones eléctricas de distribución
20
en los Estados Yaracuy de la Región Noroeste y en Carabobo de la Región
Norcentral.
La Compañía Anónima Energía Eléctrica de Venezuela (ENELVEN) debe
operar y mantener las instalaciones eléctricas de distribución en el Estado Falcón
de la Región Noroeste.
La Compañía Anónima La Electricidad de Caracas (ELECAR) para que
opere y mantenga las instalaciones eléctricas de distribución en los Estados Aragua
y Miranda de la Región Norcentral, y en el Estado Nueva Esparta de la Región
Oriental.
Objetivos de la Empresa.
El objeto de la Compañía es la Generación, Transmisión, Distribución y la
comercialización de energía eléctrica, a los fines de cumplir con las exigencias del
proceso de desarrollo eléctrico en el país, reafirmando su compromiso social.
Objetivos Específicos.
• Prestar el servicio eléctrico, tanto en las zonas urbanas como rurales.
• Garantizar la oferta de energía eléctrica que requiere el desarrollo
económico y social del país, mediante la prestación de un servicio
eficiente y confiable, que permita suministrar a cada tipo de consumidor
la cantidad y calidad de energía eléctrica que demande, a un mínimo
costo.
• Suministrar energía eléctrica al mayor número de población.
• Alcanzar niveles satisfactorios de seguridad y calidad en el servicio
prestado.
• Utilizar los recursos naturales del país en forma racional.
• Adecuar la organización de la Empresa a los fines de ir mejorando la
productividad.
21
Filosofía de Gestión.
Misión.
Desarrollar, proporcionar y garantizar un servicio eléctrico de calidad,
eficiente, confiable, con sentido social y sostenibilidad en todo el territorio nacional,
a través de la utilización de tecnología de vanguardia en la ejecución de los
procesos de generación, transmisión, distribución y comercialización del sistema
eléctrico nacional, integrando a la comunidad organizada, proveedores y
trabajadores calificados, motivados y comprometidos con valores éticos socialistas,
para contribuir con el desarrollo político, social y económico del país.
Visión.
Ser una Corporación con ética y carácter socialista, modelo en la prestación
de servicio público, garante del suministro de energía eléctrica con eficiencia,
confiabilidad y sostenibilidad financiera. Con un talento humano capacitado, que
promueve la participación de las comunidades organizadas en la gestión de la
Corporación, en concordancia con las políticas del Estado para apalancar el
desarrollo y el progreso del país, asegurando con ello calidad de vida para todo el
pueblo venezolano.
Valores Corporativos.
• Ética Socialista.
• Responsabilidad.
• Autocrítica.
• Respeto.
• Honestidad.
• Eficiencia.
• Compromiso.
22
Área donde se realizó la pasantía.
El área donde se desarrolló la pasantía fue en la Gerencia de
Automatización, Tecnologías de la Información y Telecomunicaciones (ATIT) Región
Bolívar.
Propósito general de La Gerencia de Automatización, Tecnologías de la
Información y Telecomunicaciones (ATIT).
La Gerencia de Automatización Tecnologías de la Información y
Telecomunicaciones (ATIT), depende en línea de mando directo de la
Vicepresidencia Ejecutiva de ATIT de CADAFE y según la distribución propuesta se
encuentra estructurada por un equipo de apoyo a la gestión, un equipo de
continuidad operativa informática Bolívar, un equipo de continuidad operativa de
telecomunicaciones Bolívar, los cuales se encargan de ejecutar los procesos
internos de la gerencia y dar soporte a los procesos medulares de CADAFE,
mediante la atención de fallas y requerimientos en área de Informática y
Telecomunicaciones en la Zona Bolívar.
Misión.
Prestar los servicios de Automatización, Tecnologías de la Información y
Telecomunicaciones a los usuarios de CADAFE Zona Bolívar, mediante la
asistencia técnica y soluciones de calidad, eficiente, efectivo, confiable y oportuno,
con el fin de garantizar la estabilidad y continuidad operativa de CADAFE, con un
personal comprometido, honesto, eficiente, e identificado con nuestra empresa.
Visión.
Ser una Gerencia estratégica y líder en el área de tecnología, que
proporcione un servicio de Automatización Tecnologías de la Información y
Telecomunicaciones óptimo, de calidad, eficiente e innovador mediante una
Filosofía de la mejora continua que garantice la continuidad operativa de la
23
Empresa, con un personal altamente calificado donde prevalezca la honestidad, el
trabajo en equipo, el respeto y la seguridad en el trabajo
Referidos a la Investigación.
Para la Coordinación de Informática, adscrita a la Gerencia ATIT, Región
Bolívar, se elaboró un formato de hoja de cálculo de Microsoft Excel, con la cual se
lleva a cabo el manejo de solicitudes y el control de los indicadores de gestión. El
mismo se muestra a continuación:
Figura 2. Formato de Hoja de Cálculo. Fuente: Gerencia de ATIT, Coordinación de Informática
En tal sentido, la Coordinación tiene nuevos requerimientos, por lo que se
decide implantar el sistema propuesto. Así mismo, la hoja del cálculo antes
mencionada serviría de apoyo para el levantamiento de información del Sistema de
Control de Gestión (SIASA).
24
Bases Teóricas.
Sistema de Información.
Kendall, et al (1991) expresan los sistemas de información consisten en
procedimientos y reglas establecidas para entregar información a los miembros de
la organización.
Un sistema de información automatizado o basado en computadoras, es la
integración de hardware, software, personas, procedimientos y datos. Todos estos
elementos se conjugan, trabajando juntos para proporcionar información básica para
la conducción del Departamento.
Atributos y componentes de un sistema de información.
Según Kendall, et al (1991) expresa: Un sistema de información posee los
siguientes atributos: Confiable, Oportuno, Disponible, Fácil de usar, Compartido,
Flexible y Colectivo.
Está compuesto por cincos elementos como lo indica la siguiente figura:
Figura 3. Componentes de un Sistema de Información. Fuente: Kendall y Kendall (1991)
Hardware
Comunicaciones
REDES Recursos Humanos
Software
Data /Información
25
Lenguaje unificado del modelado (UML)
Booch (1999) expresa UML “Es un lenguaje de modelado que se usa para
entender, diseñar, configurar, mantener y controlar la información sobre los sistemas
a construir. UML capta la información sobre la estructura estática y el
comportamiento dinámico de un sistema”.
Diagramas UML.
Booch (1999) define, “Para la construcción de modelos, hay que concentrar
la atención en los detalles relevantes mientras se ignoran los demás, por lo cual,
con un único modelo no se tiene suficiente información.”
Varios modelos aportan diferentes vistas de un sistema, los cuales, ayudan a
comprenderlo desde diferentes frentes; así, UML recomienda el uso de nueve
diagramas, para representar las distintas vistas de un sistema.
Tipos de UML.
� Diagrama de Caso de Uso.
Es una técnica para capturar información, de cómo un sistema o negocio
trabaja, o de cómo desea que trabaje. No pertenece estrictamente al enfoque
orientado a objeto. Entre sus aspectos más resaltantes se tienen:
a) Describen bajo la forma de acciones y reacciones el comportamiento de un
sistema desde el punto de vista del usuario.
b) Permiten definir los límites del sistema y las relaciones entre el sistema y el
entorno.
c) Son descripciones de la funcionalidad del sistema, independientes de la
implementación
26
d) Particionan el conjunto de necesidades atendiendo a la categoría de usuarios que
participan en el mismo y e) Están basados en el lenguaje natural, es decir, es
accesible por los usuarios.
Los Casos de Uso se determinan observando y precisando, actor por actor,
las secuencias de iteración y los escenarios, desde el punto de vista del usuario.
Los casos de uso intervienen durante todo el ciclo de vida, es decir, el proceso de
desarrollo está dirigido por los casos de uso. (Bennett, 2007)
� Tipos de relación de los casos de uso.
Comunicación: es una relación sencilla, para combinar elementos en el diagrama.
Inclusión (<<include>>): una instancia del caso de uso origen incluye el
comportamiento descrito por el caso de uso destino.
Extensión (<<extend>>): el caso de uso origen extiende el comportamiento del caso
de uso destino.
Herencia: el caso de uso origen hereda la especificación del caso de uso destino y
posiblemente la modifica y/o amplia. (Bennett, 2007)
� Diagrama de Actividad.
Un diagrama de Actividad demuestra la serie de actividades que deben ser
realizadas en un uso-caso, así como las distintas rutas que pueden irse
desencadenando en el uso-caso.
Es importante recalcar que aunque un diagrama de actividad es muy
similar en definición a un diagrama de flujo (típicamente asociado en el diseño de
Software), estos no son lo mismo. Un diagrama de actividad es utilizado en
conjunción de un diagrama uso-caso para auxiliar a los miembros del equipo de
desarrollo a entender como es utilizado el sistema y cómo reacciona en
determinados eventos. Lo anterior, en contraste con un diagrama de flujo que
ayuda a un programador a desarrollar código a través de una descripción lógica
27
de un proceso. Se pudiera considerar que un diagrama de actividad describe el
problema, mientras un diagrama de flujo describe la solución.
En la siguiente sección se describen los diversos elementos que
componen un diagrama de Actividad.
Composición:
• Inicio: El inicio de un diagrama de actividad es representado por un círculo
de color negro sólido.
• Actividad: Una actividad representa la acción que será realizada por el
sistema la cual es representada dentro de un ovalo.
• Transición: Una transición ocurre cuando se lleva a cabo el cambio de una
actividad a otra, la transición es representada simplemente por una linea con
una flecha en su terminación para indicar dirección.
• Ramificación (Branch): Una ramificación ocurre cuando existe la
posibilidad que ocurra más de una transición (resultado) al terminar
determinada actividad. Este elemento es representado a través de un
rombo.
• Unión (Merge): Una unión ocurre al fusionar dos o más transiciones en una
sola transición o actividad. Éste elemento también es representado a través
de un rombo.
• Expresiones Resguardadas (GuardExpressions): Una expresión
resguardada es utilizada para indicar una descripción explicita acerca de
una transición. Este tipo de expresión es representada mediante corchetes
([...] y es colocada sobre la linea de transición.
• Fork : Un fork representa una necesidad de ramificar una transición en más
de una posibilidad. Aunque similar a una ramificación (Branch) la diferencia
radica en que un fork representa más de una ramificación obligada, esto es,
28
la actividad debe proceder por ambos o más caminos, mientras que una
ramificación (Branch) representa una transición u otra para la actividad
(como una condicional). Un fork es representado por una linea negra solida,
perpendicular a las líneas de transición.
• Join: Una join ocurre al fusionar dos o más transiciones provenientes de un
fork, y es empleado para dichas transiciones en una sola, tal y como ocurría
antes de un fork .Un fork es representado por una línea negra solida,
perpendicular a las líneas de transición.
• Fin: El fin de un diagrama de actividad es representado por un círculo, con
otro círculo concéntrico de color negro sólido.
• Canales (Swimlanes): En determinadas ocasiones ocurre que un
diagrama de actividad se expanda a lo largo de más de un entidad o actor,
cuando esto ocurre el diagrama de actividad es particionada en canales
(swimlines), donde cada canal representa la entidad o actor que está
llevando a cabo la actividad. (Bennett, 2007)
� Diagrama de Actividades.
Los diagramas de actividades son básicamente diagramas de flujo
adornados, que guardan mucha similitud con los diagramas de estados. Mientras
que los diagramas de estados centran su atención en el proceso que está llevando a
cabo un objeto, los diagramas de actividades muestran como las actividades fluyen
y las dependencias entre ellas.
Los diagramas de actividades pueden dividirse en “calles” que determinan
qué objeto es responsable de qué actividad. Las actividades vienen unidas por
transiciones, que pueden separarse en ramas en función del resultado de una
condición expresada entre corchetes. Cada rama muestra la condición que debe ser
satisfecha para que el flujo opte por ese camino. Igualmente, las transiciones se
pueden bifurcarse en dos o más actividades paralelas. (Bennett, 2007)
29
Bases de datos.
La información es un recurso para el desarrollo de las actividades, por esto
es necesario lograr una gestión de la misma a partir de la administración de bases
de datos para interpretarla y sacar provecho. Esta administración debe proveer
resultados que satisfagan las necesidades de información de los usuarios,
facilitando la obtención de datos para la toma de decisiones. Para esto es necesario
comprender el concepto de bases de datos.
Una base de datos (o banco de datos) es un conjunto de datos que
pertenecen al mismo contexto almacenados sistemáticamente para su posterior uso.
En este sentido, una biblioteca puede considerarse una base de datos compuesta
en su mayoría por documentos y textos impresos en papel e indexados para su
consulta. En la actualidad, y debido al desarrollo tecnológico de campos como la
informática y la electrónica, la mayoría de las bases de datos tienen formato
electrónico, que ofrece un amplio rango de soluciones al problema de almacenar
datos.
Un sistema manejador de base de datos es un software para crear y
mantener bases de datos y permite desarrollar aplicaciones individuales de
negocios para extraer los datos que se necesitan. Se componen de lenguaje de
definición de datos (especifica el contenido y estructura de datos), lenguaje de
manejo de datos (permite realizar consultas) y el diccionario de datos (permite
almacenar y organizar la información concerniente con los datos). (Silberschatz,
2002)
Diagrama Entidad-Relación.
“Los diagramas o modelos entidad-relación (a veces denominado por su
siglas, E-R "Entityrelationship") son una herramienta para el modelado de datos de
un sistema de información. Estos modelos expresan entidades relevantes para un
sistema de información, sus inter-relaciones y propiedades.”
30
El Modelo Entidad-Relación es un concepto de modelado para bases de
datos, propuesto por Peter Chen, mediante el cual se pretende 'visualizar' los
objetos que pertenecen a la Base de Datos como entidades (esto es similar al
modelo de Programación Orientada a Objetos) las cuales tienen unos atributos y se
vinculan mediante relaciones.
Es una representación lógica de la información. Mediante una serie de
procedimientos se puede pasar del modelo E-R a otros, como por ejemplo el modelo
relacional.
El modelado entidad-relación es una técnica para el modelado de datos
utilizando diagramas entidad relación. No es la única técnica pero sí la más
utilizada. Brevemente consiste en los siguientes pasos:
Se parte de una descripción textual del problema o sistema de información a
automatizar (los requisitos).
Se hace una lista de los sustantivos y verbos que aparecen.
Los sustantivos son posibles entidades o atributos.
Los verbos son posibles relaciones.
Analizando las frases se determina la cardinalidad de las relaciones y otros
detalles.
Se elabora el diagrama (o diagramas) entidad-relación.
Se completa el modelo con listas de atributos y una descripción de otras
restricciones que no se pueden reflejar en el diagrama.
Dado lo rudimentario de esta técnica se necesita cierto entrenamiento y experiencia
para lograr buenos modelos de datos. (Silberschatz, 2002)
31
Ciclo De Vida Clásico Del Desarrollo De Sistemas.
El método de ciclo de vida para el desarrollo de sistemas es el conjunto de
actividades que los analistas, diseñadores y usuarios realizan para desarrollar e
implantar un sistema de información. El método del ciclo de vida para el desarrollo
de sistemas consta de 6 fases:
1). Investigación Preliminar: La solicitud para recibir ayuda de un sistema de
información puede originarse por varias razones: sin importar cuales sean estas, el
proceso se inicia siempre con la petición de una persona.
2). Determinación de los requerimientos del sistema: El aspecto fundamental del
análisis de sistemas es comprender todas las facetas importantes de la parte de la
empresa que se encuentra bajo estudio. Los analistas, al trabajar con los empleados
y administradores, deben estudiar los procesos de una empresa para dar respuesta
a las siguientes preguntas clave:
• ¿Qué es lo que hace?
• ¿Cómo se hace?
• ¿Con que frecuencia se presenta?
• ¿Qué tan grande es el volumen de transacciones o decisiones?
• ¿Cuál es el grado de eficiencia con el que se efectúan las tareas?
• ¿Existe algún problema? ¿Qué tan serio es? ¿Cuál es la causa que lo
origina?
3). Diseño del sistema: El diseño de un sistema de información produce los detalles
que establecen la forma en la que el sistema cumplirá con los requerimientos
identificados durante la fase de análisis. Los especialistas en sistemas se refieren,
32
con frecuencia, a esta etapa como diseño lógico en contraste con la del desarrollo
del software, a la que denominan diseño físico.
4). Desarrollo del software: Los encargados de desarrollar software pueden instalar
software comprobando a terceros o escribir programas diseñados a la medida del
solicitante. La elección depende del costo de cada alternativa, del tiempo disponible
para escribir el software y de la disponibilidad de los programadores.
Por lo general, los programadores que trabajan en las grandes organizaciones
pertenecen a un grupo permanente de profesionales.
5). Prueba de sistemas: Durante la prueba de sistemas, el sistema se emplea de
manera experimental para asegurarse de que el software no tenga fallas, es decir,
que funciona de acuerdo con las especificaciones y en la forma en que los usuarios
esperan que lo haga.
Se alimentan como entradas conjunto de datos de prueba para su procesamiento y
después se examinan los resultados.
6). Implantación y evaluación: La implantación es el proceso de verificar e instalar
nuevo equipo, entrenar a los usuarios, instalar la aplicación y construir todos los
archivos de datos necesarios para utilizarla. Una vez instaladas, las aplicaciones se
emplean durante muchos años. Sin embargo, las organizaciones y los usuarios
cambian con el paso del tiempo, incluso el ambiente es diferente con el paso de las
semanas y los meses. (Kendall, 1991).
Bases Legales del Tema en Estudio.
Entre las bases legales que competen a la propuesta del sistema de
información se encuentran en el Decreto Nº 3.390, publicado en Gaceta Oficial No
38.095 de fecha 28 de Diciembre de 2004. El cual CORPOELEC por ser una
empresa del Estado toma en cuenta en el momento de trabajar con sistemas,
proyectos y servicios informáticos. (Ver anexo B).
33
Herramientas Utilizadas.
Xampp.
Es un servidor web multiplataforma constituido por un servidor HTTP
Apache, base de datos MySQL y los intérpretes para scripts de PHP y Perl. El
nombre proviene del acrónimo de X (para cualquiera de los diferentes sistemas
operativos), Apache, MySQL, PHP, Perl. El programa está liberado bajo la licencia
GNU y actúa como un servidor Web libre, fácil de usar y capaz de interpretar
páginas dinámicas. Neteraft (1995)
Apache.
El servidor HTTP Apache es un servidor de código abierto para plataformas
Unix (BSD, GNU/Linux, entre otros), Windows y otras, que implementa el protocolo
HTTP/1.1 (RFC 2616) y la noción de sitio virtual. Cuando comenzó su desarrollo en
1995 se basó inicialmente en código del popular NCSA HTTPd 1.3, pero más tarde
fue reescrito por completo. Su nombre se debe a que originalmente Apache
consistía solamente en un conjunto de parches a aplicar al servidor de NCSA. Era,
en inglés, a patchy server (un servidor parcheado).
El servidor Apache se desarrolla dentro del proyecto HTTP Server (httpd) de la
Apache SoftwareFoundation.
Apache presenta entre otras características mensajes de error altamente
configurables, bases de datos de autenticación y negociado de contenido, pero fue
criticado por la falta de una interfaz gráfica que ayude en su configuración. Neteraft
(1995)
34
PHP.
Es un lenguaje de programación de estilo clásico, es decir es un lenguaje de
programación con variables, sentencias condicionales, bucles, funciones, entre
otros. No es un lenguaje de marcas como podría ser HTML, XML, WML. Este más
cercano a JavaScript o a C, para aquellos que conocen estos lenguajes.
Puede ser utilizado en cualquiera de los principales sistemas operativos del
mercado, incluyendo Linux, muchas variantes Unix (incluyendo HP-UX, Solaris y
OpenBSD), Microsoft Windows, Mac OS X, RISC OS y probablemente alguno más.
PHP soporta la mayoría de servidores web de hoy en día, incluyendo Apache,
Microsoft Internet Information Server, Personal Web Server, Netscape e iPlanet,
OreillyWebsite Pro server, Caudium, Xitami, OmniHTTPd y muchos otros. PHP tiene
módulos disponibles para la mayoría de los servidores, para aquellos otros que
soporten el estándar CGI, PHP puede usarse como procesador CGI. De modo que,
con PHP se tiene la libertad de elegir el sistema operativo y el servidor de su gusto.
Su interpretación y ejecución se da en el servidor web, en el cual se encuentra
almacenado el scrip, y el cliente sólo recibe el resultado de la ejecución. Cuando el
cliente hace una petición al servidor para que le envíe una página web, generada
por un script PHP, el servidor ejecuta el intérprete de PHP, el cual procesa el script
solicitado que generará el contenido de manera dinámica, pudiendo modificar el
contenido a enviar, y regresa el resultado al servidor, el cual se encarga de
regresárselo al cliente. Además es posible utilizar PHP para generar archivos PDF,
Flash, así como imágenes en diferentes formatos, entre otras cosas.
Quizás la característica más potente y destacable de PHP es que permite la
conexión a diferentes tipos de servidores de bases de datos tales como MSQL,
Postgres, Oracle, ODBC, DB2, Microsoft SQL Server, Firebird y SQLite; lo cual
permite la creación de Aplicaciones Web muy robustas. (Piatitini, 1996)
35
PostgreSQL.
PostgreSQL es un servidor de base de datos objeto relacional libre, liberado
bajo la licencia BSD. Como muchos otros proyectos open source, el desarrollo de
PostgreSQL no es manejado por una sola compañía sino que es dirigido por una
comunidad de desarrolladores y organizaciones comerciales las cuales trabajan en
su desarrollo, dicha comunidad es denominada el PGDG (PostgreSQL Global
DevelopmentGroup).
Características:
Algunas de sus principales características son:
Alta concurrencia. Mediante un sistema denominado MVCC (Acceso concurrente
multiversión, por sus siglas en inglés). PostgreSQL permite que mientras un
proceso escribe en una tabla, otros accedan a la misma tabla sin necesidad de
bloqueos. Cada usuario obtiene una visión consistente de lo último a lo que se le
hizo commit. Esta estrategia es superior al uso de bloqueos por tabla o por filas
común en otras bases, eliminando la necesidad del uso de bloqueos explícitos.
• Amplia variedad de tipos nativos. PostgreSQL provee nativamente
soporte para:
• Números de precisión arbitraria.
• Texto de largo ilimitado.
• Figuras geométricas (con una variedad de funciones asociadas)
• Direcciones IP (IPv4 e IPv6).
• Bloques de direcciones estilo CIDR.
• Direcciones MAC.
36
• Arrays.
Adicionalmente los usuarios pueden crear sus propios tipos de datos, los que
pueden ser por completo indexables gracias a la infraestructura GiST de
PostgreSQL. Algunos ejemplos son los tipos de datos GIS creados por el proyecto
PostGIS.
Claves ajenas también denominadas Llaves ajenas o Llaves Foráneas
(foreignkeys).
Disparadores (triggers). Un disparador o triggers se define en una acción
específica basada en algo ocurrente dentro de la base de datos. En PostgreSQL
esto significa la ejecución de un procedimiento almacenado basado en una
determinada acción sobre una tabla específica. Ahora todos los disparadores se
definen por seis características: -El nombre del trigger o disparador -El momento en
que el disparador debe arrancar -El evento del disparador deberá activarse sobre... -
La tabla donde el disparador se activará -La frecuencia de la ejecución -La función
que podría ser llamada. Entonces combinando estas seis características,
PostgreSQL le permitirá crear una amplia funcionalidad a través de su sistema de
activación de disparadores (triggers).
• Vistas.
• Integridad transaccional.
• Herencia de tablas.
• Tipos de datos y operaciones geométricas.
Funciones:
Bloques de código que se ejecutan en el servidor. Pueden ser escritos en
varios lenguajes, con la potencia que cada uno de ellos da, desde las operaciones
37
básicas de programación, tales como bifurcaciones y bucles, hasta las
complejidades de la programación orientación a objetos o la programación funcional.
Los disparadores (triggers en inglés) son funciones enlazadas a operaciones
sobre los datos.
Algunos de los lenguajes que se pueden usar son los siguientes:
• Un lenguaje propio llamado PL/PgSQL (similar al PL/SQL de oracle).
• C.
• C++.
• Gambas.
• Java PL/Java web.
• PL/Perl.
• plPHP.
• PL/Python.
• PL/Ruby.
• PL/sh.
• PL/Tcl.
• PL/Scheme.
• Lenguaje para aplicaciones estadísticas R through PL/R.
38
PostgreSQL soporta funciones que retornan "filas", donde la salida puede
tratarse como un conjunto de valores que pueden ser tratados igual a una fila
retornada por una consulta (query en inglés).
Las funciones pueden ser definidas para ejecutarse con los derechos del
usuario ejecutor o con los derechos de un usuario previamente definido. El concepto
de funciones, en otros DBMS, son muchas veces referidas como "procedimientos
almacenados" (storedprocedures en inglés).(Silberschatz,2002)
Lenguaje Java Script.
JavaScript: es el lenguaje que nos permite interactuar con el navegador de
manera dinámica y eficaz, proporcionando a las páginas web dinamismo y vida.
(Rossainz, 2009)
Xajax.
Xajax es una biblioteca de código abierto para PHP que permite crear de
manera fácil y simple aplicaciones Web basadas en AJAX usando además HTML,
CSS, y Javascript. Las aplicaciones desarrolladas con Xajax pueden comunicarse
asíncronamente con funciones que se encuentran del lado del servidor y así
actualizar el contenido de una página sin tener que recargarla nuevamente, su
última versión es la 0.5 Final que cambia ligeramente comparado con las versiones
anteriores 2.5.x y anteriores.
En un principio se crea una instancia de objeto Xajax (xajaxobject). Este
objeto manejará todo el procesamiento a través de Xajax. En segundo lugar se debe
registrar todas las funciones que se han definido previamente en el objeto Xajax,
esto se puede hacer usando el método xajax->register ( ). Finalmente todas las
respuestas serán procesadas utilizando el método xajax->processRequest ( ).
(Rossainz, 2009)
39
Dreamweaver.
Es una herramienta utilizada para el diseño de páginas web. Esta cumple
perfectamente el objetivo de diseñar páginas con aspecto profesional, y soporta
gran cantidad de tecnologías, además muy fáciles de usar:
• Hojas de estilo y capas
• Java script para crear efectos e interactividades
• Inserción de archivos multimedia.
Los lenguajes de programación que domina Dreamweaver son ASP, CSS,
PHP, SQL, JSP, y XML. El potencial del software en cuanto a la capacidad de
programar bajo los lenguajes que acabamos de citar es de lo más amplio,
permitiendo la creación de aplicaciones y diseños web complejos. Uno de los puntos
de mayor énfasis de Dreamweaver son el soporte y las características de desarrollo
en Cascading Style Sheet, haciendo posible creaciones con más facilidad y
precisión, aplicando herramientas capaces de inspeccionar el código escrito. Otro
aspecto capaz de ser analizado es la compatibilidad de nuestro sitio con los
diversos navegadores, para que todos puedan visualizar la página correctamente.
(Rossainz, 2009)
StarUML.
StarUML es una herramienta para el modelado de software basado en los
estándares UML y MDA (de sus siglas en inglés ModelDrivenArquitecture), que en
un principio era un producto comercial y que hace cerca de un año pasó de ser un
proyecto comercial (anteriormente llamado plastic) a uno de licencia abierta
GNU/GPL.
El software heredó todas las características de la versión comercial y poco a
poco ha ido mejorando sus características, entre las cuales se encuentran:
40
� Soporte completo al diseño UML mediante el uso de: Diagrama de casos
de uso, Diagrama de clase, Diagrama de secuencia, Diagrama de
colaboración, Diagrama de estados, Diagrama de actividad, Diagrama de
componentes,
Diagrama de despliegue, Diagrama de composición estructural (UML
2.0),
� Definir elementos propios para los diagramas, que no necesariamente
pertenezcan al estándar de UML.
� La capacidad de generar código a partir de los diagramas y viceversa,
actualmente funcionando para los lenguajes C++, C# y java.
� Generar documentación en formatos Word, Excel y PowerPoint sobre los
diagramas.
� Patrones GoF (Gang of Four), EJB (Enterprise JavaBeans) y
personalizados.
� Plantillas de proyectos.
� Posibilidad de crear plugins para el programa.
En definitiva esta es una de las mejores alternativas gratuitas que hay en
Internet para el modelamiento de software y probablemente una gran ayuda a la
hora de su elaboración. (Schmuller, 2000)
Hojas de Estilo CCS.
Las Hojas de Estilo describen como es que los documentos son presentados
en pantalla, de forma impresa, o quizás como son pronunciados. Las CSS son
especialmente implementadas en una amplia variedad de navegadores. Al adjuntar
hojas de estilo a documentos estructurados en la Web (por ejemplo HTML), los
autores y lectores pueden influenciar la presentación de documentos sin sacrificar la
41
independencia respecto de los dispositivos ni teniendo que agregar nuevas
etiquetas HTML. (Rossainz, 2009)
42
CAPITULO III
MARCO METODOLOGICO
La finalidad de este capítulo es establecer el nivel de profundidad que se
busca mediante el conocimiento propuesto, así como la forma de acceder a la
información referente al estudio. Para cumplir con tal fin, el primer aspecto a definir
debe ser el tipo y diseño de la investigación, se determina el objeto de estudio, se
relacionan las técnicas e instrumentos, seguidamente se describe el procedimiento
seguido por los investigadores para la realización del trabajo con el respectivo
cronograma de actividades en relación a la metodología aplicada.
Tipo de Estudio
Son diversos los tipos de investigación existentes, especialmente porque los
estudios de la materia suelen presentar propuestas diferentes al respecto. Sin
embargo, existen algunas concepciones generalmente aceptadas por la mayoría de
los investigadores metodológicos. Dentro de esa categoría se ubica:
Proyecto factible: La presente investigación es un proyecto factible ya que
está dirigida a la automatización del proceso de administración de solicitudes en la
Coordinación de Informática, Gerencia de ATIT de CORPOELEC. A objeto de
mejorar la eficiencia de dicho proceso, y optimizar el mismo generando mayor
precisión de la información que concierne al control de solicitudes e indicadores de
gestión centralizados. De manera tal de realizar un seguimiento y control adecuado
de cada una de las solicitudes que se realizan, y así contribuir a la efectividad en la
solución de las mismas. Al respecto Acacia (2000) establece que:
43
“consiste en investigar, elaborar y desarrollar una propuesta de un modelo
operativo viable para solucionar problemas, requerimientos o necesidades
de organizaciones o grupos sociales; puede referirse a la formación de
políticas, programas, tecnologías, métodos o procesos”.( Pág.75).
El proyecto factible comprende: procedimiento metodológico, actividades y
recursos necesarios para su ejecución, análisis y conclusiones sobre la vida y
realización del Proyecto, y en el caso de su desarrollo, la ejecución de la propuesta
y la evaluación tanto del proceso como de resultados. (UPEL 1998). Además, la
investigación se clasifica de acuerdo a aspectos metodológicos de la siguiente
manera:
Según su finalidad, es Aplicada, pues según Rojas de Narváez (1997) "Se
diseñan estrategias, instrumentos, herramientas totalmente practicas y directamente
relacionadas con una situación real en el ambiente de trabajo”. La investigación se
orienta a un problema específico, como lo es el control de gestión de la
Coordinación de Informática adscrita a la Gerencia de ATIT de CORPOELEC.
Según el Nivel de Profundidad, Rojas de Narváez (1997) enuncia que es
Descriptiva, porque "Consiste en describir, registrar, analizar e interpretar la
naturaleza actual, la composición o los procesos de los fenómenos, para presentar
una interpretación correcta”. “Es aquella que obtiene la información acerca del
fenómeno o proceso, para describir sus implicaciones, sin interesarse mucho o muy
poco en conocer el origen o causa de la situación.
Está orientada a dar una visión de cómo opera y cuáles son sus
características” (Universidad Nacional Abierta, 1984, Pag. 78). Por las dos
conceptualizaciones descritas, se puede decir que el nivel de profundidad de la
investigación es descriptiva ya que, el enfoque no se dio al porque del problema,
sino más que todo a entender la situación actual, el problema como tal, y la solución
para este problema y así ofrecer la mejora a la organización, que es lo que se busca
en el proyecto factible.
44
De Campo: la investigación distingue un trabajo de campo, por la forma en
cómo se recopiló la información, tanto en el de área que fue objeto de estudio,
quienes dieron información del proceso, en este caso el personal de informática,
quien aportó información en el aspecto técnico para el análisis y desarrollo del
sistema, La UNA (1984) dice “Este tipo de investigación está basado en métodos o
técnicas que permiten recoger datos en forma directa donde se presentan, es decir,
el campo de trabajo donde se aplicará la solución del problema planteados”, (Pág.
80).
Investigación documental: Del mismo modo la investigación se presenta
como trabajo documental, ya que fue necesario recurrir a fuentes bibliográficas
tanto de las bibliotecas de las universidades y fueron entre otras: documentos
escritos, como libros, diapositivas,…De la misma manera, se considera una
investigación documental, ya que se hicieron investigaciones tanto bibliográficas
como en la web, para conocer algunas funciones del lenguaje PHP para realizar
determinadas actividades, así como investigación sobre la clase XAJAX para PHP, y
los demás componentes de la programación web como son documentación acerca
Javascript, XHTML y CSS, además se reviso también la documentación de
PostgreSQL, para las consultas a la Base de Datos, y elaboración de la misma.
De acuerdo con Cázares, (1982)
La investigación documental depende fundamentalmente de la información que se
recoge o consulta en documentos, entendiéndose este término, en sentido amplio,
como todo material de índole permanente, es decir, al que se puede acudir como
fuente o referencia en cualquier momento o lugar, sin que se altere su naturaleza o
sentido, para que aporte información o rinda cuentas de una realidad
o acontecimiento. (Pág.81)
45
Objeto de Estudio.
Estudio sobre PHP para la codificación de la lógica del negocio, javascript
como complemento de la programación web, XHTML para el diseño de las páginas
web, SQL para las consultas a la base de datos.
Estudio para la implementación de la clase XAJAX de PHP, para
refrescamiento de las páginas para un mejor rendimiento de la página en los
servidores.
Estudio de las herramientas necesarias para la programación web,
administración de base de datos PgAmin III de PostgreSQL, Mozilla Firefox como
navegador web para hacer las pruebas del sistema, y para el diseño de los
diagramas UML, la herramienta StarUML.
Población y Muestra.
La aplicación será utilizada en la Coordinación de Informática; se tomó como
muestra un total de tres (3) técnicos, a los que a le realizaron las entrevistas y
posterior a ello las pruebas del proceso.
Técnicas aplicadas para la Recolección de Datos.
Las técnicas aplicadas para la recolección de datos fueron: la entrevista y el
análisis documental informativo. Considerándose estas herramientas como las más
adecuadas para la recopilación de información.
La observación.
A través de este método se observó con atención el hecho tal cual como se
presentó la situación del problema. Se empleó básicamente para recolectar datos
del comportamiento del proceso de control de gestión en la Coordinación de
Informática. Registrando la deficiencia que presentaba en cuanto proceso de
administración de solicitudes se refiere para así proponer una solución adecuada.
46
La Entrevista.
La entrevista fue aplicada a los trabajadores de la Coordinación de
Informática en la Gerencia de ATIT, quienes serian los usuarios del sistema para así
obtener la información del proceso y entender el mismo, y desarrollar el sistema en
base a los requerimientos establecidos y así mismo para obtener información de
aspecto técnico para el uso de las aplicaciones, y el diseño y desarrollo del sistema.
Revisión Documental.
Se realizaron múltiples investigaciones documentales, tanto en sitios Web
como diferentes bibliografías. Los libros fueron de mucha ayuda para el análisis y
diseño del sistema al igual que para el desarrollo de la investigación. Los sitios Web
más que todo para la resolución de problemas de código y Base de datos es decir
para el desarrollo como tal del sistema. Para más detalle de la revisión documental,
ver Referencias Bibliográficas de la presente investigación.
Problema a resolver.
Considerando el marco del problema descrito en el Capítulo I, la
Coordinación de Informática, adscrita a la Gerencia de ATIT, infiere la necesidad de
realizar un proyecto para mejorar el de administración de solicitudes, que es el
objeto de los resultados presentados en este documento, mediante el Análisis,
Diseño y Desarrollo del Sistema de Control de Gestión (SIASA), descrito en el
capítulo IV de este documento, sistema que solventaría la problemática en el
proceso antes mencionado.
Área de Interés de la Investigación.
El área de interés dentro del cual se enmarca la investigación corresponde al
diseño y desarrollo de sistemas. El diseño que corresponde al proceso de aplicar
ciertas técnicas y principios con el propósito de definir un dispositivo, un proceso o
un sistema, con suficientes detalles como para permitir su interpretación y
47
realización física. El objetivo del proceso de Diseño del Sistema de Información
(DSI) es la definición de la arquitectura del sistema y del entorno tecnológico que le
va a dar soporte, junto con la especificación detallada de los componentes del
sistema de información. A partir de dicha información se generan todas las
especificaciones de construcción relativas al propio sistema, así como la descripción
técnica del plan de pruebas, la definición de los requisitos de implantación y el
diseño de los procedimientos de migración y carga inicial, éstos últimos cuando
proceda.
Partiendo de la premisa que dicho diseño ha pasado por las múltiples
evaluaciones, y observaciones por parte del ente que requiere el sistema en
conjunto con el analista programador que lo ha diseñado, se habrían efectuado las
correcciones pertinentes, se entra en la parte de codificación donde el programador
desarrollara el sistema previamente analizado y diseñado bajo los conceptos
establecidos en el modelado, y los requerimientos funcionales establecidos.
De acuerdo a las necesidades de la Coordinación de Informática Adscrita a
la Gerencia de ATIT, el objeto de estudio contempla el análisis, diseño y desarrollo
de un sistema para la automatización del proceso de administración de solicitudes.
48
CAPITULO IV
RESULTADOS
Metodología de Desarrollo de Sistemas.
El paradigma del Ciclo de Vida Clásico de Sistemas tiene un lugar definido
e importante en el trabajo de la ingeniería del software. Proporciona una plantilla en
la que se encuentran métodos para análisis y levantamiento de requerimientos,
diseño, codificación, pruebas y mantenimiento. El ciclo de vida clásico sigue siendo
el modelo de proceso más extensamente utilizado por la ingeniería del software.
Basándose en las virtudes de esta metodología de desarrollo, se escogió la
misma puesto que se ha comprobado que los sistemas de información que se
apoyan en el ciclo de vida clásico se desarrollan de mejor manera por fases y
ofrecen mejores resultados.
Las fases del ciclo de vida clásico de sistemas, fueron desarrolladas para el
SIASA, y aparecen descritas a continuación en las actividades realizadas:
Descripción de Actividades Realizadas.
Fase de Análisis
Levantamiento de Requerimientos
Las primeras dos semanas se establecieron las reuniones de trabajo, entrevistas,
donde se especificó el problema, y lo que se quería para darle solución al mismo.
Las necesidades de la unidad para así entender cuáles eran los requerimientos, y
así comenzar con la parte de análisis del sistema.
Fase de Análisis y Diseño del Sistema con los Siguientes Diagramas UML
Diseño de Diagrama de Casos de Uso
Esta actividad comprendió la elaboración de los diagramas de casos de uso del
sistema, donde se comprendería las diferentes acciones que tendrían los diferentes
49
tipos de usuarios, sus permisos dentro del sistema, y al mismo tiempo establecer la
modularidad del sistema.
Diseño de Diagrama de Actividades
También fue una actividad de la fase de diseño y modelado la elaboración del
diagrama de actividades, puesto que es necesario para el mejor entendimiento del
proceso, y de lo que se quiere desarrollar.
Diseño de Modelo Entidad Relación
Necesario para todo sistema de información de la actualidad, contar con una base
de datos para guardar la información, y poder hacer las consultas a la misma para
cualquier actividad que desee hacer el usuario, o para diferentes validaciones que
se quiera hacer en el código. La base de datos primeramente pasó por el diseño del
modelo entidad relación para luego, pasar a la creación física; sus tablas, atributos,
relaciones, claves foráneas, claves primarias y todo lo que puede contemplar una
base de datos, según el modelo diseñado.
Diseño de Diccionario de Datos
Se elaboró un diccionario de datos a manera de especificación para los demás
desarrolladores que pudieran hacerle mantenimiento al sistema, tener la descripción
textual de la base de datos, tanto de las tablas como de los atributos, su tipo de dato
y longitud.
Fase de Desarrollo del Sistema
Diseño de la interfaz del sistema
Una actividad necesaria es la elaboración de una interfaz no funcional, las pantallas
que puedan ser mostradas al usuario antes de comenzar a desarrollar, esta
actividad se contempló además por la metodología de desarrollo aplicada que fue la
del prototipo.
50
Programación de las clases
Las clases identificadas, y diseñadas en el diagrama de clases, es lo primero que se
comenzó a desarrollar, los métodos principales de registro, modificación, y
eliminación, y algunas consultas. A medida que se avanza en el desarrollo siempre
nace la necesidad de nuevos métodos que se van añadiendo a las clases ya
creadas.
Programación de componentes
Actividad que corresponde al desarrollo de los componentes que implica el sistema,
poner a funcionar las interfaces diseñadas, e implementar las clases desarrolladas.
Pruebas y validaciones
Con esta actividad lo se busca es depurar los errores tanto funcionales, errores de
código, como errores del proceso debido a algún error que pudo ocurrir en la fase
de análisis, y manejo de la información. Esto antes de implantar el sistema.
Cronograma de Actividades.
A continuación se describe la programación de actividades realizadas
durante el desarrollo del sistema planteado.
51
Tabla 2. Cronograma de Actividades. Fuente: El Autor
Estudio De Factibilidad.
Se pudo determinar que el proyecto es factible debido a que cumple con los
siguientes aspectos que se detallan a continuación.
Factibilidad Operativa.
El proyecto cuenta con la factibilidad operacional debido a que el desarrollo
del Sistema de Administración de Solicitudes, es una propuesta de complejidad baja
lo cual asegura que los usuarios del sistema podrán utilizarlo. Además, a esto se le
suma el hecho de que durante la investigación preliminar se detectó gran aceptación
de los cambios futuros que ocasionará la implementación del sistema, y la solicitud
por parte de la unidad de una herramienta que automatizará este proceso.
Factibilidad Técnica.
Durante la investigación preliminar se pudo constatar que el proyecto cuenta
con la factibilidad técnica debido a que la Coordinación de Informática posee los
recursos de software y hardware requeridos para implementar en un futuro, el
52
sistema propuesto y así mismo dicha unidad tiene la experiencia técnica requerida
para hacer los correspondientes mantenimientos del sistema que estaría en
funcionamiento.
Descripción Conceptual de Los Procesos Del Sistema.
El SIASA tiene como objetivo realizar un seguimiento del Control de la
Gestión de la Gerencia de Automatización, Tecnologías de la Información y
Telecomunicaciones (ATIT). Mediante la automatización de los procesos de
administración de solicitudes y a partir de ello permitir la generación de los
indicadores de gestión correspondientes a la unidad.
Módulo de Gestión de Solicitudes: los usuarios cargan solicitudes, así
mismo pueden realizar la modificación de las mismas y eliminarlas en caso de ser
necesario.
Módulo de Gestión de Usuarios: se lleva el control de usuarios, unidades y
ubicaciones; bien sea, agregar, modificar o eliminar cada una de ellas.
Módulo de Gestión de Técnicos: se lleva el control de cada uno de los
técnicos, agregar y modificar la información de cada uno de ellos, y así mismo,
modificar el estatus de disponibilidad para atender solicitudes.
Módulo de Gestión de Actividades: se realiza el Control de los Sistemas,
Subsistemas y de las Actividades, permitiendo agregar, modificar y eliminar cada
uno de ellos.
Módulo de Gestión de Reportes: se pueden consultar los reportes en un
período de tiempo determinado por el usuario.
53
Requerimientos de Información.
Mediante el estudio de los datos suministrados durante la fase investigación
y análisis preliminar, se pudieron identificar los siguientes requerimientos
funcionales y no funcionales.
Requerimientos Funcionales.
• Agregar, modificar y eliminar solicitudes.
• Agregar y modificar usuarios.
• Agregar, modificar y eliminar unidades.
• Agregar, modificar y eliminar ubicaciones.
• Agregar y modificar técnicos.
• Modificar Estatus de Técnicos.
• Agregar, modificar y eliminar sistemas.
• Agregar, modificar y eliminar subsistemas.
• Agregar, modificar y eliminar actividades.
• Consultar reportes en un rango de fechas que ingrese el usuario.
Requerimientos No Funcionales.
• Creación de la Base de Datos del Sistema siguiendo el modelo relacional.
• Validación de acceso al Sistema, con el fin de proteger los datos
almacenados en el mismo.
54
Casos de Uso detallados para el SIASA.
Diagrama de Roles
Figura 4. Diagrama de Roles. Fuente: El Autor
Propósito: Especificar los Roles de usuarios dentro del sistema SIASA
(Sistema de Administración de Solicitudes)
Descripción: Se establece una generalización de usuarios donde el usuario
técnico es el que tiene menos privilegios dentro del sistema y el administrador es el
usuario con más privilegios ya que puede hacer lo que hace el técnico más acciones
propias de él. En el siguiente diagrama se especificará lo que hace cada usuario en
el sistema de manera general.
55
Diagrama General.
Figura 5. Diagrama General. Fuente: El Autor
Actor principal: Técnico y Administrador.
Entorno: Diagrama General.
Propósito: El presente caso de uso representa lo que hará cada usuario
contra cada módulo del sistema, recordando además el diagrama de roles se sabe
también que los usuarios heredan acciones de otros usuarios, dependiendo de su
rol.
56
Descripción:
EL TÉCNICO PODRÁ:
Tener acceso al módulo de Solicitudes donde:
• Se agregan solicitudes.
• Se modifican solicitudes.
• Se eliminan solicitudes.
Tener acceso al módulo de Usuarios donde:
• Se agregan usuarios.
• Se modifican usuarios.
• Se agregan unidades.
• Se modifican unidades.
• Se eliminan unidades.
• Se agregan ubicaciones.
• Se modifican ubicaciones.
• Se eliminan ubicaciones.
EL ADMINISTRADOR, además de hacer lo mismo que hace el técnico, podrá:
Tener acceso al módulo de Técnicos:
• Se agregan técnicos.
• Se modifican técnicos.
• Se eliminan técnicos.
• Se controla la asistencia de los técnicos.
Tener acceso al módulo de Actividades:
• Se agregan actividades con sus respectivos puntajes.
• Se agregan Sistemas.
57
• Se modifican Sistemas.
• Se eliminan Sistemas.
• Se agregan Subsistemas.
• Se modifican Subsistemas.
• Se eliminan Subsistemas.
Tener acceso al módulo de Reportes:
• Ingresar fecha.
• Seleccionar reporte que desea visualizar.
58
Diagrama de Gestión de Solicitudes.
Figura 6. Diagrama de Gestión de Solicitudes. Fuente: El Autor
Actor Principal: Técnico.
Entorno: Módulo de Gestión de Solicitudes.
Propósito: El presente caso de uso permite ver que acciones puede tomar el
técnico dentro del módulo de solicitudes, como son agregar una solicitud, modificar
la misma, o eliminarlas.
59
Diagrama de Gestión de Usuarios.
Figura 7. Diagrama de Gestión de Gestión de Usuarios. Fuente: El Autor
Actor Principal: Técnico.
Entorno: Módulo de Gestión de Usuarios.
Propósito: El presente caso de uso permite ver que acciones puede tomar el
técnico dentro del módulo de usuarios, como son agregar y modificar usuarios; lo
mismo puede hacer con las unidades y las ubicaciones.
60
Diagrama de Gestión de Técnicos.
Figura 8. Diagrama de Gestión de Gestión de Técnicos. Fuente: El Autor
Actor Principal: Administrador.
Entorno: Módulo de Gestión de Técnicos.
Propósito: El presente caso de uso permite ver que acciones puede tomar el
administrador dentro del módulo de gestión de técnicos, como son agregar y
modificar técnicos; así mismo, permite controlar la asistencia de los mismos.
61
Diagrama de Gestión de Actividades.
Figura 9. Diagrama de Gestión de Gestión de Actividades. Fuente: El Autor
Actor Principal: Administrador.
Entorno: Módulo de Gestión de Actividades.
Propósito: El presente caso de uso permite ver que acciones puede tomar el
Administrador dentro del módulo de actividades, como son agregar, modificar y
eliminar sistemas, subsistemas y actividades.
62
Diagrama de Gestión de Reportes.
Figura 10. Diagrama de Gestión de Gestión de Reportes. Fuente: El Autor
Actor Principal: Administrador.
Entorno: Módulo de Gestión de Reportes.
Propósito: El presente caso de uso permite ver que acciones puede tomar el
Administrador dentro del módulo de reportes, como son ingresar fecha y seleccionar
el reporte que desea visualizar.
63
Diagramas de Actividades.
Actividad Agregar Solicitudes.
Figura 11. Actividad Agregar Solicitudes. Fuente: El Autor
64
Actividad Modificar Solicitudes.
Figura 12. Actividad Modificar Solicitudes. Fuente: El Autor
65
Actividad Eliminar Solicitudes.
Figura 13. Actividad Eliminar Solicitudes. Fuente: El Autor
66
Actividad Agregar y Modificar Usuarios.
Figura 14. Actividad Agregar y Modificar Usuarios. Fuente: El Autor
67
Actividad Agregar Unidad.
Figura 15. Actividad Agregar Unidad. Fuente: El Autor
68
Actividad Modificar Unidad.
Figura 16. Actividad Modificar Unidad. Fuente: El Autor
69
Actividad Eliminar Unidad.
Figura 17. Actividad Eliminar Unidad. Fuente: El Autor
70
Actividad Agregar Ubicación.
Figura 18. Actividad Agregar Ubicación. Fuente: El Autor
Actividad Modificar Ubicación.
Figura 19. Actividad Modificar Ubicación. Fuente: El Autor
71
Actividad Eliminar Ubicación.
Figura 20. Actividad Eliminar Ubicación. Fuente: El Autor
72
Actividad Agregar y Modificar Técnicos.
Figura 21. Actividad Agregar y Modificar Técnicos. Fuente: El Autor
73
Actividad Modificar Estatus Técnicos.
Figura 22. Actividad Modificar Estatus Técnicos. Fuente: El Autor
74
Actividad Agregar Sistemas.
Figura 23. Actividad Agregar Sistemas. Fuente: El Autor
75
Actividad Modificar Sistemas.
Figura 24. Actividad Modificar Sistemas. Fuente: El Autor
76
Actividad Eliminar Sistemas.
Figura 25. Actividad Eliminar Sistemas. Fuente: El Autor
77
Actividad Agregar Subsistemas.
Figura 26. Actividad Agregar Subsistemas. Fuente: El Autor
78
Actividad Modificar Subsistemas.
Figura 27. Actividad Modificar Subsistemas. Fuente: El Autor
79
Actividad Eliminar Subsistemas.
Figura 28. Actividad Eliminar Subsistemas. Fuente: El Autor
80
Actividad Agregar Actividad.
Figura 29. Actividad Agregar Actividad. Fuente: El Autor
81
Actividad Modificar Actividad.
Figura 30. Actividad Modificar Actividad. Fuente: El Autor
82
Actividad Eliminar Actividad.
Figura 31. Actividad Eliminar Actividad. Fuente: El Autor
83
Actividad Visualizar Reportes
Figura 32. Actividad Visualizar Reportes. Fuente: El Autor
Tabla Visual de Contenidos.
Figura 33. Tabla Visual General
Figura 34. Tabla Visual – Gestión de Solicitudes
1. Gestión de Solicitudes
2. Gestión de Usuarios
1.1.2 Agregar Solicitud
Tabla Visual de Contenidos.
. Tabla Visual General. Fuente: El Autor
Gestión de Solicitudes. Fuente: El Autor
SIASA
2. Gestión de Usuarios
3. Gestión de Técnicos
4. Gestión de Actividades
SIASA
1. Gestión de Solicitudes
1.1 Control de Solicitud
1.1.2 Agregar Solicitud
1.1.3 Modificar Solicitud
1.1.4 Eliminar Solicutd
84
5. Gestión de Reportes
Figura 35. Tabla Visual – Gestión de Usuarios
Figura 36. Tabla Visual – Gestión de Usuarios
2.2.1 Agregar Unidad
Gestión de Usuarios – Control de Usuarios. Fuente:
Gestión de Usuarios – Control de Unidad. Fuente: El Autor
SIASA
2. Gestión de Usuarios
2.1 Control de Usuarios
2.1.1 Agregar Usuarios
2.1.2 Modificar Usuarios
SIASA
2. Gestión de Usuarios
2.2 Control de Unidad
2.2.1 Agregar Unidad
2.2.2 Modificar Unidad
2.2.3 Eliminar Unidad
85
Fuente: El Autor
El Autor
Figura 37. Tabla Visual – Gestión de Usuarios
Figura 38. Tabla Visual – Gestión de
2.3.1 Agregar
Ubicación
Gestión de Usuarios – Control de Ubicación. Fuente:
Gestión de Técnicos – Control de Técnicos. Fuente:
SIASA
2. Gestión de Usuarios
2.3 Control de
Ubicación
2.3.1 Agregar
Ubicación
2.3.2 Modificar Ubicación
2.3.3 Eliminar
Ubicación
SIASA
3. Gestión de Técnicos
3.1 Control de Técnicos
3.1.1 Agregar Técnicos
3.1.2 Modificar Técnicos
86
Fuente: El Autor
Fuente: El Autor
Figura 39. Tabla Visual – Gestión de Técnicos
Figura 40. Tabla Visual – Gestión de Actividades
4.1.1 Agregar
Sistemas
Gestión de Técnicos – Estatus Técnicos. Fuente: El Autor
Gestión de Actividades – Control de Sistemas. Fuente:
SIASA
3. Gestión de Técnicos
3.2 Estatus Técnicos
3.2.1 Asistencia Técnicos
SIASA
4. Gestión de
Actividades
4.1 Control de Sistemas
4.1.1 Agregar
Sistemas
4.1.2 Modificar Sistemas
4.1.3 Eliminar Sistemas
87
El Autor
Fuente: El Autor
Figura 41. Tabla Visual – Gestión de Actividades
Figura 42. Tabla Visual – Gestión de Actividades
4.2.1 Agregar
Subsistemas
4.3.1 Agregar
Actividades
Gestión de Actividades – Control de Subsistemas. Fuente:
Gestión de Actividades – Control de Actividades. Fuente:
SIASA
4. Gestión de Actividades
4.2 Control de
Subsistemas
4.2.1 Agregar
Subsistemas
4.2.2 Modificar
Subsistemas
4.2.3 Eliminar
Subsistemas
SIASA
4. Gestión de Actividades
4.3 Control de
Actividades
4.3.1 Agregar
Actividades
4.3.2 Modificar
Actividades
4.3.3 Eliminar
Actividades
88
Fuente: El Autor
Fuente: El Autor
Figura 43. Tabla Visual – Gestión de Reportes
Gestión de Reportes. Fuente: El Autor
SIASA
5. Gestión de Reportes
5.1 Reportes
5.1.1 Ingresar Fecha
5.1.2 Seleccionar
Reportes
89
90
Modelo Entidad Relación.
Figura 44. Modelo Entidad Relación. Fuente: El Autor
91
Diccionario de Datos.
Tabla usuarios: En esta tabla se almacenaran los diferentes usuarios del sistema.
usuarios
Atributo Tipo de Dato Descripción
id (PK) Bigserial (not null) Cédula del empleado que lo identifica como único en el sistema,
nombre character varying Nombre del Empleado y/o Usuario
apellido character varying Apellido del Empleado y/o Usuario
telefono integer Telefono del Empleado y/o Usuario
id_unidad bigint Unidad a la que pertenece el Empleado y/o Usuario
estatus integer Estatus del Empleado y/o Usuario 1=Activo 0=Inactivo
login character varying Nombre de Usuario para acceso al sistema
clave character varying Contraseña del Usuario para acceso al sistema
privilegio integer DEFAULT 3
Privilegio del usuario dentro del sistema 1=Administrador 2=Tecnico 3=Analista
operante Carácter(longitud = 1,
not null)
Atributo para manejar si un usuario estará o no disponible para atender solicitudes.
Tabla 3. Diccionario de Datos – Tabla usuarios. Fuente: El Autor
Claves foráneas de Tabla usuarios
Nombre Tabla Externa Atributo
Externo
Atributo
Interno
usuarios_id_unidad_fkey unidad id id_unidad
Tabla 4. Diccionario de Datos – Claves foráneas de tabla usuarios. Fuente: El Autor
92
Tabla unidad: en esta tabla se almacenaran las unidades.
unidad
Atributo Tipo de Dato Descripción
id (PK) Bigserial (not null) Id de unidad único y autoincremento
nombre character varying Nombre de la Unidad
id_ubicacion bigint Identificador de la Ubicación a la que pertenece la Unidad
estatus integer Estatus de la Unidad 1=Activa 0=Inactiva
Tabla 5: Diccionario de Datos – Tabla unidad. Fuente: El Autor
Claves foráneas de Tabla unidad
Nombre Tabla Externa Atributo
Externo
Atributo
Interno
unidad_id_ubicacion_fkey ubicacion id id_ ubicacion
Tabla 6: Diccionario de Datos – Claves foráneas de tabla unidad. Fuente: El Autor
Tabla ubicacion: en esta tabla se almacenaran las ubicaciones.
ubicacion
Atributo Tipo de Dato Descripción
id (PK) Bigserial (not null) Id de Ubicacion único y autoincremento
nombre character varying Nombre de la Ubicacion
estatus integer Estatus de la Ubicación 1=Activa 0=Inactiva
Tabla 7. Diccionario de Datos – Tabla ubicación. Fuente: El Autor
93
Tabla sistema: en esta tabla se almacenaran los sistemas.
sistema
Atributo Tipo de Dato Descripción
id (PK) Bigserial (not null) Id de Sistema único y autoincremento
descripcion character varying Nombre del Sistema
estatus integer Estatus del Sistema 1=Activo 0=Inactivo
Tabla 8. Diccionario de Datos – Tabla sistema. Fuente. El Autor
Tabla subsistemas: en esta tabla se almacenaran los subsistemas.
subsistemas
Atributo Tipo de Dato Descripción
id (PK) Bigserial (not null) Id de Subsistema único y autoincremento
descripcion character varying Nombre del Subsistema
id_sistema bigint Identificador del Sistema al que pertenece el Subsistema
estatus integer Estatus del Subsistema 1=Activo 0=Inactivo
Tabla 9. Diccionario de Datos – Tabla subsistemas. Fuente: El Autor
Claves foráneas de Tabla subsistemas
Nombre Tabla Externa Atributo
Externo
Atributo
Interno
subsistemas_id_sistema_fkey sistema id id_sistema
Tabla 10. Diccionario de Datos – Claves foráneas de tabla subsistemas. Fuente: El Autor
94
Tabla soluciones: en esta tabla se almacenaran las soluciones o actividades que realizaran los técnicos en cada una de las solicitudes
soluciones
Atributo Tipo de Dato Descripción
id (PK) Bigserial (not null) Id de Actividad único y autoincremento
descripcion Character varying Descripción de la Actividad
puntaje integer Puntaje o valor que tiene para el técnico llevar a cabo esta actividad
id_subsistema bigint Identificador del Subsistema al que pertenece esta actividad
estatus integer Estatus de la Actividad 1=Activa 0=Inactiva
Tabla 11. Diccionario de Datos – Tabla soluciones. Fuente: El Autor
Claves foráneas de Tabla soluciones
Nombre Tabla Externa Atributo
Externo
Atributo
Interno
soluciones_id_subsistema_fkey subsistema id id_
subsistema
Tabla 12. Diccionario de Datos – Claves foráneas tabla soluciones. Fuente: El Autor
95
Tabla solicitud: en esta tabla se almacenaran las solicitudes que sean creadas
solicitud
Atributo Tipo de Dato Descripción
id (PK) Bigserial (not null) Id de la Solicitud único y autoincremento
descripción_del_problema character varying Descripción del Problema que se presenta y por el cual se hace la solicitud
id_usuario integer Id del analista que hace la solicitud
id_tecnico integer Id del técnico que atiende la solicitud
estatus integer Estado de la Solicitud 1= Atendida 0= Pendiente por Atender
tipo integer Tipo de solicitud 1= Falla 2=Requerimiento
fecha timestamp without
time zone Fecha en la que se creó la Solicitud
estatus_elimanacion integer Estatus de la Solicitud 1=Activa 0=Inactiva
fecha_cierre timestamp without
time zone Fecha en la que se cerro la solicitud, es decir paso a ser Atendida
Tabla 13. Diccionario de Datos – Tabla solicitud. Fuente: El Autor
Claves foráneas de Tabla solicitud
Nombre Tabla Externa Atributo
Externo
Atributo
Interno
solicitudes_id_tecnico_fkey usuario id id_tecnico
solicitudes_id_usuario_fkey usuario id id_usuario
Tabla 14. Diccionario de Datos – Claves foráneas tabla solicitud. Fuente: El Autor
96
Tabla soluciones_solicitud: tabla relacional entre tabla solicitud y soluciones.
soluciones_solicitud
Atributo Tipo de Dato Descripción
id (PK) Bigserial (not null) Id de la solución hecha en la solicitud único y autoincremento
id_solicitud bigint Id de la solicitud
id_solucion bigint Id de solución que se realizo en la solicitud
fecha timestamp without
time zone Fecha en la que se realizo solución
Tiempo_solucion integer Tiempo que se tardo el técnico en realizar dicha solucion
Tabla 15. Diccionario de Datos – Tabla soluciones. Fuente: El Autor
Claves foráneas de Tabla soluciones_solicitud
Nombre Tabla Externa Atributo
Externo
Atributo
Interno
soluciones_solicitud_id_solucion_fkey soluciones id id_ solucion
Tabla 16. Diccionario de Datos – Claves foráneas tabla soluciones_solicitud. Fuente: El Autor
97
Tabla cola: Tabla para manejar la cola de los técnicos en el sistema para atender las solicitudes pendientes
cola
Atributo Tipo de Dato Descripción
id (PK) Bigserial (not null) Id único de la tabla para llevar control de la cola de técnicos para asignarse a las solicitudes salientes
id_usuario integer Id de técnico que atenderá la solicitud
estatus integer Estatus del usuario en la cola 1= Activo 0= Ocupado
turno integer Turno del técnico en la cola para atender la solicitud si es igual a 1 será el asignado a la siguiente solicitud
Tabla 17. Diccionario de Datos – Tabla cola. Fuente: El Autor
Claves foráneas de Tabla cola
Nombre Tabla Externa Atributo
Externo
Atributo
Interno
cola_id_usuario_fkey usuarios id id_ usuario
Tabla 18. Diccionario de Datos – Claves foráneas tabla cola. Fuente: El Autor
98
CONCLUSIONES
1. Se alcanzó el objetivo principal de las pasantías, el desarrollo del sistema
de información en la Coordinación de Informática y se pudo mejorar y
optimizar el proceso de administración de solicitudes de dicha unidad.
2. Luego del estudio del problema existente, se efectuó un diagnóstico del
proceso donde se determinó que existía la necesidad de elaborar un
sistema de información para la automatización del control de solicitudes,
y así hacer el levantamiento de requerimientos de la unidad, para hacer
el diseño del sistema que cumpliera con las necesidades.
3. Se realizó el modelado del sistema basándose en el Lenguaje de
Modelado Unificado (UML), empleando StarUML, para la elaboración de
estos diagramas. A través de ellos, se pudo mostrar a los usuarios una
especie de bosquejo de las acciones que tendrían los mismos con el
sistema presentándole los casos de usos detallados, y así definir el
alcance del mismo previa aprobación de los usuarios. Con el diseño del
Modelo Entidad Relación para la creación de la Base de datos, se
pudieron entender las relaciones entre las tablas existentes, y así poder
brindar soporte al sistema para el resguardo de la información. Además
de el diseño de los diagramas de actividades.
4. La codificación y construcción del SIASA se desarrolló bajo la aplicación
Dreamweaver integrando código en PHP, HTML, JavaScript y CSS
implementando nociones de programación modular y programación
orientada a objetos. Para el manejo de la base de datos se uso
PostgreSQL con el visor PGAdminIII. Se implemento la clase XAJAX,
para el refrescamiento de las páginas y evitar las recargas completas de
páginas.
99
5. Una vez culminada la fase de desarrollo, se instaló satisfactoriamente el
sistema en la Unidad, y posterior a ello se impartió el adiestramiento al
personal que manejará el SIASA, obteniendo como resultado el completo
entendimiento del mismo por parte de los usuarios.
100
RECOMENDACIONES
1. Estudiar la posibilidad de agregar al SIASA un módulo para que los
usuarios de las diferentes unidades puedan tener acceso al sistema, con
la finalidad de realizar las solicitudes de manera independiente; de esta
forma se estaría mejorando el proceso y los técnicos ya no tendrían esta
responsabilidad.
2. Realizar un análisis periódico de las necesidades de los usuarios para
poder estipular nuevos requerimientos que puedan surgir para el SIASA.
3. Diseñar los correspondientes diagramas UML antes de comenzar a
desarrollar un nuevo módulo del sistema, ya que esto facilita el trabajo
antes de entrar a la fase de codificación, y sirve a los demás
programadores para entender la lógica del negocio apoyándose en el
manual de sistema que contenga dichos diagramas.
4. Investigar constantemente las nuevas tecnologías que surjan para el
desarrollo de sistemas y estudiar las mismas, para hacerle las mejoras
correspondientes al sistema implementado, y los futuros módulos que
puedan ser desarrollados.
5. Elaborar los respectivos manuales de usuarios, y adiestramiento de
personal en el momento de la implementación de un nuevo módulo o la
modificación de alguno existente, esto para integrar al usuario al nuevo
cambio o función del sistema.
101
REFERENCIAS
Cázares, L., Christen, M. y otros (1982). Técnicas actuales de investigación
documental. México: Trillas
Bennett, S. (2007). Análisis y Diseño Orientado a Objetos de Sistemas Usando
UML. Tercera Edición. Editorial McGrawHill. España.
Booch, G., Rumbaught, J. y Jacobson, I. (1999). El lenguaje Unificado de Modelado.
Madrid: Addison-Wesley.
Hernádez, Acacia (2000) La Investigación como Discurso. Tesis Doctoral. Caracas:
USR.
Kendall, K. y Kendall, J. (1991). Análisis y Diseño de Sistemas. México:
Prentice-Hall.
Neteraft (1995) [Documento en línea]. Disponible:
http://es.wikipedia.org/wiki/servidor-http-apache [Consulta: 2011, agosto 15]
Piattini et al (1996), Análisis y diseño de aplicaciones informáticas de gestión. Ra-
Ma (PP 206 - 208).
Rojas de Narváez, Rosa (1997). Orientaciones prácticas para la elaboración de
informes de investigación. Puerto Ordaz: Editorial Universidad Nacional
Experimental Politécnica "Antonio José de Sucre".
Rossainz, M. Diseño Orientado a Objetos. Recuperado el 6 de febrero de 2009, de
http://www.cs.buap.mx/~dpinto/semadoo/mario.pdf.
Sabino, C. (1986). El Proceso de Investigación. Editorial Panapo. Caracas.
Schmuller, J. (2000). Aprendiendo UML en 24 horas. México: Prentice-Hall.
102
Senn, James A. (1992) Análisis y Diseño de Sistemas de Información. Segunda
Edición. Editorial McGrawHill. México.
Silberschatz A. (2002) Fundamentos de Base de Datos. Cuarta edición. McGraw
Hill,(PP 100 - 104).
Tamayo & Tamayo Mario (2005). El proceso de la Investigación Científica. (PP 46 -
53). Mexico: 4ta edición, Limusa.
UPEL (1998): Manual de Trabajos de Grado y Maestría y Tesis Doctoral de la
Universidad Pedagógica Experimental Libertador. Caracas: UPEL.
103
ANEXOS
104
Anexo A.
MANUAL DE USUARIO
I.- Inicio de Sesión
El inicio de sesión se hará ingresando los datos pertenecientes al nombre de
usuario y contraseña.
Dependiendo del grupo de usuario a que pertenezca, se habilitaran las
distintas barras de menú, donde el usuario podrá accionar lo que le corresponde
según los privilegios que tenga.
105
Existen dos grupos diferentes de usuarios:
- Administrador.
- Técnico.
Administrador: este tipo de usuario es el q tiene todos los privilegios del sistema,
puede usar todas las funciones del mismo, y el siguiente es el menú que se le
presenta.
Técnico: este tipo de usuario diferencia del administrador, solo puede ingresar a los
módulos de Gestión de Gestión de Solicitudes y de Usuarios. El siguiente es el
menú que se le presenta.
106
II.- Módulo de Gestión de Solicitudes.
En este módulo es de donde podemos hacer todo lo que a control de
solicitudes se refiere. Bien sea agregar, modificar y eliminar solicitud.
Agregar Solicitud:
1.- Ingresar C.I
del trabajador
2.- Ingresar
descripción el
problema
3.- Seleccionar
tipo
4.- Hacer click en
guardar
107
Modificar Solicitud:
Seleccionar
editar
3.- Seleccionar
editar
4.- Ingresar tiempo
de solución
5.- Seleccionar
agregar solución
Seleccionar
eliminar si la
solución no es
correcta
Hacer click si desea
cerrar la solicitud, es
decir, si no desea
agregar otra solución
1.- Seleccionar
sistemas
2.- Seleccionar
subsistemas
108
Eliminar Solicitud:
Seleccionar
eliminar
Hacer click en
aceptar
109
III.- Módulo de Gestión de Usuarios.
En este módulo es de donde podemos hacer todo lo que a control de
usuarios, unidades y ubicaciones se refiere. Bien sea agregar, modificar y eliminar
las mismas.
Agregar y Modificar Usuarios:
Si el usuario existe, el sistema permitirá modificar todos los campos
disponibles, de lo contrario deberá llenarlos. Como se muestra a continuación:
1.- Ingresar CI del
usuario 2.- Hacer click
en la lupa
110
Agregar Unidad:
1.- Seleccionar
ubicación
2.- Ingresar el
nombre de la
unidad
111
Modificar Unidad:
Eliminar Unidad:
1.- Seleccionar
ubicación
3.- Ingresar el
nombre de la
unidad
2.- Hacer click en
editar
4.- Hacer click en
guardar
Hacer click en
eliminar
112
Agregar Ubicación:
Hacer click en
aceptar
1.- Ingresar
nombre de la
ubicación
2.- Hacer click en
guardar
113
Modificar Ubicación:
Eliminar Ubicación:
1.- Hacer click en
editar
2.- Modificar
nombre de la
ubicación
3.- Hacer click en
guardar
Hacer click en
eliminar
114
Hacer click en
aceptar
115
IV.- Módulo de Gestión de Técnicos.
En este módulo en usuario podrá hacer todo lo referente al Control de
Técnicos, bien sea agregar o modificar los datos de los mismos, y visualizar y
modificar su Estatus de disponibilidad para atender solicitudes.
Agregar y Modificar Técnicos:
Si el técnico existe, el sistema permitirá modificar todos los campos
disponibles, de lo contrario deberá llenarlos. Como se muestra a continuación:
1.- Ingresar CI del
técnico 2.- Hacer click
en la lupa
116
Modificar disponibilidad de técnicos:
1.- Hacer click
en Estatus
2.- Hacer click
en aceptar
117
V.- Módulo de Gestión de Actividades.
En este módulo en usuario podrá hacer todo lo referente al Control de
Actividades, sistemas y subsistemas ya sea agregar, modificar o eliminar cada uno
de ellos.
Agregar, modificar y eliminar actividades:
1.- Seleccionar
Estatus 2.- Seleccionar
Subsistemas 1.- Ingresar
puntaje de
actividad
Hacer click en editar si
desea modificar la
actividad
Hacer click en eliminar si
desea descartar la
actividad
118
Agregar, modificar y eliminar sistemas:
Agregar, modificar y eliminar subsistemas:
Hacer click en editar si
desea modificar el
sistema
Hacer click en eliminar si
desea descartar el
sistema
1.- Ingresar la descripción del
sistema si este no se
encuentra en el listado, luego
haga click en guardar
Hacer click en editar si
desea modificar el
subsistema
Hacer click en eliminar si
desea descartar el
subsistema
2.- Ingresar la descripción del
subsistema si este no se
encuentra en el listado, luego
haga click en guardar
1.- Seleccionar
hardware
119
VI.- Módulo de Gestión de Reportes.
A través de éste módulo los usuarios podrán obtener las estadísticas, bien
sea por analistas, por unidades o indicadores de desempeño.
En caso de que el usuario indique como tipo de reporte, “Indicadores de
desempeño” se mostrará de la siguiente manera:
1.- Ingresar fecha de
inicio
2.- Ingresar fecha fin 3.- Seleccionar tipo de
reporte
120
121
Anexo B.
Publicado en la Gaceta oficial Nº 38.095 de fecha 28/ 12/ 2004
Decreto N° 3.390
Fecha: 23 de diciembre de 2004
HUGO CHÁVEZ FRÍAS
PRESIDENTE DE LA REPÚBLICA
De conformidad con lo dispuesto en los artículos 110 y 226 de la Constitución de la
República Bolivariana de Venezuela, 12 y 47 de la Ley Orgánica de la
Administración Pública y, 2º, 19 y 22 del Decreto con Rango y Fuerza de Ley
Orgánica de Ciencia, Tecnología e Innovación, en Consejo de Ministros,
CONSIDERANDO
Que es prioridad del Estado incentivar y fomentar la producción de bienes y servicios para satisfacer las necesidades de la población,
CONSIDERANDO
Que el uso del Software Libre desarrollado con Estándares Abiertos fortalecerá la
industria del software nacional, aumentando y fortaleciendo sus capacidades,
CONSIDERANDO
Que la reducción de la brecha social y tecnológica en el menor tiempo y costo
posibles, con calidad de servicio, se facilita con el uso de Software Libre
desarrollado con Estándares Abiertos,
CONSIDERANDO
Que la adopción del Software Libre desarrollado con Estándares Abiertos en la
Administración Pública y en los servicios públicos facilitará la interoperabilidad de
122
los sistemas de información del Estado, contribuyendo a dar respuestas rápidas y
oportunas a los ciudadanos, mejorando la gobernabilidad,
CONSIDERANDO
Que el Software Libre desarrollado con Estándares Abiertos, permite mayor
participación de los usuarios en el mantenimiento de los niveles de seguridad e
interoperatividad,
DECRETA
Artículo 1. La Administración Pública Nacional empleará prioritariamente Software
Libre desarrollado con Estándares Abiertos, en sus sistemas, proyectos y servicios
informáticos. A tales fines, todos los órganos y entes de la Administración Pública
Nacional iniciarán los procesos de migración gradual y progresiva de éstos hacia el
Software Libre desarrollado con Estándares Abiertos.
Artículo 2. A los efectos del presente Decreto se entenderá por:
Software Libre: Programa de computación cuya licencia garantiza al usuario acceso
al código fuente del programa y lo autoriza a ejecutarlo con cualquier propósito,
modificarlo y redistribuir tanto el programa original como sus
modificaciones en las mismas condiciones de licenciamiento acordadas al programa
original, sin tener que pagar regalías a los desarrolladores previos.
Estándares Abiertos: Especificaciones técnicas, publicadas y controladas por alguna
organización que se encarga de su desarrollo, las cuales han sido aceptadas por la
industria, estando a disposición de cualquier usuario para ser
implementadas en un software libre u otro, promoviendo la competitividad,
interoperatividad o flexibilidad.
Software Propietario: Programa de computación cuya licencia establece
restricciones de uso, redistribución o modificación por parte de los usuarios, o
requiere de autorización expresa del Licenciador.
123
Distribución Software Libre desarrollado con Estándares Abiertos para el Estado
Venezolano: Un paquete de programas y aplicaciones de Informática elaborado
utilizando Software Libre con Estándares Abiertos para ser utilizados y distribuidos
entre distintos usuarios.
Artículo 3. En los casos que no se puedan desarrollar o adquirir aplicaciones en
Software Libre bajo Estándares Abiertos, los órganos y entes de la Administración
Pública Nacional deberán solicitar ante el Ministerio de Ciencia
y Tecnología autorización para adoptar otro tipo de soluciones bajo los normas y
criterios establecidos por ese Ministerio.
Artículo 4. El Ministerio de Ciencia y Tecnología, adelantará los programas de
capacitación de los funcionarios públicos, en el uso del Software Libre desarrollado
con Estándares Abiertos, haciendo especial énfasis en los responsables de las
áreas de tecnologías de información y comunicación, para lo cual establecerá con
los demás órganos y entes de la Administración Pública Nacional los mecanismos
que se requieran.
Artículo 5. El Ejecutivo Nacional fomentará la investigación y desarrollo de software
bajo modelo Software Libre desarrollado con Estándares Abiertos, procurando
incentivos especiales para desarrolladores.
Artículo 6. El Ejecutivo Nacional fortalecerá el desarrollo de la industria nacional del
software, mediante el establecimiento de una red de formación, de servicios
especializados en Software Libre desarrollado con Estándares
Abiertos y desarrolladores.
Artículo 7. El Ministerio de Ciencia y Tecnología será responsable de proveer la
Distribución Software Libre desarrollado con Estándares Abiertos para el Estado
Venezolano, para lo cual implementará los mecanismos que se
requieran.
124
Artículo 8. El Ejecutivo Nacional promoverá el uso generalizado del Software Libre
desarrollado con Estándares Abiertos en la sociedad, para lo cual desarrollará
mecanismos orientados a capacitar e instruir a los usuarios en la utilización del
Software Libre desarrollado con Estándares Abiertos.
Artículo 9. El Ejecutivo Nacional promoverá la cooperación internacional en materia
de Software Libre desarrollado con Estándares Abiertos, con especial énfasis en la
cooperación regional a través del MERCOSUR, CAN, CARICOM y la cooperación
SUR-SUR.
Artículo 10. El Ministerio de Educación y Deportes, en coordinación con el Ministerio
de Ciencia y Tecnología, establecerá las políticas para incluir el Software Libre
desarrollado con Estándares Abiertos, en los programas de
educación básica y diversificada.
Artículo 11. En un plazo no mayor de noventa (90) días continuos, contados a partir
de la publicación del presente Decreto en la Gaceta Oficial de la República
Bolivariana de Venezuela, el Ministerio de Ciencia y Tecnología
deberá presentar ante la Presidencia de la República, los planes y programas que
servirán de plataforma para la ejecución progresiva del presente Decreto.
Artículo 12. Cada Ministro en coordinación con la Ministra de Ciencia y Tecnología,
en un plazo no mayor de noventa (90) días continuos, contados a partir de la
aprobación por parte de la Presidencia de la República de los planes y programas
referidos en el artículo anterior, publicará en la Gaceta Oficial de la República
Bolivariana de Venezuela su respectivo plan de implantación progresiva del
Software Libre desarrollado con Estándares Abiertos, acogiéndose a los
lineamientos contenidos en aquellos, incluyendo estudios de financiamiento e
incentivos fiscales a quienes desarrollen Software Libre con Estándares Abiertos
destinados a la aplicación de los objetivos previstos en el presente Decreto.
Igualmente, las máximas autoridades de sus entes adscritos publicaran a través del
Ministerio de adscripción sus respectivos planes. Los planes de implantación
125
progresiva del Software Libre desarrollado con Estándares Abiertos de los distintos
órganos y entes de la Administración Pública Nacional, deberán ejecutarse en un
plazo no mayor de veinticuatro (24) meses, dependiendo de las características
propias de sus sistemas de información. Los Ministros mediante Resolución y las
máximas autoridades de los entes que le estén adscritos a través de sus respectivos
actos, determinarán las fases de ejecución del referido Plan, así como las razones
de índole técnico que imposibiliten la implantación progresiva del Software Libre en
los casos excepcionales, de acuerdo a lo establecido en el artículo 3 del presente
Decreto.
Artículo 13. El Ministerio de Ciencia y Tecnología establecerá dentro de los planes y
programas contemplados en el presente Decreto, mecanismos que preserven la
identidad y necesidades culturales del país, incluyendo a sus grupos indígenas, para
lo cual procurará que los sistemas operativos y aplicaciones que se desarrollen se
adecuen a su cultura.
Artículo 14. Todos los Ministros quedan encargados de la ejecución del presente
Decreto, bajo la coordinación de la Ministra de Ciencia y Tecnología.
Dado en Caracas, a los días del mes de de dos mil cuatro. Año
194° de la Independencia y 145° de la Federación.
(L.S)
HUGO CHAVEZ FRIAS
Refrendado:
El Vicepresidente de la República
(L.S)
JOSÉ VICENTE RANGEL
Todos los Ministros
