Embed Size (px)
Citation preview
UNIVERSIDAD DE ORIENTENÚCLEO DE MONAGAS
PROGRAMA DE INGENIERÍA DE SISTEMASSUB - COMISION DE TRABAJOS DE GRADO
MATURIN / MONAGAS / VENEZUELA
DESARROLLO DE UN SISTEMA HELP DESK PARA EL CONTROL Y GESTIÓN DE OPERACIONES, REALIZADAS POR LA DIVISIÓN DE
TELEMÁTICA DE LA DIRECCIÓN DE CIENCIA Y TECNOLOGÍA EN LA GOBERNACIÓN DEL ESTADO MONAGAS.
Informe de Pasantías de Grado presentado ante la Comisión de Trabajos de Grado, como requisito para optar al título de Ingeniero en Sistemas
MATURÍN, JULIO DE 2011
BR. ELIO JOSÉ LUCES CÁRDENAS CI: 18.080.219
TUTOR ACADÉMICO: ING. JESÚS CHAPARRO.CI: 4.526.369
TUTOR LABORAL: ING. MARIANN MARTÍNEZ.CI: 13.994.708
UNIVERSIDAD DE ORIENTENÚCLEO DE MONAGAS
PROGRAMA DE INGENIERÍA DE SISTEMASSUB - COMISION DE TRABAJOS DE GRADO
MATURIN / MONAGAS / VENEZUELA
MATURÍN, 15 de Febrero de 20011PIS-STG-MP-007
AUTORIZACIÓN DEL ASESOR LABORAL
En mi carácter de Asesora Laboral del Trabajo Especial de Grado
titulado: DESARROLLO DE UN SISTEMA HELP DESK PARA EL
CONTROL Y GESTIÓN DE OPERACIONES, REALIZADAS POR LA
DIVISIÓN DE TELEMÁTICA DE LA DIRECCIÓN DE CIENCIA Y
TECNOLOGÍA EN LA GOBERNACIÓN DEL ESTADO MONAGAS,
presentado por el ciudadano Elio José Luces Cárdenas, considero que éste reúne
los requisitos y méritos, tanto de forma como de fondo, suficientes para ser
sometido a la evaluación por la Comisión de Trabajo Especial de Grado,
modalidad pasantías, a fin de optar a su aprobación.
_________________________________Ing. Mariann Martínez.
C.I 13.994.708
ii
UNIVERSIDAD DE ORIENTENÚCLEO DE MONAGAS
PROGRAMA DE INGENIERÍA DE SISTEMASSUB - COMISION DE TRABAJOS DE GRADO
MATURIN / MONAGAS / VENEZUELA
MATURÍN, 15 de Febrero de 20011PIS-STG-MP-007
AUTORIZACIÓN DEL ASESOR ACADÉMICO
En mi carácter de Asesora Académico del Trabajo Especial de Grado
titulado: DESARROLLO DE UN SISTEMA HELP DESK PARA EL
CONTROL Y GESTIÓN DE OPERACIONES, REALIZADAS POR LA
DIVISIÓN DE TELEMÁTICA DE LA DIRECCIÓN DE CIENCIA Y
TECNOLOGÍA EN LA GOBERNACIÓN DEL ESTADO MONAGAS,
presentado por el ciudadano Elio José Luces Cárdenas, considero que éste reúne
los requisitos y méritos, tanto de forma como de fondo, suficientes para ser
sometido a la evaluación por la Comisión de Trabajo Especial de Grado,
modalidad pasantías, a fin de optar a su aprobación.
_________________________________Ing. Jesús Chaparro.
C.I. 4.526.369
iii
UNIVERSIDAD DE ORIENTENÚCLEO DE MONAGAS
PROGRAMA DE INGENIERÍA DE SISTEMASSUB - COMISION DE TRABAJOS DE GRADO
MATURIN / MONAGAS / VENEZUELA
APROBACIÓN
Quienes suscriben, Miembros del jurado evaluador designados por la
comisión de Trabajos de Grado de la Escuela de Ingeniería de Sistemas de la
Universidad de Oriente Núcleo Monagas, para examinar el Trabajo de Grado
modalidad pasantía presentado por el Bachiller: Elio José Luces Cárdenas,
portador de la cédula de identidad número:18080219. Titulado: DESARROLLO
DE UN SISTEMA HELP DESK PARA EL CONTROL Y GESTIÓN DE
OPERACIONES, REALIZADAS POR LA DIVISIÓN DE TELEMÁTICA DE
LA DIRECCIÓN DE CIENCIA Y TECNOLOGÍA EN LA GOBERNACIÓN
DEL ESTADO MONAGAS, el cual es presentado para optar al grado
académico de Ingeniero de Sistemas, consideramos que dicho trabajo cumple
con los requisitos exigidos para tal efecto y por tanto lo declaramos:
En la ciudad de Maturín a los días del mes de de dos mil once.
iv
________________________
Miembro Principal
________________________
Miembro Principal
DEDICATORIA
Dedico este trabajo, la culminación de una meta y el inicio de muchísimas
otras, a mis Padres quienes siempre han sido mi fortaleza y ejemplo invaluable
de trabajo y constancia; y a mis hermanas mis más grandes fuentes de
inspiración y ejemplos éxito.
v
AGRADECIMIENTO
Dar las gracias es una pequeña retribución por haber recibido tantas
cosas maravillosas de personas que sin ser su deber, me dieron su apoyo en los
momentos en que menos lo esperaba, por ello; creo que recordar en unas líneas
a todas las personas que han contribuido con el cumplimiento de esta importante
meta en mi vida, es una tarea difícil. Primero que nada debo de dar gracias a
Dios y La virgen María, mi refugio espiritual en los buenos y malos momentos.
A mis Padres, Herman Luces y Betzi Cárdenas quienes me han apoyado
en todas las formas posibles, me considero privilegiado de tenerlos a ustedes. A
mis hermanas, Angélica Luces y Daniela Luces, ustedes me enseñaron que si se
quiere alcanzar el éxito debes convertir cada paso en una meta y cada meta en
mi siguiente paso. A todos mis tíos y primos quienes me han brindado su cariño
sincero y aliento de esperanza.
A la Sra. Ana Murillo que siempre me brindo un cariño de madre y del
cual estoy muy agradecido. A todos mis amigos quienes compartieron la inmensa
aventura llamada UDO y que lamentablemente es irrepetible, en especial a:
Anajanit Padrón, Pedro Rodríguez, Yuraulis Pino, Renán Guzmán, Zairen
Torres, Diana García, Paola López, Albanis Ojeda.
Al equipo de la Dirección General de Ciencia y Tecnología quienes me
brindaron la oportunidad de trabajar con ustedes. Al Ing. Jesús Chaparro mi
tutor académico a quien admiro por su profesionalismo y dedicación al trabajo.
vi
UNIVERSIDAD DE ORIENTENÚCLEO DE MONAGAS
PROGRAMA DE INGENIERÍA DE SISTEMASSUB - COMISION DE TRABAJOS DE GRADO
MATURIN / MONAGAS / VENEZUELA
Desarrollo de un sistema help desk para el control y gestión de operaciones,
realizadas por la división de Telemática de la Dirección de Ciencia y Tecnología
en la Gobernación del estado Monagas.
Autor: Elio José Luces Cárdenas. Tutor académico: Ing. Jesús Chaparro
C.I: 18.080.219 CI. 4.526.369
Febrero de 2011
RESUMENEste investigación tiene como objetivo el desarrollo de un sistema help
desk para el control y gestión de operaciones, realizadas por la división de Telemática de la Dirección de Ciencia y Tecnología en la Gobernación del estado Monagas; que permitirá apoyar la labor de los usuarios, garantizando la explotación eficiente de los recursos involucrados. Este trabajo está desarrollado en el área de sistemas de información transaccionales, bajo la modalidad de proyecto factible. Para su desarrollo fue empleada una combinación de la metodología de sistemas blandos de Peter Checkland y la metodología de proceso unificado UP, usando como lenguaje de modelado de diagramas UML. Se levanto información concerniente a entorno y los requerimientos del sistema, así como las impresiones de los usuarios involucrados, las cuales corroboraron la necesidad de desarrollo del sistema. Basándose en la información obtenida mediante la utilización de las distintas técnicas de recolección de datos se procedió al desarrollo de las interfaces del sistema, obteniéndose la versión Beta del mismo. Durante el desarrollo de este sistema de información se aplicaron las normas de calidad ISO/IEC TR 9126-3:2003 mismas que representan la calidad del software en los estados de evolución intermedios y finales no ejecutables. Se recomienda mantener el diseño de la interfaces en casos de futuras ampliaciones del software para así mantener la homogeneidad de la herramienta.
vii
Descriptores: Help Desk, UP, UML, version Beta.
viii
INDICE GENERAL
1.1 Gobernación del Estado Monagas......................................................................25
1.1.1 Misión y Visión..................................................................................................26
1.1.2 Naturaleza y Objetivos.....................................................................................26
1.2 Dirección General de Ciencia y Tecnología......................................................27
1.2.1 Visión.................................................................................................................29
1.2.2 Misión................................................................................................................29
1.2.3 Objetivo Institucional.......................................................................................30
1.2.4 Objetivos específicos....................................................................................30
1.2.5 Organigrama de la Dirección General de Ciencia y Tecnología..................30
2.1 Planteamiento del Problema...............................................................................32
2.2 Objetivos de la investigación..............................................................................35
2.2.1 Objetivo general................................................................................................35
2.2.1 Objetivos Específicos........................................................................................35
ix
AUTORIZACIÓN DEL ASESOR LABORAL............................................................ii
AUTORIZACIÓN DEL ASESOR ACADÉMICO.....................................................iii
APROBACIÓN............................................................................................................iv
DEDICATORIA............................................................................................................v
AGRADECIMIENTO..................................................................................................vi
RESUMEN..................................................................................................................vii
INTRODUCCIÓN.......................................................................................................22
CAPÍTULO I...............................................................................................................25
CONTEXTO ORGANIZACIONAL...........................................................................25
CAPITULO II..............................................................................................................32
EL PROBLEMA Y SUS GENERALIDADES...........................................................32
2.3 Justificación de la Investigación.........................................................................36
2.4 Alcance de la Investigación.................................................................................36
3.1 Antecedentes de la Investigación........................................................................38
3.2 Bases Teóricas......................................................................................................39
3.2.1 Sistemas de Información...........................................................................39
3.2.2 Sistemas de información Transaccionales...............................................40
3.2.3 Help Desk...................................................................................................40
3.2.4 Proceso Unificado (UP).............................................................................41
3.2.5 Fases del Proceso Unificado.....................................................................42
3.2.6 UML............................................................................................................43
3.2.7 Diagramas de UML...................................................................................44
3.2.8 Metodología de sistemas Blandos de Peter Checkland..........................54
3.2.9 Bases de Datos............................................................................................56
3.2.9.1 Características de las bases de datos....................................................56
3.2.9.2 Tipos de Bases de Datos.........................................................................56
3.2.10 PHP...........................................................................................................58
3.2.11 Postgre SQL.............................................................................................59
3.2.12 Java script................................................................................................60
3.3 Bases Legales........................................................................................................60
3.3.1 Decreto 3390, publicado en gaceta oficial N° 38.095 de fecha 28/12/2004..............................................................................................................................60
x
CAPITULO III............................................................................................................38
MARCO REFERENCIAL..........................................................................................38
3.4 Definición de Términos.......................................................................................64
4.1 Tipo y Nivel de investigación..............................................................................65
4.2 Población y Muestra............................................................................................66
4.3 Técnicas e instrumentos de Recolección de Datos............................................67
4.4 Técnicas de análisis de datos...............................................................................69
4.5 Diseño Operativo.................................................................................................70
4.6 Cuadro Operativo................................................................................................73
5.1 Etapa I: Especificación conceptual y análisis de los requerimientos..............76
5.1.1 Análisis de encuestas........................................................................................77
5.1.2 Entregables de la Etapa I: Especificación conceptual y análisis de los requerimientos...........................................................................................................81
Visión..........................................................................................................................82
Plan de desarrollo de software...............................................................................106
Plan de Administración de Riesgos........................................................................126
Plan de Iteración General.......................................................................................134
Modelado del Negocio.............................................................................................141
Realizar Instalación y Configuración.............................................................148
Realizar Traslado.............................................................................................154
Actualizar, configurar e Instalar programas y aplicaciones.......................160
Realizar Mantenimiento Correctivo...............................................................167
Asesorar, configurar e Instalar redes y servidores.....................................174
Realizar mantenimiento de aplicaciones........................................................181
xi
CAPITULO IV............................................................................................................65
MARCO METODOLOGICO.....................................................................................65
CAPITULO V..............................................................................................................76
RESULTADOS...........................................................................................................76
Desarrollar aplicaciones..................................................................................187
Realizar solicitud de servicio...........................................................................193
5.2 Etapa II: Diseño inicial y codificación.............................................................199
5.2.1 Entregables de la Etapa II: Diseño Inicial y Codificación..........................199
Especificación de Caso de Uso del Sistema:..........................................................200
Autenticar Usuario..................................................................................................200
Reportar incidente Telemático........................................................................210
Reasignar solicitud...........................................................................................218
Consultar solicitudes pendientes.....................................................................226
Consultar estado de solicitudes.......................................................................233
Registrar servicio de solicitudes pendientes...................................................240
Registrar usuario..............................................................................................248
Registrar Equipo de Hardware.......................................................................256
Registrar Equipo de Redes y Servidores........................................................264
Registrar Equipo de Comunicaciones............................................................272
Registrar Sistema.............................................................................................280
Especificaciones Complementarias........................................................................288
Documento Arquitectura........................................................................................304
5.3 Etapa III: Construcción....................................................................................314
5.3.1 Entregables de la Etapa III: Construcción...................................................314
Plan de Pruebas.......................................................................................................315
Especificación de Caso de Prueba:.................................................................326
Reportar Incidente Telemático.......................................................................326
xii
Especificación de Caso de Prueba:.................................................................329
Registrar Equipo de Hardware.......................................................................329
Glosario.....................................................................................................................333
5.4 Análisis Costo- Beneficio...................................................................................341
LISTA DE FIGURAS
Figura 1.Estructura organizativa del la Gobernación del Estado Monagas........28
Figura 2. Organigrama de la Dirección General de Ciencia y Tecnología..........31
xiii
CONCLUSIONES.....................................................................................................348
RECOMENDACIONES...........................................................................................350
BIBLIOGRAFÍA.......................................................................................................351
ANEXOS...................................................................................................................354
Figura 4. Ejemplo de un diagrama de clases...........................................................47
Figura 5. Ejemplo de un diagrama de caso de uso.................................................49
Figura 6. Ejemplo de un diagrama de actividad.....................................................51
Figura 7. Ejemplo de un diagrama de secuencia....................................................52
Figura 8. Ejemplo de diagrama de despliegue........................................................53
Figura 9. Fases e Hitos de UP................................................................................120
Figura 10. Plan de iteración primera fase.............................................................139
Figura 11. Plan de iteración segunda fase.............................................................139
Figura 12. Plan de iteración tercera fase...............................................................140
xiv
LISTA DE CUADROS
Cuadro 1. Diagramas de UML 44
Cuadro 2. Cuadro Operacional 74
Cuadro 3. Sentencia que define el problema 87
Cuadro 4. Sentencia que define la posición del Producto 88
Cuadro 5. Resumen de Stakeholders 89
Cuadro 6. Resumen de Usuarios 90
Cuadro 7. Requerimientos del sistema 90
Cuadro 8. Entorno de usuario 91
Cuadro 9. Perfil de los Stakeholders : Jefe de la división de Telemática de la
Dirección de Ciencia y Tecnología. 91
Cuadro 10. Perfil de los Stakeholders: Representantes del área técnica y
sistemas de información 92
Cuadro 11. Perfil de los Stakeholders: Representantes del área técnica y
sistemas de información 92
Cuadro 12. Perfiles de Usuario: Ing. Ángel Farías Director de la Organización.
93
Cuadro 13. Perfiles de Usuario: Tsu. José Ramírez Jefe de la División de
Telemática. 93
Cuadro 14. Perfiles de Usuario: Coordinadores de la División de Telemática 94
Cuadro 15. Perfiles de Usuario: Analistas adscritos a las coordinaciones de la
división de Telemática 94
Cuadro 16. Perfiles de Usuario: Personal adscrito a la Gobernación del Esto
Monagas 95
Cuadro 17. Resumen de características del producto 96
Cuadro 18. Requerimientos Materiales para el desarrollo del proyecto 97
xv
Cuadro 19. Atributos de características 102
Cuadro 20. Roles y Responsabilidades 117
Cuadro 21. Plan de fases 118
Cuadro 22. Hitos que marcan el final de cada fase de UP 119
Cuadro 23. Disciplinas / Artefactos generados o modificados durante la Fase de
Inicio 121
Cuadro 24. Disciplinas / Artefactos generados o modificados durante la Fase de
Elaboración 122
Cuadro 25. Disciplinas / Artefactos generados o modificados durante la Fase de
Construcción 123
Cuadro 26. Modelo de cuadro identificador de riesgos 130
Cuadro 27. Elementos de riesgos a mitigar 131
Cuadro 28. Lista Actor-Objetivo 146
Cuadro 29. Reglas del negocio. 294
Cuadro 30. Métrica de Adecuación 296
Cuadro 31. Métrica de Seguridad. 296
Cuadro 32. Métrica de Madurez 298
Cuadro 33. Métrica de Aprendibilidad. 300
Cuadro 34. Métrica de Comportamiento 301
Cuadro 35. Métrica de Cambiabilidad 303
Cuadro 36. Prueba de la integridad de los datos y de la base de datos 320
Cuadro 37. Prueba de Funcionalidad 320
Cuadro 38. Prueba de Interfaz del Usuario 321
Cuadro 39. El Perfil de Funcionamiento 322
Cuadro 40. Herramientas para pruebas 322
Cuadro 41. Roles de Pruebas 323
Cuadro 42. Recursos del sistema 324
xvi
Cuadro 43. Recursos de hardware 324
Cuadro 44. Actividades de prueba 325
Cuadro 45. Resultados de las pruebas 325
Cuadro 46. Beneficios tangibles- solicitud de servicio 342
Cuadro 47. Beneficios Tangibles-Generación de informe técnico de solicitud de
servicio 343
Cuadro 48. Beneficios Tangibles-Generación de informe de gestión. 343
Cuadro 49. Resumen de costos-Consumibles 347
xvii
LISTA DE GRÁFICOS
Gráfico 1. Porcentaje de usuarios que hacen uso de cada Coordinación de la
DGCT..........................................................................................................................78
Gráfico 2. Conocimiento de los usuarios, acerca de donde recurrir para solicitud
de servicio...................................................................................................................78
Gráfico 3. Frecuencia en las solicitudes de servicio son resueltas a tiempo.........79
Gráfico 4.Medios empleados por los usuarios para la solicitud de servicios.......79
Gráfico 5. Necesidad de los usuarios de un sistema web........................................80
Gráfico 6. Funcionalidades y/o características deseadas por los usuarios...........80
xviii
LISTA DE DIAGRAMAS
Diagrama 1. Caso de uso general del negocio.......................................................144
Diagrama 2. Vista del modelo de dominio del negocio.........................................145
Diagrama 3. Especificación de Caso de Uso del negocio: Realizar Instalación y
configuración............................................................................................................151
Diagrama 4. Diagrama de actividad- Realizar instalación y configuración......153
Diagrama 5. Especificación de Caso de Uso del negocio: Realizar Traslado.....157
Diagrama 6. Diagrama de actividad- Realizar traslado......................................159
Diagrama 7. Especificación de Caso de Uso del negocio: Actualizar, configurar e
Instalar programas y aplicaciones........................................................................163
Diagrama 8. Diagrama de actividad- actualizar, configurar e instalar programas
y aplicaciones............................................................................................................166
Diagrama 9. Especificación de Caso de Uso del negocio: Realizar Mantenimiento
Correctivo.................................................................................................................170
Diagrama 10. Diagrama de actividad-Realizar Mantenimiento Correctivo......173
Diagrama 11. Especificación de Caso de Uso del negocio: Asesorar, configurar e
instalar redes y servidores......................................................................................177
Diagrama 12. Diagrama de actividad-Asesorar, configurar e instalar redes y
servidores..................................................................................................................180
Diagrama 13. Especificación de Caso de Uso del negocio: Realizar
mantenimiento de aplicaciones...............................................................................184
Diagrama 14. Diagrama de actividad- Realizar mantenimiento de aplicaciones
...................................................................................................................................186
Diagrama 15. Especificación de Caso de Uso del negocio: Desarrollar
aplicaciones...............................................................................................................190
Diagrama 16. Diagrama de Actividad-Desarrollar aplicaciones.........................192
xix
Diagrama 17. Especificación de Caso de Uso del negocio: Realizar Solicitud de
servicio......................................................................................................................196
Diagrama 18. Diagrama de actividad-Realizar Solicitud de servicio.................198
Diagrama 19. Caso de uso general del Sistema.....................................................203
Diagrama 20. Especificación de Caso de Uso del Sistema: Autenticar Usuario 204
Diagrama 21. Diagrama de Clases- Autenticar usuario.....................................206
Diagrama 22. Diagrama de secuencia Autenticar Usuario..................................206
Diagrama 23. Especificación de Caso de Uso del Sistema: Reportar incidente
telemático..................................................................................................................213
Diagrama 24. Diagrama de clase- reportar incidente telemático........................215
Diagrama 25. Diagrama de secuencia: Reportar incidente telemático...............216
Diagrama 26. Especificación de Caso de Uso del Sistema: Reasignar solicitud 221
Diagrama 27. Diagrama de clases- Reasignar solicitud......................................223
Diagrama 28. Diagrama de secuencia: Reasignar solicitud.................................224
Diagrama 29. Especificación de Caso de Uso del Sistema: Consultar solicitudes
pendientes.................................................................................................................229
Diagrama 30. Diagrama de clase - Consultar solicitudes pendientes.................230
Diagrama 31. Diagrama de secuencia - Consultar solicitudes pendientes........231
Diagrama 32. Especificación de Caso de Uso del Sistema: Consultar estado de
solicitudes.................................................................................................................236
Diagrama 33. Diagrama de Clase - Consultar estado de solicitudes...................237
Diagrama 34. Diagrama de secuencia: Consultar estado de solicitudes.............238
Diagrama 35. Especificación de Caso de Uso del Sistema: Registrar servicio de
solicitudes pendientes..............................................................................................243
Diagrama 36. Diagrama de Clase - Registrar Servicio de solicitudes pendientes.
...................................................................................................................................245
xx
Diagrama 37. Diagrama de secuencia: Registrar servicio de solicitudes
pendientes.................................................................................................................246
Diagrama 38. Especificación de Caso de Uso del Sistema: Registrar usuario...251
Diagrama 39. Diagrama de clase - Registrar usuario..........................................253
Diagrama 40.Diagrama de secuencia: Registrar usuario....................................254
Diagrama 41. Especificación de Caso de Uso del Sistema: Registrar equipo....259
Diagrama 42. Diagrama de clase - Registrar equipo de Hardware....................261
Diagrama 43. Diagrama de secuencia: Registrar equipo.....................................262
Diagrama 44. Especificación de Caso de Uso del Sistema: Registrar equipo de
Redes y Servidores...................................................................................................267
Diagrama 45. Diagrama de clase - Registrar equipo de Redes y Servidores....269
Diagrama 46. Diagrama de secuencia: Registrar equipo de Redes y Servidores
...................................................................................................................................270
Diagrama 47. Especificación de Caso de Uso del Sistema: Registrar equipo de
comunicaciones........................................................................................................275
Diagrama 48. Diagrama de clase - Registrar equipo de Comunicaciones..........277
Diagrama 49. Diagrama de secuencia: Registrar equipo de Comunicaciones...278
Diagrama 50. Especificación de Caso de Uso del Sistema: Registrar sistema...283
Diagrama 51. Diagrama de clase - Registrar sistema...........................................285
Diagrama 52. Diagrama de secuencia: Registrar sistema....................................286
Diagrama 53. Modelo Conceptual..........................................................................309
Diagrama 54. Modelo Físico...................................................................................310
Diagrama 55. Modelo de base de datos..................................................................311
Diagrama 56. Modelo de despliegue del sistema SELAIT...................................312
xxi
LISTA DE INTERFACES
Interfaz 1. Login de Usuario...................................................................................207
Interfaz 2. Menú usuario Administrador..............................................................207
Interfaz 3. Menú usuario Coordinador.................................................................208
Interfaz 4. Menú usuario Analista.........................................................................208
Interfaz 5. Menú super-usuario..............................................................................209
Interfaz 6. Menú usuario-organismos....................................................................209
Interfaz 7. Reportar incidente telemático..............................................................217
Interfaz 8. Consulta de solicitudes pendientes......................................................225
Interfaz 9. Ficha de incidencia...............................................................................225
Interfaz 10. Consultar solicitudes Pendientes.......................................................232
Interfaz 11. Consultar estado de solicitudes..........................................................239
Interfaz 12. Consulta de solicitudes Pendientes....................................................247
Interfaz 13. Registro de Actividades por solicitud................................................247
Interfaz 14. Opciones de submenú personal.........................................................255
Interfaz 15. Formulario de registro.......................................................................255
Interfaz 16. Registro de equipo de hardware........................................................263
Interfaz 17. Selección de coordinación y tipo de equipo......................................271
Interfaz 18. Registro de redes.................................................................................271
Interfaz 19. Registro de equipo de comunicaciones..............................................279
Interfaz 20. Registrar Nueva Aplicación...............................................................287
xxii
INTRODUCCIÓN
Actualmente el ritmo acelerado que vive el mundo organizacional, lo ha
obligado aumentar verticalmente la búsqueda de eficiencia y productividad, este
vertiginoso movimiento a originado un importante interés en las organizaciones
del siglo XXI en los sistemas de información como herramienta para el manejo
de información valiosa, considerada como un bien invaluable de la empresa y
que no es solo un subproducto de la conducción empresarial sino que a la vez
alimenta los negocios y puede ser uno de los tantos factores críticos que
determinan el éxito.
La tecnología y la información son las nuevas formas de medir la
competencia de una organización, por tal razón la permanencia en el tiempo de
las mismas dependerá en gran medida de la manera en que administren, entre
otros elementos, sus recursos tecnológicos y de información, aunado al hecho de
evolucionar con ellos y adaptarse a los cambios del mundo organizacional. Este
fenómeno afecta a todos los sectores tanto privados como públicos; ya no sólo es
obtener utilidades o prestar un servicio sino más bien aumentar la seguridad del
cliente sin sacrificar los recursos de la organización y prestar un buen servicio
de la manera más eficiente ahorrando en gastos operativos.
La Dirección General de Ciencia y Tecnología del Estado Monagas
(DGCT), es un organismo público adscrito a la Gobernación del Estado, que
como toda organización con miras a la excelencia está interesada en desarrollo
de tecnologías que permitan aumentar la eficiencia y eficacia en sus operaciones,
a fin de posicionarse como un organismo sólido con gran potencial en la
prestación de servicios de calidad, y capaz de manejar con eficiencia su área
operativa en el estado.
Para la DGCT, la División de Telemática constituye un departamento de
gran importancia y funcionalidad para el cumplimiento de sus metas y objetivos
institucionales; en este contexto y enmarcada en el objetivo de alcanzar el mejor
y mayor nivel de servicio, la División de Telemática procede a desarrollar un
sistema Help Desk destinado a control y gestión de las operaciones realizadas
por la División en los distintos organismos adscritos a la Gobernación del Estado
Monagas.
Para el desarrollo del trabajo presentado a continuación, fue empleada la
metodología de Proceso Unificado (UP); enmarcada bajo la modalidad de
proyecto factible y con un nivel de investigación descriptiva. El trabajo esta
esquematizado en cinco (5) capítulos dispuestos de la siguiente manera:
Capítulo I: Contexto Organizacional.
Esta sección contiene información de interés acerca de la Gobernación del
Estado Monagas y la Dirección General de Ciencia y Tecnología del estado
Monagas, entre los que destacan: una breve reseña histórica, organigramas
funcionales, misión y visión.
Capítulo II: El problema y sus generalidades.
Este bloque está integrado por la descripción del problema presentado en
la Dirección General de Ciencia y Tecnología, así como los objetivos generales y
específicos a alcanzar durante la investigación.
Capítulo III: Marco referencial.
En esta parte del documento se encuentran referenciados los antecedentes
de investigación, las bases teóricas del proyecto, las bases legales sobre las cuales
se sienta la investigación y la definición de términos básicos referenciado a los
largo del proyecto.
25
Capítulo IV: Marco Metodológico.
En este segmento se encuentran esquematizados el tipo y nivel de
investigación, la población y muestra, las técnicas de recolección de datos, las
técnicas de análisis de datos y el diseño operativo.
Capitulo V: Resultados.
En este capítulo se presentan los resultados obtenidos a lo largo de la
investigación, en concordancia con el objetivo general establecido; de igual
forma el desarrollo de un sistema help desk para el control y gestión de
operaciones, realizadas por la división de Telemática de la Dirección de Ciencia
y Tecnología en la Gobernación del estado Monagas. Al finalizar este capítulo se
presentan las conclusiones y recomendaciones, al igual que la bibliografía de
referencia y los anexos como herramientas para sustentar la investigación.
26
CAPÍTULO I
CONTEXTO ORGANIZACIONAL
1.1 Gobernación del Estado Monagas
La sede de la gobernación bolivariana de Monagas se encuentra frente a la
Plaza Bolívar de Maturín. Es una edificación contratada el 31 de enero de 1945
con la empresa sociedad de Arquitectura y construcciones S.A.C. por la cantidad
de Bs. 420.000,00. Por resolución del 15 de noviembre de 1946 se erogan Bs.
25.000,00 como anticipo a Ángel María Rousse, representante de la
constructora. Esta hermosa casona entró en servicio en el año de 1949. El 6 de
enero de 1952 el entonces gobernador Guerrero Gori decretó su
reacondicionamiento. Luego el gobernador Pablo Morillo la mandó de nuevo a
restaurar. Esta casona ha recibido el mantenimiento adecuado para lucir tal
como la podemos observar hoy y en su interior funcionan algunas dependencias
y direcciones de la gobernación, tales como: el Despacho del Gobernador, la
Secretaria Privada, Administración, Hacienda, Tesorería, Correo y otros. A raíz
del proceso de centralización, la gobernación creo nuevas alternativas que a
través del tiempo se han ido mejorando.
Actualmente se encuentra ejerciendo el cargo de Gobernador del Estado
Monagas, José Gregorio Briceño, el cual fue elegido el 31 de octubre del año
2004 y reelegido en el año 2008. La Gobernación Bolivariana de Monagas es el
organismo constituyente del Poder que conjuntamente con el Poder Legislativo
(Consejo Legislativo del estado Monagas CLEM) conforman el Poder Público
Estatal, cuyo ente efectivo, dinámico, eficiente, ajustado a la Constitución y las
27
leyes que rigen el logro de un desarrollo integral que permite el fortalecimiento
de la Constitución Democrática.
1.1.1 Misión y Visión.
La gobernación bolivariana del estado Monagas se visualiza como una
institución eficiente y debidamente descentralizada, capaz de satisfacer en forma
efectiva a través de la gestión de un personal altamente capacitado y valorizado
y con los recursos materiales suficientes, con el objetivo de promover e impulsar
las actividades económicas, de manera que se puedan aprovechar las ventajas
comparativas de la entidad, en función de mejorar la calidad de vida de toda la
comunidad monaguense.
Asimismo atender la demanda y necesidades de la población en los
sectores de Seguridad, Salud, Educación, Cultura, Deporte, Infraestructura y
Desarrollo Social acorde a la vialidad ambiental y con el objeto de reducir la
pobreza y elevar el nivel del monaguense. Todo esto a través de una gestión de
gobierno caracterizada por la legalidad, honestidad, transparencia, eficiencia,
eficacia y calidad.
1.1.2 Naturaleza y Objetivos
La Gobernación del Estado Monagas, es el órgano encargado de cumplir
y hacer cumplir la Constitución y las leyes del Estado. También se encarga de
suministrar, controlar y manejar el presupuesto, basado en los lineamientos de
la política presupuestaria, que regirá para el sector público del Estado, los
cuales se corresponden con el programa de ajuste económico, acordado por el
gobierno nacional, permitiendo de esta manera, se pueda desarrollar y ampliar
sus labores satisfactoriamente, cumpliendo a su vez con lo dispuesto en la Ley de
28
Presupuesto, donde los aportes otorgados estén acordes con las funciones y
objetivos básicos para los cuales fueron creados.
Por esta razón las transacciones gubernamentales, que regirán lo dispuesto
en la Ley de Presupuesto, estarán encaminadas a lograr la racionalización del
gasto público, de manera tal que su efecto en el orden social, contribuya a elevar
el nivel de calidad de vida de su población.
Entre los objetivos de la Gobernación del Estado Monagas se pueden
mencionar los siguientes:
A. Promover la acción coordinada para el mantenimiento de los servicios
públicos.
B. Recibir y manejar y manejar los fondos del estado
C. Prestar los servicios necesarios para llevar a cabo el plan anual del
gobierno
D. Incorporar la planificación del desarrollo del Estado.
E. Formatear el desarrollo económico, la instrucción pública, la cultura,
educación el progreso del estado en todas sus funciones como: salud,
vivienda, administración de justicia.
El organigrama de la Gobernación del estado Monagas se encuentra
ampliado en la Error: Reference source not found.
29
1.2 Dirección General de Ciencia y Tecnología
La dirección de ciencia y tecnología fue creada el 18 de Mayo de 2003 por el
Gobernador del Estado Monagas, con la misión de asesorar al Gobierno
Regional en el campo de la ciencia y tecnología, en conjunto con el FONACIT, y
bajo los lineamientos Nacionales del Ministerio de ciencia y tecnología. Actúa
como la institución adscrita a la Gobernación del Estado.
Esta organización cuenta con un nivel organizativo considerable, se encarga
de regular, formular y hacer seguimientos de las políticas, la planificación y
realización de actividades del Ejecutivo Regional para la creación de un
verdadero sistema científico y tecnológico; orientar las investigaciones científicas
y
30
28
Figura 1.Estructura organizativa del la Gobernación del Estado Monagas.
Fuente. Gobernación del Estado Monagas (2009).
32
tecnológicas a fin de contribuir de forma determinante, a satisfacer los
requerimientos de la población y a dinamizar todo el sistema productivo de la
región; fortalecer, coordinar e integrar el sistema tecnológico en concordancia
con las demandas de las cadenas productivas, promoviendo y multiplicando los
procesos de innovación y transferencia.
También es responsabilidad de esta dirección fortalecer el estudio de
postgrados como instancia fundamental para cultivar el desarrollo científico,
tecnológico y humanístico de la región, en la Secretaria de Educación, Cultura y
Deporte, como también deberá interrelacionarse con los entes u organismos que
formen parte del aparato productivo, en coordinación con la secretaria de
asuntos económicos. La Dirección de Ciencia y Tecnología está ubicada en la
Zona Industrial de Maturín, sector la Cruz, Estadio Monumental.
1.2.1 Visión
Orientar la generación y uso de conocimientos y tecnología hacia el
bienestar social, elevando la calidad de vida.
Entrelazar la investigación con los actores fundamentales de la sociedad
(comunidad-universidad-productores-entes del gobierno) para la formación de
un sistema regional de ciencia, tecnología e innovación.
1.2.2 Misión
Promover la generación y apropiación del conocimiento, la ciencia, la
tecnología y la innovación para impulsar el mejoramiento del estándar de la
calidad de vida del individuo, así como fortalecer el desarrollo de los diferentes
sectores productivos del Estado Monagas, mediante el aporte de soluciones
eficientes en armonía con el medio ambiente actuando bajo los lineamientos
emanados del Ministerio de Ciencia y Tecnología.
33
1.2.3 Objetivo Institucional
Diseñar y ejecutar proyectos de investigación científica y tecnológica
relacionados directamente con el Plan Nacional de Desarrollo Económico y
Social de la Nación (PNDES 2002-2007), con el nuevo mapa estratégico del país y
con los cinco grandes equilibrios (económico, social, político, territorial e
internacional) a fin de impulsar el desarrollo económico del estado y alcanzar la
justicia social, donde la persona y la sustentabilidad ambiental son hegemónicos.
1.2.4 Objetivos específicos
A. Liderar el desarrollo de la ciencia y la tecnología en el Estado Monagas.
B. Establecer planes que contribuyan al fortalecimiento de la investigación
científica y tecnológica.
C. Cooperar con los centros e institutos de investigación.
D. Impulsar el desarrollo de nuevas tecnologías que requieran los sectores
regionales.
E. Propiciar la creación de premios y becas a los efectos de estimular el
desarrollo de actividades de Ciencia y Tecnología.
1.2.5 Organigrama de la Dirección General de Ciencia y Tecnología.
En la Figura 2, se encuentra detalla da la estructura organizativa de la
Dirección de Ciencia y Tecnología del Estado Monagas.
34
Figura 2. Organigrama de la Dirección General de Ciencia y Tecnología.
Fuente. Dirección General de Ciencia y Tecnología (2009).
35
CAPITULO II
EL PROBLEMA Y SUS GENERALIDADES
2.1 Planteamiento del Problema
La necesidad de control y manejo de grandes volúmenes de información
en las organizaciones a nivel mundial son cada vez mayores, al punto de que es
un requisito indispensable para definir la competitividad de las mismas frente a
otras organizaciones cada vez más pujantes en un mercado común. Frente a las
nuevas áreas de competencia empresarial, cada vez más líderes organizacionales
destinan recursos al cuidado y desarrollo de las capacidades de la organización
para el manejo de recursos invaluables como es el caso de la información.
Llevar un control eficiente de las actividades que realiza una
organización y de los recursos asignados a ellas es de vital importancia para
medir el desempeño de las mismas y de esta forma facilitar el control y la toma
de decisiones efectiva a nivel gerencial. Las actuales demandas de información
abren campo a la introducción de nuevos conceptos que pueden llegar a
potencializar la organización dentro del ámbito de operaciones si se le da el
adecuado manejo, reconocimiento y medición; en este sentido los sistemas de
información desempeñan un importante papel como elemento de control y
organización, mismos que están orientados a lograr una alta competitividad
frente a un entorno cada vez más fuerte y agresivo.
La Dirección General de Ciencia y Tecnología del Estado Monagas
(DGCT) es un organismo adscrito a la Gobernación del estado Monagas y es la
encargada de regular, formular y hacer seguimientos de las políticas, la
planificación y realización de actividades del Ejecutivo Regional para la creación
de un verdadero sistema
científico y tecnológico; en su ámbito de operaciones se encuentra el orientar las
investigaciones científicas y tecnológicas a fin de contribuir de forma
determinante, el satisfacer los requerimientos de la población y a dinamizar todo
el sistema productivo de la región; fortalecer, coordinar e integrar el sistema
tecnológico en concordancia con las demandas de las cadenas productivas,
promoviendo y multiplicando los procesos de innovación y transferencia.
La Dirección General de Ciencia y Tecnología está conformada por un
conjunto de departamentos que funcionan como engranajes para lograr el éxito
en las operaciones del organismo en general, esto con el fin de cumplir con los
objetivos del Ejecutivo Regional de consolidar un sólido sistema científico y
tecnológico en el estado. La división de Telemática es un departamento de la
DGCT, esta cubre un campo científico y tecnológico de una considerable
amplitud, englobando el estudio, diseño, gestión y aplicación de las redes y
servicios de comunicaciones, para el transporte, almacenamiento y procesado de
información, incluyendo el análisis y diseño de tecnologías y sistemas de
computación. Entre sus funciones se encuentra: formular, ejecutar y controlar
los planes, programas y proyectos que debe desarrollar la DGCT para el
cumplimiento de sus funciones.
Una función de la División de Telemática es el coordinar en las distintas
dependencias de la Gobernación, la elaboración de estudios y diseños de
tecnologías que permitan la completa integración telemática en el ente rector del
estado. La División de Telemática tiene injerencia en el análisis y diseño de
sistemas de información, al igual que el establecer los estándares de los equipos
de hardware y software usados por las distintas Secretarías, Direcciones y otros
organismos adjuntos a la Gobernación del Estado; también es de su competencia
el mantener la infraestructura de telecomunicaciones y cableado de redes en
perfecto funcionamiento.
Las actividades que realiza la División de Telemática en los distintos
organismos generan un alto flujo de información concerniente a las actividades
llevadas a cabo por las distintas coordinaciones de la división (Aplicaciones,
Sitios de Redes, Comunicaciones, Soporte en Sitio) en cada uno de los
organismos dependientes de la Gobernación del Estado en que realice alguna
actividad. Esta información es de vital importancia puesto que es un aval del
trabajo realizado y en ella se documenta a detalle la novedad y los medios de
solución, así como los recursos utilizado en cada actividad.
La información generada por la División de Telemática es utilizada por la
dirección general para apoyar la toma de decisiones y así garantizar el control
en las operaciones. Cabe destacar que la forma de generar, manejar y analizar
la información es mediante el uso de herramientas tradicionales de ofimática
(como Word y Excel), por lo cual para la dirección le es difícil el analizar y
estudiar toda la información que se maneja periódicamente. Cada uno de los
coordinadores de la División de Telemática deben presentar en reuniones
periódicas el resultado de las actividades, para ello deben analizar la
información perteneciente a su respectiva coordinación y presentarla a la
dirección; en este proceso muchas veces se pierden datos de interés y no se
toman en cuenta medidas de rendimiento, que den una idea clara de las
actividades realizadas.
La asignación de recurso humano es un factor clave para cada
coordinación, puesto que con esto se pretende distribuir de manera equitativa,
de acuerdo a la necesidad, al personal disponible; y de esta forma distribuir las
cargas de trabajo para el correcto funcionamiento de cada coordinación. Uno
de los mayores contra tiempos presentados en la División es la forma en que los
usuarios solicitan colaboración por parte de las distintas coordinaciones. Esta
acción la mayoría de las veces es realizada por teléfono, sin protocolo definido, y
debido a la falta de conocimientos en el área de muchos usuarios, se tiene una
descripción del la novedad carente de detalles y poco confiable; razón por la
cual, en algunos casos, se incurre en la asignación del personal incorrecto a la
realización de ciertas actividades.
El norte de la organización es la automatización y el ahorro de
materiales, y como se expuso anteriormente las actividades generadas por cada
una de las coordinaciones de la División de Telemática generan una gran
cantidad de información que es llevada de manera física, lo cual genera grandes
volúmenes de papel, poco prácticos para el manejo. La falta de información
congruente que permita la toma de decisiones efectiva hace más difícil el control
de gestión de la división y por ende de la Dirección de Ciencia y Tecnología,
tomando muchas veces decisiones poco acertadas o que cubran a cabalidad las
necesidades de la dirección.
Ante la problemática planteada se infiere la necesidad de desarrollar un
sistema de información que automatice las actividades de la división de
telemática y facilite la toma de decisiones tanto a nivel de división como de
dirección. El sistema planteado debe permitir a los coordinadores la asignación
efectiva de personal y la mejor documentación de sus operaciones; así como el
mejor manejo las novedades notificadas por los usuarios de los distintos
organismos.
2.2 Objetivos de la investigación
2.2.1 Objetivo general
Desarrollar un sistema Help Desk para el control y gestión de
operaciones, realizadas por la división de Telemática de la dirección de Ciencia y
Tecnología en los distintos organismos adscritos a la gobernación del estado
Monagas.
2.2.1 Objetivos Específicos.
A. Estudiar los procedimientos para la gestión, control y monitoreo
de operaciones realizadas por la división de Telemática.
B. Establecer un modelo de funcionamiento del sistema, acorde con
las políticas de la organización.
C. Diseñar los componentes del sistema, en base al modelo funcional.
D. Construir el sistema Help Desk, en su versión Beta, basado en el
modelo de funcionamiento del sistema.
2.3 Justificación de la Investigación
La presente investigación desarrollada en la división de Telemática de la
Dirección General de Ciencia y Tecnología del Estado Monagas comprende el
“Desarrollo de un sistema Help Desk para el control y gestión de operaciones,
realizadas por la división de Telemática de la Dirección de Ciencia y Tecnología
en los distintos organismos adscritos a la gobernación del estado Monagas”,
formando parte de las metas propuestas por la organización en materia de
automatización y las establecidas por el Ejecutivo Nacional mediante el decreto
N° 3.390 el cual sugiere la utilización preferiblemente de software libre en las
instituciones públicas.
El desarrollo de este sistema de información constituye un paso adelante
en las metas trazadas por la DGCT en materia de automatización de procesos y
mejoramiento de la calidad en los servicios prestados a los distintos organismos
adscritos a la Gobernación del Estado Monagas. En cuanto al mejoramiento en
la calidad de los servicios, el sistema permitirá a los organismos requirentes un
reporte de incidentes más organizado y efectivo, así como un registro detallado
de los mismos. En los beneficios referidos a la automatización de procesos; el
Help Desk contribuirá en gran medida a un mejor y mayor control en las
operaciones de la División de Telemática, mejorando la distribución de las
cargas de trabajo entre los analistas pertenecientes a cada una de sus
coordinaciones, y facilitando a los directivos, el control de desempeño de los
equipos de trabajo a su cargo; para de esta forma establecer planes que
permitan optimizar el rendimiento del recurso humano disponible.
2.4 Alcance de la Investigación
El alcance de esta investigación abarcó el desarrollo de un sistema Help
Desk para el control y gestión de operaciones realizadas por la División de
Telemática de la Dirección de Ciencia y Tecnología, en los distintos organismos
adscritos a la Gobernación del Estado Monagas, más específicamente aquellos
ubicados dentro de la capital Monaguense.
El desarrollo de esta investigación está contemplado hasta la tercera fase
(Construcción) de la metodología del Proceso Unificado; mediante la cual se
obtuvo la versión Beta del sistema, permitiendo tener una idea clara de las
capacidades y funcionalidades del mismo.
CAPITULO III
MARCO REFERENCIAL
3.1 Antecedentes de la Investigación
Urimare K. Guzmán G (2009) “Sistema de gestión y control administrativo
de los servicios de soporte técnico a usuarios de la Universidad de Oriente, Núcleo
Monagas”. Trabajo presentado en la Universidad de Oriente como requisito
para optar al título de ingeniero de sistemas. El objetivo principal de este
trabajo fue el desarrollo de un Sistema de Gestión y Control Administrativo de
los Servicios de Soporte Técnico a usuarios de la Universidad de Oriente Núcleo
Monagas; esta investigación fue realizada bajo la metodología del Proceso
Unificado de Desarrollo y usando como lenguaje de modelado UML. Este
trabajo fue de gran utilidad para la comprensión de la metodología del Proceso
Unificado al igual que los sistemas de información orientados a la prestación de
servicios.
Núñez, Y (2008) “Sistema Automatizado para la gestión de los procesos
administrativos en la sección de compra Núcleo Monagas enmarcado dentro del
proyecto macro software libre de la Universidad de Oriente”. Trabajo presentado
en la Universidad de Oriente como requisito para optar al título de ingeniero de
sistemas, el cual tiene como propósito la construcción de una aplicación Web que
permita gestionar los procesos de la sección de compras, utilizando la
combinación de la metodología de sistemas suaves de Checkland y la
metodología RUP. Este trabajo sirvió de ayuda para tener un mejor
43
entendimiento de la metodología RUP y el lenguaje de modelado UML como
herramientas para el desarrollo de software.
Briceño, G. (2008) “Sistema Automatizado Para La Gestión De Los
Procesos Administrativos De La Delegación De Planificación De La Universidad
De Oriente Núcleo Monagas”. Trabajo presentado en la Universidad de Oriente
como requisito para optar al título de ingeniero de sistemas. El objetivo de este
trabajo fue automatizar los procesos administrativos que se llevan a cabo en la
Delegación de Planificación, haciendo uso de la metodología de desarrollo RUP.
Esta investigación permitió ahondar en el uso y aplicación de los diferentes
diagramas de UML para el modelado del negocio y del sistema en cuestión,
aunado al hecho de ser un proyecto basado en los criterios del software libre en
Venezuela.
3.2 Bases Teóricas
3.2.1 Sistemas de Información
Según J. Whitte, L Bentley y V. Barlow (2003), un Sistema de
Información es:
“Una disposición de personas, actividades, datos, redes y tecnología integrados entre sí con el propósito de apoyar y mejorar las operaciones cotidianas de una empresa, así como satisfacer las necesidades de información para la resolución de problemas y la toma de decisiones por parte de los directivos de la empresa”.
Los Sistemas de Información constituyen un conjunto de funciones que
una vez integradas funcionan como unidad, haciendo posible la captura de
datos, su almacenamiento, procesamiento y posterior salida en forma de
información. Los sistemas de información están constituidos por cuatro
actividades fundamentales, las cuales son: Entrada, almacenamiento,
procesamiento y salida de información.
45
Entrada: puede se manual o automática, el sistema toma los datos que
requiere para procesar la información.
Almacenamiento: El sistema almacena en estructuras la información
guardada en procesos o sesiones anteriores.
Proceso: son un conjunto de cálculos realizados por el sistema, los cuales
siguen una secuencia previamente establecida.
Salida de información: son los datos convertidos en información útil,
estos son los datos de entrada mostrados al exterior a través de unidades típicas
de salida.
3.2.2 Sistemas de información Transaccionales
Los sistemas de información transaccionales según Vivanco (2007) “…son
los que logran la automatización de los procesos operativos dentro de una
organización, su función primordial consiste en procesar transacciones tales
como pagos, cobros, pólizas, entradas, salidas, etc.” Este tipo de sistema de
información tienen la propiedad de ser recolectores de información y a través de
ellos se generan las grandes bases de información para su explotación posterior.
Los sistemas de procesamiento de transacciones brindan velocidad y
exactitud; se pueden programar para seguir rutinas sin ninguna variación. En el
proceso de desarrollo se diseñan tanto los sistemas como los procesos para el
manejo de este tipo de actividades. Un sistema transaccional debe controlar las
transacciones para mantener la seguridad y consistencia de los datos
involucrados.
3.2.3 Help Desk
Un Help desk, es un concepto de sistema de información transaccional;
constituido por un conglomerado de servicios que ofrece a través de uno o varios
medios de contacto la posibilidad de gestionar y solucionar todas las posibles
incidencias que guardan relación con los servicios prestados por una
organización. Esta tecnología representa una gran ayuda a la hora de
incrementar la productividad de las organizaciones al mismo tiempo que
aumenta la satisfacción de los usuarios tanto internos como externos.
Puesto que los sistemas Help Desks son utilizados para la realización de
funciones básicas dentro de las organizaciones; la información que estos generan
tiene una gran relevancia en la toma de decisiones; por esta razón estos sistemas
de información deben estar caracterizados por la rapidez en sus transacciones,
al igual que garantizar la disponibilidad de la información, su integridad y el
que no pueda ser modificada por usuarios no autorizados. Un Help Desk debe
poseer una gran fiabilidad, ya que de lo contrario podría afectar a los usuarios,
a las transacciones de información, a la reputación de la organización, etc. De
igual forma en caso de fallas, debe tener mecanismos de recuperación y de
respaldo de datos para de esta forma garantizar la calidad del sistema.
3.2.4 Proceso Unificado (UP)
El proceso Unificado o UP consiste de un proceso de desarrollo iterativo y
creciente. Este enfoque está basado en el Unified Modeling Language (UML)
para la descripción de la arquitectura del software (funcional, de aplicación y
física) y para el desarrollo de los casos usuarios. El Proceso Unificado según
Mosqueira (2007) “…es un marco de desarrollo iterativo e incremental
compuesto de cuatro fases denominadas: Inicio, Elaboración, Construcción y
Transición”. Cada una de estas fases es a su vez dividida en una serie de
iteraciones. Estas iteraciones ofrecen como resultado un incremento del
producto desarrollado que añade o mejora las funcionalidades del sistema que se
está desarrollando. Cada una de estas iteraciones se divide a su vez en una serie
de disciplinas que recuerdan a las definidas en el ciclo de vida clásico o en
cascada: Análisis de requisitos, diseño, implementación y Prueba. Aunque todas
las iteraciones suelen incluir trabajo en casi todas las disciplinas, el grado de
esfuerzo dentro de cada una de ellas varía a lo largo del proyecto.
En el Proceso Unificado los casos de uso se utilizan para capturar los
requisitos funcionales y para definir los contenidos de las iteraciones. La idea es
que cada iteración tome un conjunto de casos de uso o escenarios y desarrolle
todo el camino a través de las distintas disciplinas: diseño, implementación,
prueba, etc. El Proceso Unificado asume que no existe un modelo único que
cubra todos los aspectos del sistema. Por dicho motivo existen múltiples modelos
y vistas que definen la arquitectura de software de un sistema.
El Proceso Unificado requiere que el equipo del proyecto se centre en
identificar los riesgos críticos en una etapa temprana del ciclo de vida. Los
resultados de cada iteración, en especial los de la fase de Elaboración, deben ser
seleccionados en un orden que asegure que los riesgos principales sean
considerados primero. UP se apoya en UML para especificar, visualizar,
construir y documentar artefactos de un sistema de software. Se usa para
entender, diseñar, configurar, mantener y controlar la información sobre los
sistemas que se van a construir.
3.2.5 Fases del Proceso Unificado
El Proceso Unificado, según Mosqueira (2007); está compuesto por cuatro
fases o incrementos:
Fase 1. Inicio.
También llamada “incremento 1”, el objetivo de esta fase es determinar si
merece la pena desarrollar el sistema en estudio (estudiar su viabilidad). Por
tanto, durante esta fase se establecen los objetivos del proyecto, se realiza su
planificación y se determina su alcance. Al hacer la planificación hay que
considerar: los criterios de éxito del proyecto; hacer una adecuada estimación de
recursos; hacer una evaluación del riesgo; y definir un plan de trabajo,
identificando los diversos hitos del proyecto.
Fase 2. Elaboración.
Se establece un plan para el proyecto y se define la arquitectura del
sistema, esta fase también es llamada “incremento 2”. El propósito de esta fase
es establecer una base arquitectónica sólida para el sistema, sobre la cual se
asentará la fase de construcción. Las decisiones sobre la arquitectura del sistema
se deben tomar considerando el proyecto de un modo global. Por cuanto se debe
describir los requisitos fundamentales del sistema y de mayor peso identificados
en fases anteriores. También se tendrá que hacer una evaluación de los riesgos.
Para verificar la arquitectura se implementa un sistema (prototipo de la
arquitectura) que demuestre las posibilidades de la arquitectura y ejecute los
casos de uso más significativos.
Fase 3. Construcción.
La fase de construcción o “incremento 3”, se desarrolla iterativamente y
de modo incremental un producto completo preparado para la siguiente fase.
Esto supone describir los restantes objetivos, los criterios de aceptación, y
refinado del diseño. Se completan la implementación y las pruebas. Para ello, se
describen los requisitos no desarrollados antes y se completa el desarrollo del
sistema basándose en la arquitectura definida.
Fase 4. Transición.
El objetivo de esta fase (incremento 4) es asegurar que los requisitos se
han cumplido y que el software está disponible para los usuarios finales. Por eso
esta fase está dirigida por la retroalimentación de los usuarios, a partir de la
información que se deduzca de la versión beta del sistema en funcionamiento.
3.2.6 UML
UML, es el lenguaje de modelado de sistemas de software más conocido y
utilizado en la actualidad; está respaldado por el OMG (Object Management
Group). Según JACOBSON, Ivar; BOOCH, Grady; RUMBAUGH, James
(2007) el lenguaje unificado de modelado (UML), “…es un lenguaje de modelado
visual de propósito general que se utiliza para especificar, visualizar, construir y
documentar artefactos de un sistema de software …, se usa para comprender,
diseñar, ojear, configurar, mantener y controlar la información sobre tales
sistemas…”
UML no puede compararse con la programación estructurada, pues
UML significa Lenguaje Unificado de Modelado, no es programación, solo se
diagrama la realidad de una utilización en un requerimiento. Mientras que,
programación estructurada, es una forma de programar como lo es la
orientación a objetos, sin embargo, la programación orientada a objetos viene
siendo un complemento perfecto de UML, pero no por eso se toma UML sólo
para lenguajes orientados a objetos.
3.2.7 Diagramas de UML
UML está constituido por un conjunto de diagramas, que representan
visualmente diferentes aspectos de las entidades representadas. Es posible
combinar el uso de estos diagramas, a fin de lograr un mejor entendimiento del
proyecto que se esté desarrollado. En el Cuadro 1 se presenta un resumen de lo
diagramas de UML.
Cuadro 1. Diagramas de UML
Área Principal de UML
Diagrama Conceptos principales
EstructuralDiagrama de clases Asociación, clase,
dependencia, generalización, interfaz, realización.
Estructura interna Conector, interfaz obligatoria, interfaz proporcionada, parte, puerto.
Diagrama de colaboración
Colaboración, conector, rol, uso de la colaboración.
Diagrama de componentes
Componente, dependencia, interfaz proporcionada, interfaz obligatoria, puerto, realización, subsistema.
Diagrama de casos de uso
Actor, asociación caso de uso, extensión, generalización de casos de uso, inclusión.
Área Principal de UML
Diagrama Conceptos principales
Dinámica Diagrama de máquina de estados
Actividad hacer, disparador, efecto, estado, evento, región, transición, transición de finalización.
Diagrama de actividad Acción, actividad, control de flujo, división, excepción, flujo de datos, nodo de control, nodo objeto, pin, región de expansión, unión.
Diagrama de secuencia Especificación de la ejecución, especificación del suceso, fragmento de la interacción, interacción, línea de vida, mensaje, operando de la interacción, señal
Diagrama de comunicación
Colaboración, condición de guarda, mensaje, rol, numero de secuencia.
Física Diagrama de despliegue Artefacto, dependencia,
Cuadro 1 (Cont.)
manifestación, nodo.Gestión del modelo Diagrama de paquetes Importar, modelo,
paqueteDiagrama de paquetes Estereotipo, perfil,
restricción, valor etiquetado.
Fuente. JACOBSON, Ivar; BOOCH, Grady; RUMBAUGH (2007).
Al observar el Cuadro 1, podemos notar la gran cantidad de
herramientas de las que está dispuesto UML, sin embargo gran cantidad de
problemas pueden ser resueltos usando solo una parte de estas herramientas,
por supuesto esto dependerá del juicio de la persona que las este empleando. A
continuación se verán en detalle algunas de estas herramientas:
A. Diagramas de clases.
Un diagrama de clases es un tipo de diagrama estático que describe la
estructura de un sistema mostrando sus clases, atributos y las relaciones entre
ellos; una clase es una descripción de un concepto del dominio de la aplicación o
del dominio de la solución, alrededor de la cual se forma la vista de clases. Los
diagramas de clases son utilizados durante el proceso de análisis y diseño de los
sistemas, donde se crea el diseño conceptual de la información que se manejará
en el sistema, y los componentes que se encargaran del funcionamiento y la
relación entre uno y otro.
Las clases se dibujan como rectángulos. La lista de atributos y operaciones se
muestran en compartimientos separados. Se pueden suprimir los
compartimientos cuando no se necesitan todos los detalles. Una clase puede
aparecer en varios diagramas. Los atributos y operaciones a menudo se
muestran en un diagrama (el diagrama “raíz”) y se suprime del resto de los
diagramas. Al diseñar una clase se debe pensar en cómo se puede identificar un
objeto real, como una persona, un transporte, un documento o un paquete.
Durante el proceso del diseño de las clases se toman las propiedades que
identifican como único al objeto y otras propiedades adicionales como datos que
corresponden al objeto.
El diagrama de clases incluye mucha más información como la relación entre
un objeto y otro, la herencia de propiedades de otro objeto, conjuntos de
operaciones/propiedades que son implementadas para una interfaz. Las
relaciones entre las clases se muestran como líneas que conectan los rectángulos
de las clases. Los diferentes tipos de relaciones se distinguen por la textura de la
línea y por los adornos en las líneas o en sus extremos. En la Figura 3 se muestra
un ejemplo de un diagrama de clases sencillo.
B. Diagrama de caso de uso.
Según JACOBSON, Ivar; BOOCH, Grady; RUMBAUGH, “un caso de uso
es una descripción lógica de una parte de funcionalidad. No es una construcción
manifiesta de la implementación de un sistema. En su lugar, cada caso de uso se
debe corresponder con las clases que implementan un sistema. El
comportamiento de un caso de uso se corresponde con las transiciones y
operaciones de las clases”. El valor verdadero de un caso de uso reposa en la
descripción escrita del comportamiento del sistema al afrontar una tarea de
negocio o un requisito de negocio y la posición o contexto del caso de uso entre
otros casos de uso.
Figura 3. Ejemplo de un diagrama de clases
Fuente. www.clikear.com/manuales/uml/faseconstruccionbajonivel.aspxruccionb
ajonivel.aspx
Los diagramas de caso de uso, como el mostrado en la Figura 4, se usan
para describir lo que hace un sistema desde el punto de vista de un observador
externo, debido a esto, un diagrama de este tipo generalmente es de los más
sencillos de interpretar en UML, ya que su razón de ser se concentra en un
“Que” hace el sistema, a diferencia de otros diagramas UML que intentan dar
respuesta a un “Como” logra su comportamiento el sistema.
Los elementos que pueden aparecer en un Diagrama de Casos de Uso son:
actores, casos de uso y relaciones entre casos de uso, referenciados a
continuación:
Actores: un actor es algo con comportamiento, como una persona
(identificada por un rol), un sistema informatizado u organización, y que realiza
algún tipo de interacción con el sistema.. Se representa mediante una figura
humana dibujada con palotes. Esta representación sirve tanto para actores que
son personas como para otro tipo de actores.
Casos de Uso: un caso de uso es una descripción de la secuencia de
interacciones que se producen entre un actor y el sistema, cuando el actor usa el
sistema para llevar a cabo una tarea específica. Expresa una unidad coherente
de funcionalidad, y se representa en el Diagrama de Casos de Uso mediante una
elipse con el nombre del caso de uso en su interior. El nombre del caso de uso
debe reflejar la tarea específica que el actor desea llevar a cabo usando el
sistema.
Relaciones entre Casos de Uso: un caso de uso, en principio, debería
describir una tarea que tiene un sentido completo para el usuario. Sin embargo,
hay ocasiones en las que es útil describir una interacción con un alcance menor
como caso de uso. La razón para utilizar estos casos de uso no completos en
algunos casos, es mejorar la comunicación en el equipo de desarrollo, el manejo
de la documentación de casos de uso. En el caso de que se quiera utilizar estos
casos de uso más pequeños, las relaciones entre estos y los casos de uso
ordinarios pueden ser de los siguientes tipos:
a. Inclusión (include o use): representado con la etiqueta "«include»". Es
una forma de interacción o creación, un caso de uso dado puede "incluir"
otro. El primer caso de uso a menudo depende del resultado del caso de
uso incluido. Esto es útil para extraer comportamientos verdaderamente
comunes desde múltiples casos de uso a una descripción individual, desde
el caso de uso que lo incluye hasta el caso de uso incluido.
b. Extensión (Extend): la notación, es una flecha de punta abierta con línea
discontinua, desde el caso de uso extensión al caso de uso extendido
denotado con la etiqueta "«extend». Es otra forma de interacción, un
caso de uso dado, (la extensión) puede extender a otro. Esta relación
indica que el comportamiento del caso de uso extensión puede ser
insertado en el caso de uso extendido bajo ciertas condiciones.
c. Generalización: la notación es una línea solida terminada en un triángulo
dibujado desde el caso de uso especializado al caso de uso general. En la
tercera forma de relaciones entre casos de uso, existe una relación
generalización/especialización. Un caso de uso dado puede estar en una
forma especializada de un caso de uso existente.
Figura 4. Ejemplo de un diagrama de caso de uso
Fuente. http://argouml-stats.stage.tigris.org/nonav/documentation-es/manual-
0.28/ch04s03.html
C. Diagrama de actividad.
Es una forma especial de diagrama de estado usado para modelar una
secuencia de acciones y condiciones tomadas dentro de un proceso. El propósito
del diagrama de actividad es modelar un proceso de flujo de trabajo (workflow)
y/o modelar operaciones. Una Operación es un servicio proporcionado por un
objeto, que está disponible a través de una interfaz que a su vez es un grupo de
operaciones relacionadas con la semántica. En la Figura 5 puede ser observado
un ejemplo de un diagrama de actividad.
Un nodo de actividad se muestra como una caja con las esquinas
redondeadas que contiene la descripción de una actividad. Un flujo de control se
denota como una flecha. Las bifurcaciones se muestran como condiciones de
guarda sobre los flujos de control o como rombos con múltiples flechas de salida
etiquetada. Una unión o división de control se denotan mediante múltiples
flechas saliendo o entrando en una barra gruesa de sincronización.
Particiones: algunas veces es útil organizar las actividades de un modelo de
acuerdo con su responsabilidad. Este tipo de asignación se puede denotar
organizando las actividades en distintas regiones (denominadas particiones)
separadas por líneas en el diagrama, como las mostradas en la Figura 5. Debido
a su apariencia, una región a veces recibe el nombre de calle.
Flujo de objetos: Un diagrama de actividad puede mostrar el flujo de valores de
objetos, a demás del flujo de control. Un flujo de objetos representa un objeto en
la entrada o salida de una actividad. Para un valor de salida, se dibuja una
flecha de línea continua desde la actividad al flujo de objeto. Para un valor de
entrada se dibuja una flecha de línea continua del flujo de objeto a la actividad.
D. Diagrama de secuencia.
Un diagrama de secuencia es un tipo de diagrama usado para modelar
interacción entre objetos en un sistema; muestra una interacción como un
grafico de dos dimensiones. La dimensión vertical es el eje del tiempo, que
avanza hacia el final de la página. La dimensión temporal muestra los roles que
representan objetos individuales en la colaboración. Cada rol se representa en
una columna vertical, como
Figura 5. Ejemplo de un diagrama de actividad
Fuente. http://www.ibiblio.org/pub/linux/docs/LuCaS/Tutoriales/doc-modelado-
sistemas-UML/multiple-html/x291.html
las mostradas en la Figura 6, que contiene un símbolo de cabecera y una línea
vertical (línea de vida). Durante el tiempo que existe un objeto, la línea de vida
se representa con una línea discontinua. Durante el tiempo que la ejecución de la
especificación de un procedimiento sobre el objeto esta activo, la línea se
representa con una línea doble.
Un diagrama de secuencia solo muestra secuencias de mensajes y no
intervalos de tiempo exactos, es posible la utilización de un diagrama de tiempo
cuando la métrica de tiempo es importante, pero para la comprensión de la
semántica de la interacción, normalmente los diagramas de secuencia son
suficientes. Un mensaje se muestra como una flecha desde la línea de vida de un
objeto a la línea de vida de otro. Los mensajes asíncronos se muestran mediante
flechas de punta abierta.
Figura 6. Ejemplo de un diagrama de secuencia.
Fuente. http://es.wikipedia.org/wiki/Diagrama_de_secuencia
E. Diagrama de despliegue.
Un diagrama de despliegue (mostrado en la Figura 7) modela la arquitectura
en tiempo de ejecución de un sistema, para esto muestra la configuración de los
elementos de hardware (nodos) y la forma cómo los elementos y artefactos del
software se trazan en esos nodos. La vista de despliegue puede resaltar los
cuellos de botella en el rendimiento debidos a la ubicación de los artefactos que
manifiestan componentes independientes en diferentes nodos.
Nodo: modela un recurso computacional de tiempo de ejecución. Un tipo de
nodo se muestra como un cubo estilizado con su nombre en el interior. Una
instancia de un nodo se representa mediante una cadena subrayada con el
nombre y el tipo de nodo. Las asociaciones entre los nodos representan caminos
de comunicación. Las asociaciones pueden tener estereotipos para distinguir los
diferentes tipos de comunicación. Los nodos pueden tener relaciones de
generalización para relacionar una descripción general de un nodo con una
variación más específica.
Artefacto: un artefacto es un producto del proceso de desarrollo de software,
que puede incluir los modelos del proceso (por ejemplo, modelos de Casos de
Uso, modelos de Diseño, etc.), archivos fuente, ejecutables, documentos de
diseño, reportes de prueba, prototipos, manuales de usuario y más. Un artefacto
se denota por un rectángulo mostrando el nombre del artefacto, el estereotipo
«artifact» y un icono de documento.
Figura 7. Ejemplo de diagrama de despliegue.
Fuente. http://umldaniel.blogspot.com/2009/05/diagrama-de-despliegue.html
3.2.8 Metodología de sistemas Blandos de Peter Checkland
Es una técnica cualitativa que puede aplicarse a situaciones complejas
donde exista un alto componente social, político y humano. Es una metodología
sistémica fundamentada en el concepto de perspectiva o en el lenguaje de la
metodología “Weltanschauung”. Un “weltanschauung” representa la visión
propia de un observador, o grupo de ellos, sobre un objeto de estudio, visión ésta
que afecta las decisiones que el o los observadores puedan tomar en un momento
dado sobre su accionar con el objeto. La metodología de sistemas blandos (o
SSM, por sus siglas en inglés) toma como punto de partida la idealización de
estos “weltanschauung” para proponer cambios sobre el sistema que en teoría
deberían tender a mejorar su funcionamiento.
La SSM de Peter Checkland, Según Martínez (2004), está conformada
por siete estadios cuyo orden puede variar de acuerdo a las características del
estudio, a continuación se describen brevemente estos estadios:
Estadio 1: La Situación Problema no Estructurada: en este estadio se pretende
lograr una descripción de la situación donde se percibe la existencia de un
problema, sin hacer hincapié en el problema en sí, esto es sin dar ningún tipo de
estructura a la situación.
Estadio 2: La Situación Problema Expresada: se da forma a la situación
describiendo su estructura organizativa, actividades e interrelación de éstas,
flujos de entrada y salida, etc.
Estadio 3: Definiciones Raíz de Sistemas Pertinentes: se elaboran definiciones de
lo que, idealmente, según los diferentes “weltanschauung” involucrados, es el
sistema. La construcción de estas definiciones se fundamenta en seis factores que
deben aparecer explícitos en todas ellas, estos se agrupan bajo el nemónico de
sus siglas en ingles CATWOE (consumidores, actores, proceso de
transformación, weltanschauung, poseedor y restricción del ambiente).
Estadio 4: Confección y Verificación de Modelos Conceptuales: partiendo de los
verbos de acción presentes en las definiciones raíz, se elaboran modelos
conceptuales que representen, idealmente, las actividades que, según la
definición raíz en cuestión, se deban realizar en el sistema. Existirán tantos
modelos conceptuales como definiciones raíz. Este estadio se asiste de los sub-
estadios 4a y 4b.
Estadio 4a: Concepto de Sistema Formal: Según Martínez (2004), “este
consiste en el uso de un modelo general de sistema de la actividad humana que se
puede usar para verificar que los modelos construidos no sean
fundamentalmente deficientes”.
Estadio 4b: Otros Pensamientos de Sistemas: Según Martínez (2004),
“consiste en transformar el modelo obtenido en alguna otra forma de
pensamiento sistémico que, dadas las particularidades del problema, pueda ser
conveniente”.
Estadio 5: Comparación de los modelos conceptuales con la realidad: se
comparan los modelos conceptuales con la situación actual del sistema
expresada, dicha comparación pretende hacer emerger las diferencias existentes
entre lo descrito en los modelos conceptuales y lo que existe en la actualidad en
el sistema.
Estadio 6: Diseño de Cambios Deseables, Viables: de las diferencias emergidas
entre la situación actual y los modelos conceptuales, se proponen cambios
tendientes a superarlas, dichos cambios deben ser evaluados y aprobados por las
personas que conforman el sistema humano, para garantizar con esto que sean
deseables y viables.
Estadio 7: Acciones para Mejorar la Situación Problema: finalmente este estadio
comprende la puesta en marcha de los cambios diseñados, tendientes a
solucionar la situación problema, y el control de los mismos. Este estadio no
representa el fin de la aplicación de la metodología, pues en su aplicación se
transforma en un ciclo de continua conceptualización y habilitación de cambios,
siempre tendiendo a mejorar la situación.
3.2.9 Bases de Datos
Según Kendall y Kendall (2005), una base de datos es:
Una fuente central de datos destinada a compartirse entre muchos usuarios para una diversidad de aplicaciones. El corazón de una bases de datos lo constituye el Sistema de Administración de Base de Datos (DBMS, database management system), el cual que permite la creación, modificación y actualización de la base de datos, la recuperación de datos y la generación de informes y pantallas.
Las aplicaciones más usuales de las bases de datos son para la gestión de
empresas e instituciones públicas. También son ampliamente utilizadas en
entornos científicos con el objeto de almacenar la información experimental.
3.2.9.1 Características de las bases de datos.
Entre las principales características de los sistemas de base de datos podemos
mencionar:
A. Independencia lógica y física de los datos.
B. Redundancia mínima.
C. Acceso concurrente por parte de múltiples usuarios.
D. Integridad de los datos.
E. Consultas complejas optimizadas.
F. Seguridad de acceso y auditoría.
G. Respaldo y recuperación.
H. Acceso a través de lenguajes de programación estándar.
3.2.9.2 Tipos de Bases de Datos.
Las bases de datos pueden ser clasificadas según la variabilidad de los
datos almacenados y según el contenido.
Según la variabilidad de los datos almacenados:
A. Bases de datos estática: Éstas son bases de datos de sólo lectura,
utilizadas primordialmente para almacenar datos históricos que
posteriormente se pueden utilizar para estudiar el comportamiento de un
conjunto de datos a través del tiempo, realizar proyecciones y tomar
decisiones.
B. Bases de datos dinámicas: Éstas son bases de datos donde la información
almacenada se modifica con el tiempo, permitiendo operaciones como
actualización, borrado y adición de datos, además de las operaciones
fundamentales de consulta. Un ejemplo de esto puede ser la base de datos
utilizada en un sistema de información de una tienda de abarrotes, una
farmacia, un videoclub.
Según el contenido:
A. Bases de datos bibliográficas: Solo contienen un surrogante
(representante) de la fuente primaria, que permite localizarla. Como su
nombre lo indica, el contenido son cifras o números. Por ejemplo, una
colección de resultados de análisis de laboratorio, entre otras.
B. Bases de datos de texto completo: Almacenan las fuentes primarias, como
por ejemplo, todo el contenido de todas las ediciones de una colección de
revistas científicas.
C. Directorios: Un ejemplo son las guías telefónicas en formato electrónico.
D. Bases de datos o "bibliotecas" de información química o biológica: Son
bases de datos que almacenan diferentes tipos de información
proveniente de la química, las ciencias de la vida o médicas.
3.2.10 PHP
PHP es un acrónimo recursivo que significa Hypertext Pre-Procesor. Es
un lenguaje de programación interpretado, diseñado originalmente para la
creación de programas web dinámicos. Es usado principalmente en la
interpretación de lado del servidor (Server-Side Scripting) pero actualmente
puede ser utilizado desde una interfaz de línea de comandos o en la creación de
otros tipos de programas incluyendo aplicaciones con interfaz grafica usando las
bibliotecas Qt o GTKT.
PHP permite la conexión a diferentes tipos de servidores de bases de datos
tales como MySQL, Postgres, Oracle, ODBC, BB2, Microsoft SQL server,
Firebird y SQLite. Tiene la capacidad de ser ejecutadoen la mayoría de los
sistemas operativos, tales como Linux o Mac OSx) y Windows; además que
permite interactuar con los servidores de web más populares. Entre las
principales ventajas de PHP se pueden mencionar las siguientes:
A. Es un lenguaje multiplataforma.
B. Completamente orientado a la web.
C. Capacidad de conexión con la mayoría de los motores de base de datos
que se utilizan en la actualidad, destaca su conectividad con MYSQL
y PostgreSQL.
D. Capacidad de expandir su potencial utilizando la enorme cantidad de
módulos (llamados ext's o extensiones).
E. Es libre, por lo que se presenta como una alternativa de fácil acceso
para todos.
F. Permite aplicar técnicas de programación orientada a objetos.
G. Biblioteca nativa de funciones sumamente amplia e incluida.
H. No requiere definición de tipos de variables aunque sus variables se
pueden evaluar también por el tipo que estén manejando en tiempo de
ejecución.
I. Tiene manejo de excepciones (desde PHP5).
J. Si bien PHP no obliga a quien lo usa a seguir una determinada
metodología a la hora de programar (muchos otros lenguajes tampoco
lo hacen), aun estando dirigido a alguna en particular, el
programador puede aplicar en su trabajo cualquier técnica de
programación y/o desarrollo que le permita escribir código ordenado,
estructurado y manejable. Un ejemplo de esto son los desarrollos que
en PHP se han hecho del patrón de diseño Modelo Vista Controlador
(o MVC), que permiten separar el tratamiento y acceso a los datos, la
lógica de control y la interfaz de usuario en tres componentes
independientes.
Sin embargo, la ofuscación de código es la única forma de ocultar las
fuentes, lo cual constituye una desventaja para PHP.
3.2.11 Postgre SQL
Es un sistema de gestión de base de datos relacional orientada a objetos
de software libre, publicado bajo licencia BSD. El desarrollo de Postgre SQL
está dirigido por una comunidad de desarrolladores y organizaciones
comerciales las cuales trabajan en su desarrollo. Dicha comunidad es
denominada el PGDG (PostgreSQL Global Development Group).
Entre sus principales características se encuentran:
A. Alta concurrencia: mediante un sistema denominado MVCC (Acceso
concurrente multiversión, por sus siglas en ingles). PostgreSQL
permite que mientras un proceso escribe en una tabla, otros accedan a
la misma tabla sin necesidad de bloqueos. Cada usuario obtiene una
versión consistente de lo último a lo que se le hizo commit.
B. 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 y arrays.
Los usuarios pueden crear sus propios tipos de datos, mismos que pueden
ser completamente indexable, gracias a la infraestructura GiST de PostgreSQL.
3.2.12 Java script
Es un leguaje de programación utilizado principalmente en el desarrollo
de páginas web dinámicas. Este es un lenguaje de programación interpretado,
por lo que no se necesita compilar los programas antes de ser ejecutados.
Es un lenguaje basado en objetos, es un dialecto de ECMAscript y se
caracteriza por ser un leguaje basado en prototipos con tipiado débil y dinámico
con funciones de primera clase. Todos los navegadores modernos interpretan el
código Java Script integrado dentro de las páginas web.
3.3 Bases Legales
3.3.1 Decreto 3390, publicado en gaceta oficial N° 38.095 de fecha
28/12/2004
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.
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.
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 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.
3.4 Definición de Términos
Los términos empleados a lo largo de esta investigación junto con sus
respectivas definiciones están reflejados en el documento glosario que forma
parte de los entregables del proyecto, ubicado en la parte final del mismo; esto
con el fin de evitar la equívoca interpretación de algunos de los términos
empleados durante la investigación.
CAPITULO IV
MARCO METODOLOGICO
4.1 Tipo y Nivel de investigación
Para alcanzar los objetivos planteados en el desarrollo del sistema Help
Desk para el control y gestión de operaciones realizadas por la División de
Telemática de la Dirección de Ciencia y Tecnología en los distintos organismos
adscritos a la Gobernación del estado Monagas, se empleó la investigación de
campo; por cuanto los datos fueron obtenidos directamente del sujeto
investigado (La División de Telemática de la Dirección de Ciencia y Tecnología),
además no se realizó ningún cambio en las variables estudiadas.
Según Arias, F. G (2004), la investigación de campo “consiste en la
recolección de datos directamente de los sujetos investigados, o de la realidad
donde ocurren los hechos (datos primarios), sin manipular o controlar variable
alguna”. Esta investigación se adapta a la modalidad de proyecto factible, puesto
que constituye una solución factible a un problema planteado, aunado al hecho
de que las variables involucradas fueron estudiadas en su contexto natural, por
cuanto tiene un diseño “no experimental”.
Arias, F. G, 2006 (citado por Blanco, C, 2008) define al proyecto factible
como: “que se trata de una propuesta de acción para resolver un problema
práctico o satisfacer una necesidad. Es indispensable que dicha propuesta se
acompañe de una investigación, que demuestre su factibilidad o posibilidad de
realización”.
72
En relación a la profundidad del estudio y los conocimientos generados
por el mismo, esta investigación tiene un nivel descriptivo, puesto que según
Arias, F. G (2004), la investigación descriptiva “consiste en la caracterización de
un hecho, fenómeno o grupo con el fin de establecer su estructura o
comportamiento. Los resultados de este tipo de investigación se ubican en un
nivel intermedio en cuanto a la profundidad de los conocimientos se refiere”.
4.2 Población y Muestra
La población o universo es el conjunto de unidades o elementos,
claramente definidos, sobre los cuales se realiza la investigación, y que les será
útil los resultados obtenidos. En este mismo orden de ideas; para Tamayo
(2001) “La población es la totalidad de un fenómeno de estudio, incluye la
totalidad de unidades de análisis o entidades de población que integran dicho
fenómeno y que debe cuantificarse por un determinado estudio”.
Para la presente investigación la población estuvo conformada por: el
personal perteneciente a la División de Telemática de la Dirección General de
Ciencia y Tecnología del estado Monagas, incluyendo: Jefe de división y las
cuatro coordinaciones que la conforman (coordinación de sistema y aplicaciones,
redes y servidores, comunicaciones y soporte en sitio) y las distintas
dependencias adscritas a la Gobernación del estado Monagas. Se aplicó la
técnica de muestreo no probabilístico intencional. Según Martínez (1998). “La
muestra se escoge en función del control que se pretende establecer sobre
determinadas variables extrañas, o en base a una serie de criterios que se
consideran necesarios para tener una mejor aproximación al evento”. Para esta
investigación la muestra la conformaron 138 personas, distribuidas de la
siguiente forma:
La División de Telemática:
73
A. Jefe de la División de Telemática (1).
B. Coordinación de Soporte en Sitio (6).
C. Coordinación de Redes y Servidores (4).
D. Coordinación de Sistemas y Aplicaciones (4).
E. Coordinación de Comunicaciones (3).
Dependencias adscritas a la Gobernación del Estado Monagas:
A. Palacio de Gobierno (20)
B. Fundación del Niño (20).
C. Dirección de Comunicaciones (20).
D. Dirección de Hacienda (20).
E. Dirección de Policía (20).
F. Secretaria de Educación (20).
Los antes mencionados formaron parte indispensable para el estudio,
puesto que constituyeron la fuente primaria de información. La selección de las
dependencias adscritas a la Gobernación del estado Monagas respondió al hecho
de que estos organismos, debido a la naturaleza de sus actividades, son los más
propensos a requerir de los servicios de las cuatro coordinaciones que
conforman la División de Telemática. En cuanto a la División de Telemática la
muestra en la constituyó la misma población. Según Hurtado (2000) “La
muestra es una porción de la población que se toma para realizar el estudio, la
cual se considera representativa”.
4.3 Técnicas e instrumentos de Recolección de Datos
Arias, F. G (2004) define a las técnica como “…el procedimiento o forma
particular de obtener datos o información” y los instrumentos de recolección de
datos como “un dispositivo o formato (en papel o digital), que se utiliza para
obtener, registrar o almacenar información”. Las técnicas e instrumentos para
la recolección de datos necesarios para cumplir con los objetivos y diseño de la
investigación fueron los siguientes:
Observación directa: con esta técnica se pudo tener una percepción más
clara del problema planteado, pudiendo observar la situación desde el enfoque
de los usuarios como de los integrantes de la división de telemática. Se obtuvo un
mejor entendimiento acerca de la notificación de incidentes y de la problemática
existente en tal acción.
Entrevista no Estructurada: la aplicación de entrevistas permitió indagar
de manera más profunda sobre los detalles de la situación planteada, para
efectos de la investigación se optó por la realización de una entrevista no
estructurada, la cual es definida por Arias, F. G (2004) de la siguiente forma “…
no se dispone de una guía de preguntas elaboradas previamente. Sin embargo, se
orienta por unos objetivos preestablecidos, lo que permite definir el tema de la
entrevista. ”
Las entrevistas fueron realizadas a dieciocho (18) personas,
pertenecientes a la División de Telemática de la Dirección de Ciencia y
Tecnología, a fin de indagar sobre los detalles de las actividades llevadas a cavo
en cada una de las coordinaciones, y de esta forma obtener datos relevantes para
el desarrollo del sistema.
Encuestas: esta técnica fue aplicada de manera escrita, y con ella se
recolectó información valiosa de parte de los usuarios, Arias, F. G (2004); define
a las encuestas como “…una técnica que pretende obtener información que
suministra a un grupo o muestra de sujetos acerca de si mismos, o en relación
con un tema en particular”.
Las encuestas fueron aplicadas a un total de 120 personas pertenecientes
a seis organismos adscritos a la Gobernación del estado Monagas (Palacio de
Gobierno, Fundación del Niño, Dirección de Comunicaciones, Dirección de
Hacienda, Dirección de Policía, Secretaria de Educación), los cuales representan
a los usuarios requirentes de los servicios de la División de Telemática. Con esta
técnica se obtuvo información valiosa a cerca de la prestación actual de
servicios por parte de la división y las expectativas futuras de los usuarios. El
instrumento empleado para la recolección de los datos fue el cuestionario, el cual
se encuentra en el Anexo 1.
4.4 Técnicas de análisis de datos
Para el análisis y entendimiento de los datos, fue necesario definir una
técnica de análisis de datos, para efectos de esta investigación se utilizó el análisis
cualitativo y cuantitativo; esto con el fin de poder determinar las verdaderas
necesidades de la organización y de los usuarios en general.
Sabino, C. (2000) al hablar del análisis cuantitativo lo define como: "Una
operación que se efectúa, con toda la información numérica resultante de la
investigación. Esta, luego del procesamiento que ya se le habrá hecho, se nos
presentará como un conjunto de cuadros y medidas, con porcentajes ya
calculados" (P. 110). Este análisis fue necesario para el procesamiento de los
datos generados por las encuestas aplicadas.
Según Hernández, S. (2003), propone que "El análisis cualitativo se
define como: "un método que busca obtener información de sujetos,
comunidades, contextos, variables o situaciones en profundidad, asumiendo una
postura reflexiva y evitando a toda costa no involucrar sus creencias o
experiencia" .
En la presente investigación se aplicó el análisis cuantitativo y cualitativo
de la información obtenida como resultado de la observación directa, las
entrevistas y las encuestas que se realizaron en la Gobernación del estado
Monagas.
4.5 Diseño Operativo
El desarrollo de este trabajo de investigación estuvo comprendido en tres
etapas: Especificación conceptual y análisis de los requerimientos, Diseño inicial
y codificación y Construcción. Para el desarrollo de estas etapas se empleó el uso
de la metodología de proceso unificado (UP) la cual consiste en un proceso de
desarrollo iterativo y creciente. Este enfoque está basado en el modelo UML
para la descripción de la arquitectura del software, cabe destacar que para el
desarrollo de dichas etapas, esta investigación también se apoyó en la
Metodología de Sistemas Blandos (SSM) de Peter Checkland; a continuación se
describe la forma en que se llevaron a cabo las etapas planteadas anteriormente
y la adaptación de las metodologías para desarrollo de sistemas UP y la
Metodología para Sistemas Blandos de Peter Checkland.
Etapa 1: Especificación conceptual y análisis de los requerimientos.
Esta etapa se encuentra relacionada con las fases 1 y 2 de la metodología
de desarrollo de sistemas de información UP y con el primer estadio de la
Metodología de Sistemas Blandos de Peter Checkland.
Estadio 1 La Situación Problema no Estructurada (Peter Checkland).
Con la aplicación de este estadio se logró tener una descripción de la
situación organizacional, permitiendo tener una perspectiva más clara del
entorno. El patrón de comunicaciones, tanto formal como informal. Se
estudiaron las actividades básicas de cada una de las coordinaciones bajo
estudio.
Fase 1: Inicio (UP).
Durante el desarrollo de esta fase se determinó la viabilidad de
desarrollar el proyecto para lo cual se establecieron los objetivos del mismo, se
realizó la planificación y se determinó el alcance. Esta fase supuso empezar por
el flujo de trabajo de requisitos, en cuyo inicio se comprendió el dominio del
problema para luego construir el modelo del negocio (la forma en que la
División de Telemática realiza el negocio); para comprender mejor el negocio,
esta fase se apoyó en la Metodología de Sistemas Blandos de Peter Checkland, la
cual permitió conocer mejor el entorno organizacional y determinar las
necesidades organizacionales. Durante esta fase se realizó también el diagrama
de casos de uso inicial, dentro del flujo de requisitos y del modelo del negocio. Al
finalizar esta fase se examinaron los objetivos del proyecto y se determinó si se
continuaba o no con el mismo.
Fase 2: Elaboración (UP).
En esta fase se estableció la base arquitectónica sólida para el sistema,
sobre la que se basó la fase de construcción. De igual forma se realizó el dominio
del problema, para lo cual se procedió a definir los requisitos iníciales. La fase
de elaboración comprendió igualmente la eliminación de los elementos de más
alto riesgo para el proyecto (se refinaron sus propiedades). En esta fase se
realizó un plan de trabajo para el proyecto.
Al finalizar esta fase se examinó el alcance y los objetivos del sistema, la
arquitectura y la solución de riesgos mayores; también se decidió si se pasaba a
la siguiente fase.
Al finalizar esta etapa se obtuvieron los siguientes artefactos:
A. La versión inicial del modelo de dominio.
B. La versión inicial del modelo de negocio.
C. La versión inicial del modelo de los artefactos de los requisitos
(diagrama de casos de usos).
D. Una versión preliminar de la arquitectura.
E. La lista inicial de los riesgos.
F. El plan de trabajo para la fase siguiente.
Etapa 2: Diseño inicial y codificación.
Para el desarrollo de esta etapa se apoyó en un complemento de la fase 2
(Elaboración) de la metodología para desarrollo de sistemas de información UP.
Fase 2: Elaboración (UP).
Durante esta fase se desarrollaron los prototipos de interfaz de usuario
(UI, “User Interface”). Los modelos de facilidad de uso, navegación dentro del
sistema (entre los menús, entre las ventanas, etc.)
Al finalizar esta fase se obtuvieron los siguientes artefactos:
A. Modelo de dominio terminado.
B. Modelo de negocio terminado.
C. Los artefactos de los requisitos terminados.
D. Una versión revisada de la arquitectura.
E. Lista actualizada y refinada de los riesgos.
F. Pruebas para la detección de fallos.
G. El plan de administración del proyecto para el resto de fases.
Etapa 3: Construcción.
Esta etapa coincide con la fase 3 (Construcción) de la metodología para
desarrollo de sistemas de información UP.
Fase 3: Construcción.
En esta fase se describieron los objetivos restantes, los criterios de
aceptación y refinado del diseño. Se complementó la implementación y pruebas,
para lo cual se describieron los requisitos no desarrollados en la fase anterior y
se completó el desarrollo del sistema basándose en la arquitectura definida en la
fase de elaboración.
En esta fase se desarrolló el flujo de trabajo de implementación y
pruebas. La mayor carga de trabajo en esta fase recayó en la programación y en
el control de calidad. Esto implicó que al detectar algún fallo que requiriera
modificaciones en los elementos previos del flujo de trabajo, se tuvo que revisar
los elementos o cambiar los requisitos que habrían provocado el error.
Al finalizar esta fase se decidió si todo estaba preparado para la
instalación del sistema (el software acabado, localización del sistema y usuarios
preparados).
Al finalizar esta fase se obtuvieron los siguientes artefactos:
A. Versión beta del sistema.
B. La arquitectura terminada
C. La lista de riesgos actualizada.
4.6 Cuadro Operativo
En el Cuadro 2 se encuentran especificadas las actividades contempladas
en cada una de las etapas de la investigación, al igual que las fases de las
metodologías del Proceso Unificado y la Metodología de Sistemas Blandos de
Peter Checkland aplicadas en cada una de ellas; en este mismo cuadro se
encuentran detallados los objetivos específicos logrados con la aplicación de cada
una de las etapas propuestas.
74
Cuadro 2. Cuadro Operacional
ETAPA OBJETIVO ESPECIFICO
METODOLOGÍA APLICADA
FASE ACTIVIDADES
Etapa 1: Especificación
conceptual y análisis de los requerimientos.
Estudiar los procedimientos para la gestión, control y
monitoreo de operaciones realizadas
por la división de Telemática.
Metodología para sistemas blandos de
Peter Checkland.
Metodología de proceso unificado
(UP)
Estadio 1: La Situación
Problema no Estructurada.
FASE 1: Inicio
Realizar entrevistas (no estructuradas), para comprender el funcionamiento del sistema.Realizar encuestas para captar requisitos del sistema.
Recopilación de los Requerimientos del sistema: Elaboración de Modelos de Casos
de Uso Elaboración del documento Visión. Especificaciones Complementarias
del sistema Elaboración de Glosario del
dominio.Gestión del proyecto: Plan de desarrollo del proyecto
Entorno: Estudio para la adaptación del UP
para este proyecto.Establecer un modelo de funcionamiento del
sistema, acorde con las políticas de la
organización.
Metodología de proceso unificado
(UP)
FASE 2: Elaboración.
Elaboración del Modelo del Dominio
Elaboración del Modelo de Diseño
Desarrollo de Documento de Arquitectura.
75
Elaboración del Modelo de Prueba.
Diseño del Modelo de Implementación
ETAPA OBJETIVO ESPECIFICO
METODOLOGÍA APLICADA
FASE ACTIVIDADES
Etapa 2: Diseño inicial y codificación.
Diseñar los componentes del
sistema, en base al modelo funcional.
Metodología de proceso unificado
(UP)
FASE 2: Elaboración.
Construcción de prototipos de la interfaz de usuario
Elaborar la Lista de riesgos actualizada
Elaboración del plan del proyecto para el resto de las fases.
Etapa 3: Construcción.
Construir el sistema Help Desk, en su
versión Beta, basado en el modelo de
funcionamiento del sistema.
Metodología de proceso unificado
(UP)
FASE 3: Construcción
Elaboración de manual de usuario inicial
Obtención de la Versión beta del sistema.
Elaborar la Lista de riesgos actualizada
Realización de pruebas para la detección de fallos omitidos en fases anteriores.
Fuente. Autor (2010)
Cuadro 2 (Cont.)
CAPITULO V
RESULTADOS
5.1 Etapa I: Especificación conceptual y análisis de los
requerimientos.
Esta etapa estuvo orientada a entender el funcionamiento de la División
de telemática de la Dirección General de ciencia y tecnología y la interacción de
sus cuatro coordinaciones (Soporte en sitio, redes y servidores, sistemas y
aplicaciones, y comunicaciones) con los distintos entes adscritos a la
Gobernación del estado Monagas; para lo cual fueron aplicadas encuestas,
entrevistas no estructuradas y observación directa.
Las entrevistas no estructuradas fueron aplicadas al personal que labora
dentro de cada una de las coordinaciones de la división de Telemática, con el fin
de conocer su punto de vista del negocio, y la forma en que se llevan a cabo cada
una de sus actividades, del igual forma esta técnica permitió captar requisitos
preliminares del sistemas basándose en las percepciones del personal; así como
determinar el alcanza del proyecto. Con resultados de las entrevistas se pudo
comprender el orden de consecuencias originadas al momento de ser solicitado
un servicio por parte de algún usuario perteneciente a cualquiera de los entes
adscritos a la gobernación del estado Monagas.
La aplicación de encuestas fue de gran utilidad para el desarrollo de esta
etapa, las mismas se realizaron a los usuarios de seis entes pertenecientes a la
Gobernación del Estado Monagas, los cuales fueron: Palacio de Gobierno,
84
Fundación del Niño, Dirección de Comunicaciones, Dirección de sus
impresiones y poder complementar el modelo del negocio. Esta técnica permitió
captar requisitos importantes del sistema que fueron reflejados en los productos
de esta fase.
Con el fin de conocer en detalle el funcionamiento del negocio y
complementar las demás técnicas aplicadas, se recurrió a la observación directa;
mediante la cual se logró colectar detalles importantes para la investigación
relacionados con los servicios prestados por cada una de las coordinaciones, así
como reforzar la información obtenida con las técnicas anteriores y captar
detalles omitidos.
Es importante resaltar que para el desarrollo de esta etapa se empleó el
Estadio 1: La Situación Problema no Estructurada de la metodología para
sistemas blandos de Peter Checkland y las fases 1y 2 (Inicio y Elaboración,
respectivamente) de la metodología UP. Al término de esta fase se obtuvieron los
siguientes productos:
A. Documento visión
B. Plan de desarrollo
C. Plan de iteración general
D. Plan de administración de riesgos
E. Modelado del negocio.
F. Diagramas de caso de uso del negocio
5.1.1 Análisis de encuestas
Para un mejor entendimiento de la situación problema, fue aplicada una
encuesta a 120 usuarios pertenecientes a: Palacio de Gobierno, Fundación del
85
Niño, Dirección de Comunicaciones, Dirección de Hacienda, Dirección de
Policía, Secretaría de Educación; en la que se les consulto en cinco preguntas
cerradas y una abierta en la que la que pudieron contestar según su propia
apreciación. El cuestionario aplicado para la encuesta puede ser revisado en el
Anexo 1. A continuación se muestra el análisis de los resultados de la
encuesta aplicada.
A. Porcentaje de usuarios que hacen uso de cada coordinación
Gráfico 1. Porcentaje de usuarios que hacen uso de cada Coordinación de la DGCT
Fuente. Autor (2009)
Análisis: según los datos recabados mediante la encuesta, el 50% de los
usuarios encuestados utilizan más frecuentemente la coordinación de Soporte en
sitio, seguidos por un 24% que utilizaron mayor frecuencia la coordinación de
Redes y Servidores; el 18%de los encuestados utilizan la coordinación de
Comunicaciones, mientras que el 8% pertenece a la coordinación de Sistemas y
Aplicaciones.
B. Conocimiento de los usuarios acerca de donde recurrir para la solicitud
de servicios telemáticos.
86
Gráfico 2. Conocimiento de los usuarios, acerca de donde recurrir para solicitud
de servicio
Fuente. Autor (2009)
Análisis: el 62% de los usuarios encuestados sabe los medios a seguir para la
solicitud de servicio, mientras que el 38% de los usuarios conoce los medios a
seguir.
C. Frecuencia en que las solicitudes de servicio son resueltas a tiempo.
Gráfico 3. Frecuencia en las solicitudes de servicio son resueltas a tiempo
Fuente. Autor (2009)
Análisis: el 40% de los encuestados considera que algunas veces sus
solicitudes son resueltas a tiempo, un 36% de los usuarios considera que casi
siempre estas son resueltas a tiempo, otro 22% de los encuestados manifestó que
siempre son resueltas tiempo sus solicitudes; por ultimo un 2% de la población
considera que sus solicitudes nunca son resueltas a tiempo.
87
D. Medios utilizados por los usuarios para la solicitud de servicios
Gráfico 4.Medios empleados por los usuarios para la solicitud de servicios
Fuente. Autor (2009)
Analisis: el 62% de los usuarios encuestados manifesto la solicitud de
servicios via telefonica, el otro 28% utiliza oficios para la solicitud de servicios;
mientras que el 10% de los encuestads los realiza en persona.
E. Necesidad de los usuarios de un sistema via web, para la solucitud de
servicios.
Gráfico 5. Necesidad de los usuarios de un sistema web
Fuente. Autor (2009)
Analisis: El 100% de los encuestados considera necerario la implementación
de un sistema web para la solicitud de servico.
F. Funcionalidades y/ caracteristicas deseadas por los usuarios del nuevo
sistema web.
88
Gráfico 6. Funcionalidades y/o características deseadas por los usuarios
Fuente. Autor (2009)
Análisis: el 37% de los usuarios considera que el nuevo sistema web
contengan un modulo de reporte de fallas, el 26% considera necesario la
consulta de estatus, el 20% de los usuarios desea características como la rapidez
de respuesta del sistema si como el 17% de los usuarios que desea que el sistema
sea de fácil acceso.
Habiendo obtenido y computado los resultados de las encuestas, se pudo
tener una mejor comprensión de la percepción de los usuarios pertenecientes a
los entes adscritos a la Gobernación del Estado, acerca de la prestación actual de
los servicios por parte de la División de Telemática. De igual forma se pudo
constatar la necesidad de un sistema automatizado para la gestión de solicitudes
de servicios que además incluyera ciertas características deseadas por los
usuarios.
Las impresiones de los usuarios, referidas a la prestación actual de
servicios, fueron de gran utilidad para complementar el modelo de negocio, en
cuanto a las características deseadas del nuevo sistema web, por parte de los
sujetos encuestados, constituyeron un gran aporte en la elaboración del diseño y
en las tareas de codificación.
89
5.1.2 Entregables de la Etapa I: Especificación conceptual y análisis
de los requerimientos.
Los documentos generados durante el desarrollo de esta etapa, son el
producto de la información obtenida a partir de la aplicación de las técnicas de
recolección de datos, así como del análisis minucioso de los recursos
tecnológicos, humanos, de materiales y de tiempo disponibles para el desarrollo
del proyecto. A continuación se presenta la documentación generada durante
ésta etapa.
90
DIRECCION GENERAL DE CIENCIA Y TECNOLOGIA
DESARROLLO DE UN SISTEMA HELP DESK PARA EL CONTROL Y GESTIÓN DE OPERACIONES, REALIZADAS POR LA DIVISIÓN DE
TELEMÁTICA DE LA DIRECCIÓN DE CIENCIA Y TECNOLOGÍA EN LA GOBERNACIÓN DEL ESTADO MONAGAS.
VisiónVersión 1.0
91
PROYECTO: Desarrollo de un sistema Help Desk para el control y gestión de operaciones, realizadas por la división de telemática de la dirección de ciencia y tecnología en la gobernación del estado Monagas.
Versión: 1.0
Documento: Visión Fecha: 17/07/2009
Historial de Revisiones
Fecha Versión Descripción Autor
06-07-09 0.9 Documento Visión Elio José Luces Cárdenas
20-07-09 1.0 Documento Visión Elio José Luces Cárdenas
92
PROYECTO: Desarrollo de un sistema Help Desk para el control y gestión de operaciones, realizadas por la división de telemática de la dirección de ciencia y tecnología en la gobernación del estado Monagas.
Versión: 1.0
Documento: Visión Fecha: 17/07/2009
Tabla de Contenidos
93
PROYECTO: Desarrollo de un sistema Help Desk para el control y gestión de operaciones, realizadas por la división de telemática de la dirección de ciencia y tecnología en la gobernación del estado Monagas.
Versión: 1.0
Documento: Visión Fecha: 17/07/2009
94
1 Introducción
1. Introducción
2. Vista General del Proyecto
3. Organización del Proyecto
4. Gestión del Proceso
5. Referencias
1. Caso de uso General del Negocio.
2. Vista del modelo de dominio del negocio.
3. Lista de Actor-Objetivo
1. Realizar Traslado.
2. Flujo de Eventos
3. Precondiciones
4. Poscondiciones
5. Diagrama de actividad
1. Actualizar, configurar e instalar programas y aplicaciones2. Flujo de Eventos3. Precondiciones
4. Pos condiciones
5. Diagrama de Actividad
1. Realizar Mantenimiento Correctivo2. Flujo de Eventos3. Precondiciones
4. Poscondiciones
5. Diagrama de Actividad
1. Asesorar, configurar e instalar redes y servidores.
2. Flujo de Eventos.
3. Precondiciones
4. Poscondiciones
5. Diagrama de actividad
1. Realizar Mantenimiento de aplicaciones
2. Flujo de Eventos
3. Precondiciones
4. Poscondiciones
5. Diagrama de Actividad
1. Desarrollar aplicaciones
2. Flujo de Eventos
3. Precondiciones
4. Pos condiciones
5. Diagrama de Actividad
1. Caso de uso general del Sistema
2. Diagrama de caso de uso
3. Flujo de Eventos.
Especificación de caso de uso: Autenticar Usuario.
1. Caso de uso general del Sistema.
Para dar comienzo a este documento, se presenta a continuación el caso de uso
general del sistema.
Diagrama 19. Caso de uso general del Sistema Fuente. Autor (2010)
1.1 Descripción
5. Diagrama de secuencia
PROYECTO: Desarrollo de un sistema Help Desk para el control y gestión de operaciones, realizadas por la división de telemática de la dirección de ciencia y tecnología en la gobernación del estado Monagas.
Versión: 1.0
Documento: Visión Fecha: 17/07/2009
95
2 Posicionamiento3 Descripción de Stakeholders (Participantes en el Proyecto) y Usuarios
4 Descripción Detallada del Producto
5 Descripción Global del Producto
6 Restricciones
7 Precedencia y Prioridad
8 Otros Requisitos del Producto
9 Requisitos de Documentación
