Departamento de Sistemas y Computación
“SISTEMA DE CONTROL DE SERVICIOS DE INGENIERÍA”
ANGÉLICA TLAIXCO TLATEMPA
ÁNGEL LUIS INFANTE MATOS
ASESORA DE TESIS:
M. S. C. ISABEL GUERRERO GARCÍA
VILLA DE ÁLVAREZ, COLIMA, FEBRERO 2017
TESIS PROFESIONAL
Que para obtener el Título de:
INGENIERO EN SISTEMAS COMPUTACIONALES E
INGENIERO EN INFORMÁTICA
Agradecimientos
Durante el tiempo transcurrido en esta residencia hubo muchas personas e instituciones que nos brindaron su apoyo moral, material, económica e intelectual, por lo que deseamos expresarles nuestro agradecimiento.
En primer lugar, gracias a Dios por darnos salud, sabiduría, fortaleza, y la suficiente seguridad para confiar en nosotros mismos y realizar este proyecto de vida. A nuestras familias por otorgarnos su apoyo incondicional, que sin su ayuda esto no hubiese sido posible ya que abarca en todos los aspectos, en su amor, en la economía, en los triunfos y fracasos.
Al Instituto Tecnológico de Colima por darnos la hospitalidad y la oportunidad de ser parte de este honorable plantel, y el apoyo incondicional de nuestro Director Saturnino Castro Reyes acompañado de todo su equipo de trabajo.
Gracias a nuestra maestra y asesora M. S. C. Isabel Guerrero García, por su tiempo, paciencia, conocimiento, y experiencia en el ámbito laboral, y por muchas aportaciones más, pero sobre todo por confiar en nosotros.
Un agradecimiento infinito a cada uno de nuestros maestros que formaron parte de este sueño de formarnos como unos profesionistas íntegros, ya que no cualquiera tiene ese lujo de llegar a tener este grado de estudios, pero con trabajo, dedicación, esfuerzo, todo se puede lograr en esta vida llena de oportunidades.
A la empresa Tojol Ingeniería – Valuación, por abrirnos sus puertas y formar parte de su proyecto, gracias por su hospitalidad, por el excelente ambito laboral, por la cooperación amable de los compañeros de trabajo y por el apoyo incondicional del M. V. Ing. Rogelio Miguel Maldonado Santa Cruz.
ÍNDICE GENERAL
RESUMEN ... 9
INTRODUCCIÓN... 10
CAPÍTULO I: CONTEXTO DEL PROYECTO ... 12
1.1 CONTEXTO DEL PROBLEMA ... 13
1.2 JUSTIFICACIÓN ... 15
1.3 OBJETIVOS ... 16
1.4 HIPÓTESIS ... 16
CAPÍTULO II: ESTADO DEL CAMPO DEL CONOCIMIENTO ... 18
2.1 MARCO HISTÓRICO ... 19
2. 1. 1 Antecedentes históricos de las técnicas de planeación ... 19
2. 1. 2 Definición de un proyecto de construcción ... 20
2. 1. 3 Necesidad de planear y controlar un proyecto de construcción ... 21
2. 1. 4 Administración de proyectos en la construcción... 24
2. 1. 5 Historia del avalúo en México ... 26
2.2 MARCO CONTEXTUAL ... 27
2.3 MARCO TEÓRICO ... 28
2. 3. 1 Avalúo ... 28
2. 3. 2 Servidor ... 28
2. 3. 2. 1 Tipos de servidores ... 29
2. 3. 2. 2 Apache ... 31
2. 3. 2. 3 Hostinger ... 31
2. 3. 3 Lenguajes de programación Web ... 31
2. 3. 3. 1 CSS ... 32
2. 3. 3. 2 JavaScript ... 33
2. 3. 3. 3 Bootstrap ... 33
2. 3. 3. 4 PHP ... 33
2. 3. 3. 5 Codeigniter ... 34
2. 3. 3. 6 MySQL ... 34
CAPÍTULO III: DESARROLLO DEL PROYECTO ... 35
3.1 METODOLOGÍA ... 36
3. 1. 1 SCRUM ... 36
3. 1. 1. 1 Características ... 37
3. 1. 1. 2 Herramientas y prácticas ... 37
3. 1. 1. 3 Product Backlog List ... 37
3. 1. 1. 4 Sprints ... 38
3. 1. 1. 5 Burn Down Chart ... 38
3. 1. 1. 6 Sprint Backlog ... 38
3. 1. 1. 7 Stabilization Sprints ... 39
3. 1. 1. 8 Scrum of Scrum o MetaScrum ... 39
3. 1. 1. 9 Roles y responsabilidades ... 39
3. 1. 1. 10 Product Owner ... 39
3. 1. 1. 11 ScrumMaster (o Facilitador) ... 39
3. 1. 1. 12 Equipo ... 40
3. 1. 1. 14 Stakeholders (Clientes, Proveedores). ... 40
3. 1. 1. 15 Managers ... 40
3. 1. 2 Reuniones en Scrum ... 40
3. 1. 2. 1 Daily Scrum ... 40
3. 1. 2. 2 Scrum de Scrum ... 41
3. 1. 2. 3 Reunión de Planificación del Sprint (Sprint Planning Meeting) ... 41
3. 1. 2. 4 Reunión de Revisión del Sprint (Sprint Review Meeting) ... 42
3. 1. 2. 5 Retrospectiva del Sprint (Sprint Retrospective) ... 42
3.2 ANÁLISIS DEL SISTEMA ... 43
3. 2. 1 Requerimientos del sistema... 44
3. 2. 1. 1 Funcionales ... 44
3. 2. 1. 2 No funcionales ... 44
3.3 DISEÑO ... 44
3. 3. 1 Diseño arquitectónico ... 45
3. 3. 2 Base de Datos ... 47
3. 3. 2. 1 Diagrama E-R ... 49
3. 3. 2. 2 Diccionario de datos ... 50
3. 3. 3 Clases ... 56
3. 3. 3. 1 Clase cliente ... 57
3. 3. 3. 2 Clase Avalúos ... 57
3. 3. 3. 3 Clase TableroG ... 58
3. 3. 3. 4 Clase Datos_usuario ... 58
3. 3. 3. 5 Clase Edicion_servicio ... 58
3. 3. 3. 6 Clase Estadística ... 59
3. 3. 3. 7 Clase Editar_cliente ... 61
3. 3. 3. 8 Clase Nuevo_cliente ... 61
3. 3. 3. 9 Clase Clientes ... 61
3. 3. 3. 10 Clase Comentarios ... 61
3. 3. 3. 11 Clase Gestión ... 61
3. 3. 3. 12 Clase Nuevo_avaluo ... 61
3. 3. 3. 13 Clase Consulta ... 62
3. 3. 3. 14 Clase Login ... 62
3. 3. 3. 15 Clase Inicio ... 62
3. 3. 3. 16 Clase Estadísticas ... 62
3. 3. 3. 17 Clase Registro ... 62
3. 3. 3. 18 Clase Status_avaluo ... 62
3. 3. 3. 19 Clase Edicion_servicio ... 63
3. 3. 3. 20 Clase Perfil ... 63
3. 3. 4 Usuarios ... 63
3. 3. 4. 1 Diagramas de Actores y Casos de Usos ... 63
3. 3. 4. 1. 1 Actores: Director General, Gerente Administrativo, Gerente de Área Técnica y Departamento de Informática. ... 64
3. 3. 4. 1. 2 Actores: Recepción y Control Administrativo. ... 66
3. 3. 4. 1. 3 Actores: Control de Área Técnica y Capturista. ... 67
3. 3. 4. 1. 4 Actores: Gestión 01, 02, 03 y 04. ... 67
3. 3. 4. 1. 5 Caso de Uso: Nuevo servicio. ... 68
3. 3. 4. 1. 6 Caso de Uso: Status. ... 69
3. 3. 4. 1. 7 Caso de Uso: Registro de empleados. ... 70
3. 3. 4. 1. 8 Caso de Uso: Consultas. ... 70
3. 3. 4. 1. 10 Caso de Uso: Gestión. ... 72
3. 3. 4. 1. 11 Caso de Uso: Finanzas. ... 73
3. 3. 4. 1. 12 Caso de Uso: Registro de cliente. ... 74
3. 3. 5 Clasificación del contenido ... 75
3. 3. 6 Diseño de interfaces ... 76
3.4 PROGRAMACIÓN ... 79
3. 4. 1 Del lado del controlador ... 79
3. 4. 2 Del lado del Modelo. ... 81
3. 4. 3 De lado de Vistas ... 83
3.5 MÓDULOS Y COMPONENTES ... 85
3. 5. 1 Interfaz WEB del Sistema ... 85
3. 5. 1. 1 Requerimientos ... 85
3. 5. 1. 2 Estructura ... 85
3. 5. 1. 2. 1 Principal ... 85
3. 5. 1. 2. 2 Modelo ... 85
3. 5. 1. 2. 3 Vista ... 86
3. 5. 1. 2. 4 Contenido ... 86
3. 5. 1. 2. 5 Controlador ... 87
3. 5. 2 Instalación ... 87
3. 5. 3 Base de Datos ... 88
3. 5. 4 Interfaces ... 88
3. 5. 4. 1 Inicio ... 88
3. 5. 4. 2 Administración ... 88
3. 5. 4. 3 Servicios ... 90
3. 5. 4. 4 Revisión ... 93
CAPÍTULO IV: PRUEBAS ... 98
4.1 PRUEBAS ... 99
4. 1. 1 Unidad e integración ... 99
4. 1. 2 Operación ... 99
4. 1. 3 Tensión ... 99
4. 1. 4 Congruencia ... 99
4. 1. 5 Usabilidad ... 99
4.2 RESULTADOS ... 100
4.3 INTERPRETACIÓN DE RESULTADOS ... 101
4. 3. 1 Mes de Diciembre 2016: Sucursal de Manzanillo ... 101
4. 3. 2 Mes de Diciembre 2016: Sucursal de Colima ... 102
4. 3. 3 Mes de Enero 2017: Sucursal de Manzanillo ... 103
4. 3. 4 Mes de Enero 2017: Sucursal de Colima ... 104
4. 3. 4 Gráfica del mes de Diciembre 2016: Sucursal de Manzanillo ... 107
4. 3. 5 Gráfica del mes de Diciembre 2016: Sucursal de Colima ... 107
4. 3. 6 Gráfica del mes de Enero 2017: Sucursal de Manzanillo ... 108
4. 3. 7 Gráfica del mes de Enero 2017: Sucursal de Colima ... 109
CAPÍTULO V: CONCLUSIONES Y RECOMENDACIONES ... 110
ÍNDICE DE FIGURAS
Figura 1. Un servidor. ... 28
Figura 2. Esquema "cliente-servidor". ... 29
Figura 3. Estructura central de Scrum. ... 37
Figura 4. Visión general del modelo de SCRUM (Software, 2016) ... 42
Figura 5. Interfaz del sistema. ... 43
Figura 6. Arquitectura del sistema. ... 45
Figura 7. Modelo de 3 capas. ... 46
Figura 8. Diagrama Entidad-Relación. ... 49
Figura 9. Modelo de Clases: lado del Modelo. ... 56
Figura 10. Modelo de clases: lado del controlador. ... 60
Figura 11. Actor: Director General. ... 64
Figura 12. Actor: Gerente Administrativo. ... 64
Figura 13. Actor: Gerente de Área Técnica. ... 65
Figura 14. Actor: Departamento de Informática. ... 65
Figura 15. Actor: Recepción. ... 66
Figura 16. Actor: Control Administrativo. ... 66
Figura 17. Actor: Control de Área Técnica. ... 67
Figura 18. Actor: Capturista. ... 67
Figura 19. Actor: Gestión 01. ... 67
Figura 20. Actor: Gestión 02. ... 67
Figura 21. Actor: Gestión 03. ... 68
Figura 22. Actor: Gestión 04. ... 68
Figura 23. Interfaz del inicio de sesión. ... 76
Figura 24. Interfaz de Inicio... 76
Figura 25. Módulo Administración: Registro de clientes. ... 77
Figura 26. Módulo Administración: registro de empleados. ... 77
Figura 27. Módulo Servicios: Nuevo Servicio. ... 78
Figura 28. Módulo Revisión: consultas. ... 78
Figura 29. Controlador de Login. ... 79
Figura 30. Controlador de Consultas. ... 80
Figura 31. Controlador de Gestión. ... 80
Figura 32. Modelo de avalúo. ... 81
Figura 33. Modelo de Estadísticas. ... 81
Figura 34. Modelo de Cliente. ... 82
Figura 35. Modelo de TableroG. ... 82
Figura 36. Vista de footer. ... 83
Figura 37. Vista de header. ... 83
Figura 38. Vista del Menú. ... 84
Figura 39. Inicio. ... 88
Figura 40. Registro de empleados. ... 89
Figura 41. Clientes. ... 89
Figura 43. Nuevo servicio parte 2. ... 91
Figura 44. Agregar Colonia. ... 91
Figura 45. Nuevo Cliente. ... 92
Figura 46. Extras. ... 93
Figura 47. Status de avalúos. ... 93
Figura 48. Editar servicio. ... 94
Figura 49. Primer abono. ... 95
Figura 50. Segundo abono... 95
Figura 51. Consulta. ... 96
Figura 52. Estadísticas. ... 96
Figura 53. Gestión parte 1. ... 97
Figura 54. Tablero de Gestión. ... 97
Figura 55. Gráfica del total de servicios. ... 105
Figura 56. Gráfica con el promedio de días de entrega. ... 106
Figura 57. Gráfica con el porcentaje del total de servicios. ... 106
Figura 58. Gráfica de la sucursal de Manzanillo, mes de Diciembre 2016. ... 107
Figura 59. Gráfica de la Sucursal de Colima, mes de Diciembre 2016. ... 107
Figura 60. Gráfica de la Sucursal de Manzanillo, mes de Enero 2017. ... 108
ÍNDICE DE TABLAS
Tabla 1. Tipos de servidores (García, 2006). ... 30
Tabla 2. Elementos necesarios para el sistema de control de Servicios. ... 44
Tabla 3. Conceptos de abreviaturas para tablas. ... 50
Tabla 4. Área. ... 50
Tabla 5. Tipos_Servicio ... 50
Tabla 6. Unidades_servicio. ... 50
Tabla 7. Valuación. ... 51
Tabla 8. Status_avaluos. ... 51
Tabla 9. Clientes. ... 52
Tabla 10. Cat_calle. ... 52
Tabla 11. Cat_colonias. ... 52
Tabla 12. Cat_municipios ... 53
Tabla 13. cat_estados ... 53
Tabla 14. Pagos. ... 53
Tabla 15. Tipo_pago. ... 53
Tabla 16. Det_asignación. ... 54
Tabla 17. Notificaciones. ... 54
Tabla 18. Usuarios. ... 54
Tabla 19. Cat_puestos. ... 55
Tabla 20. Cat_sucursales. ... 55
Tabla 21. Comentarios. ... 55
Tabla 22. Caso de Uso: Nuevo servicio. ... 68
Tabla 23. Caso de Uso: Status. ... 69
Tabla 24. Caso de Uso: Registro de empleados ... 70
Tabla 25. Caso de Uso: Consultas. ... 70
Tabla 26. Caso de Uso: Estadísticas. ... 71
Tabla 27. Caso de Uso: Gestión. ... 72
Tabla 28. Caso de Uso: Finanzas. ... 73
Tabla 29. Caso de Uso: Registro de cliente. ... 74
Tabla 30. Clasificación de tipos de servicios. ... 75
Tabla 31. Sucursal de Manzanillo ... 101
Tabla 32. Sucursal de Colima. ... 102
Tabla 33. Sucursal de Manzanillo. ... 103
RESUMEN
El papel que juegan los Sistemas de Control son muy importantes debido a que gracias a su implementación automatiza cualquier tipo de labor ya sea administrativa o de otra área, mejorando tiempos de producción en tiempo competente.
Para llevar a cabo este proyecto se tomó en cuenta en primera instancia aplicar una metodología que permitiera el control del mismo, para tener un orden en los procesos que se realizan para controlar los servicios de ingeniería.
INTRODUCCIÓN
Para llevar a cabo un sistema se tiene que partir de una problemática, en este caso la empresa Tojol Ingeniería – valuación realizó su petición al Instituto Tecnológico de Colima, para desarrollar un sistema que le permitiera controlar los procesos de sus valuaciones.
Para realizar un proyecto desde cero es un poco complejo debido a que hay que adaptarse a la interpretación del cliente, analizar bien lo que necesita, sin embargo al elegir este proyecto fue un gran reto, ya que es otro ambiente laboral en el que deben quedar conformes los clientes, de este parte la recomendación de uno mismo.
El objetivo principal de este proyecto es llevar un control de avance de servicios que se ofrecen en la empresa.
SERVICIOS DE VALUACIÓN: C. (RECUP)
SERVICIOS DE INGENIERÍA: PLANOS
DICTAMENES FIRMAS D.R.O MEMORIA CAL
OTROS SERVICIOS: FOTOS
CAPÍTULO I:
CONTEXTO DEL
1. 1 Contexto del problema
Actualmente la empresa Tojol Ingeniería - Valuación, cuenta con dos sucursales en el Estado de Colima, en los municipios de Manzanillo y Colima, esta última mencionada siendo la sucursal matriz, la mayor parte de estos procesos se realizan físicamente por medio de libros estilo bitácora, para registrar los servicios que se van generando por día, y apoyándose con Microsoft Excel para el registro de información extra del servicio, debido a que al solicitar un servicio este requiere documentos y más información, al comparar resultados semanales, mensuales o anuales, deben coincidir ambas partes.
Para elaborar y certificar avalúos bajo estándares altos de calidad y confiabilidad, se tienen como apoyo las páginas oficiales: Unidad de Valuación, con las siglas VIASC M.R y Consultoría en Valuación Integral, y sus respectivas siglas COVI S.A de C. V, las cuales otorgan una clave única por servicio y se realiza el pago por dar de alta dichos avalúos dependiendo del servicio es el costo.
Una vez que se tiene la clave, se genera uno internamente, que se distingue por la siguiente terminología:
“TC” Tojol Colima “TM” Tojol Manzanillo
Continuando con los datos que se necesitan para generar el servicio, se toma en cuenta la unidad de servicios que son: Covi, Viasc y tojol. El área al que pertenecen: ingeniería, valuación y otros.
1. 2 Justificación
Esta necesidad nace debido a la intensidad de información que se maneja.
Cuando un cliente solicita un servicio hay entrada de información, datos del servicio como tipo de servicio, la unidad de servicio a la que pertenece y al área que está vinculada, por otro lado información personal del cliente, nombre, apellidos, domicilio (calle, colonia, municipio y estado de la república), fecha en la que se solicitó el servicio, y no obstante la documentación como la solicitud del servicio, cédula de la visita, IFE y CURP del propietario, IFE y CURP del comprador, predial, agua, plano arquitectónico, escritura, precalificación, comprobante de antigüedad, etc.
El desarrollo de esta aplicación es con el fin de beneficiar tanto a los clientes otorgándoles el mejor servicio en el menor tiempo posible, como a los empleados que forman parte de la empresa, cada uno realiza una actividad diferente, ya sea para consultar información, dar de alta, hacer ediciones a la información existente, esto les ayuda en avanzar más rápido, cuando se genera un servicio, un equipo de trabajo está a cargo de este, y lleva a cabo diversos cambios a través de su proceso, dichos cambios realizados deben ser notificados a la persona que está al mando del servicio, en este caso el Gerente General es el que da la última palabra, si un servicio cumple con lo requerido se libera para ser archivado, en caso contrario se hacen las observaciones necesarias y se trabaja en ello, una vez que se archiva un servicio, se sigue avanzando con otro.
El proceso que se lleva en un servicio es un tanto complejo, en este caso la documentación se maneja físicamente, si hace falta un documento, se tiene que verificar en el archivo que estén completos, cabe la posibilidad que a este personal se le pase por alto alguno y se tengan problemas a futuro.
1. 3 Objetivos
A continuación se muestran los objetivos generales y específicos:
General
Crear una aplicación web que facilite la automatización en el control de servicios de ingeniería, por medio de diferentes módulos que ayuden a la empresa a tener un mejor rendimiento y de manera organizada, debido a la complejidad de los servicios que maneja.
Específicos
Analizar los requerimientos funcionales del sistema.
Analizar los formatos de entrada y salida en los procesos manuales.
Analizar y desarrollar una base de datos para los requerimientos del sistema.
Diseñar y desarrollar la interfaz para loguear usuarios.
Diseñar y desarrollar la interfaz para el control de usuarios.
Diseñar y desarrollar la interfaz para el control de clientes.
Diseñar y desarrollar la interfaz para el control de servicios de ingeniería.
Diseñar y desarrollar la interfaz para el control de pagos de servicios de ingeniería.
Diseñar y desarrollar la interfaz para el control de reportes estadísticos del sistema.
Diseñar un sistema que permita facilitar las actividades que se realizan en el área de los procesos de control de servicios.
Diseñar y desarrollar manual de usuario, manual técnico e informe técnico
Instalar el sistema y desarrollar diversas pruebas de estabilidad, usabilidad y rendimiento del sistema, con el fin de capturar errores de codificación.
Entregar al asesor externo el sistema probado y documentación necesaria para la liberación del proyecto de residencia.
1. 4 Hipótesis
Variable independiente
El desarrollo de una aplicación web para el Sistema de Control de Servicios de Ingeniería. Variable Dependiente
CAPÍTULO II: ESTADO
DEL CAMPO DEL
2. 1 Marco Histórico
2. 1. 1 Antecedentes históricos de las técnicas de planeación
Existen proyectos de tal complejidad que no basta con que el ingeniero responsable de la obra tenga en su mente todos los procesos constructivos necesarios para la realización del mismo. Es necesario plasmarlo sobre papel, y aplicar ciertas técnicas para poder llevar a cabo una planeación adecuada, así como para poder comunicarse con las demás partes involucradas en el proyecto. Ante esta necesidad surge la aplicación de diagramas de barras, la cual es una herramienta muy simple, pero que permite administrar la obra y llevar un control sobre la misma (Catarina, 2016).
Esta herramienta solo registra aspectos generales del proyecto, ya que resulta impráctico el registro de cada una de las actividades específicas en el diagrama de barras. Se agrupan diversas actividades en otras más generales que engloban procedimientos completos. Estas actividades son las que se grafican en dicho diagrama. Los primeros diagramas de barra no establecían una relación entre actividades, e incluso ya que se basaba en una simple secuencia escalonada, no dejaba claro qué actividades podrían traslaparse. Posteriormente estos diagramas se modificaron permitiendo el traslape de actividades, y señalando una relación ente una actividad y otra, lo que permitía un mejor control de la obra en proceso, y también le permitía al ingeniero optimizar procesos constructivos, o resolver problemas de manera más rápida.
De cualquier forma no es suficiente esta herramienta para establecer interrelaciones adecuadas entre una actividad y otra, no es tan fácil optimizar procesos constructivos, y lo más importante es que no permite saber qué actividades son las más importantes o las críticas del proyecto. Además de que es muy difícil de saber las restricciones de tiempo entre actividades.
En 1956, Morgan Walker de la compañía Du Pont, y James E. Kelly del grupo de planeación de la construcción interna de Remington Rand, crearon una nueva técnica de planeación y calendarización de la construcción con la finalidad de mejorar la utilidad de la computadora Univac. De esta manera se creó un método racional, secuencial y simple, que podría ser interpretado por una computadora. Esta técnica fue llamada primero el Método Walker-Kelly, y posteriormente se le llamó el Método de la Ruta Crítica, (Critical Path Method).
En 1957 la Oficina de Artillería de la Marina de los Estados Unidos desarrolló el programa POLARIS, el cual consistió en 60,000 operaciones y 3800 contratistas. Para poder coordinar e integrar este programa se desarrolló una técnica llamada Program Evaluation Review Technique, (PERT).
Tanto la Ruta Crística como el PERT han sido ampliamente usados en la industria de la construcción y su uso se ha extendido a casi todo el mundo. Se ha continuado con investigaciones en búsqueda de mejores métodos o técnicas de planeación, teniendo como resultado ciertos sistemas de control de recursos, o creación de modelos para analizar el funcionamiento de un proceso constructivo, pero la base siendo la Ruta Crítica y el PERT, los cuales son complementados con dichos sistemas y modelos.
2. 1. 2 Definición de un proyecto de construcción
Un proyecto de construcción es una infraestructura necesaria para satisfacer una necesidad pública o privada que necesita ser creada. Este proyecto consta de diferentes etapas de desarrollo. En primera instancia se tiene el estudio preliminar para delimitar la necesidad existente, y a factibilidad del mismo. Posteriormente se procede a elaborar un diseño preliminar, con el cual se puede saber de manera más clara el costo de la obra. Para finalizar, el proyecto terminado se integra de planos arquitectónicos, estructurales, y de instalaciones, así como una descripción por escrito de las especificaciones técnicas del proyecto; todo esto junto con un programa detallado de obra (Catarina, 2016).
De la misma forma, todos los proyectos de construcción se pueden y deben planear aplicando las técnicas de planeación más comunes, como por ejemplo, el diagrama de barras, la ruta crítica, diagrama de tiempo y espacio, la línea de balance, y el PERT. Dependiendo del tamaño y tipo del proyecto será la conveniencia de utilizar una u otra técnica, o incluso varias.
Para poder administrar un proyecto, es necesario primero saber el tamaño o alcance y el tipo del proyecto. Si no se tiene idea clara del tamaño real del proyecto, no es posible elaborar un presupuesto acertado, ni mucho menos una calendarización del mismo. Normalmente esta delimitación del alcance o tamaño del proyecto es elaborado por los diseñadores, quienes elaboran un presupuesto preliminar base para el cliente. Son las empresas constructoras, y específicamente los administradores de obras, quienes elaboran una calendarización y planeación precisa del proyecto con base a los planos y especificaciones elaborados por los diseñadores. En muchos de los casos, el tipo de proyecto dictaminará el tipo de método de planeación a usarse, así como su nivel de detalle.
2. 1. 3 Necesidad de planear y controlar un proyecto de construcción
En ciertos proyectos de construcción, se requieren materiales poco comerciales, los cuales deben de ser pedidos con anticipación, e incluso puede ser que algunos necesiten someterse a pruebas de calidad antes de ser utilizados. No solo aplica esto para materiales, sino también para piezas estructurales como piezas de concreto precoladas, o vigas de acero, las cuales deben de ser pedidas con anticipación y someterse a ciertas pruebas de resistencia. Muchas veces tanto los materiales como las piezas estructurales deben de ser transportadas desde el banco de extracción o lugar de fabricación según sea el caso, y se debe contemplar y por lo tanto el tiempo de traslado, y las posibles demoras. Si no se cuenta con una planeación de la obra, puede haber retrasos en la llegada del material o de las piezas prefabricadas, o por otro lado, puede haber material almacenado por mucho tiempo de forma innecesaria. Esto último implica un aumento en los costos ya que si el material no está bien almacenado o está a la intemperie pierde sus propiedades, o en caso de arena o tierra puede haber pérdidas; y además se hace una erogación de dinero en un recurso que en ese momento no es necesario, lo que afecta el flujo de efectivo de la empresa. Una situación parecida sucede con la mano de obra calificada y escasa.
Conforme pasa el tiempo, los costos de mano de obra, y los precios de los materiales y equipo se encarecen. En la mayoría de las veces, la ganancia en una obra consiste en el máximo aprovechamiento de los recursos, con la finalidad de minimizar costos. Con una buena planeación de la obra se puede determinar en primera instancia el equipo más adecuado en cuanto a operación y costo. De la misma forma se pueden mejorar procesos constructivos, que combinado con el equipo y la herramienta adecuados, minimice la cantidad de mano de obra a utilizarse. Se trata de contratar la mano de obra necesaria para cada etapa del proyecto, de tal manera que se eviten tiempos perdidos, o que se subutilice mano de obra especializada que sale casa en trabajos poco complejos.
Hacer una buena planeación permite prever ciertos sucesos desfavorables como lo son las lluvias y otros fenómenos naturales que están fuera de control del contratista. Es necesario conocer la situación climática del lugar para poder planear y organizar la obra de tal manera que la lluvia u otros eventos climáticos no interrumpan o afecten la construcción. Por último, si se cuenta con una planeación adecuada de la obra se pueden hacer correcciones por los diferentes imprevistos que puedan presentarse. Pueden surgir imprevistos por condiciones del terreno diferentes a las reportadas por los estudios preliminares. Puede ser que algún trabajador abandone repentinamente la obra, o que exista cualquier otro tipo de situación que afecte o interrumpa la obra. La planeación en la obra deber de ser continua, procurando resolver los problemas ocasionados por estos imprevistos, así como mejorar u optimizar cada etapa del proyecto conforme se va avanzando en su realización Una buena planeación ayuda a identificar riesgos potenciales.
Existen otras razones que implican una necesidad de planear un proyecto, pero estas son las más importantes a considerar. En resumen las razones por la cual la planeación es necesaria son:
Tener una comunicación efectiva entre las diferentes partes del proyecto.
Cumplir con las obligaciones contractuales.
Poder pedir y probar los materiales y piezas prefabricadas con la anticipación adecuada, lo que se denomina como administración de la calidad.
Optimizar recursos de mano de obra, materiales y equipo.
Inducir confianza sobre la buena realización del proyecto en instituciones financieras o aseguradoras.
Prever situaciones desfavorables o solucionar imprevistos de manera rápida y efectiva.
2. 1. 4 Administración de proyectos en la construcción
La administración de proyectos en la construcción consiste en administrar en forma efectiva, gente, materiales, dinero y equipo, así como elaborar una calendarización completa para terminar el proyecto en tiempo y costo. Aunado a lo anterior, establecen un método para el control del proyecto (Catarina, 2016).
El trabajo del administrador general es la gerencia de construcción, que implica en primera instancia administrar a la gente. Una de sus funciones primordiales es coordinar a las diferentes partes involucradas en el proyecto, así como delegar responsabilidades a las mismas. El administrador general no se involucra con actividades detalladas, sino que por el contrario se enfoca en los objetivos generales del proyecto que se pretenden alcanzar. Debe tratarse de una persona con la capacidad de resolver los problemas que pueden surgir durante el desarrollo de la obra, deber ser un líder que guíe en forma efectiva a todos los trabajadores a su cargo, y que cuente con una actitud de “sí se puede” que contagie esa energía positiva y pro-activa a todos los trabajadores. El administrador debe elaborar principalmente un plan en el cual basarse para organizar el proyecto. El nivel de planeación dependerá de los distintos niveles de administración de que se trate. En este caso, el administrador general está encargado de la planeación a largo plazo y a un nivel gerencia.
En general la administración de proyectos consiste de 4 funciones básicas:
Planeación
Programación
Organización
Planeación: Consiste en elaborar una especie de estrategia general para la realización del proyecto. Se construye a base de actividades generales de la obra, con la finalidad de estimar los tiempos de realización de cada una, así como las posibles limitaciones o imprevistos que pudieran surgir. Este plan servirá de guía para el desarrollo general del proyecto. En ciertas circunstancias, se recomienda planear lo planeado. Existen tres tipos de planeación en función de sus objetivos: a largo plazo, ha mediado plazo y a corto plazo.
Programación: Es la elaboración de un plan más detallado, en la que se integran las diferentes actividades específicas del proyecto. Estas actividades se ordenan de manera sistemática, y se le asigna una duración y una fecha de inicio y terminación. También se establecen relaciones entre las diferentes actividades, y las posibles restricciones existentes entre unas y otras.
Organización: Basado en la programación, se trata de organizar todos los recursos requeridos para casa proceso o actividad. Estos recursos pueden ser materiales, herramientas, mano de obra o equipo. Consiste también en la selección de personal adecuado para la realización de trabajos específicos, así como la asignación de trabajos a los diferentes trabajadores, de acuerdo a los requerimientos de la programación de obra. Control: Es tal vez de las más difíciles partes de la administración de proyectos. Consiste en elaborar un sistema de control que le permita al administrador medir, reportar y prevenir posibles variaciones en el tiempo o costo de la obra. Debido a esto, se dice que la planeación es un proceso continuo, ya que conforme se mantiene el control de la obra, es probable que en ocasiones se requiera hacer modificaciones en la programación para poder cumplir con lo establecido en el plan general. Se trata de estar al tanto de la situación de la obra, sus avances y posibles anomalías, para poder resolver problemas a tiempo.
Necesitan establecer la secuencia de actividades a realizar, como lo son investigaciones, estudios del terreno, cálculos, elaboración de planos, aprobación de los mismos, preparación de documentos de especificaciones técnicas y de instalaciones, entre otras múltiples actividades que deben de ser planeadas para evitar pérdida de tiempo o retrasos, así como posibles omisiones. En última instancia está el contratista, quién elaborará una planeación detallada, donde normalmente la escala de tiempo utilizada sea diaria, pudiendo ser mayor o menor según se requiera, para poder organizar sus recursos, y controlar en forma efectiva todo el desarrollo de la obra.
2. 1. 5 Historia del avalúo en México
Durante la época colonial después del 13 de agosto de 1521, Hernán Cortés decide construir una nueva ciudad sobre la anterior, conforme a las reglas establecidas y consagradas por la legislación española, encarga el primer plano de la ciudad a Alonso García Bravo, quién es auxiliado por Bernardino Vázquez Tapia y por dos aztecas. Este primer plano es conocido como la Traza de Cortés (Lagarda, 2009).
El repartimiento de terrenos en la ciudad de México, se hizo por donación de solares a los conquistadores y a los primeros pobladores, dentro y fuera de la traza de la ciudad, según sus méritos. El primer avalúo practicado por el Cabildo de la ciudad de México, fue el 14 de agosto de 1528, en el que le hace un libramiento de $ 44.00 oro a Rodrigo de Pontecillos, por las obras que hizo en la ciudad.
Durante el Virreinato de don Gastón de Peralta los primeros avalúos practicados por peritos designados por las autoridades, se ejecutaron en el año de 1607, con el propósito de allegarse recursos, para llevar a cabo las obras de desagüe de las aguas excedentes del valle y de la ciudad de México, en que se gravaron todas las casas de la ciudad, previo avalúo, que se encargó al Arq. Andrés de la Concha, quien declaró que el valor total de las propiedades, ascendía a la suma de $20.267,555.00, lo que produjo una contribución de $213,000.00.
Hasta entonces, a excepción de los avalúos practicados por Andrés de la Concha en 1607, los de 1629 y los de 1748 con motivo de las inundaciones, en que fueron practicados por profesionales, siguiendo el sistema de cuantificación de partidas, el resto de los bienes era tasado por el tribunal de Propios y Arbitrios, que era el encargado de fijar las rentas, tanto de los propios, que eran las tierras inalienables, cuyas rentas tenían por objeto, que los vecinos no tuvieran gravamen alguno de los gastos públicos, o al menos, que su contribución, fuera sólo para llenar el déficit.
Durante la época independiente el Síndico Primero del Ayuntamiento de la Ciudad de México, encomendó a los arquitectos don Joaquín de Heredia y don Francisco de Paula Heredia, el avalúo de los terrenos de la ciudad, los que se publicaron en la memoria económica de la municipalidad de México por orden del Excmo. Ayuntamiento, por una comisión de su seno, en 1830.
2. 2 Marco Contextual
Actualmente existen sistemas de control para diferentes áreas del mercado, aunque la finalidad de la empresa Tojol Ingeniería – Valuación, es tener un sistema propio el cual le ayude a controlar sus servicios de ingeniería y poder gestionarlos de forma local con sus correspondientes sucursales dentro del Estado de Colima. A continuación se muestra información acerca de los Sistemas de Control existentes o que tratan del mismo:
NEODATA: Es una aplicación para el proceso de control de obras o servicios, así también es una empresa mexicana que, a lo largo de 23 años se ha distinguido por ser una marca que provee software de calidad para la industria de la construcción en México (NEODATA, 2016).
Por otro lado existe una tesis que desarrolla un modelo de control de obras, el cual permite obtener la información necesaria para la toma de decisiones oportunamente, obteniendo el estado que guarda la obra en cualquier momentos, así como la documentación necesaria para la realización del pago (Uscanga, 2012).
Diseño de un sistema de control de construcción de obras de infraestructura para la Gerencia de Producción de Obras de la empresa, PROYECONSTRUCCION, CA., que permita el manejo integral de la información y una gestión eficaz de plazos, recursos y costos, ampliando de esa forma los niveles de calidad y productividad en la realización de los proyectos (Lacruz, 2009).
2. 3 Marco teórico
2. 3. 1 Avalúo
Es una estimación de valor comercial de un inmueble o artículo reflejado en cifras monetarias por medio de un dictamen técnico imparcial, a través de sus características físicas, de uso, de investigación y el análisis de mercado, tomando en cuenta las condiciones físicas y urbanas del inmueble (VALUAINM, 2012).
2. 3. 2 Servidor
Un servidor (figura 1), como la misma palabra indica, es un ordenador o máquina informática que está al “servicio” de otras máquinas, ordenadores o personas llamadas clientes y que le suministran a estos, todo tipo de información (García, 2006).
Figura 1. Un servidor.
también pueden ser otros dispositivos como ordenadores, móviles, impresoras, etc.) (García, 2006).
Por tanto básicamente tendremos el siguiente esquema general, denominado “cliente -servidor” que es uno de los más usados ya que en él se basa gran parte de internet.
Como vemos en la figura 2, tenemos una máquina servidora que se comunica con variados clientes, todos demandando algún tipo de información. Esta información puede ser desde archivos de texto, video, audio, imágenes, emails, aplicaciones, programas, consultas a base de datos, etc.
Figura 2. Esquema "cliente-servidor".
Por regla general, las máquinas servidoras suelen ser algo más potentes que un ordenador normal. Sobre todo suelen tener más capacidad tanto de almacenamiento de información como de memoria principal, ya que tienen que dar servicio a muchos clientes. Pero como todo, también depende de las necesidades, ya que podemos tener un servidor de menores prestaciones si vamos a tener pocos clientes conectados, o si los servicios que queramos en el servidor no requieren una gran capacidad servidora. A modo de ejemplo, podríamos hacer funcionar un ordenador en nuestra casa como si fuera un servidor, aunque esto no es lo más habitual. Por general, los servidores suelen estar situados en centros de datos de empresas (edificios con grandes salas dedicadas a alojar a los servidores) (García, 2006).
2. 3. 2. 1 Tipos de servidores
Tabla 1. Tipos de servidores (García, 2006).
Denominación de servidor
Descripción
Servidor de Correo Es el servidor que almacena, envía, recibe y realiza todas las operaciones relacionadas con el e-mail de sus clientes.
Servidor Proxy
Es el servidor que actúa de intermediario de forma que el servidor que recibe una petición no conoce quién es el cliente que verdaderamente está detrás de esa petición.
Servidor de Base de Datos
Da servicios de almacenamiento y gestión de bases de datos a sus clientes. Una base de datos es un sistema que nos permite almacenar grandes cantidades de información. Por ejemplo, todos los datos de los clientes de un banco y sus movimientos en las cuentas.
Servidores Clúster
Son servidores especializados en el almacenamiento de la información teniendo grandes capacidades de almacenamiento y permitiendo evitar la pérdida de la información por problemas en otros servidores.
Servidores Dedicados
Como ya expresamos anteriormente, hay servidores compartidos si hay varias personas o empresas usando un mismo servidor, o dedicados que son exclusivos para una sola persona o empresa.
Servidores de Imágenes
Recientemente también se han popularizado servidores especializados en imágenes, permitiendo alojar gran cantidad de imágenes sin consumir recursos de nuestro servidor web en almacenamiento o para almacenar fotografías personales, profesionales, etc. Algunos gratuitos pueden ser: www.imgur.com, www.photobucket.com, www.flickr.com de Yahoo, o picasaweb.google.com de Google.
Servidor Web
Almacena principalmente documentos HTML (son documentos a modo de archivos con un formato especial para la visualización de páginas web en los navegadores de los clientes), imágenes, videos, texto, presentaciones, y en general todo tipo de información. Además se encarga de enviar estas informaciones a los clientes.
2. 3. 2. 2 Apache
Es un Servidor WEB desarrollado por el grupo Apache. Su código fuente se puede distribuir y utilizar de forma libre. Está disponible para diferentes plataformas de Sistemas Operativos entre otros Windows, Linux, Mac y NetWare.
Ofrece ventajas tales como independencia de plataforma, haciendo posible el cambio de plataforma en cualquier momento; creación de contenidos dinámicos, permitiendo crear sitios mediante lenguajes PHP.
Además de ser libre su soporte técnico es accesible ya que existe una comunidad que está disponible en foros, canales IRC y servidores de noticias, donde hay gran cantidad de usuarios disponibles para cuando surge algún problema (APACHE, 2016).
2. 3. 2. 3 Hostinger
Para alojar el sitio Web http://tojol-iv.com/IBIS/ se utilizó el hosting cloud “hostinger” dependiendo del paquete son las restricciones, si se elige el gratis no se pagará nada pero como tal los accesos son limitados, el Premium ya tiene un costo mensual pero con más acceso a los diferentes servicios que dicho servidor tiene, y el empresarial es el que tiene un costo un poco más elevado pero no hay límite en los servicios que ofrece (hostinger, 2016).
2. 3. 3 Lenguajes de programación Web
El más conocido de los lenguajes de programación web es el HTML (Hiper Text Markup Language). Se puede traducir como lenguaje de marcas hipertextuales, es el lenguaje usado para crear páginas web en Internet. Este lenguaje de programación web, el HTML, codifica un documento y junto con el texto incluye unas etiquetas o marcas que le aportan información adicional sobre la forma y presentación de ese texto.
El HTML se ha convertido en uno de los lenguajes de programación web más importantes gracias a que la mayoría de los navegadores de Internet lo toleran bastante bien, es uno de los lenguajes más usados para la creación de documentos y es un lenguaje muy fácil de aprender.
SGML (Lenguaje Estándar de Marcación General) que permite colocar etiquetas o marcas en un texto para indicar como queremos que ese documento se visualice.
No es un lenguaje de programación como el Visual Basic, o el C++ que tienen compilador. Por esta razón si cometemos algún error de sintaxis, el programa no lo notará y se verá tal y como el HTML lo entienda. Para trabajar con este lenguaje de programación web, como es un procesador de texto, lo único que necesitaremos es un simple bloc de notas o cualquier otro editor de texto para comenzar a escribir el código de la página web que queramos crear.
De todas formas existen otros lenguajes de programación web que también se usan como partes o a veces acompañando o mejorando el contenido de las páginas web, entre ellos tenemos: CSS, hojas de estilo que mejoran la presentación del documento. JavaScript, lenguaje de programación web que permite darle efectos dinámicos a las páginas webs. PHP, es el más conocido y usado de los lenguajes de programación web de servidor. ASP y JSP, son dos lenguajes de programación web que actualmente están siendo muy usados. Y MySQL, lenguaje de programación para manejar bases de datos (larevistainformatica, 2015).
2. 3. 3. 1 CSS
2. 3. 3. 2 JavaScript
Es un lenguaje de programación orientado a objetos. Es un lenguaje dinámico, las variables no necesitan ser introducidas antes de su uso y los tipos de variables se resuelven dinámicamente durante su ejecución. Se trata de un lenguaje de programación del lado del cliente, porque es el navegador el que soporta la carga de procesamiento. Fue creado por Brendan Eich en la empresa Netscape Communications. El código JavaScript que se encuentra dentro de las páginas web puede ser interpretado por todos los navegadores. Permite que las definiciones de funciones y otro tipo de código sean modificados mientras el programa se esté ejecutando. El modelo de ejecución de JavaScript se basa en la interpretación del código fuente. Es un lenguaje de alto nivel, multiplataforma y no necesita compilación. Está basado en objetos, admite la programación estructurada y maneja la mayoría de los eventos que se pueden producir sobre la página web. La mayoría de los navegadores en sus últimas versiones interpretan el código JavaScript integrado dentro de las páginas web (Ecured, 2016).
2. 3. 3. 3 Bootstrap
Es un framework originalmente creado por twitter, que permite crear interfaces web con CSS y JavaScript, cuya particularidad es la de adaptar la interfaz del sitio web al tamaño del dispositivo en que se visualice. Es decir, el sitio web se adapta automáticamente al tamaño de una PC, una Tablet u otro dispositivo. Esta técnica de diseño y desarrollo se conoce como “responsive design” o diseño adaptativo (Solis, 2014).
2. 3. 3. 4 PHP
2. 3. 3. 5 Codeigniter
Es un framework para el desarrollo de aplicaciones en php que utiliza el MVC. Permite a los programadores Web mejorar la forma de trabajar y hacerlo a mayor velocidad.
Al igual que cualquier framework está pensado para gente que tiene un dominio, al menos medio, del lenguaje de programación PHP. Siempre hay que controlar PHP “a pelo” para empezar a trabajar de forma eficiente con este framework (o cualquier otro).
¿Qué es MCV?
El Modelo Vista Controlador es un estilo de programación en el que la aplicación está dividida en 3 capas:
Modelo: es dónde se procesa y obtienen los datos, la conexión con la DB. Vista: presenta los datos en pantalla, es donde va el código HTML.
Controlador: controla los datos, dicho de forma rápida obtiene datos de un modelo, los procesa, y se los pasa a la vista (Fontán, 2012).
2. 3. 3. 6 MySQL
Es un manejador de Bases de Datos, el cual permite múltiples hilos y múltiples usuarios, fue desarrollado como software libre.
Aunque se puede usar sobre varias plataformas es muy utilizado sobre LINUX. Es libre para uso en Servidores WEB.
CAPÍTULO III:
Este sistema consiste en poner en marcha un conjunto de módulos que le permitan al usuario tener un buen control sobre sus servicios.
3. 1 Metodología
A continuación se mostrará de manera detallada dicha metodología:
3. 1. 1 SCRUM
Es una metodología ágil de desarrollo, aunque surgió como modelo para el desarrollo de productos tecnológicos, también se emplea en entornos que trabajan con requisitos inestables y que requieren rapidez y flexibilidad; situaciones frecuentes en el desarrollo de determinados sistemas de software (Software, 2016).
Es una metodología de desarrollo muy simple, que requiere trabajo duro porque no se basa en el seguimiento de un plan, sino en la adaptación continua a las circunstancias de la evolución del proyecto (figura 4).
Scrum es una metodología ágil, y como tal:
Es un modo de desarrollo de carácter adaptable más que predictivo.
Orientado a las personas más que a los procesos.
Emplea la estructura de desarrollo ágil: incremental basada en iteraciones y revisiones.
Se comienza con la visión general del producto, especificando y dando detalle a las funcionalidades o partes que tienen mayor prioridad de desarrollo y que pueden llevarse a cabo en un periodo de tiempo breve (normalmente 30 días).
Cada uno de estos periodos de desarrollo es una iteración que finaliza con la producción de un incremento operativo del producto.
Figura 3. Estructura central de Scrum. 3. 1. 1. 1 Características
Equipos autodirigidos
Utiliza reglas para crear un entorno ágil de administración de proyectos.
No prescribe prácticas específicas de ingeniería.
Los requerimientos se capturan como ítems de la lista Producto Backlog.
El producto se construye en una serie de Sprints de un mes de duración.
3. 1. 1. 2 Herramientas y prácticas
Scrum no requiere ni provee prácticas de Ingeniería. En lugar de eso, especifica prácticas y herramientas de gerencia que se aplican en sus distintas fases para evitar el caos originado por la complejidad e imposibilidad de realizar predicciones.
3. 1. 1. 3 Product Backlog List
Es una lista priorizada que define el trabajo que se va a realizar en el proyecto. Cuando un proyecto comienza es muy difícil tener claro todos los requerimientos sobre el producto. Sin embargo, suelen surgir los más importantes que casi siempre son más que suficientes para un Sprint.
El objetivo es asegurar que le producto definido al terminar la lista es el más correcto, útil y competitivo posible y para esto la lista debe acompañar los cambios en el entorno y el producto.
3. 1. 1. 4 Sprints
Un sprint es un procedimiento de adaptación de las cambiantes variables del entorno (requerimientos, tiempo, recursos, conocimiento, tecnología). Son ciclos iterativos en los cuales se desarrolla o mejora una funcionalidad para producir nuevos incrementos. Durante un Sprint el producto es diseñado, codificado y probado. Y su arquitectura y diseño evolucionan durante el desarrollo.
El objetivo de un Sprint debe ser expresado en pocas palabras para que sea fácil de recordar y esté siempre presente en el equipo.
3. 1. 1. 5 Burn Down Chart
La Burn down chart es una gráfica mostrada públicamente que mide la cantidad de requisitos en el Backlog del proyecto pendientes al comienzo de cada Sprint. Dibujando una línea que conecte los puntos de todos los Sprints completados, podremos ver el progreso del proyecto. Lo normal es que esta línea sea descendente (en casos en que todo va bien en el sentido de que los requisitos están bien definidos desde el principio y no varían nunca) hasta llegar al eje horizontal, momento en el cual el proyecto se ha terminado (no hay más requisitos pendientes de ser completados en el Backlog). Si durante el proceso se añaden nuevos requisitos la recta tendrá pendiente ascendente en determinado segmentos, y si se modifican algunos requisitos la pendiente variará o incluso valdrá cero en algunos tramos.
3. 1. 1. 6 Sprint Backlog
Es el punto de entrada de cada Sprint. Es una lista que tiene los ítems de la Product Backlog List que van a ser implementados en el siguiente Sprint.
3. 1. 1. 7 Stabilization Sprints
En estos Sprints el equipo se concentra en encontrar defectos, no en agregar funcionalidad. Suelen aplicarse cuando se prepara un producto para el release. Son útiles cuando se están realizando pruebas beta, se está introduciendo a un equipo en la metodología de Scrum o cuando la calidad de un producto no alcanza los límites esperados.
No fueron definidos por Scrum pero han sido recomendados por su utilidad al aplicar esta metodología.
3. 1. 1. 8 Scrum of Scrum o MetaScrum
Los equipos de Scrum suelen tener entre 5 y 10 personas, sin embargo está metodología ha sido aplicada en proyectos que involucran más de 600 personas. Esto ha sido llevado a cabo dividiendo a los accionistas en equipos de pequeños de hasta 10 personas aproximadamente. Y definiendo jerárquicamente personas que pertenecen a dos equipos, es decir, además de su rol específico dentro de un equipo tienen el rol de enlace en un equipo superior.
3. 1. 1. 9 Roles y responsabilidades
Scrum clasifica a todas las personas que intervienen o tienen interés en el desarrollo del proyecto en: propietario del producto, equipo, gestor de Scrum (también Scrum Manager o Scrum Master) y “otros interesados”. Los tres primeros grupos (propietario, equipo y gestor) son los responsables del proyecto, los que según la comparación siguiente (y sin connotaciones peyorativas).
3. 1. 1. 10 Product Owner
El Product Owner representa la voz del cliente. Se asegura de que el equipo Scrum trabaja de forma adecuada desde la perspectiva del negocio. El Product Owner escribe historias de usuario, las prioriza, y las coloca en el Product Backlog.
3. 1. 1. 11 ScrumMaster (o Facilitador)
el líder del equipo (porque ellos se auto-organizan), sino que actúa como una protección entre el equipo y cualquier influencia que le distraiga. El ScrumMaster se asegura de que el proceso Scrum se utiliza como es debido. El ScrumMaster es el que hace que las reglas se cumplan.
3. 1. 1. 12 Equipo
El equipo tiene la responsabilidad de entregar el producto. Un pequeño equipo de 5 a 9 personas con las habilidades transversales necesarias para realizar el trabajo (diseñador, desarrollador, etc.).
3. 1. 1. 13 Usuarios
Es el destinatario final del producto. Como bien lo dice la paradoja, El árbol cae en el bosque cuando no hay nadie ¿Hace ruido? Aquí la definición sería Si el software no es usado ¿fue alguna vez escrito?
3. 1. 1. 14 Stakeholders (Clientes, Proveedores).
Se refiere a la gente que hace posible el proyecto y para quienes el proyecto producirán el beneficio acordado que lo justifica. Sólo participan directamente durante las revisiones del sprint.
3. 1. 1. 15 Managers
Es la gente que establece el ambiente para el desarrollo del producto. 3. 1. 2 Reuniones en Scrum
3. 1. 2. 1 Daily Scrum
Cada día de un sprint, se realiza la reunión sobre el estado de un proyecto. Esto se llama "daily standup". El scrum tiene unas guías específicas:
La reunión comienza puntualmente a su hora. A menudo hay castigos acordados por el equipo para quién llega tarde (por ejemplo: dinero, flexiones, etc.)
Todos los asistentes deben mantenerse de pie (esto ayuda a mantener la reunión corta) La reunión debe ocurrir en la misma ubicación y a la misma hora todos los días.
Durante la reunión, cada miembro del equipo contesta a tres preguntas:
¿Qué has hecho desde ayer?
¿Qué es lo que estás planeando hacer hoy?
¿Has tenido algún problema que te haya impedido alcanzar tu objetivo? (Es el papel del ScrumMaster recordar estos impedimentos).
3. 1. 2. 2 Scrum de Scrum
Cada día normalmente después del “Daily Scrum”
Estas reuniones permiten a los grupos de equipos discutir su trabajo, enfocándose especialmente en áreas de solapamiento e integración.
Asiste una persona asignada por cada equipo.
La agenda será la misma como del Daily Scrum, además de las siguientes cuatro preguntas:
¿Qué ha hecho tu equipo desde nuestra última reunión?
¿Qué hará tu equipo antes que nos volvamos a reunir?
¿Hay algo que demora o estorba a tu equipo?
¿Estás a punto de poner algo en el camino del otro equipo?
3. 1. 2. 3 Reunión de Planificación del Sprint (Sprint Planning Meeting)
Al inicio del ciclo Sprint (cada 15 o 30 días), una “Reunión de Planificación del Sprint” se lleva a cabo.
Seleccionar que trabajo se hará.
Preparar, con el equipo completo, el Sprint Backlog que detalla el tiempo que tomara hacer el trabajo.
Ocho horas como límite.
Al final del ciclo Sprint, dos reuniones se llevaran a cabo: la “Reunión de Revisión del Sprint” y la “Retrospectiva del Sprint”.
3. 1. 2. 4 Reunión de Revisión del Sprint (Sprint Review Meeting)
Revisar el trabajo que fue completado y no completado.
Presentar el trabajo completado a los interesados (alias “demo”).
El trabajo incompleto no puede ser demostrado.
Cuatro horas como límite.
3. 1. 2. 5 Retrospectiva del Sprint (Sprint Retrospective)
Después de cada sprint, se lleva a cabo una retrospectiva del sprint, en la cual todos los miembros del equipo dejan sus impresiones sobre el sprint recién superado. El propósito de la retrospectiva es realizar una mejora continua del proceso. Esta reunión tiene un tiempo fijo de cuatro horas.
3. 2
Análisis del sistema
Para la solución de esta problemática se requiere la implementación de un servidor web, que proporcione una plataforma estable para mostrar el software que permita la interacción con los usuarios y el funcionamiento de los diferentes módulos. Es importante recalcar que con el servidor web nos estamos refiriendo a la estructura física (computadora, conexión a internet) y a las herramientas adicionales al software desarrollado (MySql, PHP, apache).
Entre las herramientas básicas que deben ser instaladas son, un servidor HTTP (apache) con soporte para el lenguaje PHP y un servidor de base de datos como lo es MySQL. A través de esta interfaz Web los usuarios que estén permitidos a accesar podrán hacer uso del mismo, dependiendo de los cargos serán sus privilegios, ya sea consultar datos, dar de alta información, entre otras funciones más.
El funcionamiento del sistema habrán dos tipos de usuarios, que harán uso del mismo en la figura 5 se muestra, dependiendo del tipo de usuario serán las acciones que podrán realizar.
Usuarios registrados: estos serán dados de alta por el personal autorizado, ya que debe limitar algunos accesos dependiendo del cargo que lleve este usuario.
Usuario Administrador: en este caso será la persona que quede a cargo del mantenimiento del sistema, podrá ser uno o más dependiendo del gerente general, de momento sólo hay uno, este se encargará de controlar aspectos más específicos del sistema.
3. 2. 1 Requerimientos del sistema
A continuación se muestran los requerimientos del sistema funcionales y no funcionales. 3. 2. 1. 1 Funcionales
Analizar y desarrollar una Base de Datos para los requerimientos del sistema.
Diseñar y desarrollar la interfaz para loguear los usuarios.
Diseñar y desarrollar la interfaz para el control de clientes, usuarios.
Diseñar y desarrollar la interfaz para el control de servicios de ingeniería.
Diseñar y desarrollar la interfaz para el control de pagos de servicios de ingeniería.
Implantar un servidor donde se montarán los módulos.
3. 2. 1. 2 No funcionales
Implantar el sistema en las dos sucursales existentes.
Visualizarse y funcionar en cualquier navegador.
Visualizarse y funcionar correctamente en cualquier Sistema Operativo.
3. 3 Diseño
Para la implantación del servidor, se hará uso de Apache como servidor HTTP con soporte para PHP, MySQL para el almacenamiento de los datos. En la tabla 2 se muestran los elementos que se necesitan en un servidor para el funcionamiento de los módulos desarrollados.
Tabla 2. Elementos necesarios para el sistema de control de Servicios.
Nombre Versión
Apache ≥ 2.4
MyQSL Server ≥ 5.5
PHP ≥ 5.4
Sublime Text ≥ 3
JavaScript ≥ 5
3. 3. 1 Diseño arquitectónico
La estructura del sistema se muestra en la figura 6, donde los clientes harán las diferentes peticiones por medio de la interfaz Web, de manera interactiva para la pronta adaptación del usuario. Todas estas funcionalidades se apoyan sobre MySQL para el control de la informática.
Figura 6. Arquitectura del sistema.
Se hace uso del modelo de 3 capas, es la capa más completa y que se adapta al proceso que realiza una aplicación web ya que interactúa con una intensidad de información. Las aplicaciones Web están basadas en el modelo Cliente/Servidor que gestionan servidores Web, y que utilizan como interfaz páginas Web.
Las páginas Web son el componente principal de una aplicación o sitio Web. Los browsers piden páginas (almacenadas o creadas dinámicamente) con información a los servidores Web. En algunos ambientes de desarrollo de aplicaciones Web, las páginas contienen código HTML y scripts dinámicos, que son ejecutados por el servidor antes de entregar la página.
a la interfaz de usuarios y a los datos, esta capa intermedia centraliza la lógica de negocio, haciendo la administración más sencilla, los datos se pueden integrar de múltiples fuentes, las aplicaciones Web actuales se ajustan a este modelo.
Figura 7. Modelo de 3 capas.
Las capas de este modelo son (figura 7):
1. Capa de presentación (parte en el cliente y en el servidor)
Recoge la información del usuario y la envía al servidor (cliente)
Manda información a la capa de proceso para su procesado
Recibe los resultados de la capa de proceso
Generan la presentación
Visualizan la presentación al usuario (cliente) 2. Capa de proceso (servidor Web)
Recibe la entrada de datos de la capa de presentación
Interactúa con la capa de datos para realizar operaciones
Manda los resultados procesados a la capa de presentación 3. Capa de datos (servidor de datos)
Almacena los datos
Recupera datos
Mantiene los datos
3. 3. 2 Base de Datos
La base de datos consta de un conjunto de tablas que utilizan el motor InnoDB, con un CHARSET utf-8 para de esta forma ampliar el conjunto de símbolos y caracteres permitidos para su almacenaje, y un COLLATION utf-8 default collation, sin embargo este último podría cambiar de acuerdo a las necesidades de búsqueda. En la figura 8, se muestra la estructuración de los datos para su uso con los diferentes módulos del sistema, básicamente se compone de 18 elementos:
Área: Esta estructura contiene las áreas principales de los servicios, que en este caso son; “Ingeniería”, “Valuación” y “Otros”. Se muestra en la tabla 4.
Tipos_Servicio: Esta estructura se almacenan los servicios que promueve la empresa Tojol, como se muestra en la tabla 5.
Unidades_servicio: Se almacenan las unidades de servicios, como se muestra en la tabla 6.
Valuación: Es la estructura central, en el cual se almacena la información de las valuaciones, como se muestra en la tabla 7.
Status_avaluos: En esta estructura se almacenarán los diferentes status que presentarán los avalúos, como se muestra en la tabla 8.
Clientes: Se almacenarán los datos de los clientes que se irán registrando, como se muestra en la tabla 9.
Cat_calle: Esta estructura es un catálogo de calles, debido a la intensidad de información se almacena en éste, como se muestra en la tabla 10.
Cat_colonias: Al igual que el catálogo de calles, se generó otro de colonias, como se muestra en la tabla 11.
Cat_municipios: También el catálogo de los municipios, como se muestra en la
tabla 12.
Pagos: Este detalle se generó debido a que se necesita un control de los pagos, como se muestra en la tabla 14, y en qué avalúo se genera.
Tipo_pagos: En esta estructura se mantendrá un catálogo de los tipos de pagos, como se muestra en la tabla 15.
Det_asignación: En este detalle se hace una fusión de las notificaciones en la que irán haciendo los usuarios de cada valuación, como se muestra en la tabla 16. Notificaciones: Se almacenará información acerca de las notificaciones que se
realicen ya sea una modificación a las valuaciones, como se muestra en la tabla 17, con la fecha y de más información.
Usuarios: Este es para tener un control de los usuarios, ya que de esta manera se podrá ver a qué sucursal pertenece, como se muestra en la tabla 18, y de esta manera ver los comentarios que se realizan.
Cat_puestos: Este es para mantener una relación de los puestos que existen y qué usuario pertenece a dicho puesto, como se muestra en la tabla 19.
Cat_sucursal: Este es para controlar las sucursales, actualmente se cuenta con 2, pero a futuro puede que existan más, y de esta manera se almacenan, como se muestra en la tabla 20.
3. 3. 2. 1 Diagrama E-R
3. 3. 2. 2 Diccionario de datos
A continuación se muestra el diccionario de datos de cada tabla que se utilizarán en el proyecto. Tabla 3. Conceptos de abreviaturas para tablas.
CP (Llave primaria) FK (Clave Foránea) NN (No nulo) BIN (Binario) Un (Sin signo)
UQ (Crear / remover llave única)
ZF (Rellenar con ceros)
AI (Autoincre-mentable)
Tabla 4. Área.
Campo Tipo CP FK NN UQ BIN UN ZF AI Default Descripción
Id_area Int (11) x x Identificador único del área.
Nomb_area Varchar (30) x x Nombre del área (Ingeniería, Valuación, Otros).
Tabla 5. Tipos_Servicio
Campo Tipo CP FK NN UQ BIN UN ZF AI Default Descripción
Id_tip_serv Int (11) x x x Identificador único de Tipos_Servicio.
Nomb_tip_serv Varchar (40) x Nombre de Tipos_servicio como; Dictámenes, Planos, etc. Id_area Int (11) x x Identificador único del área.
Id_unid_servicio Int (11) x x Identificador único de unidad de servicios.
Tabla 6. Unidades_servicio.
Campo Tipo CP FK NN UQ BIN UN ZF AI Default Descripción
Id_unid_servicio Int (11) x x x Identificador único de unidad de servicios.
