AUTOMATIZACIÓN DE CRITERIOS PARA EL REPORTE DE INDICADO-RES DE ACREDITACIÓN DE CARRERAS DE INFORMÁTICA Y SISTEMAS

AUTOMATED REPORTING CRITERIA FOR ACCREDITATION OF INDICATORS OF CAREERS COMPUTERS AND SYSTEMS

Ángel González Santillán
Instituto Tecnológico de Tuxtepec
santillan@ittux.edu.mx

María Isabel Hernández Zágada
Instituto Tecnológico de Tuxtepec
maria.isabel.hernandez.zagada@ittux.edu.mx

Resumen

En el departamento de sistemas y computación que depende directamente de la subdirección académica y estas a su vez de la dirección, para llevar a cabo todas las actividades encomendadas por la academia tales como generar propuestas, ideas e innovaciones, para el diseño y desarrollo de proyectos académicos institucionales en forma conjunta, participativa e integral, a través de la conformación de grupos de trabajo se llevan a cabo reuniones de academia en las cuales se tienen actividades futuras a desarrollar, fundamentadas en las prioridades académicas de la institución y de acuerdo con las políticas y lineamientos de mediano plazo enunciadas en el programa nacional educativo del gobierno federal, de los programas que establezcan la Subsecretaría de Educación e Investigación Tecnológicas, así como las políticas educativas determinadas en el apartado para la Dirección General de Institutos Tecnológicos y los mecanismos de coordinación instrumentados por estas, para el diseño y desarrollo de los pro-gramas institucionales, entre los cuales se establecen los siguientes proyectos académicos: seguimiento curricular, Investigación científica y tecnológica, formación y actualización docente y profesional, proyectos de vinculación y residencias profesionales, apoyos académicos, fortalecimiento del proceso enseñanza aprendizaje, adquisición de material bibliográfico, apoyo al posgrado, apoyo a la titulación.

Palabras Clave: Base de datos, SDLC, Fusión charts.

Abstract
In the department of computer systems and reporting directly to the academic subaddress and these in turn direction, to carry out all activities assigned by the academy such as generating proposals, ideas and innovations for the design and development of projects academic institutions together, participatory and integrated through the formation of working groups meetings academy in which future activities are developing, based on academic priorities of the institution and in accordance with the policies carried out and medium-term guidelines set out in national educational program of the federal government, programs that establish the Secretariat for Education and Technological Research and education policies identified in part to the Directorate General of Technological Institutes and coordination mechanisms implemented by these, for the design and development of institutional pro-grams, including the following academic projects are established: curricular track, scientific and technological research, training and educational and professional development, linking projects and professional residences, academic support, strengthening the teaching-learning process, acquisition of library materials, support postgraduate degree support.

Key Words: Database, SDLC, Fusión charts

Fecha recepción:   Junio 2014           Fecha aceptación: Agosto 2014

Introducción

Hoy en día la creación de un sistema web que permita automatizar un estadístico de aquellos criterios que han sido cumplidos y los que no, reportados por cada responsable de cada criterio del formato de autoevaluación de la casa acre-ditadora CONAIC es de gran importancia debido a que un compromiso que se estableció entre la casa acreditadora y el instituto es reportar semestralmente. Por ello, contar con información oportuna para su correcto cumplimiento es de vital importancia para toda la comunidad tecnológica (cuerpo directivo, docente, no docente y alumnos) permi-tiendo modificar la forma de trabajar, haciendo con ello una manera más eficiente y cómoda permitiendo ahorro de tiempo, es por ello que el proyecto se desarrolló contemplando en el capítulo I la problematización que habla de in-formación relevante a los antecedentes, planteamiento del problema, objetivos y justificación. Después, en el capítulo II se ilustra el marco teórico, en el que se muestran los conocimientos de los temas como Ciclo de vida que permitirá observar la metodología de la elaboración de un sistema web, PHP que es un intérprete que trabaja del lado servidor y permite hacer las conexiones y enlaces necesarios entre las interfaces y la base de datos, HTML que es un lenguaje marcador de hipertexto que permitirá la generación de las interfaces vía formularios, y MySql que es el gestor que permitirá dar las propiedades de una base de datos que brinde los beneficios potenciales del acceso a la información.

