SST

CSS HTML JQuery JavaScript PHP PgSQL Proyecto Zend



Especificaciones

  • Año: 2017
  • Categoría: Help Desk
  • Framework: Zend Framework
  • Gráficas: Sí (Highcharts)
  • Lenguajes: PHP, HTML, CSS, JS
  • SGBD: PostgreSQL

Enlaces

  • Código fuente en Github.
  • Archivo .exe de este proyecto.

Situación Problema

El software libre se introduce cada día más en la informática moderna gracias al esfuerzo individual y colectivo de personas que buscan servir constructivamente a otros, así como también de los países que han puesto en marcha una serie de políticas e iniciativas populares en pro de la implementación y el uso del software libre; ya que comienzan a ver esta política tecnológica como un mecanismo para reducir sus gastos de administración, disminuir la dependencia tecnológica e impulsar sus industrias locales de software.

El concepto de software libre que propone Stallman (2004) indica que: Con software libre nos referimos a la libertad de los usuarios para ejecutar, copiar, distribuir, estudiar, cambiar y mejorar el software. Nos referimos especialmente a cuatro clases de libertad para los usuarios de software:

  1. Libertad 0: la libertad para ejecutar el programa sea cual sea nuestro propósito.

  2. Libertad 1: la libertad para estudiar el funcionamiento del programa y adaptarlo a tus necesidades —el acceso al código fuente es condición indispensable para esto.

  3. Libertad 2: la libertad para redistribuir copias y ayudar así a tu vecino.

  4. Libertad 3: la libertad para mejorar el programa y luego publicarlo para el bien de toda la comunidad —el acceso al código fuente es condición indispensable para esto.

Cada vez son más son los países que apuestan por el software libre y Venezuela no es la excepción, pues a finales de diciembre del 2004 surge el decreto presidencial N° 3.390 de la Ley Orgánica de Ciencia, Tecnología e Innovación, donde se ordena en su artículo 1 que, “la Administración Pública Nacional debe emplear prioritariamente Software Libre desarrollado con Estándares Abiertos, en sus sistemas, proyectos y servicios informáticos”.

Este decreto obliga a que todas las empresas del estado migren toda su plataforma tecnológica de forma gradual a software libre, de esta manera estas pueden beneficiarse de las numerosas ventajas que proveen las nuevas herramientas y al mismo tiempo evitar sanciones por parte del estado. Una de las primeras grandes empresas en dar inicio al proceso migratorio fue Petróleos de Venezuela S.A. (PDVSA), con el “Plan de Migración de PDVSA a Software Libre” desde el año 2005.

La empresa Corporación Siderúrgica de Venezuela (CSV) Ferrominera Orinoco siendo parte del conjunto de empresas pertenecientes al estado venezolano, se ha visto en la necesidad de migrar toda su plataforma tecnológica y realizar el desarrollo de nuevos sistemas en software libre, este proceso es llevado a cabo por la gerencia de Telemática.

Dentro las funciones de la gerencia de Telemática se encuentra la gestión de las solicitudes de servicios telemáticos (restauración de claves, revisión, configuración y reemplazo de los equipos de cómputo, desarrollo y mantenimiento de los sistemas de información, gestión de acceso a los sistemas, entre otros), provenientes de las distintas áreas de la empresa, actualmente se cuenta con un sistema basado en software privativo que permite de forma limitada y poco eficiente la gestión de este proceso, entre estas limitantes del sistema se pueden mencionar las siguientes:

  1. No brinda a los usuarios a posibilidad de consultar el estado actual de sus solicitudes ya que solo son notificados cuando se cierran las mismas, por lo que se ven en la necesidad de contactar directamente a los analistas o a los supervisores de estos vía correo electrónico, llamadas telefónicas o incluso encuentros presenciales, solo para preguntar por sus solicitudes.

  2. No cuenta con una herramienta óptima que permita a los usuarios especificar su ubicación física, para ello solo cuenta con un campo de texto en el que los usuarios ingresan lo que su juicio es una descripción de su ubicación física, por lo que en muchas ocasiones los analistas terminan contactando directamente a los usuarios para obtener esa información.

  3. No permite la asignación de una solicitud a múltiples analistas, en su lugar se divide la solicitud original en varias solicitudes lo cual altera las estadísticas de atención (aunque se atiendan varias solicitudes estas pudieron ser o no, en realidad una sola solicitud).

  4. No permite consultar de manera óptima el resumen mensual de solicitudes, ya que debido a la forma en la que está diseñada la consulta (SQL), los tiempos de respuesta oscilan entre 5 y 10 minutos, dependiendo de si ya se ha realizado o no el cierre del mes consultado.

