Aplicación con Tecnología J2EE para la Administración y control en el Área de Logística (página 3)
Enviado por nixon blaz arteaga
Tabla nº 17: Descripción del modelo use case: gestión de almacén
Nombre : | Registrar Artículo | ||||
Actor: | Secretaria | ||||
Definición : | Permite registrar el artículo que ingresa a almacén | ||||
Pasos: | |||||
1. | Se extraen los datos pertinentes de cada artículo, incluyendo el código generado por Proceso Técnico | ||||
2. | Buscamos y seleccionamos el proveedor | ||||
3. | Buscamos y seleccionamos el categoría | ||||
4. | Buscamos y seleccionamos sección | ||||
5. | Se registra el artículo |
Nombre : | Registrar proveedor | |||||
Actor: | Secretaria | |||||
Definición : | Permite registrar el proveedor de loa artículos | |||||
Pasos: | ||||||
1. | Se busca si el proveedor solicitado no se encuentra en la base de datos | |||||
2. | Se ingresan los datos del proveedor | |||||
3. | Se registra el proveedor |
Nombre : | Registrar categoría | |||||
Actor: | Secretaria | |||||
Definición : | Permite registrar la categoría de los artículos | |||||
Pasos: | ||||||
1. | Se busca si la categoría solicitada no se encuentra en la base de datos | |||||
2. | Se ingresan los datos de la categoría | |||||
3. | Se registra la categoría |
Nombre : | Registrar sección | |||||
Actor: | Secretaria | |||||
Definición : | Permite registrar la sección donde se almacenará los artículos | |||||
Pasos: | ||||||
1. | Se busca si la sección solicitada no se encuentra en la base de datos | |||||
2. | Se ingresan los datos de la sección | |||||
3. | Se registra la sección |
Nombre : | Mantener artículo | |||||
Actor: | Secretaria | |||||
Definición : | Permite mantener artículo. | |||||
Pasos: | ||||||
1. | Se busca el artículo solicitado mostrándose una lista según los parámetros de búsqueda. | |||||
2. | Si selecciona en nuevo, re direcciona al formulario de registrar artículo. | |||||
3. | Si selecciona en modificar, se cambia la información y se guarda los cambios. | |||||
4. | Si selecciona en Eliminar, se elimina el registro seleccionado en el caso de no estar asignado a un material bibliográfico. |
Nombre : | Mantener proveedor | |||||
Actor: | Secretaria | |||||
Definición : | Permite mantener proveedor. | |||||
Pasos: | ||||||
1. | Se busca el proveedor solicitado mostrándose una lista según los parámetros de búsqueda. | |||||
2. | Si selecciona en nuevo, re direcciona al formulario de registrar proveedor. | |||||
3. | Si selecciona en modificar, se cambia la información y se guarda los cambios. | |||||
4. | Si selecciona en Eliminar, se elimina el registro seleccionado en el caso de no estar asignado a un material bibliográfico. | |||||
Nombre : | Mantener categoría | |||||
Actor: | Secretaria | |||||
Definición : | Permite mantener categoría. | |||||
Pasos: | ||||||
1. | Se busca el categoría solicitado mostrándose una lista según los parámetros de búsqueda. | |||||
2. | Si selecciona en nuevo, re direcciona al formulario de registrar categoría. | |||||
3. | Si selecciona en modificar, se cambia la información y se guarda los cambios. | |||||
4. | Si selecciona en Eliminar, se elimina el registro seleccionado en el caso de no estar asignado a un material bibliográfico. |
Nombre : | Mantener sección | |||||
Actor: | Secretaria | |||||
Definición : | Permite mantener la sección | |||||
Pasos: | ||||||
1. | Se busca la sección solicitada mostrándose una lista según los parámetros de búsqueda. | |||||
2. | Si selecciona en nuevo, re direcciona al formulario de registrar de sección. | |||||
3. | Si selecciona en modificar, se cambia la información y se guarda los cambios. | |||||
4. | Si selecciona en Eliminar, se elimina el registro seleccionado en el caso de no estar asignado a un material bibliográfico. |
Diagrama de Paquetes del Análisis
Figura nº21: Diagrama de paquetes
Diagrama de Clases
Figura nº22: Diagrama de clases
Diseño de la base de datos
D.1. diccionario de datos
Tabla nº 18 diccionario de datos
CLASE | DESCRIPCION | |
ARTÍCULO |
| |
ALMACÉN |
| |
PEDIDO |
| |
PROVEEDOR |
| |
USUARIO |
user_clave, dni, fecha_alta, fecha_baja.
| |
CATEGORÍA |
| |
SECCIÓN |
|
Diagrama de base de datos
Figura nº 23: Diagrama de base de datos
Fase de construcción
Diagrama de componentes.
Figura nº 24: diagrama de componentes
CAPITULO IV:
Resultados de la investigación
RESULTADOS
A los usuarios
Según las encuestas realizadas a los usuarios se verifica que existe una mejora en cuanto a los valores de los indicadores luego de la implantación del sistema.
A continuación, un cuadro comparativo que muestra en resumen todos los indicadores tomados con sus respectivos valores Pre y Post Test.
Tabla nº 19: resultado de indicadores
Nº | INDICADOR | PRE TEST | POS TEST | ||||||
1 | utilidad por los usuarios | 2.54 | 5 | ||||||
2 | registrar entradas y salidas de artículo | 2.15 | 4.57 | ||||||
3 | control de usuarios | 2.15 | 3.15 | ||||||
4 | consultar artículos | 1.69 | 4.43 | ||||||
5 | manejo de información | 2.08 | 4.43 | ||||||
6 | usabilidad de la aplicación | 1.69 | 4.29 | ||||||
7 | Atención al cliente | 2.71 | 3.52 |
Contrastación de hipótesis
Formulación de cuadros de valores de indicadores
La contrastación de la hipótesis se realizará de acuerdo al diseño de investigación mostrado en el capítulo III, el cual es conocido también como pre-test y post-test, que se representa mediante la siguiente simbología:
Donde:
GE: Los usuarios en el área de Logística y Almacén en el Hospital Amazónico de Yarinacocha.
O1: Análisis de los resultados, antes de la instalación de la Aplicación con Tecnología J2EE.
X: Es la Aplicación con tecnología J2EE.
O2: Análisis de los resultados, después de la instalación de la Aplicación con Tecnología J2EE.
El procedimiento consiste en determinar en primer lugar una tabla de rango de valores, la cual nos permite ubicar valores cuantitativos de los indicadores, por medio de valores cualitativos expresados en este rango.
Posteriormente realizamos la comparación de valores entre indicadores de acuerdo al diseño de contrastación; esta comparación nos permite finalmente aceptar o rechazar la hipótesis de acuerdo a los estándares científicos de la Estadística.
Para variables cuantitativas:
RANGO SATISFACCIÓN |
[ 0 – 1.5 ] Nada Satisfactorio |
[ 1.6 – 3.2] Parcialmente Satisfactorio |
[ 3.3 – 5] Satisfactorio |
Para variables cualitativos:
RANGO SATISFACCIÓN |
[ 0 – 1.5] Nada Ventajoso |
[1.6 – 3.2] Poco Ventajoso |
[3.3 – 5] Altamente Ventajoso |
Los cuadros siguientes muestran la comparación de indicadores de la
Siguiente página se obtiene mediante la recolección de datos al realizar una encuesta pre test y post test según formato especificado en los anexos 5, 6, 7, 8, 9, 10 y 11.
Se emplea las siguientes abreviaturas:
VC: Valor cuantitativo
VI: Valor Inicial
VF: Valor Final
Tabla nº 20: Comparación de indicadores cualitativos
Supuestos de la prueba de hipótesis
1. Los datos muestrales se seleccionaron de manera no probabilística y por conveniencia, a una muestra de 7, correspondiente al personal que labora en el área de logística y almacén, que esta en contacto con la Aplicación, así mismo evaluamos los 7 indicadores relevantes para la prueba de hipótesis.
2. La hipótesis nula Ho es la negación de la relación existente entre la variable independiente y la variable dependiente y la hipótesis Ha es la afirmación correspondiente.
3. Se utilizó el 95% del nivel de confiabilidad y 5% del nivel de significancia
4. Se acepta la hipótesis nula si el Valor Calculado Tc es menor al valor en tabla Tt, caso contrario se rechaza la Ho y se acepta la hipótesis alterna Ha.
Cálculo del valor crítico y la función de prueba
Después de analizar las diferencias entre los indicadores en Pre-test (O1) y post-test (O2), se puede concluir que para todos los indicadores hay diferencias significativas y una mejora después de utilizar el Sistema Web con tecnología J2EE.
Tabla nº 21: Resumen de Resultados de Valores
Cálculo de la diferencia promedio (D)
Regiones de Aceptación y Rechazo
Cálculo del valor calculado o Función de Prueba (Tc).
Tc = 7.33
Por lo tanto:
Como Tc = 7.33 es mayor que Tt = 1,943; entonces se rechazan Ho y se acepta Ha = 02 – 01 > 0
Finalmente se concluye que la hipótesis planteada es aceptada.
En el desarrollo de la presente investigación a través de sus diferentes etapas, queda demostrado que la Aplicación con Tecnología J2EE mejora la administración en el Área de Logística y Almacén en el Hospital Amazónico de Yarinacocha, con lo cual constituye una alternativa de solución al problema planteado, con un nivel de confianza del 95%.
Según el análisis realizado y sobre la base de los objetivos de la investigación se establecieron las siguientes conclusiones:
1. Se logro identificar los procesos administrativos del área de logística y almacén en el Hospital de Yarinacocha el mismo que me ha conducido a realizar este trabajo de investigación.
2. Se Diseñó la base de datos en SQL Server 2005 para almacenar toda la información de logística y almacén.
3. La metodología RUP se ha adaptado fácilmente a la naturaleza de este proyecto de investigación permitiéndonos realizar un desarrollo organizado del mismo. Además la integración con herramientas Rational nos ha permitido aprovechar potencialmente sus virtudes.
4. Se ha demostrado que la Tecnología J2EE nos ha permitido solucionar el problema sobre la administración y control en el área de logística y control en el hospital de yarinacocha por las características propias, que ésta Tecnología brinda.
5. El uso de la notación UML para representar los requerimientos funcionales del sistema de administración bibliotecaria ha sido adecuada y flexible al permitirnos disponer de una variedad de diagramas para plasmar la representación requerida y ser interpretados posteriormente por los desarrolladores o usuarios.
De acuerdo a las conclusiones de la investigación realizada se recomienda lo siguiente:
1. Aplicar Rational Unified Process y UML para la construcción de Sistemas Web con integración de la Tecnología J2EE.
2. Realizar las pruebas necesarias en lo que respecta al entorno de trabajo para que este tipo de sistemas funcionen en su totalidad.
3. Implantar la Aplicación con Tecnología J2EE para la administración en el área de logística y almacén, por los beneficios que se obtendrían al respecto.
4. Promover trabajos de investigación utilizando la tecnología J2EE y la Ingeniería de software que permitan solucionar problemas sociales y culturales.
5. Promover trabajos de investigación para tratar de llevar a la práctica los estudios económicos para el desarrollo de Ingeniería de Software, con la finalidad de establecer un estándar.
1. Apolinario, A. N. (2007). Programacion en Java2. Lima: Megabyte s.a.c.
2. Blanchard, B. S. (2003). INGENIERÍA LOGÍSTICA. Madrid: Graficas Monterreyna, S.A.( Madrid).
3. Booch, G. e. (2005). "El Lenguaje Unificado de Modelado". Massachussets: Addison Wesley.
4. Booch, G. R. (2000). El Lenguaje Unificado de Modelado. Wesley: Addison.
5. CHACÓN, J. C. (2006). APLICACION DE LA METODOLOGIA RUP PARA EL DESARROLLO BASADO EN ESTANDADRES J2EE. Guatemala
6. Chacón, J. C. (2006). APLICACIÓN DE LA METODOLOGÍA RUP PARA EL DESARROLLO RÁPIDO DE APLICACIONES BASADO EN EL ESTÁNDAR J2EE. Guatemala: (tesis de grado) para obetner el titutlo de ingenieria en ciecias y sistemas – Universidad de San Carlos de Guatemala.
7. Falkner, J. (2002). Fundamentos Desarrollo Web con JSP. Madrid: Anaya Multimedia.
8. Natalí Janet del Rocio Padierna Venegas, K. V. (2003). Sistema de Informacion Académica y dee Servicios para la Escuela P䲯fesional de Ingeniería de Computaci{on y Sistemas de la Universidad Privada Antenor Orrego. Trujillo: (Tesis de Grado) .
9. Pino, M. A. (2006). Evaluación Comparativa de aplicaciones Web entre J2EE Y Microsoft.NET. Temuco: (tesis de grado) para obtener el titulo de Ingeniero de Ejecución en Informática / Universidad Catolica de Temuco.
10. Ponce, A. R. (2004). Administracion Moderna. Mexico: Limusa.
11. Rojas, M. (2002). Manual de Investigación y Redacción Científica. Lima: Book Xx press.
12. Sábada, A. A. (2003). Administracion de Organizaciones en el Entorno Actual. Madrid: Ediciones Pramide( Grupo Anaya, S.A.).
13. Samchez, J. (2004). Java2. mexico: navarrete.
UNIVERSIDAD NACIONAL DE UCAYALI
FACULTAD DE INGENIERIA DE SISTEMAS E INGENIERIA CIVIL
ESCUELA PROFESIONAL DE INGENIERIA DE SISTEMAS
APLICACIÓN CON TECNOLOGÍA J2EE PARA LA ADMINISTRACIÓN Y CONTROL EN EL ÁREA DE LOGÍSTICA Y ALMACÉN EN EL HOSPITAL AMAZÓNICO DE YARINACOCHA.
Curso : SEMINARIO DE TESIS
Autor : BLAZ ARTEAGA, NIXON G.
Asesor : MG. JORGE LUIS HILARIO RIVAS
Yarina – Peru
2010
Encuesta post-test
El cuestionario que aquí le presentamos pretende recoger su opinión sobre diferentes aspectos relacionados con la administración y control de almacén en el área de Logística y Almacén del Hospital Amazónico de Yarinacocha. Por ello, le pedimos que tenga en cuenta que no hay respuestas correctas o incorrectas, sólo tiene que marcar una alternativa por pregunta, la que mejor refleja su opinión.
Toda información que no facilite, así como los resultados que a través de este cuestionario se obtengan, serán tratados con absoluta confidencialidad y anonimato. Muchas gracias por su colaboración.
P10.- ¿Le parece difícil el acceso al sistema?
1) Si 2) No
P11.- ¿Es entendible el menú de opciones?
1) Si 2) No
P12.- ¿Es sencillo el ingreso de datos?
1) Si 2) No
P13.- ¿Las respuestas de las búsquedas son entendibles?
1) Si 2) No
P14.- ¿Es fácil la navegación en el sistema?
1) Si 2) No
P15.- ¿Los colores que se utilizan en la interfaz le irritan la vista?
1) Si 2) No
P16.- ¿Está de acuerdo con la distribución del menú?
1) Si 2) No
P17.- ¿Los reportes son fáciles de comprender?
1) Si 2) No
Se le agradece por su atención prestada.
PRESUPUESTO
Peso de los actores
Primero empezamos considerando los actores de nuestro sistema y determinamos para cada Actor si estos son simples, promedio o complejos; para esto nos guiamos de la siguiente tabla:
Tipo de Actor | Descripción | Factor | |
Simple | Interfaz del programa | 1 | |
Promedio | Interactivo, o manejador de interfaz con protocolo | 2 | |
Complejo | Interfaz gráfica | 3 |
Asignamos a cada actor su tipo:
Gerente de Logística-Promedio
Secretaria – Promedio
Jefe de Almacén-Simple
Despachador – Simple
Personal Vigilancia – Simple
Por tanto:
3 Simple * 1 = 3
2 Promedio * 2 = 4
0 Complejo * 3 = 0
Total de peso de actores = 3 + 4 + 0 = 7
Peso de los Use Case
Ahora hacemos algo similar para la lista de Use Case; con la diferencia que esto basado en el Número de transacciones que realiza cada Use Case. Determinando si estos son simples, promedios o complejos.
Tipo de Actor | Descripción | Factor | ||
Simple | 3 o menos Transacciones | 5 | ||
Promedio | 4 a 7 Transacciones | 10 | ||
Complejo | 7 Transacciones | 15 |
Asignamos a cada use case su tipo:
1.- | Registrar Usuarios | Simple | ||||||
2.- | Registrar Proveedores | Simple | ||||||
3.- | Registrar Ingreso Materia | Promedio | ||||||
4.- | Registrar Salida de Materia | Promedio | ||||||
5.- | Registrar Servicio | Simple | ||||||
6.- | Registrar Reserva | Simple | ||||||
7.- | Consultar Stocks | Simple | ||||||
8.- | Registrar Devoluciones | Simple |
Entonces:
6 simple * 5 = 30
2 promedio * 10 = 20
0 complejo * 15 = 0
Total de peso de use case = 30 + 20 + 0 = 50
Calculando UUCP
Para encontrar el Ajuste de Puntos para el Use Case (UUCP); el cual refleja la complejidad del proyecto y la experiencia de las personas en el proyecto, para estos utilizamos los pesos de los actores y de los use case:
7 + 50 = 57 UUCP
Calculando el TCF
Ahora necesitamos calcular la complejidad técnica para este proyecto, a esto se le llama Factor Técnico de Complejidad (TFC).
Para calcular el TFC lo hacemos a través de la siguiente tabla, que llenamos con factores de 0 a 5 un puntaje de 0 significa que el factor es irrelevante, un puntaje de 5 significa que el factor es significante para este proyecto:
Numero de factor | Descripción del Factor | Peso de Factor | Valor Asignados | Valor Total | |||
T1 | Sistema Distribuido | 2 | 2 | 4 | |||
T2 | Respuesta o Rendimiento de los objetivos cumplidos | 1 | 3 | 3 | |||
T3 | Eficiencia de los Usuarios Finales (en Línea) | 1 | 5 | 5 | |||
T4 | Procesamiento interno complejo | 1 | 2 | 2 | |||
T5 | Código debe ser reusable | 1 | 4 | 4 | |||
T6 | Fácil de instalar | 0.5 | 5 | 2.5 | |||
T7 | Fácil de usar | 0.5 | 5 | 2.5 | |||
Numero de factor | Descripción del Factor | Peso de Factor | Valor Asignados | Valor Total | |||
T8 | Portable | 2 | 4 | 8 | |||
T9 | Fácil de cambiar | 1 | 3 | 3 | |||
T10 | Concurrente | 1 | 2 | 2 | |||
T11 | Incluye características especiales de seguridad | 1 | 2 | 2 | |||
T12 | Provee acceso directo para terceros | 1 | 0 | 0 | |||
T13 | Capacitación especial | 1 | 3 | 3 |
TFactor = Sumatoria (Peso del Factor) * (TValores Asignados)
TFactor = 41
TFC = 0.6 + (0.01 * Factor)
TFC = 0.6 + (0.01 * 41) = 1.01
Calculando el EF
En este punto calcularemos el nivel de experiencia de las personas del proyecto, a esto se Llama el Factor Environment. Para calcular esto lo hacemos a través de la siguiente tabla; Teniendo en consideración los siguientes puntos:
De F1 a F4; 0 es no experiencia, 3 es mas o menos y 5 es experto.
F5; 0 no motivado, 3 más o menos y 5 muy motivado.
F6; 0 requerimientos inestables, 3 más o menos y 5 requerimientos estables.
F7; 0 no hay staff de medio tiempo, 3 más o menos y 5 todos trabajan medio tiempo.
F8; 0 fácil uso de la programación, 3 más o menos y 5 mucha dificultad para la programación.
Número del Factor | Descripción del Factor | Peso | Valor Asignado | Valor Total | |||||
F1 | Manejo de Procesos Unificados | 1.5 | 5 | 7.5 | |||||
F2 | Experiencia en Aplicaciones | 0.5 | 4 | 2 | |||||
F3 | Experiencia en la Orientación a Objetos. | 1 | 5 | 5 | |||||
F4 | Capacidad de Análisis y Liderazgo | 0.5 | 5 | 2.5 | |||||
F5 | Motivación | 1 | 5 | 5 | |||||
F6 | Requerimientos estables | 2 | 3 | 6 | |||||
F7 | Trabajadores a medio tiempo | -1 | 1 | -1 | |||||
F8 | Dificultad en el lenguaje de Programación | -1 | 0 | 0 |
EFactor = Sumatoria (Valor Asignado * Peso del Factor)
EFactor =26.5
EF = 0.35 + (0.03 * EFactor)
EF = 0.35 + (0.03 * 26.5) = 1.145
Calculando el UCP
Finalmente para calcular los puntos de Use Case;
UCP = UUCP * TCF * EF
UCP = 57 * 1.01* 1.145= 65.92
Para elegir el factor hombre / horas
Para esto examinamos los datos en los EF y contamos del F1 a F6 los factores que son menores a tres y contamos de F7 a F8 son a partir de tres. Si el total es 2 o menos utilizamos 20 hombres/horas por UCP, si son mayores a tres usamos 28 hombres/horas por UCP.
En nuestro caso utilizaremos 20 hombres/horas, por lo que multiplicaremos; 20 hombres/horas * 65.92 UCP = 1318.35, que consideramos que es el esfuerzo que vamos a necesitar para el proyecto.
Con esto también podemos calcular el tiempo aproximado que necesitaremos para el Proyecto; considerando que la semana tiene 42 horas (6 días * 7 horas) entonces: 1318.35/ 40 = 31.4 Semanas, entre 2 personas que desarrollarán éste proyecto, el tiempo calculado es de 15.7 semanas.
El costo del Proyecto se calculó; en base a un sueldo mensual para el integrante del Equipo (S/. 1200.00 c/u) que multiplicado por el tiempo estimado para dicho proyecto (3.93 meses) Hacen un total de S/.9420.00 aproximadamente por los 2 programadores; a este costo se le suma los gastos de aprovisionamiento que hace un total de S/.4743.00,
TESIS
PARA OPTAR PPOR EL TITULO PROFESIONAL DE INGENIERIA DE SISTEMAS
DEDICATORIA
A Dios por darme salud y bienestar en el día a día que lucho por lograr mis objetivos
Blaz
AGRADECIMIENTO
A los Docentes que nos brindan sus conocimientos para nosotros incrementar nuestra sabiduría.
Al Mg. Jorge Luis Hilario Rivas docente del curso seminario de tesis quien nos brinda su asesoría incondicional para la elaboración de nuestra tesis.
Autor:
Blaz Arteaga, Nixon Glauber
Yarinacocha – Perú
2010
UNIVERSIDAD NACIONAL DE UCAYALI
Facultad de Ingeniería de Sistemas y de Ingeniería Civil
Escuela Profesional Ingeniería de Sistemas
Página anterior | Volver al principio del trabajo | Página siguiente |