Todas estas actividades mencionadas anteriormente se llevan a cabo en el seno de la academia y como se puede ob-servar en cada proyecto académico es muy importante y cobra mayor relevancia cuando es atendido en las reuniones llevadas a cabo por los integrantes de la academia de Lic. Informática e Ing. Sistemas Computacionales del Instituto Tecnológico de Tuxtepec. A su vez, atender estos proyectos se refleja en los criterios de acreditación, los cuales forman parte del formato de autoevaluación de la casa acreditadora CONAIC (Consejo Nacional de Acreditación en Infor-mática y Computación), por lo que desarrollar un software que permita verificar qué criterios se han cubierto a la fecha y cuales pendientes, agilizará la toma de decisiones para la entrega oportuna semestral no solo de la información emanada de la academia, sino también de aquella que es proporcionada por las oficinas involucradas en la institución pero que es recopilada por los responsables de cada criterio nombrados por acuerdo en la academia misma.

Para todo ello se utilizará la metodología ciclo de vida que consta de: 1. Identificación de problemas, oportunidades y objetivos, 2. Determinación de los requerimientos de información, 3. Análisis de las necesidades\del sistema, 4. Diseño del sistema recomendado, 5. Desarrollo y documentación del software, 6. Pruebas y mantenimiento del sistema, 7. Implementación y evaluación del sistema.

Para el capítulo III se desarrolló el marco contextual que permite conocer el lugar donde se desarrolló el sistema web, los servicios que ofrece el lugar, así como su historia y naturaleza de la institución. Después, en el capítulo IV se ilustra el proceso metodológico que comprende desde la metodología utilizada considerando las variables de hipótesis a medir y la forma de recopilar la información, así como la aplicación de las 7 fases de la metodología del Ciclo de Vida, permitiendo el diseño, desarrollo e implementación del sistema web. En el capítulo V se presentan los resultados, análisis e interpretación que se llevan a cabo una vez implementado el sistema, midiendo el impacto que este tiene en las variables de hipótesis, así como las conclusiones a las que se llegaron.

DESARROLLO

El ciclo de vida del desarrollo de Sistemas

El ciclo de vida del desarrollo de sistemas (SDLC Systems Development Life Cycle) es una metodología que se uti-liza para desarrollar un sistema (en este caso será un sistema Web) desde el punto de vista de un analista de datos y el usuario, quien es al final quien terminará utilizando el sistema. Como se encontró en Kenneth e. Kendall (2005):
El ciclo de vida del desarrollo de sistemas (SDLC, Systems Development Life Cycle). El SDLC es un enfoque por fases para el análisis y el diseño cuya premisa principal consiste en que los sistemas se desarrollan mejor utilizando un ciclo específico de actividades del analista y el usuario. (p. 10).
El SDLC contempla 7 fases, las cuales se utilizarán para el desarrollo del sistema Web (Sistema de bitácoras de aca-demia). Estas 7 fases van desde la identificación de las necesidades a cubrir, detectar las áreas de oportunidad, hasta la implementación y evaluación del sistema ya instalado. Como se encontró en (Kenneth e. Kendall, 2005, P. 10):

Identificación de problemas, oportunidades y objetivos.

Esta es una de las primeras fases del SDLC y no por ello la menos importante, debido a que en estas se detectan las áreas de oportunidad y una vez detectadas permitirán generar de manera contundente los objetivos que tiene como tendencia cubrir aquellos problemas o necesidades que predominan en la Institución (Instituto Tecnológico de Tuxtepec) al momento de recopilar la información de cada uno de los 11 criterios de acreditación del formato de autoevaluación del CONAIC.

