Informe Final

Facultad de Ingeniería
Facultad de Ingeniería
Escuela Académico Profesional de Ingeniería de Sistemas
TEMA DE PRÁCTICAS : “SISTEMA DE GESTIÓN DE ALMACÉN ”

NOMBRE DE LA EMPRESA: Compumall E.I.R.L.
ALUMNOS:
- Guarniz Cueva Milagros Elizabeth
- Rojas Guevara Remso Ivan
DOCENTE ASESOR:
Ing. GOMEZ AVILA, JOSE ALBERTO, Mg.
CICLO:
VIII
TRUJILLO – PERÚ
2015
Página | 1
Contenido
CAPITULO I: DESCRIPCION DE LA ORGANIZACIÓN ........................................................................ 3
1.1. DESCRIPCION GENERAL DE LA ORGANIZACIÓN ............................................................ 3
1.2. UBICACIÓN Y/O ENTORNO ............................................................................................ 4
1.3. RESEÑA HISTORICA........................................................................................................ 4
1.4. MISIÓN .......................................................................................................................... 4
1.5. VISIÓN ........................................................................................................................... 5
1.6. ESTRUCTURA ORGANICA ............................................................................................... 5
CAPITULO II: DEFINICIÓN DE PROBLEMA ...................................................................................... 6
2.1. REALIDAD PROBLEMÁTICA ............................................................................................ 6
2.2. JUSTIFICACION DEL PROYECTO ..................................................................................... 6
2.3. OBJETIVOS DEL PROYECTO ............................................................................................ 6
2.4. PRESUPUESTO ............................................................................................................... 7
2.5. FUNDAMENTO TEÓRICO ............................................................................................... 8
2.5.1. METODOLOGIA XP................................................................................................. 8
CAPITULO III: DESARROLLO DEL PROYECTO ................................................................................ 12
3.1. FASE DE PLANIFICACIÓN ............................................................................................. 12
3.1.1. PRINCIPALES ACTIVIDADES.................................................................................. 12
3.1.2. Historia de usuarios:............................................................................................ 13
3.1.3. REQUERIMIENTOS DEL SISTEMA DE INFORMACION .......................................... 19
3.2. FASE DE DISEÑO .......................................................................................................... 21
3.2.1. DISEÑO DE ARQUITECTURA ................................................................................ 21
3.2.2. MODELO DE BAS DE DATOS ................................................................................ 22
3.2.3. TARJETA CRC........................................................................................................ 23
3.2.4. DICCIONARIO DE DATOS ..................................................................................... 26
3.2.5. PROTOTIPO .......................................................................................................... 28
3.3. FASE DE CODIFICACION ............................................................................................... 39
3.4. FASE DE PRUEBAS........................................................................................................ 40
3.4.1. PRUEBAS FUNCIONALES ...................................................................................... 40
CONCLUSIONES ........................................................................................................................... 45
Página | 2
CAPITULO I: DESCRIPCION DE LA ORGANIZACIÓN
1.1. DESCRIPCION GENERAL DE LA ORGANIZACIÓN

Compumall, es una empresa privada con fines de lucro, que está asociado a los PYMES
del sector de comercialización y ventas de productos de cómputo.
DATOS GENERALES
 RUC:
20559759491
 Razón Social:
Compumall E.I.R.L.
 Tipo Empresa
Empresa Individual de Responsabilidad Limitada
 Actividad Comercial:
Comercialización de productos de cómputo y consultores en equipos
informáticos
 Condición:
Activo
 Fecha de inicio actividades

20 de noviembre de 2013
 Teléfono:
044 - 292322
 Gerente General:
MORENO OLIVARES, Johnny Enrique
Página | 3
1.2. UBICACIÓN Y/O ENTORNO
COMPUMALL EIRL tiene su ubicación en Jirón Junín Nro. 642, distrito Trujillo,
departamento de La Libertad.
Ilustración 1: Ubicación de COMPUMALL E.I.R.L.

Fuente: Información brindada por GoogleMaps
1.3. RESEÑA HISTORICA

Compumall EIRL , se fundó en diciembre del año 2012 y empezó a funcionar en
noviembre de 2013 como una empresa dedicada al rubro de la comercialización al por
mayor de implementos de computo. Teniendo como gerente a Moreno Olivares Johnny
Enrique.
Compumall EIRL tiene como predecesora a una empresa de mayor tiempo en el

mercado como es ComputerExpress, fundada en el año de 2003, empresa también
dedicada al rubro de comercialización de implementos de computo.
Por lo que desde el año 2012, Compumall EIRL busca siempre brindar los mejores
productos y a los mejores precios para poder satisfacer las necesidades de las personas.
1.4. MISIÓN
“Somos una empresa dedicada al rubro de comercialización de productos de cómputo
premiada y reconocida como líder en calidad de productos y de servicio técnico. Gracias
a nuestra experiencia, compromiso social y moderna tecnología satisfacemos con
calidad y eficiencia la demanda de nuestro mercado.”
Información brindada por COMPUMALL E.I.R.L.
Página | 4
1.5. VISIÓN
“Aspiramos para el 2020 ser reconocidos como una sólida organización que brinde
confianza y preocupación por la preferencia de nuestros clientes además de
posicionarnos como una empresa líder en el mercado regional”
Información brindada por COMPUMALL E.I.R.L.
1.6. ESTRUCTURA ORGANICA
Ilustración 2: Organigrama de COMPUMALL E.I.R.L.

Fuente: Información brindada por COMPUMALL E.I.R.L.
Página | 5
CAPITULO II: DEFINICIÓN DE PROBLEMA
2.1. REALIDAD PROBLEMÁTICA

