Introducción Con el objetivo de disminuir la deserción

Transcripción

12th INTERNATIONAL CONFERENCE ON INFORMATION SYSTEMS & TECHNOLOGY MANAGEMENT - CONTECSI
REENGINEERING APPLIED TO EARLY WARNING SYSTEM, AS A TOOL TO REDUCE THE VOID IN
HIGH SCHOOL IN MEXICO
Eva Martha Chaparro Salinas
Julio Alvarez Botello
Cesar Enrique Estrada Gutierrez
Maria del Carmen Hernández Silva
This research project outlines a proposal for reengineering of computer Early Warning System,
which is part of the Follow him Strategy, which aims to provide a model of care and
comprehensive support for adolescents and young people who are pursuing a upper secondary
education: 1) Les support to enhance meaningful learning; 2) improve retention and reduce
dropouts, and; 3) increase the completion rate of education.
The early warning system forms a very important role in this model, since, is aimed at early
detection of students at risk of dropping out, to thereby establish mechanisms of attention and
intervention to ensure their permanence in the school.
The proposed reengineering established herein seeks to incorporate innovative elements for
analysis and systematization of information to allow timely institutions identify risk factors for
school failure of students, monitoring their activities and reporting of educational statistics for
better decision-making.
Keywords: Information systems; Education; Scolar statistical
REINGENIERÍA APLICADA AL SISTEMA DE ALERTA TEMPRANA, COMO INSTRUMENTO PARA
ABATIR LA DESERCIÓN EN LOS PLANTELES DE EDUCACIÓN MEDIA SUPERIOR EN MÉXICO
La presente investigación, resume una propuesta de reingeniería del Sistema informático, la cual,
forma parte de la Estrategia “Síguele”, que tiene como objetivo el ofrecer un modelo de atención
y acompañamiento integral para los adolescentes y jóvenes que están cursando la educación
media superior que: 1) Les apoye para mejorar el aprendizaje significativo; 2) disminuya la
deserción escolar, e; 3) incremente la eficiencia terminal del nivel medio superior.
El sistema de alerta temprana tiene como finalidad la detección oportuna de alumnos en riesgo
de abandono escolar, para con ello, establecer mecanismos de atención e intervención oportuna
para lograr su permanencia en la escuela.
La propuesta de reingeniería que establece el presente documento, busca incorporar elementos
innovadores para el análisis y sistematización de información que permita a las instituciones
identificar oportunamente los factores de riesgo de fracaso escolar de los estudiantes,
seguimiento de sus intervenciones y generación de reportes de estadística educativa para la
mejor toma de decisiones.
Palabras clave: Sistemas de información; Educación; Estadística escolar
Introducción
Con el objetivo de disminuir la deserción escolar en Educación Media Superior en México,
la Subsecretaría de Educación Media Superior, con base a la Reforma Integral del Nivel
Medio Superior(RIEMS) implementó la “Estrategia Síguele. caminemos juntos.
Acompañamiento Integral para Jóvenes en el Nivel Medio Superior” la cual tiene como
finalidad mejorar el aprovechamiento académico, contribuir a la disminución de la
deserción y elevar la eficiencia terminal a través de articular una serie de dimensiones:
1
3830
Sistema de Alerta Temprana (SIAT); Sistema Nacional de Tutorías Académicas (SiNaTA);
los Programas de Orientación Vocacional, Construye T, Becas y Fomento a la Lectura.
A tres años de implementación del SIAT se detectaron diversas problemáticas que entre
ellas se enlistan las siguientes:
El proceso de captura de información es deficiente, ya que se realizan cargas
masivas en archivos en Excel y trae como consecuencia que no se respeta la
integridad de la información así también el sistema se tarda mucho tiempo en
procesarla.
No genera reportes de seguimiento de alumnos en riesgo de manera general para
toma de decisiones
No es posible dar el seguimiento de intervención de aquellos alumnos detectados
en riesgo
Para poder medir el cumplimiento de los objetivos del programa no se cuenta con
un sistema paralelo que permita la generación de reportes de indicadores educativos
Hoy en día se hace un seguimiento de manera manual y empírica, por lo cual trae como
consecuencia en contar con datos poco confiables y generación de reportes en tiempos
posteriores a los solicitados o requeridos, por lo que representa una debilidad al no dar
cumplimiento y soluciones oportunas a las necesidades que va presentando el programa.
Por lo anterior la predente investigación pretendió generar una propuesta de reingeniería
del Sistema de Alerta Temprana con el propósito de contar con una herramienta que
contenga información oportuna, confiable, actualizada e integral que permita una mejor
toma de decisiones con base a la detección de alumnos en riesgo de abandono escolar,
seguimiento de intervenciones y reportes de resultados con base a indicadores educativos y
así fortalecer la Estrategia Síguele en el cumplimiento de sus objetivos.
Metodología
Objetivo General
Generar una propuesta de reingeniería del Sistema de Alerta Temprana con el propósito de
contar con una herramienta que contenga información oportuna, confiable, actualizada e
integral que permita una mejor toma de decisiones con base a la detección de alumnos en
riesgo de abandono escolar, seguimiento de intervenciones y reportes de resultados con
base a indicadores educativos y así fortalecer la Estrategia Síguele en el cumplimiento de
sus objetivos.
Tipo de Investigación.
La investigación que se realizará para poder establecer un sistema de toma de decisiones,
es cualitativo de tipo interpretativo, que es una investigación que se emplea cuando se está
buscando un conocimiento más profundo sobre el problema, sus alternativas de decisión y
las variables que se deben considerar.
Preguntas de Investigación.
1. ¿Qué metodología utilizar para la realización de la propuesta de reingeniería de
software?
2. ¿Cuáles son los diferentes tipos de reportes que pueda presentar el sistema que
sean útiles para toma de decisiones?
3. ¿De qué manera se puede recopilar la información necesaria para alimentar el
sistema?
4. ¿De qué forma se puede cargar la información de alumnos que sea más eficiente a
la forma que actualmente utiliza el SIAT?
2
3831
5. ¿Cuáles son los indicadores educativos que se podrán consultar en el SIAT ?
Marco Teórico “Reingeniería”
“La reingeniería debe entenderse como un estímulo al cambio de las realidades
empresariales. Pretende proporcionar soluciones que permitan a las organizaciones
enfrentarse a los retos que exigen los clientes, al obstáculo que representa la competencia
y, por último, al riesgo que supone un importante cambio en la empresa” (Pindado,2010)
Reingeniería de Procesos
“La reingeniería de Procesos, es una de las herramientas de gestión más recientes que
surge a finales de la década de los 80 de la mano de los autores Michael Hammer y James
Champy”. (Pindado,2008)
“La reingeniería se define como la revisión total y el consecuente rediseño profundo de los
procesos, para lograr mejoras espectaculares en aspectos importantes como los costos,
calidad, servicio, tiempo, etc.” (Cuatrecasas,2012)
De los Santos (2008) menciona que conviene distinguir entre mejora y reingeniería de
procesos. La mejora de procesos parte de procesos existentes persiguiendo su mejora
continua modificándolos, para hacerlo más eficiente, eficaz y flexible, mientras que la
reingeniería persigue cambiarlos de forma sustancial buscando una mejora de fuerte
impacto, partiendo a veces incluso de procesos ideales inexistentes, es decir, el rediseño de
los procesos de negocio y su implantación para conseguir los objetivos estratégicos.
-
Reingeniería de Software.
Agarwal(2010) define la reingeniería de software como el proceso de análisis de software
y la alteración del mismo basado en los resultados de análisis. La reingeniería se realiza
con el fin de actualizar el sistema para obtener mejores beneficios tanto para usuarios
finales como los que le dan mantenimiento al sistema.
Los principios de reingeniería fueron aplicados a los procesos de desarrollo de software,
que trae efectos positivos como la reducción del costo del software, mejoramiento en la
calidad, servicio al cliente y velocidad de entrega.
En reingeniería de software recurrimos a uno o más de los siguientes aspectos:
Redefinición del alcance del software y objetivos
Rediseño de la arquitectura de la aplicación usando nueva tecnología, actualizaciones y
plataformas, para hacer los procesos más rápidos, más inteligentes y automáticos
Recurrir a la reestructuración de datos, mejorar el diseño de la base de datos,
reestructuración del código fuente para hacerlo más pequeño y las operaciones más
eficientes.
Reescribir la documentación para hacerlo más entendible para el usuario
La reingeniería de software es frecuentemente asociada con la reingeniería de procesos de
negocio. Un estudio de Patterson P.Sage y B.Rouse (2009, p106 citado en Patterson)
comenta que existe una relación recíproca entre ambas.
La labor facilitadora de las tecnologías de información hacen posible la expansión de las
actividades de los procesos de negocio, así también, los cambios en el software puede
influenciar en cambios del proceso de negocio.
Cambios potenciales en la funcionalidad del software derivado a las mejoras tecnológicas,
puede permitir cambios en el proceso de negocio. Así mismo, cambios en el proceso de
negocio, crea cambios en los requerimientos del software de soporte. Sin embargo, ésta
3
3832
relación de causa y efecto entre reingeniería de procesos de negocio y reingeniería de
software no puede ser generalizado. Cada caso requiere un análisis independiente. El
efecto de proceso de reingeniería de procesos en el software puede variar desde su
mantenimiento común hasta la reingeniería del software.
El software existe para automatizar las funciones del proceso de negocio, el propósito de
un software de soporte puede ser identificado por las funciones que constituyen el proceso.
Por lo tanto, la reingeniería del proceso a nivel funcional, en general, siempre requiere
reingeniería de software con el mismo nivel de propósito. La reingeniería de software
puede ser el resultado del proceso de reingeniería de negocio o puede ser el resultado de la
necesidad del costo-beneficio de las características del software.
La reingeniería comienza con un sistema existente y el proceso de desarrollo para su
reemplazo se basa en comprender y transformar el sistema original. La Figura 1 ilustra el
proceso de reingeniería. La entrada del proceso es un programa heredado y la salida es una
versión modularizada y estructurada del mismo programa.(Agarwal,2010)
Programa
Original
Documentación
del Programa
Programa
Modularizado
Datos originales
Ingeniería
Inversa
Traslado de
Figura
Código
Fuente
Modularización
del Programa
Mejora de la
Estructura del
Programa
Programa
Estructurado
Reingeniería
de Datos
Datos con
reingeniería
Figura No. 1. Proceso de reingeniería(Agarwal,2010)
Durante la reingeniería del programa, los datos del sistema también sufren reingeniería.
Las actividades de éste proceso de reingeniería son:
Traducción del código fuente: El programa es convenido desde un lenguaje de
programación antiguo a una versión más moderna del mismo lenguaje o a un lenguaje
diferente.
Ingeniería Inversa: El programa se analiza y se extrae información a partir de él. Esto
ayuda a documentar su organización y funcionalidad.
Mejora de la estructura del programa: La estructura de control del programa se analiza y
modifica para hacerla más fácil de leer y comprender
Modularización del programa: Se limpia la redundancia de las partes, agrupándolas en
partes relacionadas.
Reingeniería de datos: Los datos procesados por el programa se cambian para reflejar los
cambios en él.
4
3833
Métodos y Modelos del Proceso de Reingeniería del Software.
A continuación de describen los métodos y modelos que son utilizados para realizar una
buena reingeniería del software cuya finalidad es la restructuración de sistemas ya creados.
a) EL METODO DE ANALISIS DE OPCIONES PARA LA REINGENIERIA
(OptionsAnalysisForReingeneering (OAR) )
El Análisis de Opciones para Reingeniería (Clements,2007) (OAR por sus siglas en ingles
de OptionsAnalysisforReengineering) es un método sistemático, de arquitectura central y
de toma de decisiones para la identificación y extracción de componentes dentro de
grandes y complejos sistemas de software. La extracción envuelve rehabilitación de partes
de un sistema viejo para su re-uso. OAR identifica componentes de arquitectura
potencialmente relevantes y analiza los cambios requeridos para usarlos en una línea de
producción de software o nuevas arquitecturas de software. En esencia, OAR proporciona
un conjunto de opciones de extracción junto con estimación de costos, esfuerzo y riesgos
asociados con estas opciones.
La extracción de componentes casi siempre había sido discutido como una alternativa, pero
requería el entendimiento de qué tipos de componentes valían la pena extraer y cómo se
debería extraer. Los siguientes puntos son motivos para el cambio:
Componentes existentes casi siempre eran pobremente estructurados y documentados.
Componentes existentes diferían en niveles de granuralidad.
No había una guía clara sobre cómo salvar componentes
OAR proporciona un acercamiento sistemático para direccionar estos puntos y tomar
decisiones requeridas para el costo efectivo de extraer componentes de sistemas
heredados.
Actividades Principales del Método OAR
Establecimiento del contexto de extracción (ECE).
Es importante para OAR entender el contexto para extracción. La primer actividad de
OAR consiste en entrevistar a los accionistas y estudiar la línea de producción de la
organización. Estos esfuerzos establecen una línea base de un conjunto de metas,
expectaciones y necesidades de componentes.
1.
2.
3.
4.
Inventario de Componentes (IC).
Después del ECE, la OAR identifica componentes del sistema heredado que pueden ser
extraídos para usarlos en una línea de producción.
En el proceso de esta actividad, lo miembros del equipo identifican componentes de líneas
de producción necesarios y evalúan los componentes heredados basados en estos criterios.
Las actividades del IC son seis:
Identificar características de los componentes necesarios:
Determina las características requeridas de los potenciales componentes heredados.
Identifica las características satisfactorias de los componentes:
Crea una tabla de componentes heredados con detalles de sus características.
Filtra los componentes que no satisfacen las características requeridas.
Compara las necesidades de los componentes:
Compara los componentes heredados con detalles de sus características.
Filtra los componentes que no satisfacen las características requeridas.
Inventario de componentes candidatos
5
3834
Actualiza la tabla de componentes con más detalles de los componentes candidatos
seleccionados.
5. Produce tópicos de extracción.
Revisa cualquier tópico de extracción e inquietudes que fueron identificados durante la
actividad.
6. Revisión del calendario OAR:
Actualiza el calendario OAR si fuera necesario.
1.
2.
3.
4.
5.
6.
Análisis de componentes candidatos (ACC)
El siguiente paso de los miembros del equipo es analizar el conjunto de los candidatos de
componentes heredados para extraer los tipos de cambios que son requeridos. Esta
actividad tiene seis tareas:
Selección de componentes deseables.
Determinar criterios deseables para cada componente heredado.
Deja afuera aquellos que no satisfacen esos criterios.
Identifica los componentes “Tal como están y de caja negra”.
Determinan aquellos componentes que pueden ser tapados o usados “tal como están.
Identifica componentes de caja blanca.
Determina aquellos componentes que necesitarán ser modificados.
Determina cambios requeridos
Determina los tipos de cambios que cada componente necesitará, el costo y el esfuerzo
involucrados, el nivel de dificultad y riesgos, el costo y esfuerzo comparativo para el
desarrollo de componentes desde cero.
Producción de tópicos de extracción.
Revisa cualquier tópico de extracción e inquietudes que fueron identificado durante la
actividad.
Revisa del calendario OAR:
Plan de opciones de extracción (POE)
Teniendo el conjunto de componentes de candidatos analizados, el equipo desarrolla
alternativas para la extracción basada en consideraciones de calendario, costo, esfuerzo,
riego y recursos. POE tiene siete tareas:
1. Selecciona componentes favorables:
Desarrolla criterios, tales como el costo o niveles de esfuerzos requeridos.
2. Ejecución de intercambio de componentes:
Identifica un componente por línea de producción de componentes necesarios.
3. Formas opciones de componentes:
Desarrolla criterios para agregar componentes.
4. Determina costos comparativos de esfuerzos:
Compara el costo para cada agregación con el costo a desarrollar desde cero.
5. Analiza dificultad o riesgo :
Determina el nivel de dificultad y riesgo involucrados por cada agregación.
6. Producción de tópicos de extracción:
Revisa cualquier tópico de extracción e inquietudes que fueron identificados durante la
actividad.
7. Revisa del calendario OAR:
6
3835
Selección de opciones de extracción (SOE)
Como último paso los miembros del equipo seleccionan la mejor opción de extracción
para programas y consideraciones técnicas. Una vez terminando de evaluar cada opción de
extracción, preparan un resumen y presenta y justifica sus elecciones.
La actividad SOE tiene cinco tareas:
1. Elegir la mejor opción:
Determina los controladores para seleccionar entre las opciones.
Selecciona una opción o combinación de ellas.
2. Verificación de opción:
Guarda todos los detalles acerca de cada de las opciones escogidas.
3. Identifica componentes necesarios satisfechos.
Completa la lista final de componentes necesarios satisfechos y no satisfechos atreves de
las opciones seleccionadas.
4. Presentación de descubrimientos.
Prepara la presentación de descubrimientos que proporciona detalles acerca de las opciones
selecciona.
5. Producción de resumen.
Producción de un reporte final ya detallando las opciones seleccionadas y las razones para
esas elecciones.
Tareas Especializadas.
Las actividades tienen a su vez un grupo de actividades particulares que guían los
diferentes escenarios que podrían impedir que se cumplan. Existen las siguientes
condiciones para aplicar esas tareas:
Actividades no satisfechas.
Se requiere más trabajo.
Se requieren datos adicionales.
Existe necesidad de completar tareas estándares OAR.
Estructura de actividades
Las tareas tienen sub-tareas para resolver cuestiones de actividades específicas. Estas
cuestionen definen la actividad y sirven como puntos para revisar cada actividad.
Figura 2.Actividades del Método OAR(Clements,2007)
b) EL MODELO HERRADURA
7
3836
De acuerdo a Streekmann(2012),se describe a continuación el modelo herradura: los tres
procesos básicos de análisis de un sistema existente, transformación lógica y desarrollo de
un nuevo sistema forman la base del modelo de herradura. El primer proceso sube el
extremo izquierdo de la herradura, el segundo cruza la parte superior y el tercero baja por
el extremo derecho de la herradura.
Los Tres Niveles Del Modelo Herradura
En el modelo herradura existen tres niveles:
"Representación de la estructura de código", el cual incluye código fuente y artefactos tales
como árboles de sintaxis abstractos y diagramas de flujo obtenidos a través del análisis
gramatical y operaciones analíticas de rutina.
"Representación del nivel funcional", el cual describe la relación entre las funciones del
programa (llamadas), datos (funciones y relaciones de datos), y archivos (agrupamiento de
funciones y datos).
"Nivel conceptual", el cual representa grupo tanto de funciones y artefactos del nivel de
código que son ensamblados dentro de subsistemas de componentes relacionados o
conceptos. El modelo completo no solo hace transformaciones en el nivel de arquitectura,
también lo hace en los niveles subsidiarios.(Streekmann,2012)
c) EL MODELO CÍCLICO
Este modelo define 6 actividades (William,2009)las cuales se muestran en la figura 3
Figura
Figura 3.Modelo cíclico(William,2009)
Esto significa que cada una de las actividades presentadas como parte del paradigma puede
repetirse en otras ocasiones. Para un ciclo en particular, el proceso puede terminar después
de cualquier de estas actividades.
Análisis de Inventario: Todas las organizaciones de software deberán disponer de un
inventario de todas sus aplicaciones. El inventario puede que no sea más que una hoja de
cálculo con la información que proporciona una descripción detallada (por ejemplo:
tamaño, edad, importancia para el negocio) de todas las aplicaciones activas.
Los candidatos a la reingeniería aparecen cuando se ordena esta información en función de
su importancia para el negocio, longevidad, mantenibilidad actual y otros criterios
localmente importantes. Es entonces cuando es posible asignar recursos a las aplicaciones
candidatas para el trabajo de reingeniería.
8
3837
Es importante destacar que el inventario deberá revisarse con regularidad. El estado de las
aplicaciones (por ejemplo, la importancia con respecto al negocio) puede cambiar en
función del tiempo y, como resultado, cambiarán también las prioridades para la
reingeniería.
Restructuración de Documentación. Una documentación escasa es la marca de muchos
sistemas de información heredados. ¿Qué se puede hacer al respecto?
a) La creación de documentos consume demasiado tiempo. El sistema funciona, y ya nos
ajustaremos con lo que se tiene. En algunos casos, éste es el enfoque correcto. No es
posible volver a crear la documentación para cientos de programas de computadoras. Si un
programa es relativamente estático está llegando al final de vida útil, y no es probable que
experimente muchos cambios: ¡dejémoslo así!.
Es preciso actualizar la documentación, pero se dispone de recursos limitados.Se utilizará
un enfoque “del tipo documentar si se modifica”. Quizá no es necesario volver a
documentar por completo la aplicación. Más bien se documentarán por completo aquellas
partes del sistema que estén experimentando cambios en ese momento. La colección de
documentos útil y relevante irá evolucionando con el tiempo.
El sistema es fundamental para el negocio, y es preciso volver a documentarlo por
completo.Incluso en estos casos, un enfoque inteligente, es resumirla documentación aun
mínimo esencial.
Todas y cada una de estas opciones son viables. Las organizaciones del software deberán
seleccionar aquella que resulte más adecuada para cada caso.
Ingeniería Inversa. El término “ingeniería inversa” tiene sus orígenes en el mundo del
hardware. Una cierta compañía desensambla un producto de hardware competitivo en un
esfuerzo por comprender los “secretos” del diseño y fabricación de su competidor. Estos
secretos se podrán comprender más fácilmente si se obtuvieran las especificaciones de
diseño y fabricación del mismo. Pero estos documentos son privados, y no están
disponibles para la compañía que efectúa la ingeniería inversa. En esencia, una ingeniería
inversa con éxito precede de una o más especificaciones de diseño y fabricación para el
producto, mediante el examen de ejemplos reales de ese producto.
La ingeniería inversa del software es algo bastante similar. Sin embargo, en la mayoría de
los casos, el programa del cual hay que hacer una ingeniería inversa no es el de un rival,
sino, más bien, el propio trabajo de la compañía (con frecuencia efectuado hace muchos
años). Los “secretos” que hay que comprender resultan incomprensibles porque nunca se
llegó a desarrollar una especificación. Consiguientemente, la ingeniería inversa del
software es el proceso de análisis de un programa con el fin de crear una representación de
programa con un nivel de abstracción más elevado que el código fuente. La ingeniería
inversa se extraerá del programa existente información del diseño arquitectónico y de
proceso, e información de los datos
Restructuración de código. Es el tipo más común de reingeniería. Algunos sistemas
heredados tienen una arquitectura de programa relativamente sólido, pero los módulos
individuales fueron codificados en una forma que hace difícil
comprenderlos,
comprobarlos y mantenerlos, En estos casos, se puede reestructurar el código ubicado
dentro de los módulos sospechosos.
Para llevar a cabo esta actividad, se analiza el código fuente mediante una herramienta de
reestructuración, se indican las violaciones de las estructuras de programación
estructurada, y entonces se reestructura el código (esto se puede hacer automáticamente).
El código reestructurado resultante se revisa y se comprueba para asegurar que no se hayan
introducido anomalías. Se actualiza la documentación interna del código.
9
3838
Reestructuración de Datos. Un programa con arquitectura de datos débil será difícil su
adaptación y mejora. De hecho, para muchas aplicaciones, la arquitectura de datos tiene
más que ver con la viabilidad a largo plazo de un programa que el propio código fuente.
A diferencia de la reestructuración de código que se produce a un nivel relativamente bajo
de abstracción, la estructuración de datos es una actividad de reingeniería a gran escala.
En la mayoría de los casos, la reestructuración de datos comienza por una actividad de
ingeniería inversa. La arquitectura de datos actual se analiza minuciosamente y se definen
los modelos de datos necesarios. Se identifican los objetos de datos y atributos y, a
continuación, se revisan las estructuras de datos a efectos de calidad. Cuando la estructura
de datos es débil (por ejemplo, actualmente se implementan archivos planos, cuando un
enfoque relacional simplificaría muchísimo el procesamiento), se aplica una reingeniería a
los datos.
Dado que la arquitectura de datos tiene una gran influencia sobre la arquitectura del
programa, y también sobre los algoritmos que los pueblan, los cambios en datos darán
lugar invariablemente a cambios o bien de arquitectura o bien de código.
Ingeniería Directa. La ingeniería directa, que se denomina también renovación o
reclamación, no solamente recupera la información de diseño de un software ya existente,
sino que, además, utiliza esta información en un esfuerzo por mejorar su calidad global. En
la mayoría de los casos, el software procedente de una reingeniería vuelve a implementar
la funcionalidad del sistema existente, y añade además nuevas funciones y/o mejora el
rendimiento global.
La siguiente figura muestra los procesos que sigue la ingeniería directa, si seguimos ese
camino hacia "atrás" (o de manera inversa), hacemos ingeniería inversa, si continuamos
con el camino y planteamos cambios (o mejoras), por la derecha, ese camino nos lleva a
una reingeniería, si no alteramos el contenido de los modelos obtenidos durante los
procesos de la ingeniería inversa y seguimos el camino de la izquierda, eso se llama
desarrollar una copia.
Figura 4.Proceso Ingeniería Directa(Sommerville,2012)
10
3839
Resultados del estudio de Reingeniería del Sistema de Alerta Temprana
Reingeniería del Sistema de Alerta Temprana
¿Por qué aplicar reingeniería?
Es necesario que a partir del Sistema de Alerta Temprana se logre facilitar la
identificación, control y seguimiento de los alumnos en riesgo de abandono escolar y que a
partir de la información generada, los docentes-tutores logren incidir oportunamente en los
alumnos con riesgo de abandono y con ello cumplir con los objetivos planteados de la
Estrategia Síguele. Por lo que se considera prioritario, lograr que a través del SIAT sea
posible cuantificar las acciones para estar en condiciones de analizar su impacto en la
permanencia de los estudiantes.
Actualmente, el SIAT ofrece pocas alternativas para facilitar estas actividades, se sugieren
la incorporación de nuevos requerimientos, modificación de algunos de sus requisitos
originales, y contar con su documentación correspondiente, ya que , actualmente no hay
documentación existente, por lo tanto, se hace necesaria la construcción de un nuevo
prototipo.
El modelo que se usará para la Reingeniería del Sistema de Alerta Temprana es el Cíclico,
ya que aporta flexibilidad en el orden de realización de cada una de sus actividades con
base a las necesidades del proyecto. Para un ciclo en particular, el proceso puede terminar
después de cualquier de sus actividades que la componen.
Es importante mencionar que la actividad de documentación se estará realizando conforme
se vayan realizando cada actividad que plantea el modelo.
Análisis de Inventario.
Se describen a continuación las características del Sistema de Alerta Temprana:
Nombre
de
la Sistema
Aplicación
Temprana
Tamaño
Grande
Edad
3 años
Nivel
de Alta
Importancia
Funcionalidad
40%
Usabilidad
70%
Fiabilidad
40%
Mantenibilidad
60%
Interoperabilidad
80%
de
Alerta
Figura 5.Características del SIAT
Caballero y Calero(2009) menciona las definiciones de algunos de los atributos
establecidos por el estándar ISO-9126 para determinar la calidad de software:
Funcionalidad: Capacidad del software de proveer los servicios necesarios para cumplir
con los requisitos funcionales
Usabilidad:Consiste de un conjunto de atributos que permiten evaluar el esfuerzo necesario
que deberá invertir el usuario para utilizar el sistema
Fiabilidad:La fiabilidad del software se define en términos estadísticos como la
probabilidad de operación libre de fallos de un software en un entorno determinado.
11
3840
Mantenibilidad: Representa el esfuerzo para realizar modificaciones específicas
Interoperabilidad: Se refiere al esfuerzo necesario para comunicar un sistema con otro.
Restructuración de Documentación
El SIAT para la prevención de la deserción escolar es un recurso de la Estrategia Síguele,
un momento fundamental del proceso, pues aporta nada menos que la información que
permite decidir oportunamente dónde, cómo, y sobre todo, con quiénes incidir.
Con el SIAT 2.0, se adicionan reportes de resultados adaptado a las necesidades de cada
nivel de consulta (Plantel, Subsistema, Entidad Federativa y Nacional) para el seguimiento
y análisis controlado del comportamiento de los alumnos de Educación Media Superior.
El siguiente diagrama permite conocer la operación del SIAT 2.0 en el contexto del
proceso general al que pertenece:
Figura 6. Diagrama de procesos SIAT
3841
12
Ingeniería Inversa.
La ingeniería inversa tiene la misión de descubrir cómo funciona un programa y
recuperar el diseño de una aplicación a partir del código fuente.
El Sistema de Alerta Temprana no cuenta con documentación existente que permita
entender el funcionamiento interno del programa, por lo tanto, se considera importante
aplicar ingeniería Inversa al sistema, la cual, es un método eficiente para entender el
funcionamiento del sistema, ya que involucra, principalmente, la obtención de los
componentes arquitectónicos y la re documentación de esos componentes. La ingeniería
inversa permite alcanzar una idea clara de qué hace el programa y cómo lo hace, lo que
posibilita la reutilización de los artefactos o componentes existentes.
El proceso de ingeniería inversa con UML, se basa en el análisis de bibliotecas y
componentes existentes. Con la ayuda de los modelos visuales, se puede integrar el código
heredado en una nueva arquitectura remodelada.
Se prevé que el SIAT se extienda constantemente, debido a características propias del
ambiente en el que se encuentra inserto. Por lo tanto, es necesario un método que guíe las
modificaciones del diseño a medida que cambien los requerimientos
Así, se decidió utilizar el modelo UML para representar el diseño recuperado del SIAT;
diseño que sirvió de guía en la extensión del diseño original de una manera rápida y
ordenada.
Recuperación Arquitectónica
Para describir la arquitectura del SIAT, se usó el modelo de 4+1 compuesto de múltiples
vistas o perspectivas
Programadores
Gestión del Software
Usuario Final
Funcionalidad
Vista de
Desarrollo
Vista Lógica
Escenario
Vista Procesos
Integradores
Rendimiento
Escalabilidad
Vista Física
Figura 7.Modelo 4+1(Caballero,2009)Ingeniería de Sistemas
Topología
Comunicaciones
Vista Lógica: Soporta el análisis y la especificación de los requisitos funcionales: lo que el
sistema debería proporcionar en términos de servicios a sus usuarios. El sistema se
descompone en un conjunto de abstracciones clave tomadas mayormente del dominio del
problema, en forma de objetos o clases.
Vista de Procesos: La vista se centra en la concurrencia y distribución de procesos.
13
3842
Vista de Desarrollo: La vista de desarrollo o despliegue se enfoca en la organización de los
módulos software en el entorno de desarrollo. El software es empaquetado en pequeños
trozos
Vista Física: Describe el mapeo del software en el hardware y refleja los aspectos de
distribución.
Vista de Escenario: La vista de escenarios corresponde con instancias de casos de uso que
unifican todas las vistas. Así, desde casos de uso se debiera poder hacer una trazabilidad a
todos los componentes del sistema software, viendo, por ejemplo, que máquinas, o clases,
o componentes, o .jar, o procesos, son los responsables de que el sistema cubra una cierta
funcionalidad.
Recuperación de Vista Lógica.
Diagrama de Clases.
Figura 8. Diagrama de clases (desarrollo propio)
14
3843
Recuperación de Vista de Procesos
Diagrama de Actividades
Recuperación Vista de Desarrollo
Diagrama de Componentes
Figura 9.Diagrama de Componentes
15
3844
Recuperación de Vista Física
Diagrama de Despliegue
Figura 10.Diagrama de Despliegue
Recuperación de Vista de Escenarios
Diagrama de Casos de Uso
Figura 11.Diagrama de Casos de Uso
16
3845
Conclusión.
Una vez realizada la ingeniería Inversa se puede concluir lo siguiente:
Análisis de Vista Lógica: En ésta vista, se percibe que algunos títulos que cuentan las
clases no son los adecuados para su fácil comprensión, así también, existen clases que
están demás, las cuales se pueden incorporar en una sola; en general, se considera
pertinente la simplificación del diagrama de clases. En la siguiente tabla, muestra a detalle
los ajustes que se realizarán a las clases del sistema heredado:
Clase
Operación
Justificación
TipoNuclear
Eliminar
Intervención
Actualizar
Archivos
Eliminar
Estado, Municipio,
Eliminar
Localidad
Plantel
Actualizar
Clase_periodo
Actualizar
Agrupa_Asignatura, Eliminar
Agrupa_Alumnos
Periodo
Eliminar
PlanEstudios
Reutilizar
Alumnos
Reutilizar
Usuario
Reutilizar
Asignatura
Reutilizar
Esta clase clasifica las asignaturas que se
consideran de tipo nuclear, la cual, se
consideraba como uno de los factores a
determinar el nivel de riesgo de un alumno, para
el nuevo sistema ya no se considerará como
factor determinante.
Se considera mejorar la forma de operar del
módulo de intervención con el que cuenta el
sistema heredado, de tal manera, que se pueda
dar seguimiento puntual a las intervenciones
que se les realizan a los alumnos detectados en
riesgo de abandono escolar.
Se pretende inhabilitar el uso de carga masiva
de información a través de archivos de Excel.
Las clases cuentan con información estática que
sirven como atributos de la clase subsistema y
plantel, por lo que se eliminarán las clases para
que sean incorporadas como atributos.
Se pretende incorporar la ubicación geográfica
(latitud y longitud) de los planteles, con la
finalidad, de que se incorporen resultados de
indicadores a través de mapas cartográficos.
La forma de ingresar las calificaciones e
inasistencias por parcial, va a diferir al sistema
heredado, por lo tanto, se realizarán ajustes a los
atributos y métodos de la clase, así como el
cambio de título.
Se considera innecesario tener agrupado el
número de alumnos con banderas amarillas y
rojas, ya que es un dato que no expresa
resultados para la toma de decisiones
Se considera como atributo para las clases
Unicamente, se actualizará el nombre de la
clase
17
3846
Subsistema
Reutilizar
Roles
Reutilizar
Análisis de la Vista de Procesos: Se percibe el flujo de trabajo y la comunicación con los
distintos procesos que conforma el sistema heredado.
En la actividad que dice “Procesa la información en el SIAT”, se tienen las siguientes
problemáticas:
Con base del número de quejas recibidas por los usuarios del sistema y por
experiencia propia de pruebas realizadas, el procesamiento de información es
demasiado tardado, el cual puede tardar desde media hora hasta todo un día,
dependiendo del número de usuarios que se encuentren haciendo la misma
actividad en el sistema y el volumen de información a procesar.
Para subsanar el problema, se considera pertinente lo siguiente:
-
Restructurar el proceso de captura que no implique retrabajo.
Validar la información antes de ser guardada a la base de datos
Rediseño de la estructura interna del sistema
Conseguir un servidor de mejores características, el cual se revisará a mayor
detalle en el análisis de la vista física.
Realizando una extracción de información de la Base de Datos, se puede observar,
demasiada información incongruente, caracteres raros, registros duplicados, etc,
por lo que repercute gravemente a la validez de los resultados para toma de
decisiones.
Análisis de la Vista de Desarrollo: Al momento de ingresar al código fuente del sistema
heredado, se percibe que se fue creando código y estructuras de datos conforme fueron
requeridos una vez ya implementado el sistema sin la realización de algún análisis previo
El componente que se eliminará es el de asignar nucleares, ya que, es un proceso que ya no
se va a usar para el nuevo sistema.
Análisis de la Vista Física: El sistema de alerta temprana almacena información básica
para su operación de calificaciones e inasistencias por parcial de todos los alumnos de
Educación Media Superior a nivel nacional de las Direcciones Generales de DGETI,
DGETA, DGECYTM, DGB,COLBACH y CONALEP Federal, así como históricos de los
mismos desde el ciclo escolar 2011-2012.
Tiene un nivel de concurrencia muy alto en los periodos de captura establecidos a nivel
nacional, la cual, son bimestrales.
Se pretende incorporar el seguimiento a detalle de estrategias de intervención que se les
realizarán a los alumnos detectados en riesgo de abandono escolar, así como la generación
de una variedad de reportes para la toma de decisiones.
Actualmente el servidor donde se encuentra alojado el SIAT, cuenta con las siguientes
características:
Modelo y marca: HP proliant ML350 G6
Procesador Xeon E5520 (2.26 GHz, 8MB L3 Cache, 80 W, DDR3-1066, HT,
Turbo 1/1/2/2)
4 GB (2 x 2 GB) PC3-10600R (DDR3-1333) DIMMs
18
3847
HP Smart Array P410i/256 MB Controller (1+0)
2 discos duros(160GB) SAS/SATA de 2,5
En Torre
Desventajas:
El servidor no cuenta con arreglo raid, por tanto, ante la falla de los discos duros existe el
riesgo de perder la información almacenada.
Este servidor es prestado, la cual, el sistema, comparte espacio con otra aplicación.
El servidor no rinde para el volumen de información que maneja el SIAT, provocando
fuertes problemas de eficiencia en el mismo y sobretodo en periodos de carga.
Por tal motivo, es necesaria la adquisición de un servidor propio y que cumpla con las
características necesarias para la operación óptima y eficiente del SIAT.
Solución
La Dirección General de Tecnologías de Información y Comunicaciones (DGETIC) de la
SEP e INFOTEC, empresa con la que cuenta con convenio con la SEP ofrecen las
siguientes soluciones:
Solución
Servicios
Servidor Dell PowerEdge R510
Intel 2 xeon quad core 2.40 GHZ
32 GB RAM
3 Discos Duros de 2TB cada uno
Solicitando los siguientes servicios:
RENTA
DE
UN
SERVIDOR TIPO D A
TRAVÉS
DE
LOS
SERVICIOS
ADMINISTRADOS
DE
COMPUTO (SAC) DE LA
DGTIC
SEGUNDA
OPCIÓN.
RENTA
DE
UN
SERVIDOR A INFOTEC
SERVIDOR VIRTUAL
Hospedaje(conectividad SSH, SFTP)
Servicio de Conectividad
Instalación de Ubuntu Server versión 12.10
Instalación Apache 2.2.23
MySQL Server 5.5.28
PHP 5.2.17
Postgre SQL 9.1
Acceso remoto al manejador de Base de Datos
Servicio de Respaldos
Protocolo https
Servicio de hospedaje
Servicio de procesamiento
4 vCPU, 8 GB RAM, 200 GB en Disco Duro
Sistema operativo Ubuntu server 12.10
MySQL 5.5.28
Postgre SQL 9.1
Apache 2.2.23
PHP 5.2.17
Servicio de Seguridad Perimetral Firewall
19
3848
Servicio de Seguridad Perimetral VPN (SSH,SFTP)
Acceso remoto al manejador de Base de Datos
Protocolo https
Revisando las características de las dos propuestas, se tienen las siguientes conclusiones:
-La capacidad de ambas soluciones son óptimas para el buen funcionamiento del sistema.
-La solución que se escogió es la primera, puesto que tiene mayor capacidad y pertenece a
los servicios administrados que provee la Dirección General propia de la SEP.
Análisis de la Vista de Escenario: En esta vista, se puede tener una mejor claridad a nivel
funcional, de ésta manera podemos determinar aquellas funciones que se consideran
convenientes seguir operando, así como la consideración de añadir nuevas funciones.
Se actualizará el módulo de carga, el módulo de procesamiento de información, el módulo
de intervenciones y el módulo de consulta por asignatura, carrera y grupo, el resto se
mantendrá en adición de nuevas funcionalidades..
1.1.
Restructuración de Código.
Una vez aplicada la ingeniería inversa, se realizó una restructuración de código fuente al
SIAT para su mejor comprensión y simplicidad. Se entiende por restructuración o
refactorización a la limpieza al código fuente, la cual no arregla errores, ni añade
funcionalidades. Su objetivo principal, es mejorar la facilidad de comprensión del código o
cambiar su estructura y diseño y eliminar código muerto.
La restructuración del código fuente, se realizó con el apoyo de un programador, la cual, se
corrigieron los siguientes aspectos:
Código incongruente: Se identificó código fuente de otros sistema, por lo que éstos,
fueron eliminados
Nombres sin sentido: El código fuente no cuenta con estándares de nomenclatura,
de tal manera que sea clara su interpretación.
3.5. Restructuración de Datos.
La restructuración de Datos, es un paso fundamental en el proceso de reingeniería, ya que,
el esfuerzo de la restructuración, se extiende más allá de los límites de los módulos y
abarca la arquitectura del software con la adición de nuevas funcionalidades
Con base a la ingeniería inversa realizada al sistema heredado, a continuación se presentan
nuevamente el modelo de 4+1 en su proceso de reingeniería
20
3849
Vista Lógica versión 1.0 vs 2.0
Diagrama de clases
Versión 1.0
Versión 2.0
Figura 67.Diagrama de clases. SIATv1 vs SIATv2
21
3850
3.6.
Ingeniería Directa.
La segunda fase de la metodología, denominada de ingeniería directa, se encarga de la
ejecución planificada del desarrollo, implantación y puesta en marcha de los procesos
(redefinidos y nuevos) del nuevo modelo de funcionamiento del sistema.
3.6.1. Plan de Proyecto de Ingeniería Directa.
mes
Actividades
1
Plan de actuación para el
cambio
Definición
de
nuevos
requerimientos funcionales y no
funcionales
Diseño
Plan de pruebas
Plan de Implementación
mes mes
2
3
3.6.2. Plan de actuación para el cambio
A continuación se presenta una tabla de las modificaciones que se realizaran a la
versión heredada.
Procesos
SIAT 1.0 SIAT2.0
Proceso de Captura
Cada profesor digita calificaciones e inasistencias de sus
grupos asignados
x
Seguimiento de Alumnos en Riesgo
x
Generación de alertas por parcial
X actualizada
La determinación de la alerta por parcial de una asignatura,
considera la situación escolar del alumno del parcial anterior
x
Reportes de alumnos en riesgo por alumno , asignatura y grupo x
x
Seguimiento a Intervenciones
Captura de Intervenciones a Nivel individual, grupal,
asignatura, carrera a través de la carga de archivos de cualquier
formato
x
Captura de intervenciones identificando la dimensión y al
alumno que será atendido independientemente que sea una
tutoría grupal o individual
x
Generación de reportes de seguimiento a Intervenciones a
nivel plantel, DG, Entidad Federativa y Nacional
Generación de reportes de alumnos detectados en riesgo y de
estos cuantos fueron Intervenidos
x
x
22
3851
Generación de reportes de histórico por alumno de alertas y
seguimiento a sus intervenciones independiente a los distintos
planteles que pudo haber pasado
Reportes de Indicadores Educativos
Reportes de tasa de abandono escolar, Índice de Reprobación
y Eficiencia Terminal a nivel Plantel, DG,Estado, Nacional
x
x
Figura 71.Modificaciones al SIAT 1.0
Requerimientos Funcionales.
El proyecto total está constituido por 4 grandes núcleos de información:
FR1. Proceso de Captura
FR2. Proceso de Seguimiento de Alumnos en Riesgo
FR3. Proceso de Generación de Reportes (Indicadores Educativos)
FR4. Proceso de Administración de Usuarios y Catálogos
Estos procesos, a su vez, están formados por un grupo de aplicaciones las cuales tienen
funciones muy específicas y se detallan a continuación:
FR1.Proceso de Captura
Objetivos específicos:
Mejorar el proceso de captura de información
Procurar la integridad, confidencialidad y fiabilidad de la información que
se está capturando.
Invertir muy poco tiempo de captura.
Asegurar la disponibilidad de la información en tiempo.
Procurar que el plantel capture lo menos posible de información.
Realizar el proceso de captura más sencillo.
FR1.2.Iniciación en el plantel
Antes que empiece a operar el SIAT es necesario la precarga de información básica por
periodo para su óptimo aprovechamiento.
1.2.1. Administración de Profesores y Alumnos a Nivel Plantel
El coordinador del SIAT del plantel, dará de alta a cada profesor y alumno en el sistema
vía formulario.
1.2.2. Distribución de grupos, asignaturas y docentes
El sistema deberá de dar las facilidades para que el Coordinador del SIAT del plantel,
pueda especificar grupos, asignaturas y profesores.
FR1.3.Captura de Calificaciones e Inasistencias.
La captura se realizará cada parcial cumpliendo 3 parciales y un final. Cada profesor
capturará calificaciones e inasistencias de sus alumnos.
FR2.Proceso de Seguimiento de Alumnos en Riesgo
Objetivo:
Detectar oportunamente a los alumnos en riesgo de abandono escolar
A) Criterios para generación de Alerta por Asignatura y parcial
Indicador
A - Inasistencias
Umbral crítico
Grado alerta
A1 - Mayor o igual al 10 % de unparcial
Amarilla
en cualquier periodo de evaluación
Ar - Mayor o igual al 10 % de 2 o más
Amarilla
parciales
recurrente en cualquier
23
3852
periodo de evaluación
B1 - De un parcial en cualquier periodo
Amarilla
de evaluación
Br – De 2 o más parciales recurrentes
Roja
en cualquier periodo de evaluación
B – Reprobación
B) Criterios de determinación del Nivel de Riesgo en base a calificación Final o
Parcial
Indicador
B - Reprobación
Umbral crítico
Nivel de Riesgo
B - De una materia
Bajo
B2 - En Dos materias
Medio
B3 - En tres o más materias
Alto
El sistema deberá generar reportes de Alumnos en Riesgo en 4 niveles: Plantel, Dirección
General, Estado, SEMS.
FR3.Proceso de Generación de Reportes (Indicadores Educativos)
Se requiere la generación de reportes de los siguientes indicadores educativos:
Indicador
Deserción
Fórmula
1
Mt
1
Datos
ANI t
Mt
1
AE t
x100
Mt+1
ANIt+
1
Reprobación
ARp t
x100
Mt
Eficiencia
Terminal
AECo t
x100
ANI t
Matrícula de inicio en el ciclo escolar
t+1
Matrícula de nuevo ingreso a primer
semestre en el ciclo escolar t+1
AEt
Número de alumnos que egresaron en
el ciclo escolar t
Mt
AAPt
Mt
Matrícula de inicio en el ciclo escolar t
Alumnos reprobados
en el ciclo
escolar t.
Matrícula de inicio en el ciclo escolar t
Número de alumnos que egresaron de
la misma generación en el ciclo
escolar t.
AECo
t
ANItm
Matrícula de nuevo ingreso al plantel
en el ciclo escolar (t-m)
m
Número de años del tiempo ideal
establecido menos uno (- 1).
Los indicadores se deberán de presentar en los siguientes niveles:
24
3853
Plan de Ejecución de Pruebas
Según la IEEE standars(2013) define a las pruebas como “el proceso de analizar un
producto de software para detectar las diferencias entre el comportamiento real con el
pedido, y para evaluar las funcionalidades y características no funcionales del software”
En este apartado se presenta una perspectiva general de la estrategia que se va a seguir para
analizar, diseñar, implementar y ejecutar las pruebas del proyecto. Así mismo se definirá
qué tipos de pruebas se van a realizar y cómo se ejecutarán.
Plan de Proyecto.
Mes
Actividad
1
Mes 2 Mes 3 Mes 4 Mes 5
Pruebas Funcionales
Elaboración de casos de prueba
Ejecución de pruebas
Generación de reporte de
conclusión de pruebas
Pruebas de Aceptación
Elaboración de casos de prueba
Solicitud y selección de usuarios
finales que realizarán las pruebas
Ejecución de pruebas
Generación de reporte de
Pruebas Funcionales
La prueba funcional es un proceso para procurar encontrar discrepancias entre el software
desarrollado y la especificación funcional. Esta prueba permite validar:
Los procesos y reglas de negocio establecidas,
Que se cumplan los requerimientos funcionales establecidos
El objetivo de las pruebas de aceptación es validar que la solución desarrollada cumpla con
el funcionamiento esperado y permitir al usuario de dicho sistema determine su aceptación,
desde el punto de vista de su funcionalidad y de su rendimiento. Estas pruebas son
realizadas por el cliente o usuario final, donde comprueba que el sistema cumple con lo
definido.
Técnicas de Ejecución de las Pruebas
TIPO
DE
TECNICA DE EJECUCIÓN
PRUEBAS
Pruebas
Las pruebas funcionales
involucra los
Funcionales
siguientes pasos:
a. Crear los casos de prueba mediante el
formato establecido para ellos.
b. Ejecución de los casos de prueba con
forme las funcionalidades van siendo
liberadas para pruebas.
25
3854
TIPO
PRUEBAS
Pruebas
Aceptación
DE
TECNICA DE EJECUCIÓN
c. Reporte de los defectos encontrados
según las pruebas.
d. Asignación de la incidencia.
e. Corrección de la incidencia.
f. Repetición de la prueba.
g. Al finalizar generar un reporte de
de Las pruebas de aceptación involucra los
siguientes pasos:
a. Crear los casos de prueba mediante el
formato establecido para ellos.
b. Asignar una muestra de usuarios
finales para la etapa de pruebas.
c. Reporte de los defectos encontrados
según las pruebas.
d. Asignación de la incidencia
e. Corrección de la incidencia.
f. Repetición de la prueba.
g. Al finalizar, generar un reporte de
Recursos Humanos
Para la ejecución de las pruebas, se dispondrá de los siguientes perfiles.
Tipo de Pruebas
Perfil de Recursos Humanos
Pruebas Funcionales
a)Analista de Pruebas
a)Analista
de
Pruebas
b) Usuario Final.
Se elegirá a un plantel por subsistema
de la Subsecretaria de Educación
Media Superior y un plantel por
subsistema de la Educación Media
Superior del Gobierno de los Estados.
-Un
representante
por
cada
subsistema para las pruebas de
usuario administrador
Procedimiento de atención y control de incidentes para las pruebas de Aceptación.
1. Cuando se presente un incidente de plantel, DG o Estado, éste deberá de ser
reportado vía correo electrónico
Con la finalidad de poder dar un mejor control de seguimiento en el asunto del
correo indicar lo siguiente:
Nivel
Incidente Reportado de Plantel
Asunto
Asunto + DG perteneciente + nombre corto
de plantel
26
3855
Incidente Reportado de DG
Asunto + DG perteneciente+ en caso que
sea un subsistema estatal añadir el Estado
2. A continuación se le dará atención, registro de incidente y seguimiento hasta su
solución del mismo dando respuesta al usuario.
Plan de Implementación.
Una vez finalizando la etapa de pruebas, se procede a la implementación nacional del
SIAT 2.0 considerando las siguientes actividades:
Actividad
Mes 1 Mes 2 Mes 3
Elaboración de manual de usuario y videotutorial
Migración del SIAT 2.0 del servidor de pruebas al servidor
de producción
Alta de catálogos básicos para el funcionamiento del SIAT
Migración de información ya depurada del SIAT de la
versión heredada
Generación de plan de capacitación para uso del SIAT
Generación de claves de acceso
Determinación del esquema de trabajo para el seguimiento
de la operación de la nueva versión del SIAT
A continuación se explica a detalle cada actividad:
Elaboración de manual de usuario y videotutorial: Sirve como instrumento de apoyo
dónde, contiene la información necesaria para que los usuarios utilicen correctamente la
aplicación
El usuario lo podrá localizar en el apartado de ayuda en el sistema, en formato pdf, así
también, podrá encontrar un videotutorial del mismo , a fin de que utilice el que mejor se
acomode a sus necesidades.
Migración del SIAT 2.0 del servidor de pruebas al servidor de producción: Actualmente, el
SIAT se encuentra en un servidor de prueba. En la etapa de implementación nacional, el
sistema, se pasará al servidor considerado de producción, el cual, cuenta con la capacidad
necesaria, para dar soporte al volumen de información que se manejará.
Alta de catálogos básicos para el funcionamiento del SIAT: El sistema debe de contar con
la precarga de los siguientes catálogos:
-Catálogo de subsistemas
-Catálogo de planteles.
-Catálogo de Entidad Federativa, municipio y localidad, deacuerdo a las claves que utiliza
INEGI.
-Catálogos de Oferta Educativa de todos los subsistemas del Nivel Medio Superior.
-Catálogo de Directores por plantel
Migración de información ya depurada del SIAT de la versión heredada: Se considera
adecuar la información que cuenta el SIAT 1.O a la nueva Base de Datos del SIAT 2.0,
con el fin, que el usuario pueda seguir contando con su información ya trabajada de
periodos anteriores.
Generación de plan de capacitación para uso del SIAT: Con el fin de que el manejo del
sistema sea correcto, aceptado y su uso sea para los fines con que fue realizado, es
27
3856
necesario realizar un programa de capacitación nacional, dónde se tengan reuniones por
regiones y todos los usuarios tengan el pleno conocimiento de la herramienta.
Generación de claves de acceso: Se solicitarán los datos de los directores y de los usuarios
que se encargarán de la administración del programa de cada plantel, para así, darlos de
alta en el sistema y entregar sus claves de acceso vía correo electrónico.
Determinación del esquema de trabajo para el seguimiento de la operación de la nueva
versión del SIAT: Para poder dar seguimiento a la correcta operación del sistema a nivel
nacional, es necesario la elaboración de un plan de trabajo, dónde se especifique las
diferentes tareas a realizar, el equipo de colaboradores necesarios, así como la
especificación de periodos de cortes de estatus de información, con la finalidad de verificar
el cumplimiento de los objetivos del programa.
Para la ejecución del plan de implementación, se consideran los siguientes recursos como
mínimo:
Recursos Humanos
Perfil
1 Diseñador Gráfico
Actividades
Diseño editorial de manual de usuario en formato
pdf e impreso.
Elaboración de videoturorial
Diseño Editorial de documentación del programa
1 Administrador de Bases de Datos -Depuración de la Base de datos del sistema
heredado.
-Migración de la Base de Datos depurada del sistema
heredado al SIAT 2.0.
-Administración de la Base de Datos del SIAT 2.0
1 Programador
Administración a nivel técnico del sistema.
Migrar el sistema del servidor de pruebas al servidor
de producción
1 Responsable del SIAT por cada Asegurar el buen funcionamiento del SIAT de los
Dirección General
planteles de su Dirección General.
Dar seguimiento a cualquier inquietud que presente
el usuario de cada plantel
1 Responsable del SIAT Nacional
-Elaboración del plan de operación nacional del
SIAT
-Gestión de operación del sistema a nivel nacional
Personal de apoyo para la -Gestión y coordinación de los eventos de
capacitación del sistema
capacitación del sistema
-Ejecución de la capacitación del sistema
Infraestructura
Servidor de Producción
Características
Servidor Dell PowerEdge R510
Intel 2 xeon quad core 2.40 GHZ
SERVIDOR TIPO D A TRAVÉS DE LOS
32 GB RAM
SERVICIOS
ADMINISTRADOS
DE
3 Discos Duros de 2TB cada uno
COMPUTO (SAC) DE LA DGTIC
28
3857
Solicitando los siguientes servicios:
Hospedaje(conectividad
SSH,
SFTP)
Instalación de
Ubuntu Server
versión 12.10
Instalación Apache 2.2.23
MySQL Server 5.5.28
PHP 5.2.17
Postgre SQL 9.1
Acceso remoto al manejador de
Base de Datos
Protocolo https
Conclusiones
La reingeniería del software ofrece una disciplina de preparación para migrar un sistema de
información heredado hacia un sistema capaz de evolucionar, ya que tiene el potencial de
mejorar la productividad y calidad del software a través de todo el ciclo de vida.
En este orden de ideas, se decidió aplicar el proceso de reingeniería al Sistema de Alerta
Temprana (SIAT), ya que, es una herramienta con mucho potencial, la cual no se ha
podido aprovechar puesto que la versión heredada contaba con fuertes problemas de
eficiencia, así también, la necesidad de la inclusión de nuevos módulos.
Con éste proceso de reingeniería, se lograron detectar las causas de las diversas fallas que
contaba el sistema heredado, realizando un rediseño en su arquitectura, para la
simplificación del código, así como la inclusión de nuevos módulos y mejora de los que ya
contaba.
Como parte de las etapas de reingeniería de software, el trabajo terminal de grado dispone
de la realización de un análisis y rediseño profundo al sistema, ya que es una actividad
importante que no debe llevarse a cabo de forma descuidada, ya que, de esta fase, depende
fundamentalmente el éxito o fracaso del nuevo sistema. Considero, que se logró de manera
satisfactoria, ya que se cumplieron los objetivos planteados, teniendo como producto final
una propuesta robusta y confiable, ahora bien, la siguiente etapa le corresponde a su
desarrollo, pruebas e implementación y con ello, la conclusión de la reingeniería del
Sistema de Alerta Temprana.
29
3858
Bibliografía
B.B, Agarwal.(2010).”Software Engineering & Testing”.USA:Tyler Creative
Caballero, Ismael y Calero,Coral.(2009).”Introducción a la Calidad. Modelos de
Calidad ISO 9126”. Alarcos
CEPAL (2010). “Transferencias públicas en etapas tempranas del ciclo vital: un
desafío para el combate intertemporal a la desigualdad, en Panorama Social de
América Latina 2010.” Recuperado el 31 de agosto de 2013, de
http://www.eclac.cl/publicaciones/xml/9/41799/PSE2010-Cap-V-transferenciaspreliminar.pdf
Clements,P y Northrop, L.(2007).”Software Product Lines: Practice and Patters”.
USA:Addison Wesley Longman Inc.
COSDAC.(2012)”Siguele,caminemos juntos.Acompañamiento integral para
jóvenes de la Educación Media Superior”
Cuatrecasas, Arbós. Lluís.(2012)Organización de la producción y dirección de
operaciones: Sistemas actuales de gestión eficiente y competitiva. Madrid:Díaz de
Santos
De los Santos, Ignacio Soret.(2008).Modelo de medición de conocimiento y
generación de ventajas competitivas sostenidas en el ámbito de la iniciativa
“Respuesta eficiente al consumidor”.Madrid:ESIC
FLACSO.Facultad Latinoamericana de Ciencias Sociales. (2010). “Modelo Integral
para la Atención y Acompañamiento de Adolescentes y Jóvenes en la Educación
Media Superior. Documento de investigación Interno “.México
IEEE Standars Associations.(2013). Standard for Testing.Recuperado de
http://standards.ieee.org/develop/project/1450.4.html
Instituto de Ingeniería de software.(2013). “Architecting in a complexworld”. USA
INEE. Instituto Nacional para la Evaluación de la Educación (2011). “La
Educación Media Superior en México”.México
Microsoft.(2013).¿Qué es un unit test?. http://msdn.microsoft.com/eses/library/jj130731.aspx.
o OECD (2011).Education at Glance. Recuperado el 31 de agosto de 2013, de
http://www.oecd.org/dataoecd/61/2/48631582.pdf
P. Sage, Andrew y B.Rouse,William. (2009).”Handbook of systems engineering
and management”.NewYersey:Wiley
Pindado,Julio y Payne, Gregory(2008)Estableciendo puentes en una economía
global. Madrid:ESIC
Scrum
Manager.(2013).
Pruebas
de
Integración.
http://www.scrummanager.net/bok/index.php?title=Pruebas_de_integraci%C3%B3
n
SEMS.(2012).”Lineamientos de Operación del SIAT”.México
SEMS & COPEEMS.(2012).”Reporte de la Encuesta Nacional de Deserción en la
Educación Media Superior”. México
Sommerville,Ian. (2012). “Software Engineering 3: Domains, Requirements, and
Software Design”.Alemania:Springer
Streekmann, Niels.(2012).”Clustering-Based Support for Software Architecture
Restructuring”.Alemania:Vieweg + Teubner.
SEMS.(2013). Historia. Recuperado de http://www.sems.gob.mx/es/sems/historia
30
3859

Introducción Con el objetivo de disminuir la deserción

Transcripción

Documentos relacionados

¿Fracaso la reingeniería? - Centro de Liderazgo y Gestión

Descargar el archivo PDF

el modelo de gestión de la calidad total