Embed Size (px)
Citation preview
SISTEMA AUTOMATIZADO PARA EL CONTROL Y GENERACIÓN DE REPORTE DE DETECCIÓN DE OBRAS PÚBLICAS Y PRIVADAS, PARA LA
REGULARIZACIÓN DEL SERVICIO DE AFILIACION DE OBRAS EN LA CIUDAD DE OAXACA
MAYO DE 2016 UNIVERSIDAD AUTÓNOMA “BENITO JUÁREZ” DE OAXACA
JESÚS SANJUAN MENDEZ
LICENCIATURA EN COMPUTACIÓN
i
Tabla de Contenidos
Introducción .................................................................................................................................................. 1
Capítulo I Marco teórico ............................................................................................................................... 3
Metodología utilizada ................................................................................................................... 3
Capítulo II Exploración general del sistema .................................................................................................. 6
Descripción del problema ............................................................................................................. 6
Objetivo general ............................................................................................................................ 9
Objetivos específicos .................................................................................................................... 9
Justificación ................................................................................................................................. 10
Tecnologías a utilizar ................................................................................................................... 12
Definición de historias de usuario del sistema ........................................................................... 14
Planificación de entrega .............................................................................................................. 16
Duración de cada iteración y posibles historias de usuario de cada iteración ........................... 16
2.8.1. Historias de usuario por iteración ....................................................................................... 16
2.8.2. Duración por iteración ........................................................................................................ 16
Capítulo III Iteraciones del sistema ............................................................................................................. 17
Primera iteración ........................................................................................................................ 17
3.1.1. Exploración .......................................................................................................................... 17
3.1.1.1. Historias de usuario que se utilizarán en esta primera iteración ............................... 17
3.1.2. Planeación ........................................................................................................................... 17
3.1.2.1. Selección de historias de usuario ................................................................................ 17
3.1.3. Diseño ................................................................................................................................. 18
3.1.3.1. Historia de usuario: Usuarios ...................................................................................... 18
3.1.3.2. Historia de usuario: Municipio .................................................................................... 27
3.1.3.3. Historia de usuario: Patrón ......................................................................................... 35
3.1.4. Codificación ......................................................................................................................... 41
3.1.4.1. Usuarios ...................................................................................................................... 41
3.1.4.2. Municipio .................................................................................................................... 42
3.1.4.3. Patrón .......................................................................................................................... 44
3.1.5. Pruebas ............................................................................................................................... 46
Segunda iteración ....................................................................................................................... 47
3.2.1. Exploración .......................................................................................................................... 47
ii
dewe5
3.2.1.1. Historias de usuario que se utilizarán en esta segunda iteración ............................... 47
3.2.1.2. Tecnología a utilizar en esta iteración ........................................................................ 47
3.2.2. Planeación ........................................................................................................................... 48
3.2.2.1. Selección de historias de usuario ................................................................................ 48
3.2.3. Diseño ................................................................................................................................. 49
3.2.3.1. Historia de usuario: Detección de obras ..................................................................... 49
3.2.3.2. Historia de usuario: Alertas ......................................................................................... 63
3.2.4. Codificación ......................................................................................................................... 71
3.2.4.1. Detección de obra ....................................................................................................... 71
3.2.4.2. Alertas ......................................................................................................................... 73
3.2.5. Pruebas ............................................................................................................................... 74
Tercera iteración ......................................................................................................................... 75
3.3.1. Exploración .......................................................................................................................... 75
3.3.1.1. Historias de usuario que se utilizarán en esta tercera iteración................................. 75
3.3.1.2. Tecnología a utilizar en esta iteración ........................................................................ 75
3.3.2. Planeación ........................................................................................................................... 75
3.3.2.1. Selección de historias de usuario ................................................................................ 75
3.3.3. Diseño ................................................................................................................................. 76
3.3.3.1. Historia de usuario: Reportes ..................................................................................... 76
3.3.4. Codificación ......................................................................................................................... 83
3.3.4.1. Reportes ...................................................................................................................... 83
3.3.5. Pruebas ............................................................................................................................... 85
Capítulo IV Resultados ................................................................................................................................ 86
4.1. Diagramas de base de datos ....................................................................................................... 87
4.2. Integración del sistema ............................................................................................................... 89
4.3. Entrega final ................................................................................................................................ 90
4.4. Conclusiones ............................................................................................................................... 91
4.5. Recomendaciones ....................................................................................................................... 93
4.5.1. Requisitos de instalación del sistema ................................................................................. 93
4.5.2. Requisitos para el acceso al sistema desde el navegador web ........................................... 94
4.6. Proyectos futuros ........................................................................................................................ 95
Lista bibliográfica ........................................................................................................................................ 96
iii
Lista de Tablas
Tabla 1. Planificación de historias de usuario del sistema. ......................................................................... 15
Tabla 2. Distribución de historias de usuario en cada iteración. ................................................................ 16
Tabla 3. Planificación de duración de cada iteración.................................................................................. 16
Tabla 4. Tiempo estimado de cada historia de usuario de la primera iteración. ....................................... 17
Tabla 5. Tiempo estimado de cada historia de usuario de la segunda iteración. ....................................... 47
Tabla 6. Tiempo estimado de la última historia de usuario de la tercera iteración. .................................. 75
iv
Lista de Figuras
Figura 1. Estructura de tabla SQL nombrada “usuarios” ............................................................................ 19
Figura 2. Código SQL de tabla “usuarios”. .................................................................................................. 19
Figura 3. Estructura de tabla SQL nombrada “tipousuario”. ...................................................................... 19
Figura 4. Código SQL de tabla “tipousuarios”. ............................................................................................ 19
Figura 5. Estructura de tabla SQL nombrada “profesiones”. ...................................................................... 19
Figura 6. Código SQL de tabla “profesiones”. ............................................................................................. 19
Figura 7. Prototipo de alta de usuarios. ...................................................................................................... 20
Figura 8. Prototipo de consulta de usuarios. .............................................................................................. 21
Figura 9. Prototipo de baja de usuarios. ..................................................................................................... 22
Figura 10. Prototipo de modificación de datos de usuarios. ...................................................................... 23
Figura 11. Estructura de tabla SQL nombrada “colonia”. ........................................................................... 28
Figura 12. Código SQL de tabla “colonia”. ................................................................................................. 28
Figura 13. Estructura de tabla SQL nombrada “municipios_delegaciones”. .............................................. 28
Figura 14. Código SQL de tabla “municipios_delegaciones”. .................................................................... 28
Figura 15. Prototipo de alta de municipios, con sus respectivas colonias y códigos postales. .................. 29
Figura 16. Prototipo de consulta de municipios. ........................................................................................ 30
Figura 17. Prototipo de modificación y eliminación de municipio con sus respectivas colonias. .............. 31
Figura 18. Estructura de tabla SQL nombrada “patron”. ............................................................................ 36
Figura 19. Código SQL de tabla “patron”. .................................................................................................. 36
Figura 20. Prototipo para el alta, consulta y modificación de los registros patronales. ............................ 37
Figura 21. Estructura de tabla SQL nombrada “control”. ........................................................................... 50
Figura 22. Código SQL de tabla “control”. .................................................................................................. 51
Figura 23. Estructura de tabla SQL nombrada “contratista_subcontratista”. ............................................ 51
Figura 24. Código SQL de tabla “contratista_subcontratista”. ................................................................... 51
Figura 25. Estructura de tabla SQL nombrada “tipoobra”. ......................................................................... 52
Figura 26. Código SQL de tabla “tipoobra”. ................................................................................................ 52
Figura 27. Estructura de tabla SQL nombrada “privacidad”. ...................................................................... 52
Figura 28. Código SQL de tabla “privacidad” ............................................................................................. 52
Figura 29. Estructura de tabla SQL nombrada “fase”. ................................................................................ 52
Figura 30. Código SQL de tabla “fase”. ....................................................................................................... 52
v
dewe5
Figura 31. Estructura de tabla SQL nombrada “situación”. ........................................................................ 53
Figura 32. Código SQL de tabla “situación”. ............................................................................................... 53
Figura 33. Estructura de tabla SQL nombrada “origen_fuente”. ................................................................ 53
Figura 34. Código SQL de tabla “origen_fuente”. ....................................................................................... 53
Figura 35. Prototipo de alta de detección de obras. .................................................................................. 54
Figura 36. Prototipo de consulta de detección de obra en sesión visitador. ............................................. 55
Figura 37. Prototipo de consulta de detección de obra en sesión supervisor. ........................................... 56
Figura 38. Prototipo de modificación de detección de obra. ..................................................................... 57
Figura 39. Estructura de tabla SQL nombrada “alertas”. ............................................................................ 63
Figura 40. Código SQL de la tabla “alertas”. ............................................................................................... 64
Figura 41. Prototipo de consulta de alertas para visitadores. .................................................................... 64
Figura 42. Prototipo de consulta de alertas para supervisores. ................................................................. 65
Figura 43. Prototipo de modificación de alertas......................................................................................... 66
Figura 44. Prototipo de reporte para visitadores. ..................................................................................... 78
Figura 45. Prototipo de reporte para supervisor. ...................................................................................... 79
Figura 46. Ejemplo de opción de exportación de información a Excel. ...................................................... 80
Figura 47. Modelo entidad-relación del sistema. ....................................................................................... 86
Figura 48. Base de datos del sistema. ......................................................................................................... 87
Figura 49. Modelo relacional del sistema ................................................................................................... 88
vi
vii
Resumen
El departamento de auditoría de patrones es el encargado de llevar un control de las
obras que se efectúa en el ciudad de Oaxaca, al realizar este control, los trabajadores del
departamento se encargan de detectar las obras, las cuales deben estar registradas ante el
Instituto Mexicano del Seguro Social (IMSS), después de tener un control de las detecciones de
las obras también se comprueba que los obreros se encuentren asegurados ante el IMSS, ya
que de esta manera se protege al obrero por cualquier percance que llegara a tener en la
ejecución de su trabajo, logrando también evitar sancionar al patrón por no cumplir con su
obligación.
El objetivo por el cual se realiza este sistema, es por la necesidad de mejorar el control
de la información de las detecciones de obra, esto ha sido posible mediante el diseño de una
plataforma web, que permite administrar la información de las obras públicas y privadas de la
ciudad de Oaxaca.
Las metodologías ágiles, en particular la Programación Extrema, siendo la más conocida
y ampliamente usada, ya que otorga mayor valor al individuo, a la colaboración con el cliente y
al desarrollo incremental del software con iteraciones muy cortas. El enfoque que dispone esta
metodología muestra efectividad en proyectos con requisitos muy cambiantes, y proporciona una
reducción drástica a los tiempos de desarrollo, pero manteniendo una alta calidad. Siendo estas
las razones del uso de esta metodología para el desarrollo de este proyecto.
Al aplicar la metodología XP para el desarrollo de este sistema, ha sido posible organizar
los requerimientos para trabajar en las distintas iteraciones que se establecieron, de igual manera
ha permitido tener una menor taza de errores lo cual proporciona al programador una gran
satisfacción, esta reducción de errores es posible mediante un conjunto de pruebas continuas
que propone la metodología, las cuales se realizaron durante el desarrollo del proyecto.
Al fomentar la comunicación entre el cliente y desarrollador, lo cual promueve esta
metodología, ha sido posible realizar con facilidad los cambios que solicitó el cliente mediante
esta interacción, lo que también ha concedido ahorrar tiempo y dinero. La metodología XP
también permitió en este proyecto ocupar cualquier lenguaje de programación por la flexibilidad
que ofrece, por ende, puede ser utilizado en la implementación de nuevas tecnologías, lo cual se
promueve en el desarrollo de este proyecto.
viii
dewe5
En cuanto al lenguaje de programación que se usa para el desarrollo es PHP, este
lenguaje es usado para programar páginas de contenido dinámico, tiene su funcionamiento
principalmente del lado del servidor. Entre las ventajas que ofrece este lenguaje es la realización
de algunas acciones que no se pueden ejecutar en páginas estáticas, como por ejemplo: recoger
datos del usuario, trabajar con base de datos, crear sesiones de usuarios, restringir páginas con
contraseña, etc. Estas acciones que permite realizar el lenguaje PHP son muy necesarias para
el desarrollo de este proyecto.
Entre las tecnologías más utilizadas en el proyecto se encuentra jQuery y Ajax. jQuery es
una biblioteca que tiene como función la navegación y manipulación proporcionada del Modelo
de Objetos del Documento (DOM), mientras Ajax se encarga de la transmisión de datos entre el
navegador y el servidor. El funcionamiento que otorga estas tecnologías fue de gran apoyo para
las diversas funciones, debido a que permiten un manejo más dinámico y ágil en el sistema.
Al concluir con el desarrollo del proyecto, se ha logrado agilizar el proceso de
regularización de obras, esto se ha conseguido mediante la generación automática de reportes
y con ayuda del módulo de alertas. El sistema también ofrece diversas ventajas con las que se
evita el ingreso de información incorrecta o faltante, lo cual contribuye a la agilización de este
trámite, esto es posible mediante el formulario de altas de detección de obras debido a que valida
cada campo y dato ingresado, así mismo, se ha logrado conseguir una mayor eficiencia para el
registro de obras y trabajadores ante el instituto, mediante el uso de reportes digitales, ya que
esta es la razón más importante por la cual se desarrolló este sistema.
1
dewe5
Introducción
El presente proyecto se redacta con carácter de fin de carrera, para obtener el título de
Licenciado en Computación, mediante el desarrollo del “Sistema automatizado para el control y
generación de reporte de detección de obras públicas y privadas, para la regularización del
servicio de afiliación de obras en la ciudad de Oaxaca”.
Este proyecto llega a ser una iniciativa para proponer un mayor uso de las TIC
(Tecnologías de la Información y la Comunicación), puesto que en la actualidad ofrece una
diversidad de herramientas para facilitar las tareas administrativas que son muy necesarias en
una institución gubernamental, esto es de suma importancia en el departamento de auditoría de
patrones, dado que se perciben desventajas en la gestión de información y regularización del
servicio de detección de obras que ofrece la institución.
El departamento de auditoría de patrones, es el encargado de verificar que las obras que
se realizan en la ciudad de Oaxaca se encuentren afiliadas ante el IMSS, y que cumplan entre
otros lineamientos más que establece su reglamento, en el caso de no encontrarse afiliados, se
le exhorta al patrón que afilie la obra y a sus trabajadores al instituto, debido a que podría ser
acreedor de sanciones por falta de cumplimiento a la obligación que tiene como patrón.
Uno de los intereses que nos lleva realizar este trabajo, es el crecimiento
desproporcionado de personas que no se encuentran aseguradas en las obras, ya que día a día
surge la necesidad de requerir más mano de obra para la construcción, esto surge por no tener
un buen control de la información de las detecciones de obra, ya que si se contara con un sistema
que gestión y genere los diversos reportes de detección de obras públicas o privas será posible
agilizar el trámite de afiliación a trabajadores, por consiguiente, se conseguirá cuidar el bienestar
del trabajador.
Este software, se desarrolla con el propósito de mejorar la manera en que se controla y
genera los diversos reportes de detección de obras para el proceso de regularización de obras
de la ciudad de Oaxaca, esto se logrará mediante la elaboración de un conjunto de herramientas,
que apoyen al trabajador del departamento de auditoría de patrones de la subdelegación del
IMSS Oaxaca, el software incluye diversas funcionalidades entre las cuales destacan, recabar
toda la información de las obras mediante un formulario digital, lo cual permitirá la creación de
2
dewe5
diversos reportes automatizados, y también, lograr obtener un control exacto de las detecciones
de obra, al cual se le incluye un control de alertas para la información que se llegue a rezagar.
El desarrollo de este trabajo se divide en 4 capítulos: Marco Teórico, Exploración del
Sistema, Iteraciones del Sistema y Resultados.
Capítulo I Marco Teórico, Se da la explicación de la metodología XP que se ocupó para
el desarrollo de este trabajo, en el cual se definen las ventajas, características y razones por la
que se usa la metodología XP en este proyecto.
Capítulo II Exploración General del Sistema, se describe la problemática que existe en el
departamento de auditoría, los objetivos que se determinaron para el desarrollo de este proyecto,
la razón por la que se desarrolla, descripción de las tecnologías que se usan en el proyecto y la
forma en la que se planifica para la entrega final.
Capítulo III Iteraciones del Sistema, en este capítulo se presenta la exploración,
planeación, diseño, codificación y pruebas de los distintos módulos que se irán realizando en las
tres iteraciones que se establecieron para el desarrollo del sistema.
Capítulo IV Resultados, se exponen los resultados obtenidos por el sistema, como fue la
entrega final al cliente del sistema y las conclusiones a las que se llegó al desarrollar este
sistema, así mismo los proyectos futuros que se podrían llegar a realizar a partir de este proyecto.
3
dewe5
Capítulo I Marco teórico
Metodología utilizada
La programación extrema es quizás el método ágil mejor conocido y más ampliamente
usado, dado que es adaptable al desarrollo de sistemas pequeños y grandes, de igual manera
toma un enfoque “extremo” para el desarrollo incremental y tiene como objetivo el proceso ágil
para ser usado específicamente en organizaciones grandes. El desarrollo incremental que ofrece
la metodología XP se apoya en pequeñas y frecuentes liberaciones del sistema. De esta manera,
los clientes intervienen estrechamente en la especificación y priorización de los requerimientos
del sistema que se entreguen en cada iteración, siendo esta metodología adaptable a los
cambios, por el enlace continuo que se puede lograr entre el cliente y el equipo de desarrollo.
XP es aplicable en equipos con muy pocos programadores, los cual conlleva muy pocos
procesos en paralelo, al requerir de un grupo pequeño de programadores para trabajar ya sea
entre 2-15 personas, el cual puede ir incrementándose conforme sea necesario. Hay que tener
en cuenta que en el desarrollo de este trabajo será realizado por un solo programador, lo que no
quiere decir, que no sea posible aplicar esta metodología, ya que únicamente llegaría a darse el
caso de no poder aplicar ciertas prácticas de la metodología como por ejemplo la programación
en pares, en cuanto a las demás características que ofrece la metodología son posibles de
realizar únicamente por un programador.
Una particularidad de esta metodología son las pruebas unitarias, las cuales se realizan
en los principales procesos del proyecto, es como si nos adelantáramos a obtener los posibles
errores, de esta forma con estas pruebas nos adelantemos en algo hacia el futuro, y así podamos
realizar más pruebas de las fallas que podrían llegar a ocurrir.
El desarrollo ágil de software, es un conjunto de principios para el perfeccionamiento de
software, en el que las necesidades y soluciones evolucionan a través de la colaboración entre
la auto-organización y equipos multi-funcionales. Los cuales promueven la planificación
adaptativa, desarrollo evolutivo y la mejora continua, ya que se adecua a una respuesta rápida y
flexible para los cambios.
El manifiesto ágil se basa en doce principios (“El manifiesto ágil- Scrum Manager BoK, 2016”):
1. La satisfacción del cliente basado en una entrega temprana y continua de software de
valor.
4
dewe5
2. Bienvenido requisitos cambiantes, e incluso en el desarrollo tardío.
3. Entregar software funcional con frecuencia, en periodos de semanas lugar de meses.
4. La estrecha cooperación de forma cotidiana, la gente de negocios y desarrolladores
deben de trabajar juntos para el buen desarrollo del proyecto.
5. Los proyectos se construyen en torno a individuos motivados, dando la oportunidad y
respaldo que lleguen a necesitar.
6. La forma más eficiente y efectiva de comunicar información de ida y vuelta dentro de un
equipo de desarrollo es mediante la conversación cara a cara.
7. Software que funciona es la principal medida del progreso.
8. Los procesos ágiles promueven el desarrollo sostenido, los patrocinadores,
desarrolladores y usuarios deben mantener un ritmo constante de forma indefinida.
9. La atención continua a la excelencia técnica enaltece la agilidad.
10. La simplicidad como arte de maximizar la cantidad de trabajo que no se hace, es esencial.
11. Las mejores arquitecturas, requisitos y diseños emergen de equipos que se auto-
organizan.
12. En intervalos regulares, el equipo reflexiona sobre la forma de ser más efectivo y ajusta
su conducta en consecuencia.
Tomando en cuenta los siguientes principios en los que se basa el manifiesto ágil, se
percata que son sumamente adecuados para aplicar en el desarrollo de este proyecto, siendo
esta la razón por la que se utilizó la metodología ágil conocida como programación extrema (XP).
De igual manera en este trabajo se utiliza Scrum, el cual permite abarcar principalmente
las prácticas de gestión, planificación y seguimiento de proyecto, con prácticas orientadas a la
gestión de equipos, tareas y funcionalidades etc., lo cual permite organizar el equipo de trabajo
y en general el tiempo en que se llevará a cabo un buen proyecto, sin entrar en las prácticas de
desarrollo como puede hacer XP. Scrum tiene sus raíces teóricas en la auto-organización,
igualmente se basa en las entregas parciales y regulares del proyecto final, estas entregas
pueden llegar a ser mensualmente o quincenales, dado que los requerimientos se priorizan por
el beneficio que aportara al receptor del proyecto. Por ello, Scrum está especialmente indicado
para proyectos en entornos complejos, en donde es necesario obtener resultados lo antes
posible, donde los requisitos son cambiantes o pocos definidos, donde la innovación, la
competitividad, la flexibilidad y la productividad son fundamentales en el proyecto que se realiza.
En conclusión, el manejo en conjunto entre Scrum y Programación Extrema es funcional,
ya que Scrum se enfoca principalmente en las prácticas de organización y gestión, mientras que
5
dewe5
XP se centra más en la práctica de la programación, siendo adecuado en particular para este
sistema por las posibilidades que da para adaptarse de forma inmediata a los cambios y optimizar
el tiempo de desarrollo, con la posibilidad de reducir a bajos costos los cambio que sean
necesarios a realizar en todas las etapas del ciclo de vida del sistema, por estas razones
desempeñan un muy buen trabajo juntas, porque tratan de áreas diferentes y se complementan
entre sí.
6
dewe5
Capítulo II Exploración general del sistema
Descripción del problema
Nombre del propietario: Departamento Auditoría de Patrones de la Subdelegación del IMSS.
Empresa: Instituto Mexicano del Seguro Social.
Nombre del Sistema: “Sistema automatizado para el control y generación de reporte de detección
de obras públicas y privadas, para la regularización del servicio de afiliación de obras en la ciudad
de Oaxaca”.
El departamento de auditoría de patrones, es el encargado de supervisar que los patrones
de obras cumplan con el debido registro de las obras en construcción, y demás obligaciones que
establece el reglamento del seguro social, ya que este proceso es obligatorio para proteger el
bienestar de los trabajadores de la construcción, aun cuando estén trabajando por un tiempo
determinado o por obra. También se encargan de orientar a los patrones sobre el proceso de
afiliación de obra, corrección patronal o fiscal, en términos de las disposiciones legales
aplicables.
Existen empresas que contratan personal para la construcción pública y privada en el
municipio de Oaxaca de Juárez, por lo que el departamento de Auditoría a Patrones de la
Subdelegación del Instituto Mexicano del Seguro Social, se encarga del control de obras públicas
y privadas que se realizan en la ciudad mediante el personal denominado “visitadores”, los cuales
recorren calle por calle las colonias del municipio de Oaxaca de Juárez, realizando promoción y
detección de construcciones privadas y públicas. Al encontrar construcciones, recopilan sus
datos, tales como colonia, calle y número de localización, el nombre del propietario o empresa
constructora y cuantos trabajadores tiene dicha construcción, entre otros datos, así mismo se
aseguran que los trabajadores estén dados de alta ante el IMSS.
Después de ello, se encargan de invitar a los patrones de obra para que acudan a la
subdelegación, y puedan recibir orientación para que presente el aviso de registro de obra y dar
su alta patronal en el caso de no estar dado de alta, para que a su vez también incorporen a sus
trabajadores, y los invite a que participen en la ejecución del registro de obra, y así comunicar
sus altas y bajas dentro de la obra, de igual manera sus modificaciones de salario para que
reciban las prestaciones en especie y en dinero que la propia ley señala.
7
dewe5
Una vez hecho esto, retornan a las oficinas de la subdelegación del IMSS a rellenar el
formato de reporte y promoción de construcción con los datos recabados en su recorrido de
censo, al cual le dan seguimiento ya que se les asignan folios institucionales para regularizar al
patrón y a sus trabajadores, o bien para llegar a un convenio con dichos patrones. Seguido de
esto se pasa los reportes al supervisor para la revisión y firma de aprobación del reporte.
Muchos son los inconvenientes que presentan los visitadores, en la manera en la que
realizan este proceso actualmente para la realización de reportes de promoción y detección de
construcciones de obras, ya que se ha observa que se invierte mucho tiempo en la manera en
que se generan actualmente los reportes, debido a que este proceso llega a ser monótono,
manual y repetitivo, lo cual no ayuda a la agilización de los trámites del registro de obra.
Al realizar el trabajo de manera manual, llegan a surgir diversos problemas en este
proceso, por ejemplo, que la escritura sea ilegible o en su caso exista información incompleta,
también en el manejo de los diversos folios que contienen los reportes, no se escriban de manera
adecuada por los visitadores con la estructura ya definida por él instituto, estos problemas
generan más pérdida de tiempo, debido a que se tendría que llamar a quien realizó el reporte,
ya sea para que lo corrija o explique lo que quiso dar a entender en el reporte que ha realizado.
Entre otros problemas que se pueden observar, es que no se maneja de una manera
eficiente el control de dichos reportes después se les otorga un folio único de reporte y la
autorización de un supervisor, ya que la manera correcta de llevar un control es mediante un
concentrado de tales documentos foliados, para saber a qué visitador se le dio determinado folio
y cantidad que se le expidió a cada uno, esto para llevar un buen control de la información. Lo
cual origina algunas cuestiones como el no darles seguimiento a los reportes por parte de los
visitadores, este seguimiento de los reportes se pierde por la excesiva carga de trabajo que se
les asigna a los visitadores, haciendo que no lleve bien este control, dicha sobre carga de trabajo
no es posible que pueda llegar a disminuir, pero si es posible hacer recordatorios con un sistema
que le ayude al visitador a gestionar la información faltante.
El departamento al no poder dar seguimiento más ágil a dichos documentos, se atrasa en
cuestiones administrativas, lo que conlleva, a que si un patrón decide presentar su afiliación al
instituto o regularizarse, no pueda proceder su solicitud, porque no se tiene por completo el
trámite por escrito.
8
dewe5
Este trámite se establece después de la realización del reporte de promoción y detección
de construcción de obra pública o privada, es decir, los documentos deben estar debidamente
rellenados y completos, para que se les asignen los folios propios de la subdelegación, y con ello
seguir con los demás pasos para registrar al patrón y los trabajadores.
Por estos problemas que se llegan a generar, se propone la realización que un sistema
que apoye en estas tareas tan simples, pero muy necesarias en la labor diaria del visitador, este
sistema le otorgará de manera rápida y eficaz los distintos reportes que son necesarios para su
trabajo, ya sea para el visitador o supervisor, de igual manera dará recordatorio del trabajo que
se le llegue retrasar a los visitadores.
9
dewe5
Objetivo general
Diseñar un sistema de información para el IMSS que gestione la información de obras públicas
y privadas, a través de una plataforma web.
Objetivos específicos
Los objetivos específicos que sigue este proyecto son:
• Desarrollar un módulo para el control de usuarios que ingresaran al sistema y así evitar el acceso
a personal no autorizado.
• Desarrollar una aplicación para administrar la información de los municipios, colonias y códigos
postales y así lograr agilizar su búsqueda.
• Implementar un módulo para la gestión de patrones mediante la verificación de la información en
las detecciones de obras.
• Diseñar un formulario dinámico para las detecciones de obra, mediante el cual se podrá realizar
las altas, modificación y consulta.
• Realizar un subsistema de alertas para notificar a los visitadores las obras con falta de
información.
• Realizar una interfaz de usuario para generar reportes automatizados, para lograr apresurar el
desarrollo del trámite de detección de obra.
10
dewe5
Justificación
El Sistema automatizado para el control y generación de reporte de detección de obras
públicas y privadas, para la regularización del servicio de afiliación de obras en la ciudad de
Oaxaca, busca ser una herramienta de ayuda para el departamento de auditoría a patrones de
la subdelegación del IMSS en Oaxaca, ya que este departamento en la actualidad, aún no cuenta
con un sistema que ayude a la agilización y gestión de la información de las nuevas obras, y por
consiguiente la creaciones de diversos reportes de detección de obras.
Este sistema mejorara el control y supervisión de reportes de detección de obras, de igual
manera contribuye a llevar una buena administración sobre la carga de trabajo que se les otorga
a los visitadores, de modo que ayude a la eficiencia, mejoramiento y agilización de este proceso
de generación de reportes de detección de obras, al mismo tiempo con la agilización de este
proceso es posible también apoyar a la regularizar del servicio de seguridad social a los
trabajadores de las construcciones, dado que esto es de suma importancia para el instituto,
debido a que el trabajador se debe encontrar asegurado desde el inicio de la obra, hasta su
conclusión.
Los motivos de la realización de este sistema, son los beneficios que otorgará a los
patrones, debido a que les ayudará a obtener la afiliación de sus trabajadores con mayor rapidez
y eficiencia, de esta manera también estará obteniendo la correcta afiliación de su obra, otra
razón más por la que se realiza, es por la disminución de información incorrecta o mal escrita
cuando se está realizando la captura de manera manual de los reportes, por tanto, esta
información incorrecta provoca retrasos en la afiliación de obras, tomando en cuenta que en los
reportes digitales no existirán estos inconvenientes, y también se podrán manejar de una manera
más flexible sin la necesidad de que intervenga el visitador o supervisor en la creación de estos
reportes, ya que se generarán de forma automática y cualquier trabajador podrá acceder a ellos
de una manera rápida, lo que conllevará a poder lograr mejor calidad en el servicio y cuidar la
importancia del mismo.
El desarrollo de este sistema beneficiará de la siguiente manera:
Los visitadores del departamento de auditoría de patrones, les contribuirá a
disminuir costos en cuanto tiempo de realización de la captura e insumos que se ocupan
actualmente para realizar el proceso, igualmente contribuirá a que no se origine un mayor
retraso de información, ya que se verificará que cada visitador tenga asignado un cierto
11
dewe5
número de reportes, tanto como completados o en ejecución, si está autorizado o no, así
también el visitador dejará de preocuparse si ya ingreso los folios necesarios a la
detección de obra, en consecuencia el visitador estará al corriente con sus detecciones
de obra, lo cual también le permitirá saber que reportes les falta por realizar la asignación
del folio de numero de reporte de detección de obra.
Los supervisores y jefes inmediatos obtendrán con mayor rapidez reportes
generales de la información de los visitadores, de igual manera, podrán realizar acciones
sobre los recordatorios que genera el sistema hacia los visitadores que se atrasan con la
información.
El derechohabiente será respaldado por el instituto con atención médica, ante
cualquier incidente que se pudiera llegar a percatar durante la realización de la obra en la
que este laborando, todo esto al concluir su proceso de afiliación.
El patrón, evitará tener sanciones de cualquier tipo por no registrar su obra y a sus
trabajadores ante el instituto, puesto que es obligación del mismo.
De tal manera, el sistema resolverá los siguientes problemas que se presentan actualmente:
• Reducción en el tiempo de elaboración de reportes de detección de obra.
• Reducción a los costos de insumos de papelería, ya que se manejan cantidades excesivas en el
departamento.
• Mejorar la calidad del servicio que se le da a los patrones.
• Cumplir la función de control, uso y generación de reportes de detección de construcción.
• Mediante el control de detección de obras, se logrará otorgar el seguro del IMSS con mayor
rapidez a los trabajadores de obras.
• Tener un mejor control de las obras registradas ante el instituto, para una mejor eficiencia de la
consulta de la información.
12
dewe5
Tecnologías a utilizar
Para el desarrollo del sistema, se utilizará PHP, el cual es un lenguaje diseñado para el
desarrollo web y puede ser embebido en código HTML, o bien puede utilizar en combinación con
varios sistemas de plantillas web, sistemas de gestión de contenido web y framework web, pero
de igual manera se utiliza como lenguaje de propósito general. PHP conocido también como
Procesador de Hipertexto, absorbe la sintaxis de lenguajes como C, Java y Perl los cuales son
lenguajes de programación populares en la actualidad, siendo también un lenguaje de fácil
aprendizaje para programadores.
El objetivo general de PHP es permitir a los desarrolladores escribir rápidamente páginas
web con contenido dinámico, tomando en cuenta que PHP también se utiliza en muchas otras
áreas. Es considerado uno de los lenguajes más flexibles, potentes y de alto rendimiento
conocidos hasta el día de hoy.
PHP también ofrece la capacidad de poder ser ejecutado en la gran mayoría de sistemas
operativos háblese de Unix siendo de este tipo, como Linux o Mac OS X y también en Microsoft
Windows, y puede haber una interactuación con los servidores web más populares que ya existen
en versión CGI (Interfaz de entrada común), módulo para Apache.
Este lenguaje de programación también permite la conexión entre diferentes tipos de
servidores de bases de datos SQL como MySQL, PostgreSQL, Oracle, entre otros, los cuales
serán indispensables para el desarrollo de este sistema.
En el manejo de PHP, es preciso que trabaje en conjunto con JavaScrip, el cual es un
lenguaje de programación de interpretado, llega a definirse como dinámico y orientado a objetos,
este lenguaje fue diseñado originalmente para el HTML dinámico en los navegadores, este
lenguaje llegará a ser de gran ayuda en este proyecto por las características que ofrece, como
evaluar las diversas instrucciones que demande el usuario para modificar contenido, igualmente
ofrece la carga o generación de información lo cual otorgara diversas posibilidades dentro de
HTML y CSS.
Dentro de las posibilidades que también ofrece JavaScript son Ajax y jQuery las cuales
son bibliotecas de JavaScrip, estas 2 bibliotecas son de suma importancia para el desarrollo de
este proyecto.
13
dewe5
Ajax, al no ser una tecnología, sino la unión de un conjunto de grupo de tecnologías, la
cual llega a ofrecer en el lado del cliente la creación de aplicaciones web asíncronas, ya que
permite enviar datos desde la web, como por ejemplo consultas SQL, y recuperar los resultados
del lado del servidor de forma asíncrona, sin intervenir en la visualización y comportamiento de
la página existente, ya que no existe la necesidad de volver a cargar la página por completo.
Por otro lado, jQuery tiene como función el acceder a HTML para la navegación y
manipulación proporcionada (Document Object Model) de elementos, lo cual permite la creación
de animaciones, manejar eventos y desarrollar aplicaciones Ajax. jQuery fue diseñada para
simplificar el script del lado del cliente de HTML, esto permite a los desarrolladores crear
abstracciones para la interacción de bajo nivel, asimismo animaciones y efectos avanzados. El
enfoque modular que otorga la biblioteca jQuery permite la creación de potentes páginas web
dinámicas y aplicaciones Web. (jQuery write less, do more, 2016)
También se ocupa para el desarrollo de este proyecto PHPExcel y PHPWord, ambas son
un conjunto de clases para el lenguaje de programación PHP, en el caso de PHPExcel entre las
características que proporciona, son escribir y leer los diferentes formatos de hojas de cálculo
(.xls, .xlsx), al igual que la definición de hoja de cálculo de metadatos, manipular varias hojas,
modificar a diferentes fuentes y estilos de fuente, los bordes de las celdas, rellenos, gradientes,
añadir imágenes a la hoja de cálculo, el cálculo de las fórmulas y entre diversas acciones más
que permitirá realizar PHPExcel, en cambio PHPWord se basa en la creación y manipulación de
documentos de texto.
El manejo de estas diversas tecnologías, es indispensable para el buen desarrollo de este
proyecto, los cuales se complementan para obtener un buen sistema estable.
14
dewe5
Definición de historias de usuario del sistema
Las historias de usuarios que se desarrollarán a continuación para este sistema, ayudarán
a comprender la importancia de ir realizando el sistema por módulos, y así se logren realizar
estimaciones razonables de recursos, costos y planificaciones temporales.
Historias de usuarios ID Nombre Descripción Importancia Estimación inicial
(En horas) Como probarlo Notas u
observaciones
1 Usuarios El sistema se controlará por 2 tipos de usuarios, los cuales contarán con una clave de acceso, lo cual es necesario para que exista un correcto manejo de cada área del sistema.
90 45 Insertar, consultar y eliminar los distintos usuarios que se manejen, con sus respectivas validaciones.
Tipos de Usuarios:
• Supervisor
• Visitador
2 Municipio Contendrá todos los municipios del estado de Oaxaca, con sus respectivas colonias y códigos postales.
70 60 Insertar, consultar, modificar y eliminar los distintos municipios que estén dados de alta, con sus respectivas validaciones.
3 Patrón El sistema manejará los distintos patrones mediante un identificador único, conocido como registro patronal, se manipulará como un catálogo de patrones.
90 70 Insertar, consultar, modificar y eliminar los patrones al momento de dar de alta una detección de obra.
4 Detección Obras En el sistema se permitirá el manejo de información de las detecciones de obra por medio de un formulario, el cual contará con diversos campos de acuerdo a las necesidades del visitador.
100 90 Se consultará y modificará la información que el mismo visitador a dado de alta con anterioridad.
5 Alertas El sistema tendrá un control de alertas, el cual notificará al visitador mediante la visualización de diversos campos, los cuales especificará el supervisor, para la toma de acciones sobre el reporte de detección de obra atrasado.
85 65 Al iniciar sesión, observará una tabla, la cual mostrará la información de detección de obras sin toma de acciones.
6 Reporte El sistema generará diversos reportes en
80 50 El visitador tendrá la opción de generar reportes en la
15
dewe5
la sesión del visitador y supervisor.
extensión .docx (Documento de Microsoft Word) y .xlsx (Hoja de cálculo de Microsoft Excel).
Tabla 1. Planificación de historias de usuario del sistema.
16
dewe5
Planificación de entrega
Existen distintos tipos de métodos que permiten estimar el tiempo de administración de
un proyecto. Es de suma importancia que se tome en consideración: la duración total del
proyecto, fecha de inicio y el fin de cada una de las iteraciones, debido a que con estas
estimaciones será del conocimiento algún atraso o desfase en las realizaciones de las tareas
individuales que conformaran el proyecto. Tomando en cuenta que este proyecto se le dedicará
6 horas diarias, se podrá estimar la fecha de entrega.
Duración de cada iteración y posibles historias de usuario de cada iteración
El sistema se dividió en 6 historias de usuarios, las cuales se planificaron en 3 iteraciones,
quedando distribuidas de la siguiente manera:
2.8.1. Historias de usuario por iteración
Historias de usuario Iteración Tiempo estimado Usuarios 1 28 horas
Municipio 1 36 horas
Patrón 1 64 horas
Detección Obras 2 77 horas
Alertas 2 61 horas
Reportes 3 50 horas
Tabla 2. Distribución de historias de usuario en cada iteración.
2.8.2. Duración por iteración
Iteración Tiempo
estimado(Hrs)
Tiempos (días
hábiles)
Fecha de Inicio Fecha Fin
1 128 22 02/febrero/2016 03/marzo/2016
2 138 24 07/marzo/2016 11/abril/2016
3 50 9
13/abril/2016 25/abril/2016
Tabla 3. Planificación de duración de cada iteración.
17
dewe5
Capítulo III Iteraciones del sistema
Primera iteración
3.1.1. Exploración
3.1.1.1. Historias de usuario que se utilizarán en esta primera iteración
En esta iteración, se analizarán las historias de usuario, de usuarios,
municipio y patrón, que son de suma importancia para una buena planificación y
desarrollo de este proyecto, en la tabla que se presenta a continuación se puede
observar el tiempo estimado en el que fue desarrollado cada historia de usuario.
Historias de usuario Iteración Tiempo estimado Usuarios 1 28 horas
Municipio 1 36 horas
Patrón 1 64 horas
Tabla 4. Tiempo estimado de cada historia de usuario de la primera iteración.
3.1.2. Planeación
3.1.2.1. Selección de historias de usuario
En la primera iteración trabajamos con las siguientes historias de usuario:
Usuarios: Llevará a cabo el control de los usuarios que utilizarán el sistema,
podrán realizar alta, consultas, modificaciones y bajas, dependiendo de los
privilegios que tenga el usuario logueado usuario.
Municipio: Llevará el alta, consulta, modificación y eliminación de las colonias o
municipios que se lleguen a registrar en el sistema.
Patrón: Llevará el control de los distintos patrones que se manejen en el sistema,
para esto se realizarán altas, consultas, modificación y bajas de la información de
los patrones.
18
dewe5
3.1.3. Diseño
3.1.3.1. Historia de usuario: Usuarios
Tarea Número de tarea: 1 Número de historia: 1 Usuarios
Nombre de tarea: Recolectar información
Tipo de tarea: Recopilación de información Puntos estimados: 4 horas
Fecha de inicio: 02/febrero/2016 Fecha de fin: 02/febrero/ 2016
Programador responsable: Jesús Sanjuan Méndez
Descripción: Recolectar la información necesaria para crear las tablas de usuarios.
La tarea uno, se realizó la recopilación de información, esta se obtuvo mediante una visita
al cliente, el cual expuso y proporcionó la información necesaria para saber qué tipos de usuarios
se utilizarán en el sistema, esta información que proporcionó el cliente, ayudó para la realización
del diseño de las tablas de la base de datos, al igual que con el prototipo del manejo de usuarios
y continuar con la realización del módulo.
Tarea Número de tarea: 2 Número de historia: 1 Usuarios
Nombre de tarea: Creación de tabla
Tipo de tarea: Otro Puntos estimados: 6 horas
Fecha de inicio: 03/febrero/2016 Fecha de fin: 03/ febrero /2016
Programador responsable: Jesús Sanjuan Méndez
Descripción: Se estructura las tablas de la base de datos conforme a la información que proporcionó el cliente, de esta manera se crearon 3 tablas.
Después de la reunión que se tuvo con el cliente del sistema, se diseñaron 3 tablas para
esta historia de usuario, en la primera tabla nombrada “usuarios” la cual cuenta con 8 atributos
como se observa en la Figura 1, seguido de su código SQL (Figura 2), esta primer tabla es la
principal en la cual se enlazan las siguientes 2 tablas creadas. En cuanto a las siguientes 2 tablas
son de tipo catalogo las cuales se puede apreciar su estructura en las Figura 3 y Figura 5 seguido
de su código SQL de cada tabla.
19
dewe5
Columna Tipo de dato Longitud Clave Primaria Clave Foránea Descripción
id_usuario varchar 20 SI NO Identificador único de usuario
id_profesion varchar 5 NO SI Identificador único de profesión
nombre varchar 15 NO NO Nombre del usuario
apellmat varchar 15 NO NO Apellido materno del usuario
apellpat varchar 15 NO NO Apellido paterno del usuario
idtipousuario varchar 5 NO SI Identificador único del tipo de usuario
nombrelogin varchar 15 NO NO Nombre para el inicio de sesión del usuario
contrasena varchar 20 NO NO Contraseña del usuario
Figura 1. Estructura de tabla SQL nombrada “usuarios”
Figura 2. Código SQL de tabla “usuarios”.
Columna Tipo de dato Longitud Clave Primaria Clave Foránea Descripción
idtipousuario varchar 5 SI NO Identificador único del tipo de usuario
nombre_tipo varchar 20 NO NO Nombre del tipo de usuario
Figura 3. Estructura de tabla SQL nombrada “tipousuario”.
Figura 4. Código SQL de tabla “tipousuarios”.
Columna Tipo de dato Longitud Clave Primaria Clave Foránea Descripción
id_profesiones varchar 5 SI NO Identificador único de profesión de usuario
nombre_profecion varchar 30 NO NO Nombre de la profesión del usuario
Figura 5. Estructura de tabla SQL nombrada “profesiones”.
Figura 6. Código SQL de tabla “profesiones”.
CREATE TABLE `usuarios` (
`id_usuario` varchar(20) NOT NULL,
`id_profesion` varchar(5) NOT NULL,
`nombre` varchar(15) NOT NULL,
`apellmat` varchar(15) NOT NULL,
`apellpat` varchar(15) NOT NULL,
`idtipousuario` varchar(5) NOT NULL,
`nombrelogin` varchar(15) NOT NULL,
`contrasena` varchar(20) NOT NULL,
PRIMARY KEY (`id_usuario`),
FOREIGN KEY(id_profesion,idtipousuario)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE `tipousuario` (
`idtipousuario` varchar(5) NOT NULL,
`nombre_tipo` varchar(20) NOT NULL,
PRIMARY KEY (`idtipousuario `)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
CREATE TABLE `profesiones` (
`id_profesiones` varchar(5) NOT NULL,
`nombre_profesion` varchar(30) NOT NULL,
PRIMARY KEY (`id_profesiones`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
20
dewe5
Tarea Número de tarea: 3 Número de historia: 1 Usuarios
Nombre de tarea: Prototipo de aplicación
Tipo de tarea: Desarrollo de interfaces Puntos estimados: 6 horas
Fecha de inicio: 04/febrero /2016 Fecha de fin: 04/ febrero/2016
Programador responsable: Jesús Sanjuan Méndez
Descripción: Creación de la interfaz de inicio del sistema.
Para esta tarea, se desarrollaron los prototipos del sistema, en el cual se manejarán los
usuarios, quedando diseñado como se observa a continuación:
Figura 7. Prototipo de alta de usuarios.
21
dewe5
Figura 8. Prototipo de consulta de usuarios.
22
dewe5
Figura 9. Prototipo de baja de usuarios.
23
dewe5
Figura 10. Prototipo de modificación de datos de usuarios.
Tarea Número de tarea: 4 Número de historia: 1 Usuarios
Nombre de tarea: Alta de usuarios
Tipo de tarea: Desarrollo Puntos estimados: 6 horas
Fecha de inicio: 05/febrero/2016 Fecha de fin: 05/febrero/2016
Programador responsable: Jesús Sanjuan Méndez
Descripción: Crear el módulo de altas usuarios, validando distintos valores de entrada.
Con esta tarea se empezará la parte de programación de este módulo, aquí se llevará a
cabo el alta de los usuarios en el sistema.
24
dewe5
Caso de prueba
Número Caso de prueba: 1 Número y nombre de tarea: 4.- Alta de usuarios
Nombre de caso de prueba: Probar el alta de usuarios
Descripción: Verificación del alta de usuarios, con la validación de datos al momento de ingresarlos.
Condiciones de ejecución: 1. En la Figura 7, se observa la interfaz que visualizará el usuario al momento de realizar el alta de
un nuevo usuario en el sistema. 2. Solo se mostrarán a los supervisores el alta de usuarios. 3. Solo el usuario con rol de supervisor puede manipular este módulo. 4. Para realizar alta de un usuario, es necesario no repetir el nombre de inicio de sesión. 5. Se utilizará las mismas tablas para el alta de un supervisor y visitador, estos tipos de usuarios
comparten los mismos atributos para darse de alta.
Entradas: 1. Al dar de alta, el usuario debe rellenar 8 campos que son necesarios. Una vez que termina de
rellenar dará clic en el botón Alta. Se validará lo siguiente en cada campo:
a. Nombre (Caracteres alfabéticos y espacio únicamente, no permite que el nombre inicie con espacios y con longitud mínima de 2 para ser aceptado).
b. Apellido paterno y apellido materno (Caracteres alfabéticos y con longitud mínima de 2).
a. En caso de solo contar con un apellido, dar doble click sobre el campo de apellido paterno o materno, esto lo bloqueara e indicara que no cuenta con uno de sus apellidos, dar nuevamente doble click para invertir el proceso.
c. Profesión (Solo tendrá la oportunidad de escoger los de la barra desplegable, sin posibilidad de dar de alta nuevas profesiones, es necesario que seleccione alguno).
d. Tipo de Usuario (Solo tendrá la oportunidad de escoger los 2 únicos tipos de usuarios que maneja el sistema, es necesario que seleccione alguno).
e. Nombre de Usuario (Acepta caracteres alfabéticos, mayúsculas y minúsculas, no permitirá nombre de usuarios anteriormente registrados y con longitud mínima de 2).
f. Contraseña y Repita Contraseña (Acepta caracteres alfabéticos, mayúsculas y minúsculas, también valores numéricos, con longitud mayor de 6 y ambos campos deben de coincidir).
Resultado esperado: 1. Las altas que se realicen correctamente y pasen la validación de datos, se verán reflejados en la
base de datos y se mostrará la alerta de que se ha realizado con éxito el alta del usuario.
Evaluaciones: Caso de prueba 1: Alta de usuarios.
25
dewe5
Tarea Número de tarea: 5 Número de historia: 1 Usuarios
Nombre de tarea: Consulta, baja, y modificación de usuarios.
Tipo de tarea: Desarrollo Puntos estimados: 6 horas
Fecha de inicio: 08/febrero/2016 Fecha de fin: 08/febrero/2016
Programador responsable: Jesús Sanjuan Méndez
Descripción: Crear el módulo de consulta, baja, y modificación usuarios, validando distintos valores de entrada.
Caso de prueba
Número Caso de prueba: 2 Número y nombre de tarea: 5.- Consulta, baja, y modificación de usuarios.
Nombre de caso de prueba: Probar la consulta, baja y modificación de usuarios.
Descripción: Verificación el correcto funcionamiento de consulta, baja y modificación de usuarios de acuerdo a las restricciones que solicita el cliente del sistema.
Condiciones de ejecución: Consultas:
1. En la Figura 8 se muestra la interfaz de consulta de usuarios. 2. Solo se mostrarán a los supervisores la consulta de usuarios. 3. Para realizar la consulta solo se necesita recargar la página. 4. La consulta mostrará la siguiente información:
a. Nombre del usuario b. Apellido Paterno y Apellido Materno c. El tipo de usuario que es d. Cantidad de reportes de detección de obra que tiene a su cargo e. Nombre de inicio de sesión f. Contraseña g. Profesión del usuario
Bajas:
1. Para realizar las bajas, se debe presentar primero la página de consultas (Figura 8), dentro de la cual se encuentra la opción de eliminar a los usuarios, ubicado al costado izquierdo con el siguiente icono:
2. Solo se mostrará a los supervisores la baja de usuarios. 3. Solo será posible eliminar visitadores que no cuentan con ningún reporte a cargo. 4. El supervisor que inicie sesión no se le permitirá borrar su propio usuario. 5. En caso de eliminar todos los usuarios, el sistema no dejará eliminar el último supervisor
que quede en el sistema, el cual no podrá borrarse hasta que exista otro usuario con rol de supervisor.
Modificaciones:
1. Para la realizar una modificación es indispensable pasar antes por la consulta de usuarios (Figura 8), dentro de la consulta se puede acceder a la modificación (Figura 10).
2. Solo podrá ser manipulado por los supervisores esta opción.
26
dewe5
3. De los resultados otorgados por la consulta de usuarios, se seleccionará al usuario que se desea modificar su información.
4. Para la modificación se ocupará la misma tabla de altas (usuarios), solo se sustituirá la información anterior con la nueva que se ingrese en la modificación de usuarios, con excepción del id_usuario, el cual no será posible modificar.
5. Al modificar, se tendrán las mismas restricciones como el alta de usuarios, también el sistema restringirá la posibilidad de ocupar un nombre de usuario que ya este dado de alta en el sistema.
Entradas:
Consultas: 1. Solo es necesario ingresar por el menú configuración-> usuarios-> consulta, dentro de la
consulta se mostrarán los resultados, en casos de querer actualizar la tabla solo hay que recargar la página.
Bajas:
1. El supervisor deberá elegir algún otro supervisor o visitador para darlo de baja. 2. Selecciona el icono de eliminar a continuación le aparecerá un mensaje emergente para
confirmar la eliminación. 3. En caso de aceptar el usuario de su elección será dado de baja.
Modificación:
1. El supervisor debe buscar al usuario que desea modificar su información. 2. Selecciona el icono de modificar (lápiz) y se re-direccionará a la página modificar (Figura
10), aparecerán los datos en cajas de texto modificables para que sea posible editar la información.
Resultado esperado: Consulta:
Obtener la información de todos los usuarios que actualmente usan el sistema. Baja:
Cumpliendo las restricciones de entrada, se considera exitosa la eliminación de usuarios. Modificación:
Modificar correctamente la información de los usuarios, cumpliendo las restricciones establecidas en cada campo, de esta forma se obtendrá una modificación exitosa.
Evaluaciones: Caso de prueba 2. Consulta, baja y modificación de usuarios.
27
dewe5
3.1.3.2. Historia de usuario: Municipio
Tarea Número de tarea: 6 Número de historia: 2 Municipio
Nombre de tarea: Recolectar información
Tipo de tarea: Recopilación de información Puntos estimados: 4 Horas
Fecha de inicio: 09/febrero/2016 Fecha de fin: 09/febrero/2016
Programador responsable: Jesús Sanjuan Méndez
Descripción: Recolectar la información necesaria para crear las tablas del manejo de la información de municipios.
En la tarea 1 de las historias de usuario “municipio”, se realizó la recopilación de
información, la cual se obtuvo mediante una visita al cliente, el cual expuso y proporcionó la
información necesaria para saber qué tipos de conflictos llegan a generarse con el manejo de los
municipios en conjunto con códigos postales, esta información que proporcionó el cliente, ayudó
al diseño de las tablas y así continuar con la realización del módulo.
Tarea Número de tarea: 7 Número de historia: 2 Municipio
Nombre de tarea: Creación de tabla
Tipo de tarea: Otra Puntos estimados: 6 Horas
Fecha de inicio: 10/febrero/2016 Fecha de fin: 10/febrero/2016
Programador responsable: Jesús Sanjuan Méndez
Descripción: Se estructura las tablas de la base de datos conforme a la información que proporcionó el cliente, de esta manera se crearon 2 tablas.
Al concluir con la recolección de la información necesaria, se diseñaron 2 tablas para esta
historia de usuario, la primer tabla nombrada “colonia” (Figura 11. Estructura de tabla SQL nombrada
“colonia”.) es la tabla principal en la cual se guarda toda la información de todas las colonias del
estado de Oaxaca la cual esta enlaza con la tabla municipios (Figura 13). En conjunto con las
tablas, se presenta el código de creación de las tablas SQL (Figura 12 y Figura 14).
28
dewe5
Columna Tipo de dato Longitud Clave Primaria Clave Foránea Descripción
id_colonia varchar 6 SI NO Identificador único de colonia
nombre_colonia varchar 80 NO NO Nombre de la colonia
Código_postal int 5 NO NO Código postal de la colonia
Id_municipio int 5 NO SI Identificador único del municipio al que
pertenece la colonia
Figura 11. Estructura de tabla SQL nombrada “colonia”.
Figura 12. Código SQL de tabla “colonia”.
Columna Tipo de dato Longitud Clave Primaria Clave Foránea Descripción
id_municipio int 5 SI NO Identificador único del municipio
Nombre_municipio varchar 60 NO NO Nombre del municipio
Figura 13. Estructura de tabla SQL nombrada “municipios_delegaciones”.
Figura 14. Código SQL de tabla “municipios_delegaciones”.
CREATE TABLE `colonia` (
`id_colonia` varchar(6) NOT NULL,
`nombre_colonia` varchar(80) NOT NULL,
`codigo_postal` int(5) NOT NULL,
`id_municipio` int(5) NOT NULL,
PRIMARY KEY (`id_colonia`),
FOREIGN KEY(id_municipio)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
CREATE TABLE `municipios_delegaciones` (
`id_municipio` int(5) NOT NULL,
`nombre_municipio` varchar(60) NOT NULL,
PRIMARY KEY (`id_municipio`);
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
29
dewe5
Tarea Número de tarea: 8 Número de historia: 2 Municipio
Nombre de tarea: Prototipo de aplicación
Tipo de tarea: Desarrollo de interfaces Puntos estimados: 6 horas
Fecha de inicio: 11/febrero/2016 Fecha de fin: 11/febrero/2016
Programador responsable: Jesús Sanjuan Méndez
Descripción: Creación de la interfaz de control de municipios.
Para esta tarea se desarrolló el prototipo del módulo de municipio, en el cual se manejarán
los diversos municipios de Oaxaca, con sus colonias y respectivos códigos postales, quedando
diseñado como se observa a continuación:
Figura 15. Prototipo de alta de municipios, con sus respectivas colonias y códigos postales.
30
dewe5
Figura 16. Prototipo de consulta de municipios.
31
dewe5
Figura 17. Prototipo de modificación y eliminación de municipio con sus respectivas colonias.
Tarea Número de tarea: 9 Número de historia: 2 Municipio
Nombre de tarea: Alta de Municipio
Tipo de tarea: Desarrollo Puntos estimados: 8 horas
Fecha de inicio: 12/febrero/2016 Fecha de fin: 15/febrero/2016
Programador responsable: Jesús Sanjuan Méndez
Descripción: Crear el módulo de altas de municipios validando distintos valores de entrada.
Con esta tarea, se empezará la parte de programación de este módulo, aquí se llevará a
cabo el alta de los municipios permitiendo también agregando sus respectivas colonias con sus
códigos postales, lo cual se manejará de manera dinámica.
32
dewe5
Caso de prueba
Número Caso de prueba: 3 Número y nombre de tarea: 9.- Alta de municipio.
Nombre de caso de prueba: Probar el alta de municipio.
Descripción: Verificación del alta de municipio, con la validación de datos al momento de ingresar.
Condiciones de ejecución: 1. En la Figura 15, se logra observar la interfaz que visualizará el usuario al momento de dar de
alta a un nuevo municipio en el sistema. 2. Solo se mostrarán a los supervisores el alta de municipio. 3. Solo el usuario con rol de supervisor puede manipular este módulo. 4. Para realizar el alta de un municipio, es necesario que no se repita el nombre del municipio con
alguno que ya este dado de alta en el sistema.
Entradas: En altas: 1. Al dar de alta a un nuevo municipio, debe rellenar el campo llamado: nombre de municipio.
Se validará lo siguiente en este campo: a. Solo aceptara letras, números y espacio. b. Longitud mínima de 9. c. Se validará que el nombre no esté dado de alta en la base de datos.
2. Después se tendrá la opción de agregar la cantidad necesaria de colonias, lo cual agregará 2 campos por cada colonia que se agregue. Se validará lo siguiente en cada campo:
a. Nombre de la colonia, solo aceptara letras, números y espacio, con longitud mínima de 3.
b. Código postal, solo permitirá el ingreso de dígitos, con longitud forzosa de 5 dígitos. c. Se verificará que el nombre de la colonia no se repita dentro de este municipio. d. No se permitirá el uso de un código postal de otra colonia que pertenezca a otro
municipio. 3. Una vez que se termina de rellenar se dará clic en el botón Alta.
Resultado esperado: 1. Las altas que se realicen correctamente y pasen la validación de la información, se verán
reflejados en la base de datos y se mostrará una notificación que indicara si se ha realizado con éxito el alta del nuevo municipio.
Evaluaciones: Caso de prueba 3. Alta de municipio.
33
dewe5
Tarea Número de tarea: 10 Número de historia: 2 Municipio
Nombre de tarea: Consulta, modificación y baja de municipio.
Tipo de tarea: Desarrollo Puntos estimados: 12 horas
Fecha de inicio: 16/febrero/2016 Fecha de fin: 17/febrero/2016
Programador responsable: Jesús Sanjuan Méndez
Descripción: Crear el módulo de consulta, modificación y baja de municipios validando distintos valores de entrada.
Caso de prueba
Número Caso de prueba: 4 Número y nombre de tarea: 10.- Consulta, modificación y baja de municipio.
Nombre de caso de prueba: Probar la consulta, modificación y baja de municipios.
Descripción: Verificación del correcto funcionamiento de la consulta, modificación y baja de los municipios y sus colonias de acuerdo a las restricciones que solicita el cliente del sistema.
Condiciones de ejecución: Consultas:
1. En la Figura 16 se muestra la interfaz de consulta de municipios. 2. Solo se mostrarán a los supervisores la consulta de municipios. 3. La consulta mostrará la siguiente información:
a. Nombre de la colonia b. Código postal c. Municipio
Modificaciones:
1. Para la realizar una modificación, es indispensable pasar antes por la consulta de municipios (Figura 16), dentro de la consulta se puede acceder a la modificación (Figura 17).
2. Solo podrá ser manipulado por los supervisores esta opción. 3. De los resultados otorgados por la consulta de municipios, se seleccionará la colonia a la
que se le desea modificar su información. 4. Se seguirán ocupando las mismas 2 tablas de altas (municipio_delegaciones, colonia),
únicamente se sustituirá la información anterior con la nueva que se ingrese en la interfaz de modificación de municipios, con excepción de los id_municipio e id_colonia, los cuales no serán posibles de modificar en la base de datos.
5. Al modificar se tendrá las mismas validaciones de los campos como en el alta de municipios (Caso de prueba 3. Alta de municipio.).
6. Solo será posible modificar el nombre del municipio si no se encuentra en uso dentro de detecciones de obra o en datos de algún patrón.
7. Solo será posible modificar el nombre de determinadas colonias de un municipio si no se encuentra en uso dentro de detecciones de obra o en datos de algún patrón.
8. El código postal será posible modificar aun cuando se encuentra en uso dentro de detecciones de obra o en la información de algún patrón.
Bajas:
34
dewe5
1. Para realizar las bajas, se debe presentar primero la página de consultas (Figura 16), en la cual se incluye la opción de modificación (Figura 17), dentro de la modificación se permitirá eliminar el municipio completo o solamente determinadas colonias que se deseen de este municipio.
2. Solo se mostrará a los supervisores la baja de municipio y colonias. 3. Sera posible eliminar municipios que no se encuentren en uso dentro de detecciones de
obra o en la información de algún patrón. 4. Únicamente será posible eliminar colonias que no se encuentren en uso dentro de
detecciones de obra o en datos de algún patrón.
Entradas:
Consultas: 1. Solo es necesario ingresar por el menú configuración-> municipio-> consulta, al haber
ingresado, hay que seleccionar ya sea un municipio de la lista desplegable, o ingresar el código postal (solo acepta 5 dígitos).
Modificación: 1. El supervisor debe buscar la municipio-colonia a la cual desea modificarle su información. 2. Selecciona el icono de modificar (lápiz) y se redireccionará a la página modificar (Figura 17),
aparecerán los datos cargados en cajas de texto modificables para que sea posible editar la información.
Bajas: 1. Después de seleccionar la opción modificar (icono lápiz) en la consulta de municipios
(Figura 16), se localizará dentro de la modificación de municipios (Figura 17) en donde será posible realizar las bajas.
2. El supervisor debe buscar la colonia que desea eliminar. 3. Se observará un botón (basurero) del lado derecho para cada colonia, lo cual permitirá
borrar la colonia deseada. 4. De igual manera se encontrará el mismo tipo de botón (basurero) a un lado del nombre del
municipio, el cual permite borrar todo el municipio con sus respectivas colonias.
Resultado esperado: Consulta:
Obtener la información de todas las colonias del municipio que se deseó consultar. Modificación:
Permitir modificar correctamente la información, cumpliendo las restricciones establecidas en cada campo y así que se verá reflejado en la base de datos.
Baja: Cumpliendo las restricciones de entrada de eliminar, se considerará exitosa la eliminación de municipios con sus respectivas colonias.
Evaluaciones: Caso de prueba 4. Consulta, modificación y baja de colonia y municipio.
35
dewe5
3.1.3.3. Historia de usuario: Patrón
Tarea
Número de tarea: 11 Número de historia: 3 Patrón
Nombre de tarea: Recolectar información
Tipo de tarea: Recopilación de información Puntos estimados: 6 horas
Fecha de inicio: 18/febrero/2016 Fecha de fin: 18/ febrero /2016
Programador responsable: Jesús Sanjuan Méndez
Descripción: Recolectar la información necesaria para crear las tablas de patrones.
En esta tarea de la historia de usuario “patrón”, se realizó la recopilación de información,
en la cual se obtuvo en colaboración con el cliente del sistema la información necesaria para
saber los requerimientos que son necesarios para la realización del manejo de los patrones,
mediante la información que proporcionó el cliente, ayudó para la creación de las tablas y así
lograr continuar con la realización de este módulo.
Tarea Número de tarea: 12 Número de historia: 3 Patrón
Nombre de tarea: Creación de tabla
Tipo de tarea: Otra Puntos estimados: 10 horas
Fecha de inicio: 19/ febrero /2016 Fecha de fin: 22/ febrero /2016
Programador responsable: Jesús Sanjuan Méndez
Descripción: Se estructuro la tabla de base de datos conforme a la información que proporcionó el cliente.
Para la creación de la tabla de la historia de usuario de patrón, se creó la tabla con nombre
“patrón”, en la cual se guardará la información más relevante y necesaria del patrón. En la Figura
18 se puede observar los datos que se guardarán en la tabla, así también la relación que tendrá
con otras tablas que se han creado con anterioridad, de igual manera se presenta el código con
el cual se creó la tabla en la base de datos (Figura 19).
36
dewe5
Columna Tipo de dato Longitud Clave Primaria Clave Foránea Descripción
id_patron varchar 7 SI NO Identificador único del registro patronal
registro_patronal varchar 11 NO NO Número de registro patronal
nombre_razon_social varchar 100 NO NO Nombre del responsable de la obra
calle_avenida_patron varchar
150 NO NO Calle del domicilio fiscal del responsable de la obra
Id_colonia_patron varchar
6 NO SI Identificador único de la colonia, con el cual se enlaza al catálogo de colonias y municipios de Oaxaca
num_patron varchar
5 NO NO Número exterior del domicilio fiscal del responsable de la obra
Figura 18. Estructura de tabla SQL nombrada “patron”.
Figura 19. Código SQL de tabla “patron”.
CREATE TABLE `patron` (
`id_patron` varchar(7) NOT NULL,
`registro_patronal` varchar(11) NOT NULL,
`nombre_razon_social` varchar(100) NOT NULL,
`calle_avenida_patron` varchar(150) NOT NULL,
`id_colonia_patron` varchar(6) NOT NULL,
`num_patron` varchar(5) NOT NULL,
PRIMARY KEY (`id_patron`),
FOREIGN KEY(id_colonia_patron)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
37
dewe5
Tarea Número de tarea: 13 Número de historia: 3 Patrón
Nombre de tarea: Prototipo de aplicación
Tipo de tarea: Desarrollo de interfaces Puntos estimados: 10 horas
Fecha de inicio: 23/ febrero /2016 Fecha de fin: 24/ febrero /2016
Programador responsable: Jesús Sanjuan Méndez
Descripción: Creación de la interfaz de control de patrón.
Para esta tarea, se desarrolló el prototipo del módulo de patrón, en el cual se manejarán
los diversos números de registro patronal, el cual quedó diseñado como se observa a
continuación:
Figura 20. Prototipo para el alta, consulta y modificación de los registros patronales.
Tarea Número de tarea: 14 Número de historia: 3 Patrón
Nombre de tarea: Alta de patrones
Tipo de tarea: Desarrollo Puntos estimados: 12 horas
Fecha de inicio: 25/ febrero /2016 Fecha de fin: 26/ febrero /2016
Programador responsable: Jesús Sanjuan Méndez
Descripción: Crear el módulo de altas de municipios, validando distintos valores de entrada.
Con esta tarea se empezará la parte de programación de este módulo, aquí se llevará a
cabo el alta de nuevos patrones.
Tarea Número de tarea: 15 Número de historia: 3 Patrón
Nombre de tarea: Consulta de patrones
Tipo de tarea: Desarrollo Puntos estimados: 16 horas
Fecha de inicio: 29/ febrero /2016 Fecha de fin: 02/ marzo /2016
Programador responsable: Jesús Sanjuan Méndez
Descripción: Se realiza la consulta de la información de los patrones dados de alta en la base de datos, lo cual se reflejará en la interfaz del sistema.
En esta tarea, se empezará a realizar la consulta de información de los patrones que ya
se han dado de alta con anterioridad, la consulta se llegará a dar en conjunto con el alta, al darse
el caso de que el registro patronal que se intenta dar de alta, ya se encuentra en el sistema, de
esta manera solamente se cargará la información ya existente, evitando que se tenga que dar de
alta el mismo registro patronal varias veces. Manejando la tabla patrón como una tabla de tipo
catálogo.
38
dewe5
Caso de prueba
Número Caso de prueba: 5 Número y nombre de tarea: 14,15.- Alta y consulta de patrón
Nombre de caso de prueba: Probar el alta y consulta de patrones
Descripción: Verificación del alta y consulta de patrones, con la validación de datos al momento de ingresar la información.
Condiciones de ejecución: Altas:
1. En la Figura 20 se logra observar la interfaz que visualizará el usuario al momento de dar de alta a un nuevo patrón.
2. El alta de patrón lo podrá realizar solamente el visitador. 3. Para realizar el alta, primero el sistema realizará una consulta, por si existiera ya datos del
registro patronal ingresado. 4. En caso de contar con el número de registro patronal, debe tener la siguiente estructura: el
primer carácter debe ser una letra, seguido de 10 dígitos. Consultas:
1. En la Figura 20, se logra observar la interfaz que visualizará el usuario al momento de consultar la información del patrón.
2. La consulta de patrón, lo podrán realizar tanto los visitadores como los supervisores. 3. Es necesario contar con el número de registro patronal, con la siguiente estructura: primer
carácter debe ser una letra, seguido de 10 dígitos.
Entradas: En altas:
1. Al dar de alta a un nuevo patrón, ya sea que cuente o no cuente con el número de registro patronal, en el caso de contar con el registro patronal, pero del cual no se haya encontrado información, se desbloquearán las cajas de texto editable y procederá a rellenar los siguientes campos con sus respectivas validaciones:
a. Registro Patronal (Estructura primer carácter debe ser letra seguido de 10 dígitos) b. Nombre o Razón Social (Necesario Ingresar, Solo acepta números y letras) c. Calle o Avenida (Necesario Ingresar, Solo acepta números y letras) d. Municipio (Necesario Ingresar)
Buscando por Municipio, se pasará a seleccionar la colonia y automáticamente se rellenará el código postal, doble clic para reiniciar la búsqueda.
e. Código Postal (Necesario Ingresar) Buscando por código postal, se cargará automáticamente el municipio, solo se tendrá que seleccionar la colonia, doble clic para reiniciar la búsqueda.
f. Colonia (Necesario Ingresar) g. Número (Necesario Ingresar, permitirá ingresar S/N, o un numero con longitud máxima
de 6) 2. En caso de contar con número de registro personal y lo encuentre, el sistema cargara los datos
en las cajas de texto, los cuales permanecerán bloqueados. En consultas:
1. Registro Patronal (Su estructura se está definida con primer carácter debe ser letra seguido de 10 dígitos)
2. Al contar con registro patronal, se pasará a consultar con ese número de registro patronal, este cargará todos sus datos en las cajas de texto, las cuales no serán editables, y permitirán al visitador agilizar el proceso de alta.
39
dewe5
Resultado esperado: Altas:
1. Las altas que se realicen correctamente y pasen la validación de datos, ya sea que cuente con o sin el registro patronal, se verán reflejados en la base de datos.
Consultas 1. Mostrar correctamente los datos del registro patronal ingresado, de forma correcta al visitador
en la interfaz (Figura 20).
Evaluaciones: Caso de prueba 5. Alta y consulta de patrón.
Tarea Número de tarea: 16 Número de historia: 3 Patrón
Nombre de tarea: Modificación de patrón
Tipo de tarea: Desarrollo Puntos estimados: 10 horas
Fecha de inicio: 02/marzo/2016 Fecha de fin: 03/ marzo /2016
Programador responsable: Jesús Sanjuan Méndez
Descripción: Se realiza la modificación de la información de los patrones dados de alta en la base de datos, lo cual se reflejará en la interfaz del sistema.
Caso de prueba
Número Caso de prueba: 6 Número y nombre de tarea: 16.- Modificación de patrón
Nombre de caso de prueba: Probar la modificación de patrones
Descripción: Comprobar la funcionalidad de la modificación de patrones, con la validación de datos al momento de ingresar la nueva información.
Condiciones de ejecución: Modificación:
1. En la Figura 20, se logra observar la interfaz que visualizará el usuario al momento de realizar una modificación.
2. La modificación lo podrá realizar el visitador y supervisor. 3. Para realizar la modificación, primero el sistema realizará una consulta para obtener la
información que se modificara. 4. En caso de cambiar el registro patronal, se cargará toda la información del nuevo registro
patronal, y a continuación el usuario tendrá la opción de modificar estos datos que se cargaron. En caso de que el nuevo registro patronal no encuentre información en la base de datos, el usuario ingresará los datos como en el alta, pero este mantendrá el mismo id_patron inicial.
5. Al modificar, solo el id_patron no cambiara por ninguna circunstancia.
Entradas: Modificación:
1. Al modificar la información del registro patronal, se rellenarán los siguientes campos con sus respectivas validaciones:
a. Registro Patronal (Estructura: el primer carácter debe ser letra, seguido de 10 dígitos) b. Nombre o Razón Social (Solo acepta número y letras) c. Calle o Avenida (Solo acepta número y letras)
40
dewe5
d. Municipio Buscando por Municipio, se pasará a seleccionar la colonia y automáticamente se rellenará el código postal, dando doble clic para reiniciar la búsqueda en cualquiera de estos campos.
e. Código Postal Buscando por código postal, se cargará automáticamente el municipio, solo se tendrá que seleccionar la colonia, al dar doble clic en cualquiera de estos 2 campos se reiniciara la búsqueda.
f. Colonia g. Número (Permitirá ingresar S/N, o un número con longitud máxima de 6)
Resultado esperado: Modificación:
1. La correcta modificación se verá reflejada en la base de datos.
Evaluaciones:
Caso de prueba 6. Modificación de patrón.
41
dewe5
3.1.4. Codificación
3.1.4.1. Usuarios
La codificación del módulo de usuarios que se presenta a continuación, es fragmento de la
función que se encarga de realizar las altas de los usuarios, esta función se manda a llamar mediante
la técnica de desarrollo web Ajax, donde anteriormente ya se ha validado toda la información.
Para el funcionamiento del alta de usuarios, principalmente es necesario rescatar toda la
información de los componentes HTML (línea 1 a 10), después se realiza la conexión con la base de
datos (línea 12). La parte clave del desarrollo de este módulo se encuentra entre las líneas 13 a 19
las cuales se encargaran de buscar un identificador disponible para el nuevo usuario que se dará de
alta, al encontrar un identificador disponible (línea 19), el sistema procederá a realizar la inserción a
la base de datos (línea 21 a 25), al concluir, el sistema recibirá una variable(línea 25), la cual se usará
para avisar al usuario, mediante de un jAlert si se realizó con éxito la inserción del nuevo usuario
(línea 26 a 37).
$nombre = htmlspecialchars($_POST["nombre"]); 1 $app = htmlspecialchars($_POST["app"]); 2 $apm = htmlspecialchars($_POST["apm"]); 3 $profesiones = htmlspecialchars($_POST["profesiones"]); 4 $tipousuario = htmlspecialchars($_POST["tipousuario"]); 5 $nombreusuario = htmlspecialchars($_POST["nombreusuario"]); 6 $contrase= htmlspecialchars($_POST["pass1"]); 7 $repcontrase = htmlspecialchars($_POST["pass2"]); 8 $contrasenapasa= htmlspecialchars($_POST["pasodato"]); 9 $identificadorusua= htmlspecialchars($_POST["identificadorusua"]); 10 11 require('conexion.php'); 12
for ($i = 1; $i <= 1000; $i++) 13 { 14 $identificadorusua="usuario".$i; 15 $sql1="SELECT * FROM `usuarios` WHERE id_usuario='$identificadorusua'"; 16 $result2 = mysql_query($sql1); 17 $numero_filas = mysql_num_rows($result2); 18 if ($numero_filas==0) 19 { 20 $sql="INSERT INTO `usuarios` (`id_usuario`, `id_profesion`, 21 `nombre`, `apellmat`, `apellpat`, `idtipousuario`, `nombrelogin`, `contrasena`) VALUES 22 ('$identificadorusua', '$profesiones', '$nombre', '$apm', '$app', '$tipousuario', 23 '$nombreusuario', '$repcontrase');"; 24 $result2 = mysql_query($sql); 25 if($result2) 26 { 27 echo $mensaje = "<script>jAlert('Se ha dado de alta el usuario' 28 , 'Alta Exitosa',function(r){ 29 if(r){setTimeout(window.location='consultausuarios',2000);} });</script>"; 30 } 31 else 32 { 33 echo $mensaje = "<script>jAlert('No ha sido posible dar el alta 34 el usuario, intente mas tarde' , 'Error',function(r) { 35 if(r){setTimeout(window.location='obraAdmin',1000);} });</script>"; 36 } 37 break; 38 } 39 } 40
Código 1. Fragmento de código encargado de realizar el alta de nuevos usuarios.
42
dewe5
3.1.4.2. Municipio
La parte más importante en la codificación del manejo de municipios, es la modificación,
ya que llega a ser más probable que se cambie la información de un municipio, que la creación
de uno nuevo.
Para la codificación de este módulo, se presenta el fragmento de código que se encarga
de actualizar la información del nombre del municipio, nombre de la colonia y el código postal, a
su vez, este código también se encarga de dar de alta alguna nueva colonia que llegue a ser
necesaria en algún municipio, este fragmento de código, únicamente se ejecutará cuando se
haya cumplido las validaciones que se estable en cada elemento HTML (Figura 17).
El código comenzará por actualizar el nombre del municipio (línea 1 a 3), después iniciará
a extraer los nuevos valores (línea 12 a 14) para modificar los nombres de las colonias y sus
códigos postales (línea 5 a 19), hasta este punto se concluye con la modificación de la
información del municipio, a continuación, identificara si se agregaron nuevas colonias de esta
manera realizara la inserción de las nuevas colonias del municipio que se está modificando. Este
tipo de alta de colonias se toma como modificación-alta.
Después de ir recorriendo uno a uno los campos de texto (línea 20) que haya agregado
el usuario por medio de la interfaz (Figura 17), se comenzará con la búsqueda de un identificador
disponible para asignarle a la nueva colonia que se añade (línea 26 a 32), al encontrar un
identificador se iniciará a insertar la nueva colonia con su respectivo código postal (línea 27 a
39), si la inserción se realiza con éxito, se terminará de buscar un identificador saliendo así del
ciclo (línea 40 a 43), al terminar con una colonia, el código continuará con la siguiente, así hasta
que ingrese todas. Al concluir el ciclo, el sistema notificará al usuario por medio de un jAlert
si se realizó con éxito la modificación del municipio.
$sql="UPDATE `municipios_delegaciones` SET `nombre_municipio`='$nombremun' WHERE id_municipio= 1 $id_mun"; 2 $resultmun = mysql_query($sql); 3 4 for($xx=1;$xx<=$cantidadclick;$xx++) 5 { 6 $id_col='id'.$xx; 7 $col='col'.$xx; 8 $cp='cp'.$xx; 9 if (isset ($_POST[$col])) 10 { 11 $id_col2=$_POST[$id_col]; 12 $col2=$_POST[$col]; 13 $cp2=$_POST[$cp]; 14 $sql="UPDATE `colonia` SET `nombre_colonia`='$col2',`codigo_postal`='$cp2' WHERE 15 id_colonia= '$id_col2'" ; 16 $resultcol = mysql_query($sql); 17 } 18 } 19
43
dewe5
for($xx=$cantidadclick+1;$xx<=$variable;$xx++) 20 { 21 $col='col'.$xx; 22 $cp='cp'.$xx; 23 if (isset ($_POST[$col])) 24 { 25 for($i=1;$i<=9000;$i++) 26 { 27 $ii="c".$i; 28 $sql="SELECT id_colonia FROM `colonia` WHERE id_colonia= '$ii'" ; 29 $result2 = mysql_query($sql); 30 $numero_filas = mysql_num_rows($result2); 31 if ($numero_filas==0 ) 32 { 33 $colonia=$_POST[$col]; 34 $codigo=$_POST[$cp]; 35 36 $sql="INSERT INTO `colonia` (`id_colonia`, `nombre_colonia`, 37 `codigo_postal`, `id_municipio`) VALUES ('$ii', '$colonia', '$codigo', '$id_mun');" ; 38 $resultcol2 = mysql_query($sql); 39 if($resultcol2) 40 { 41 break; 42 } 43 } 44 } 45 } 46 } 47 if(($resultcol and $resultmun) or $resultcol2) 48 { 49 echo $mensaje = "<script>jAlert('Se ha realizado la modificacion 50 exitosamente' , 'Modificaion Exitosa',function(r) 51 { 52 if(r) 53 { 54 55 setTimeout(window.location='municipioconsulta',1500); 56 } 57 });</script>"; 58 59 } 60 Código 2. Fragmento de código dedicado a la modificación de información de municipios.
44
dewe5
3.1.4.3. Patrón
La codificación del módulo patrón que se presenta a continuación, se ejecuta después de
haber validado el registro patronal y al presionar sobre un botón que ejecuta esta acción, en este
fragmento de código se presenta solamente lo esencial. Después de haber dado click sobre el
botón, el código se encarga de buscar en la base de datos a los patrones por medio de su registro
patronal, cargando su información en caso de se encuentre su número de registro en la base de
datos, de esta manera se podrá evitar la redundancia de información, en el caso de no encontrar
al patrón, se permitirá ingresar los datos y dar de alta a este nuevo patrón.
Para comenzar el funcionamiento de la búsqueda, primero se ejecuta una consulta para
averiguar si el patrón se encuentra en la base de datos (línea 1 a 17), al recibir el resultado de la
consulta, se comprobará cuantas filas a dado de resultado la consulta (fila 17), mediante una
condición se comprueba si el resultado de la consulta da alguna fila (línea 18), dependiendo del
resultado de la condición se puede dar 2 casos:
• Al encontrar una coincidencia con el registro patronal ingresado por el usuario, el código
extraerá el resultado de la consulta realizada anteriormente (línea 22 a 29), esta
información servirá para presentarla en la interfaz (línea 31 a 39) que visualiza el usuario,
lo cual concluirá con la búsqueda del registro patronal.
• En el caso de no encontrar información del registro patronal ingresado, se le notificara al
usuario que no hay información del registro patronal (línea 44), después se
desbloquearán los campos para permitir ingresar la información del patrón (línea 46 a 51).
$sql=" 1 SELECT 2 patron.`id_patron` , 3 patron.`nombre_razon_social` , 4 patron.`calle_avenida_patron` , 5 colonia.`id_colonia` , 6 patron.`num_patron` , 7 municipios_delegaciones.`id_municipio` , 8 colonia.`codigo_postal` 9 FROM 10 `patron` patron INNER JOIN `colonia` colonia ON patron.`id_colonia_patron` = 11 colonia.`id_colonia` 12 INNER JOIN `municipios_delegaciones` municipios_delegaciones ON colonia.`id_municipio` = 13 municipios_delegaciones.`id_municipio` 14 WHERE registro_patronal='$registrop'" ; 15 $result2 = mysql_query($sql); 16 $numero_filas = mysql_num_rows($result2); 17 if($numero_filas!=0) 18 { 19 echo $mensaje = 20 "<script>document.getElementById('e_registrop').innerHTML='';</script>"; 21 $row11 = mysql_fetch_array($result2); 22 $id_patron=$row11['id_patron']; 23
45
dewe5
$razon_social = $row11['nombre_razon_social'];; 24 $callepatron = $row11['calle_avenida_patron']; 25 $coloniapatron = $row11['id_colonia']; 26 $numpatron = $row11['num_patron']; 27 $municipiopatron = $row11['id_municipio']; 28 $cppatron= $row11['codigo_postal']; 29 30 echo $mensaje = "<script> 31 document.getElementById('id_patron').value='$id_patron'; 32 document.getElementById('razon_social').value='$razon_social'; 33 document.getElementById('callepatron').value='$callepatron'; 34 document.getElementById('coloniapatron').value='$coloniapatron'; 35 document.getElementById('numpatron').value='$numpatron'; 36 document.getElementById('cppatron').value='$cppatron'; 37 document.getElementById('municipiopatron').value='$municipiopatron'; 38 </script>"; 39 } 40 else 41 { 42 echo $mensaje = "<script> 43 document.getElementById('e_registrop').innerHTML='Sin Informacion'; 44 document.getElementById('botonbuscar').value='2'; 45 document.getElementById('registropantronal').readOnly=true; 46 document.getElementById('razon_social').readOnly=false; 47 document.getElementById('callepatron').readOnly=false; 48 document.getElementById('coloniapatron').readOnly=false; 49 document.getElementById('numpatron').readOnly=false; 50 document.getElementById('cppatron').readOnly=false; 51 </script>"; 52 } 53
Código 3. Fragmento de código encargado de buscar y dar de alta nuevos patrones en el sistema.
46
dewe5
3.1.5. Pruebas
Caso de Prueba 1: Al ejecutar el caso de pruebas llamado “alta de usuarios”, se percató
que sus respectivas validaciones no daban ningún error, lo cual
ofrecía un buen funcionamiento en este módulo, pasando
correctamente las pruebas.
Caso de Prueba 2: Para este caso de prueba llamado “consulta, baja y modificación de
usuarios”, en el cual se realizan 3 pruebas en conjunto, una
dependiendo de la otra. Al ejecutar estos módulos los resultados
fueron positivos, otorgando un buen funcionamiento ya que se
observó la correcta funcionalidad de la consulta, e igualmente se
realizó de manera adecuada la baja y modificación, lo cual se reflejó
en la base de datos.
Caso de Prueba 3: En este caso de prueba nombrado “alta de municipio” se verificó que
se cumplieran correctamente las condiciones de entrada que fueron
establecidas, las cuales al momento de su ejecución en el software
funcionaron correctamente, sin evidenciar algún problema.
Caso de Prueba 4: “Consulta, modificación y baja de municipio” se realizó su
funcionamiento dependiendo de cada módulo anterior probado, en
lo cual al momento de su ejecución no se percató de ningún
problema, otorgando un correcto funcionamiento.
Caso de Prueba 5: El caso de prueba llamado “alta y consulta de patrón” se verificó el
correcto funcionamiento, donde no se descubrió ningún problema,
entre el manejo de ambos módulos, lo cual se ha podido comprobar
en la base de datos.
Caso de Prueba 6. Para este último caso de prueba llamado “modificación de patrón” se
realizaron correctamente las diversas pruebas de modificación de
información, verificando que funcionaran correctamente las
validaciones, lo que se puede confirmar en la base de datos, en
conclusión se obtuvo un buen funcionamiento de este módulo sin la
presencia de algún problema.
47
dewe5
Segunda iteración
3.2.1. Exploración
3.2.1.1. Historias de usuario que se utilizarán en esta segunda iteración
En esta segunda iteración, se trabará con las historias de usuarios de
detección de obra y alertas, las cuales son suma importancia para la gestión de la
información detección de obras, debido a que este módulo permitirá la
manipulación total de la información de las obras ingresadas en el sistema.
Para el desarrollo de esta iteración se estimó que se realizaría en 155
horas, la distribución de estas horas en los módulos se puede apreciar en la
siguiente tabla.
Historias de usuario Iteración Tiempo estimado Detección de obras 2 77 horas
Alertas 2 61 horas
Tabla 5. Tiempo estimado de cada historia de usuario de la segunda iteración.
3.2.1.2. Tecnología a utilizar en esta iteración
Para esta iteración se continúa trabajando con el lenguaje PHP, añadiendo
la técnica de desarrollo web conocida como Ajax, esta técnica es de suma
importancia para esta iteración, puesto que de ello dependerá el manejo más
eficiente de campos de texto, como en otros objetos más de HTML. Ajax por otro
lado se empezó aplicar con mayor frecuencia ya que permitirá crear la aplicación
más dinámica, debido a que se ejecutará del lado del cliente, mientras se mantiene
comunicación asíncrona con el servidor en segundo plano.
De igual manera, se trabajará con JQuery, esta biblioteca de JavaScrip
permitirá simplificar la manera de interactuar con el documento de HTML.
Por último, también se trabaja en esta iteración con el uso de expresiones
regulares que son definidas como una secuencia de caracteres que definen un
patrón de búsqueda, principalmente usadas en la comparación de patrones, o la
coincidencia de cadenas, es decir, “buscar y reemplazar” como operaciones, las
expresiones regulares se trabajarán en conjunto con PHP y JavaScrip, para validar
diversos campos.
48
dewe5
3.2.2. Planeación
3.2.2.1. Selección de historias de usuario
En la segunda iteración se trabajó con dos historias de usuario que son:
Detección de obras: Esta historia de usuario, se llevará el concentrado de toda
la información de detección de obras que vallan recabando en sus censos que
realicen los visitadores, se les permitirá dar de alta nuevas obras, también podrán
consultar y modificar esta información.
Alertas: En el sistema de alertas, el visitador podrá consultar que detecciones de
obras no han concluido el ingreso completo de información, principalmente el folio
SATICA1, mientras que el supervisor tendrá las opciones de consultar y modificar
diversos campos de estas alertas.
1 Servicio de Administración Tributaria de ICA (Ingenieros Civiles Asociados).
49
dewe5
3.2.3. Diseño
3.2.3.1. Historia de usuario: Detección de obras
Tarea Número de tarea: 1 Número de historia: 4 Detección de Obras
Nombre de tarea: Recolectar información
Tipo de tarea: Recopilación de información Puntos estimados: 12 horas
Fecha de inicio: 07/marzo/2016 Fecha de fin: 08/marzo/2016
Programador responsable: Jesús Sanjuan Méndez
Descripción: Recolectar la información necesaria para crear las tablas de usuarios.
La tarea 1 de la historia de usuario detección de obras, se realizó la recopilación de
información, esta se obtuvo mediante una visita al cliente el cual expuso y proporcionó la
información necesaria para realizar el correcto manejo de las detecciones de obras, esta
información proporcionada por el cliente, ayudó para la creación de las distintas tablas que se
manejarán en el sistema.
Tarea Número de tarea: 2 Número de historia: 4 Detección de Obras
Nombre de tarea: Creación de tabla
Tipo de tarea: Otra Puntos estimados: 12 horas
Fecha de inicio: 09/marzo/2016 Fecha de fin: 10/marzo/2016
Programador responsable: Jesús Sanjuan Méndez
Descripción: Diseñar y estructurar las tablas de la base de datos conforme a la información que proporcionó el cliente.
De acuerdo a la reunión que se tuvo con el cliente del sistema, y posteriormente de
analizar la información que nos proporcionó se empezó a estructurar las diversas tablas que se
usaran para el buen funcionamiento de este módulo, quedando así 6 tablas catálogo que se
pueden observar de la Figura 23 a la Figura 34 en conjunto con su correspondiente código
SQL, lo cual ayudara a comprender las características que tendrá cada una de estas tablas, ya
que estas se relacionaran con la tabla “control” (Figura 21), siendo esta tabla la más importante
para todo el sistema, ya que se enlazara con las tablas que sean creado en la primera iteración.
50
dewe5
Columna Tipo de Dato Longitud Clave Primaria Clave Foránea Descripción
num_consecutivo int 11 SI NO Identificador único de registro
id_contratista varchar 5 NO SI Identificador de contratista
num_contrato varchar 25 NO NO Número de contrato de la construcción
num_registro_obra bigint 12 NO NO Número del registro de obra
depen_contra varchar 150 NO NO Dependencia contratante
id_registro_patronal varchar 10 NO SI Identificador del número de registro
patronal
calle_avenida varchar 150 NO NO Nombre de la calle o avenida donde
encuentra la construcción
id_colonia varchar 6 NO SI Identificador de colonia donde se
encuentra la construcción
numero_exterior_interior varchar 6 NO NO Número exterior o interior de la
construcción
manzana int 6 NO NO Número de manzana donde se
encuentra la construcción
lote int 6 NO NO Número de lote donde se encuentra la
construcción
id_tipodeObra varchar 5 NO SI Identificador de tipo de obra
id_fase varchar 5 NO SI Identificador de fase de construcción
superficie int 6 NO NO Superficie de la construcción (m2)
costo_de_obra decimal 15,2 NO NO Costo de la construcción
avances tinyint 3 NO NO Nivel de avance de la construcción
fecha_inicio_obra date NO NO Fecha de inicio de la construcción
fecha_terminacion date NO NO Fecha de terminación de la construcción
num_traba int 4 NO NO Cantidad de trabajadores en la
construcción
folio_satica varchar 21 NO NO Folio de SATICA
fecha_emision_a date NO NO Fecha de emisión de Folio de SATICA
fecha_notificacion_a date NO NO Fecha de notificación de Folio de
SATICA
folio_saticb varchar 21 NO NO Folio de SATICB
fecha_emision_b date NO NO Fecha de emisión de Folio de SATICB
fecha_notificacion_b date NO NO Fecha de notificación de Folio de
SATICB
num_reporte_deteccion varchar 18 NO NO Folio de reporte de detección de obra
id_situacion varchar 5 NO SI Identificador de situación
fecha_censo date NO NO Fecha de censo
id_usuario varchar 10 NO SI Identificador de usuario
id_origen varchar 5 NO SI Identificador de origen
observaciones text NO NO Observaciones del reporte
anio_captura int 4 NO NO Año de la captura del reporte
Figura 21. Estructura de tabla SQL nombrada “control”.
51
dewe5
Figura 22. Código SQL de tabla “control”.
Columna Tipo de Dato Longitud Clave Primaria Clave Foránea Descripción
id_contratista varchar
5 SI NO Identificador unico de contratista o subcontratista
nombre varchar 15 NO NO Nombre de contratista o subcontratista
Figura 23. Estructura de tabla SQL nombrada “contratista_subcontratista”.
Figura 24. Código SQL de tabla “contratista_subcontratista”.
CREATE TABLE `control` (
`num_consecutivo` int(11) NOT NULL AUTO_INCREMENT,
`id_contratista` varchar(5) NOT NULL,
`num_contrato` varchar(25) NOT NULL,
`num_registro_obra` bigint(12) NOT NULL,
`depen_contratan` varchar(150) NOT NULL,
`id_registro_patronal` varchar(7) NOT NULL,
`calle_avenida` varchar(150) NOT NULL,
`id_colonia` varchar(6) NOT NULL,
`numero_exterior_interior` varchar(25) NOT NULL,
`manzana` int(5) NOT NULL,
`lote` int(5) NOT NULL,
`id_tipodeObra` varchar(5) NOT NULL,
`id_fase` varchar(5) NOT NULL,
`superficie` int(6) NOT NULL,
`costo_de_obra` decimal(15,2) NOT NULL,
`avances` tlnyInt(3) NOT NULL,
`fecha_inicio_obra` date NOT NULL,
`fecha_terminacion` date NOT NULL,
`num_traba` int(4) NOT NULL,
`folio_satica` varchar(21) NOT NULL,
`fecha_emision_a` date NOT NULL,
`fecha_notificacion_a` date NOT NULL,
`folio_saticb` varchar(21) NOT NULL,
`fecha_emision_b` date NOT NULL,
`fecha_notificacion_b` date NOT NULL,
`num_reporte_deteccion` varchar(18) NOT NULL,
`id_situacion` varchar(5) NOT NULL,
`fecha_censo` date NOT NULL,
`id_usuario` varchar(20) NOT NULL,
`id_origen` varchar(5) NOT NULL,
`observaciones` text NOT NULL,
`anio_captura` int(4) NOT NULL,
PRIMARY KEY (`num_consecutivo`),
FOREIGN
KEY(id_contratista,id_registro_patronal,id_colonia,id_tipodeObra,id_fase,id_situacion
,id_usuario,id_origen)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
CREATE TABLE `contratista_subcontratista` (
`id_contratista` varchar(5) NOT NULL,
`nombre` varchar(15) NOT NULL,
PRIMARY KEY (`id_contratista`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
52
dewe5
Columna Tipo de Dato Longitud Clave Primaria Clave Foránea Descripción
id_tipodeObra varchar 5 SI NO Identificador único de tipo de obra
nombretipo varchar 50 NO NO Nombre del tipo de obra
id_privacidad varchar 5 NO SI Identificador de privacidad
Figura 25. Estructura de tabla SQL nombrada “tipoobra”.
Figura 26. Código SQL de tabla “tipoobra”.
Columna Tipo de Dato Longitud Clave Primaria Clave Foránea Descripción
id_privacidad varchar 5 SI NO Identificador único de privacidad
nombrepriva varchar
10 NO NO Nombre de la privacidad de la construcción
Figura 27. Estructura de tabla SQL nombrada “privacidad”.
Figura 28. Código SQL de tabla “privacidad”
Columna Tipo de Dato Longitud Clave Primaria Clave Foránea Descripción
id_fase varchar
5 SI NO Identificador único de la fase de construcción
nombre_fase varchar 50 NO NO Nombre de la fase de la construcción
Figura 29. Estructura de tabla SQL nombrada “fase”.
Figura 30. Código SQL de tabla “fase”.
CREATE TABLE `tipoobra` (
`id_tipodeObra` varchar(5) NOT NULL,
`nombretipo` varchar(50) NOT NULL,
`id_privacidad` varchar(5) NOT NULL,
PRIMARY KEY (`id_tipodeObra`),
FOREIGN KEY(id_privacidad)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
CREATE TABLE `privacidad` (
`id_privacidad` varchar(5) NOT NULL,
`nombrepriva` varchar(10) NOT NULL,
PRIMARY KEY (`id_privacidad`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
CREATE TABLE `fase` (
`id_fase` varchar(5) NOT NULL,
`nombre_fase` varchar(50) NOT NULL,
PRIMARY KEY (`id_fase`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
53
dewe5
Columna Tipo de Dato Longitud Clave Primaria Clave Foránea Descripción
id_fase varchar
5 SI NO Identificador único de la fase de construcción
nombre_fase varchar 50 NO NO Nombre de la fase de la construcción
Figura 31. Estructura de tabla SQL nombrada “situación”.
Figura 32. Código SQL de tabla “situación”.
Columna Tipo de Dato Longitud Clave Primaria Clave Foránea Descripción
id_origen varchar 5 SI NO Identificador único de origen
nombre_fuente varchar 15 NO NO Nombre de origen
Figura 33. Estructura de tabla SQL nombrada “origen_fuente”.
Figura 34. Código SQL de tabla “origen_fuente”.
CREATE TABLE `situacion` (
`id_situacion` varchar(5) NOT NULL,
`situacion` varchar(13) NOT NULL,
PRIMARY KEY (`id_situacion`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
CREATE TABLE `origen_fuente` (
`id_origen` varchar(5) NOT NULL,
`nombre_fuente` varchar(15) NOT NULL,
PRIMARY KEY (`id_origen`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
54
dewe5
Tarea Número de tarea: 3 Número de historia: 4 Detección de Obras
Nombre de tarea: Prototipo de aplicación
Tipo de tarea: Desarrollo de interfaces Puntos estimados: 15 horas
Fecha de inicio: 11/marzo/2016 Fecha de fin: 15/marzo/2016
Programador responsable: Jesús Sanjuan Méndez
Descripción: Creación de la interfaz de manejo de la detección de obras en el sistema.
Para esta tarea, se desarrolló el prototipo de manejo de las altas, consultas y modificación
de la detección de obras, el cual quedó diseñado como se observa a continuación:
Figura 35. Prototipo de alta de detección de obras.
55
dewe5
Figura 36. Prototipo de consulta de detección de obra en sesión visitador.
56
dewe5
Figura 37. Prototipo de consulta de detección de obra en sesión supervisor.
57
dewe5
Figura 38. Prototipo de modificación de detección de obra.
58
dewe5
Tarea Número de tarea: 4 Número de historia: 4 Detección de obra
Nombre de tarea: Alta de detección de obras
Tipo de tarea: Desarrollo Puntos estimados: 22 horas
Fecha de inicio: 16/marzo/2016 Fecha de fin: 21/marzo/2016
Programador responsable: Jesús Sanjuan Méndez
Descripción: Crear el módulo el alta de detección de obras
Con esta tarea, se empezará la parte de programación de este módulo, aquí se llevará a
cabo el alta de detección de obras en el sistema.
Caso de prueba
Número Caso de prueba: 1 Número y nombre de tarea: 4.- Alta de detección de obras
Nombre de caso de prueba: Probar el alta de detección de obras
Descripción: Verificación del alta de detección de obras, con la validación de datos.
Condiciones de ejecución: 1. En la Figura 35, muestra la interfaz que visualizará el usuario al momento de dar de alta la
detección de obra en el sistema. 2. Solo se le permitirá al visitador dar el alta de detección de obras. 3. Solo el usuario con rol de visitador puede manipular este módulo de altas. 4. Para completar el alta es forzoso rellenar diversos campos los cuales se señalarán al momento
de dar de alta, pero no necesariamente todos.
Entradas: En altas: 1. Al dar de alta, el usuario debe rellenar 26 campos que son necesarios. Una vez que se termina de
rellenar, dará clic en el botón Alta. Se validará lo siguiente en cada campo, él formulario se encuentra dividido en 6 áreas:
I. Datos generales de la obra a. Número consecutivo (El sistema lo incrementa automáticamente) b. Contratista y/o Subcontrato (Necesario ingresar) c. Número de contrato (Necesario ingresar) d. Número de registro de obra (Solo acepta números, con longitud necesaria de 12) e. Dependencia contratante (Necesario ingresar)
II. Datos del patrón a. El manejo del patrón se ha explicado anteriormente en la historia de usuario Patrón.
III. Ubicación de la obra a. Calle o Avenida (Necesario ingresar) b. Municipio (Necesario ingresar)
Seleccionando el Municipio, se pasará a seleccionar la colonia y automáticamente se rellenará el código postal, dando doble clic para reiniciar la búsqueda en cualquiera de estos campos.
c. Código Postal (Necesario ingresar) Ingresando el código postal, se cargará automáticamente el municipio, solo se tendrá que seleccionar la colonia, al dar doble clic en cualquiera de estos 2 campos se reiniciará la búsqueda.
59
dewe5
d. Colonia (Necesario ingresar) e. Número (Necesario ingresar, solo permite dígitos) f. Manzana (Solo permite dígitos) g. Lote (Solo permite dígitos)
IV. Características de la obra a. Publica y/o Privada (Necesario ingresar) b. Tipo de Obra (Necesario ingresar, se activará únicamente después de seleccionar
pública o privada) c. Fase de obra (Necesario ingresar) d. Superficie (Necesario ingresar, solo permite dígitos) e. Costo de obra (Necesario ingresar únicamente si el tipo de obra es pública, acepta
números decimales, solo hasta centésimos. Al ser privado no es forzoso ingresar el costo)
f. Avances (Solo dígitos, y números entre el rango del 1 al 100) g. Fecha de inicio de obra (Solo días laborales) h. Fecha de terminación de obra (La fecha no puede ser anterior al inicio de obra) i. Número de trabajadores (Sólo dígitos)
V. Acciones de Promoción a. SATICA (Si se ingresa aceptará 2 estructuras: 2102/SATICA/201n/nnnn y 2102/EX/201n/nnnn,
donde n son dígitos) b. Fecha Emisión A (necesario ingresar, si se ingresa SATICA) c. Fecha Notificación A (La fecha notificación no puede ser anterior a la fecha de emisión) d. SATICB (Si se ingresa aceptara 2 estructuras: 2102/SATICB/201n/nnnn y 2102/EX/201n/nnnn
donde n son dígitos) e. Fecha Emisión B (necesario ingresar, si se ingresa SATICB) f. Fecha Notificación B (La fecha notificación no puede ser anterior a la fecha de emisión)
VI. Situación Actual a. Número Reporte de detección de obra (Necesario ingresar, con la estructura
2102/DET/201d/dddd, donde d son dígitos, no se permitirá ingresar un número de reporte que ya ha sido dado de alta con otro reporte de detección de obra)
b. Situación actual (Necesario ingresar) c. Fecha del censo (Necesario ingresar, solo se permite ingresar días laborables) d. Origen de fuente (Necesario ingresar) e. Nombre del censor o responsable (Seleccionado automáticamente, no es posible
cambiar) f. Observaciones
Resultado esperado: 2. Las altas que se realicen correctamente y pasen la validación de datos, se verán reflejados en la
base de datos y se mostrará una notificación de confirmación en caso de ser éxito el alta de detección de obra, seguido de su número consecutivo con el que se asignó.
Evaluaciones: Caso de prueba 7. Alta de detección de obras.
60
dewe5
Tarea Número de tarea: 5 Número de historia: 4 Detección de obra
Nombre de tarea: Consulta y modificación de detección de obras
Tipo de tarea: Desarrollo Puntos estimados: 16 horas
Fecha de inicio: 22/marzo/2016 Fecha de fin: 24/marzo/2016
Programador responsable: Jesús Sanjuan Méndez
Descripción: Crear el módulo la consulta y modificación de detección de obras
Caso de prueba
Número Caso de prueba: 2 Número y nombre de tarea: 5.-Consulta y modificación de detección de obra
Nombre de caso de prueba: Probar la consulta y modificación de detección de obra.
Descripción: Verificación del correcto funcionamiento de consulta y modificación de acuerdo a las restricciones que solicita el cliente del sistema
Condiciones de ejecución: Consultas:
1. En la Figura 37 se muestra la interfaz de detección de obra para supervisores. 2. Se mostrarán a los supervisores y visitadores la consulta de detección de obra. 3. La consulta mostrará la siguiente información a los supervisores:
1) Nombre consecutivo 2) Nombre del censor 3) Número reporte de detección de obra 4) Fecha del censo 5) Nombre o razón social 6) Registro Patronal 7) Contratista y/o subcontratista 8) Número de registro de obra 9) Calle o avenida 10) Número exterior o interior 11) Colonia 12) Municipio 13) Código postal 14) Pública o privada 15) Tipo de obra 16) Fase de obra 17) Superficie 18) Costo de obra 19) Avance 20) Número de trabajadores 21) Fecha de inicio de obra 22) Fecha de terminación de obra 23) Folio SATICA 24) Fecha de emisión SATICA 25) Fecha de notificación SATICA 26) Folio SATICB 27) Fecha de emisión SATICB
61
dewe5
28) Fecha de notificación SATICB 29) Origen 30) Situación 31) Observaciones
4. En la Figura 36, se muestra la interfaz de detección de obra para visitadores. 5. La consulta mostrará la siguiente información a los visitadores:
1) Número consecutivo 2) Número reporte detección de obra 3) Fecha del censo 4) Nombre o razón social 5) Registro patronal 6) Folio SATICA 7) Número de registro de obra 8) Situación
Modificaciones:
1. Para la realizar una modificación, es indispensable pasar antes por la consulta de detección de obras (Figura 36, Figura 37), dentro de la consulta se puede acceder a la modificación (Figura 38).
2. Lo podrán manipular los supervisores y visitadores. 3. De los resultados otorgados por la consulta de detección de obra, únicamente se seleccionará el
número consecutivo que se desea modificar su información. 4. Se ocupará las mismas tablas de alta de detección de obra, se sustituirá la información anterior
con la nueva que se ingrese en la modificación de municipios, a excepción del identificador llamado num_consecutivo, no será posible modificarlo.
5. Al modificar se tendrá las mismas restricciones como el alta de detección de obras.
Entradas: Consultas:
1. Visitador y Supervisor Solo es necesario ingresar por el menú detección de obras-> consulta detección, seleccionar los filtros de la consulta:
I. Seleccionar el usuario de quien desea obtener sus detecciones de obra (Únicamente esta opción para supervisor).
II. Por año o determinado rango de fechas. III. El orden en que desea visualizar la información.
Modificación:
1. El supervisor o visitador debe buscar el reporte de detección de obra que de desea modificar su información.
2. El supervisor tendrá la opción de ver la información de cada uno de los visitadores o toda la información en conjunto.
3. El visitador solo podrá visualizar los reportes que él tiene a su cargo. 4. Selecciona el número consecutivo del reporte a modificar y se le re-direccionará a la
página modificar (Figura 38), aparecerán los datos ya cargados en cajas de texto modificables para que sea posible editar la información anterior.
Resultado esperado: Consulta:
62
dewe5
Obtener la información de todas las detecciones de obra. Modificación:
Permitir modificar correctamente la información, cumpliendo diversas restricciones en cada campo.
Evaluaciones: Caso de prueba 8. Consulta y modificación de detección de obra.
63
dewe5
3.2.3.2. Historia de usuario: Alertas
Tarea Número de tarea: 6 Número de historia: 5 Alertas
Nombre de tarea: Recolectar información
Tipo de tarea: Recopilación de información Puntos estimados: 6 horas
Fecha de inicio: 28/marzo/2016 Fecha de fin: 28/marzo/2016
Programador responsable: Jesús Sanjuan Méndez
Descripción: Recolectar la información necesaria para crear las tablas de alertas.
En la tarea cinco, se realizó la recopilación de información, esta se obtuvo mediante una
visita al cliente el cual expuso y proporcionó la información necesaria para saber el manejo que
se la daría a las alertas de detección de obra en él sistema, esta información que proporcionó el
cliente, ayudó para la creación de las tablas y continuar con la correcta realización del módulo.
Tarea Número de tarea: 7 Número de historia: 5 Alertas
Nombre de tarea: Creación de tabla
Tipo de tarea: Otra Puntos estimados: 6 horas
Fecha de inicio: 29/marzo/2016 Fecha de fin: 29/marzo/2016
Programador responsable: Jesús Sanjuan Méndez
Descripción: Se creo la tabla de alerta en la base de datos conforme a la información que proporcionó el cliente, de esta manera se creó una tabla.
Posteriormente de recolectar la información, se creó una tabla que almacenara la
información necesaria para controlar las alertas del sistema, entre la información que guardara
esta tabla será el número consecutivo de la detección de obra que tenga la alerta. Para entender
mejor el diseño de esta tabla, se puede observar en la Figura 39 el diseño completo de la misma,
además del código SQL de creación de la tabla (Figura 40).
Columna Tipo de Dato Longitud Clave Primaria Clave Foránea Descripción
id_num_consecutivo int 11 SI NO Identificador único de alerta
observación_supervisor text NO NO Observación que hace el supervisor
accion text NO NO Observaciones de acciones a seguir
compromiso text NO NO Observaciones de tipo de compromiso
fecha_compromiso date NO NO Fecha de compromiso
id_usuario varchar 20 NO NO Identificador único de usuario
Figura 39. Estructura de tabla SQL nombrada “alertas”.
64
dewe5
Figura 40. Código SQL de la tabla “alertas”.
Tarea Número de tarea: 8 Número de historia: 5 Alertas
Nombre de tarea: Prototipo de aplicación
Tipo de tarea: Desarrollo de interfaces Puntos estimados: 10 horas
Fecha de inicio: 30/marzo/2016 Fecha de fin: 31/marzo/2016
Programador responsable: Jesús Sanjuan Méndez
Descripción: Creación de la interfaz del control de alertas.
Para esta tarea se desarrolló el prototipo del módulo de alertas, el cual quedó diseñado
como se observa a continuación:
Figura 41. Prototipo de consulta de alertas para visitadores.
CREATE TABLE `alertas` (
`id_num_consecutivo` int(11) NOT NULL,
`observacion_supervisor` text NOT NULL,
`acciones` text NOT NULL,
`compromiso` text NOT NULL,
`fecha_compromiso` date NOT NULL,
`id_usuario` varchar(20) NOT NULL,
PRIMARY KEY (`id_num_consecutivo`),
FOREIGN KEY(`id_usuario`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
65
dewe5
Figura 42. Prototipo de consulta de alertas para supervisores.
66
dewe5
Figura 43. Prototipo de modificación de alertas.
67
dewe5
Tarea Número de tarea: 9 Número de historia: 5 Alertas
Nombre de tarea: Alta de alerta
Tipo de tarea: Desarrollo Puntos estimados: 10 horas
Fecha de inicio: 01/abril/2016 Fecha de fin: 04/abril/2016
Programador responsable: Jesús Sanjuan Méndez
Descripción: Crear el módulo de alta de alerta.
Con esta tarea se empezará la parte de programación de este módulo, aquí se llevará a
cabo el alta de las alertas.
Caso de prueba
Número Caso de prueba: 3 Número y nombre de tarea: 9.- Alta de alerta
Nombre de caso de prueba: Probar el alta de alerta
Descripción: Verificación del alta de alertas, de acuerdo al alta de detección de obras
Condiciones de ejecución: 1. El alta de alertas se controlará automáticamente por el sistema, el cual dará automáticamente
el alta a la base de datos. 2. Solo los visitadores darán de alta las alertas en el sistema. 3. El alta de la alerta se realizará cuando en el alta de detección de obra (Figura 35) no se ingrese
la información del campo de SATICA.
Entradas: En altas: 1. Al no ingresar el folio SATICA en el alta de detección de obra, esta acción causará el alta de una
nueva alerta sobre ese reporte de detección de obra.
Resultado esperado: 1. Las altas que se realicen correctamente, se verán reflejados en la base de datos.
Evaluaciones: Caso de prueba 9. Alta de alerta.
68
dewe5
Tarea Número de tarea: 10 Número de historia: 5 Alertas
Nombre de tarea: Consulta de alertas
Tipo de tarea: Desarrollo Puntos estimados: 10 horas
Fecha de inicio: 05/abril/2016 Fecha de fin: 06/abril/2016
Programador responsable: Jesús Sanjuan Méndez
Descripción: Se realiza la consulta a las alertas que han sido dados de alta, reflejando esto en la interfaz del sistema.
En esta tarea se empezó a realizar la consulta de alertas del sistema, visualizando esta
información en una tabla, la cual podrán visualizar los supervisores y visitadores.
Tarea Número de tarea: 11 Número de historia: 5 Alertas
Nombre de tarea: Modificación de alertas
Tipo de tarea: Desarrollo Puntos estimados: 11 horas
Fecha de inicio: 07/abril/2016 Fecha de fin: 08/abril/2016
Programador responsable: Jesús Sanjuan Méndez
Descripción: Se realizará la modificación o actualización de la información de las alertas a la base de datos.
En esta tarea se realizará la modificación de las alertas, lo cual permitirá tomar acciones
sobre el reporte detección que tenga alerta.
Tarea Número de tarea: 12 Número de historia: 5 Alertas
Nombre de tarea: Baja de alertas
Tipo de tarea: Desarrollo Puntos estimados: 8 horas
Fecha de inicio: 11/abril/2016 Fecha de fin: 11/abril/2016
Programador responsable: Jesús Sanjuan Méndez
Descripción: Se realizará la eliminación de las alertas, en la base de datos.
En esta tarea se realiza la eliminación de alertas, de acuerdo al cumplimiento de ciertas
restricciones.
69
dewe5
Caso de prueba
Número Caso de prueba: 4 Número y nombre de tarea: 10,11,12.- Consulta, modificación y baja de alertas
Nombre de caso de prueba: Probar la consulta, modificación y baja de alertas.
Descripción: Verificación del correcto funcionamiento de consulta, modificación y baja de las alertas de acuerdo a las restricciones que solicita el cliente del sistema.
Condiciones de ejecución: Consultas:
1. En la Figura 41, se muestra la interfaz de consulta de alertas que visualizará únicamente los visitadores.
2. En la Figura 42, se muestra la interfaz de consulta de alertas que visualizara únicamente los supervisores.
3. En la consulta se visualizará los siguientes datos: a. El número consecutivo de la detección de obra que tiene la alerta. b. El número de reporte de detección. c. Días hábiles transcurridos (Únicamente los que cuente con más de 30 días) desde la
fecha de censo con la que se registró el reporte de detección. d. Acciones que se tomarán sobre el reporte de detección. e. El compromiso al que se acordó con su supervisor f. La fecha límite que tiene el visitador para ingresar los datos faltantes en el reporte de
detección. g. Nombre del supervisor, con el que ha tomado el compromiso. h. Observaciones del supervisor. i. Observaciones del reporte de detección de obra (Ingresado al momento de dar de alta
o al realizar la modificación del reporte de detección).
Modificaciones: 1. Solo podrá ser manipulado por los supervisores esta opción. 2. Para realizar una modificación, es indispensable pasar antes por la consulta de alertas (Figura
42), dentro de la consulta se puede acceder a la modificación (Figura 43). 3. Seguirá utilizándose la misma tabla (alertas), se sustituirá la información anterior con la nueva
que se ingrese en la modificación alerta, con excepción del id_num_consecutivo no será posible modificar esto dentro de la base de datos.
Bajas: 1. Solo los visitadores realizaran la baja de alertas.
Entradas: Consultas:
1. Para los visitadores la consulta de sus alertas las visualizará en cada inicio de sesión. 2. Para el supervisor, tendrá que ir a la opción Notificación Detección-> Notificación
SATICA. 3. El supervisor tendrá que seleccionar el visitador al cual desea consultar sus alertas.
Modificación:
1. El supervisor después de haber consultado y seleccionado (Figura 42), tendrá la opción de rellenar los siguientes campos:
a. Acciones
70
dewe5
b. Compromiso c. Fecha Limite de Compromiso d. Observaciones
Bajas: 1. El visitador al ingresar el folio SATICA ya sea en el alta o modificación de consulta de
obra, el sistema automáticamente dará de baja la alerta sobre ese reporte, sin la necesidad de realizar ninguna otra acción por parte del visitador.
Resultado esperado: Consulta:
• Obtener la información de todas las alertas que el visitador tiene sobre sus reportes.
• Obtener correctamente las alertas de los visitadores que seleccione el supervisor. Modificación:
Que se permita modificar correctamente la información de las alertas y se refleje en la base de datos.
Baja: Cumpliendo las restricciones de entrada de alertas, se considera exitosa la eliminación de alerta.
Evaluaciones: Caso de prueba 10. Consulta, modificación y baja de alertas.
71
dewe5
3.2.4. Codificación
3.2.4.1. Detección de obra
La codificación del alta de detección de obra es de suma de importancia, debido a que de
aquí se recopila toda la información necesaria para el desarrollo de otras tareas en el sistema.
Para ejecutar el fragmento de código que se presenta más adelante, antes se realizó la
validación de todos los campos del alta (figura 9), después el código se encargará de buscar el
identificador que se le asignará a la detección de obra (línea 1 a 11), a continuación, pueden
darse 2 casos (línea 13):
• Al ingresar un patrón que no se haya registrado con anterioridad, se buscará un
identificador para asignarle (línea 14 a 30), después se crearán 2 inserciones a la base
de datos, la primera ingresará todos los datos de la detección de obra (línea 32 a 44), en
la segunda inserción se dará de alta al nuevo patrón (línea 45 a 50) con el identificador
que se creó anteriormente.
• En el caso de que el patrón que se haya ingresado su información y ya este dado de alta,
solo se ingresaran los datos de la detección de obra (línea 54 a 66).
Al concluir con alguno de los 2 puntos anteriores, se le notificará al usuario mediante
jAlert si se ha realizó con éxito el alta (línea 68 a 93).
$sql = "SELECT num_consecutivo FROM control WHERE num_consecutivo = ( SELECT MAX( num_consecutivo 1 ) FROM control)"; 2 $result2 = mysql_query($sql); 3 while ($row11 = mysql_fetch_array($result2)) 4 { 5 $numconsecutivobasedatos=$row11['num_consecutivo']; 6 } 7 if($numconsecutivo-1!=@$numconsecutivobasedatos) 8 { 9 $numconsecutivo=$numconsecutivobasedatos+1; 10 } 11 12 if ($botonbuscar=='0' || $botonbuscar=='2') 13 { 14 for ($i = 1; $i <= 10000000; $i++) 15 { 16 $valor="PAT".$i; 17 $sql="SELECT * FROM `patron` WHERE id_patron='$valor'"; 18 $result2 = mysql_query($sql); 19 $numero_filas = mysql_num_rows($result2); 20 if ($numero_filas!=0 ) 21 { 22 $identificadorusuario= "En uso"; 23 } 24 else 25 { 26 $identificadorusuario= $valor; 27 break; 28 } 29 } 30 31
72
dewe5
$sql="INSERT INTO `control` (`num_consecutivo`, `id_contratista`, `num_contrato`, 32 `num_registro_obra`, `depen_contratan`, `id_registro_patronal`, `calle_avenida`, `id_colonia`, 33 `numero_exterior_interior`, `manzana`, `lote`, `id_tipodeObra`, `id_fase`, `superficie`, 34 `costo_de_obra`, `avances`, `fecha_inicio_obra`, `fecha_terminacion`, `num_traba`, 35 `folio_satica`, `fecha_emision_a`, `fecha_notificacion_a`, `folio_saticb`, `fecha_emision_b`, 36 `fecha_notificacion_b`, `num_reporte_deteccion`, `id_situacion`, `fecha_censo`, `id_usuario`, 37 `id_origen`, `observaciones`, `anio_captura`) VALUES ('$numconsecutivo', '$contra', 38 '$numcontrato', '$numregistroObra', '$dependencia', '$identificadorusuario', '$calle', 39 '$colonia','$numero', '$manzana', '$lote', '$tipoobra', '$fases', '$superficie', '$costo', 40 '$avances', '$fechainicio', '$fechateminacion', '$num', '$folioA', '$fechaemiA', '$fechanotA', 41 '$folioB', '$fechaemiB', '$fechanotB', '$numdeteccion', '$situacion', '$fechasenso', 42 '$nombrecensor', '$origenfuente', '$observaciones', '$numdeteccionanio');"; 43 $req = mysql_query($sql); 44 $sql3="INSERT INTO `patron` (`id_patron`, `registro_patronal`, 45 `nombre_razon_social`, `calle_avenida_patron`, `id_colonia_patron`, `num_patron`) VALUES 46 ('$identificadorusuario', '$registrop', '$razon_social', '$callepatron', '$coloniapatron', 47 '$numpatron');"; 48 $req1 = mysql_query($sql3); 49 50 } 51 else 52 { 53 $sql="INSERT INTO `control` (`num_consecutivo`, `id_contratista`, `num_contrato`, 54 `num_registro_obra`, `depen_contratan`, `id_registro_patronal`, `calle_avenida`, `id_colonia`, 55 `numero_exterior_interior`, `manzana`, `lote`, `id_tipodeObra`, `id_fase`, `superficie`, 56 `costo_de_obra`, `avances`, `fecha_inicio_obra`, `fecha_terminacion`, `num_traba`, 57 `folio_satica`, `fecha_emision_a`, `fecha_notificacion_a`, `folio_saticb`, `fecha_emision_b`, 58 `fecha_notificacion_b`, `num_reporte_deteccion`, `id_situacion`, `fecha_censo`, `id_usuario`, 59 `id_origen`, `observaciones`, `anio_captura`) VALUES ('$numconsecutivo', '$contra', 60 '$numcontrato', '$numregistroObra', '$dependencia', '$id_patron', '$calle', '$colonia', 61 '$numero', '$manzana', '$lote', '$tipoobra', '$fases', '$superficie', '$costo', '$avances', 62 '$fechainicio', '$fechateminacion', '$num', '$folioA', '$fechaemiA', '$fechanotA', '$folioB', 63 '$fechaemiB', '$fechanotB', '$numdeteccion', '$situacion', '$fechasenso', '$nombrecensor', 64 '$origenfuente', '$observaciones', '$numdeteccionanio');"; 65 $req = mysql_query($sql); 66 } 67 if($req==True and $req1==True and $req2==True ) 68 { 69 echo $mensaje = " 70 <script> 71 jAlert('Se ha Dado de alta con Numero Consecutivo: $numconsecutivo' , 'Alta 72 Exitosa',function(r) 73 { 74 if(r) 75 { 76 setTimeout(window.location='DeteccionObra',3000); 77 } 78 }); 79 </script>"; 80 } 81 else 82 { 83 echo $mensaje = " 84 <script> 85 jAlert('Error en el Sistema Intente mas Tarde' , 'Error del Sistema',function(r) 86 { 87 if(r) 88 { 89 setTimeout(window.location='DeteccionObra',3000); 90 } 91 }); 92 </script>"; 93 } 94
Código 4. Fragmento de código encargado de dar de alta nuevas detecciones de obra.
73
dewe5
3.2.4.2. Alertas
El alta de las alertas en el sistema se da en conjunto con el alta de detección de obra, en
el fragmento de código que se presenta a continuación, solo se llega a ejecutar posteriormente
de las validaciones de los campos, la alerta de las detecciones de obra, únicamente se registrará
cuando no se inserte un campo en específico, hay que recordar que este campo no es forzoso
de ingresar al momento del alta de la detección de la obra.
Para ingresar el alta de alerta, el código realiza la inserción de la detección de obra (línea
1 a 13), después se comprobará si el campo de folio SATICA se ha ingresado (línea 14), en caso
de que no se haya ingresado se procederá a realizar el alta de la alerta, insertando esta alerta a
la base de datos (línea 16 a 19), al concluir la inserción se mandará un mensaje indicando si el
proceso se ha logrado realizar con éxito (línea 23 a 49).
$sql="INSERT INTO `control` (`num_consecutivo`, `id_contratista`, `num_contrato`, 1 `num_registro_obra`, `depen_contratan`, `id_registro_patronal`, `calle_avenida`, `id_colonia`, 2 `numero_exterior_interior`, `manzana`, `lote`, `id_tipodeObra`, `id_fase`, `superficie`, 3 `costo_de_obra`, `avances`, `fecha_inicio_obra`, `fecha_terminacion`, `num_traba`, 4 `folio_satica`, `fecha_emision_a`, `fecha_notificacion_a`, `folio_saticb`, `fecha_emision_b`, 5 `fecha_notificacion_b`, `num_reporte_deteccion`, `id_situacion`, `fecha_censo`, `id_usuario`, 6 `id_origen`, `observaciones`, `anio_captura`) VALUES ('$numconsecutivo', '$contra', 7 '$numcontrato', '$numregistroObra', '$dependencia', '$id_patron', '$calle', '$colonia', 8 '$numero', '$manzana', '$lote', '$tipoobra', '$fases', '$superficie', '$costo', '$avances', 9 '$fechainicio', '$fechateminacion', '$num', '$folioA', '$fechaemiA', '$fechanotA', '$folioB', 10 '$fechaemiB', '$fechanotB', '$numdeteccion', '$situacion', '$fechasenso', '$nombrecensor', 11 '$origenfuente', '$observaciones', '$numdeteccionanio');"; 12 $req = mysql_query($sql); 13 if($folioA=='') 14 { 15 $sql2 ="INSERT INTO `obra_privada`.`alertas` (`id_num_consecutivo`, 16 `observacion_supervisor`, `acciones`, `compromiso`, `id_usuario`) VALUES('$numconsecutivo', '', 17 '', '', '');"; 18 $req2 = mysql_query($sql2); 19 $req1=True ; 20 } 21 } 22 if($req==True and $req1==True and $req2==True ) 23 { echo $mensaje = " 24 <script> 25 jAlert('Se ha Dado de alta con Numero Consecutivo: $numconsecutivo' , 'Alta 26 Exitosa',function(r) 27 { 28 if(r) 29 { setTimeout(window.location='DeteccionObra',3000); 30 } 31 }); 32 </script>"; 33 } 34 else 35 {echo $mensaje = " 36 <script> 37 jAlert('Error en el Sistema Intente mas Tarde' , 'Error del Sistema',function(r) 38 { 39 if(r) 40 { setTimeout(window.location='DeteccionObra',3000); 41 } 42 }); 43 </script>"; 44 } 45
Código 5. Fragmento de código del alta de alertas.
74
dewe5
3.2.5. Pruebas
Caso de Prueba 1: Al ejecutar el caso de pruebas llamado “alta de detección de obras,
se verificó que existiera un correcto funcionamiento de sus
validaciones, en la cual no se detectó ningún error que llevara al
mal funcionamiento de este módulo, pasando correctamente las
pruebas.
Caso de Prueba 2: Para este caso de prueba llamado “consulta y modificación de
detección de obra”, en ambos módulos sus resultados fueron
positivos, otorgando un buen funcionamiento, obteniendo
correctamente la consulta, y realizando correctamente la
modificación de la información lo cual se reflejó en la base de datos.
Caso de Prueba 3: En este caso de prueba nombrado “alta de alerta” se verificó que
cumpliera correctamente las condiciones establecidas para su
funcionamiento, las cuales al momento de su ejecución funcionaron
correctamente, sin ningún problema que se haya logrado percatar.
Caso de Prueba 4. Para este último caso de prueba llamado “consulta, modificación y
baja de alertas”, se corroboró el correcto funcionamiento, el cual se
comprobó en la base de datos, teniendo éxito y una correcta
ejecución de este módulo.
75
dewe5
Tercera iteración
3.3.1. Exploración
3.3.1.1. Historias de usuario que se utilizarán en esta tercera iteración
En esta última iteración, se trabajará con la historia de usuario llamada
reportes, la cual permitirá la descarga de reportes con la información de la obra
que se desee obtener.
Historias de usuario Iteración Tiempo estimado Reportes 3 50 horas
Tabla 6. Tiempo estimado de la última historia de usuario de la tercera iteración.
3.3.1.2. Tecnología a utilizar en esta iteración
Para esta iteración se continúa con el uso del lenguaje de programación
web PHP, al cual se le ha añadiendo PHPExcel, el cual proporciona un conjunto
de clases para este lenguaje, que nos permitirá escribir y leer de diferentes
formatos de archivo de hojas de cálculo, como Excel .xls, Excel 2007 (.xlsx). De
igual manera se utilizará PHPWord para la manipulación de documentos de texto
(.docx).
3.3.2. Planeación
3.3.2.1. Selección de historias de usuario
En la tercera iteración trabajamos una historia de usuario:
Reportes: En esta historia de usuarios se controlará el manejo de los reportes
de detección de obra para los visitadores y supervisores.
76
dewe5
3.3.3. Diseño
3.3.3.1. Historia de usuario: Reportes
Tarea Número de tarea: 1 Número de historia: 6 Reportes
Nombre de tarea: Recolectar información
Tipo de tarea: Recopilación de información Puntos estimados: 6 horas
Fecha de inicio: 13/abril/2016 Fecha de fin: 13/abril/2016
Programador responsable: Jesús Sanjuan Méndez
Descripción: Recolectar la información necesaria para crear el diseño de platillas para reportes.
La tarea uno de las historias de reportes, se realizó la recopilación de información, esta
se obtuvo mediante una visita al cliente, el cual expuso y proporcionó la información necesaria
para saber el diseño y estructura del reporte que utilizará el visitador y supervisor.
Tarea Número de tarea: 2 Número de historia: 6 Reportes
Nombre de tarea: Prototipo de reporte .xls y .docx
Tipo de tarea: Desarrollo de interfaces Puntos estimados: 10 horas
Fecha de inicio: 14/abril/2016 Fecha de fin: 15/abril/2016
Programador responsable: Jesús Sanjuan Méndez
Descripción: Diseñar las plantillas de los reportes que utilizarán los visitadores y supervisores.
De acuerdo a la reunión que se realizó con el cliente del sistema, se diseñó la plantilla en
formato .xlsx y .docx
77
dewe5
78
dewe5
Figura 44. Prototipo de reporte para visitadores.
79
dewe5
Figura 45. Prototipo de reporte para supervisor.
80
dewe5
Figura 46. Ejemplo de opción de exportación de información a Excel.
Tarea Número de tarea: 3 Número de historia: 6 Reportes
Nombre de tarea: Integración de reporte a consulta visitador
Tipo de tarea: Desarrollo Puntos estimados: 12 horas
Fecha de inicio: 18/abril/2016 Fecha de fin: 19/abril/2016
Programador responsable: Jesús Sanjuan Méndez
Descripción: Se integra el manejo de reportes de detección de obra dentro del sistema.
En esta tarea, se integra la opción de descargar del reporte de detección de obra para los visitadores.
81
dewe5
Caso de prueba
Número Caso de prueba: 1 Número y nombre de tarea: 3.- Integración de reporte en las consultas del visitador
Nombre de caso de prueba: Probar la descarga del reporte de detección de obra
Descripción: Verificación del correcto funcionamiento de la descarga del reporte para el visitador
Condiciones de ejecución: 1. En la Figura 44, se muestra el formato que obtendrá el visitador al momento de solicitar el
reporte de detección de construcción. 2. Solo podrán obtener este formato los visitadores. 3. En el área de croquis de localización se deja en blanco para que el visitador dibuje el croquis.
Entradas: 1. Para obtener el reporte de detección de construcción, es necesario pasar antes por la consulta
de reportes de detección (Figura 36). 2. Dentro de la consulta, estará la opción de descarga del reporte de detección, correspondiente
al número consecutivo de detección de obra que se desea (icono de Word).
Resultado esperado: 1. Obtener el reporte deseado con la información correspondiente al reporte de detección
seleccionado y en el orden especificado por la plantilla (Figura 44).
Evaluaciones: Caso de prueba 11. Integración de reporte en las consultas del visitador.
Tarea Número de tarea: 4 Número de historia: 6 Reportes
Nombre de tarea: Integración del reporte a consultar el supervisor
Tipo de tarea: Desarrollo Puntos estimados: 12 horas
Fecha de inicio: 20/abril/2016 Fecha de fin: 21/abril/2016
Programador responsable: Jesús Sanjuan Méndez
Descripción: Se integra el manejo de reportes de detección de obra dentro del sistema.
En esta tarea se integra la opción de descargar del reporte de detección de obra para el uso de los
supervisores.
Caso de prueba
Número Caso de prueba: 2 Número y nombre de tarea: 4.- Integración de reporte en las consultas del supervisor
Nombre de caso de prueba: Probar la descarga de reporte de detección de obra
Descripción: Verificación del correcto funcionamiento de la descarga del reporte para el supervisor.
Condiciones de ejecución: 1. En la Figura 45, se muestra el formato que obtendrá el supervisor al momento de solicitar el
reporte nombrado cédula de supervisión de obra. 2. Solo podrán obtener este formato los supervisores.
Entradas: 1. Para obtener el reporte de detección de construcción, es necesario pasar antes por la consulta
de reportes de detección (Figura 37) de supervisor. 2. Dentro de la consulta, estará la opción de descarga del reporte de detección correspondiente
al número consecutivo de detección de obra que se desea (distinguible por el icono de Excel).
82
dewe5
Resultado esperado:
1. Obtener el reporte deseado con la información correcta y en el orden especificado por la plantilla (Figura 45).
Evaluaciones: Caso de prueba 12. Integración de reportes en las consultas del supervisor.
Tarea Número de tarea: 5 Número de historia: 6 Reportes
Nombre de tarea: Integración de reportes a diversas tablas del sistema
Tipo de tarea: Desarrollo Puntos estimados: 10 horas
Fecha de inicio: 22/abril/2016 Fecha de fin: 25/abril/2016
Programador responsable: Jesús Sanjuan Méndez
Descripción: Se integra el manejo de reportes sobre las distintas tablas que entregan resultados de consultas de la base de datos.
En esta tarea se integra la opción de descargar de información en las distintas tablas de visualización de
información, para su exportación a Excel.
83
dewe5
3.3.4. Codificación
3.3.4.1. Reportes
Para obtener los reportes, es necesario ingresar a la consulta de detección de obra ya
sea visitador (figura 10) o supervisor (figura 11), al ingresar se podrá descargar mediante los
iconos de Word o Excel que se muestra al costado izquierdo.
A continuación, se muestra parte del fragmento de código que genera los reportes del
visitador. Para comenzar el código recibirá el número consecutivo de la detección de obra que
se desea obtener (línea 8), el cual se envía al dar clic sobre el icono Word, después se realizará
una consulta a la base de datos para obtener toda la información del número consecutivo (línea
9 a 10), al concluir, se empezará a extraer toda la información del resultado de la consulta (línea
11) para continuar con la asignación de los resultados a través de las correspondientes variables
(línea 13 a 57).
Para terminar, el código comenzará a rellenar con las variables la plantilla de Word (figura
16) que se ha diseñado con anterioridad (línea 60 a 91), al concluir la carga se almacenará toda
la información en el archivo de Word (.docx, línea 94) después se guardará con un nombre
asignado por el sistema (línea 97).
function consulta($tabla,$campo,$valorbusqueda,$campocompara) 1 { 2 $sql1 = "SELECT * FROM $tabla WHERE $campo ='$valorbusqueda'"; 3 $res = mysql_query($sql1); 4 $row = mysql_fetch_array($res); 5 return $row["$campocompara"]; 6 } 7 $num_con = base64_decode($_REQUEST['var']); 8 $sql = "SELECT * FROM `control` WHERE num_consecutivo ='$num_con'"; 9 $result2 = mysql_query($sql); 10 $row11 = mysql_fetch_array($result2); 11 12 $d1= substr($row11['fecha_censo'], 8, 2)."/".substr($row11['fecha_censo'], 5, 13 2)."/".substr($row11['fecha_censo'], 0, 4); 14 $d2= $row11['calle_avenida']; 15 $d3 = consulta_col_mun_cpostal($num_con,"colonia_codigo_postal"); 16 $d4 = $row11['numero_exterior_interior']; 17 $d5 = $row11['manzana']; 18 $d6 = $row11['lote']; 19 $d7 = consulta_col_mun_cpostal($num_con,"colonia_nombre_colonia"); 20 $d8= consulta_col_mun_cpostal($num_con,"colonia_nombre_colonia"); 21 $d9t = $row11['id_tipodeObra']; 22 $d9= consulta("tipoobra","id_tipodeObra","$d9t","nombretipo"); 23 $d10 = $row11['id_situacion']; 24 $d10= consulta("situacion","id_situacion","$d10","situacion"); 25 $d11= consulta("tipoobra","id_tipodeObra","$d9t","id_privacidad"); 26 $prub=consulta("privacidad","id_privacidad","$d11","nombrepriva"); 27 if(consulta("privacidad","id_privacidad","$d11","nombrepriva")=="PUBLICA") 28 { $d11 ="X"; $d11b=" "; }else{ $d11 =" "; $d11b="x"; } 29 $d12 = $row11['depen_contratan']; 30 $d13 = $row11['superficie']." m²"; 31 if("0.00" == $row11['costo_de_obra']){$d14="";}else{$d14 = "\$ ".$row11['costo_de_obra']; } 32 $d15 = $row11['id_origen']; 33 $d15= consulta("origen_fuente","id_origen","$d15","nombre_fuente"); 34
84
dewe5
$d16= substr($row11['fecha_inicio_obra'], 8, 2)."/".substr($row11['fecha_inicio_obra'], 5, 35 2)."/".substr($row11['fecha_inicio_obra'], 0, 4); 36 if("0000-00-00" == $row11['fecha_terminacion']){$d17="";} 37 else{$d17= substr($row11['fecha_terminacion'], 8, 2)."/".substr($row11['fecha_terminacion'], 5, 38 2)."/".substr($row11['fecha_terminacion'], 0, 4);} 39 $d18 = $row11['avances']; 40 $d19 = $row11['id_fase']; 41 $d19= consulta("fase","id_fase","$d19","nombre_fase"); 42 $d20t= consulta("control","num_consecutivo",$num_con,"id_registro_patronal"); 43 $d20= consulta("patron","id_patron","$d20t","nombre_razon_social"); 44 $d21=consulta("patron","id_patron","$d20t","registro_patronal"); 45 $d22 = consulta("patron","id_patron","$d20t","calle_avenida_patron"); 46 $d23t= consulta("patron","id_patron","$d20t","id_colonia_patron"); 47 $d23= consulta("colonia","id_colonia","$d23t","nombre_colonia"); 48 $d24 = consulta("patron","id_patron","$d20t","num_patron"); 49 $d25= consulta("colonia","id_colonia","$d23t","codigo_postal"); 50 $d25t= consulta("colonia","id_colonia","$d23t","id_municipio"); 51 $d26= consulta("municipios_delegaciones","id_municipio",$d25t,"nombre_municipio"); 52 $d27 = $row11['id_usuario']; 53 $d27= consultanombre("$d27"); 54 $d28 = $row11['num_registro_obra']; 55 $d29 = $row11['num_traba']; 56 $d30 = $row11['observaciones']; 57 $hoy= date("d-m-Y"); 58 // --- Asignamos valores a la plantilla 59 $templateWord->setValue('d0',$num_con); 60 $templateWord->setValue('d1',$d1); 61 $templateWord->setValue('d2',$d2); 62 $templateWord->setValue('d3',$d3); 63 $templateWord->setValue('d4',$d4); 64 $templateWord->setValue('d5',$d5); 65 $templateWord->setValue('d6',$d6); 66 $templateWord->setValue('d7',$d7); 67 $templateWord->setValue('d8',$d8); 68 $templateWord->setValue('d9',$d9); 69 $templateWord->setValue('d10',$d10); 70 $templateWord->setValue('d11',$d11); 71 $templateWord->setValue('d11b',$d11b); 72 $templateWord->setValue('d12',$d12); 73 $templateWord->setValue('d13',$d13); 74 $templateWord->setValue('d14',$d14); 75 $templateWord->setValue('d15',$d15); 76 $templateWord->setValue('d16',$d16); 77 $templateWord->setValue('d17',$d17); 78 $templateWord->setValue('d18',$d18); 79 $templateWord->setValue('d19',$d19); 80 $templateWord->setValue('d20',$d20); 81 $templateWord->setValue('d21',$d21); 82 $templateWord->setValue('d22',$d22); 83 $templateWord->setValue('d23',$d23); 84 $templateWord->setValue('d24',$d24); 85 $templateWord->setValue('d25',$d25); 86 $templateWord->setValue('d26',$d26); 87 $templateWord->setValue('d27',$d27); 88 $templateWord->setValue('d28',$d28); 89 $templateWord->setValue('d29',$d29); 90 $templateWord->setValue('d30',$d30); 91 $final=$num_con." ".$hoy; 92 // --- Guardamos el documento 93 $templateWord->saveAs('temporal.docx'); 94 95 header("Content-Disposition: attachment; 96 filename=Reporte_deteccion_".$num_con."_construccion_".$hoy.".docx; charset=iso-8859-1"); 97 echo file_get_contents('temporal.docx'); 98
Código 6. Fragmento de código encargado de generar reportes.
85
dewe5
3.3.5. Pruebas
Caso de Prueba 1: La integración del reporte en la consulta de detección de obra del
visitador realiza su funcionamiento correctamente, en lo cual no se
percató de ningún problema al momento de realizar las pruebas,
otorgando un correcto funcionamiento y descargando correctamente
el reporte.
Caso de Prueba 2: Este caso de prueba llamado “integración de reporte a consulta
supervisor” se verificó el correcto funcionamiento, donde no se
percató ningún problema, en la descarga del reporte.
86
dewe5
Capítulo IV Resultados
A continuación, en la Figura 47, se presenta el modelo entidad-relación que se realizó al recolectar toda la información necesaria para
el desarrollo del sistema, esta información se obtuvo gracias a las reuniones con el cliente, con el cual ha sido posible el modelado de
datos.
Figura 47. Modelo entidad-relación del sistema.
(1:1)
(1:n) (1:n)
(1:1)
(1:1) (1:n)
id
Fecha
Ubicación
Tipo de
obra
Superficie
m2
Propietario
de obra
id
Nombre
Sector
Profesión
Nombre
Profesión
id
Supervisor Visitadores
Reportes de detección
tiene a
su cargo
supervisa
y alerta genera
1:N
1:N
1:N
87
dewe5
4.1. Diagramas de base de datos
El diagrama de base de datos que se muestra en la Figura 48 es el resultado de la estructura de la base de datos nombrado
“obra_privada” el cual maneja todo el sistema, en el diagrama se puede apreciar la relación entre las diversas tablas que tiene la base
datos, así como los tipos de datos que ocupa.
Figura 48. Base de datos del sistema.
88
dewe5
El siguiente modelo relacional ha colaborado al modelado de la base de datos del sistema, se
espera que sea posible comprender mejor el manejo de los datos en el sistema informático que
se ha desarrollado con la ayuda de este modelo relacional.
Figura 49. Modelo relacional del sistema
89
dewe5
4.2. Integración del sistema
Para la integración final de este proyecto, no se dio tal como lo marca la metodología XP,
debido a que este proyecto se realizó únicamente por un desarrollador y no en conjunto con otros
desarrolladores, causa por la cual no existió la colaboración colectiva en este proyecto
(programación en pares), en cuanto a las demás prácticas que nos otorga la metodología son
perfectamente realizables por un solo desarrollador.
Aún, sin la existencia de la colaboración colectiva, la integración del software mediante la
metodología XP, fue de forma continua, puesto que tan pronto se completaba determinadas
tareas, estas se incorporaban en todo el sistema, llegando a integrar pequeños fragmentos de
código para la creación de nuevas versiones de los componentes del sistema, por consiguiente
se fueron verificando cada uno de los componentes por medio de pruebas unitaria y de
componente, para verificar que se cumpliera con las especificaciones, esto ayudó a evitar en la
integración final del proyecto, se tuviera que invertir grandes esfuerzos para la integración final
del sistema.
En el transcurso del desarrollo de este proyecto siempre existió una versión al día
integrada, de modo que los cambios que se realizaban siempre eran en la última versión del
sistema, esto permitía conocer las necesidades emergentes del sistema, así que esto evitó que
a futuro en la integración final se añadiera de golpe todas las mejoras, lo cual disminuyó los
esfuerzos hacia el desarrollador, evitando también llegaran a existir errores en el sistema.
90
dewe5
4.3. Entrega final
Para la entrega final del sistema, se siguieron determinados pasos para una instalación exitosa
y confiable del software.
1. Verificación de la compatibilidad: Se comprobó que los equipos de cómputo de la
institución cumplieran con los requisitos recomendados para un buen funcionamiento del
sistema, se verificó hardware y software, ya que algunos casos se puede dar la necesidad
de desinstalar versiones antiguas de software, y actualizarlas para su correcto
funcionamiento del sistema.
2. Creación de directorios requeridos: Este punto se enfocó en la instalación del servidor del
sistema, puesto que este sistema trabajará de manera local en la institución, por lo cual
se crearon las diversas rutas donde se alojará el sistema.
3. Creación de los usuarios requeridos: Se ingresaron los diversos usuarios con sus
privilegios que especificó el cliente del sistema a la base de datos, para el acceso al
sistema.
4. Copia, desempaque y descompresión de los archivos: Se ingresaron a la ruta
anteriormente creada los archivos principales, como son el código fuente, datos,
imágenes, platillas, bibliotecas y archivos de configuración.
En la configuración: Mediante los archivos de configuración, se le da a conocer al software
con que parámetros debe trabajar, en el caso del sistema se modificaron diversos
parámetros que trae por default el servidor, esto se realizó en el archivo de configuración
llamado php.ini.
5. Acceso al sistema: Se comprueba que los usuarios del sistema puedan acceder sin
ningún problema, mediante el enlace de acceso (link, liga).
6. Por último, se le proporcionará al cliente del sistema la documentación del sistema.
• Documentación técnica del desarrollo del software
• Manual de usuario
91
dewe5
4.4. Conclusiones
Al concluir con el desarrollo del sistema, se ha contribuido de manera importante el
facilitar el manejo de la información y creación de reportes de las detecciones de obra que llevan
a cabo los visitadores, esto ha sido posible gracias a la correcta adquisición de los requerimientos
del sistema.
De igual modo, dentro de los puntos que se consideramos de suma importancia para este
proyecto, fueron el detectar cuales son las necesidades reales de los visitadores que trabajan
día a día con diversos sistemas, ya que este sistema buscó apegarse a la realidad del trabajo
diario, y no que fuera un obstáculo burocrático más, dado que se llegó a involucrar a los usuarios
en el proceso de implementación del sistema, ya que de esta manera se llegó a definir lo que
ellos esperan y lo que no esperan de él, de esta manera se definió lo más claro posible los
beneficios económicos, laborales y de cualquier otra índole que se alcanzaron con este sistema,
de manera que las personas dentro del departamento de auditoria de patrones sepan cómo se
van a ver beneficiados.
Así mismo, ha sido de suma importancia el lenguaje de programación PHP en conjunto
con diversas tecnologías, debido a que permitió que el desarrollo del sistema contara con una
interfaz amigable, permitiendo desarrollar de manera adecuada todos los requerimientos que se
solicitaron por el usuario, lo cual satisface el requerimiento de ser apto para fines laborales,
además de que el resultado final fue satisfactorio para el cliente del sistema, porque permite un
manejo fácil de la información, esto se logró gracias al apoyo del cliente que permitió obtener de
manera más eficiente los requerimientos del sistema así como probar el sistemas durante las
diversas integraciones que se realizaron.
Entre las características que definen la programación extrema se incluyen las prácticas
de programación, las cuales en su mayoría se han aplicado en este proyecto para obtener un
mejor desarrollo del sistema, entre las prácticas que no han sido posibles aplicar, se encuentra
la programación en pares y propiedad colectiva debido a que solo un programador ha
desarrollado el sistema, al no lograr aplicarlas estas 2 practicas no se significa que se pierda
eficiencia para el desarrollo del mismo.
Gracias a estas prácticas de la programación extrema ha sido posible el desarrollo de
este proyecto de manera eficiente y con una reducción de errores, ya que se tuvieren presentes
durante todo el desarrollo, comenzando con la planeación incremental la cual en conjunto con la
liberación de pequeñas versiones del sistema con los requerimientos más fundamentales
92
dewe5
permitió otorgan una buena funcionalidad del sistema desde la primera iteración que se le
entrego al cliente, he incluso se trató de tener una continua comunicación con el cliente para
definir las pruebas de aceptación, la priorización de nuevos requerimiento del sistema y evaluar
las iteraciones del mismo tal como lo establece las prácticas de XP.
Hay diversas cosas que podría mencionar que se han aprendí a lo largo de este proyecto,
pero lo que considero más importante a mi parecer es más que nada llevar a cabo una buena
planeación de lo que se quiere realizar y de lo que se quiere obtener al concluir con el proyecto,
por ende se debe desarrollar una buena adquisición y análisis de requerimientos todo esto antes
de comenzar con cualquier cosa, y contemplar a futuro que existirán posibles cambios los cuales
no deberían de preocuparnos, si es que antes existió una buena planificación.
Para finalizar con una buena realización de este proyecto, se considera un punto muy
importante, dar la capacitación a los usuarios del sistema, si se realiza todo correctamente para
el desarrollo e implementación del sistema, pero no se le otorga las herramientas necesarias a
los usuarios para que trabajen con el sistema, es muy probable que todo el trabajo realizado sea
en vano y encuentren la manera de realizar sus tareas sin usarlo; haciendo que todos los
beneficios que otorgaría el sistema no solo se cumplan, sino tal vez empeoren.
93
dewe5
4.5. Recomendaciones
Para el acceso al sistema, se podrá realizar a través de un explorador web en cualquier sistema
operativo.
1. Para el inicio de sesión en el sistema, previamente se tendrán que registrar los usuarios,
esto será posible mediante el usuario con privilegios de supervisor, el cual ya ha sido
registrado por default en el momento de la entrega del software al cliente.
2. Los datos de usuario pueden ser modificados en cualquier momento por un usuario con
privilegios administrativos (supervisor).
3. Este sistema estará instalado en una computadora de escritorio que realizará la
función de servidor.
Para obtener el manual de usuario, será posible descargar al haber iniciado sesión dentro
del sistema, mediante el menú superior en la opción de ayuda, esto será posible para ambos
tipos de usuarios: supervisor o visitador.
4.5.1. Requisitos de instalación del sistema
Este sistema funcionará en un equipo de cómputo que cuente con Java Runtime
Environment (JRE) 6 o superior para ejecutar el servidor.
Environment (JDK) 6 o superior para ejecutar el servidor.
Se recomienda el uso de XAMPP como servidor, pues es necesario contar con servidor
web Apache y un sistema de gestión de base de datos Mysql, y este software cuenta
con ambos requisitos.
Requerimiento de XAMPP:
Sistema Operativo Windows 7, Windows 8 o Superior (Windows XP no soportado).
Memoria RAM de 2 Gb o Superior.
Espacio en Disco Duro 1 gb o Superior.
Procesador de 1 GHz.
Resolución mínima de pantalla 1024 x 768.
94
dewe5
4.5.2. Requisitos para el acceso al sistema desde el navegador web
La interacción con los usuarios será a través de una página en red local por medio de un
navegador web.
Se recomienda usar el navegador Google Chrome.
Sistema Operativo Windows XP SP 3 o superior, Windows 7, Windows 8 o Superior.
Memoria RAM de 2 Gb o Superior.
Espacio en Disco Duro 1 gb o Superior.
Procesador de 1 GHz.
Resolución mínima de pantalla 1024 x 768.
95
dewe5
4.6. Proyectos futuros
El sistema desarrollado para esta institución abre la posibilidad de crear nuevos sistemas
a futuro o el mejoramiento de este mismo, dado que el sistema ofrece la oportunidad de mejoras
en el manejo de más reportes que lleguen a necesitar los visitadores o supervisores.
Entre otras posibilidades que se podrían dar a partir de este proyecto es la aplicación del
diseño web adaptable lo cual optimizara el sistema para cualquier dispositivo móvil, esto para
otorgar una mejor fluidez y comodidad para los usuarios del sistema o en su caso también se
podría llegar a dar el desarrollo de una aplicación móvil.
También la administración de este sistema se podría llegar a adherir a algunos de los
sistemas que ya manejan los trabajadores, para llegar a simplificar el reingreso o cambio de
sistema constantemente para facilitarles un poco más su trabajo que realizan día a día.
Finalmente, se alienta a continuar con proyectos enfocados al desarrollo de programas
computacionales, para ser empleados en los procesos institucionales y de esta manera contribuir
a mejorar estos procesos que se realizan en estas instituciones gubernamentales.
96
dewe5
Lista bibliográfica
[1]. Academia de software libre. (07 de 03 de 2016). Manual básico de jQuery. Obtenido de
Academia de software libre: http://mundosica.github.io/tutorial_hispano_jQuery/
[2]. Ayoze Castillo, A. (2015). Curso de Programación Web JavaScrip, Ajax y jQuery. IT Campus
Academy.
[3]. BoK, S. M. (27 de abril de 2014). El manifiesto ágil - Scrum Manager BoK. Obtenido de El
manifiesto ágil - Scrum Manager BoK:
http://www.scrummanager.net/bok/index.php?title=El_manifiesto_%C3%A1gil
[4]. Cobo, A., Gómez, P., Pérez, D., & Rocha, R. (2005). PHP y MySQL Tecnologias para el desarrollo
de aplicaciones web. España: Diaz de Santos.
[5]. Dimes, T. (2015). Conceptos Basicos de Scrum. Babelcube Inc.
[6]. jQuery write less, do more. (25 de 04 de 2016). Obtenido de jQuery write less, do more:
http://jquery.com/
[7]. Kniberg , H. (2007). Scrum y XP desde las trincheras. (InfoQ.com, Ed.) Estados Unidos de
América: C4Media Inc.
[8]. Laínez Fuentes, J. R. (2014). Desarrollo de Software Agil: Extreme Programming y Scrum. (C. I.
Platform, Ed.)
[9]. Pressman , R. (2010). Ingenieria de Software. Un enfoque practico (Septima ed.). DF, Mexico: Mc
Graw Hill.
[10]. Sommerville, I. (2011). Ingenieria de Software (Septima ed.). DF, Mexico: Pearson Educacion.