Como se puede observar, esta etapa es muy importante porque si no se llegase a efectuar bien la detección de oportunidades o áreas de mejora, las otras 6 fases se verán afectadas porque están fundamentadas en la primera fase. Como se encontró en (Kenneth e. Kendall, 2005, p. 10), esta etapa es crítica para el éxito del resto del proyecto, pues a nadie le agrada desperdiciar tiempo trabajando en un problema que no era el que se debía resolver.

La labor del analista del sistema es muy importante porque en muchas de las ocasiones, como dice el dicho, dos cabezas piensan mejor que una, y con esto se quiere dar a entender que como analista uno debe ser muy objetivo, preciso. No debe basarse en apreciaciones de una sola persona, sino también en otras más, pues aquellos problemas pueden ser detectados por alguien más, como se encontró en (Kenneth e. Kendall, 2005, p. 10). Con frecuencia los problemas son detectados por alguien más, y esta es la razón de la llamada inicial al analista.

La importancia del analista en esta fase es detectar aquellas oportunidades de mejora que permitan el desarrollo e implementación del sistema, obteniendo una ventaja competitiva para la institución al ser más objetivo por detectar problemas específicos. Por tanto, aquí debe existir una buena relación entre los administradores, usuarios y analistas, que son los involucrados directos en dicha fase.

Al final se espera obtener la viabilidad del sistema que implica la definición y los objetivos del problema detectado, en este caso para la operación de las academias de los institutos tecnológicos. Una vez presentado a la administración, se debe decidir si se sigue adelante o no. Todo ello pudiera darse por varios motivos, por ejemplo, para el caso del tecnológico puede ser por falta de presupuesto, de tiempo en base a la naturaleza de operación de las oficinas, o simple y sencillamente porque la solución al problema no es un sistema como se esperaba.

Determinación de los requerimientos de la información

A diferencia de la anterior, esta fase es para que el analista esté seguro de los objetivos de la institución; en este caso, recopila la información de cada uno de los 11 criterios de acreditación del formato de autoevaluación del CONAIC y de esta manera confirma y comprende la relación que tienen los usuarios responsables de cada criterio (Kenneth e. Kendall, 2005, p. 11). Esta fase es útil para que el analista confirme la idea que tiene de la organización y de sus objetivos.

Aquí el analista debe tener el detalle de las funciones de las diversas partes, como: quién (los que operan en los criterios de acreditación), qué (las actividades se llevan a cabo), dónde (el entorno donde se desarrollan), cuándo (momento en que se desarrollan), cómo (la manera cómo se realiza el procedimiento de autoevaluación). Lo importante aquí es deslindar la razón por la que se utiliza el sistema actual o quizás saber las razones por las cuales existen propuestas para utilizar otros métodos de actualidad en el mercado.

Todo esto le permitirá al analista saber a partir de las actividades con que se genera la recopilación de la información de cada uno de los 11 criterios de acreditación del formato de autoevaluación del CONAIC, cuáles son los elementos de entrada entre el personal involucrado, las salidas esperadas, así como el proceso necesario en las respectivas salidas, y de esa manera mejorar la propuesta del sistema.

Análisis de las necesidades del sistema

Una vez recopilada la información entre los usuarios y administradores (en este caso docentes y personal directivo) visto en la fase anterior, es necesario en esta tercera fase efectuar un análisis de toda esa información cruzando el quién, qué, dónde, cuándo y cómo, para posteriormente expresar esas ideas pero por medio de un diagrama de flujo que permita expresar las actividades que se llevan a cabo en dicho proceso, sus elementos de entrada, así como sus salidas. Todo ello de forma gráfica y estructurada, es decir, plasmar toda esa información en un diagrama de flujo permite no solo reflejar los datos y actores involucrados en el proceso, sino también reflejar datos técnicos que se deberán ir con-templando en el desarrollo del sistema deseado. Tal como se encontró en (Kenneth e. Kendall, 2005, p. 11), a partir de los diagramas de flujo de datos se desarrolla un diccionario de datos que enlista todos los datos utilizados en el sistema, así como sus respectivas especificaciones.