La empresa COMPUMALL E.I.R.L., cuenta con sistema de información que no es
adecuada para llevar un control de los productos que se encuentran en almacén, como es
el registro de los productos, tanto que entran como los que salen por venta o garantía, lo
realizan en Excel y no cuentan con una infraestructura de redes generando datos no
consolidados que se necesitan para la toma de decisiones, ocasionando comúnmente
perdidas en la empresa.
Entre otros problemas que se pueden encontrar tenemos:

 No poder realizar correctamente la búsqueda o el seguimiento de un producto.
 Al momento de realizar el balance de existencias no concordaban las cantidades.
 No se poder diferenciar correctamente entre dos productos que tenían el mismo
código.
2.2. JUSTIFICACION DEL PROYECTO

Es importante señalar, que en tiempos pasados, se discutían las dificultades planteadas
por los sistemas de información luego se ha intentado despertar el interés ante las
posibilidades que ella brinda.
La influencia de la tecnología y los sistemas de información en el ser humano ha tomado

amplio interés en lo que respecta a la utilización no sólo de computador sino del conjunto
de técnicas de tratamiento de la información derivada de su uso, ha llevado a construir
los desafíos del futuro, tal es el caso de los sistemas de gestión administrativo, que se
implementan en empresas para la optimización de la información.
Por ello la siguiente investigación tiene como objetivo principal Implementar e integrar
Sistemas de información en la empresa EIRL Compumall. Este objetivo nos permitirá
brindar así una mejor comunicación y comprensión entre las diferentes áreas, facilitando
la toma de decisiones, generando más utilidades y ventaja competitiva en la organización.
2.3. OBJETIVOS DEL PROYECTO

Objetivo Principal
Implementar e implantar una aplicación para la gestión de productos de almacén de la
empresa de venta de computo COMPUMALL E.I.R.L.
Objetivos Específicos
 Obtener los resultados actualizados en el tiempo que la organización requiera
para la toma de decisiones.
 Contar con bases de datos consolidadas en la organización.
Página | 6
2.4. PRESUPUESTO
Materiales Cantidad Cost. Unitar. Costos Total
1 Personal S/. 0,00
Honorarios 2 S/. 0,00 S/. 0,00
2 Equipos S/. 2.900,00

Computadoras 1 S/. 2.100,00 S/. 2.100,00
Escritorios 1 S/. 350,00 S/. 350,00
Impresora 1 S/. 450,00 S/. 450,00
Internet 1 S/. 0,00 S/. 0,00
Software 2 S/. 0,00 S/. 0,00
3 Viajes S/. 420,00

Viaticos 0 S/. 0,00 S/. 0,00
Transporte 70 S/. 6,00 S/. 420,00
4 Materiales S/. 0,00

Libros, revistas, etc. 5 S/. 0,00 S/. 0,00
5 Imprevistos S/. 0,00
TOTAL S/. 3.320,00

Tabla 1: Presupuesto del proyecto.
Fuente: Hecha por el grupo
DETALLE DE LOS EQUIPOS

Computadora :
RAM: 4 GB
Disco Duro: 500 GB
Mainboard: MSI h81m-p33 p33
Tarjeta de RED: inalámbrica PC-Link
Procesador: Intel Core I3
Software:
Monodevelop Software de Open Source
MySQL Open Source
Página | 7
2.5. FUNDAMENTO TEÓRICO
2.5.1. METODOLOGIA XP
Un proyecto XP tiene éxito cuando el cliente selecciona el valor de negocio a implementar basado
en la habilidad del equipo para medir la funcionalidad que puede entregar a través del tiempo.
El ciclo de desarrollo consiste (a grandes rasgos) en los siguientes pasos:

• El cliente define el valor de negocio a implementar.
• El programador estima el esfuerzo necesario para su implementación.
• El cliente selecciona qué construir, de acuerdo con sus prioridades y las restricciones de
tiempo.
• El programador construye ese valor de negocio.
FASES
1. EXPLORACIÓN
En esta fase, los clientes plantean a grandes rasgos las historias de usuario que son de
interés para la primera entrega del producto. Al mismo tiempo el equipo de desarrollo se
familiariza con las herramientas, tecnologías y prácticas que se utilizarán en el proyecto.
Se prueba la tecnología y se exploran las posibilidades de la arquitectura del sistema
construyendo un prototipo. La fase de exploración toma de pocas semanas a pocos
meses, dependiendo del tamaño y familiaridad que tengan los programadores con la
tecnología.
2. PLANIFICACIÓN DE LA ENTREGA
En esta fase el cliente establece la prioridad de cada historia de usuario, y
correspondientemente, los programadores realizan una estimación del esfuerzo necesario
de cada una de ellas. Se toman acuerdos sobre el contenido de la primera entrega y se
determina un cronograma en conjunto con el cliente. Una entrega debería obtenerse en
no más de tres meses. Esta fase dura unos pocos días.
Las estimaciones de esfuerzo asociado a la implementación de las historias la establecen

los programadores utilizando como medida el punto. Un punto, equivale a una semana
ideal de programación. Las historias generalmente valen de 1 a 3 puntos. Por otra parte,
el equipo de desarrollo mantiene un registro de la “velocidad” de desarrollo, establecida
en puntos por iteración, basándose principalmente en la suma de puntos correspondientes
a las historias de usuario que fueron terminadas en la última iteración.
La planificación se puede realizar basándose en el tiempo o el alcance. La velocidad del