De acuerdo a lo planteado anteriormente el Departamento de Desarrollo y Mantenimiento de Sistemas propone el DESARROLLO DE UN SISTEMA DE GESTIÓN DE SOLICITUDES DE SERVICIOS PARA LA GERENCIA DE TELEMÁTICA DE LA EMPRESA C.S.V. FERROMINERA ORINOCO, el cual estará basado en software libre desarrollado con estándares abiertos, tal como lo establece el decreto presidencial N° 3.390 de la Ley Orgánica de Ciencia, Tecnología e Innovación, ofrecerá nuevas bondades que el sistema actual no soporta y se optimizarán las funciones deficientes del proceso actual.


Objetivos

Objetivo General

Desarrollar un sistema de gestión de solicitudes de servicios para la gerencia de telemática de la empresa C.S.V. Ferrominera Orinoco.

Objetivos Específicos

  1. Comprender el entorno y estándares de desarrollo de la empresa.

  2. Levantar información referente al sistema.

  3. Analizar y definir de requerimientos del sistema.

  4. Confirmar y ajustar de requerimientos.

  5. Diseñar el sistema (diagramas de casos de uso).

  6. Diseñar el modelo entidad-relación y modelo relacional para la base de datos.

  7. Codificar el sistema.

  8. Validar y verificar valores de entrada y salida.

  9. Detectar y corregir vulnerabilidades del sistema.

  10. Implantar el sistema.

  11. Elaborar la documentación del sistema.


Métodos, Técnicas y/o Procedimientos Aplicados

“El proceso del software es una estructura para las actividades, acciones y tareas que se requieren a fin de construir software de alta calidad” (Pressman, 2010, pág. 26). En pro de contribuir en la ejecución del cronograma de actividades descrito en la sección anterior, se evaluaron diferentes modelos de desarrollo de software y se eligió el modelo en cascada. Para Sommerville (2011, pág. 30):

El primer modelo publicado sobre el proceso de desarrollo de software se derivó a partir de procesos más generales de ingeniería de sistemas (Royce, 1970). Debido al paso de una fase en cascada a otra, este modelo se conoce como “modelo en cascada” o ciclo de vida del software. El modelo en cascada es un ejemplo de un proceso dirigido por un plan; en principio, usted debe planear y programar todas las actividades del proceso, antes de comenzar a trabajar con ellas.

En la figura 4 se puede observar como este modelo toma las actividades fundamentales del proceso de especificación, desarrollo, validación y evolución y, luego, los representa como fases separadas del proceso, tal como especificación de requerimientos, diseño de software, implementación, pruebas, entre otros. Este modelo de proceso fue elegido porque se adapta a los estándares de desarrollo planteados por el Departamento de Desarrollo y Mantenimiento de Sistemas y además, se puede ajustar sin complicaciones al sistema que se quiere diseñar.

A continuación se describen las fases implementadas en el desarrollo del sistema de gestión de solicitudes, las cuales están basadas en el modelo en cascada anteriormente descrito:

Fase 1. Análisis y definición de requerimientos: Durante esta fase se conocen las funciones, limitaciones y objetivos del sistema, a través del estudio del sistema actual y entrevistas que se realizan a los usuarios del mismo, para posteriormente ser definidas con detalle y puedan servir como una especificación del sistema.

Fase 2. Diseño del sistema y del software: En esta fase se establece la arquitectura global del sistema a partir de los requerimientos definidos, para lo cual es necesario identificar y describir las abstracciones fundamentales del sistema y sus relaciones. En este caso se utilizaron las siguientes herramientas de diseño: Diagramas de casos de uso, modelo relacional y diccionario de datos.

Fase 3. Implementación y prueba de unidad: Durante esta fase, el diseño del software se realiza como un conjunto de programas o unidades del programa, utilizando para su codificación herramientas y lenguajes de programación basados en software libre (en este caso), como los son PHP, Zend Framework, PostgreSQL, entre otros. Al término de cada unidad se verifica que esta cumpla con su especificación.