Para el desarrollo de estas fase uno como analista debe de proporcionar una pequeña propuesta del sistema que incluya una visión de las actividades desarrolladas en el formato de autoevaluación del CONAIC con los elementos y actores involucrados pero que a diferencia de llevarlo a cabo de manera manual proporcione los beneficios y costos, así como las alternativas que ofrece el nuevo sistema contrastando las ventajas así como recomendaciones.

Por lo regular, cuando el analista efectúa una propuesta del sistema implica hacer una o varias recomendaciones ya sea por el propio analista por la manera en cómo será más eficiente y eficaz el sistema o por el mismo administrador. Además, el analista también debe mencionar las posibles formas de poder solucionar el problema o área de oportunidad, para elevar la operatividad del reporte de avances del formato de autoevaluación CONAIC.

Diseño del Sistema recomendado

En esta fase el analista debe de utilizar la información recopilada en las fases anteriores para ahora hacer el diseño que va desde las interfaces gráficas de usuario (Pantallas del sistema) comúnmente conocidas como (GUIs, Gra-phical User Interfaces) hasta los archivos o base de datos en que se almacenará la información como se encontró en (Kenneth e. Kendall, 2005, p. 12). La fase de diseño también incluye el diseño de archivos o bases de datos que almacenarán gran parte de los datos indispensables para los encargados de tomar las decisiones en la organización.

Aquí es muy importante saber elegir en qué tipo de archivo se almacenará la información pues de ellos depende mucho la manera en cómo se acceda a ella (información) y se extraiga información de ellos (archivos), a todo esto para cumplir con las especificaciones del sistema detectadas en las fases anteriores, por ello la importancia de tomar la elección correcta en cuanto al tipo de archivo utilizado.

Las interfaces en una computadora son muy importantes pues entre mejor sea la interfaz entre el usuario y la computadora fortalece mejor la comunicación e interacción con ella. Como ejemplos están los teclados o mouse, entre otros, pasando por interfaces más o menos sofisticadas, lo mismo sucede con las pantallas y los menús de pantallas que permiten una buena comunicación entre el usuario y el sistema, considerando desde luego que los datos que se ingresen sean los correctos. Esto se refiere a que no se capturen caracteres erróneos que desfavorezcan el buen funcionamiento del sistema y la base de datos; por ejemplo, en lugar de capturar el nombre de un integrante de academia, capturar su edad, etcétera, tal como se encontró en (Kenneth e. Kendall, 2005, p. 12). El analista diseña procedimientos precisos para la captura de datos que aseguran que los que ingresen al sistema de información sean correctos.

Desarrollo y documentación del software

Prácticamente hasta este momento (fase 5), el analista ha contribuido a desarrollar pseudocódigo y diagramas de flujo basándose en las fases 1 y 2, donde se recopila toda información que pudiese ser necesaria para la viabilidad y operación del desarrollo del sistema Web, sin embargo, no se ha trabajado con la elaboración del software original y es que para que el programador lo desarrolle es necesario tener como entrada lo antes mencionado, pseudocódigo y diagramas de flujo, que son proporcionados por el analista al programador para que este pueda, valga la redundancia, programar el software original (Sistema de bitácoras), como se encontró en (Kenneth e. Kendall, 2005, p. 12). El analista trabaja de manera conjunta con los programadores para desarrollar cualquier software original necesario.

Claro que cuando se diseñan los diagramas de flujo , pseudocódigo, Interfaces gráficas del usuario (GUIs, Graphical User Interfaces) no se detectan errores sintácticos porque el rol del analista es solo ese, programar las entradas y salidas del proceso del reporte de actividades cumplidas en base al formato de autoevaluación CONAIC en papel. Al decir en papel, se da a entender que basándose en el lenguaje de diagramas de flujo, pseudocódigos e Interfaces de usuario, el analista está usando el lenguaje correspondiente que el programador utilizará para poder desarrollar el software original. Ese es el verdadero rol del programador: diseñar, codificar y eliminar los posibles errores sintácticos del software original. Como se encontró en (Kenneth e. Kendall, 2005, p. 12), los programadores desempeñan un rol clave en esta fase porque diseñan, codifican y eliminan errores sintácticos de los programas de cómputo.