proyecto es utilizada para establecer cuántas historias se pueden implementar antes de
una fecha determinada o cuánto tiempo tomará implementar un conjunto de historias. Al
planificar por tiempo, se multiplica el número de iteraciones por la velocidad del
proyecto, determinándose cuántos puntos se pueden completar. Al planificar según
alcance del sistema, se divide la suma de puntos de las historias de usuario seleccionadas
entre la velocidad del proyecto, obteniendo el número de iteraciones necesarias para su
implementación.
3. ITERACIONES
Página | 8
Esta fase incluye varias iteraciones sobre el sistema antes de ser entregado. El Plan de
Entrega está compuesto por iteraciones de no más de tres semanas. En la primera iteración
se puede intentar establecer una arquitectura del sistema que pueda ser utilizada durante
el resto del proyecto. Esto se logra escogiendo las historias que fuercen la creación de
esta arquitectura, sin embargo, esto no siempre es posible ya que es el cliente quien decide
qué historias se implementarán en cada iteración (para maximizar el valor de negocio).
Al final de la última iteración el sistema estará listo para entrar en producción.
Los elementos que deben tomarse en cuenta durante la elaboración del Plan de la Iteración
son: historias de usuario no abordadas, velocidad del proyecto, pruebas de aceptación no
superadas en la iteración anterior y tareas no terminadas en la iteración anterior. Todo el
trabajo de la iteración es expresado en tareas de programación, cada una de ellas es
asignada a un programador como responsable, pero llevadas a cabo por parejas de
programadores.
4. PRODUCCIÓN
La fase de producción requiere de pruebas adicionales y revisiones de rendimiento antes
de que el sistema sea trasladado al entorno del cliente. Al mismo tiempo, se deben tomar
decisiones sobre la inclusión de nuevas características a la versión actual, debido a
cambios durante esta fase.
Es posible que se rebaje el tiempo que toma cada iteración, de tres a una semana. Las
ideas que han sido propuestas y las sugerencias son documentadas para su posterior
implementación (por ejemplo, durante la fase de mantenimiento).
5. MANTENIMIENTO
Mientras la primera versión se encuentra en producción, el proyecto XP debe mantener
el sistema en funcionamiento al mismo tiempo que desarrolla nuevas iteraciones. Para
realizar esto se requiere de tareas de soporte para el cliente. De esta forma, la velocidad
de desarrollo puede bajar después de la puesta del sistema en producción. La fase de
mantenimiento puede requerir nuevo personal dentro del equipo y cambios en su
estructura.
6. MUERTE DEL PROYECTO

Es cuando el cliente no tiene más historias para ser incluidas en el sistema. Esto requiere
que se satisfagan las necesidades del cliente en otros aspectos como rendimiento y
confiabilidad del sistema. Se genera la documentación final del sistema y no se realizan
más cambios en la arquitectura. La muerte del proyecto también ocurre cuando el sistema
no genera los beneficios esperados por el cliente o cuando no hay presupuesto para
mantenerlo.
REGLAS Y PRACTICAS XP
La principal suposición que se realiza en XP es la posibilidad de disminuir la usual curva
exponencial del costo del cambio a lo largo del proyecto, lo suficiente para que el diseño
evolutivo funcione. Esto se consigue gracias a las tecnologías disponibles para ayudar en el
desarrollo de software y a la aplicación disciplinada de un conjunto de prácticas que en base
a la experiencia en proyectos de alto riesgo y requerimientos cambiantes, han surgido como
receta para un buen desempeño.
La mayoría de las prácticas propuestas por XP no son novedosas sino que en alguna forma
ya habían sido propuestas en ingeniería del software e incluso demostrado su valor en la
Página | 9
práctica. El mérito de XP es integrarlas de una forma efectiva y complementarlas con otras
ideas desde la perspectiva del negocio, los valores humanos y el trabajo en equipo.
A. EL “JUEGO” DE LA PLANIFICACIÓN
Es un espacio frecuente de comunicación entre el cliente y los programadores. El
equipo técnico realiza una estimación del esfuerzo requerido para la implementación
de las historias de usuario y los clientes deciden sobre el ámbito y tiempo de las
entregas y de cada iteración. Esta práctica se puede ilustrar como un juego, donde
existen dos tipos de jugadores: Cliente y Programador. El cliente establece la prioridad
de cada historia de usuario, de acuerdo con el valor que aporta para el negocio. Los
programadores estiman el esfuerzo asociado a cada historia de usuario. Se ordenan las
historias de usuario según prioridad y esfuerzo, y se define el contenido de la entrega
y/o iteración, apostando por enfrentar lo de más valor y riesgo cuanto antes. Este juego
se realiza durante la planificación de la entrega, en la planificación de cada iteración
y cuando sea necesario reconducir el proyecto.
B. ESCRIBIR HISTORIAS DE USUARIO

Las Historias de Usuario se crean con el mismo propósito que los Casos de Uso, pero
no son lo mismo. Se utilizan para crear estimaciones de tiempo para las reuniones de
planificación de las liberaciones. También son utilizadas en lugar del Documento de
Requerimientos.
Las Historias de Usuario son escritas por los clientes como las cosas que el cliente
necesita que el sistema haga por él. Son similares a los Escenarios de Uso, excepto
porque no están limitados a describir la interfaz de usuario. Deben ser escritas con un
formato de dos o tres líneas de texto, escritas por el cliente usando la terminología del
cliente sin términos técnicos.
C. ENTREGAS PEQUEÑAS
La idea es producir rápidamente versiones del sistema que sean operativas, aunque
obviamente no cuenten con toda la funcionalidad pretendida para el sistema pero que
constituyan un resultado de valor para el negocio. Una entrega no debería tardar más
de 3 meses.
D. ROTACIÓN DEL EQUIPO

