borra dor 11012013 con 29
DESCRIPTION
Ejemplo de tesis de sistemas de información para obtener el titulo de licenciado en Ingeniería de SistemasTRANSCRIPT
Tabla de contenido1. INTRODUCCIÓN.................................................................................................................................1
2. ANTECEDENTES.................................................................................................................................23. SITUACIÓN PROBLEMATICA..........................................................................................................3
4. PLANTEAMIENTO DEL PROBLEMA..............................................................................................45. OBJETO DE ESTUDIO........................................................................................................................4
6. OBJETIVOS..........................................................................................................................................46.1 OBJETIVO GENERAL.......................................................................................................................4
6.2 OBJETIVOS ESPECÍFICOS...............................................................................................................47. CAMPO DE ACCIÓN...........................................................................................................................5
8. IDEA A DEFENDER............................................................................................................................59. CRITERIO DE EVALUACIÓN............................................................................................................5
10. JUSTIFICACIÓN...............................................................................................................................510.1 JUSTIFICACIÓN TÉCNICA............................................................................................................5
10.2 JUSTIFICACIÓN ECONÓMICA.....................................................................................................511. ALCANCES.......................................................................................................................................6
12. LIMITACIONES................................................................................................................................613. APORTES...........................................................................................................................................6
14. INGENIERÍA DEL PROYECTO......................................................................................................61.1 SISTEMA DE INFORMACION........................................................................................................8
1.2 INGENIERIA WEB...........................................................................................................................81.3 SERVICIO WEB................................................................................................................................8
1.4 RENDIMIENTO EN MAQUINAS DE CONSTRUCCION.............................................................91.5 PROTOCOLO TCP / IP.....................................................................................................................9
1.6 PROTOCOLO HTTP.........................................................................................................................91.7 ARQUITECTURA CLIENTE SERVIDOR.....................................................................................10
1.7.1 CLIENTE........................................................................................................................................101.7.2 SERVIDOR.....................................................................................................................................10
1.7.3 ARQUITECTURA..........................................................................................................................101.8 MODELO VISTA CONTROLADOR (MVC)......................................................................................11
1.9 PHP.........................................................................................................................................................121.10 SISTEMA GESTOR DE BASE DE DATOS MySQL........................................................................12
1.10.1 CARACTERISTICAS...................................................................................................................131.10.2 VENTAJAS...................................................................................................................................13
1.11 FRAMEWORK CODEIGNITER........................................................................................................131.11.1 DIAGRAMA DE FLUJO DE LA APLICACIÓN........................................................................14
i
1.12 HTML...................................................................................................................................................141.13 JAVASCRIPT.......................................................................................................................................15
1.14 CSS.......................................................................................................................................................151.15 LENGUAJE UNIFICADO DE MODELADO.....................................................................................15
1.16 UML ENTORNO WEB.......................................................................................................................161.16.1 ESTEREOTIPOS PARA CLASES...............................................................................................16
1.16.2 ESTEREOTIPOS PARA RELACIONES.....................................................................................171.17 METODOLOGIA DEL PROYECTO: PROCESO UNIFICADO RATIONAL.................................17
1.17.1 ANTECEDENTES DEL RUP......................................................................................................181.17.2 RUP COMO PROCESO DE DESARROLLO.............................................................................18
1.17.3 FASES DE DESARROLLO DEL SOFTWARE..........................................................................181.17.4 COMO FILOSOFÍA RUP MANEJA 6 PRINCIPIOS CLAVE...................................................22
1.17.5 CARACTERÍSTICAS ESENCIALES QUE DEFINEN AL RUP...............................................231.17.6 ALCANCE DE LA METODOLOGÍA RUP................................................................................24
1.18 RUP AGIL............................................................................................................................................241.19 LA ORGANIZACION.........................................................................................................................24
1.19.1 ORGANIGRAMA DEL PROYECTO..........................................................................................241.19.2 CONCEPTOS BASICOS DE LA ORGANIZACIÓN.................................................................25
2.1 MODELADO DEL NEGOCIO..............................................................................................................272.1.1 DIAGRAMA DE CASOS DE USO DEL NEGOCIO....................................................................27
2.1.2 ESPECIFICACION DE LOS ACTORES DEL NEGOCIO...........................................................282.1.2 ESPECIFICACION DE LOS CASOS DE USO DEL NEGOCIO.................................................30
2.1.3. DIAGRAMA DE OBJETOS DEL NEGOCIO..............................................................................342.1.3.1. CASO DE USO: REALIZA TRAMO....................................................................................34
2.1.3.2. CASO DE USO: CONTROLA AVANCE.............................................................................342.1.3.3. CASO DE USO: REALIZA LIQUIDACION........................................................................35
2.1.3.4. CASO DE USO: COORDINA TAREAS...............................................................................352.1.3.5. CASO DE USO: EJECUTA TRABAJO................................................................................36
2.1.3.6. CASO DE USO: COOORDINA TRABAJOS.......................................................................372.2 METODO VORD...................................................................................................................................37
2.3 ANALISIS DE REQUISITOS – DESARROLLO DEL METODO VORD..........................................382.3.1 IDENTIFICACIÓN DE LOS PUNTOS DE VISTA.....................................................................38
2.3.2 REQUERIMIENTOS FUNCIONALES.........................................................................................392.3.3 JERARQUÍA DE PUNTOS DE VISTA.........................................................................................40
2.3.4 REQUERIMIENTOS FUNCIONALES.........................................................................................402.3.5 REQUERIMIENTOS NO FUNCIONALES..................................................................................41
3.1. MODELO DE CASOS DE USO DEL SISTEMA................................................................................423.1.1. DIAGRAMA DE CASOS DE USO: PAQUETE VALIDAR USUARIO...................................43
ii
3.1.2. DIAGRAMA DE CASOS DE USO: PAQUETE ADMINISTRADOR........................................433.1.3. DIAGRAMA DE CASOS DE USO: PAQUETE RESIDENTE...................................................43
3.1.4. DIAGRAMA DE CASOS DE USO: PAQUETE ALMACENES.................................................443.2 DESCRIPCION DE ACTORES.............................................................................................................44
3.3. ESPECIFICACIÓN DE CASOS DE USO DEL SISTEMA.................................................................464.1 DIAGRAMA DE INTERACCION........................................................................................................59
4.1.1 DIAGRAMA DE SECUENCIA.....................................................................................................594.1.2 DIAGRAMA DE COLABORACION............................................................................................63
4.2 DIAGRAMA DE CLASES PERSISTENTE PARA LA BASE DE DATOS.......................................664.3 MODELO RELACIONAL.....................................................................................................................68
4.4 ESTRUCTURA DE LA BASE DE DATOS..........................................................................................695.1. DIAGRAMA DE COMPONENTES....................................................................................................74
5.2 DIAGRAMA DE DESPLIEGUE...........................................................................................................745.3 PRESENTACION DE INTERFACES...................................................................................................75
6.1 ESTIMACIÓN DE SOFTWARE BASADA EN PUNTOS DE CASOS DE USO...............................876.2.1 CLASIFICACIÓN DE LOS ACTORES INVOLUCRADOS........................................................87
6.2.2 CLASIFICACIÓN DE CASO DE USO.........................................................................................876.2.3 FACTOR DE COMPLEJIDAD TÉCNICA DEL PROYECTO DE SOFTWARE........................87
6.2.4 FACTORES DE ENTORNO DEL PROYECTO.........................................................................886.3 CALCULO DEL COSTO DEL SISTEMA............................................................................................88
6.3.1 CLASIFICACIÓN DE LOS ACTORES DEL SISTEMA..............................................................886.3.2 CLASIFICACIÓN DE LOS CASOS DE USO DEL SISTEMA....................................................89
6.3.3 CÁLCULOS DE LOS PUNTOS DE CASOS DE USO SIN AJUSTAR.......................................896.3.4 DETERMINACIÓN DEL FACTOR DE COMPLEJIDAD TÉCNICA (TCF)..............................90
6.3.5 DETERMINACIÓN DEL FACTOR AMBIENTE........................................................................906.3.6 CALCULO DE LOS PUNTOS DE CASOS DE USO AJUSTADOS...........................................91
6.3.7 CALCULO DEL ESFUERZO........................................................................................................917.1 SEGURIDAD DEL SISTEMA..............................................................................................................92
7.2 PRUEBAS DE CAJA NEGRA..............................................................................................................937.2.1 CASO DE PRUEBA: ACCESO AL SISTEMA.............................................................................93
3.3 PRUEBA DE ACEPTACION DEL SISTEMA...............................................................................953.3.1 MÉTODO DE ESCALAMIENTO DE LIKERT.....................................................................95
3.3.2 EVALUACION DEL SISTEMA.............................................................................................963.3.3 RESULTADOS DE LA EVALUACIÓN................................................................................97
3.3.4 CONCLUSION DE LA EVALUACIÓN.................................................................................98
iii
RESUMEN
La Empresa constructora COMSCOR SRL (CONSTRUCTORA MULTIDICIPLINARIA DE
SERVICIOS CORIA), tiene la misión de desarrollar la integración Nacional, ejecuta proyectos
de saneamiento urbano y equipamiento de infraestructura caminera. El área técnica de la empresa
recibe diariamente información del rendimiento del equipo pesado, por ser esta de forma manual
presenta deficiencias en cuanto al registro de datos, duplicidad de información, pérdida de
reportes, etc. Ocasionando retrasos de operaciones, incumplimiento de cronogramas de trabajo y
plazos de contrato.
El presente proyecto se presenta como alternativa de solución a estos problemas a través del
desarrollo de un sistema de información el cual permitirá la organización de la información para
el control y seguimiento de operaciones del equipo pesado, a través de informes, elaboración de
reportes de vehículos, propietarios, proyectos y otros que van de acuerdo a las exigencias de la
empresa.
En el desarrollo del proyecto se aplicó la metodología RUP ágil, el cual tiene las mismas
características que el RUP clásico, a diferencia de la aplicación de pocos diagramas UML los
cuales ayudan a la mejor comprensión del sistema.
El presente proyecto se divide en 8 capítulos los cuales se describen a continuación:
Capítulo 1, Se explica todos los conceptos que serán utilizados en el desarrollo del proyecto.
Capítulo 2, Comprende la obtención de requerimientos a través del modelo del negocio y método
VORD
Capítulo 3, Comprende el análisis del proyecto, mostrando los casos de uso y actores del sistema,
con su respectiva descripción.
Capítulo 4, En este se realizan los diagramas de secuencia, diagrama de clases y el modelo
relación del sistema, los cuales comprende el diseño del proyecto.
Capítulo 5, Se muestra la implementación del sistema.
iv
Capítulo 6, Por medio de la estimación basada en puntos de casos de uso se determinó el costo
del sistema.
Capítulo 7, Comprende la evaluación del sistema, con la prueba de caja negra observar el
funcionamiento correcto. También se comprobó que el sistema tiene una aceptación alta de los
usuarios a través del método de escalamiento de Likert.
Capítulo 8, En este capítulo se encuentra las conclusiones y recomendaciones del proyecto.
v
MARCO PRELIMINAR
1. INTRODUCCIÓN
Para el desarrollo de una región, es necesario efectuar una buena vinculación caminera para poder
llegar en forma rápida y con seguridad desde y hasta los centros de producción; mediante el
Gobierno Central del Estado Plurinacional de Bolivia y los gobiernos departamentales, se
lanzaron proyectos de construcción de carreteras, tanto en caminos ripiados como carreteras
asfaltadas; en un proyecto de construcción de una carretera asfaltada se tiene los siguientes
grupos de ítems:
Movimiento de tierras y capa de rodadura.
Obras de arte mayor (puentes y alcantarillas de tipo cajón).
Obras de arte menor (alcantarillas tubulares).
Drenaje superficial (zanjas de coronamiento y cunetas).
Señalización horizontal y vertical.
Seguridad vial y
Mitigación ambiental.
En los Proyectos de Construcción de Carreteras Asfaltadas, se tienen asignados grandes montos
de dinero, es decir, la construcción de carreteras, no resulta nada barato y el ítem de movimiento
de tierras y capa de rodadura, absorbe un 80% de este presupuesto, donde es necesario la
utilización de equipo pesado como ser:
Tractores.
Retroexcavadoras.
Cargadores frontales.
Moto niveladoras.
Compactadoras (Rodillo liso y Pata de cabra).
Compactador neumático.
Camiones cisternas.
Camión lubrico.
Volquetas.
1
En la actualidad el manejo de la información es de vital importancia para una organización, por
ello los procesos automatizados basados en computadoras son los pilares fundamentales de las
actividades de una organización; la empresa requiere de información correcta y oportuna.
Debido a esto nace la idea de automatizar las actividades cotidianas en las organizaciones; el
avance de las telecomunicaciones y el progreso informático han experimentado y obligado a estar
en un mundo moderno de la tecnología; ser competitivo y no estar relegado en las tareas
organizacionales proporcionan beneficios para proyectar a la empresa a futuro.
Para una empresa constructora es muy importante supervisar y controlar sus equipos, esto implica
un mayor rendimiento del equipo pesado, minimizando los costos de operación; es en tal sentido
la importancia de proporcionar una herramienta el cual facilite el seguimiento y control de
operaciones del equipo pesado, además, de obtener información del mismo en forma rápida y
ordenada para la elaboración de certificados de pago e informes necesarios para el área gerencial
y de operaciones.
2. ANTECEDENTES
El presente trabajo toma como caso de estudio la Empresa constructora COMSCOR SRL
(CONSTRUCTORA MULTIDICIPLINARIA DE SERVICIOS CORIA). Esta empresa fue
creada el año 2006, con la misión de desarrollar la integración Nacional; ejecuto Proyectos en
varios Municipios del departamento de Oruro (pavimento rígido de las vías principales de la
localidad de Orinoca), además, desarrolla y ejecuta proyectos de saneamiento urbano y
equipamiento de infraestructura caminera, Actualmente, construye el tramo carretero del Circuito
Turístico Lago Poopó, el proyecto de asfalto Antequera-Poopó y realiza el mantenimiento de
camino en el Municipio de Quillacas.
Esta empresa maneja datos e información de todas las operaciones de movimiento del equipo
pesado bajo supervisión meticulosa administrativa; el fin de su administración es cumplir plazos
y cronogramas de ejecución de obras; Como toda empresa, es una necesidad imperante entrar en
la automatización de sus actividades y operaciones empresariales, bajo características y
requerimientos propios de la empresa.
Varias empresas y organizaciones tanto públicas como privadas, están en el propósito de entrar
en el mundo de la automatización de la mayor parte de sus actividades, con el único fin de
2
eliminar procedimientos burocráticos o repetitivos, donde se vislumbra la incertidumbre de
eventos los cuales van en contra de la misión y visión de la empresa, es el caso de la empresa
COMSCOR SRL.
La automatización de transacciones empresariales ha permitido el diseño y desarrollo de
proyectos de grado para empresas u organizaciones con el fin de automatizar sus actividades,
donde se demuestra la necesidad de contar con procesos automatizados, por ejemplo el proyecto
de grado del Ing. Troncoso Moller Jeaneth Salome con el tema “SISTEMA DE INFORMACIÓN
PARA LA PLANIFICACION DEL MANTENIMIENTO DE CAMINOS” CASO: SED-CAM,
El proyecto de grado, se presentó como alternativa de solución a los problemas de la
planificación de proyectos de mantenimiento de caminos en distintos tramos carreteros a través
del desarrollo de un sistema de información; el proyecto de grado del Ing. Jesús Hermogenes
Valle Quispe con el tema “SISTEMA DE CONTROL Y SEGUIMIENTO DE INVENTARIO
DE FARMACOS” CASO: CLINICA SAN DAMIAN, El proyecto de grado, se presentó como
alternativa de solución a los problemas de crecimiento a través del desarrollo de un sistema de
control y seguimiento de inventario de fármacos;
El diseñar un sistema automatizado para una empresa, requiere de características únicas y
especiales, esto permitirá desarrollar productos únicos y específicos en función de las necesidades
y requerimientos de la empresa.
3. SITUACIÓN PROBLEMATICA
La Empresa constructora COMSCOR SRL., se dedica a la construcción de carreteras, esta
empresa requiere equipo pesado tanto de su propiedad como alquilada para cumplir con sus
trabajos, en tal sentido es muy importante el control diario y efectivo de todo el equipo pesado
empleado en sus operaciones. La empresa realiza sus operaciones bajo las siguientes
características:
La superintendencia de obras de la empresa requiere información en referencia al rendimiento del
equipo pesado en un periodo de tiempo, esta información es elaborada por el área técnica de la
empresa. Existe demora en la elaboración de estos informes (de las diferentes operaciones)
debido a la utilización de medios manuales esto dificulta el normal desarrollo de las operaciones
3
o transacciones de pagos, cobros, tiempos, sueldos, etc. En referencia a operaciones propias de la
empresa.
El área técnica de la empresa recibe diariamente información del rendimiento de los equipos
(información, proporcionada por el apuntador y operador), esta área presenta deficiencias en
cuanto al registro de datos, duplicidad de información, perdida de reportes, etc. Ocasionando
retrasos de operaciones, incumplimiento de cronogramas de trabajo y plazos de contrato.
El proceso de registro de informes del área técnica presenta deficiencias en cuanto al mecanismo
de búsqueda y control de seguimiento de operaciones de equipo pesado esto demora el
cumplimiento de la responsabilidad social con los contratos de alquiler.
4. PLANTEAMIENTO DEL PROBLEMA
¿Cómo organizar el almacenamiento de la información para el control y seguimiento de
operaciones del equipo pesado en la Empresa COMSCOR SRL.?
5. OBJETO DE ESTU|DIO
Se tomará como objeto de estudio todas las operaciones que generan información acerca del
equipo pesado.
6. OBJETIVOS
6.1 OBJETIVO GENERAL
Desarrollar un sistema de información para el control y seguimiento de operaciones del equipo
pesado en la Empresa COMSCOR SRL a fin de organizar el almacenamiento de la información
del equipo pesado.
6.2 OBJETIVOS ESPECÍFICOS
Conocer el contexto de la información en referencia al equipo pesado para realizar una
adecuada determinación de requerimientos.
Diseñar una arquitectura de datos para organizar y almacenar datos e información de
acuerdo a las necesidades de la Empresa.
4
Implementar un prototipo para evaluar el sistema propuesto a fin de verificar su correcto
funcionamiento.
7. CAMPO DE ACCIÓN
El campo de acción del proyecto será las operaciones de equipo pesado de la empresa
constructora COMSCOR SRL.
8. IDEA A DEFENDER
La implementación del Sistema de Información permite un mejor registro y control del
seguimiento de las operaciones del equipo pesado de la empresa COMSCOR SRL.
9. CRITERIO DE EVALUACIÓN
Para la validación del Sistema de información se realizara pruebas de usabilidad comparando los
resultados obtenidos (reportes) con los resultados ya existentes en la empresa y el método de
escalamiento de Liker.
10. JUSTIFICACIÓN
El desarrollo del proyecto es de importancia porque permitirá administrar la información de la
empresa constructora COMSCOR SRL. El sistema de información solucionara las debilidades de
la manipulación y seguimiento de datos e información, contribuyendo de esta manera al
cumplimiento de los objetivos institucionales.
10.1 JUSTIFICACIÓN TÉCNICA
Los procedimientos para la implementación del sistema de información consideran las
innovaciones tecnológicas con el fin de obtener un producto final; estos procedimientos
permitirán establecer la seguridad, integridad, veracidad y confiablidad de toda la información de
las operaciones del equipo pesado de la empresa.
10.2 JUSTIFICACIÓN ECONÓMICA
5
La información de los equipos y maquinaria pesada, ayudan a determinar la rentabilidad de la
empresa; la implementación de un sistema de información en las actividades empresariales
viabilizará la adjudicación de contratos y cumplimiento de responsabilidades sociales. Este
sistema, reducirá la incertidumbre de rescindir contratos con terceros, asimismo, la disminución
de beneficios de la empresa.
11. ALCANCES
La superintendencia de obras de la empresa contará con información en referencia al rendimiento
del equipo pesado en un determinado periodo de tiempo, esta información estará bajo tuición de
la gerencia de la empresa.
La gerencia y área técnica de la empresa recibirá diariamente información del rendimiento del
equipo pesado; se eliminara las deficiencias en cuanto al registro de datos, duplicidad de
información, pérdida de reportes, etc. Ayudando a reducir los retrasos de operaciones,
incumplimiento de cronogramas de trabajo y plazos de contrato.
El proceso de registro y elaboración de informes para gerencia y área técnica eliminará las
deficiencias en cuanto al mecanismo de búsqueda y control de seguimiento de operaciones del
equipo pesado, reduciendo el cumplimiento de la responsabilidad social de los contratos con
terceros.
12. LIMITACIONES
El proyecto en el área de almacenes abarcara solo el control de combustible, lubricantes y
algunos repuestos.
El sistema de información será diseñado exclusivamente para la empresa constructora dedicada
a la construcción de caminos carreteros.
13. APORTES
El sistema de información será desarrollado con características únicas y exclusivas para la
empresa constructora COMSCOR SRL. Servirá de referencia para futuro proyectos en la
Universidad.
14. INGENIERÍA DEL PROYECTO6
Tabla 1.- Ingeniería del Proyecto
OBJETIVOESPECÍFICO
ACTIVIDADESMETODOLOGÍA /
MODELO
Conocer el contexto de la información en referencia al equipo pesado y maquinaria para realizar una adecuada determinación de requerimientos
Recolección de información
Identificar problemas Investigación de
requerimientos.
Entrevistas. Encuestas. Observación
directa. Revisión de
documentos.
Diseñar una arquitectura de datos para organizar y almacenar datos e información de acuerdo a las necesidades de la Empresa.
Modelado del sistema. Diseño de la base de
datos selección de la
plataforma de trabajo diccionario de datos Diseño de interfaces Diseño de entrada y
salida.
Metodología RUP (procesos unificados) Lenguaje UML LENGUAJE unificado del modelado.
Modelo entidad relación.
Modelo relacional.
Implementar un prototipo para evaluar el sistema propuesto a fin de verificar su correcto funcionamiento.
Implementar la base de datos
Programación y producción del software
Configuración del servidor
Probar el nuevo sistema
Corregir fallas del sistema
Programación orientada a objetos.
Manejador de base de datos.
Pruebas de caja blanca y negra
7
CAPITULO 1MARCO TEÓRICO
En el presente capítulo se describe las tecnologías, herramientas, conceptos y metodología de
desarrollo los cuales se utiliza para el desarrollo del presente proyecto.
1.1 SISTEMA DE INFORMACION
Un sistema de información es un conjunto organizado de elementos, que pueden ser personas,
datos, actividades o recursos materiales en general. Estos elementos interactúan entre sí para
procesar información y distribuirla de manera adecuada en función de los objetivos de una
organización.
1.2 INGENIERIA WEB
La ingeniería web es la aplicación de metodologías sistemáticas disciplinadas y cuantificables al
desarrollo eficiente, operación y evolución de aplicaciones de alta calidad en la World Wide
Web.
La ingeniería web se debe al crecimiento desenfrenado que está teniendo la Web está
ocasionando un impacto en la sociedad y el nuevo manejo que se le está dando a la información
en las diferentes área en que se presenta ha hecho que las personas tiendan a realizar todas sus
actividades por esta vía.
Desde que esto empezó a suceder el Internet se volvió más que una diversión y empezó a ser
tomado más en serio ya que el aumento de publicaciones y de informaciones hizo que la Web se
volviera como un desafío para los ingenieros del software, a raíz de esto se crearon enfoques
disciplinarios, sistemáticos y metodologías donde tuvieron en cuenta aspectos específicos de este
nuevo medio.
1.3 SERVICIO WEB
La W3C define “Servicio Web” como un sistema de software diseñado para permitir
interoperatibilidad maquina a máquina en una red.
8
En términos sencillos, un servicio web es cualquier sistema de software diseñado para soportar
interacción maquina a máquina sobre una red, permitiendo comunicación entre diferentes
maquinas, con diferentes plataformas y entre programas distintos.
1.4 RENDIMIENTO EN MAQUINAS DE CONSTRUCCION
En la industria de la construcción se utiliza la palabra producción con el mismo significado que
“rendimiento”, que el diccionario define como “la cantidad o magnitud producida, en un campo
determinado”, o dicho de otra manera “es el trabajo útil ejecutado durante las diferentes etapas de
la obra”.
El rendimiento se puede expresar cuando menos de tres maneras, la primera es tomando como
base los requisitos y programas de la obra, mientas que la segunda, es midiendo o estimando el
rendimiento de una maquina cualquiera, para determinar el número necesario que de estas se
necesitaran para obtener la producción requerida.
La tercer manera de expresar la producción es en función del costo, aunque esta es probable que
no sea muy exacta, sino hasta después que se conozcan las características de la obra y el
rendimiento del equipo.
1.5 PROTOCOLO TCP / IP
TCP/IP es un conjunto de protocolos. La sigla TCP/IP significa "Protocolo de control de
transmisión/Protocolo de Internet". Proviene de los nombres de dos protocolos importantes del
conjunto de protocolos, es decir, del protocolo TCP y del protocolo IP.
En algunos aspectos, TCP/IP representa todas las reglas de comunicación para Internet y se basa
en la noción de dirección IP, es decir, en la idea de brindar una dirección IP a cada equipo de la
red para poder enrutar paquetes de datos.
1.6 PROTOCOLO HTTP
(HyperText Transfer Protocol). Protocolo usado para acceder a la Web (WWW). Se encarga de
procesar y dar respuestas a las peticiones para visualizar una página web.
Luego de finalizada la transacción, HTTP no guarda ninguna información sobre la misma, por lo
tanto es considerado un protocolo "sin estado".9
El protocolo HTTP generalmente utiliza el puerto 80.
El HTTP está basado en el modelo cliente-servidor, en donde un cliente HTTP (un navegador por
ejemplo) abre una conexión y realizar una solicitud al servidor. Este responde a la petición con un
recurso (texto, gráficos, etc) o un mensaje de error, y finalmente se cierra la conexión.
1.7 ARQUITECTURA CLIENTE SERVIDOR
Es la tecnología que proporciona al usuario final el acceso transparente a las aplicaciones, datos,
servicios de cómputo o cualquier otro recurso del grupo de trabajo y/o, a través de la
organización, en múltiples plataformas. El modelo soporta un medio ambiente distribuido en el
cual los requerimientos de servicio hechos por estaciones de trabajo inteligentes o "clientes'',
resultan en un trabajo realizado por otros computadores llamados servidores.
1.7.1 CLIENTE
Es el que inicia un requerimiento de servicio. El requerimiento inicial puede convertirse en
múltiples requerimientos de trabajo a través de redes LAN o WAN. La ubicación de los datos o
de las aplicaciones es totalmente transparente para el cliente.
1.7.2 SERVIDOR
Es cualquier recurso de cómputo dedicado a responder a los requerimientos del cliente. Los
servidores pueden estar conectados a los clientes a través de redes LANs o WANs, para proveer
de múltiples servicios a los clientes y ciudadanos tales como impresión, acceso a bases de datos,
fax, procesamiento de imágenes, etc.
1.7.3 ARQUITECTURA
Una arquitectura es un entramado de componentes funcionales que aprovechando diferentes
estándares, convenciones, reglas y procesos, permite integrar una amplia gama de productos y
servicios informáticos, de manera que pueden ser utilizados eficazmente dentro de la
organización.
Debemos señalar que para seleccionar el modelo de una arquitectura, hay que partir del contexto
tecnológico y organizativo del momento y, que la arquitectura Cliente/Servidor requiere una
determinada especialización de cada uno de los diferentes componentes que la integran.10
Figura 1.1 Arquitectura Cliente Servidor
1.8 MODELO VISTA CONTROLADOR (MVC)
El patrón de arquitectura MVC (Modelo Vista Controlador) es un patrón que define la
organización independiente del Modelo (Objetos de Negocio), la Vista (interfaz con el usuario u
otro sistema) y el Controlador (controlador del workflow de la aplicación).
El patrón de arquitectura "modelo vista controlador", es una filosofía de diseño de aplicaciones,
compuesta por:
MODELO
Contiene el núcleo de la funcionalidad (dominio) de la aplicación.
Encapsula el estado de la aplicación.
Independiente del Controlador y la Vista.
VISTA
Es la presentación del Modelo.
Puede acceder al Modelo pero nunca cambiar su estado.
Puede ser notificada cuando hay un cambio de estado en el Modelo.
CONTROLADOR
11
Reacciona a la petición del Cliente, ejecutando la acción adecuada y creando el modelo
pertinente.
Figura 1.2 Arquitectura Modelo Vista Controlador
1.9 PHP
La sigla PHP identifica a un lenguaje de programación que nació como Personal Home Page
(PHP) Tools. Fue desarrollado por el programador de origen danés Rasmus Lerdorf en 1994 con
el propósito de facilitar el diseño de páginas web de carácter dinámico.
El acrónimo recursivo, sin embargo, en la actualidad está vinculado a PHP Hypertext Pre-
Processor. La Free Software Foundation, por lo tanto, considera la licencia PHP como parte del
software libre. El lenguaje PHP se procesa directamente en el servidor.
1.10 SISTEMA GESTOR DE BASE DE DATOS MySQL
MySQL es un Sistema Gestor de Bases de Datos relacional, fue creado por la empresa sueca
MySQL AB, la cual tiene el copyright del código fuente del servidor SQL, así como también de
la marca, es un software de código abierto, con licencia GPL de GNU, aunque MySQL AB
distribuye una versión comercial, en lo único que se diferencia de la versión libre, es en el soporte
técnico que se ofrece, y la posibilidad de integrar este gestor en un software propietario ya que de
otra manera se vulneraria la licencia GPL.
1.10.1 CARACTERISTICAS
Velocidad y Robustez.
12
Soporta gran cantidad de tipos de datos para las columnas.
Gran portabilidad entre sistemas, puede trabajar en distintas plataformas y sistemas
operativos.
Cada base de datos cuenta con 3 archivos. Uno de estructura, uno de datos y uno de
índice y soporta hasta 32 índices por tabla.
Aprovecha la potencia de sistemas multiproceso, gracias a su implementación multihilo
Flexible sistema de contraseñas (passwords) y gestión de usuarios, con un muy buen nivel
de seguridad en los datos.
1.10.2 VENTAJAS
Velocidad al realizar las operaciones, lo que le hace uno de los gestores con mejor
rendimiento.
Bajo costo en requerimientos para la elaboración de bases de datos, ya que debido a su
bajo consumo puede ser ejecutado en una maquina con escasos recursos sin ningún
problema.
Facilidad de configuración e instalación
Soporta gran variedad de Sistemas Operativos
Baja probabilidad de corromper datos, incluso si los errores no se producen en el propio
gestor, sino en el sistema en el que esta
Conectividad y Seguridad
1.11 FRAMEWORK CODEIGNITER
Es un Framework para PHP que facilita la escritura de código repetitivo, y a comparación de
otros Frameworks cómo CakePHP, Symphony o Zend Framework, Codeigniter es más rápido
pero menos fácil ya que carace de algunas librerías que los otros frameworks tienen, pero aún así
no deja de ser un buen framework además de que es totalmente extensible y altamente compatible
con gran variedad de versiones y configuraciones de PHP.
1.11.1 DIAGRAMA DE FLUJO DE LA APLICACIÓN
El siguiente gráfico ilustra como fluyen los datos a través del sistema:
13
Figura 1.3 CodeIgniter Flujo de la Aplicación
• El index.php sirve como controlador frontal, inicializando los recursos básicos necesarios
para correr CodeIgniter.
• El Router examina la petición HTTP para determinar que debe ser hecho con él.
• Si un archivo de caché existe, es enviado directamente al explorador, sobrepasando el
sistema de ejecución normal.
• Seguridad. Antes que el controlador sea cargado, la petición HTTP y cualquier dato
suministrado por el usuario es filtrado por seguridad.
• El controlador carga los modelos, librerías, plugins, asistentes y cualquier otro recurso
necesario para procesar la petición específica.
• La Vista finalizada es presentada entonces enviada al explorador web para ser vista. Si el
cacheo está habilitado, la vista es cacheada primero para que las peticiones subsecuentes
puedan ser servidas.
1.12 HTML
HTML es un lenguaje de programación que se utiliza para el desarrollo de páginas de Internet. Se
trata de la sigla que corresponde a HyperText Markup Language, es decir, Lenguaje de Marcas de
Hipertexto, que podría ser traducido como Lenguaje de Formato de Documentos para Hipertexto.
Se trata de un formato abierto que surgió a partir de las etiquetas SGML (Standard Generalized
Markup Language). Concepto traducido generalmente como “Estándar de Lenguaje de Marcado
Generalizado” y que se entiende como un sistema que permite ordenar y etiquetar diversos
documentos dentro de una lista. Este lenguaje es el que se utiliza para especificar los nombres de
las etiquetas que se utilizarán al ordenar, no existen reglas para dicha organización, por eso se
dice que es un sistema de formato abierto.
1.13 JAVASCRIPT
JavaScript es un lenguaje interpretado, es decir, que no requiere compilación, utilizado
principalmente en páginas web, con una sintaxis semejante a la del lenguaje Java y el lenguaje C.
Al contrario que Java, JavaScript no es un lenguaje orientado a objetos propiamente dicho, ya que
no dispone de Herencia, es más bien un lenguaje basado en prototipos, ya que las nuevas clases
se generan clonando las clases base (prototipos) y extendiendo su funcionalidad.14
1.14 CSS
Hojas de Estilo en Cascada (Cascading Style Sheets), es un mecanismo simple que describe cómo
se va a mostrar un documento en la pantalla.
CSS se utiliza para dar estilo a documentos HTML y XML, separando el contenido de la
presentación. Los Estilos definen la forma de mostrar los elementos HTML y XML. CSS permite
a los desarrolladores Web controlar el estilo y el formato de múltiples páginas Web al mismo
tiempo. Cualquier cambio en el estilo marcado para un elemento en la CSS afectará a todas las
páginas vinculadas a esa CSS en las que aparezca ese elemento.
1.15 LENGUAJE UNIFICADO DE MODELADO
UML es un popular lenguaje de modelado de sistemas de software. Se trata de un lenguaje
gráfico para construir, documentar, visualizar y especificar un sistema de software. Entre otras
palabras, UML se utiliza para definir un sistema de software.
Posee la riqueza suficiente como para crear un modelo del sistema, pudiendo modelar los
procesos de negocios, funciones, esquemas de bases de datos, expresiones de lenguajes de
programación, etc. Para ello utiliza varios tipos diferentes de diagramas, por ejemplo, en UML
2.0 hay 13 tipos de diagramas. Estos diagramas se pueden diferenciar en tres categorías:
Diagramas de estructura:
Diagrama de clases
Diagrama de componentes
Diagrama de objetos
Diagrama de despliegue
Diagrama de paquetes
Diagramas de comportamiento:
Diagrama de actividades
Diagrama de casos de uso
Diagrama de estados
Diagramas de interacción:15
Diagrama de secuencia
Diagrama de comunicación
1.16 UML ENTORNO WEB
UML puede ser extendido para permitir nueva semántica:
Estereotipos: define una nueva semántica al modelo.
Lista de etiquetas: podemos entregar una lista de campo-valor.
Restricciones : definen las reglas para trabajar con determinados estereotipos.
1.16.1 ESTEREOTIPOS PARA CLASES
Son Pagina Servidor, Pagina Cliente y Formulario.
<<Server Page>> Son las páginas que contienen scripts o código ejecutable por el servidor.
(.php , .asp , .jsp)
Figura 1.4 Pagina Servidor
<<Client Page>> Son las páginas que estan en el lado del cliente, normalmente páginas HTML
y scripts (jsvascript).
Figura 1.5 Pagina Cliente
<<Form>> Es la representación de un formulario. Es código HTML que contiene etiquetas de
formulario como: <input>, <textarea>, <select>.
16
Figura 1.6 Formulario
1.16.2 ESTEREOTIPOS PARA RELACIONES
<<build>> Una relación entre una página servidor y una página cliente. La página servidor
“construye” a la página cliente.
<<link>> Es una relación entre una página y otra página del sistema.
<<submit>> Es una relación entre un formulario y un servidor de página
1.17 METODOLOGIA DEL PROYECTO: PROCESO UNIFICADO RATIONAL
El Proceso Unificado Racional, Rational Unified Process en inglés, y sus siglas RUP, es un
proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML,
constituye la metodología estándar más utilizada para el análisis, implementación y
documentación de sistemas orientados a objetos.
El RUP no es un sistema con pasos firmemente establecidos, sino que trata de un conjunto de
metodologías adaptables al contexto y necesidades de cada organización, donde el software es
organizado como una colección de unidades atómicas llamados objetos, constituidos por datos y
funciones, que interactúan entre sí.
1.17.1 ANTECEDENTES DEL RUP
Los orígenes de RUP se remontan al modelo espiral original de Barry Boehm. Ken Hartman, uno
de los contribuidores claves de RUP colaboró con Boehm en la investigación. En 1995 Rational
Software compró una compañía sueca llamada Objectory AB, fundada por Ivar Jacobson, famoso
por haber incorporado los casos de uso a los métodos de desarrollo orientados a objetos.
El Rational Unified Process fue el resultado de una convergencia de Rational Approach y
Objectory. El primer resultado de esta fusión fue el Rational Objectory Process, la primera
versión de RUP, fue puesta en el mercado en 1998, siendo el arquitecto en jefe Philippe
Kruchten. Desde allí hasta la actualidad es la metodología más empleada en el mundo.
1.17.2 RUP COMO PROCESO DE DESARROLLO
17
• RUP es explícito en la definición de software y su trazabilidad, es decir, contempla en relación
causal de los programas creados desde los requerimientos hasta la implementación y pruebas.
• RUP identifica claramente a los profesionales (actores) involucrados en el desarrollo del
software y sus responsabilidades en cada una de las actividades.
1.17.3 FASES DE DESARROLLO DEL SOFTWARE
Inicio
Elaboración
Construcción
Transición
Fase de inicio
Se hace un plan de fases, donde se identifican los principales casos de uso y se identifican los
riesgos. Se concreta la idea, la visión del producto, como se enmarca en el negocio, el alcance del
proyecto. El objetivo en esta etapa es determinar la visión del proyecto.
Modelado del negocio
En esta fase el equipo se familiarizará más al funcionamiento de la empresa, sobre conocer sus
procesos.
Entender la estructura y la dinámica de la organización para la cual el sistema va ser
desarrollado.
Entender el problema actual en la organización objetivo e identificar potenciales mejoras.
Asegurar que clientes, usuarios finales y desarrolladores tengan un entendimiento común
de la organización objetivo.
Requisitos
En esta línea los requisitos son el contrato que se debe cumplir, de modo que los usuarios finales
tienen que comprender y aceptar los requisitos que especifiquemos.
Establecer y mantener un acuerdo entre clientes y otros stakeholders1 sobre lo que el
sistema podría hacer.
Proveer a los desarrolladores un mejor entendimiento de los requisitos del sistema. 1 Proveedores, vendedores, etc.
18
Definir el ámbito del sistema.
Proveer una base para estimar costos y tiempo de desarrollo del sistema.
Definir una interfaz de usuarios para el sistema, enfocada a las necesidades y metas del
usuario.
Fase de elaboración
Se realiza el plan de proyecto, donde se completan los casos de uso y se mitigan los riesgos.
Planificar las actividades necesarias y los recursos requeridos, especificando las características y
el diseño de la arquitectura. En esta etapa el objetivo es determinar la arquitectura Óptima.
Análisis y Diseño
En esta actividad se especifican los requerimientos y se describen sobre cómo se van a
implementar en el sistema.
Transformar los requisitos al diseño del sistema.
Desarrollar una arquitectura para el sistema.
Adaptar el diseño para que sea consistente con el entorno de implementación.
Fase de construcción
Se basa en la elaboración de un producto totalmente operativo y en la elaboración del manual de
usuario. Construir el producto, la arquitectura y los planes, hasta que el producto está listo para
ser enviado a la comunidad de usuarios. En esta etapa el objetivo es llevar a obtener la capacidad
operacional inicial.
Implementación
Se implementan las clases y objetos en ficheros fuente, binarios, ejecutables y demás. El
resultado final es un sistema ejecutable.
Planificar qué subsistemas deben ser implementados y en qué orden deben ser integrados,
formando el Plan de Integración.
Cada implementador decide en qué orden implementa los elementos del subsistema.
Si encuentra errores de diseño, los notifica.
Se integra el sistema siguiendo el plan.
Pruebas19
Este flujo de trabajo es el encargado de evaluar la calidad del producto que estamos
desarrollando, pero no para aceptar o rechazar el producto al final del proceso de desarrollo, sino
que debe ir integrado en todo el ciclo de vida.
Encontrar y documentar defectos en la calidad del software.
Generalmente asesora sobre la calidad del software percibida.
Provee la validación de los supuestos realizados en el diseño y especificación de
requisitos por medio de demostraciones concretas.
Verificar las funciones del producto de software según lo diseñado.
Verificar que los requisitos tengan su apropiada implementación.
Etapa de transición
Se realiza la instalación del producto en el cliente y se procede al entrenamiento de los usuarios.
Realizar la transición del producto a los usuarios, lo cual incluye: manufactura, envío,
entrenamiento, soporte y mantenimiento del producto, hasta que el cliente quede satisfecho, por
tanto en esta fase suelen ocurrir cambios.
Despliegue
Esta actividad tiene como objetivo producir con éxito distribuciones del producto y distribuirlo a
los usuarios. Las actividades implicadas incluyen:
Probar el producto en su entorno de ejecución final.
Empaquetar el software para su distribución.
Distribuir el software.
Instalar el software.
Proveer asistencia y ayuda a los usuarios.
Formar a los usuarios y al cuerpo de ventas.
Migrar el software existente o convertir bases de datos.
20
Figura 1.7 – Fases de la Metodología RUP
Cada una de estas etapas es desarrollada mediante el ciclo de iteraciones, la cual consiste en
reproducir el ciclo de vida en cascada a menor escala. Los objetivos de una iteración se
establecen en función de la evaluación de las iteraciones precedentes.
A medida que se avanza en el proyecto, es decir, cuando se va pasando de una fase a otra, la
importancia relativa de cada uno de los Flujos de Trabajo va cambiando. Así, en las iteraciones
de la Fase de Inicio el trabajo se centra principalmente en el Modelamiento del Negocio y en la
captura y especificación de requisitos. Pero en la fase de Construcción el desarrollo está enfocado
en la Implementación (codificación) y, en menor medida, en el Diseño
1.17.4 COMO FILOSOFÍA RUP MANEJA 6 PRINCIPIOS CLAVE
Adaptación Del Proceso
El proceso deberá adaptarse a las características propias de la organización. El tamaño del
mismo, así como las regulaciones que lo condicionen, influirán en su diseño específico. También
se deberá tener en cuenta el alcance del proyecto.
Balancear Prioridades
Los requerimientos de los diversos inversores pueden ser diferentes, contradictorios o disputarse
recursos limitados. Debe encontrarse un balance que satisfaga los deseos de todos.
Colaboración Entre Equipos
21
El desarrollo de software no hace una única persona sino múltiples equipos. Debe haber una
comunicación fluida para coordinar requerimientos, desarrollo, evaluaciones, planes, resultados,
etc.
Demostrar Valor Iterativamente
Los proyectos se entregan, aunque sea de modo interno, en etapas iteradas. En cada iteración se
analiza la opinión de los inversores, la estabilidad y calidad del producto, y se refina la dirección
del proyecto así como también los riesgos involucrados.
Elevar El Nivel De Abstracción
Este principio dominante motiva el uso de conceptos reutilizables tales como patrón del software,
lenguajes 4GL o esquemas (Frameworks) por nombrar algunos. Estos se pueden acompañar por
las representaciones visuales de la arquitectura, por ejemplo con UML.
Enfocarse en la calidad
El control de calidad no debe realizarse al final de cada iteración, sino en todos los aspectos de la
producción.
1.17.5 CARACTERÍSTICAS ESENCIALES QUE DEFINEN AL RUP
Proceso Dirigido por los Casos de Uso:
Con esto se refiere a la utilización de los Casos de Uso para el desenvolvimiento y desarrollo de
las disciplinas con los artefactos, roles y actividades necesarias. Los Casos de Uso son la base
para la implementación de las fases y disciplinas del RUP. Un Caso de Uso es una secuencia de
pasos a seguir para la realización de un fin o propósito, y se relaciona directamente con los
requerimientos, ya que un Caso de Uso es la secuencia de pasos que conlleva la realización e
implementación de un Requerimiento planteado por el Cliente.
Proceso Iterativo e Incremental:
Es el modelo utilizado por RUP para el desarrollo de un proyecto de software. Este modelo
plantea la implementación del proyecto a realizar en Iteraciones, con lo cual se pueden definir
objetivos por cumplir en cada iteración y así poder ir completando todo el proyecto iteración por
iteración, con lo cual se tienen varias ventajas, entre ellas se puede mencionar la de tener
22
pequeños avances del proyectos que son entregables al cliente el cual puede probar mientras se
está desarrollando otra iteración del proyecto, con lo cual el proyecto va creciendo hasta
completarlo en su totalidad.
Proceso Centrado en la Arquitectura:
Define la Arquitectura de un sistema, y una arquitectura ejecutable construida como un prototipo
evolutivo. Arquitectura de un sistema es la organización o estructura de sus partes más
relevantes. Una arquitectura ejecutable es una implementación parcial del sistema, construida
para demostrar algunas funciones y propiedades. RUP establece refinamientos sucesivos de una
arquitectura ejecutable, construida como un prototipo evolutivo.
1.17.6 ALCANCE DE LA METODOLOGÍA RUP
La metodología RUP es más apropiada para proyectos grandes, también pequeños, dado que
requiere un equipo de trabajo capaz de administrar un proceso complejo en varias etapas. En
proyectos pequeños, es posible que no se puedan cubrir los costos de dedicación del equipo de
profesionales necesarios.
1.18 RUP AGIL
En el presente proyecto se aplicará la metodología RUP ágil, el cual sigue el mismo
procedimiento que el RUP clásico con la diferencia de la aplicación de solo algunos diagramas
UML.
1.19 LA ORGANIZACION
La Empresa constructora COMSCOR SRL (CONSTRUCTORA MULTIDICIPLINARIA DE
SERVICIOS CORIA). Esta empresa fue creada el año 2006, con la misión de desarrollar la
integración Nacional; ejecuto Proyectos en varios Municipios del departamento de Oruro
(pavimento rígido de las vías principales de la localidad de Orinoca), además, desarrolla y ejecuta
proyectos de saneamiento urbano y equipamiento de infraestructura caminera, Actualmente,
construye el tramo carretero del Circuito Turístico Lago Poopó, el proyecto de asfalto Antequera-
Poopó y realiza el mantenimiento de camino en el Municipio de Quillacas.
23
1.19.1 ORGANIGRAMA DEL PROYECTO
PROYECTO: MEJORAMIENTO CAMINO ASFALTADO ANTEQUERA-
POOPO
Figura 1.8 – Organigrama de la Organización
1.19.2 CONCEPTOS BASICOS DE LA ORGANIZACIÓN
Rasante o línea de proyecto: corresponde a la línea de contacto del elemento incorporado al
terreno.
Rasante óptima: para determinar la rasante existen múltiples criterios, que serán definidos por
los profesionales encargados del proyecto. Para efectos topográficos el criterio a utilizar será el
criterio económico, esto implica ubicar la rasante en el punto en que se igualen los volúmenes de
corte con los de terraplén.
Sub rasante: se define así al terreno de fundación de los pavimentos, pudiendo estar constituida
por el suelo natural del corte o de la parte superior de un relleno debidamente compactado.
24
Ing. Elmer Coria VillcaSUPERINTENDENTE DE OBRA
Ing. (e) Estela Mamani Ch.ING. ESPECIALISTA ESTRUCTURISTA EN Ho
OBRAS DE ARTE MAYOR Y MENOR
Lic. Fermin Rodriguez H.LABORATORISTA SUELOS, Ho.
Ing. (e) Juan Pablo FloresRES. DE OBRA/ENC. PLATAFORMA
Ing.(e) Julio QuirozENC. BRIGADA TOPOGRAFICA
Sub base: es una capa, generalmente constituida por agregados pétreos convenientemente
graduados y compactados, construida sobre la sub rasante, y sobre la cual puede construirse la
base cuando sea necesaria.
Base: es una capa intermedia entre la sub base y la carpeta del pavimento, generalmente
constituida por agregados pétreos convenientemente graduados y compactados, pudiendo
contener además un agente estabilizador. Aunque hay diversos estabilizadores, el de uso más
generalizado es el cemento hidráulico.
CAPITULO 2DETERMINACION DE REQUERIMIENTOS
En este capítulo se desarrolla el trabajo de obtención de requerimientos de la Empresa
constructora COMSCOR SRL, donde la recolección de información se realizó a través de
entrevistas, cuestionarios y revisión de documentos.
25
2.1 MODELADO DEL NEGOCIO
El “Modelado de Negocio” se define como un proceso de representación de uno o más aspectos o
elementos de una empresa, tales como: su propósito, su estructura, su funcionalidad, su dinámica,
su lógica de negocios.
Asimismo, el modelado del negocio, hace referencia al modelo de Casos de Uso del Negocio y
Modelo de Objetos del Negocio
Modelo de Casos de Uso del Negocio: representa las funciones del sistema y los actores
que hacen uso de ella. Se representa mediante diagramas de casos de uso
.Modelado de objetos del negocio: describe la realización de cada caso de uso del
negocio, estableciendo los actores internos, la información que en términos generales
manipulan y los flujos de trabajo asociados al caso de uso del negocio.
2.1.1 DIAGRAMA DE CASOS DE USO DEL NEGOCIO
La siguiente figura muestra el modelo de casos de uso del Negocio.
26
Administrador
Operador de Equipo Pesado
Chofer
Almacenes
Realiza Liquidacion
Coordina Tareas
Superintendente
Realiza Tramo
Ejecuta Trabajos
CapatazTopografo
Supervisor de Gobernacion
Controla Avance
Residente de Obras
Coordina trabajos
Figura 2.1.- Modelo de Casos de Uso del Negocio
2.1.2 ESPECIFICACION DE LOS ACTORES DEL NEGOCIO
A continuación se describe los actores del negocio.
Tabla 2.1.- Especificación Actor del Negocio Topógrafo
Actor TopógrafoDescripción Es la persona encargada de realizar el relevamiento en base al diseño y
también de replantear el mismo para definir la ruta de la carretera.Responsabilidades Es responsable de revisar los planos estructurales, viales, sanitarios e
hidráulicos, además de la revisión y control de las planillas topográficas en función a los diferentes respaldo y actividades realizadas en obra
Tabla 2.2.- Especificación Actor del Negocio Operador de Equipo Pesado
Actor Operador de equipo pesadoDescripción Es el encargado de operar el equipo pesado en obra.Responsabilidades Es el responsable de ejecutar los trabajos operando los equipos en obra.
27
Tabla 2.3.- Especificación Actor del Negocio Residente de Obras
Actor Residente de ObrasDescripción Es el encargado de coordinar la ejecución del proyecto.Responsabilidades Es responsable de la ejecución del proyecto, controlar la maquinaria y el
personal dentro el proyecto.
Tabla 2.4.- Especificación Actor del Negocio Superintendente
Actor SuperintendenteDescripción Es el representante legal en obra por parte de la contratista. Responsabilidades Es el responsable de dirigir la realización de la obra, mantener coordinación
permanente y efectiva con la oficina central del contratista.
Tabla 2.5.- Especificación Actor del Negocio Capataz
Actor CapatazDescripción Es el encargado de coordinar el movimiento del equipo y personal en obra. Responsabilidades Es el responsable de hacer cumplir todas las disposiciones por parte del
cuerpo técnico para el avance de la obra.
Tabla 2.6.- Especificación Actor del Negocio Administrador
Actor AdministradorDescripción Es el encargado de administrar todo el proyecto.Responsabilidades Es responsable de hacer efectiva todo lo requerimientos y necesidades de la
obra.
Tabla 2.7.- Especificación Actor del Negocio Supervisor de Gobernación
Actor Supervisor de GobernaciónDescripción Es el encargado de supervisar y realizar el seguimiento a las diferentes
actividades ejecutadas en el proyecto.Responsabilidades Es el responsable de realizar cualquier modificación y tomar acciones de
naturaleza técnica o administrativa que vayan en bien del proyecto.
Tabla 2.8.- Especificación Actor del Negocio Chofer
Actor Chofer Descripción Es el encargado de operar las volquetas dentro los predios del proyecto.Responsabilidades Es responsable de manejar las volquetas en obra y acarrear los volúmenes de
conformación en obra.
28
Tabla 2.9.- Especificación Actor del Negocio Almacenes
Actor AlmacenesDescripción Es el encargado de almacenes. Responsabilidades Es el responsable de realizar el control de todos los activos de ingreso y
salida de almacenes.
2.1.2 ESPECIFICACION DE LOS CASOS DE USO DEL NEGOCIO
Tabla 2.10.- Especificación Caso de Uso del Negocio Realiza Tramo
Tabla 2.11.- Especificación Caso de Uso del Negocio Coordina Tareas
29
Caso de Uso Realiza tramo
Actor Supervisor de obra, Residente de obra, Topógrafo
Tipo Básico
Propósito Realizar el trazo del camino.
Resumen El supervisor entrega a la contratista el diseño de la carretera, el residente en coordinación con el topógrafo realizan el trazo del camino
Precondición Ninguno.
Flujo Principal 1. El Supervisor entrega el diseño de la carretera.2. El Residente coordina con el topógrafo.3. El Topógrafo realiza el relevamiento de la carretera. 4. El Topógrafo realiza una verificación en gabinete.5. El Topógrafo replantea el trazo de la carretera.6. El Supervisor y el Residente realizan una verificación del trazo de la carretera.
Subflujo Ninguno.
Excepciones Ninguno Caso de Uso Coordina tareas
Actor Superintendente, Residente de obra
Tipo Básico
Propósito Coordinar la ejecución del trabajo en obra
Resumen El Superintendente y Residente coordinan las actividades semanales y diarios a ejecutarse durante el progreso de la obra.
Precondición Debe de haberse realizado el caso de uso Realiza tramo.
Flujo Principal 1. El Superintendente revisa el cronograma de actividades.2. El Superintendente determina las tareas diarias, semanales y mensuales a
realizarse.3. El Superintendente coordina con el Residente las tareas diarias, semanales y
mensuales a realizarse.4. El Superintendente con el residente planifican las tareas a ejecutarse.
Subflujo Ninguno.
Excepciones Ninguno.
Tabla 2.12.- Especificación Caso de Uso del Negocio Ejecuta Trabajos
Tabla 2.13.- Especificación Caso de Uso del Negocio Controla Avance
30
Caso de Uso Ejecuta trabajos
Actor Residente de Obra, Capataz, Operador de equipo pesado, Chofer de volqueta, Almacenes
Tipo Básico
Propósito Ejecutar los trabajos programados en obra.
Resumen El Residente en base a la planificación coordina con el Capataz las actividades a realizar, quien ejecuta estos trabajos con el Operador de equipo pesado y el Chofer de volqueta.
Precondición Debe haberse ejecutado el caso de uso de negocio Realiza tramo, Coordina tareas.
Flujo Principal 1. El Residente instruye al Capataz las actividades diarias a ejecutarse.2. El Capataz indica al Chofer de volqueta los volúmenes a transportarse para
cada día y en cada tramo de la obra.3. El Chofer de volqueta, genera el parte diario donde describe a detalle la
actividad realzada en el día.4. El chofer de volqueta entrega el parte diario con el visto bueno del Capataz al
Residente de obra.5. Una vez transportado, el Capataz indica al Operador de equipo pesado el
trabajo a ejecutar.6. El Operador de equipo pesado ejecuta el trabajo programado y asignado.7. El operador de equipo pesado genera el parte diario, donde describe a detalle
la actividad realizada en el día.8. El Operador de equipo pesado entrega el parte diario con el visto bueno del
Capataz al Residente de obra.9. El Residente de obra centraliza la información de los partes diarios de todo el
equipo pesado y las volquetas.10. En todo el proceso Almacenes se encarga de suministrar repuestos,
combustible e insumos en general para la ejecución del proyecto.
Subflujo Ninguno.
Excepciones Ninguno.
Caso de Uso Controla avance
Actor Supervisor de obra, Residente de obras, Topógrafo
Tipo Básico
Propósito Controlar el avance y el control de calidad de la obra.
Resumen Realizado la ejecución de la actividad programada, se realiza el control del mismo entre el Topógrafo, Residente de obra y el Supervisor, quien realiza la liberación del trabajo ejecutado.
Precondición Debe haberse ejecutado el caso de uso de negocio Realiza tramo, Coordina tareas y Ejecuta trabajos.
Flujo Principal 1. El Topógrafo realiza la verificación del trabajo ejecutado.2. El Residente de obra realiza la solicitud de liberación del trabajo ejecutado al
Supervisor de obra, mediante nota de campo.3. El Supervisor de obra conjuntamente el Residente y el Topógrafo realizan una
verificación del trabajo ejecutado.4. El Supervisor y el Residente realizan el control de calidad del trabajo
ejecutado.5. El Supervisor de obra emite la nota de liberación del trabajo ejecutado.
Subflujo Ninguno.
Excepciones Ninguno.
Tabla 2.14.- Especificación Caso de Uso del Negocio Realiza Liquidación
Tabla 2.15.- Especificación Caso de Uso del Negocio Coordina trabajos
31
Caso de Uso Realiza liquidación
Actor Superintendente, Residente de obras, Administrador
Tipo Básico
Propósito Realizar la liquidación de los equipos que realizaron trabajos en el mes para su cancelación.
Resumen El Residente de obra en base a los partes diarios de los equipos calcula y centraliza las horas equipo y los volúmenes transportados en obra para entregar al Administrador, quien genera la liquidación mensual de cada equipo para la revisión y aprobación por el Superintendente para posteriormente mediante el Administrador realizar la solicitud de pagos de cada equipo, con el visto bueno del Superintendente.
Precondición Debe haberse ejecutado el caso de uso de negocio Ejecuta trabajos.
Flujo Principal 1. El Residente de obra realiza el resumen de las horas trabajadas por el equipo pesado en el mesen base a los partes diarios.
2. El residente de obra realiza el cálculo de los volúmenes transportados por las volquetas en base a los partes diarios.
3. El Residente de obra entrega un resumen más respaldos de las horas equipo y volúmenes transportados al Administrador.
4. El Administrador genera la liquidación mensual de cada equipo y volqueta.5. El Administrador entrega al Superintendente las liquidaciones mensuales más
los respaldos respectivos.6. El Superintendente revisa las liquidaciones mensuales y da el visto bueno.7. El Administrador realiza la solicitud de pagos mensual para los equipos y
volquetas.
Subflujo Ninguno.
Excepciones Ninguno.
Caso de Uso Coordina trabajos
Actor Superintendente, Supervisor de obra
Tipo Básico
Propósito Coordinar los trabajos a realizarse y ejecutarse en la obra.
Resumen Para una buena ejecución de la obra, el Supervisor de obra y el Superintendente coordinan los trabajos a ejecutarse, en base al cronograma de actividades aprobado.
Precondición Ninguno.
Flujo Principal 1. Iniciado la obra, el Superintendente presentara un cronograma de ejecución al Supervisor de obra.
2. El Supervisor de obra revisara y aprobara el cronograma de ejecución de obra.
3. En base a este cronograma el Supervisor de obra y el Superintendente coordinan los trabajos a ejecutarse
Subflujo Ninguno.
Excepciones Ninguno.
2.1.3. DIAGRAMA DE OBJETOS DEL NEGOCIO
2.1.3.1. CASO DE USO: REALIZA TRAMO
Supervisor de Gobernacion
Diseño
1:entrega
Topografo
Residente de Obras
2:Revisa
Trazo de carretera
3: Replantea
4: Verifica
Figura 2.2.- Objeto del Negocio Caso de uso Realiza Tramo
2.1.3.2. CASO DE USO: CONTROLA AVANCE
Topografo
Trabajos ejecutados
1: Controla
Residente de Obras
2: Verifica
Supervisor de Gobernacion
Liberacion
3: Sol ici ta
4: Real iza
Figura 2.3.- Objeto del Negocio Caso de uso Controla Avance
2.1.3.3. CASO DE USO: REALIZA LIQUIDACION
32
Costo Ejecutado de Volqueta
Horas de Trabajo de Volqueta
Liquidacion de Volqueta
Liquidacion de Equipo Pesado
Residente de Obras
1: Calcula 2: Verifica
Documento Para Liquidez
Administrador
9: Entrega
7: Entrega
3: Entrega Informe
6: Hace
Solici tud de Fondos
4: Genera
Superintendente
5:Aprueba
Figura 2.4.- Objeto del Negocio Caso de uso Realiza Liquidación
2.1.3.4. CASO DE USO: COORDINA TAREAS
Cronograma
Superintendente
1: Revisa
Residente
Capataz
Tareas
2: Determina
3: Coordina
4: Planii fca
Figura 2.5.- Objeto del Negocio Caso de uso Coordina Tareas
2.1.3.5. CASO DE USO: EJECUTA TRABAJO
33
Capataz
Operador de Equipo Pesado
Insumos equipo pesado
6: Recoge
Chofer Almacenes
5: Da
Insumos vehiculo
7: Enrega8: Recibe
Parte diario volqueta
1: Llena
2: ApruebaResidente de Obras
Controla
Parte diario equipo pesado3: Genera
4: Verifica
10: Observa
Figura 2.6.- Objeto del Negocio Caso de uso Ejecuta Trabajo
2.1.3.6. CASO DE USO: COOORDINA TRABAJOS
Superintendente Supervisor de Gobernacion
Cronograma1: Planifica
2: Verifica
Figura 2.7.- Objeto del Negocio Caso de uso Coordina trabajos
2.2 METODO VORD
El método VORD (Viewpoint Oriented Definition). Definicion de Requerimientos orientado a
Puntos de Vista, este método está basado en puntos de vista que se enfocan en usuarios
involucrados en aspectos Organizacionales. El modelo orientado a puntos de vista pasan
información de control de control y parámetros asociados al sistema. Los puntos de vista
proyectan las clases de usuarios finales de un sistema o de otro interconectado. Los puntos de
vista que estructuran el núcleo del modelo, son conocidos como puntos de vista directos . por el
34
hecho de que no todos los requerimientos son derivados de gente o subsistemas que interactúan
con sistemas especificados . los puntos de vista que respecta a sistemas externos que tienen
influencia en el dominio de la aplicación también son considerados y son llamados puntos de
vista indirectos.
Para la determinación de requerimientos se debe identificar y documentar lo que realmente
requiere la Empresa Constructora COMSCOR SRL. , es decir realizamos un listado de los
requerimientos funcionales los cuales definen la funcionalidad del sistema es decir las tareas que
el sistema será capaz de realizar y los requerimientos no funcionales que llegan a ser los atributos
que el sistema debe tener, para luego obtener lo que es el modelo de requisitos.
Este modelo de requisitos es el primero en desarrollarse, es la base para formar todos los demás
modelos en el desarrollo del software y es el modelo de casos de uso que sirve para expresar
dicho modelo.
2.3 ANALISIS DE REQUISITOS – DESARROLLO DEL METODO VORD
El proceso de recoger información sobre las necesidades existentes en la Empresa Constructora
COMSCOR SRL, se realiza con el método VORD (definición de requerimientos orientado a
puntos de vista), el cual nos permite identificar, estructurar, documentar y representar las
necesidades para todos los usuarios finales del sistema.
2.3.1 IDENTIFICACIÓN DE LOS PUNTOS DE VISTA
El primer paso es identificar los posibles puntos de vista. Para lograr esto se realiza la lluvia de
ideas.
Con la lluvia de ideas se puede identificar los puntos de vista potenciales (fondo verde), los
servicios asociados o servicios del sistema (fondo celeste) y los servicios no asociados (fondo
rosado), donde los requisitos funcionales y no funcionales serán evidenciados.
35
Figura 2.8.- Lluvia de ideas
2.3.2 REQUERIMIENTOS FUNCIONALES
A continuación se asocian los servicios con las entidades del sistema:
Tabla 2.16.- Requerimientos funcionales
Administrador Residente AlmacenesLista de servicios Lista de servicios Lista de servicios
36
Adicionar Actividad de
Volqueta
Agregar Insumo
Seguridad
Registrar Personas
Registrar Proyecto
Registrar Vales
AlmaceneroRendimiento
Registrar Parte Diario de Equipo
Pesado
Registrar Usuario
Extensibilidad
Liquidar Equipo Pesado
Amigabilidad
Registrar Empleado
Registrar Propietarios
Administrador
Registrar Vehículos
Registrar Parte Diario Volquetas
Pagar Liquidación
Residente de Obra
Registrar Compras
Adicionar Actividad de
Equipo Pesado
Pagar Liquidación
Registrar Claves
Registrar Propietarios Registrar Personas Registrar Vehículos Registrar Empleado Liquidar Equipo Pesado Pagar Liquidación Registrar Usuario Registrar Claves Registrar Proyecto
Registrar Parte Diario de Equipo Pesado
Adicionar Actividad de Volqueta
Registrar Parte Diario Volquetas
Adicionar Actividad de Equipo Pesado
Registrar Compras Registrar Vales Agregar Insumo
2.3.3 JERARQUÍA DE PUNTOS DE VISTA
Se organiza los puntos de vista en una jerarquía de herencia, para mostrar las partes que tienen en
común y reutilizar la información de los mismos. En la figura 2.2 se muestra la jerarquía de
puntos de vista para el sistema.
Figura 2.9: Jerarquía de los puntos de vista.
2.3.4 REQUERIMIENTOS FUNCIONALES
A continuación se presenta el resumen de funcionalidades que el sistema debe cumplir.
1. Registrar Propietarios
2. Registrar Personas
3. Registrar Vehículos
4. Registrar Empleado
5. Liquidar Equipo Pesado
6. Pagar Liquidación
37
Todos los puntos de vista
Residente de ObraAlmacenero Administrador
Personal de Empresa Constructora
7. Registrar Usuario
8. Registrar Claves
9. Registrar Proyecto
10. Registrar Parte Diario de Equipo Pesado
11. Adicionar Actividad de Volqueta
12. Registrar Parte Diario Volquetas
13. Adicionar Actividad de Equipo Pesado
14. Registrar Compras
15. Registrar Vales
16. Agregar Insumo
2.3.5 REQUERIMIENTOS NO FUNCIONALES
Los Requerimientos no funcionales generales estarán enmarcados en los siguientes aspectos:
Tabla 2.17.- Requerimientos no funcionales
Símbolo Atributo DescripciónA1 Seguridad La aplicación debe reflejar patrones de seguridad teniendo en
cuenta la importancia de la información que se maneja (manejo de usuarios, contraseñas y copias de seguridad).
A2 Amigabilidad El sistema debe ser de fácil manejo para el usuario final.A3 Rendimiento El tiempo de ejecución de una petición no debe prolongarse,
las respuestas deben ser inmediatas.A4 Extensibilidad El sistema debe tener una estructura de código que permita
cambios los cuales no obliguen al cambio del código total (Adición de nuevas funciones).
CAPITULO 338
ANALISIS
3.1. MODELO DE CASOS DE USO DEL SISTEMA
Para una mejor comprensión de los casos de uso se realiza el diagrama de paquetes, el cual se
muestra en la siguiente figura.
Almacenes
Administrador
Residente
Validar usuario
Figura 3.1.- Diagrama de Paquetes del Sistema
3.1.1. DIAGRAMA DE CASOS DE USO: PAQUETE VALIDAR USUARIO
AdministradorResidente
Almacenes
Validar Usuario
Usuario
Cambiar Clave
Figura 3.2.- Caso de uso Paquete Validar Usuario
3.1.2. DIAGRAMA DE CASOS DE USO: PAQUETE ADMINISTRADOR
39
Registrar Personas
Registrar Vehiculos
Registrar PropietariosRegistrar Empleado
Registrar ProyectoRegistrar Claves
Liquidar Equipo Pesado
Registrar Usuario
Registrar Parametros
Administrador
<<include>>
<<include>>
<<include>>
Pagar Liquidacion
<<include>>
Figura 3.3.- Caso de uso Paquete Administrador
3.1.3. DIAGRAMA DE CASOS DE USO: PAQUETE RESIDENTE
Registrar Nuevo Parte Diario de Equipo Pesado
Adicionar Actividad de Equipo Pesado
Editar Parte Diario de Volqueta
Adicionar Actividad de VolquetaRegistrar Parte Diario de
Equipo Pesado
<<include>>
Registrar Parte Diario Volquetas
Residente
Registrar Nuevo Parte Diario de Volqueta
<<include>>
<<extend>> <<extend>>
<<extend>><<extend>>
Editar Actividad de Equipo Pesado
Editar Parte Diario Equipo Pesado
<<extend>>
<<extend>>
<<extend>>
Editar Atividad de Volqueta<<extend>>
Figura 3.4.- Caso de uso Paquete Residente
3.1.4. DIAGRAMA DE CASOS DE USO: PAQUETE ALMACENES
40
Comprar
Editar Insumo
Registrar Nuevo Vale
Editar Vales
Registrar Compras
<<extend>>
Registrar Vales
<<include>>
Almacenes
<<extend>>
Registrar Nuevo Insumo
<<extend>>
<<include>>
<<extend>>
<<extend>>
Figura 3.5.- Caso de uso Paquete Almacenes
3.2 DESCRIPCION DE ACTORES
Tabla 3.1.- Descripción del Actor Administrador
ACTOR Administrador
CASOS DE USO Registrar Propietarios, Registrar Personas, Registrar Vehiculos,
Registrar Empleado, Registrar Parametros, Liquidar Equipo Pesado,
Pagar Liquidacion, Registrar Usuario, Registrar Claves, , Registrar
Proyecto.
DESCRIPCIÓN DEL ACTOR: Es el usuario encargado de registrar a los usuarios,
empleados, proyectos. Verifica los datos para la liquidación de equipo pesado y volquetas.
Tabla 3.2.- Descripción del Actor Residente
ACTOR Residente
CASOS DE USO Registrar Parte Diario de Equipo Pesado, Editar Parte Diario Equipo
Pesado, Adicionar Actividad de Volqueta, Registrar Nuevo Parte
Diario de Equipo Pesado, Registrar Parte Diario Volquetas, Registrar
Nuevo Parte Diario de Volqueta, Editar Parte Diario de Volqueta,
Adicionar Actividad de Equipo Pesado, Editar Actividad de Equipo
41
Pesado, Editar Actividad de Volqueta
DESCRIPCIÓN DEL ACTOR: Es el usuario encargado de registrar las partes diarias del
equipo pesado y volquetas, además de registrar los datos para la liquidación.
Tabla 3.3.- Descripción del Actor Almacenes
ACTOR Almacenes
CASOS DE USO Registrar Compras, Comprar, Editar Insumo, Registrar Vales,
Registrar Nuevo Vale, Editar Vales, Agregar Insumo
DESCRIPCIÓN DEL ACTOR: Es el usuario encargado de administrar los insumos
requeridos para la ejecución del proyecto. Estos insumos, son específicamente, para el
funcionamiento del equipo pesado y volquetas.
Tabla 3.4.- Descripción del Actor Usuario
ACTOR Usuario
CASOS DE USO Validar Usuario, Cambiar Clave
DESCRIPCIÓN DEL ACTOR: Representa a todos los actores que tendrán acceso al
sistema.
3.3. ESPECIFICACIÓN DE CASOS DE USO DEL SISTEMA
3.3.1 CASO DE USO: VALIDAR USUARIO
Figura 3.6.- Pantalla de acceso al sistema
Tabla 3.5.- Descripción del caso de uso Validar Usuario
ACTORES Usuario
PROPOSITO Restringir el acceso al sistema
42
RESUMEN
El usuario debe iniciar sesión, el sistema valida los datos para dar acceso o no al usuario.
ACCION DEL ACTOR ACCION DEL SISTEMA
1.- Ingresar su nombre de usuario y contraseña en la Pantalla de acceso al sistema.
2.- Si los datos son correctos, el sistema muestra la pantalla principal de acuerdo al rol que se ha asignado al usuario.3.- Caso contrario vuelve a la pantalla de acceso al sistema, solicitando de nuevo el nombre del usuario y contraseña del mismo.
3.3.2 CASO DE USO: CAMBIAR CLAVE
Figura 3.7.- Pantalla Cambiar clave
Tabla 3.6.- Descripción del caso de uso Cambiar clave
ACTORES Usuario
PROPOSITO Cambiar clave del usuario
RESUMEN
En este caso de uso, los usuarios tienen la opción de cambiar su clave para mayor control y restricción del sistema.
ACCION DEL ACTOR ACCION DEL SISTEMA
1. En la pantalla Cambiar clave, el usuario ingresa los datos.2. En la misma pantalla presiona el botón Aceptar
3. El sistema guarda la clave modificada.4. El sistema muestra la anterior pantalla que desplegaba el sistema antes que se ejecute este caso de uso.
3.3.3. Caso de uso: Registrar Parte Diario de Equipo Pesado
43
Figura 3.8.- Pantalla Registrar Parte Diario de Equipo Pesado
Tabla 3.7.- Descripción del caso de uso Registrar Parte Diario de Equipo Pesado ACTORES Residente
PROPOSITO Este caso de uso permite buscar equipo pesado e ingresar uno nuevo.
RESUMEN
Busca equipo pesado de acuerdo al código y crea uno nuevo con la asignación de código.
ACCION DEL ACTOR ACCION DEL SISTEMA
1.- El usuario introduce un código de equipo pesado y selecciona la opción buscar.
3.- Si el Residente desea editar los datos de un determinado equipo pesado puede seleccionar la opción editar.
5.- Si el Residente desea enviar la información del equipo pesado seleccionado al administrador, debe optar por la opción enviar.
7.- Si el Residente desea registrar un equipo pesado nuevo, tendrá que seleccionar la opción nuevo
9.- Si el Residente va a imprimir el informe de Parte Diario de un Equipo Pesado seleccionado
2.- El sistema despliega en la pantalla Registrar Parte Diario de Equipo Pesado la información correspondiente de todos los equipos con el código respectivo.
4.- El sistema ejecuta el caso de uso: Editar Parte Diario de Equipo Pesado
6.- El sistema envía los datos a la base de datos del usuario administrador.
8.- El sistema ejecuta el caso de uso Registrar Nuevo Parte Diario de Equipo Pesado.
44
10.- El sistema imprime el informe.
3.3.4. Caso de uso: Registrar Nuevo Parte Diario de Equipo Pesado
Figura 3.9.- Pantalla Editar Parte Diario de Equipo Pesado
Tabla 3.8.- Descripción del caso de uso Editar Parte Diario de Equipo Pesado
ACTORES Residente
PROPOSITO Este caso de uso permite editar los datos de un determinado equipo pesado.
RESUMEN
El Residente puede editar los datos del equipo pesado.
ACCION DEL ACTOR ACCION DEL SISTEMA
1.- El Residente puede cambiar cualquiera de los campos2.- Si el Residente desea adicionar alguna actividad del equipo pesado, entonces debe seleccionar adicionar.
3.- Si el Residente desea editar alguna actividad, debe seleccionar la opción editar.
5.- Si el Residente desea eliminar una actividad
2.- El sistema ejecuta el caso de uso Adicionar Actividad de Equipo Pesado.
4.- El sistema ejecuta el caso de uso Editar Actividad de Equipo Pesado.
45
específica.
7.- Si el Residente va a guardar los datos cambiados presiona el botón Aceptar.
9.- Si el Residente no va a realizar ningún cambio presiona el botón Cancelar
6.- El sistema borra el registro de la actividad seleccionada.
8.- El sistema guarda los datos modificados y ejecuta el caso de uso Registrar Parte Diario de Equipo Pesado.
10.- El sistema ejecuta el caso de uso Registrar Parte Diario de Equipo Pesado.
3.3.5 Caso de uso: Adicionar Actividad de Equipo Pesado
Figura 3.10.- Pantalla Editar Actividad de Equipo Pesado
Tabla 3.9.- Descripción del caso de uso Editar Actividad de Equipo Pesado
ACTORES Residente
PROPOSITO Cambiar información con referencia a la actividad del equipo pesado
RESUMEN
El Residente adiciona los campos requeridos para la descripción de la actividad de un determinado parte diario.
46
ACCION DEL ACTOR ACCION DEL SISTEMA
1.- El Residente selecciona clave de actividad.2.- Describe la actividad seleccionada.3.- Ingresa las horas de trabajo y las horas no operadas.4.- Si va a guardar la información, presiona el botón aceptar.
6.- Si no va a adicionar ninguna actividad. Presiona el botón Cancelar.
5.- El sistema guarda los datos de la nueva actividad y ejecuta el caso de uso Editar Parte Diario de Equipo Pesado.
7.- El sistema ejecuta el caso de uso Editar Parte Diario de Equipo Pesado
3.3.6 Caso de uso: Registrar Parte Diario de Volqueta
Figura 3.11.- Pantalla Registrar Parte Diario de Volqueta
Tabla 3.10.- Descripción del caso de uso Registrar Parte Diario de Volqueta ACTORES Residente
PROPOSITO Este caso de uso permite buscar volqueta e ingresar uno nuevo.
RESUMEN
Busca Volqueta de acuerdo al código y crea uno nuevo con la asignación de código.
ACCION DEL ACTOR ACCION DEL SISTEMA
47
1.- El usuario introduce un código de Volqueta y selecciona la opción buscar.
3.- Si el Residente desea editar los datos de un determinada Volqueta puede seleccionar la opción editar.
5.- Si el Residente desea enviar la información de la Volqueta seleccionado al administrador, debe optar por la opción enviar.
7.- Si el Residente desea registrar una Volqueta nuevo, tendrá que seleccionar la opción nuevo
9.- Si el Residente va a imprimir el informe de Parte Diario de una volqueta seleccionada
2.- El sistema despliega en la pantalla Registrar Parte Diario de Volqueta la información correspondiente de todos las Volquetas con el código respectivo.
4.- El sistema ejecuta el caso de uso: Editar Parte Diario de Volqueta
6.- El sistema envía los datos a la base de datos del usuario administrador.
8.- El sistema ejecuta el caso de uso Registrar Nuevo Parte Diario de Volqueta.
10.- El sistema imprime el informe.
3.3.7 Caso de uso: Editar Parte diario de Volqueta
48
Figura 3.12.- Pantalla Editar Parte Diario de Volqueta
Tabla 3.11.- Descripción del caso de uso Editar Parte Diario de Volqueta ACTORES Residente
PROPOSITO Este caso de uso permite editar los datos de un determinada Volqueta.
RESUMEN
El Residente puede editar los datos de Volqueta.
ACCION DEL ACTOR ACCION DEL SISTEMA
1.- El Residente puede cambiar cualquiera de los campos2.- Si el Residente desea adicionar alguna actividad de Volqueta, entonces debe seleccionar adicionar.
3.- Si el Residente desea editar alguna actividad, debe seleccionar la opción editar.
5.- Si el Residente desea eliminar una actividad específica.
7.- Si el Residente va a guardar los datos cambiados presiona el botón Aceptar.
2.- El sistema ejecuta el caso de uso Adicionar Actividad de Volqueta.
4.- El sistema ejecuta el caso de uso Editar Actividad de Volqueta.
6.- El sistema borra el registro de la actividad seleccionada.
8.- El sistema guarda los datos modificados y ejecuta 49
9.- Si el Residente no va a realizar ningún cambio presiona el botón Cancelar
el caso de uso Registrar Parte Diario de Volqueta.
10.- El sistema ejecuta el caso de uso Registrar Parte Diario de Volqueta.
3.3.8 Caso de uso: Adicionar actividad de volqueta
Figura 3.13.- Pantalla Adicionar actividad de volqueta
Tabla 3.12.- Descripción del caso de uso Adicionar actividad de volqueta
ACTORES Residente
PROPOSITO Cambiar información con referencia a la actividad del equipo pesado
RESUMEN
El Residente adiciona los campos requeridos para la descripción de la actividad de un determinado parte diario.
ACCION DEL ACTOR ACCION DEL SISTEMA
1.- El Residente selecciona clave de actividad.2.- Describe la actividad seleccionada.3.- Ingresa las horas de trabajo y las horas no operadas.4.- Si va a guardar la información, presiona el botón aceptar. 5.- El sistema guarda los datos de la nueva actividad y
50
6.- Si no va a adicionar ninguna actividad. Presiona el botón Cancelar.
ejecuta el caso de uso Editar Parte Diario de Volqueta.
7.- El sistema ejecuta el caso de uso Editar Parte Diario de Volqueta
3.3.9 Caso de uso: Registrar compras
Figura 3.14.- Pantalla Registrar compras
Tabla 3.13.- Descripción del caso de uso Registrar comprasACTORES Almacenes
PROPOSITO Registrar compras que se realiza para el abastecimiento del almacén
RESUMEN
El usuario inicia el caso de uso, elige un insumo, para realizar la compra. También puede añadir o editar insumos.
ACCION DEL ACTOR ACCION DEL SISTEMA
1.- El usuario busca un determinado insumo.
3.- Si el usuario va a comprar el insumo buscado, elige la opción Comprar.
5.- Si el usuario va a registrar un nuevo insumo, presiona el botón Nuevo.
2.- El sistema muestra el insumo buscado.
4.- El sistema ejecuta el caso de uso Comprar
6.- El sistema ejecuta el caso de uso Registrar Nuevo
51
7.- Si el usuario va a cambiar los datos de un insumo, elige la opción editar de un insumo.
insumo.
8.- El sistema ejecuta el caso de uso Editar insumo.
3.3.10 Caso de uso: Editar insumo
Figura 3.15.- Pantalla Editar insumo
Tabla 3.14.- Descripción del caso de uso Editar insumo
ACTORES Almacenes
PROPOSITO Cambiar los datos de un insumo
RESUMEN
El usuario inicia el caso de uso. Cambia los datos de un determinado insumo y guarda los mismos.
ACCION DEL ACTOR ACCION DEL SISTEMA
1.- Cambia los datos necesarios.2.- Selecciona el tipo de insumo.3.- Si decide guardar los cambios efectuados, presiona el botón Aceptar.
5.- Si decide no efectuar los cambios, presiona el botón Cancelar.
4.- El sistema guarda los datos modificados en el registro y ejecuta el caso de uso Registrar compras.
6.- El sistema ejecuta el caso de uso Registrar
52
compras
3.3.11 Caso de uso: Registrar Nuevo insumo
Figura 3.16.- Pantalla Registrar Nuevo insumo
Tabla 3.15.- Descripción del caso de uso Registrar Nuevo insumo
ACTORES Almacenes
PROPOSITO Registrar los datos de un insumo
RESUMEN
El usuario inicia el caso de uso. Registra los datos de un insumo y guarda los mismos.
ACCION DEL ACTOR ACCION DEL SISTEMA
1.- ingresa los datos necesarios.2.- Selecciona el tipo de insumo.3.- Si decide guardar los datos ingresados, presiona el botón Aceptar.
5.- Si decide no efectuar los cambios, presiona el botón Cancelar.
4.- El sistema guarda los datos ingresados y ejecuta el caso de uso Registrar compras.
6.- El sistema ejecuta el caso de uso Registrar compras
53
CAPITULO 4DISEÑO DEL SISTEMA
4.1 DIAGRAMA DE INTERACCION
4.1.1 DIAGRAMA DE SECUENCIA54
Caso de uso: Validar Usuario
: Usuario : Usuario : Validar : Validar : Usuarios : Usuarios : CValidar : CValidar : PantallaPrincipal : PantallaPrincipal : FPantallaPrincipal : FPantallaPrincipal
Ingresa(usuario,clave)
Opcion(acceso)
Valida(usuario,clave)
Verifica(usuario,clave)
Actualiza()
Mostrar()
Figura 4.1.- Diagrama de secuencia Validar Usuario
Caso de uso: Cambiar Clave
: Usuario : Usuario : PantallaPrincipal : PantallaPrincipal : CPantallaPrincipal
: CPantallaPrincipal
: CambiarClave : CambiarClave : Usuarios : Usuarios : CCambiarClave : CCambiarClave
Opcion(Cambiar Clave)
Opcion(CambiarClave)
Mostrar()
Opcion(aceptar)
Registrar(NuevaClave)
Cambiar(NuevaClave)
Ingresar(NuevaClave)
Mostrar()
Figura 4.2.- Diagrama de secuencia Cambiar Clave
Caso de uso: Registrar Parte Diario de Equipo Pesado
55
: Residente : Residente : PantallaPrincipal : PantallaPrincipal : CPantallaPrincipal
: CPantallaPrincipal :
PartediarioEquipoPesado :
PartediarioEquipoPesado
: Asignaciones : Asignaciones : CPartediarioEquipoPesado
: CPartediarioEquipoPesado
: FPartediarioEquipoPesado
: FPartediarioEquipoPesado
: EditarPartediarioEP : EditarPartediarioEP : NuevoPartediarioEP : NuevoPartediarioEP
Opcion(ParteDiarioEquipoPesado)
Opcion(ParteDiarioEquipoPesado)
Mostrar()
Ingresa(Codigo)
Opcion(Buscar)
Opcion(Buscar)
Buscar(Codigo)
Actualizar(Codigo)
Mostrar()
Opcion(imprimir)
Opcion(Imprimir)
Imprimir(Codigo)
Opcion(Enviar)
Enviar(Codigo)
Opcion(Editar)
Opcion(Nuevo)
Opcion(Editar)
Opcion(Nuevo)
Habilitar(Codigo)
Mostrar()
Figura 4.3.- Diagrama de secuencia Registrar Parte Diario de Equipo Pesado
Caso de uso: Editar Parte Diario de Equipo Pesado
56
Figura 4.4.- Diagrama de secuencia Editar Parte Diario de Equipo Pesado
57
: Ad
icio
narA
ctiv
idad
: Ad
icio
narA
ctiv
idad
: R
esid
ente
: R
esid
ente
: E
dita
rPar
tedi
ario
EP
: E
dita
rPar
tedi
ario
EP
: P
arte
diar
ioE
quip
oPes
ado
: P
arte
diar
ioE
quip
oPes
ado
: C
Par
tedi
ario
Equ
ipoP
esad
o :
CP
arte
diar
ioE
quip
oPes
ado
: Ac
tivid
ades
: Ac
tivid
ades
: As
igna
cion
es :
Asig
naci
ones
: E
mpl
eado
s :
Em
plea
dos
: Ve
hicu
los
: Ve
hicu
los
: E
dita
rAct
ivid
ad :
Edi
tarA
ctiv
idad
Sel
ecci
ona(
Obr
a)
Sel
ecci
ona
(Ope
rado
r)
Sel
ecci
ona(
Cod
igo)
Ingr
esa(
fech
a,lu
gar,
ent1
,ent
2,sa
l1,s
al2)
Opc
ión(
Adic
iona
r)
Opc
ión(
Adic
iona
r)
Mos
trar(
)
Opc
ion(
Edi
tar)
Opc
ion(
Edi
tar)
Mos
trar(
)O
pcio
(Elim
inar
)
Elim
inar
(Act
ivid
ad)
Bor
rar(
Activ
idad
)
Ingr
esar
(HI,H
F,K
I,KF)
Opc
ion(
Acep
tar)
Opc
ion(
Acep
tar)
Asig
nar(
Ope
rado
r)
Asig
na(O
pera
dor)
Asig
na(C
odig
o)
Asig
na(C
odig
o)
Gua
rda(
fech
a,lu
gar,
ent1
,ent
2,sa
l1,s
al2,
HI.H
F,K
I,KF)
Opc
ion(
Can
cela
r)
Opc
ion(
Can
cela
r) Mos
trar(
)
4.1.2 DIAGRAMA DE COLABORACION
Caso de uso: Validar Usuario
: Usuario
: Usuarios
: PantallaPrincipal
: Validar
: CValidar
: FPantallaPrincipal
1: Ingresa(usuario,clave)2: Opcion(acceso)3: Valida(usuario,clave)
4: Verifica(usuario,clave)
5: Actualiza()
6: Mostrar()
Figura 4.5.- Diagrama de colaboración Validar Usuario
Caso de uso: Cambiar Clave
: Usuario
: Usuarios
: CCambiarClave
: CambiarClave
: CPantallaPrincipal
: PantallaPrincipal
1: Opcion(Cambiar Clave)
2: Opcion(CambiarClave)
3: Mostrar()4: Ingresar(NuevaClave)5: Opcion(aceptar)
6: Registrar(NuevaClave)
7: Cambiar(NuevaClave)
8: Mostrar()
Figura 4.6.- Diagrama de colaboración Cambiar Clave
Caso de uso: Registrar Parte Diario de Equipo Pesado
58
: Asignaciones
: Residente
: PartediarioEquipoPesado
: FPartediarioEquipoPesado
: CPartediarioEquipoPesado
: CPantallaPrincipal
: PantallaPrincipal
: EditarPartediarioEP
: NuevoPartediarioEP
1: Opcion(ParteDiarioEquipoPesado)
2: Opcion(ParteDiarioEquipoPesado)
3: Mostrar()
4: Ingresa(Codigo)5: Opcion(Buscar)
6: Opcion(Buscar)7: Buscar(Codigo)
8: Actualizar(Codigo)
9: Mostrar()
10: Opcion(imprimir)
11: Opcion(Imprimir)
12: Imprimir(Codigo)
13: Opcion(Enviar)
14: Enviar(Codigo)
15: Opcion(Editar)
16: Opcion(Editar)
17: Habilitar(Codigo)
18: Opcion(Nuevo)
19: Opcion(Nuevo)
20: Mostrar()
Figura 4.7.- Diagrama de colaboración Registrar Parte Diario de Equipo Pesado
59
Caso de uso: Editar Parte Diario de Equipo Pesado
: Asignaciones
: Empleados
: Vehiculos
: Residente
: CPartediarioEquipoPesado
: EditarPartediarioEP
: AdicionarActividad
: EditarActividad
: Actividades
: PartediarioEquipoPesado1: Selecciona(Obra)
2: Selecciona (Operador)3: Selecciona(Codigo)
4: Ingresa(fecha,lugar, ent1,ent2,sal1,sal2)5: Opción(Adicionar)
6: Opción(Adicionar)
7: Opcion(Editar)
8: Mostrar()
9: Opcion(Editar)
10: Mostrar()
11: Opcio(Eliminar)
12: Eliminar(Actividad)
13: Borrar(Actividad)
14: Ingresar(HI,HF,KI,KF)15: Opcion(Aceptar)
16: Opcion(Aceptar)17: Asignar(Operador)
18: Asigna(Operador)
19: Asigna(Codigo)
20: Asigna(Codigo)
21: Guarda(fecha,lugar, ent1,ent2,sal1,sal2,HI.HF,KI,KF)
22: Opcion(Cancelar)
23: Opcion(Cancelar)
24: Mostrar()
Figura 4.8.- Diagrama de colaboración Editar Parte Diario de Equipo Pesado
4.2 DIAGRAMA DE CLASES PERSISTENTE PARA LA BASE DE DATOS
Un diagrama de clases persistente sirve para visualizar las relaciones entre las clases persistentes
que involucran el sistema. Una clase es una categoría o grupo de casos u objetos que tiene
atributos y acciones.
60
A continuación se presenta el diagrama de clases persistente del sistema para el presente
proyecto.
Propietarioscodpropietario : Integertipo : String
insertar()buscar()modificar()eliminar()listar()
Proyectoscodproyecto : Integerdescripcion : Stringfecha_inicio : Datefecha_final : Date
insertar()modificar()eliminar()listar()
Insumoscodinsumo : Integerdescripcion : Stringtipo : Stringunidad : String
insertar()listar()
Valescodvale : Integercodempleado : Integercodinsumo : Integercantidad : Integerprecio_unitario : Double
buscar()modificar()listar()
*
1
*
1
Detallescoddetalle : Integercantidad : Integerprecio_unitario : Double
insertar()modificar()
*
1
*
1
*
1
*
1
Pedidoscodpedido : Integerdescripcion : String
insertar()buscar()modificar()eliminar()listar()1
*
1
*
Proveedorescodproveedor : Integercodpersona : Integernit : Integerestacion_dir : String
insertar()buscar()listar()modificar()eliminar()
1
*
1
*
Usuarioscodusuario : Integerusuario : Stringclave : String
insertar()modificar()eliminar()
Clavescodclave : Integerdescripcion : String
insertar()modificar()eliminar()
Personascodpersona : Integernombre : Stringci : Integertelefono : Integercelular : Integer
insertar()modificar()eliminar()buscar()listar()
1
*
1
*
*1
*1
*
1
*
1
Empleadoscodempleado : Integerlicencia : Stringfecha : Datefecha_ingreso : Dateprofesion : String
insertar()buscar()modificar()eliminar()listar()
*
1
*
1
Vehiculoscodvehiculo : Integertipo : Stringdescripcion : String
insertar()buscar()eliminar()lis tar()
1
*
1
*
Asignacionescodasignacion : Integerfecha_inicial : Datefecha_final : Datesector : Stringobservacion : Stringtipo : Stringentrada1 : Stringentrada2 : Stringsalida1 : Stringsalida2 : StringHI : StringHF : StringKI : StringKF : StringpregI : StringpregF : StringpregHI : StringpregHF : String
insertar()listar()
1
*
1
*
1
*
1
*
Actividadescodactividad : Integercoditem : Integerdescripcion : StringHNO : StringHT : String
listar()
1
*
1
*
1
*
1
*
Itemscoditem : Integerdescripcion : Stringfecha_inicio : Datefecha_final : Date
insertar()modificar()
*
1
*
1
1
n
1
n
Figura 4.2.- Diagrama persistente para la base de datos
61
4.3 MODELO RELACIONAL
Figura 4.10.- Modelo Relacional
62
4.4 ESTRUCTURA DE LA BASE DE DATOS
Tabla 4.1.-Actividades
Campo Tipo Primary Key
Foreing Key Descripción
codactividad int(11) Código de la tabla actividades
codasignacion int(11) Código de la tabla asignaciones
codclave int(11) Código de la tabla claves
descripcion varchar(100) Describir en detalle el tipo de trabajo realizado y el motivo por el que se encuentra en reparación o inactivo el Equipo Pesado.
HNO varchar(100) Horas no operadas por el equipo Pesado
HT varchar(100) Horas Operadas por el Equipo Pesado
Tabla 4.1.-Asignaciones
Campo Tipo Primary Key
Foreing Key Descripción
codasignacion int(11) Código de la tabla asignaciones
codempleado int(11) Código de la tabla empleados
codvehiculo int(11) Código de la tabla vehículos
fecha_inicial date Fecha inicial del trabajo del Equipo
fecha_final date Fecha final del trabajo del Equipo
sector varchar(100) Lugar donde se está realizando el trabajo
observacion varchar(100) Alguna observación en la asignación
tipo varchar(100) Tipo de asignación
entrada1 varchar(100) Hora de ingreso del equipo durante el transcurso de la mañana
entrada2 varchar(100) Hora de Salida del Equipo durante el transcurso de la mañana
salida1 varchar(100) Hora de ingreso del equipo durante el transcurso de la tarde
salida2 varchar(100) Hora de ingreso del equipo durante el transcurso de la tarde
HI varchar(100) Lectura del Horometro de inicio de trabajo
63
HF varchar(100) Lectura del Horometro de final de trabajo
KI varchar(100) Lectura del Kilometraje de inicio de jornada de trabajo
KF varchar(100) Lectura del Kilometraje de final de jornada
pregI varchar(100) Punto de inicio de transporte
pregF varchar(100) Punto final de transporte
pregHI varchar(100) Hora inicial de trabajo
pregHF varchar(100) Hora final de trabajo
Tabla 4.3.-Claves
Campo Tipo Primary Key
Foreing Key Descripción
codclave int(11) Código de la tabla claves
descripcion varchar(100) Descripción de la tabla claves
Tabla 4.4.-Detalles
Campo Tipo Primary Key
Foreing Key Descripción
coddetalle int(11) Código de la tabla detalles
codpedido int(11) Código de la tablas pedidos
codinsumo int(11) Código de la tabla insumos
codvale int(11) Código de la tabla vales
cantidad int(11) Cantidad de insumo
precio_unitario float Costo unitario del insumo
Tabla 4.5.-Empleados
Campo Tipo Primary Key
Foreing Key Descripción
codempleado int(11) Código de la tabla empleados
codpersona int(11) Código de la tabla personas
licencia varchar(100) Numero de licencia de conducir
fecha date Fecha actual del día
fecha_ingreso date Fecha de ingreso para inicio de trabajo
64
profesion varchar(100) Ocupación que desempeña
Tabla 4.6.-Insumos
Campo Tipo Primary Key
Foreing Key
Descripción
codinsumo int(11) Código de la tabla insumos
descripcion varchar(100) Descripción del insumo que se está
usando
tipo varchar(100) Tipo de insumo que se está usando
unidad varchar(100) Número de piezas o litros de insumo
Tabla 4.7.-Items
Campo Tipo Primary Key
Foreing Key
Descripción
coditem int(11) Código de la tabla ítems
codproyecto int(11) Código de la tablas proyectos
descripcion varchar(100) Descripción de item
fecha_inicio date Fecha de inicio de trabajo en obra
fecha_final date Fecha final de culminación en obra
Tabla 4.8.-Pedidos
Campo Tipo Primary Key
Foreing Key
Descripción
codpedido int(11) Código de la tabla pedidos
codproveedor int(11) Código de la tabla proveedores
descripcion varchar(100
)
Descripción de los pedidos
Tabla 4.9.-Personas
Campo Tipo Primary Key
Foreing Key
Descripción
codpersona int(11) Codigo de la tabla personas
65
nombre varchar(100) Nombre del usuario
ci int(7) Numero de cedula de identidad
telefono int(7) Número de teléfono del usuario
celular int(7) Numero de celular
Tabla 4.10.-Propietarios
Campo Tipo Primary Key
Foreing Key
Descripción
codpropietario int(11) Código de la tabla propietarios
codpersona int(11) Código de la tabla personas
codvehiculo int(11) Código de la tabla vehiculos
tipo varchar(100) Tipo de propietario
Tabla 4.11.-Proveedores
Campo Tipo Primary Key
Foreing Key
Descripción
codproveedor int(11) Código de la tabla proveedores
codpersona int(11) Código de la tabla personas
nit int(11) Numero de NIT del proveedor
estacion_dir varchar(100) Nombre de la estación de Servicio
Tabla 4.12.-Proyectos
Campo Tipo Primary Key
Foreing Key
Descripción
codproyecto int(11) Código de la tabla proyectos
descripcion varchar(200) Descripción del proyecto a ejecutar
fecha_inicio date Fecha de inicio del proyecto
fecha_final date Fecha de conclusión del proyecto
Tabla 4.13.-Usuarios
Campo Tipo Primary Key
Foreing Key
Descripción
codusuario int(11) Código de la tabla usuarios
codpersona int(11) Codigo de la tabla personas
usuario varchar(100) Nombre del usuario
66
clave varchar(100) Clave asignado al usuario
Tabla 4.14.-Vales
Campo Tipo Primary Key
Foreing Key
Descripción
codvale int(11) Código de la tabla vales
codempleado int(11) Código de la tabla empleados
codinsumo int(11) Código de la tabla insumos
cantidad int(11) Cantidad del insumo entregado
precio_unitari
o
float Precio referencial del insumo
Tabla 4.15.-Vehiculos
Campo Tipo Primary Key
Foreing Key
Descripción
codvehiculo int(11) Código de la tabla vehículos
tipo varchar(50) Tipo de vehículo
descripcion varchar(100) Descripción del vehículo asignado
67
CAPITULO 5IMPLEMENTACION
5.1. DIAGRAMA DE COMPONENTES
Navegador(html)
Interfaz de Controlador
Interfaz de Base de Datos
Base de Datos MySql
Scripts(js, html, css)
Figura 5.1.- Diagrama de componentes
5.2 DIAGRAMA DE DESPLIEGUE
Servidor de Base de Datos
Impresora
Servidor Web
Navegador Usuario
TCP/IP
USB
TCP/IP
Figura 5.2: Diagrama de despliegue
68
5.3 PRESENTACION DE INTERFACES
A continuación se muestran algunas interfaces del sistema por casos de uso, para más
información Ver Anexo B.
Caso de uso: Validar Usuario
Interfaz Validar Usuario
Caso de uso: Registrar Personas
69
Interfaz Registrar Personas
Este caso de uso presenta además las siguientes interfaces, que se muestran a continuación.
70
Interfaz Registrar Personas - Eliminar Registro de una persona
Interfaz Registrar Personas - Editar Registro de una persona
Caso de uso: Registrar Parte diario de Equipo pesado
71
Registrar Parte diario de Equipo pesado
Caso de uso: Cambiar Clave
Interfaz Cambiar ClaveCAPITULO 6
COSTO DEL SISTEMA
6.1 ESTIMACIÓN DE SOFTWARE BASADA EN PUNTOS DE CASOS DE USO
Uno de los métodos utilizados para estimar el esfuerzo de desarrollo de software se basa en
modelos de Casos de Uso, técnica ampliamente difundido para describir la interacción de los
usuarios con un sistema de software. Gustav Karner [KAR1993], tomó el modelo de Casos de
Uso para mejorar la técnica de Puntos de Función, en la estimación de esfuerzo en proyectos de
software.
6.2.1 CLASIFICACIÓN DE LOS ACTORES INVOLUCRADOS
Los actores involucrados en los casos de uso se clasifican de acuerdo a su característica
intrínseca y la forma en que interactúan con el sistema. Un actor simple (peso=1) es aquel que
representa una interfaz de programación o API; un actor medio (peso=2) es aquel que interactúa
mediante un protocolo y un actor complejo (peso=3) es aquel que interactúa por medio de una
72
interfaz gráfica. A cada actor de acuerdo a esta clasificación le corresponde un valor el cual se
denomina peso.
6.2.2 CLASIFICACIÓN DE CASO DE USO
Los casos de uso son clasificados de acuerdo a la cantidad de transacciones que poseen,
incluyendo las transacciones de escenarios alternativos y excluyendo las extensiones o
inclusiones de otros casos de uso. Un caso de uso simple (peso=5) es aquel que posee 3 o menos
transacciones; uno medio (peso=10) es el que posee de 4 a 7 transacciones; y un caso de uso
complejo (peso=15) es el que posee más de 7 transacciones. Nuevamente, a cada caso de uso le
corresponde un peso.
6.2.3 FACTOR DE COMPLEJIDAD TÉCNICA DEL PROYECTO DE SOFTWARE
Los factores técnicos (T) están definidos por las influencias técnicas que puedan afectar el
proceso de desarrollo del sistema a construir. Cada factor técnico posee un grado de complejidad,
que oscila entre 0 y 5, donde 0 significa un valor irrelevante o nulo y 5 determina un valor con
alto grado de influencia. Cada factor técnico posee un valor de peso. El peso total de ese factor de
influencia técnica se obtiene con el producto entre el valor de complejidad asignado y el peso que
le corresponde al factor.
6.2.4 FACTORES DE ENTORNO DEL PROYECTO
Los factores de entorno (E) indican la influencia del grupo humano involucrado en el proyecto
sobre el sistema a desarrollar. De manera similar a los factores técnicos, los factores de entorno
poseen un grado de influencia que oscila entre 0 y 5, donde 0 significa un valor irrelevante o nulo
y 5 determina un valor con alto grado de influencia. Cada factor de entorno posee un valor de
peso. El peso total de ese factor de influencia técnica se obtiene con el producto entre el valor de
influencia asignado y el peso que le corresponde al factor de entorno.
Para determinar la estimación de los Puntos de Caso de Uso se deben cumplir los siguientes
pasos:
1. Clasificar los actores para determinar el valor de UAW (Unadjusted Actor Weight)
UAW = Sumatoria de todos los pesos de los actores identificados
73
2. Clasificar los casos de uso para determinar el valores de UUCW (Unadjusted Use Case
Weight)
UUCW= Sumatoria de los pesos de los casos de uso
3. Determinar el valor del UUCP (Unadjusted Use Case Point)
UUCP = UAW + UUCW
4. Determinar el valor de TCF (Technical Complexity Factor)
TCF= 0,6 + (0,01 * ∑(T1 ...T13))
5. Determinar el valor de EF (Enviroment Factor)
EF = 1,4 + (-0,03 * ∑(E1…E8))
6. Determinar el valor de AUCP (Adjusted Use Case Point)
AUCP = UUCP * TFC * EF
7. Calculo del esfuerzo, Karner establece un factor de 20hs hombre por punto de caso de uso para
realizar la estimación de un proyecto de software
UCP = AUCP * 20
El valor de Use Case Point (UCP) obtenido indica el esfuerzo de horas hombre que se deben
invertir para desarrollar el proyecto de software.
6.3 CALCULO DEL COSTO DEL SISTEMA
6.3.1 CLASIFICACIÓN DE LOS ACTORES DEL SISTEMA
Actores del Sistema
Administrador
Residente
Almacenes
Tabla 6.1.- Clasificación de los Actores del Sistema
Tipo de actor
Factorde peso
Número de actores
Resultado
Simple 1 0 0
Promedio 2 0 0
Complejo 3 3 9
Total 9
74
El factor de peso de los actores sin ajustar es:
UAW= 9
6.3.2 CLASIFICACIÓN DE LOS CASOS DE USO DEL SISTEMA
Casos de uso del sistema (tabla 6.2)
Tabla 6.2.- Clasificación de los Casos de Uso del Sistema
Tipo de caso de uso
Factorde peso
Número de Casos de Uso
Resultado
Simple 5 19 95
Promedio 10 10 100
Complejo 15 0
Total 195
El factor de peso de los casos de uso sin ajustar es:
UUCW= 195
6.3.3 CÁLCULOS DE LOS PUNTOS DE CASOS DE USO SIN AJUSTAR
Es la suma del factor de peso de los actores sin ajustar y el factor de peso de los casos de uso sin
ajustar.
UUCP = UAW + UUCW = 9 + 195 = 204
6.3.4 DETERMINACIÓN DEL FACTOR DE COMPLEJIDAD TÉCNICA (TCF)
Este se calcula según el valor asignado a cada factor (Tabla 6.3.).
Tabla 6.3.- Determinación del TCF
Número de factor Descripción Peso Valor Resultado
75
T1 Sistema Distribuido 2 0 0
T2 Tiempo de respuesta 1 1 1
T3 Eficiencia por el usuario 1 3 3
T4 Proceso interno complejo 1 3 3
T5 Reusabilidad 1 2 2
T6 Facilidad de instalación 0.5 1 0.5
T7 Facilidad de uso 0.5 3 1.5
T8 Portabilidad 2 3 6
T9 Facilidad de cambio 1 3 3
T10 Concurrencia 1 3 3
T11 Objetivos especiales de seguridad 1 4 4
T12 Acceso directo a terceras partes 1 0 0
T13 Facilidades especiales de entrenamiento a usuarios finales
1 0 0
Total Factor 27
TCF= 0,6 + (0,01 * ∑ (T1...T13))
TCF= 0,6 + (0,01 * 27) = 0,87
6.3.5 DETERMINACIÓN DEL FACTOR AMBIENTE
Tabla 6.4.- Determinación de EF
Número del factor Descripción Peso Valor Resultado
E1 Familiaridad con el modelo del proyecto usado.
1.5 4 6
E2 Experiencia en la aplicación 0.5 4 2
E3 Experiencia OO. 1 4 4
E4 Capacidad del analista líder. 0.5 4 2
E5 Motivación. 1 5 5
E6 Estabilidad de los requerimientos.
2 4 8
E7 Personal media jornada. -1 0 0
E8 Dificultad en lenguaje de programación.
-1 1 -1
Total 26
76
EF = 1,4 + (-0,03 * ∑(E1…E8))
EF= 1,4 + (-0,03 * 26) = 0,62
6.3.6 CALCULO DE LOS PUNTOS DE CASOS DE USO AJUSTADOS
Es el producto de los puntos de los casos de uso sin ajustar, los factores técnicos y los factores
ambientales.
AUCP = UUCP * TFC * EF = 204 * 0,87 * 0,62 = 110,04
6.3.7 CALCULO DEL ESFUERZO
E = AUCP * 20 = 110,04 * 20 = 2.201 [horas -hombre]
Cálculo del costo de desarrollo:
CS= TD*SMN
Donde:
CS: Costo del software
SMN: Salario mínimo nacional (1200 Bs.)
TD: Tiempo de desarrollo.
HM: horas al mes de trabajo.
Tomando en cuenta el trabajo 8 hrs diarios y 25 días al mes laborales, aproximadamente:
HM = 8 * 25 = 200 [hrs/mes]
TD = 2.201 [hrs/hombre] / 200 [hrs/mes]
TD= 11 [mes/hombre]
CS= TD*SMN
CS = 11 [mes/hombre]* 1.200 [Bs.]
CS= 13.200 [Bs.]
Considerando el cambio de dólar en fecha actual (Diciembre de 2013) de 6,96 Bs, entonces
77
CS= 1.896,5 $. Aproximadamente.
Por tanto, el costo del software del presente proyecto obtenido por el método basado en Puntos de
Casos de Uso es de 1.896,5 $.
Para un tiempo de desarrollo de 11 meses aproximadamente.
CAPITULO 7PRUEBA DEL SISTEMA
La aplicación de pruebas al sistema se lo realiza con el objetivo de descubrir fallas en el mismo.
En este capítulo se explicara las pruebas efectuadas al sistema.
7.1 SEGURIDAD DEL SISTEMA
El Sistema solicita un identificador de usuario y una contraseña para iniciar sesión, la cual está
protegida mediante un código de encriptación.
La aplicación para los usuarios tiene implementado una comprobación de inicio de sesión para
restringir el acceso a personal no autorizado.
7.2 PRUEBAS DE CAJA NEGRA
Las pruebas de caja negra demuestran la funcionalidad operativa del sistema. Esto se lo realiza
mediante las pruebas de corrida del programa realizadas para verificar el funcionamiento correcto
de cada uno de los módulos del sistema.
7.2.1 CASO DE PRUEBA: ACCESO AL SISTEMA
78
Figura 7.1 Acceso al Sistema
DATOS DE ENTRADA
IDENTIFICACIÓN DE CLASES EQUIVALENTES
Tabla 7.1.- Identificación de Clases Equivalentes
Condición de entrada Clases de equivalencia valida
Clases de equivalencia no valida
Cuenta 1: 0..9, a..z 2: OtroPassword 1: 0..9, a..z 2: Otro
EVALUACIÓN DE CLASES EQUIVALENTES
Tabla 7.2.- Evaluación de Clases Equivalentes
N° de caso
Clase de equivalencia Usuario Contraseña Resultado
1 1 Admin 12345 Acceso al menú principal del sistema
2 2 Administrador 123 Acceso denegado
79
Condiciones de ejecución: no existe en la tabla USUARIOS (usuario, clave) la tupla
<”Administrador”,”123”> pero si la tupla <”Admin”,”12345”>
Resultado esperado: Restringe el acceso a la tupla <”Administrador”,”123”>
Objetivo del caso de prueba: comprobar el acceso al Sistema
PROCEDIMIENTO DE LA PRUEBA:
Ejecutar la aplicación
Comprobar que en la BD, exista el usuario <”Admin”,”12345”>
Escribir “Administrador” en el interfaz grafica en el campo con etiqueta Cuenta
Escribir “123” en el interfaz grafica en el campo con etiqueta Password
Pulsar el botón Aceptar
Resultado Esperado:
El sistema restringe el acceso ver figura 8.1
Figura 7.2 Acceso Denegado al sistema
80
1.3 PRUEBA DE ACEPTACION DEL SISTEMA
Para esta prueba se realiza el método de Escalamiento de Likert.
1.3.1 MÉTODO DE ESCALAMIENTO DE LIKERT
El método de Escalamiento Likert consiste en un conjunto de ítems presentados en forma de
afirmaciones o juicios ante los cuales se pide la reacción de los sujetos a los que se les administra.
El resultado “X” obtenido de la encuesta está comprendido en el rango:0≤X≤10
; cuya relación
para determinar “X” viene dado por la siguiente relación:
X= TENE∗NI
DondeX: Ponderación obtenida resultante de la Escala.
TE: Representa el total de la evaluación de la escala de Likert, calculado por las
ponderaciones de las respuestas y sus respectivas coincidencias.
NE: Representa el número de encuestas realizadas.
NI: Es el número de ítems expuestas en el cuestionario.
Las ponderaciones para el Método de Escalamiento de Likert son:
Tabla 7.3 – Ponderaciones Método de Escalamiento de Likert
ESCALA PUNTUACIÓN
Muy de acuerdo 10
De acuerdo 7.5
Ni de acuerdo, ni en desacuerdo 5
En desacuerdo 2.5
Muy en desacuerdo 0
1.3.2 EVALUACION DEL SISTEMA
81
Para la evaluación del sistema se realizó un cuestionario de nueve preguntas, el cual se les facilito
a los usuarios del sistema: Administrador, Residente y Encargado de Almacenes (Ver Anexo A)
1.3.3 RESULTADOS DE LA EVALUACIÓN
Los resultados obtenidos se reflejan en la siguiente tabla:
Tabla 7.5.- Método de Escalamiento de Likert - Resultados
Nro.pregunta
Muy de Acuerd
o
De acuerdo
Ni de Acuerdo ni en Desacuerdo
En Desacuerdo
Muy en Desacuerdo
1 1 2
2 1 2
3 1 2
4 1 2
5 1 1 1
6 2 1
7 2 1
8 2 1
9 1 1 1
Total 11 12 4 0 0
Cálculos para obtener el valor de X:
Tabla 7.3.- Método de Escalamiento de Likert – Calculo de TE
11x10 12x7.5 4x5 0x2.5 0x0 TE110 90 20 0 0 220
X= 2203∗9
=22027
=8.15
1.3.4 CONCLUSION DE LA EVALUACIÓN
El valor de X = 8.15 es cercano a 10, por tanto el sistema desarrollado tiene una aceptación alta
en la empresa COMSCOR SRL.
82
CAPITULO 8CONCLUSIONES Y RECOMENDACIONES
|CONCLUSIONES
En el presente proyecto, se llegó a las siguientes conclusiones:
De acuerdo a los objetivos específicos, para su cumplimiento, se realizó:
Se han empleado, métodos y herramientas para el desarrollo del software en la
determinación de requerimientos, logrando identificar las necesidades de la Empresa
COMSCOR SRL, para el desarrollo del sistema de información.
La construcción de la base de datos se realizó por medio del modelo relacional, lo que
permitió sistematizar la información de los diferentes procesos existentes en la Empresa,
de acuerdo a las necesidades de la misma.
Se elaboró el prototipo del sistema de información, realizando las acciones para cada fase
de la metodología, para su distribución en los equipos de cómputo adecuados, generando
reportes según el criterio del usuario, facilitando su trabajo.
De acuerdo al objetivo general, para su cumplimiento, se realizó:
Se desarrolló un Sistema de Información entorno Web para la Empresa COMSCOR SRL,
el cual satisface las necesidades de los usuarios, proporcionando información en los
procesos de control y seguimiento de operaciones del equipo pesado. El Sistema reporta
informes confiables y oportunos. La satisfacción de los usuarios fue medida a través del
Método de Escalamiento de Likert, obteniéndose un valor para X= 8.15, valor
comprendido entre la escala [Totalmente de acuerdo, De acuerdo].
RECOMENDACIONES
El presente proyecto es una base para el mejoramiento y nuevas perspectivas para el
sistema de empresas constructoras y sus diversos proyectos.
83
Incorporar nuevos módulos, en el área de almacenes que pueda realizar un control
minucioso de todos los insumos. Con los que cuenta la empresa constructora.
La capacitación del personal es importante para poder garantizar el proceso y los
resultados que ofrece la aplicación.
Se recomienda a los usuarios del sistema cambiar periódicamente las contraseñas de
usuario de ingreso al sistema, para resguardar la seguridad de la información almacenada
en el sistema.
BIBLIOGRAFÍA
ÁREA DE SISTEMAS
84
1. [PRE1994] PRESSMAN ROGER, “Ingeniería del Software”, ED. MCGRAW HILL, España 1994.
2. JACOBSON, Ivar; BOOCH, Grady; RUMBAUGH, James. “El Lenguaje Unificado de Modelado”, Pearson Addisson-Wesley. Año 2000.
3. [KIM1994] KIMMEL PAUL, “Manual de UML”.4. [PRE1994] JACOBSON, Ivar; BOOCH, Grady; RUMBAUGH, James; “El Lenguaje
Unificado de Modelado”, Pearson Addisson-Wesley. Año 20005. [KAR1993] KARNER, Gustav, Metrics for Objectory, Degree thesis, Universidad de
Linkoping, Suecia (1993)
ÁREA CIVIL
1. Andeza Saavedra Pedro José; “DISEÑÓ GEOMÉTRICO DE CARRETERAS”2. Carciente Jacob, “ESTUDIO Y PROYECTO DE CARRETERAS”3. Ing. Lanza Ordoñez Raúl, “MAQUINARIA Y EQUIPO PESADO DE
CONSTRUCCIÓN”4. Valle Rodas Raúl, “CARRETERAS, CALLES Y AEROPISTAS”, Editorial “El Ateneo”,
Sexta Edición.[MEF2013]: Texto "Resumen Estadístico elaborado con información de Registros Administrativos del Ministerio de Economía y Finanzas Públicas y Notas de Solicitud a Instituciones que conforman la muestra"
ANEXO ACUESTIONARIOS
85
CUESTIONARIO
¿El sistema de información le ayuda a organizar la información generada en el control y seguimiento de las operaciones del equipo pesado en la Empresa COMSCOR SRL.?
Muy de Acuerdo De acuerdo Ni de Acuerdo ni en Desacuerdo
En Desacuerdo Muy en Desacuerdo
¿El Sistema de Información brinda reportes de las operaciones realizadas por el área técnica de la empresa, con relación al Equipo Pesado?
Muy de Acuerdo De acuerdo Ni de Acuerdo ni en Desacuerdo
En Desacuerdo Muy en Desacuerdo
¿El Sistema de Información presenta informes con respecto al rendimiento del Equipo pesado requeridos por la Superintendencia?
Muy de Acuerdo De acuerdo Ni de Acuerdo ni en Desacuerdo
En Desacuerdo Muy en Desacuerdo
¿El sistema de información muestra en que proyectos se empleó un determinado Equipo Pesado?Muy de Acuerdo De acuerdo Ni de Acuerdo ni en
DesacuerdoEn Desacuerdo Muy en Desacuerdo
¿A través del Sistema de Información usted puede conocer el tiempo total de horas trabajadas por un determinado Equipo Pesado, según el lugar y tipo de proyecto?
Muy de Acuerdo De acuerdo Ni de Acuerdo ni en Desacuerdo
En Desacuerdo Muy en Desacuerdo
<¿Se obtienen reportes de los distintos tipos de vehículos (Equipo Pesado) más sus características (capacidad, volumen, tipo de trabajo, etc.) existentes en la empresa COMSCOR SRL?
Muy de Acuerdo De acuerdo Ni de Acuerdo ni en Desacuerdo
En Desacuerdo Muy en Desacuerdo
¿El Sistema Software le informa al respecto de los vales empleados en la adquisición de Insumos (gasolina y herramientas) para el Equipo Pesado de la empresa?
Muy de Acuerdo De acuerdo Ni de Acuerdo ni en En Desacuerdo Muy en Desacuerdo
86
Desacuerdo
¿El Sistema de Información es comprensible en todas las opciones (menú, enlaces, etc.) que presenta?Muy de Acuerdo De acuerdo Ni de Acuerdo ni en
DesacuerdoEn Desacuerdo Muy en Desacuerdo
¿Los reportes que muestra el Sistema de Información le ayudan en tomar decisiones presentes y/o futuras, relacionadas al trabajo en la empresa?
Muy de Acuerdo De acuerdo Ni de Acuerdo ni en Desacuerdo
En Desacuerdo Muy en Desacuerdo
ANEXO BPANTALLAS DEL SISTEMA
Pantalla principal del usuario - Administrador
87
Pantalla principal del usuario - Residente
Pantalla Acceso a la interfaz para el caso de uso: Cambiar Clave
88
|
ANEXO C
89
DOCUMENTACION
90