Fase 4. Integración y prueba del sistema: En esta fase las unidades de programas o los programas individuales se integran y prueban como un sistema completo, creando, actualizando y eliminando datos, verificando que los valores de salida correspondan con los valores de entrada y asegurándose de que se cumplan con los requerimientos de software. Después de probarlo se elaboran los manuales y se realizan los trámites para su puesta en marcha.


Resultados

Fase 1. Análisis y definición de requerimientos

Gracias a las entrevistas realizadas a los usuarios finales, se analizaron las necesidades de los mismos y se logró obtener una mejor comprensión del proceso de gestión de solicitudes, así mismo a través del estudio del sistema actual se identificaron las funciones (almacenar y administrar solicitudes, emitir reportes estadísticos mensuales, calificar el servicio recibido), limitaciones (detalladas en el planteamiento del problema) y objetivos (hacer seguimiento y control de las solicitudes, agilizar los tiempos de atención de las solicitudes, detectar y corregir fallas en la atención de solicitudes que le permitan a la gerencia ofrecer un mejor servicio) que este cumple en la empresa, de manera que el nuevo sistema pueda ofrecer las bondades con lo que ya se cuenta y mucho más.

Esta información recolectada permite definir los requerimientos funcionales que debe cumplir el sistema, mientras que los requerimientos no funcionales fueron producto del estudio de los estándares de desarrollo y las reuniones con parte del personal del Departamento de Desarrollo y Mantenimiento de Sistemas.

En cuanto a los requerimientos de sistemas de software se refiere, Somerville (2011, pág. 86) nos relata que: A menudo, los requerimientos del sistema de software se clasifican como requerimientos funcionales o requerimientos no funcionales:

  1. Requerimientos funcionales: Son enunciados acerca de servicios que el sistema debe proveer, de cómo debería reaccionar el sistema a entradas particulares y de cómo debería comportarse el sistema en situaciones específicas. En algunos casos, los requerimientos funcionales también explican lo que no debe hacer el sistema.

  2. Requerimientos no funcionales: Son limitaciones sobre servicios o funciones que ofrece el sistema. Incluyen restricciones tanto de temporización y del proceso de desarrollo, como impuestas por los estándares. Los requerimientos no funcionales se suelen aplicar al sistema como un todo, más que a características o a servicios individuales del sistema.

A continuación se mencionan los requerimientos funcionales y no funcionales del sistema de gestión de solicitudes:

Requerimientos funcionales:

  1. El sistema debe permitir el registro de las solicitudes de servicios entrantes, con la opción de adjuntar archivos si el usuario lo desea.

  2. Administrar las solicitudes registradas en el sistema, lo cual implica la aprobación, rechazo, asignación y cierre de las mismas.

  3. Permitir generar dependencias entre las solicitudes registradas que lo requieran.

  4. Contemplar las horas ajenas al encargado de atender la solicitud, para determinar el tiempo real de atención de la misma.

  5. Enviar correos electrónicos que informen acerca de los cambios en el estado de las solicitudes.

  6. Permitir la constante revisión del estado actual de las solicitudes.

  7. Establecer mecanismos que permitan una posterior calificación de las solicitudes una vez que estas han sido atendidas en su totalidad.

  8. Generar estadísticas que permitan evaluar los tiempos de atención a 3 niveles (gerencia, departamento y sección).

  9. El sistema debe producir gráficas en las que se evidencie las calificaciones de los usuarios a tres niveles (gerencia, departamento y sección).

Requerimientos no funcionales:

  1. El sistema debe ser desarrollado utilizando exclusivamente tecnologías basadas software libre, en cumplimiento con el decreto N° 3.390 de la Ley Orgánica de Ciencia, Tecnología e Innovación.

  2. El sistema debe cumplir con los estándares y procedimientos definidos por el Departamento de Desarrollo y Mantenimiento Sistemas de C.S.V. Ferrominera Orinoco.

  3. El sistema debe ofrecer una ofrecer una interfaz amigable a los usuarios del mismo.

  4. El sistema debe manejar eficientemente los recursos disponibles de manera que garantice tiempos respuesta relativamente cortos.

  5. El personal activo de la empresa será único con acceso al sistema.

  6. El sistema debe estar disponible en cualquier computadora conectada a la intranet de la empresa.