Pruebas y mantenimiento del sistema

Algo muy importante en esta fase (6), una vez que sea haya terminado el software original, es probarlo, pero más importante aún es probarlo de manera tal que los problemas a detectar no sean tan costosos en su mismo proceso de detección. Para que no resulte costoso es necesario que en primera instancia el software original creado lo pruebe el mismo programador, solo que la desventaja que se puede tener es que el programador en su misma tarea de crear software original y no dudando de su experiencia, solo detectará líneas sintácticas y quizás mejore la validación de algunas interfaces de usuario (pantallas) porque la naturaleza del programador es solo esa y no la de tener un contacto directo con las personas que lo utilizarán, por lo que una vez que el programador termina de probar el sistema es recomendable que ahora ese sistema (software original) lo pruebe el analista, pues ha sido él quien le dio las ideas, las entradas, las salidas, el desarrollo del proceso en que operan los usuarios y administradores del manual de academias de institutos tecnológicos. El analista conoce y tiene la recopilación de las experiencias vividas de los usuarios que interactúan de manera real en dicho proceso. Sin embargo, es recomendable para acercarse más a la realidad de la objetividad del sistema que cuando este sea probado se alimente con datos reales de usuarios y administradores para de esa forma ganar precisión en la detección de problemas.

Pero, ¿qué hace el analista mientras el programador trabaja en el software original? Mientras el programador se encuentra leyendo y traduciendo las interfaces de usuario, diagramas de flujo y pseudocódigo proporcionados por el propio analista, este se encargará de ir elaborando los manuales correspondientes pudiendo ser manuales de usuarios, manuales de administrador, manuales de supervisores, etcétera. El analista es el que tiene la recopilación de las exigencias y necesidades de los que operan directamente con el proceso. Cuando se entrega el sistema Web con estas fase (6) se desarrolla a futuro el mantenimiento del sistema de información y, por ende, si hay modificaciones al sistema habrá que actualizar los manuales correspondientes, por lo que aquí la tarea persiste entre el analista y el programador respectivamente. Como se encontró en (Kenneth e. Kendall, 2005, p. 13). El mantenimiento del sistema de información y su documentación empiezan en esta fase y se llevan a cabo de manera rutinaria durante toda su vida útil.

Implementación y evaluación del sistema

En esta última fase participan de manera directa el programador y el analista, ya que una vez terminado el sistema de información Web y después de ser probado por ellos se debe de implementar. Con esto se refiere a llevar a cabo una planeación del sistema anterior al actual, si es que ese fuera el caso, y si no existiera un sistema anterior a migrar simplemente se llevaría a cabo una planeación como único sistema. A pesar de que esta etapa se lleva a cabo entre el programador y el analista, el responsable directo es solo el analista.

Cabe aclarar que a pesar de que en esta última fase se presenta la evaluación del sistema de información, no significa que en las otras fases no se evalúe. En realidad, desde la fase 1 se hacen evaluaciones de diversa índole, por ejemplo, en la fase 1 se evalúa la viabilidad del sistema, etcétera. Esta fase ha sido polémica, por lo que solo se evalúa la implementación del sistema, sin descartar las anteriores fases en las que, como ya se mencionó, el enfoque es de evaluación.

Es muy importante aclarar que a pesar de que existen 7 fases no siempre el hecho de terminar una fase y avanzar 3 no quiere decir que no se pueda uno regresar a la fase o fases anteriores pues en realidad pueden ser muchos los motivos por los cuales uno pueda retroceder 1, 2 o más fases y van desde motivos como información mal inter-pretada por el analista, hasta información errónea proporcionada por los que operan con el reporte de actividades cumplidas en base al formato de autoevaluación CONAIC según sea el caso, es por ello que en realidad el trabajo del desarrollo de un sistema es cíclico.