La rotación del equipo evita problemas de conocimiento y de cuellos de botella. Si
una única persona puede trabajar en un área dada y esa persona deja el equipo o tiene
otras tareas pendientes, aparecerá un atraso en el avance.
La rotación del equipo en conjunto con la Programación en Parejas, lograrían dicho
entrenamiento.
En lugar de que una persona conozca el código de una sección completa, todo el
equipo conoce todo el código de cada sección.
Con esto el equipo se vuelve más flexible y se sobrecarga menos.
E. DISEÑO SIMPLE
Se debe diseñar la solución más simple que pueda funcionar y ser implementada en
un momento determinado del proyecto. Un diseño simple siempre toma menos tiempo
para finalizarlo que un complejo.
Página | 10
La complejidad innecesaria y el código extra debe ser removido inmediatamente.
Siempre es más rápido y más barato reemplazar ahora el código complejo antes que
gastemos más tiempo en él.
Hay que mantener las cosas lo más simples posibles tanto como sea posible a través
de no agregar nuevas funcionalidades antes de que sean agendadas.
F. TARJETAS CRC
Usar Tarjetas CRC (Class, Responsibilities and Collaboration) para diseñar el sistema
en conjunto. La mayor ventaja de las tarjetas CRC es permitir reducir el modo de pensar
procedural y apreciar la tecnología de objetos. Las tarjetas CRC permiten contribuir al
diseño a todo el equipo del proyecto.
G. PROGRAMACIÓN EN PAREJAS
Toda la producción de código debe realizarse con trabajo en parejas de programadores.
La programación de a pares incrementa la calidad del software sin impactar el tiempo
para cumplir lo prometido. No es muy intuitivo, pero dos personas trabajando en una
sola computadora agregarán tantas funcionalidades como si estuvieran trabajando por
separado, excepto que lograrán una mayor calidad. Y con una mayor calidad tendremos
grandes ahorros de tiempo en el futuro.
Página | 11
CAPITULO III: DESARROLLO DEL PROYECTO
3.1. FASE DE PLANIFICACIÓN
3.1.1. PRINCIPALES ACTIVIDADES
Las actividades estarán en función al periodo programado por los integrantes del proyecto
DURACIÓN COMIENZO FIN
CRONOGRAMA DE PRÁCTICAS 76 días lun 28/09/15 lun 11/01/16
INICIACIÓN 3 días lun 28/09/15 mié 30/09/15
Coordinación de horarios con la empresa 1 día lun 28/09/15 lun 28/09/15
Explicación de problemática 1 día mar 29/09/15 mar 29/09/15
Listar los requerimientos de la empresa 1 día mié 30/09/15 mié 30/09/15
PLANIFICACIÓN 8 días sáb 03/10/15 lun 12/10/15
Maqueteo de la aplicación 2 días sáb 03/10/15 dom 04/10/15
Revisión del maqueteo y anotación de errores 1 día lun 05/10/15 lun 05/10/15
Corrección de errores 2 días mar 06/10/15 mié 07/10/15
Retroalimentación del maqueteo 3 días sáb 10/10/15 lun 12/10/15
EJECUCIÓN Y CONTROL 61 días lun 12/10/15 lun 04/01/16
Diseño de la base de datos 4 días lun 12/10/15 sáb 17/10/15
Desarrollo de la base de datos 8 días dom 18/10/15 mar 27/10/15
Presentación y revisión de la base de datos 1 día mié 28/10/15 mié 28/10/15
Retroalimentación de la base de datos 4 días sáb 31/10/15 mar 03/11/15
Desarrollo de la aplicación en C# 25 días mié 04/11/15 mar 08/12/15
Presentación y revisión del proyecto en la empresa 1 día mié 09/12/15 mié 09/12/15
Retroalimentación del proyecto 7 días sáb 12/12/15 dom 20/12/15
Verificación de conexiones para el software 1 día lun 21/12/15 lun 21/12/15
Realizar conexión para el proyecto 2 días mar 22/12/15 mié 23/12/15
Instalación del proyecto en la empresa 5 días sáb 26/12/15 mié 30/12/15
Prueba del proyecto 3 días sáb 02/01/16 lun 04/01/16
CIERRE 5 días mar 05/01/16 lun 11/01/16
Listar datos de la empresa 3 días mar 05/01/16 sáb 09/01/16
Llenado de los datos en los software 2 días sáb 09/01/16 dom 10/01/16
Entrega del manual de usuario 1 día lun 11/01/16 lun 11/01/16
Tabla 2: Cronograma del proyecto.
Tiempo Estimado del proyecto: 76 días calendario

Horario de trabajo:
 Lunes, Martes, Domingo (8:00 – 13:00)
 Sábado (8:00 – 13:00 , 15:00 – 18:00)
Página | 12
Esta es la planificación de historias usuarios que realizamos del proyecto, tras estudiar el proyecto
y mantener conversaciones con el cliente. De esta redacción inicial de historias de usuario se
realizó una planificación inicial y posteriormente fue cambiada a lo largo del proyecto. A medida
que cambiaban los requisitos del cliente o se tenía una concepción más clara del proyecto.
3.1.2. Historia de usuarios:

Numero Nombre de historia Prioridad en negocio
1 Registro de proveedores Alta
2 Registro de clientes Media
3 Registro de mercancía Alta
4 Registro de venta Alta
5 Registro de garantía Alta
ITERACIONES
PRIMERA ITERACIÓN
Consta de 2 historia de usuario:
Registro de clientes
Registro de proveedores
Tareas a realizar:
Diseño de interfaz Registro de clientes.
Diseño de interfaz Registro de proveedores.
SEGUNDA ITERACIÓN
Consta de 1 historia de usuario:
Registro de mercancía
Tareas a realizar:
Diseño de interfaz Registro de mercancía
TERCERA ITERACIÓN
Consta de 2 historias de usuarios:
Registro de venta
Registro de garantía
Tareas a realizar:
Diseño de interfaz Registro de venta
Diseño de interfaz Registro de garantía
Página | 13
PRIMERA ITERACIÓN
HISTORIA DE USUARIO
Historia de Usuario
Número: 1 Usuario: Jefe de almacén
Nombre historia: Registro de proveedores
Prioridad en negocio: Alta Riesgo en desarrollo: Baja
Iteración asignada: 1
Programador responsable: Remso Rojas – Milagros Guarniz
Descripción:
El registro de proveedores se realiza tomando en cuenta los datos principales de cada
proveedor, para tener un mejor control de todos los proveedores que se asocian a la empresa.
El jefe de almacén dispondrá de un botón que le dirigirá al formulario para rellenar los datos
necesarios del proveedor.
Observaciones:
Historia de Usuario
Nombre historia: Registro de clientes
Prioridad en negocio: Alta Riesgo en desarrollo: Baja
Descripción:
El registro de clientes se realiza tomando en cuenta los datos principales de cada uno, para tener
un mejor control de todos los clientes que se asocian a la empresa. El jefe de almacén dispondrá
de un botón que le dirigirá al formulario para rellenar los datos necesarios del cliente.
Observaciones:

Página | 14
TAREA A REALIZAR
Tarea
Número de tarea: 1 Numero de historia: 1
Nombre de la tarea: Diseño de interfaz Registro de clientes.
Tipo de tarea: Desarrollo
Descripción:
Se desarrollara una ventana que contendrá todos los campos que será ingresado por el jefe de
almacén para realizar un registro de los clientes
Tarea
Nombre de la tarea: Diseño de interfaz Registro de proveedores..
Descripción:
almacén para realizar un registro de los proveedores
Página | 15
SEGUNDA ITERACIÓN
HISTORIA DE USUARIOS
Historia de Usuario
Nombre historia: Registro de mercadería
Prioridad en negocio: Alta Riesgo en desarrollo: Alta
Descripción:
El jede de almacén ingresara la cantidad de productos que llegan a la empresa, ingresando un
numero de la guía de remisión, le proveedor y la fecha.
Se ingresaran todos los datos que pide la interfaz, para después agregarlos a la base de datos.
Observaciones:
Los nombre de los proveedores se mostraran en la interfaz, solo para seleccionarlo
TAREAS A REALIZAR
Tarea
Nombre de la tarea: Diseño de interfaz Registro de mercancía.
Descripción:
almacén para realizar un registro de los productos que entran en la tienda.
Página | 16
TERCERA ITERACIÓN
Historia de Usuario
Nombre historia: Registro de venta
Descripción:
El jede de almacén ingresara la cantidad de productos que vende en la empresa, ingresando un
numero de la guía de venta, le cliente y la fecha.
Se seleccionara todos los datos que pide la interfaz, para después agregarlos a la base de datos.
Observaciones:
Los nombre de los clientes se mostraran en la interfaz, solo para seleccionarlo
Historia de Usuario
Nombre historia: Registro de garantia
Descripción:
El jede de almacén ingresara la cantidad de productos que salen de la empresa con destino a
irse al proveedor, ingresando un numero de la garantía, le proveedor y la fecha.
Se ingresaran todos los datos que pide la interfaz, para después agregarlos a la base de datos.
Observaciones:
Los nombre de los proveedores se mostraran en la interfaz, solo para seleccionarlo
Página | 17
TAREAS A REALIZAR
Tarea
Nombre de la tarea: Diseño de interfaz Registro de venta.
Descripción:
almacén para realizar un registro de los productos que salen de la tienda hacia los clientes
Tarea
Nombre de la tarea: Diseño de interfaz Registro de garantía.
Descripción:
almacén para realizar un registro de los productos que salen por garantía hacia los proveedores
Página | 18
3.1.3. REQUERIMIENTOS DEL SISTEMA DE INFORMACION
REQUERIMIENTO DE SOFTWARE
Aquí se denotan todos los requerimientos de software que permita a los diseñadores
realizar el diseño de un sistema que satisfaga dichos requerimientos y probar que el
sistema cumple con lo planteado.
1. REQUERIMIENTO FUNCIONALES
 Login
Esta funcionalidad permite al administrador crear usuarios, eliminar y editar, que
harán uso del sistema.
 Inventariado de los productos

Esta funcionalidad permitirá al jefe de almacén revisar constantemente el stock
de los productos que entran en la empresa
 Registrar los productos comprados

Esta funcionalidad permitirá al jefe de almacén registrar los productos comprados
adjuntando con las guías de remisión.
 Actualizar stock
Esta funcionalidad permite actualizar el stock de los productos en la empresa.
 Registrar los productos que se venden

Esta funcionalidad permite al jefe de almacén registra los productos que salen de
la empresa.
 Gestionar clientes
Esta funcionalidad permite al administrador registrar todos los clientes.
 Gestionar proveedores
Esta funcionalidad permite al administrador registrar todos los proveedores.
 Registrar los productos que salen por garantía

Esta funcionalidad permite al jefe de almacén que registra los productos que salen
de la empresa por medio de garantía.
 Reporte de entrada
Esta funcionalidad permite saber el número de productos que entraron a la tienda,
permitiendo ver en una fecha determinada.
 Reporte de salida
Esta funcionalidad permite saber el número de productos que salieron de la
tienda, permitiendo ver en una fecha determinada.
Página | 19
 Reporte de garantía
Esta funcionalidad permite saber el número de productos que fueron llevados por
garantía.
 Reporte de stock total

Esta funcionalidad permite saber el total de productos que se encuentran en la
tienda.
2. REQUERIMIENTO NO FUNCIONALES
 Escalabilidad
El sistema contempla el uso óptimo de recursos tales como conexiones a base de
datos. A la vez el diseño está enmarcado por el orden en el cual se maneja la
distribución de las capas de desarrollo.
 Disponibilidad
El sistema garantiza la disponibilidad en todo momento, esto significa que estará
disponible en cualquier momento en el que el usuario lo requiera.
 Seguridad
El sistema cuenta con estándares y patrones de seguridad que le brindan la
seguridad necesaria para mantener a salvo la aplicación y el acceso a ella.
 Desempeño