Fase 2. Diseño del sistema y del software

Los diagramas de casos de uso, el modelo relacional y el diccionario de datos, fueron los resultados obtenidos de esta fase de diseño, los cuales se muestran a continuación:

Diagramas de casos de uso

Conscientes de su base semántica común, Gómez & Moraleda (2014, pág. 245) subrayan que: Un caso de uso describe, desde el punto de vista de los actores, un grupo de actividades de un sistema que produce un resultado concreto y tangible. Los casos de uso son descriptores de las interacciones típicas entre los usuarios de un sistema y ese mismo sistema. Representan el interfaz externo del sistema y especifican que requisitos de funcionamiento debe tener éste (únicamente el qué, nunca el cómo).

Distribución de módulos del sistema

En la figura 9 se muestra como estarán distribuidos los módulos del sistema a través un mapa jerárquico, el cual representa de manera estática la estructura general del sistema.

Modelo entidad-relación y modelo relacional

Debido a la gran cantidad de elementos involucrados (entidades, atributos, y relaciones) en el diseño de la base de datos, primero se presentará una versión general y simplificada del modelo entidad-relación, para luego mostrar la versión detalla y completa del modelo relacional, a fin de facilitar su comprensión.

A continuación se muestra el modelo relacional utilizado en el diseño de la base de datos, en él se puede observar todas las entidades que intervienen en el sistema con sus respectivos atributos y la relación existente entre ellas.

Diccionario de datos

A continuación se muestra el diccionario de datos del modelo relacional anteriormente presentado.

Fase 3. Implementación y prueba de unidad

Producto de esta fase se logró obtener las funcionalidades individuales del sistema, tales como la generación, consulta, aprobación, rechazo, asignación y cierre de las solicitudes. A continuación se muestran la interfaz que permite realizar las funciones antes mencionadas:

La figura 12 es la interfaz que permite a los usuarios generar nuevas solicitudes, una vez que se ha generado una solicitud por primera vez, el sistema guarda los datos básicos de la persona para que la próxima vez que intente generar una nueva solicitud, se autocompleten estos campos con la última información guardada.

La figura 13 muestra al usuario el estado actual de sus solicitudes, si alguna de estas fue rechazada se coloca en un enlace que permite conocer el motivo por el cual fue rechazada la solicitud.

La figura 14 muestra al supervisor la lista de solicitudes que tiene pendiente para ser aprobadas o rechazadas, en caso de ser rechazada una solicitud se muestra un cuadro de texto que le permite seleccionar o introducir el motivo de rechazo.

La figura 15 muestra al supervisor la lista de solicitudes aprobadas, de manera que este pueda seleccionarlas y asignarlas a algún analista para ser atendidas, también cuenta con un panel que le permite elegir el orden y la cantidad de solicitudes que se muestra.

La figura 16 muestra al analista las solicitudes que tiene asignadas, y le permite administrar los documentos y recursos de la solicitud, llevar el control de cambios, emitir reportes y cerrar la solicitud una vez que esta ha sido atendida.

Fase 4. Integración y prueba del sistema

Durante esta fase se integraron todas las funcionalidades que se habían desarrollado individualmente, lo cual permitió la realización de pruebas de integración, a fin de comprobar el correcto funcionamiento del mismo y el cumplimiento de los requerimientos de software.

En la tabla N° 37 se muestra el plan de pruebas que se realizó en compañía de una de las analistas del departamento.

Para observar con detalle el funcionamiento del sistema véase el manual de usuario (Ver Anexos). A continuación se muestran ejemplos de las estadísticas y gráficas que puede generar el sistema cuando se encuentra operando a plenitud:

La tabla 38 muestra un resumen muy general de la atención mensual de solicitudes a nivel de gerencia. Los datos que se observan antes del mes de diciembre fueron generados al azar una sola vez por lo que se repiten en el resto de los meses, mientras que los datos del mes de diciembre fueron generados de forma controlada durante las pruebas, es por ello que se hará énfasis en este mes en las próximas ilustraciones. El promedio que muestra se refiere al promedio de tiempo de atención en horas.