Desarrollo e implementación del software

En esta etapa se desarrolló el software necesario que atiende las especificaciones de las etapas anteriores. La organización de los archivos en el sistema se localizará de la siguiente manera:

Desarrollo e implementación del software

En esta etapa se desarrolló el software necesario que atiende las especificaciones de las etapas anteriores. La organización de los archivos en el sistema se localizará de la siguiente manera:

Para controlar los accesos al sistema hay dos maneras de hacerlo, una que será en modo administrador que podrá ser el presidente, secretario de academia o jefe de departamento, accesando a la carpeta ADMISITRADOR  y otro el integrante de academia accediendo a la carpeta CONSULTA, el primero tendrá todo los derechos y privilegios en el sistema y el segundo solo consultas y reportes dando limitado a modificar, eliminar o dar de alta información. La manera de autentificarse será la siguiente:

Para el desarrollo de la interfaz anterior se consultará la tabla correspondiente a los usuarios registrados permitiendo solo el acceso a los autorizados por el administrador del sistema, como se observa en el siguiente código:

Una vez que el usuario es autentificado y se le permite el acceso al sistema, tendrá derecho según sus permisos a las opciones del sistema. Tomando en cuenta que tenga todos los derechos y privilegios del sistema, se desarrolló el código de los formularios que serán la interfaz entre el usuario y la base de datos, estas sentencias son las mismas que se aplican a todos los formularios de inserción, solo varían los campos y variables a que hace referencia, según sea el caso. Para insertar se tiene el código del formularios siguiente que contempla las variables de las bases de datos.

Fig. No. 2. Formulario y código de inserción.

Para el caso de una consulta de información previamente almacenada en una base de datos se tiene el siguiente formulario, que despliega por default los datos de una tabla, es decir, aquí no se le colocó algún dato a buscar, solo despliega el total de su contenido como se observa en la figura No. 3.

Fig. No. 3. Formulario y código de consulta.

Como se puede apreciar en la figura anterior, también existe un ícono que proporciona la opción de modificar . De la misma forma, no está por demás mencionar que esta misma sentencia aplica a todas las modificaciones que se realizan a las tablas de las bases de datos a la cuales se desee cambiar alguna información previamente cap-turada, lo que vale la pena comentar es que el valor a modificar lo tomará directamente del renglón posición , por lo que en automático mostrará el valor pero con la opción de modificar, como se observa en la figura No. 3:

Fig. No. 4. Formulario y código de modificación de registro específico.

Como se puede apreciar en la figura anterior también existe un ícono que proporciona la opción de eliminar , de la misma forma no está por demás mencionar que esta misma sentencia aplica a todas las modificaciones que se realizan a las tablas de las bases de datos en las que se desee eliminar alguna información previamente capturada. Vale la pena comentar que el valor a eliminar lo tomará directamente del renglón posición de donde se haya tomado ,, por lo que en automático mostraría una ventana para que se confirme la operación seleccionada, como se observa en la figura No. 5:

Fig. No. 5. Formulario y código de eliminación de un registro específico.

En el desarrollo del código se utilizaron la librería fpdf para la generación de archivos .PDF como se muestra en la figura No. 6.

Fig. 6. Reporte .pdf asistencia de docentes.

Para la generación del formato anterior se empleó el siguiente código que utiliza la librería antes mencionada (fpdf), per-mitiendo obtener en tiempo real información que en su momento es capturada vía web dentro o fuera de la institución y ser almacenada en un archivo de lectura. Esto también permite portabilidad de los reportes. El código es el siguiente:

En el código anterior se observa la librería fpdf, así como la configuración de los mensajes que tendrá el archivo que se genere; por otro lado, se genera la conexión a la base de datos que permitirá extraer la información almacenada en sus tablas y después se establece el criterio de consulta que permitirá extraer la información específica. Hasta este momento no se despliega algún resultado, pues solo se declaró la función de la librería, se conectó a la base de datos y se hizo la consulta, de esta misma manera se hace la generación de los demás reportes.