El sistema permite un buen desempeño con un tiempo de respuesta menos a 5
segundos ante la alta demanda de peticiones.
Página | 20
3.2. FASE DE DISEÑO
3.2.1. DISEÑO DE ARQUITECTURA
ARQUITECTORA GENERAL DE SISTEMAS
1. REPRESENTACION
Capa de aplicación y lógica

Módulo de negocio Visual C Sharp (C#)
Negocio
Base de datos
Base de datos del sistema Capa de Base de datos
SQL
a. Capa de lógica de negocio

Esta capa es la que pose todas las funciones que realizará el sistema, estas
funciones están agrupadas para un mejor desempeño de la aplicación. Estas
aplicaciones están basadas en lenguaje de programación C Sharp.
b. Capa de acceso a datos

Esta capa nos permite saber cómo está distribuido el esquema de la base de datos,
la relación entre las tablas y su implementación física. Un buen desarrollo de estos
puntos permite al sistema realizar las funcionalidades del sistema adecuadamente
2. VISTA DE IMPLEMENTACION
Ilustración 3: Implementación de las capas.

Página | 21
3.2.2. MODELO DE BAS DE DATOS
Ilustración 4: Esquema de la base de datos.

Página | 22
3.2.3. TARJETA CRC
PRODUCTO
ATRIBUTOS COLABORADORES
ID_Producto Administrador
Nombre Jefe de Almacén
Marca
Codigo
Serie
Autogenerado
Caracteristicas
Estado
RESPONSABILIDADES
Información de los productos de que llegan a
la empresa
GUIA DE REMISION
ID_Guia Administrador
Numero Jefe de Almacén
Fecha
RUC
RESPONSABILIDADES
Información de los datos generales de una
guía de remisión
DETALLE GUIA
ID_Guia Administrador
ID_Producto Jefe de Almacén
Cantidad Guía de remisión
RESPONSABILIDADES
Información del detalle de la guía de remisión
PROVEEDOR
RUC Administrador
NombreProv Jefe de Almacén
Descripcion
RESPONSABILIDADES
Información de los datos generales de los
proveedores
Página | 23
CLIENTE
DOC_Identidad Administrador
Nombre_Cliente Jefe de Almacén
Telefono
RESPONSABILIDADES
Información de los datos generales de los
clientes
SALIDA
IDSalida Administrador
NumSalida Jefe de Almacén
TipoSalida
DOC__Identidad
FechaSalida
RESPONSABILIDADES
salida
DETALLE_SALIDA
ID_Salida Administrador
Cantidad
RESPONSABILIDADES
Información del detalle de la salida
SALIDA GARANTIA
ID_SalidaGarantia Administrador
RUC Jefe de Almacén
FechaIngreso
RESPONSABILIDADES
salida por garantía
DETALLE SALIDA GARANTIA

ID_SalidaGarantia Administrador
Cantidad
RESPONSABILIDADES
Página | 24
Información de detalle de salida por garantía
USUARIO
ID_Usuario Administrador
Usuario Jefe de Almacén
Contraseña
Tipo
RESPONSABILIDADES
Información de los datos generales de un
usuario
DETALLE NOTIFICACION
ID_Noti Administrador
ID_Usuario
RESPONSABILIDADES
Información del detalle de las notificaciones
Página | 25
3.2.4. DICCIONARIO DE DATOS
TABLA
PRODUCTO
CAMPOS TIPO DE CAMPOS
ID_Producto INT
Nombre VARCHAR(50)
Marca VARCHAR(50)
Codigo VARCHAR(50)
Serie VARCHAR(50)
Autogenerado VARCHAR(50)
Caracteristicas VARCHAR(50)
Estado
TABLA
GUIA DE REMISION
ID_Guia INT
Numero VARCHAR(20)
Fecha DATE
RUC VARCHAR(50)
TABLA
DETALLE GUIA
ID_Guia INT
ID_Producto VARCHAR(20)
Cantidad INT
TABLA
PROVEEDOR
RUC INT
NombreProv VARCHAR(20)
Descripcion VARCHAR(50)
TABLA
CLIENTE
DOC_Identidad VARCHAR(20)
Nombre_Cliente VARCHAR(20)
Telefono VARCHAR(20)
Página | 26
TABLA
SALIDA
IDSalida INT
NumSalida VARCHAR(20)
TipoSalida VARCHAR(20)
DOC_Identidad VARCHAR(20)
FechaSalida DATE
TABLA
DETALLE_SALIDA
ID_Salida INT
ID_Producto INT
Cantidad VARCHAR(20)
TABLA
SALIDA GARANTIA
ID_SalidaGarantia INT
RUC VARCHAR(20)
FechaIngreso DATE
TABLA
DETALLE SALIDA GARANTIA
ID_SalidaGarantia INT
ID_Producto INT
Cantidad VARCHAR(20)
TABLA
USUARIO
ID_Usuario INT
Usuario VARCHAR(20)
Contraseña VARCHAR(20)
Tipo VARCHAR(20)
TABLA
DETALLE NOTIFICACION
Página | 27
ID_Noti INT
ID_Usuario INT
3.2.5. PROTOTIPO
1. INICIO SESION
2. REGISTRAR USUARIO
Página | 28
3. REGISTRAR PROVEEDORES
4. REGISTRO DE TIPO DE PRODUCTO
Página | 29
5. REGISTRO DE MARCA DE PRODUCTO
6. REGISTRO DE CODIGO DE PRODUCTO
Página | 30
Página | 31
7. REGISTRO DE GUIA DE REMISION
Página | 32
8. REGISTRO DE SALIDA
Página | 33
9. REGISTRO SALIDA POR GARANTIA
10. LISTADO DE PRODUCTOS EN LA TIENDA
Página | 34
11. LISTADO DE PRODUCTOS SALIENTES
12. LISTADO DE PRODUCTOS POR GARANTIA
Página | 35
Página | 36
13. REPORTES DE ENTRADA
14. REPORTE DE SALIDA
Página | 37
15. REPORTES DE PRODUCTOS EN GARANTIA
16. REPORTE DE STOCK TOTAL
Página | 38
3.3. FASE DE CODIFICACION
Para esta fase utilizamos el método de programación en parejas y la refactorización, para no

redundar en mucha codificación y tener un orden al momento que se requiera un cambio en el
código, hacer que el impacto sea menor sobre el proyecto.
Reglas de codificación
 Solo una pareja realizara la integración a la vez.
 Se utilizará solo un computador para la programación: se debe tener en claro cuál
es la última versión del código, evitando la duplicidad
 Se deben realizar interacciones frecuentes: se realizaran integraciones cada pocas
horas o en lo posible no tardar más de un día en integrar los códigos
Página | 39
3.4. FASE DE PRUEBAS
3.4.1. PRUEBAS FUNCIONALES
Cada documento está asociado a una historia de usuario diferente, y en ellos se describen los
posibles modos de utilización de la aplicación en cada una de estas historias de usuario. En los
documentos se indican la respuesta que tiene la aplicación en la utilización de cada una de estas
funcionalidades, así como los posibles mensajes de error, información o de aceptación que emite
la aplicación cuando se utiliza dicha funcionalidad.
1. CASO DE PRUEBA FUNCIONAL: Registrar proveedores
Registro funcionales: Nombre de proceso: Prueba Nro: 1 Fecha de prueba

Registrar proveedores Registrar proveedores Historia Nro: 1 12/11/15
Descripción
Caso Descripción del caso Condiciones de Prueba Resultados esperados
Nro
1 Registrar proveedores 1. Acceso correcto al sistema El sistema muestra el
con el usuario administrador siguiente mensaje
2. Ingresar la opción registrar “registro correcto”
proveedores
3. Escribir los datos de los
proveedores
4. Agregue los procesos en la
tabla identificador
Nombre:
• Deltron
RUC
• 20212331377
Descripción
• San Fernando 125
2 Mensaje de error al 1. Acceso correcto al sistema El sistema muestra

registrar proveedores con el usuario administrador mensaje “ “
2. Ingresar la opción registrar
proveedores
proveedores
Página | 40
2. CASO DE PRUEBA FUNCIONAL: Registrar clientes

Registrar cliente Registrar cliente Historia Nro: 2 12/11/15
Descripción
Nro
1 Registrar cliente 1. Acceso correcto al sistema El sistema muestra el
con el usuario administrador siguiente mensaje
clientes
clientes
4. Agregue los procesos en la
tabla identificador
Nº documento:
• 4745863
Nombre
• Rafael Rubiños
Telefono
• 214585

registrar cliente con el usuario administrador mensaje “ “
2. Ingresar la opción registrar
clientes
clientes.
Página | 41
3. CASO DE PRUEBA FUNCIONAL: Registrar mercancía

Buscar proveedores Registrar mercancía Historia Nro: 3 12/11/15
Registrar mercancía
Descripción
Nro
1 Registrar mercancía 1. Acceso correcto al sistema El sistema mostrara la
con el usuario administrador información necesitada:
2. Ingresar la opción registrar Fecha:
entrada de producto • 15/01/2016
3. Agregar los datos Proveedor:
correspondiente: • Deltron
Numero de guía:
• 001
Selecciona la fecha
correspondiente
Seleccionar el proveedor
1 Registrar detalle de 1. Acceso correcto al sistema El sistema muestra el

guía de remision con el usuario administrador siguiente mensaje
entrada de producto
3. Seleccionar
Tipo de producto
• Laptop
Marca
• Asus
Código
• K55l
4. Ingresar:
Serie
• 011
Descripcion
• 1 TB, 2GB tarjeta
grafica
registrar guía de con el usuario administrador mensaje “ “
remisión 2. Ingresar la opción registrar
entrada de producto
3. Escribir los datos de la
entrada de producto
Página | 42
4. CASO DE PRUEBA FUNCIONAL: Registrar venta
Buscar cliente Registrar Venta Historia Nro: 5 12/11/15
Buscar producto
Descripción
Nro
1 Registrar venta 1. Acceso correcto al sistema El sistema mostrara la
con el usuario administrador información necesitada:
2. Ingresar la opción registrar Tipo de salida:
Salida productos • Boleta
3. Agregar los datos Fecha:
correspondiente: • 15/01/2016
Numero de salida: Proveedor:
• 001 • Rafael Rubiños
Selecciona el tipo de salida
Seleccionar la fecha
Seleccionar el cliente
2 Registrar venta con 1. Acceso correcto al sistema El sistema muestra el

nuevo cliente con el usuario administrador siguiente mensaje
Salida productos
3. Seleccionar nuevo
4. Agregar datos
correspondiendo a clientes
guía de remision con el usuario administrador siguiente mensaje
salida producto.
3. Buscar producto y añadir
registrar guía de con el usuario administrador mensaje “ Error, revise los
remisión 2. Ingresar la opción registrar datos “
salida producto.
3. Buscar producto y añadir
Página | 43
5. CASO DE PRUEBA FUNCIONAL: Registrar garantía
Buscar proveedores Registrar mercancía Historia Nro: 3 12/11/15
Descripción
Nro
1 Registrar garantía 1. Acceso correcto al sistema El sistema mostrara la
producto con el usuario información necesitada:
administrador Fecha:
2. Ingresar la opción registrar • 15/01/2016
garantía producto Proveedor:
3. Agregar los datos • Deltron
correspondiente:
Numero:
• 001
Selecciona la fecha
correspondiente
Seleccionar el proveedor

garantía producto con el usuario administrador siguiente mensaje
2. Buscar y añadir producto “registro correcto”
registrar garantía con el usuario administrador mensaje “ “
producto 4. Ingresar la opción registrar
garantía producto
5. Escribir los datos de la
garantía de producto
Página | 44
CONCLUSIONES
Retomando con los objetivos que se han propuesto para el desarrollo del proyecto tenemos:
 El primer se refería a “Implementar e implantar una aplicación para la gestión de

productos de almacén de la empresa de venta de computo COMPUMALL E.I.R.L.”,
por lo que después de desarrollar la aplicación, en el tiempo que se estableció en el
plan de prácticas, se logró llevar el correcto seguimiento y control de productos para
el área de almacén
 El segundo objetivo fue “Obtener los resultados actualizados en el tiempo que la

organización requiera para la toma de decisiones, por lo que después de realizar el
estudio de la organización, análisis y diseño de prototipos se determinó que la
organización ya no tendrá problemas con los resultados correctos ya que los
resultados se estarán actualizando correctamente y constantemente.
 El tercer objetivo fue “Contar con bases de datos consolidadas en la organización”,

por lo que después de realizar el análisis de los diferente motores de base de datos
que posee la organización se determinó que para consolidar todas la base de datos se
tendrá que esta estandarizar y realizar integraciones.
Página | 45
BIBLIOGRAFÍA
 TRIPOD. (2005). Fases de la Programación Extrema. 2012, de TRIPOD Sitio web:

http://programacionextrema.tripod.com/fases.htm#primeraFase
 UNIVERSIDAD NACIONAL DE TRUJILLO SEDE VALLE JEQUETEPEQUE.

(2010). METODLOGIAS ÁGILES PARA EL DESARROLLO DE SOFTWARE. 2015,
de . UNTVJ Sitio web: http://es.slideshare.net/ChristianGH/monografia-metodologia-xp
 Luis Miguel Echeverry Tobón y Luz Elena delgado Carmona (2007), caso práctico de la
metodología ágil XP al desarrollo de software recuperado de
repositorio.utp.edu.co/dspace/bitstream/11059/794/1/0053E18cp.pdf
 Patricio Letelier y Mª Carmen Penadés, Métodologías ágiles para el desarrollo de

software: eXtreme Programming (XP)(2004) recuperado de
http://users.dsic.upv.es/asignaturas/eui/lds/doc/masyxp.pdf
 Extreme Programming (XP) (2006) recuperado de
http://www.fing.edu.uy/inco/cursos/gestsoft/Presentaciones/XP%20-%20G3/XP.doc.
Página | 46

Informe Final

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Informe Final

Uploaded by

Copyright:

Available Formats

Facultad de Ingeniería

TEMA DE PRÁCTICAS : “SISTEMA DE GESTIÓN DE ALMACÉN ”

1.1. DESCRIPCION GENERAL DE LA ORGANIZACIÓN

 Fecha de inicio actividades

Ilustración 1: Ubicación de COMPUMALL E.I.R.L.

1.3. RESEÑA HISTORICA

Compumall EIRL tiene como predecesora a una empresa de mayor tiempo en el

Información brindada por COMPUMALL E.I.R.L.

Información brindada por COMPUMALL E.I.R.L.

1.6. ESTRUCTURA ORGANICA

Ilustración 2: Organigrama de COMPUMALL E.I.R.L.

2.1. REALIDAD PROBLEMÁTICA

Entre otros problemas que se pueden encontrar tenemos:

2.2. JUSTIFICACION DEL PROYECTO

La influencia de la tecnología y los sistemas de información en el ser humano ha tomado

2.3. OBJETIVOS DEL PROYECTO

2 Equipos S/. 2.900,00

3 Viajes S/. 420,00

4 Materiales S/. 0,00

5 Imprevistos S/. 0,00

TOTAL S/. 3.320,00

DETALLE DE LOS EQUIPOS

El ciclo de desarrollo consiste (a grandes rasgos) en los siguientes pasos:

Las estimaciones de esfuerzo asociado a la implementación de las historias la establecen

La planificación se puede realizar basándose en el tiempo o el alcance. La velocidad del

6. MUERTE DEL PROYECTO

B. ESCRIBIR HISTORIAS DE USUARIO

D. ROTACIÓN DEL EQUIPO

Tiempo Estimado del proyecto: 76 días calendario

3.1.2. Historia de usuarios:

Número: 1 Usuario: Jefe de almacén

Nombre historia: Registro de proveedores

Prioridad en negocio: Alta Riesgo en desarrollo: Baja

Programador responsable: Remso Rojas – Milagros Guarniz

Fuente: Hecha por el grupo

Número: 2 Usuario: Jefe de almacén

Nombre historia: Registro de clientes

Prioridad en negocio: Alta Riesgo en desarrollo: Baja

Programador responsable: Remso Rojas – Milagros Guarniz

Fuente: Hecha por el grupo

Número de tarea: 1 Numero de historia: 1

Nombre de la tarea: Diseño de interfaz Registro de clientes.

Tipo de tarea: Desarrollo

Fuente: Hecha por el grupo

Número de tarea: 2 Numero de historia: 2

Nombre de la tarea: Diseño de interfaz Registro de proveedores..

Tipo de tarea: Desarrollo

Fuente: Hecha por el grupo

Número: 3 Usuario: Jefe de almacén

Nombre historia: Registro de mercadería

Prioridad en negocio: Alta Riesgo en desarrollo: Alta

Programador responsable: Remso Rojas – Milagros Guarniz

Fuente: Hecha por el grupo

Número de tarea: 3 Numero de historia: 3

Nombre de la tarea: Diseño de interfaz Registro de mercancía.

Tipo de tarea: Desarrollo

Fuente: Hecha por el grupo

Número: 4 Usuario: Jefe de almacén

Nombre historia: Registro de venta

Prioridad en negocio: Alta Riesgo en desarrollo: Alta

Programador responsable: Remso Rojas – Milagros Guarniz

Fuente: Hecha por el grupo

Número: 5 Usuario: Jefe de almacén