La tabla 39 muestra un resumen detallado de la atención mensual de solicitudes a nivel de departamento. Los promedios utilizados en estas estadísticas de nivel superior no se hacen referencia a los promedios de nivel inferiores sino que son calculados a partir de tiempos de atención de las solicitudes directamente, es decir, no se están calculando promedios de promedios sino promedios del todo.

La tabla 40 muestra un resumen muy general de la atención mensual de solicitudes a nivel de secciones. Con lo que se cumple con el octavo requerimiento funcional: generación de estadísticas a 3 niveles; gerencias, departamentos y secciones.

Las figuras 17, 18 y 19 muestran las gráficas a nivel de gerencia, departamento y sección respectivamente, generadas a partir de las calificaciones que puede dar un usuario al servicio recibido mediante el uso de encuestas digitales, las cuales poseen un tiempo de vencimiento de 5 días continuos posteriores a la fecha en la que se cerró la solicitud, lo que significa que si un usuario no completa la encuesta en este lapso, se auto calificará como excelente.

Esta característica del sistema obligó al departamento realizar los trámites necesarios para colocar un programa que se ejecute de forma automática diariamente, así el mismo sistema se encarga de validar este comportamiento.


Facilidades, Dificultades Y Aportes

Facilidades

  1. Apoyo y disposición del personal del Departamento de Desarrollo y Mantenimiento del Sistemas y del tutor industrial ante cualquier duda.

  2. Disponibilidad de la documentación de los estándares de desarrollo y herramientas de programación (Zend Framework, PHP, PostgreSQL, entre otros).

  3. Aplicación de conocimientos previamente adquiridos en la Universidad Experimental de Guayana tales como: técnicas de programación, estructura de datos, base de datos, ingeniería del software, desarrollo web, entre otros.

  4. Buen ambiente de trabajo; iluminado, ordenado, limpio, armonioso.

  5. Los usuarios con más jerarquía (supervisores y analistas) pertenecían a la misma gerencia donde se desarrolló la pasantía lo cual facilitó la comunicación con ellos.

Dificultades

  1. Parte de los usuarios finales eran jefes de sección o departamento, por lo que en un principio se presentaron requerimientos que contradecían o anulaban otros requerimientos y resultaba difícil llegar a un consenso.

  2. Cambio de tutor industrial a finales del primer mes desarrollo, lo cual generaba discrepancias con el trabajo que se ya se había realizado.

  3. Falta de experiencia en la utilización de Zend Framework y el patrón de diseño modelo-vista-controlador (MVC).

  4. Surgimiento de cambios en los requerimientos durante las etapas finales del desarrollo.

Aportes datos a la empresa

  1. Desarrollo del sistema de gestión de solicitudes cumpliendo con los requisitos de software y satisfaciendo las necesidades de los usuarios.

  2. Desarrollo del manual de usuario del sistema de gestión de solicitudes.

  3. Apoyo en la familiarización con el entorno de desarrollo de nuevos pasantes.


Conocimientos Adquiridos Durante La Pasantía

A medida que se avanzaba en el desarrollo del sistema de gestión de solicitudes para la gerencia de telemática de la empresa, el pasante obtuvo una serie de conocimientos teóricos y prácticos, los cuales se listan a continuación.

Teóricos

  1. Esquema de trabajo del Departamento de Desarrollo y Mantenimiento de sistemas.

  2. Conocimientos sobre el proceso de gestión de solicitudes que se realiza en la Gerencia de Telemática de la empresa.

  3. Conocimientos sobre el control de proyectos.

  4. Conocimientos sobre el control de inventario de la empresa.

Prácticos

  1. Utilización de un framework en el desarrollo de un sistema como fue el caso de Zend Framework.

  2. Aplicación del patrón de diseño llamado modelo-vista-controlador (MVC).

  3. Utilización de las librerías de JavaScript JQuery y Highcharts (para generar las gráficas).

  4. Profundización en los lenguajes HTML, PHP y SQL.

  5. Mantener presente la extensibilidad y mantenibilidad del sistema al momento de diseñar la base de datos.

Además de ser un requisito para optar al título de ingeniero, la pasantía presentó una oportunidad para experimentar el ambiente laboral en el cual se desenvolverá el pasante en el futuro, así como también permitió aplicar y reforzar todos los conocimientos adquiridos durante la carrera universitaria en la casa de estudios e incluso se obtuvieron nuevos conocimientos.


