ÍNDICE DE CONTENIDO
CONTENIDO PAG.
1 INTRODUCCIÓN……………………………….………………………………....……..4
2 ANTECEDENTES………………………………………………...……………………...4
2.1 Antecedentes Institucionales………………………………………………..…………. 4
2.2 Misión…………………………………….………………………………………………..5
2.3 Visión.………………………………….…………………………………...……………. 5
2.4 Descripción del caso de Estudio.………………………………………......…………. 5
3 PLANTEAMIENTO DEL PROBLEMA……………………….………………………..6
3.1 Planteamiento del Problema……..………………….…………………..……………..6
3.2 Planteamiento del Problema………………………………….………………………..6
4 OBJETIVO…………………………………...……………………………….................7
4.1 Objetivo General…………………………..………………………….………………… 7
4.2 Objetivos Específicos…………………………………………..……………….………. 7
5 JUSTIFICACIÓN...…..……………………………………….…………………………. 7
6 METODOLOGÍA………………………..…….………..………………….……….…… 8
6.1 Programación Extrema………..………………..…….…………………………..….. 8
6.1.1 Las Historias de Usuario……..………………..………..………………………..….. 8
6.1.2 Roles (XP)……….………………………………….…….………………………..….. 8
6.1.3 Programador………………………………………………………………………..…..8
6.1.4 Cliente……………………………………………………………………………………8.
6.1.5 Encargado de pruebas (Tester)………………………..……………………………..9
6.1.6 Encargado de Seguimiento (Tracker)……………………………………………..…9
6.1.7 Entrenador (Coach)……………… ……………..………………..……………..…….9
6.1.8 Consultor……………………………………..…………….……………………………9
6.1.9 Gestor (Big Boss)……………………………………………………………………….9
6.2 Proceso (XP)…………………………………….……….…………..…..……………..9
6.2.1 Fase I Exploración……………………………………………………………………..10
6.2.2 Fase II Planificación de la Entrega…………………. ………………………………10.
1 - 43
6.2.3 Fase III Iteraciones……………………………………………….……………………10
6.2.4 Fase IV Producción……………………………………………………………………10
6.2.5 Fase V Mantenimiento………………………………………………….…………….11
6.2.6 Fase VI Muerte del Proyecto… ……………………………………….……………11
6.3 Practicas (XP)……………………………………………………………………...…11
6.3.1 El Juego de la Planificación……………………………………………….………..11
6.3.2 Entregas pequeñas………………………………………………………………..…11
6.3.3 Metáfora………………………………………………………………………….……11
6.3.4 Diseño simple…………………………………………………………………………12
6.3.5 Pruebas…………………………………………………………………………..……12.
6.3.6 Refactorización (Refactoring)………………………………………..…………...…12
6.3.7 Programación en parejas……………………………………………………………12
6.3.8 Propiedad colectiva del código…………………………………………………..…12
6.3.9 Integración continúa………………………………………………………………….12
6.3.10 40 horas por semana………………………………………………..………………13
6.3.11 Cliente in-situ…………………………………………………………………………13
6.3.12 Estándares de programación……………………………………….………………13
6.3.13 Comentarios respecto de las prácticas…………………………..………………..13
7. DESCRIPCION DEL PROYECTO……………………………..…………………13
7.1 Análisis Preliminar……………………………………………….…………………13
7.2 Desarrollo del Proyecto………………………………………..…………………14
7.2.1. Estudio de Factibilidad………………………………………….………………..14
7.2.1.1 Hardware del Comando de Comunicaciones………………….………………14
7.2.1.2. Requerimiento de Hardware……………………………………….………………15
7.2.1.3. Software del Comando de Comunicaciones…………………….………………15
7.2.1.4. Requerimiento de Software……………………………………….……………….15
7.2.1.5. Sistemas de Comunicación……………………………………………………….15
7.2.1.6. Requerimiento de Sistemas de Comunicación…………………………………16
7.2.1.7. Operativa…………………………………………………………..………………16
7.2.1.8. Requerimiento de Hardware………………………………………………………16
7.2.1.9. Requerimiento de Software……………………………………………………….17
2 - 43
7.2.1.10. Requerimiento de Sistemas de Comunicación…………………………………17
7.2.1.11. Capacitación……………………………………………………………………….17
7.2.1.12. Desarrollo………………………………………………………………………….17
7.2.1.13. Costo Total del Sistema……………………………………………………….18
7.2.2. Presentar el resultado a la gerencia y al cliente………………………………18
7.2.3. Descripción de la Unidad (Diagrama de paquetes)………………………….18
7.2.4. Tabla de Requisitos………………………………………………………………19
7.2.5. Tabla de Actores……………………………………………………………………20
7.2.6. Tabla de Procesos………………………………………………………………..…20
7.2.7 Diagrama de Casos de Uso de Alto Nivel…………………………………………………..21
7.2.8 Diagramas de Casos de Uso Expandidos……………………………………………...…21
7.2.9 Tabla de Casos de Uso de Alto Nivel………………………………………..……247.2.10. Tablas de Casos de Uso Expandidos……………………………………..………24
7.2.11. Diagramas de Secuencia……………………………………………………..…..27
7.3. Desarrollo……………………………………………………………………...….….29
7.4. Pruebas………………………………………………………………………….…...29
8. IMPACTO…………………………………………………………………………….29
9. BIBLIOGRAFIA…………………………………………………………………..…30
10. ANEXOS………………………………………………………………………………30
10.1 Anexo “A” Pantallas Muertas………………………………………………….……30
10.2 Anexo “B” Pantallas de ingreso y salida……………………………….…………33
10.3 Anexo “C” Planificación……………………………………………………..………34
10.4 Anexo “D” Resultado Entrevista……………………………………………..………35
10.5 Anexo “E” Encuesta a los Usuarios…………………………………………………37
10.6 Anexo “F” Resultado de las Encuestas…………………………………..…………39
3 - 43
En el presente Capítulo se identifica los problemas, objetivos, justificaciones. Las mismas se constituyen en información fundamental para el desarrollo del presente proyecto.
1. INTRODUCCION
La información en una Institución conforma la base fundamental para salvaguardar evidencia de sus actividades, de esta manera facilita la toma de decisiones y administrar e l c ono c i m ie n t o p lasmado en múltiples presentaciones documentales, sin importar su tipo de soporte, con el entendido de que los documentos son material importante de conservar y organizar para cualquier Institución pública o privada.
La documentación es el soporte del sistema de gestión de la calidad, pues en ella se plasman no sólo las formas de operar de la organización sino toda la i n f o r ma ci ó n q ue permite el d e s a r r o l l o de todos los procesos y la toma de decisiones. [BARRY, 1996].
La información manejada por el Comando de comunicaciones del Ejercito, hace imperiosa la necesidad de implementar el Sistema de Control de Registro del Centro General de Comunicaciones, permitiendo de esta manera la rapidez, seguridad y exactitud de la información.
En base a lo expuesto del presente proyecto, se pretende establecer el diseño de un Sistema Web de Control y entrega de información del Sistema General de Comunicaciones para el COMANDO DE COMUNICACIONES, el mismo establecerá la administración de documentos de forma que se use el menor tiempo posible para la emisión de reportes al escalafón superior (grado jerárquico militar), y pueda ser implementada en la institución llegando a tener resultados de desempeño del proceso de las personas.
2. ANTECEDENTES
2.1. Antecedentes Institucionales
La Historia del Arma de Comunicaciones en nuestro Ejército se remonta a las primeras organizaciones de Ingeniería que data del año 1843, cuando el entonces Presidente de Bolivia el Gral. José Ballivián fundó la Escuela de Ingeniería a objeto de capacitar a Oficiales como técnicos en esa especialidad, donde Comunicaciones era solo un apéndice de ésta Arma.
Posteriormente en 1937 se organiza la Escuela Militar de Transmisiones y Enlaces que constituye el punto de partida para la creación como arma.
4 - 43
El año 1.973 se creó el Comando de Transmisiones y Enlaces como parte del Estado Mayor Especial del Comando General del Ejército; y el año 1.982 por Orden de Ejército cambió el denominativo a COMUNICACIONES del Ejército, como actualmente se conoce. Para ello el Comando de Comunicaciones se trazó la siguiente misión:“MODERNIZAR EL SISTEMA Y LOS MEDIOS DE COMUNICACIONES DEL EJÉRCITO CON PERSONAL DE CUADROS CAPACITADOS PROFESIONALMENTE Y CON EQUIPAMIENTO ACORDE A LOS AVANCES TECNOLÓGICOS”.
El año 1996 se implementan los sistemas para la transmisión de datos MODEM, constituyéndose en un hito para la modernización del arma de comando.
2.2. Misión
El comando de comunicaciones del ejército, con todos sus medios humanos, materiales y técnicos disponibles, proporcionara apoyo de comunicaciones, durante la presente gestión, en todo el territorio nacional, para satisfacer las necesidades de comando, control y comunicaciones del Ejército a fin de contribuir al cumplimiento de la misión constitucional del escalón superior.
2.3. Visión
Constituirse en una organización de comando, altamente eficiente y eficaz en la satisfacción de las necesidades de comunicaciones de los diferentes niveles de comando del ejército.
2.4. Descripción del Caso de Estudio
Se pretende establecer el diseño de un Sistema Web de Control y entrega de información del Sistema General de Comunicaciones para el COMANDO DE COMUNICACIONES el mismo optimizara la administración de documentos de forma que se use el menor tiempo posible para la emisión de reportes al escalafón superior (grado jerárquico militar), y pueda ser implementada en la institución llegando a tener resultados de desempeño, eficacia del proceso y la satisfacción de las personas.
Para una mejor comprensión del seguimiento de trámite a continuación se describe los siguientes tipos de documentación:
Interna.- Corresponde toda aquella documentación del Comando de comunicaciones que son recepcionadas o transmitidas.
Los tipos de documentación interna son los siguientes:
• Notas de Servicio• Oficio• Solicitud• Telefonemas.
5 - 43
• Radiogramas.• Ordenes de Servicio.• Informativas.• V arios
Su llenado, registro de salida y entrada se lo realiza de forma manual.
Externas.- Corresponde toda aquella documentación ajena a la institución o proveniente de direcciones del interior del país, además de todos los radiogramas enviadas a las diferentes unidades militares.
Los tipos de documentación externa son los siguientes:
• Solicitud• Invitaciones.• Oficios.• Telefonemas.• Radiogramas.• Entrega directa• Varios•
3. PLANTEAMIENTO DEL PROBLEMA
Se han establecido los siguientes puntos para el planteamiento del problema.
3.1. PROBLEMA PRINCIPAL
Actualmente en el Comando de Comunicaciones del Ejército, el control y entrega de la información se almacena de manera manual, lo que provoca un deficiente control en el almacenamiento de radiogramas transmitidos y recibidos.
3.2. PROBLEMAS SECUNDARIOS
En el Comando de Comunicaciones del Ejército, no se cuenta con un sistema Web de archivo de radiogramas.
La información de documentación de gestiones anteriores se encuentra en archivos manuscritos dispersos y almacenados en ambientes no apropiados dificultando la ubicación específica para el acceso y la obtención inmediata de reportes e informes.
La información archivada en numerosas carpetas, ocasionan la demora en la búsqueda y respuesta de una documentación y como consecuencia se provoca descontento en el escalafón superior.
6 - 43
4. OBJETIVOS
Esta sección abarca la descripción de los objetivos.
4.1. Objetivo General.
Desarrollar un Sistema Web de Control, entrega, y recepción de información de manera precisa, segura y eficiente para mejorar la administración y uso de toda la documentación recibida y expedida del Sistema General de Comunicaciones.
4.2. Objetivos Específicos.
Realizar la recopilación de la información, relacionada con la implementación del sistema Web.
Realizar el análisis de la información obtenida, para el mejoramiento del sistema actual.
Proponer el diseño del Sistema atreves de la metodología XP, la cual se utilizara en la elaboración del proyecto.
Se desarrollara el Sistema para un mejor manejo de la información por parte del personal que trabaja en el Comando de Comunicaciones del Ejército.
5. JUSTIFICACIÓN.
En el Comando de Comunicaciones del Ejército, no se cuenta con un sistema Web de archivo de radiogramas, por el cual es necesario implementar este sistema de registro, asimismo facilitara el control de radiogramas transmitidos y recibidos.
La implementación de la base de datos permitirá que dicha información sea almacenada y de fácil acceso en el sistema general de comunicaciones.
Una vez logrado el objetivo del proyecto, el beneficio brindara la herramienta de centralizar la información.
Los costos que se reducirá con la existencia de la herramienta para la centralización de la información, será favorable tanto para el administrador del sistema como para el comando de comunicaciones
7 - 43
La herramienta permitirá que todo el personal de Radio Operadores tenga la facilidad de centralizar toda la información enviada y recibida de las diferentes Unidades Militares.
6. METODOLOGIA (Materiales y Métodos)
6.1. Programación Extrema (XP.)
Es una metodología ágil centrada en potenciar las relaciones interpersonales como clave para el éxito en desarrollo de software, promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en realimentación continua entre el cliente y el equipo de desarrollo, comunicación fluida entre todos los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los cambios. XP se define como especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo técnico.
A continuación presentaremos las características esenciales de XP organizadas en los tres apartados siguientes: historias de usuario, roles, proceso y prácticas
6.1.1. Las Historias de Usuario Las historias de usuario son la técnica utilizada en XP para especificar los requisitos del software. Se trata de tarjetas de papel en las cuales el cliente describe brevemente las características que el sistema debe poseer, sean requisitos funcionales o no funcionales. El tratamiento de las historias de usuario es muy dinámico y flexible, en cualquier momento historias de usuario pueden romperse, reemplazarse por otras más específicas o generales, añadirse nuevas o ser modificadas. Cada historia de usuario es lo suficientemente comprensible y delimitada para que los programadores puedan implementarla en unas semanas.
6.1.2. Roles XP
Aunque en otras fuentes de información aparecen algunas variaciones y extensiones de roles XP, en este apartado describiremos los roles de acuerdo con la propuesta original de Beck.
6.1.3. Programador
El programador escribe las pruebas unitarias y produce el código del sistema. Debe existir una comunicación y coordinación adecuada entre los programadores y otros miembros del equipo.
6.1.4. Cliente
8 - 43
El cliente escribe las historias de usuario y las pruebas funcionales para validar su implementación. Además, asigna la prioridad a las historias de usuario y decide cuáles se implementan en cada iteración centrándose en aportar mayor valor al negocio. El cliente es sólo uno dentro del proyecto pero puede corresponder a un interlocutor que está representando a varias personas que se verán afectadas por el sistema.
6.1.5. Encargado de pruebas (Tester)
El encargado de pruebas ayuda al cliente a escribir las pruebas funcionales. Ejecuta las pruebas regularmente, difunde los resultados en el equipo y es responsable de las herramientas de soporte para pruebas.
6.1.6. Encargado de seguimiento (Tracker)
El encargado de seguimiento proporciona realimentación al equipo en el proceso XP. Su responsabilidad es verificar el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, comunicando los resultados para mejorar futuras estimaciones. También realiza el seguimiento del progreso de cada iteración y evalúa si los objetivos son alcanzables con las restricciones de tiempo y recursos presentes. Determina cuándo es necesario realizar algún cambio para lograr los objetivos de cada iteración.
6.1.7. Entrenador (Coach)
Es responsable del proceso global. Es necesario que conozca a fondo el proceso XP para proveer guías a los miembros del equipo de forma que se apliquen las prácticas XP y se siga el proceso correctamente.
6.1.8. Consultor
Es un miembro externo del equipo con un conocimiento específico en algún tema necesario para el proyecto. Guía al equipo para resolver un problema específico.
6.1.9. Gestor (Big boss)
Es el vínculo entre clientes y programadores, ayuda a que el equipo trabaje efectivamente creando las condiciones adecuadas. Su labor esencial es de coordinación.
6.2. Proceso (XP)
Un proyecto XP tiene éxito cuando el cliente selecciona el valor de negocio a implementar basado en la habilidad del equipo para medir la funcionalidad que puede entregar a través del tiempo. El ciclo de desarrollo consiste (a grandes rasgos) en los siguientes pasos:
9 - 43
1. El cliente define el valor de negocio a implementar. 2. El programador estima el esfuerzo necesario para su implementación.
3. El cliente selecciona qué construir, de acuerdo con sus prioridades y las restricciones de tiempo.
4. El programador construye ese valor de negocio.
5. Vuelve al paso 1.
En todas las iteraciones de este ciclo tanto el cliente como el programador aprenden. No se debe presionar al programador a realizar más trabajo que el estimado, ya que se perderá calidad en el software o no se cumplirán los plazos. De la misma forma el cliente tiene la obligación de manejar el ámbito de entrega del producto, para asegurarse que el sistema tenga el mayor valor de negocio posible con cada iteración.
El ciclo de vida ideal de XP consiste de seis fases que son:
6.2.1. Fase I: Exploración
En esta fase, los clientes plantean a grandes rasgos las historias de usuario que son de interés para la primera entrega del producto. Al mismo tiempo el equipo de desarrollo se familiariza con las herramientas, tecnologías y prácticas que se utilizarán en el proyecto. Se prueba la tecnología y se exploran las posibilidades de la arquitectura del sistema construyendo un prototipo. La fase de exploración toma de pocas semanas a pocos meses, dependiendo del tamaño y familiaridad que tengan los programadores con la tecnología.
6.2.2. Fase II: Planificación de la Entrega
En esta fase el cliente establece la prioridad de cada historia de usuario, y correspondientemente, los programadores realizan una estimación del esfuerzo necesario de cada una de ellas. Se toman acuerdos sobre el contenido de la primera entrega y se determina un cronograma en conjunto con el cliente. Una entrega debería obtenerse en no más de tres meses. Esta fase dura unos pocos días.
6.2.3 Fase III: Iteraciones
Esta fase incluye varias iteraciones sobre el sistema antes de ser entregado. El Plan de Entrega está compuesto por iteraciones de no más de tres semanas. En la primera iteración se puede intentar establecer una arquitectura del sistema que pueda ser utilizada durante el resto del proyecto. Esto se logra escogiendo las historias que exijan la creación de esta arquitectura, sin embargo, esto no siempre es posible ya que es el cliente quien decide qué historias se implementarán en cada iteración (para maximizar el valor de negocio). Al final de la última iteración el sistema estará listo para entrar en producción.
6.2.4. Fase IV: Producción
La fase de producción requiere de pruebas adicionales y revisiones de rendimiento antes de que el sistema sea trasladado al entorno del cliente. Al mismo tiempo, se
10 - 43
deben tomar decisiones sobre la inclusión de nuevas características a la versión actual, debido a cambios durante esta fase.
Es posible que se rebaje el tiempo que toma cada iteración, de tres a una semana. Las ideas que han sido propuestas y las sugerencias son documentadas para su posterior implementación (por ejemplo, durante la fase de mantenimiento).
6.2.5. Fase V: Mantenimiento
Mientras la primera versión se encuentra en producción, el proyecto XP debe mantener el sistema en funcionamiento al mismo tiempo que desarrolla nuevas iteraciones. Para realizar esto se requiere de tareas de soporte para el cliente. De esta forma, la velocidad de desarrollo puede bajar después de la puesta del sistema en producción. La fase de mantenimiento puede requerir nuevo personal dentro del equipo y cambios en su estructura.
6.2.6. Fase VI: Muerte del Proyecto
Es cuando el cliente no tiene más historias para ser incluidas en el sistema. Esto requiere que se satisfagan las necesidades del cliente en otros aspectos como rendimiento y confiabilidad del sistema. Se genera la documentación final del sistema y no se realizan más cambios en la arquitectura. La muerte del proyecto también ocurre cuando el sistema no genera los beneficios esperados por el cliente o cuando no hay presupuesto para mantenerlo.
6.3. PRÁCTICAS XP.
La principal suposición que se realiza en XP es la posibilidad de disminuir la mítica curva exponencial del costo del cambio a lo largo del proyecto, lo suficiente para que el diseño evolutivo funcione. XP apuesta por un crecimiento lento del costo del cambio y con un comportamiento asintótico. Esto se consigue gracias a las tecnologías disponibles para ayudar en el desarrollo de software y a la aplicación disciplinada de las prácticas que describiremos a continuación.
6.3.1. El juego de la planificación
Es un espacio frecuente de comunicación entre el cliente y los programadores. El equipo técnico realiza una estimación del esfuerzo requerido para la implementación de las historias de usuario y los clientes deciden sobre el ámbito y tiempo de las entregas y de cada iteración. Esta práctica se puede ilustrar como un juego, donde existen dos tipos de jugadores: Cliente y Programador. El cliente establece la prioridad de cada historia de usuario, de acuerdo con el valor que aporta para el negocio. Los programadores estiman el esfuerzo asociado a cada historia de usuario.
6.3.2 . Entregas pequeñas
La idea es producir rápidamente versiones del sistema que sean operativas, aunque obviamente no cuenten con toda la funcionalidad pretendida para el sistema pero que
11 - 43
constituyan un resultado de valor para el negocio. Una entrega no debería tardar más 3 meses.
6.3.3. Metáfora
En XP no se enfatiza la definición temprana de una arquitectura estable para el sistema. Dicha arquitectura se asume evolutiva y los posibles inconvenientes que se generarían por no contar con ella explícitamente en el comienzo del proyecto se solventan con la existencia de una metáfora. El sistema es definido mediante una metáfora o un conjunto de metáforas compartidas por el cliente y el equipo de desarrollo. Una metáfora es una historia compartida que describe cómo debería funcionar el sistema.
6.3.4. Diseño simple
Se debe diseñar la solución más simple que pueda funcionar y ser implementada en un momento determinado del proyecto. La complejidad innecesaria y el código extra debe ser removido inmediatamente.
6.3.5. Pruebas
La producción de código está dirigida por las pruebas unitarias. Las pruebas unitarias son establecidas antes de escribir el código y son ejecutadas constantemente ante cada modificación del sistema.
6.3.6. Refactorización (Refactoring)
La refactorización es una actividad constante de reestructuración del código con el objetivo de remover duplicación de código, mejorar su legibilidad, simplificarlo y hacerlo más flexible para facilitar los posteriores cambios. La refactorización mejora la estructura interna del código sin alterar su comportamiento externo.
6.3.7. Programación en Parejas
Toda la producción de código debe realizarse con trabajo en parejas de programadores. Según Cockburn y Williams en un estudio realizado para identificar los costos y beneficios de la programación en parejas, las principales ventajas de introducir este estilo de programación son: muchos errores son detectados conforme son introducidos en el código, por consiguiente la tasa de errores del producto final es más baja, los diseños son mejores y el tamaño del código menor, los problemas de programación se resuelven más rápido, se posibilita la transferencia de conocimientos de programación entre los miembros del equipo y finalmente, los programadores disfrutan más su trabajo. Dichos beneficios se consiguen después de varios meses de practicar la programación en parejas. En los estudios realizados por Cockburn y Williams este lapso de tiempo varía de 3 a 4 meses.
6.3.8. Propiedad colectiva del código
Cualquier programador puede cambiar cualquier parte del código en cualquier momento. Esta práctica motiva a todos a contribuir con nuevas ideas en todos los
12 - 43
segmentos del sistema, evitando a la vez que algún programador sea imprescindible para realizar cambios en alguna porción de código.
6.3.9. Integración continúa
Cada pieza de código es integrada en el sistema una vez que esté lista. Así, el sistema puede llegar a ser integrado y construido varias veces en un mismo día. Todas las pruebas son ejecutadas y tienen que ser aprobadas para que el nuevo código sea incorporado definitivamente. La integración continua a menudo reduce la fragmentación de los esfuerzos de los desarrolladores por falta de comunicación sobre lo que puede ser reutilizado o compartido.
6.3.10. 40 horas por semana
Se debe trabajar un máximo de 40 horas por semana. No se trabajan horas extras en dos semanas seguidas. Si esto ocurre, probablemente está ocurriendo un problema que debe corregirse. El trabajo extra desmotiva al equipo.
6.3.11. Cliente in-situ
El cliente tiene que estar presente y disponible todo el tiempo para el equipo. Gran parte del éxito del proyecto XP se debe a que es el cliente quien conduce constantemente el trabajo hacia lo que aportará mayor valor de negocio y los programadores pueden resolver de manera inmediata cualquier duda asociada.
6.3.12. Estándares de programación
XP enfatiza la comunicación de los programadores a través del código, con lo cual es indispensable que se sigan ciertos estándares de programación (del equipo, de la organización u otros estándares reconocidos para los lenguajes de programación utilizados). Los estándares de programación mantienen el código legible para los miembros del equipo, facilitando los cambios.
6.3.13. Comentarios respecto de las prácticas
El mayor beneficio de las prácticas se consigue con su aplicación conjunta y equilibrada puesto que se apoyan unas en otras.
La mayoría de las prácticas propuestas por XP no son novedosas sino que en alguna forma ya habían sido propuestas en ingeniería del software e incluso demostrado su valor en la práctica. El mérito de XP es integrarlas de una forma efectiva y complementarlas con otras ideas desde la perspectiva del negocio, los valores humanos y el trabajo en equipo.
7. DESCRIPCION GENERAL DEL PROYECTO.
7.1. Análisis Preliminar.
13 - 43
El presente proyecto presentará de una manera detallada y objetiva un portal web que deberá ser diseñado de modo dinámico, porque manejará base de datos con información de los radiogramas tanto enviadas como receptadas por parte del Centro de Comunicaciones del Ejercito.
El presente proyecto aborda una de las problemáticas que desde hace años afectan a muchas Instituciones Militares, y es el llevar un Control Automatizado efectivo sobre los radiogramas enviadas por parte del Centro Comunicaciones del Ejercito.
El proceso de envíos y recepción de información, la cual tiene como objetivo determinar la información mediante la eficacia, confiabilidad, veracidad y rapidez mediante el control automatizado. Por ende el principal objetivo de este proyecto es realizar un estudio sobre las causas que originan la necesidad de llevar un buen Sistema de Control de entregas de información en las Grandes Unidades de Combate y las herramientas necesarias para erradicar los problemas más comunes en cuanto a los procesos de control manual.
Se observó actualmente la falta de tecnología en el la Institución Castrense, funcionando en forma manual y originando alto grado de desorganización, lentitud en la realización de reportes del envío y recepción, duplicación de radiogramas y demora en la entrega de la información al escalón superior, en el proceso que a su vez ocasiona agotamiento del personal.
Como objetivo general proponer un sistema automatizado que permita el control de envíos y entrega de información en forma automatizada y online (Sistema Web) para dar apoyo a la toma de decisiones por parte de los comandantes de las GG.UU.CC.
Las GG.UU.CC. cuenten con una herramienta poderosa en el control de la recepción y envíos de información, ya que con la implantación de un proceso automatizado, las unidades militares pretendan mejorar, el mecanismo del control de información, obteniendo una verificación rápida de la recepción de las mismas, sobre determinadas operaciones que le permitan aplicar oportunamente.
7.2. Desarrollo del Proyecto.
En este flujo de trabajo se diseñan los estudios de factibilidad, diagramas de paquetes, tabla de requisitos, tabla de actores, tabla de procesos, diagrama de casos de uso, detallando el funcionamiento de cada uno de los procesos, empleando y los diagramas de secuencia que a continuación veremos en el siguiente detalle:
7.2.1. Estudio de Factibilidad.
7.2.1.1. Hardware del Comando de Comunicaciones.
EQUIPO DISPOSITIVO CARACTERÍSTICAS CANTIDADTIEMPO DE
USO
P – IV
Microprocesador Intel Pentium IV 2,54 Mhz 3 2 AÑOSMemoria RAM 512 MBTarjeta madre PC chips series 1100 o similaresLector de CD/DVD 52x o superiorTarjeta de Red Ethermet 10/100 kdps
14 - 43
Monitor 800x600 32bits Disco duro 80 Gb.Procesador Dual Core Xeon 2.00 Ghz. 1 8 MESES
Memoria RAM 5130 MB.Servidor Tarjeta Integrada PERC 5/i Floppy 1,44 Mb. Disco duro 300 Gb. Windows Server 2003 R2.Impresora Canon LJ 500 3 2 AÑOS
7.2.1.2. Requerimiento de Hardware.
EQUIPO DISPOSITIVO CARACTERÍSTICAS CANTIDADTIEMPO DE
USO
Servidor
Procesador INTEL CORE I5 2.8 6M LGA 1155 2 NUEVO
Memoria RAM 6 GB.Tarjeta Integrada PERC 5/i
Floppy FLOPPY CARD READER 3.5"
Disco duro SAMSUNG DISCO DURO 640GB SATA
Windows Server SEVEN 7Lector de CD/DVD SONY DVD-ROM DRIVE
48XMonitor LCD 15"Cooler GENIUS NB STAND 100
7.2.1.3. Software del Comando de Comunicaciones
SOFTWARE CARACTERISTICAS LICENCIA
S.O. Windows NoOffice Word, Excel NoLenguaje Java NoGestor de Base de Datos MySql. SiInternet Explorer Explorer 3.0 o superior SiServidor de Aplicaciones Apache 2.5.1 Si7.2.1.4. Requerimiento de Software
SOFTWARE CARACTERISTICAS MINIMO OPTIMO
S.O. Windows XP 7Office Word, Excel 2008 2010Lenguaje JavaGestor de Base de Datos MySql.Internet Explorer Explorer 3.0Servidor de Aplicaciones Apache 2.5.1
15 - 43
7.2.1.5. Sistemas de Comunicación.
EQUIPO CARACTERISTICAS TIEMPOHUB Dlink, 10 PUERTOS RED Topología estrella
7.2.1.6. Requerimiento de Sistemas de Comunicación.
EQUIPOCARACTERISTICAS
CANTIDADMARCA PROPIEDADES
HUB Dlink 20 Puertos 1RED cable PT, 3m Cat 5 100 mts.
7.2.1.7. Operativa.
USUARIO CANTIDAD NIVEL TIEMPO EN EL CARGO
Cajero 3 Bueno 6 añosAdministrador 1 Bueno 5 añosJefe de personal 1 Muy bueno 8 añosProgramador 1 Muy bueno 10 años
USUARIO NOMBRE NIVEL TIEMPO EN EL CARGO
Cajero Juan chura Bueno 6 añosAdministrador Alex López Bueno 5 añosSecretarias Sergio Luna Regular 3 añosJefe de personal Pedro Sosa Muy bueno 8 años
7.2.1.8. Requerimiento de Hardware.
EQUIPO DISPOSITIVO CARACTERÍSTICAS CANTIDADCOSTO
UNITARIOCOSTO TOTAL
Servidor
Procesador INTEL CORE I5 2.8 6M LGA 1155
2 300 600
Memoria RAM 6 GB. 200 400Tarjeta Integrada
PERC 5/i100 200
Floppy FLOPPY CARD READER 3.5"
300 600
Disco duro SAMSUNG DISCO DURO 640GB SATA
250 500
16 - 43
Windows Server
SEVEN 7123 246
Lector de CD/DVD
SONY DVD-ROM DRIVE 48X
300 600
Monitor LCD 15" 500 1000Cooler GENIUS NB STAND 100 50 100
TOTAL 2123 4246
7.2.1.9. Requerimiento de Software.
SOFTWARE CARACTERISTICAS MINIMO OPTIMOCOSTO
UNITARIOCOSTO TOTAL
S.O. Windows XP 7 500 1000Office Word, Excel 2008 2010 50 100Lenguaje Java 0 0Gestor de Base de Datos MySql. 0 0
Internet Explorer Explorer 3.0 70 140
Servidor de Aplicaciones Apache 2.5.1 0 0
TOTAL 620 1240
7.2.1.10. Requerimiento de Sistemas de Comunicación.
EQUIPOCARACTERISTICAS
CANTIDADCOSTO
UNITARIOCOSTO TOTALMARCA PROPIEDADES
HUB Dlink 20 Puertos 1 600 600RED cable PT, 3m Cat. 5 100 mts. 5 500
TOTAL 605 11007.2.1.11. Capacitación.
USUARIO CANTIDAD NIVELNUMERO DE
HORASCOSTO X
HORACOSTO TOTAL
Cajero 3 Bueno 24 30 720Administrador 1 Bueno 18 45 810Jefe de personal 1 Muy bueno 30 50 300Programador 1 Muy bueno 72 100 7200
TOTAL 90307.2.1.12. Desarrollo.
ETAPADURACION
(MES)NUMERO DE PERSONAL
COSTO PERSONAL
COSTO TOTAL
Análisis de requerimientos 2 2 45 90
Diseño del sistema 4 4 30 120Desarrollo del Sistema 3 2 50 150Pruebas del sistema 1 3 25 25
17 - 43
TOTAL 385
7.2.1.13. Costo Total del Sistema.
DESCRIPCION COSTOS TOTALES
Costos de hardware 4246
Costos del software 1240
Costo de desarrollo 385
Costo de comunicación 1100
Costos de capacitación 9030
TOTAL 16.001 Bs.
7.2.2. Presentar el resultado a la gerencia y al cliente.
Desarrollo de un Sistema Web.
La solución propuesta para el mejoramiento del control de envió y entrega de información a través del Internet incluye los siguientes puntos:
Portal principal: Incluye menú de enlaces a sitios didácticos, sección de impresión, sección de comentarios para el administrador, lista de información publicadas con la fecha de entrega y recepción.
Pagina de registro: Para que los operadores se registren en la página y poder acceder a beneficios como password personal, enlaces y demás.Portal para el ingreso, actualización y eliminación de la información publicada por parte del Comando de Comunicaciones, permitiendo poder almacenar un archivo o tan solo publicar la orden de los radiogramas en el portal.
18 - 43
7.2.3. Descripción de la Unidad (Diagrama de paquetes)
7.2.4. Tabla de Requisitos.
19 - 43
No. Detalle Tipo
R 1 Los radio operadores realizan el manejo del sistemade control y archivo de información
Oculto
R 2 Registro de los datos personales de los radio operadores
Evidente
R 3 Registro de datos de los Radiogramas EvidenteR 4 Registro de datos de los Telefonemas EvidenteR 5 Registro de datos de las Entregas Directas EvidenteR 6 Controlar el Acceso al sistema del SGC.,
mediante un Password y una contraseña de acuerdo a los Movimientos de Usuarios.
Oculto
R 7 Generar un reporte de la información de los radiogramas, de manera semanal, mensual y anual.
Oculto
R 8El sistema autentifica al usuario y le ofrece una lista de acciones disponibles de acuerdo al nivel de acceso que tiene.
Evidente
R 9Registro y seguimiento de la información de Radiogramas (Expedidos y Recibidos).
Evidente
R 10Reporte de Movimiento de información (Radiogramas Expedidos y Recibidos) Evidente
R 11Reportes diarios de los radiogramas, por equipo de comunicación. (detallados)
Evidente
R 12Registrar y almacenar en una base de datos la información de las unidades.
Oculto
R 13 Recibir la información de las GG.UU.CC. Evidente
R 14Permitir la impresión reportes de acuerdo a solicitud del usuario.
Evidente
R 15 Registrar los nombres de la GG.UU.CC. Evidente
R 16 Registrar y almacenar datos del personal. Evidente
7.2.5. Tabla de Actores.
20 - 43
7.2.6. Tabla de Procesos.
No. PROCESOS TAREAS
1Sistema de control de archivos del SGC.
Administrar y/o controlar el registro de los radiogramas y telefonemas.
2Registro de personal Registrar a todo el personal que se
encuentra inmerso en el comando.
3Registro de control de información.
Registrar la información de radiogramas y telefonemas.
4Registro de UU.RR.MM. Registrar las diferentes UU.RR.MM. del
Ejercito.
5Distribución y recepción de información.
Transmisión y recepción a las diferentes UU.RR.MM.
6 Registro de datos Registrar información, reportes.7 Registro de modificaciones Modificar los datos.
21 - 43
ACTOR TAREAS
JEFE DE CENTROHacer cumplir las normas del sistema manual.Toma de decisiones del personal a cargo.Realiza el registro del personal a su mando.
RADIO OPERADOR
Llenar la información de radiogramas telefonemas al sistema.Confirmar el ingreso de datos.Genera reportes diarios Eleva informe.
RO. GUC.
Llenar la información de radiogramas telefonemas al sistema.Confirmar el ingreso de datos.Genera reportes diarios Eleva informe.
8 Registro de cambio Registra los cambios realizados 9 Validar Verificar, el registro de modificación
10 Almacenamiento de datos Lugar donde se guardan los datos.
11Registro de radiogramas y telefonemas
Registrar todos los documentos.
12 Modificación de Rad/Telef. Editar información según requerimiento.
13Envió de radiogramas y telefonemas
Transmisión de información a los diferentes UU.RR.MM.
7.2.7. Diagrama de Casos de Uso de Alto Nivel
7.2.8 Diagramas de Casos de Uso Expandidos
22 - 43
23 - 43
24 - 43
7.2.9 Tabla de Casos de Uso de Alto Nivel
7.2.10 Tabla de Casos de Uso Expandido.
Gestión de Usuario
25 - 43
Caso de uso Sistema web de control y entrega de información del SGC a las GG.UU.CC. del ejército
Actores Jefe de Centro, Radio operador, RO. de la GUC.
Tipo Primario
Descripción En el diagrama de casos de uso de alto nivel muestra que el Jefe de centro y el Radio operador ingresan al sistema con su respectivo nombre de usuario y su password, luego el jefe de centro realiza el registro del personal y tiene el control total del sistema además puede administrar usuarios; el radio operador llena información y generar reportes; el usuario externo solo tiene la facultad de verificar el estado en el que se encuentra su documentación desde cualquier punto del país con su página web.
Registro Personal
26 - 43
Caso de uso Gestión de usuario
Actores Jefe de Centro, radio operador.
PropósitoLo que se ve en el siguiente proceso es el ingreso al sistema con el respectivo nombre de usuario y contraseña.
Tipo PrimarioReferencia cruzada R6, R8
CURSO NORMAL DE ACCIONES
ACCION DEL ACTOR RESPUESTA DEL SISTEMA
1.- El Jefe de Centro y radio operador introducen su respectivo nombre de usuario y contraseña para ingresar al sistema. 2.- El sistema valida datos capturados y
envía a la Base de Datos3.-En la Base de Datos se verifica y compara los datos digitados4.-Al ser comprobado ingresa al sistema asignando prioridades y restricciones
Caso de uso Registro de personalActores Jefe de CentroPropósito contar con los datos del personal dependiente del centro de
comunicaciones y de las GG.UU.CC.Tipo PrimarioReferencia cruzada R2, R6, R8, R15
CURSO NORMAL DE ACCIONESACCION DEL ACTOR RESPUESTA DEL SISTEMA
1.- El jefe de centro realiza la operación de registro al personal.
3.- Llena formulario y guarda
8.- Solicita impresión del formulario.
10.- cierra la sesión.
2.- muestra el formulario de registro
4.- Valida datos del formulario.5.- Verifica los datos del registro6.- Si. Se almacena en la Base de datos7.- No. Datos no correctos vuelve al (paso 3) 9.- Muestra el registro e imprime.
Control de Información
Distribución de la Información
27 - 43
Caso de uso Registro y control de informaciónActores Radio operadorPropósito Poseer información y almacenar en una base de datos. Tipo PrimarioReferencia cruzada R1, R3, R4, R5, R7, R10, R13
CURSO NORMAL DE ACCIONESACCION DEL ACTOR RESPUESTA DEL SISTEMA
1.- El radio operador solicita formulario para llenar la información (radiogramas, telefonemas y entregas directas)
3.- El radio operador llena la información.
8.- solicita la impresión de la información
10.- Cierre de sesión.
2.- muestra el formulario para el llenado.
4.- actualiza y valida la información.5.- Verifica la información llenada.6.- Si. Se almacena la información en la Base de Datos.7.- No. Volver a llenar la información (paso 3).
9.- Muestra la información e imprime.
Caso de uso Distribución de informaciónActores Radio operadorPropósito Enviar y recibir la información a las GG.UU.CC. Tipo PrimarioReferencia cruzada R9, R11, R12
CURSO NORMAL DE ACCIONESACCION DEL ACTOR RESPUESTA DEL SISTEMA
1.- El Radio operador solicita el envío y recepción de la información (radiogramas, telefonemas y entregas directas)
3.- selecciona el destinatario.
8.- Autentica la información. Enviada y recibida.9.- cierre de sesión.
2.- muestra los destinatarios.
4.- Realiza el envio y/o recepción de la información.5.- valida la información.6.- Si. Información enviada, se almacena en la base de datos.7.- No. Información no enviada (vuelve al paso 3)
Registro de GG.UU.CC.
7.2.11. Diagramas de Secuencia.
28 - 43
Caso de uso Registro de GG.UU.CC.Actores Radio operadorPropósito Registrar las GG.UU.CC. Tipo PrimarioReferencia cruzada R9, R14
CURSO NORMAL DE ACCIONESACCION DEL ACTOR RESPUESTA DEL SISTEMA
1.- Realiza la operación de registro de las GG.UU.CC.
3.- Llena formulario y guarda
8.- Solicita impresión del formulario.
10.- cierra la sesión.
2.- muestra el formulario de registro
4.- Valida datos del formulario.5.- Verifica los datos del registro6.- Si. Se almacena en la Base de datos7.- No. Datos no correctos vuelve al (paso 3) 9.- Muestra el registro e imprime.
29 - 43
30 - 43
7.3. DESARROLLO.
Pantallas Muertas (Ver Anexo “A”)
7.4. PRUEBAS
Pantallas de ingreso y salida (Ver Anexo “B”)
8. IMPACTO
La implementación en el Comando de Comunicaciones de un SISTEMA WEB DE CONTROL Y ENTREGA DE INFORMACIÓN DEL S.G.C. A LAS GG.UU.CC. DEL EJÉRCITO, optimizará la administración, flujo y almacenado de radiogramas y telefonemas enviadas como recibidas, realzando de esta manera la aplicación del presente proyecto.
31 - 43
9. BIBLIOGRAFIA.
BERTALANFFY, 1976 Ludwig Von, Bertalanffy TGS “Teoría General de Sistemas” 1976, 208 Paginas.
SENN, 1990 Senn James “Análisis y Diseño de Sistemas” Mc Graw-Hill México 1990.
DATE, 2001 C.J., Date “Introducción a los Sistemas de Bases de Datos” Vol. 2 Sexta Edición, Addison Wesley Iberoamericana, 2001.
COMANCOM., 2012 Comando de Comunicaciones del Ejercito, (Entrevista con el Comandante: 27 Septiembre 2012)
10. ANEXOS
10.1. Anexo “A”
Pantallas Muertas
32 - 43
33 - 43
34 - 43
10.2. Anexo “B”
Pantallas de Ingreso y Salida
35 - 43
10.3. Anexo “C”
Planificación
36 - 43
10.4 Anexo “D”
RESULTADO ENTREVISTA (Al Sr. Cmdte. del Comando de Comunicaciones del Ejercito)
37 - 43
JEFE DE CENTRO
1. ¿Como considera Ud. el actual sistema de Archivo e radiogramas y porque?
El actual sistema de archivos es manual, el Comando necesita un nuevo sistema para facilitar el trabajo.
2. ¿Cuál es el objetivo de implementar el nuevo sistema?
El objetivo de implementar un Sistema Web de Control de Registro de Información es para mejorar el trabajo de los radio operadores de manera segura, precisa y eficiente la información del Sistema General de Comunicaciones.
3. ¿Que desventajas existe en el sistema actual?
La desventaja es, la documentación que uno requiere, debe ser buscado manualmente, esto significa tiempo, asimismo es muy vultuoso.
4. ¿Qué tan seguro es el sistema actual?
El sistema actual no es tan seguro debido a que está expuesto y que puede ser accedido por cualquier personal del Comando.
5. ¿Qué mejoras necesita el sistema actual?
El sistema actual deber ser actualizado por un sistema informático el cual realice el control y archivo de la información.
6. ¿Qué necesita que haga el sistema?
El sistema debe realizar la tarea de poder almacenar todas las informaciones en una base de datos y que permita recuperar la información requerida.
7. ¿Por qué desea cambiar a un nuevo sistema?
38 - 43
Los nuevos adelantos en el actual sistema del mundo de las comunicaciones, esta insertada en un proceso de cambio de todos los sistemas referidos en el manejo de información, en el campo; educativo, Científico, comercial, social y Militar.
Debido a estos nuevos adelantos el comando ha visto por conveniente realizar este cambio.
8. ¿Cuenta con medios para implementar el nuevo sistema?
Tenemos todos los medios disponibles para la implementación de este nuevo sistema.
9. ¿Es necesario capacitar al personal para el uso del nuevo sistema?
Para el manejo de este nuevo sistema es necesario, pero la mayoría del personal ya tiene algún conocimiento básico sobre el nuevo sistema a implantar.
10.¿En que lenguaje quiere que se desarrolle el nuevo sistema?
El nuevo sistema debe ser desarrollado en el lenguaje PHP, es de fácil manejo.
11.¿Quiénes usaran el sistema?
El uso del nuevo sistema estará a cargo de todo el personal de la Jefatura de Radio.
10.5. Anexo “E”
39 - 43
ENCUESTA A LOS USUARIOS
GRUPO 6
Nombre: …………………………………………………………………………………………..
SISTEMA WEB DE CONTROL Y ENTREGA DE INFORMACION DEL SGC A LAS GG.UU.CC. DEL EJERCITO.
Encuesta para los Radio Operadores del Centro de Comunicaciones
Favor de subrayar la respuesta correcta.
1. ¿Hace uso de algún sistema para el archivo de Radiogramas?
Sí No
2. ¿El acceso y consulta del Sistema de archivos se realizan de manera rápida y sencilla, lo que permite disponer de información oportuna?
Nunca Algunas veces Casi siempre Siempre
3. ¿El sistema manual le ha servido como una herramienta de trabajo que facilita el desarrollo de sus actividades?
Nunca Algunas veces Casi siempre Siempre
4. ¿La información contenida se encuentra ordenada de manera tal que facilita su búsqueda e identificación inmediata?
Nunca Algunas veces Casi siempre Siempre
5. ¿Sabe usted a quien recurrir para solicitar información no disponible o bien apoyo técnico en caso de fallas?
Nunca Algunas veces Casi siempre Siempre
6. ¿Sus solicitudes de información o atención han sido atendidas de manera eficiente?
Nunca Algunas veces Casi siempre Siempre
7. ¿Actualmente cuenta con un sistema de archivo de Radiograma confiable?
40 - 43
Si No
8. ¿Es necesario mejorar el sistema actual?
Si No
9. ¿El Sistema actual que utilizan el SGC., es confiable?
Si No
10. ¿Quienes utilizan el sistema de archivos?
Radio operado Jefe de radio
11. ¿Todo el personal de la jefatura de radio conoce el manejo de archivos?
Si No
12. ¿Que tan seguro es utilizar el sistema actual?
Bueno malo regular
13. ¿Tienen conocimiento de este nuevo sistema a implantar?
Si No
14. ¿Trabaja con computadoras?
Si No
15.- ¿Consideran que exista cambios del sistema actual?
Si No
10.6 Anexo “F”
41 - 43
RESULTADO DE LAS ENCUESTAS
1. ¿Hace uso de algún sistema para el archivo de Radiogramas?
R.- El 80 % del personal encuestado no hace uso de algún sistema para el archivo de radiogramas y el 20 % hace uso de un sistema de archivo de radiogramas.
2. ¿El acceso y consulta del Sistema de archivos se realizan de manera rápida y sencilla, lo que permite disponer de información oportuna?
R.- El 55 % del personal encuestado algunas veces tiene el acceso y consulta de manera rápida y sencilla, el 25 % casi siempre, el 20 % nunca y 0 % siempre.
3. ¿El sistema manual le ha servido como una herramienta de trabajo que facilita el desarrollo de sus actividades?
R.- El 45 % del personal encuestado indica que el sistema manual ha servido como una herramienta, el 35 % casi siempre, el 10 % siempre y el 10% nunca le ha servido como una herramienta que facilite el desarrollo de las actividades.
4. ¿La información contenida se encuentra ordenada de manera tal que facilita su
búsqueda e identificación inmediata?
42 - 43
R.- El 55 % del personal encuestado indica que la información contenida de manera ordenada algunas veces facilita la búsqueda e identificación inmediata, el 25 % casi siempre, el 10 % siempre y el 10% nunca se encuentra ordenada de manera tal que facilite su búsqueda.
5. ¿Sabe usted a quien recurrir para solicitar información no disponible o bien apoyo técnico en caso de fallas?
R.- El 40 % del personal encuestado nunca requiere recurrir para solicitar información no disponible o apoyo técnico, el 40 % algunas veces, el 10 % casi siempre y el 10% siempre recurre para solicitar información o apoyo técnico.
6. ¿Sus solicitudes de información o atención han sido atendidas de manera eficiente?
R.- El 50 % del personal encuestado las solicitudes de información algunas veces han sido atendidas, el 25 % casi siempre, el 25 % nunca y el 0% siempre.
7. ¿Actualmente cuenta con un sistema de archivo de Radiograma confiable?
43 - 43
R.- El 90 % del personal encuestado no cuenta con un sistema de archivo de radiogramas y el 10 % cuenta con un sistema de archivo de radiogramas.
8. ¿Es necesario mejorar el sistema actual?
R.- El 100 % del personal encuestado indica que es necesario mejorar el sistema actual y el 0 % no es necesario mejorar el sistema actual.
9. ¿El Sistema actual que utilizan el SGC., es confiable?
R.- El 90 % del personal encuestado indica que el sistema actual que utiliza el SGC no es fiable y el 10 % el sistema actual es fiable.
10. ¿Quienes utilizan el sistema de archivos?
R.- El 55 % del personal encuestado indica que si los radio operadores utilizan el sistema de archivos y el 45 % no utilizan.
44 - 43
11. ¿Todo el personal de la jefatura de radio conoce el manejo de archivos?
R.- El 65 % del personal encuestado si conoce el manejo de archivos y el 35 % no conoce el manejo de archivo.
12. ¿Que tan seguro es utilizar el sistema actual?
R.- El 70 % del personal encuestado indica regular cuan seguro es utilizar el sistema actual, 15 % es bueno y el 1 % es malo e inseguro de utilizar el sistema actual.
13. ¿Tienen conocimiento de este nuevo sistema a implantar?
45 - 43
R.- El 85 % del personal encuestado no tiene conocimiento del nuevo sistema a implantar y el 15 % si tiene conocimiento del nuevo sistema.
14. ¿Trabaja con computadoras?
R.- El 85 % del personal encuestado si trabaja con computadoras y el 15 % no trabaja con computadoras.
15.- ¿Consideran que exista cambios del sistema actual?
R.- El 90 % del personal encuestado considera que si debería existir cambios del sistema actual y el 10 % no consideran que exista cambios del sistema actual.
46 - 43
Recommended