En el código anterior se observa el despliegue de la información que se tomó de la base de datos previamente, para desplegarla se utilizó un while con un ciclo anidado if else, colocando los nombres de los campos que contiene la base de datos en sus tablas respectivas. Todo ello es para la generación de la tabla del formato que solicita conaic.

En el código anterior se muestra la consulta para el caso contrario al previo, es decir, cuando las asistencias cumplan la condición de NO. El formato de salida y el despliegue de la tabla es el mismo que el anterior. De esta forma, solo cambiando las condiciones de consulta y el formato de diseño del reporte Pdf según se requiera, es como se obtienen los formatos de salida solicitados por el usuario.
Para el caso de la generación de reportes de gráficas se utilizó la librería:

1. FusionCharts

La librería (FusionCharts) se utilizó para generar gráficas en tiempo real, pero a diferencia del anterior no se ex-portaron para pegarlas en un documento Pdf, solo se pegaron directamente en la pantalla del sistema para efecto de consulta, como se observa en la siguiente figura:

Fig. 7. Reporte de docentes por carrera.

Para generar todas gráficas de este tipo (FusionCharts), en el sistema se declara al principio la librería a utilizar, lo único que varía entre una gráfica y otras es el tipo de consulta que se vaya a realizar, dependiendo del tipo de informe que se solicite. Lo demás, tanto la conexión, nombre de librería, formato, diseño, tamaño tipo de letra, etcétera, permanecerá igual. La declaración de la librería es la siguiente:

Después de la declaración se inicializan las variables:

Después se procederá a definir las características del texto o leyenda en el eje de las equis, como se observa a continuación:

Una vez colocada la leyenda se procede a desplegar los valores que contendrá cada barra así como sus respectivos colores, como se observa en el siguiente código:

Queda pendiente desplegar la gráfica terminada con sus respetivas características de tamaño, como se observa en el siguiente código:

Al término de la programación de todas las interfaces proporcionadas basadas en las etapas anteriores, se realizaron repasos en la estructura del diseño y codificación, para eliminar errores sintácticos o semánticos en el sistema.

La documentación sobre el buen uso para el mejor desempeño del sistema es primordial, por lo que se diseñaron

1. manuales:

1. Manual del administrador (Jefe de departamento, Coordinador acreditación).

1. Integrante de academia.

CONCLUSIONES

Una vez terminado el análisis, desarrollo e implementación del sistema del sistema, se procederá a comprobar las variables por medio de un cuestionario mencionado con anterioridad antes de aplicar la metodología SDLC (Cuestionario).

Se observa que al automatizar las actividades del procedimiento de las academias en el instituto Tecnológico de Tuxtepec, se disminuyen los tiempos de acceso y localización de la información desde cualquier parte, dentro y fuera de la institución, por lo que cubre las necesidades para lo cual fue creado, permitiendo, entre otras cosas: reducir tiempo en la localización de la información, volver más fácil la toma de decisiones y buscar información, todo ello en tiempo real.

Al concluir el proyecto se observa que las variables de hipótesis plateadas en un inicio, tales como las interfaces, el sistema web y la generación de reportes, todo ello en tiempo real y a distancia (en red), mostraron un resultado positivo considerable al cubrir las necesidades para las cuales fueron creadas. Sin embargo, es necesario mantener una retroalimentación permanente y una mejora continua en el manual de procedimientos.

Bibliografía

DATE, C.J. (2001). Introducción a los sistemas de base de datos. 7a. Ed. Reading Massachusetts, Estados Unidos. Dirección General de Institutos Tecnológicos (1997). Manual de procedimientos para la instalación y operación de las academias en el Sistema Nacional de Institutos Tecnológicos.
KENDALL, E. Kenneth (2005). Análisis y diseño de sistemas. 6a. Ed. School of Business-Camden Camden, New Jersey.
SAMPIERI, Hernández Roberto (2010). Metodología de la Investigación.5a. Ed. SAETHER, Stig (2002). Manual de PHP. 2a. Ed.