Conclusiones

  1. Para capturar las necesidades de los usuarios con la máxima precisión posible, es necesario tener una buena comunicación con los mismos, esto facilitará la identificación y compresión del problema a solucionar, de manera que este se pueda analizar correctamente y poder así definir los requerimientos funcionales con los que el usuario se sentirá satisfecho una vez que sea desarrollado el sistema.

  2. En la fase de diseño resulta muy conveniente modelar el sistema lo más parecido al mundo real, ya que las desatenciones en esta fase se pueden traducir en pérdidas de tiempo y esfuerzo en las etapas finales del desarrollo cuando nos vemos en la obligación de rediseñar grandes o pequeñas partes del sistema.

  3. Desarrollar sistemas basados en web le evita a los usuarios muchos temas de los cuales preocuparse, como lo es el tener que descargar o instalar algún software, ocupación de espacio en disco, consumo de recursos, actualizaciones inmediatas, portabilidad, entre otros.

  4. El desarrollo de sistemas basados en web, al ser una las áreas más demandas (al igual que el desarrollo de aplicaciones móviles) en el mundo informático actualmente, resulta altamente beneficioso en el crecimiento profesional de un pasante.

  5. El poder contar con sistemas que generen indicadores de gestión, facilita la detección de ineficacias o ineficiencias en las distintas áreas de una organización, de manera que estas puedan ser corregidas a la brevedad posible.

  6. Se logró cumplir con el objetivo propuesto, desarrollando el Sistema de Gestión de Solicitudes de Servicios, empleando prioritariamente software libre desarrollado con estándares abiertos, tal como lo establece el decreto presidencial N° 3.390 de la Ley Orgánica de Ciencia, Tecnología e Innovación.


Recomendaciones

A la Empresa

  1. Adiestrar a los usuarios, supervisores y analistas en el manejo del sistema de gestión de solicitudes, con la ayuda del manual de usuario de forma que estos sean capaces de aprovechar al máximo las funcionalidades que este ofrece y lo puedan operar eficientemente.

  2. Suministrar al sistema una información lo más detallada posible de las áreas de la empresa (el sistema ofrece un módulo de configuración para esto), lo cual facilitará en gran medida conocer la localización geográfica de los usuarios que requieran una atención presencial.

  3. Definir y planificar periódicamente planes de mantenimiento para el sistema de gestión de solicitudes.

  4. Desarrollar los mecanismos necesarios que permitan comunicar el sistema de gestión de solicitudes con el sistema de control de inventario, lo cual puede aumentar en gran medida la eficiencia en el desempeño de las actividades ambas áreas.

A la universidad y próximos pasantes

  1. Incluir más contenido relacionado con el desarrollo de sistemas basados en web, en las asignaturas pertinentes.

  2. Repasar los contenidos presentados en la casa de estudio relacionados con el desarrollo de software.

  3. Investigar y probar las herramientas de desarrollo de software más utilizadas en el mercado y que no se presentan en la casa de estudio, así se podrá contar con más opciones que faciliten el desarrollo.

  4. Revisar la documentación del sistema de gestión de solicitudes, tanto el manual de usuario como el manual del sistema, ya que puede servir como ejemplo antes de iniciar nuevos proyectos.


Referencias

Ferrominera. (31 de Enero de 2017). CVS FERROMINERA ORINOCO Copyrigth ® 2016. Obtenido de http://www.ferrominera.com/site/

Gómez, S., & Moraleda, E. (2014). Aproximación a la ingeniería del software. Madrid: Centro de Estudios Ramón Areces, S. A.

Laudon, K., & Laudon, J. (2012). Sistema de información gerencial (Decimosegunda ed.). Naucalpan de Juárez: Pearson.

Pressman, R. (2010). Ingeniería del software: Un enfonque práctico. (Séptima ed.). México, D. F.: Mcgraw-Hill.

Sommerville, I. (2011). Ingeniería de software (Novena ed.). Naucalpan de Juárez: Pearson.

Stallman, R. (2004). Software libre para una sociedad libre. Madrid, España: Traficante de sueños.

Whitten, J. (2000). Análisis y Diseño de Sistemas de Información (Tercera ed.). Bogotá: McGraw-Hill.


Nota: Todas las tablas, figuras e imágenes mencionadas en este post se encuentran en el informe que está en los enlaces.