Académique Documents
Professionnel Documents
Culture Documents
Ingeniería de la Computación
Por
Ingeniero en Computación
Por
Elianna Bugallo Piersanti
RESUMEN
En el presente informe se describen las actividades desarrolladas durante el período de pasantía larga,
realizada en la empresa CENTROBECO C.A, y de todas las herramientas utilizadas para lograr cumplir con los
objetivos de este proyecto.
El objetivo de esta pasantía se traduce en analizar, desarrollar e implementar un sistema Web de acceso
interno (Prototipo Funcional), que permita llevar el control y gestión del proceso de orden de compra, despachos,
activos y servicios de insumos internos necesarios (SOCDISAS) en la Empresa CENTROBECO, C.A. Este sistema
permite principalmente a los colaboradores emitir órdenes de compra, notas de recibo, y despachar los insumos
recibidos entre las tiendas y departamentos, además de permitir realizar pedidos desde el lugar de trabajo. Todo esto
se hará con el fin de poder mejorar la forma en cómo se llevan cada uno de estos procesos actualmente. Además,
SOCDISAS permite llevar de una manera más organizada y actualizada toda la información que se tenga sobre
proveedores, insumos, líneas de insumos, almacenes, solicitudes de cotización, facturas internas, cuentas contables,
centros de costo y usuarios.
Para ello, se utilizó la metodología Racional Unified Process (RUP), y el lenguaje de modelado UML, para
llevar a cabo de la manera más eficaz, el proceso de desarrollo de este sistema y la entrega de un producto de
software que cumpla con los requisitos establecidos.
iii
DEDICATORIA
A mis padres, porque después de Dios, gracias a ellos he llegado hasta aquí
iv
AGRADECIMIENTOS
A mi Salvador Jesús, a quien quiero y respeto mucho. Gracias por tu infinita paciencia y cariño
A mis padres, por apoyarme en todo lo que hago y llevarme por este largo camino
A mi compañero de pasantía Daniel Fernández. Tantos años de sacrificio juntos, finalmente dieron
resultados
Al resto de mis amigos: Carmen, Marilyn, Fabiana y Carlos, por todas las vivencias y experiencias
que hemos tenido en estos 5 años. Buenas o malas, han fortalecido grandemente nuestros lazos, y
A todos mis amigos de Comisión de Carrera: Vicky, Gian Paolo, Francisco, Mariana, Alfredo. Se
Gracias a todos
v
ÍNDICE GENERAL
1. INTRODUCCIÓN...............................................................................................................................1
2. ENTORNO EMPRESARIAL..............................................................................................................3
2.1 Antecedentes de la empresa...........................................................................................................3
2.2 Misión................................................................................................................................................4
2.3 Visión ................................................................................................................................................4
2.4 Estructura Organizacional...............................................................................................................4
2.5 Gerencia de Sistemas......................................................................................................................5
3. DEFINICIÓN DEL PROYECTO.........................................................................................................7
3.1 Planteamiento del Problema ...........................................................................................................7
3.2 Solución propuesta.......................................................................................................................10
3.3 Objetivo General.............................................................................................................................12
3.4 Objetivos Específicos....................................................................................................................12
4. MARCO TEÓRICO.........................................................................................................................13
4.1 Arquitectura en Capas:..................................................................................................................13
4.2 Unified Modeling Language (UML) ...............................................................................................14
4.3 Programación orientada a Objetos...............................................................................................15
4.3.1 Características de la POO...................................................................................................................15
4.4 El lenguaje de Programación JAVA..............................................................................................16
4.4.1 Ventajas de JAVA ...............................................................................................................................16
4.5 Modelo Vista Controlador (MVC) ..................................................................................................16
4.6 Struts...............................................................................................................................................17
4.6.1 ¿Como funciona Struts?...................................................................................................................... 17
4.6.2 Ventajas de Struts: [WebAppsWiki 2005]............................................................................................ 18
5. MARCO METODOLÓGICO ............................................................................................................19
5.1 Rational Unified Process...............................................................................................................19
5.2 Estructura del Proceso: Dos Dimensiones..................................................................................20
5.2.1 Fase de Inicio ......................................................................................................................................21
5.2.2 Fase de Elaboración ...........................................................................................................................22
5.2.3 Fase Construcción ..............................................................................................................................22
5.2.4 Fase de Transición..............................................................................................................................23
6. DESARROLLO................................................................................................................................24
6.1 Fase de Inicio..................................................................................................................................24
vi
6.1.1 Plan de Proyecto .................................................................................................................................24
6.1.2 Visión del sistema ...............................................................................................................................25
6.1.3 Lista Inicial de Requerimientos ...........................................................................................................25
6.1.4 Lista Inicial de Riesgos........................................................................................................................ 31
6.1.5 Herramientas de Desarrollo ................................................................................................................32
6.1.6 Infraestructura de Desarrollo...............................................................................................................33
6.1.7 Plan de Proyecto para la Fase de Elaboración ..................................................................................34
6.2 Fase de Elaboración ......................................................................................................................35
6.2.1 Vista de Casos de Uso........................................................................................................................ 36
6.2.2 Vista Lógica.........................................................................................................................................36
6.2.3 Vista de Procesos ...............................................................................................................................39
6.2.4 Vista de Implementación o Desarrollo................................................................................................. 40
6.2.5 Vista de Implantación o Física ............................................................................................................41
6.2.6 Plan de Proyecto para la Fase de Construcción .................................................................................42
6.3 Fase de Construcción....................................................................................................................43
6.3.1 Modelo Entidad- Interrelación .............................................................................................................43
6.3.2 Aspectos del Desarrollo ...................................................................................................................... 44
6.3.3 Diagramas de Secuencia .................................................................................................................... 45
6.3.4 Interfaz gráfica con el usuario .............................................................................................................45
6.3.5 Pruebas Realizadas ............................................................................................................................48
7. CONCLUSIONES Y RECOMENDACIONES...................................................................................51
8. REFERENCIAS BIBLIOGRÁFICAS ...............................................................................................52
vii
ÍNDICE DE FIGURAS
viii
ÍNDICE DE TABLAS
ix
LISTA DE SIMBOLOS Y ABREVIATURAS
MB Megabyte.
x
1. INTRODUCCIÓN
Cada vez es mayor el auge que la computación ha tenido, y cada vez se hace más importante optimizar las
operaciones que se realizan, porque la demanda es mayor día a día. Es por esto que las empresas están invirtiendo
sumas considerables de dinero en herramientas o tecnologías, que permitan disminuir el costo de operaciones, y
lograr así la sobrevivencia en el mercado, que se torna más competitivo.
CENTROBECO está consiente de ello y por eso está en la búsqueda de soluciones que permitan
automatizar cada uno de sus procesos, siempre con el norte de brindar a los clientes el mejor servicio, y mejorar la
productividad en cada una sus tiendas, y departamentos.
En este sentido, se propone como solución exitosa el Sistema de Orden de Compra, Despacho, Insumos,
Activos y Servicios, conocido como SOCDISAS, que permitirá automatizar los procesos de emisión de órdenes de
compra, despacho e inventario de todos aquellos suministros no comerciales, pero importantes para el buen
funcionamiento de la empresa. Hasta ahora estos procesos han sido apoyados con la ayuda de Microsoft Excel, el
teléfono, fax y correo electrónico. Esta forma de llevar las tareas ha hecho que la Coordinación de Suministros no
responda con la misma eficacia de otros tiempos, principalmente porque el sistema requiere de mucho control
humano y la demanda de productos y servicios ha aumentado, pues se han abierto más tiendas y la sede
administrativa tiene mayor personal.
SOCDISAS se diseñó e implementó como una aplicación Web con acceso local, que permite llevar los
procesos de orden de compra, recepción de suministros, inventario y distribución, haciendo uso de la metodología de
desarrollo y las herramientas más adecuadas para lograr cumplir todos los requerimientos definidos.
Este trabajo está estructurado en 8 capítulos. En el presente Capítulo 1, se presenta una breve introducción
al proyecto, expresando la importancia del mismo, y las ventajas de su implementación.
El Capítulo 2, Entorno Empresarial, contiene una breve descripción de diversos aspectos de la empresa
CENTROBECO C.A.
El Capítulo 3, Definición del Proyecto, contiene el planteamiento del problema, se describe el trabajo a
realizar, su alcance, su justificación y los resultados que se esperan obtener en forma de objetivo general y
específicos.
1
2
El Capítulo 4, Marco Teórico, presenta las bases teóricas en las cuales se fundamenta el desarrollo del
sistema.
El Capítulo 5, Marco Metodológico, describe la metodología utilizada para el desarrollo del sistema.
El Capítulo 6, Desarrollo, explica todo lo realizado durante el período de pasantía larga, para cada una de
las fases de la metodología utilizada.
El Capítulo 7, Conclusiones, muestra las conclusiones y objetivos alcanzados para el período de pasantía
larga.
El Capítulo 8, Referencias Bibliográficas, muestra todos los libros artículos y/o enlaces utilizados como
apoyo durante el período de pasaría larga y redacción del informe.
En la sección de apéndices se presentan los artefactos creados para el sistema SOCDISAS, esto con el fin
de comprender mejor lo realizado y lo obtenido durante el mismo
En la sección de anexos, se encuentra el pedido inicial entregado del sistema de orden de compra
suministros
2. ENTORNO EMPRESARIAL
En este capítulo se mostrará una idea general de cómo está estructurada la empresa, sus departamentos y
cuál es su función. Además se especifica el departamento donde laboró el pasante. Esto es con el fin de tener una
mejor noción de la compañía, y de cómo ésta desempeña sus actividades para lograr su misión.
BECO es una empresa privada venezolana que forma parte de la reconocida organización BECOBLOHM, la
cual fue fundada por el comerciante George Blohm en el año de 1835.
La Compañía comienza sus actividades como tiendas por departamentos en 1965, en el Estado Lara. Su
fundación se debió a la visión de satisfacer las necesidades del consumidor directamente, ofreciendo productos y
servicios en un ambiente agradable y dinámico.
Una vez establecida la Compañía en el mercado, comienza la fase de profundización en los procesos
administrativos e implementación de nuevos sistemas de información, que permiten mayor eficiencia operativa.
Simultáneamente, se involucra en un constante proceso de crecimiento, inaugurando tiendas en las principales
ciudades del país, disfrutando de una excelente aprobación por parte de los consumidores, proveedores y
empleados.
3
4
En el año 2001, se inauguró la tienda piloto del Centro Comercial la Granja (Valencia), que refleja este
nuevo modelo comercial, basado en las categorías anteriores. Además, BECO está conformada por otras 7 tiendas,
un Centro de Distribución y la Oficina Central que reside en Caracas. Cada una de las tiendas, están ubicadas
estratégicamente en Caracas, Barquisimeto y Maracaibo, y juntas suman una superficie de 40.000 mts2 de
exhibición, ventas, servicios al cliente y depósitos.
2.2 MISIÓN
“Comercializar a través de dinámicas tiendas especializadas en Moda, Hogar, Belleza y Deporte, productos
y servicios de calidad a precios competitivos, satisfaciendo las aspiraciones de nuestros clientes y cumpliendo los
compromisos con nuestros relacionados” [BECO, 2007]
2.3 VISIÓN
“Hacer de las Tiendas BECO la mejor opción de compras por su excelente calidad en productos y servicios”
[BECO, 2007]
La Compañía se divide fundamentalmente por departamentos, entre los que se encuentran: Ventas,
Merchandising, Mercadeo, Personal, Control, Logística, Sistemas y Relaciones Institucionales. Cada uno de ellos
juega un papel fundamental dentro del correcto funcionamiento de la empresa:
En cuanto a la estructura organizativa de la empresa, se puede observar en la Figura 1, que ésta se divide
en seis niveles: Alta Gerencia (Nivel 1), Gerencia (Nivel2), Gerencia Media (Nivel 3), Supervisorio (Nivel 4),
Operativo (Nivel 5), Base (Nivel 6). Los niveles 4, 5 y 6, se representan de manera diferente para cada
Departamento.
Manejo de operaciones
Dotación de equipos
Adiestramiento del personal para el uso de aplicaciones; en general, ofrece servicios completos de
atención al usuario.
6
Luego de haber desarrollado este capítulo se tiene un conocimiento más amplio de empresa CENTROBECO, de
cómo trabaja, y como está estructurada. A continuación se presenta el capítulo referente a la Definición del Proyecto.
3. DEFINICIÓN DEL PROYECTO
En este capítulo, se define el proyecto que se desarrolló durante el período de pasantía larga. En él se
plantea el problema, la solución propuesta, y los objetivos que se establecieron durante este período.
BECO es una cadena de tiendas, que vende productos tanto nacionales como importados, clasificados en
las categorías principales que son: Hogar, Moda, Belleza y Deporte. Estos artículos se reciben en la sede principal
de la empresa, y de allí se despachan a cada una de las tiendas.
Todas las tiendas y departamentos de la sede principal, deben contar con insumos de carácter interno
(bolsas de compra para las tiendas, lápices, bolígrafos, etiquetas para precio, uniformes para los colaboradores,
etc.), para desempeñar mejor sus funciones. La Coordinación de Suministros es la encargada de llevar el control de
estos insumos, y de garantizar que estos no falten en los centros.
Para iniciar el proceso de compra de insumos, existen dos maneras de llevarlo a cabo. La primera forma es
realizar una solicitud previa a uno o varios proveedores, indicando los insumos que se quieran comprar. Los
proveedores entregarán un reporte indicando el precio de cada artículo, y cualquier oferta que sobre ellos tengan.
Con esta información, el Coordinador de Suministros decidirá cuál es la mejor oferta, y a partir de allí realizar una
compra directa a un proveedor.
La otra opción es emitir la orden de compra directamente, sin tener que hacer ninguna solicitud previa.
Luego de que la orden ha sido enviada al proveedor, éste debe entregar la mercancía en el centro de
distribución de la sede principal. El personal del Centro de Distribución comienza el proceso de recepción, y cuenta
por insumo, la cantidad que se recibe. Esta cantidad se compara con la orden de compra asociada, y con la factura
recibida por parte del proveedor. De este proceso se emite una nota de recibo, indicando entre otras cosas, la
cantidad según la orden de compra, la cantidad según la factura, la cantidad chequeada, y la cantidad que se
finalmente se acepta, la cual dependerá estrictamente de lo que ordene el Coordinador de Suministros. Además se
establece la condición de entrega de la nota, que puede ser: orden parcial (no se está entregando la mercancía
completa), orden total (se recibe toda la mercancía ordenada) y excedente (se recibe más de lo ordenado
inicialmente).
7
8
Para cancelar las notas de recibo emitidas, se envía a Finanzas el documento, y son ellos lo que proceden
a realizar el pago, bajo alguna de estas formas:
Pagos por adelanto: para que el proveedor comience a enviar la mercancía, es necesario cancelar un
porcentaje a priori. El porcentaje se establece directamente con el proveedor.
Pagos por pronto pago: en algunas ocasiones, los proveedores pueden hacer descuentos, si el tiempo de
pago es antes de una fecha concreta (Ejemplo: los primeros 7 días después del envío). Cuando la oferta resulta
conveniente, se realiza este tipo de pago.
Pagos normales: luego de recibir la mercancía, se cancela de la manera habitual, teniendo como fecha
tope la condición de pago establecida a priori en la orden de compra asociada (15 días, 30 días, etc.).
Con la nota de recibo, el Coordinador de Suministros procede a realizar el despacho de los insumos entre
los centros de costo, tomando en cuenta algunos de estos parámetros:
Por porcentaje de ventas: la tienda con mayor porcentaje de ventas, se le despachará mayor cantidad de
insumos.
Por artículos recibidos: se envía una factura indicando el monto a descontarse por los artículos enviados
Una vez repartido los insumos entre los centros de costo, se envía a cada uno una factura interna, donde se
notifica los insumos que se despacharon, la cantidad, el precio unitario y el total de la factura. Este monto se le resta
del presupuesto disponible del centro de costo asociado, para la fecha de emisión de la factura.
Además de controlar todo el proceso de compra y distribución de los insumos internos, la Coordinación de
Suministros tiene otras funciones que desempeñar:
Iniciar y cerrar un proceso de inventario: el proceso de inventario consiste en contar la cantidad física de
algunos insumos, y cotejar los resultados con lo que se tiene almacenado en documentos. Esto se realiza cada cierto
tiempo, con la finalidad de controlar la cantidad por insumo que se tiene en los almacenes o depósitos.
Para iniciar un proceso de inventario, se seleccionan los insumos que se van a inventariar, y se distribuyen
entre uno o varios auxiliares de la Coordinación. Los auxiliares se dirigen a los depósitos donde se guardan los
insumos asignados y comienzan a contar la cantidad física que se tiene en depósito para cada uno de ellos. Una vez
realizado este conteo, se compara los resultados obtenidos con la información que se tiene previamente almacenada
9
en documentos. Si existe una diferencia entre lo contado y lo previamente registrado, se procede a hacer un ajuste
de la cantidad, actualizando en función de los resultados, y se emite un reporte indicando todas esta diferencias.
Este reporte lo recibirá el Coordinador de Suministros, para su posterior estudio y análisis.
No debemos olvidar que, además de todas estas labores, se debe tener almacenados los proveedores y
sus datos, los usuarios que utilizarán el sistema, los centros de costo, los insumos, las líneas de insumos, cuentas
contables y almacenes.
Como se puede observar, son muchas las funciones que realiza esta Coordinación, por lo que es
importante que cada una de ellas, se hagan de la manera más óptima y rápida posible.
Actualmente, la manera en como se llevan cada uno de los procesos es de forma manual. Todas las
órdenes de compra, solicitudes y despacho de insumos, así como también el agregar los datos de un nuevo
proveedor, insumo, línea o cualquier otro dato importante, se hacen utilizando los programas EXCEL o WORD, y se
almacenan digitalmente en la computadora personal del Coordinador de Suministros.
Cada vez que se emite una orden de compra, se deben ingresar manualmente la descripción de los
insumos, la cantidad a comprar y el precio de compra, además del proveedor, la condición de pago y demás datos
importantes. Esto se hace para cada orden de compra que se emita, así que, si por ejemplo se necesitan emitir 3
órdenes, 3 veces hay que modificar la plantilla.
De la misma manera sucede con los demás documentos que se deben emitir. En el caso de las notas de
recibo, el Personal de Distribución debe ingresar manualmente los datos de la nota de recibo, y de los insumos que
se están recibiendo. Además, el sistema que utilizan para ello es muy antiguo, y no permite detectar fácilmente los
errores que puedan ocurrir, mientras se ingresan los datos. Cuando se imprime la nota, el formato es muy poco
práctico, porque no se puede determinar con facilidad que información pertenece a que insumo, y esto dificulta en
gran manera la lectura y análisis de todo lo expuesto allí.
Con el despacho de los insumos, se debe ingresar en EXCEL el centro de costo, y los insumos que se van
a despachar. Esto debe hacerse para cada centro de costo. Todos los documentos se almacenan digitalmente en la
computadora personal del Coordinador de Suministros.
Como se puede observar, la manera en como se llevan todos estos procesos y como se almacenan, trae
consecuencias notorias no solo al desempeño de la Coordinación de Suministros, sino a la compañía en general
porque:
10
El proceso de emisión de una orden de compra es más tedioso, y se invierte más tiempo del
requerido, logrando con esto que no se disponga del tiempo suficiente para hacer el resto de las
labores.
A medida que aumenta la demanda de insumos internos, aumenta el número de órdenes que
realizar, y es más difícil satisfacer en su totalidad dicha demanda, si se siguen emitiendo de esta
manera.
Es más difícil manejar el control de lo que se tiene en la almacenes, puesto que se debe contar con
una disciplina muy rigurosa, no muy tolerante a las fallas humanas, las cuales suceden con mucha
frecuencia.
Al requerir más tiempo del necesario para las diversas funciones, disminuye la productividad
Es por estos motivos que es necesario proponer una solución que permita realizar cada una de las
funciones de manera eficaz, para aprovechar mucho mejor el tiempo con el que se cuenta, y así no disminuir la
productividad de la Coordinación de Suministros.
Con el fin de superar las limitaciones antes descritas, la Coordinación de Suministros de CENTROBECO
C.A, conjuntamente con el Departamento de Logística (jefe inmediato de la Coordinación) desea que se desarrolle
un sistema con acceso interno para el manejo, registro y control de órdenes de compra, despacho de insumos e
inventario.
El Sistema debe, en líneas generales, permitir al Coordinador de Suministros, la emisión de los documentos
importantes (órdenes de compra, solicitudes de cotización, facturas internas, facturas), y que genere en función de
los datos ingresados, un imprimible del documento. Es importante que se tenga almacenada toda esta información,
de manera de poder consultarla cuando así se requiera.
11
Se quiere también realizar el proceso de despacho de suministros internos, y gestionar toda la información
relacionada con proveedores, almacenes, insumos, centros de costo, cuentas por pagar, cuentas contables, facturas
recibidas notas de recibo, devoluciones, proceso de inventario, resultados de un conteo físico y colaboradores.
Además, se debe permitir que los colaboradores autorizados puedan emitir sus pedidos directamente, que
el supervisor inmediato los estudie y, en caso de aprobarlo, solicitar el permiso de parte de la Coordinación de
Suministros. El sistema deberá también mostrar reportes estadísticos imprimibles sobre cada una de las
transacciones que se hagan. Para mayor información, puede consultar el anexo I: Pedido Orden de Compra
Suministros
Para lograr esto, se propone una base de datos única, y un sistema distribuido por módulos, de manera que
permita realizar las funciones anteriormente expuestas.
Lo que la Coordinación de Suministros persigue con este sistema, en líneas generales, es automatizar sus
actividades, para poder llevar un mejor control de la información, aumentar la productividad y disminuir el tiempo que
se invierte en cada una de ellas.
Disminuir el tiempo invertido en cada una de las actividades realizadas por el Coordinador de
Suministros, facilitando de esta manera sus labores.
Mantener la exactitud necesaria de los datos, así como también agilizar lo más posible los procesos
internos de la Coordinación.
Reducir el tiempo de emisión de las notas de recibo por parte del Personal de Distribución
Llevar un mejor control de los suministros internos, y saber con mayor exactitud qué se necesita en
cada uno de los centros de costo
12
El objetivo de la pasantía es Sistematizar las solicitudes de materiales y suministros internos, con el fin de
optimizar estos recursos. Más específicamente, es implementar el módulo de Órdenes de Compra, como prototipo
funcional.
A continuación se presenta el capítulo del Marco Teórico en el que se explica brevemente toda la tecnología
y demás aspectos considerados durante el desarrollo del sistema.
4. MARCO TEÓRICO
En este capítulo se da una breve explicación todo lo que se utilizó para el desarrollo del sistema. Se hace
referencia a la tecnología utilizada para el desarrollo del sistema. Se explica en líneas generales lo que es la
arquitectura de tres capas, la programación orientada a objetos, el lenguaje JAVA, y la tecnología utilizada para el
desarrollo de la interfaz con el usuario.
La arquitectura de las tres capas consiste en aislar la lógica de la aplicación y en convertirla en una capa
intermedia bien definida y lógica del software [LARMAN, 1999]. Existen tres capas principales, como se observa en
la Figura 3:
Capa de presentación: es la interfaz y por medio de ella, el usuario se comunica con el sistema, a
través de acciones emitidas por él (presionando un botón, ingresando los datos en un formulario,
etcétera)
Capa del negocio: son todas las tareas y reglas que rigen el proceso. Es la lógica del negocio
13
14
Capa de datos: es donde residen los datos. Está formada por una o más gestor de bases de datos
que realizan todo el almacenamiento de datos. Además, se reciben las solicitudes de
almacenamiento o recuperación de información desde la capa del negocio
Distribución de las capas en varios nodos físicos de cómputo y en varios procesos lo cual puede
mejorar el desempeño, coordinación y compartimiento de información.
Posibilidad de realizar actividades simultáneas en equipo al ser asignadas a los diseñadores las
diversas capas.
La arquitectura que se escoja para un sistema es importante, porque de ella depende el buen
funcionamiento del proyecto. Sin embargo, para garantizar la solidez de todo sistema, es necesario que pase por un
proceso de análisis que permita determinar todos los objetos que participan en el mismo, y como ellos interactúan
entre sí. Para ello se utiliza un lenguaje de modelado que permita realizar todos estos procesos
UML es un lenguaje de modelado apoyado por el OMG que ayuda a visualizar, especificar y modelar un
sistema de software, incluyendo su estructura y diseño en una manera que permite conocer todos los
requerimientos. UML ofrece un standard para describir un plano del sistema, incluyendo aspectos conceptuales tales
como procesos de negocio y funciones del sistema. Su versión actual es la 2.1.1, según la página oficial de UML
[UML, 2007].
15
La Programación Orientada a Objetos (POO), es un paradigma de computación que define a los programas
como clases de objetos, las cuales son entidades que combinan atributos o datos, métodos e identidad. Este estilo
de programación permite definir a los programas como conjuntos de objetos o clases, que trabajan entre sí para
ejecutar tareas. La ventaja de este paradigma es, entre otras cosas, poder hacer programas más fáciles de escribir,
mantener y reutilizar.
Abstracción: cada objeto en el sistema sirve como modelo de un “agente” abstracto que puede realizar
trabajo, informar y cambiar su estado y comunicarse con otros objetos, sin revelar cómo se implementan esas
características.
Encapsulamiento: significa reunir a todos los elementos que pueden considerarse pertenecientes a una
misma entidad, permitiendo aumentar la cohesión de los componentes del sistema
Principio de ocultación: cada objeto está aislado del exterior, exponiendo cada uno una interfaz a otros
objetos, para que puedan comunicase entre sí. El aislamiento permite proteger las propiedades de un objeto de
cualquier modificación de todos los que no tienen derecho a ellas.
Polimorfismo: comportamientos distintos, asociados a objetos diferentes, pueden tener el mismo nombre
Herencia: las clases se relacionan entre sí, formando una jerarquía de clasificación. De esta manera,
podemos tener clases u objetos que pueden heredar y por ende, utilizar atributos propios de su clase padre, en el
caso de que así se requiera.
Uno de los lenguajes más conocidos orientado a objetos es JAVA, el cual ha sido durante muchos años, el
lenguaje standard utilizado en aplicaciones Web, por su eficacia y versatilidad.
16
JAVA es un lenguaje de programación orientado a objetos desarrollado por Sun Microsystems, para el año
de 1990.
El lenguaje tiene muchas similitudes con C y C++, pero tiene un modelo de objetos más simple y elimina
herramientas de bajo nivel como los apuntadores.
La tecnología JAVA es tan atractiva actualmente porque permite a los desarrolladores: [HORSTMAN &
CORNELL, 1999]
Tiene una sintaxis similar al lenguaje C++, lo cual lo hizo sencillo de aprender
MVC es un patrón de arquitectura de software muy utilizado en los proyectos de aplicación Web, que
separa los datos, la interfaz y la lógica en tres componentes distintos: el modelo, la vista y la controladora.
Modelo: es la representación específica de los datos con los cuales se opera. El modelo asegura la
integridad de los datos y permite derivar nuevos.
Vista: estos componentes se usan en el patrón MVC para generar una respuesta al usuario,
proveyendo todo lo que el usuario puede ver (Interfaz)
Controlador: recibe las solicitudes de la aplicación por parte de los usuarios, y maneja el fluido de
datos entre el modelo y las vistas
17
4.6 STRUTS
El framework Struts es una herramienta de soporte desarrollada por la Apache Software Foundation,
utilizando la plataforma J2EE. Inicialmente, Struts se contaba como parte del proyecto Jakarta, pero actualmente es
un proyecto independiente conocido como Apache Struts.
Este framework resulta compatible con todas las plataformas en que Java Enterprise esté disponible,
logrando con esto que sea altamente cotizado en la actualidad. Lo que permite este framework es disminuir el tiempo
de desarrollo, por lo que resulta ideal para proyectos de mediana a gran envergadura.
Struts se basa en el patrón MVC, en donde cada componente está integrado de:
Componentes del Modelo: corresponden a la lógica del negocio con el cual se comunica la
aplicación Web. Generalmente son clases de JAVA.
Las vistas: son la parte de la información encargada de presentar la información a los usuarios y
recopilar datos provistos en las planillas. Generalmente corresponden a páginas dinámicas
generadas por archivos JSP
Componentes del control: son los encargados de coordinar las actividades de la aplicación, que
van desde la recepción de datos del usuario, las verificaciones de forma, la selección de un
componente del modelo a ser llamado. Por su parte los componentes del modelo envían al control
sus eventuales resultados y/o errores de manera de poder continuar con otros pasos de la aplicación
18
Esta separación simplifica considerablemente la escritura tanto de vistas como de componentes del modelo:
las páginas JSP no tienen que incluir manejo de errores, mientras que los elementos de control simplemente deciden
la salida a tomar.
Struts presenta ciertos atributos que lo hacen atractivo a la hora de seleccionar un framework que permita
reducir el tiempo de desarrollo de un proyecto de software. Dentro de sus principales ventajas están:
Configuración centralizada: los enlaces y direcciones url a seguir función del resultado de alguna
solicitud, se encuentran en un único archivo llamado struts-config.xml y a la hora de hacer alguna
modificación, resulta muy práctico porque simplemente se hacen una sola vez en este archivo, sin
necesidad de hacerlo para todas las páginas, como ocurre en JSP puro
Librerías de tags para facilitar la mayoría de las operaciones que generalmente realizan las páginas
JSP.
En vista de toda las ventajas que ofrece Struts, y de cómo este permite reducir el tiempo de desarrollo de
una aplicación, resulta muy práctico para este proyecto, pues cada una de las diversas tareas que antes se
realizaban dentro del mismo JSP, ahora han sido distribuidas entre los componentes de planillas y las acciones,
logrando con esto que el código JSP sea muy sencillo y fácil de mantener. Además, al estar hecho en JAVA cumple
con el requisito primordial de la compañía, que es que cualquier proyecto que se implemente, debe estar hecho en
ese lenguaje.
Una vez explicadas las bases teóricas de este proyecto, en el próximo capítulo se trata el aspecto
Metodológico de la pasantía.
5. MARCO METODOLÓGICO
En este capítulo se tratan los conceptos generales de una de las metodologías más utilizadas en el
desarrollo de sistemas de información como lo es Rational Unified Process (RUP). Se mencionan aspectos como en
qué consiste, cuántas fases la componen, que se realiza en cada una de ellas y cuáles son aplicadas para el caso
que nos ocupa con esta pasantía larga.
Para la realización del proyecto de pasantía se decidió que RUP sería la metodología a seguir para el
desarrollo del Sistema SOCDISAS, debido a que ofrece numerosas ventajas, como son las siguientes:
Proceso de desarrollo iterativo: cada una de las fases que constituye RUP se pueden repetir para
afinar tanto los objetivos como los artefactos resultantes. Esto es de gran utilidad en un ambiente
organizacional donde el sistema está sujeto a la incertidumbre, y a la hora de que se descubra un
nuevo requerimiento o cualquier otro detalle, se puede regresa a la fase adecuada, y afinar todo lo
que se necesite
Racional Unified Process (RUP), es una metodología de desarrollo iterativo de software creado por la
Racional Software Corporation, durante de la década de los 80, 90.
RUP describe a gran detalle las actividades, roles, responsabilidades, productos de trabajo y herramientas
para definir quién hace qué y en qué momento, en un proyecto de desarrollo de software. Es de interés para todas
19
20
las áreas de las empresas que tengan que ver con esta actividad, aún si subcontratan parte del proceso. RUP
representa un ideal que sirve de referencia para todo equipo de desarrollo, independientemente de su tamaño o de la
tecnología que se utilice para la construcción del software.
El ciclo de vida de RUP está dividido en 4 fases principales: Inicio, Elaboración, Construcción y Transición,
que corresponden a los 4 hitos principales de RUP: proyecto, arquitectura, versión β y release.
En términos de habilidades y conocimientos, está dividido en disciplinas. Cada una de ellas corresponde a
distintos aspectos del desarrollo de software que generalmente requieren habilidades específicas, que se reflejan en
los roles y las actividades definidas para cada disciplina.
Cada fase cambia el foco del equipo de trabajo para alcanzar cada uno de los hitos, y es llevada a cabo de
forma iterativa. Esto quiere decir que la fase se fragmenta en pequeños proyectos que recorren todas las disciplinas
y producen un ejecutable, siendo este una versión del proyecto que se está desarrollando. Dicho producto es la
forma más efectiva de verificar el progreso del proyecto y de reducir los riesgos inherentes.
El eje horizontal representa el tiempo y muestra los aspectos del ciclo de vida del proceso.
(representa la parte dinámica del proceso).
El eje vertical representa flujos de trabajo del proceso, los cuales agrupan las actividades de acuerdo
a su naturaleza (representa la parte estática del proceso).
Se centra principalmente en el caso del negocio, el cual explica el contexto del proyecto, factores de éxito,
expectativas, y se establece un pronóstico financiero (estimación de costos y tiempos de desarrollo) del mismo. Es
en esta fase, donde se estudia si el proyecto es factible o no.
Se definen los usuarios y los stakeholders del proyecto, así como la interacción de cada uno de ellos con el
proyecto a desarrollar. Si el proyecto no pasa de esta fase, o se cancela, o se puede re-iterar, estableciendo un
diseño nuevo para el Sistema.
Un documento con la visión del proyecto: un documento que explique, en líneas generales, de qué se
trata el proyecto, cuál es la razón por la cual se está desarrollando, qué se quiere con él y la
definición de los actores y stakeholders
El modelo de casos de uso con una lista de todos los casos de uso y los actores que puedan ser
identificados.
Un glosario inicial del proyecto, con la definición de los términos más importantes.
Un caso de negocio inicial el cual incluye: contexto del negocio, criterios de éxito, planificación
financiera.
Un estudio inicial de los riesgos que se deben tomar, así como la magnitud de cada uno
En esta fase es donde el proyecto comienza a tomar forma, pues en ella comienza el proceso de análisis
del problema, además de que se establece una arquitectura de software sólida para el proyecto que contempla: los
casos de uso críticos y los riesgos identificados, establecidos en la fase anterior, y revisados en esta fase. A partir de
aquí la arquitectura, los requerimientos y los planes de desarrollo son estables.
Un modelo de casos de uso (completo en al menos un 80%), con todos los actores identificados y la
mayor parte de las descripciones de casos de uso.
Plan del proyecto, incluyendo iteraciones y criterios de evaluación para cada iteración.
Durante esta fase, el enfoque principal va al desarrollo de componentes del sistema que se diseñó. Esta es
la etapa donde el “código duro” toma lugar. Muchas veces ocurren múltiples iteraciones en esta fase, en un esfuerzo
por dividir los casos de uso en problemas más pequeños y manejables, para así producir prototipos demostrables,
que vayan determinando el progreso. Durante esta fase todo se prueba en profundidad, y el énfasis está en la
producción eficiente y no ya en la creación intelectual.
Al final de esta fase, se obtiene un producto beta, que debe decidirse si puede ponerse en ejecución sin
mayores riesgos
Finalmente se realiza la transición del producto a los usuarios, lo cual incluye: manufactura, envío,
entrenamiento, soporte y mantenimiento del producto, hasta que el cliente esté satisfecho. Esta fase incluye:
Pruebas beta para validar el producto con las expectativas del cliente
Conversión de datos
Entrenamiento de usuarios
Distribuir el producto
Al final de las cuatro fases se tiene un producto de software, que evolucionará dentro de su próxima
generación, al iniciar un nuevo proceso por la misma repetición de las fases. Cada uno de estos períodos se les
denomina ciclos de evolución.
Durante el período de pasantía larga, se desarrollaron las fases de inicio, elaboración y construcción. Para
la fase de inicio y de elaboración se tienen dos iteraciones, y para la fase de construcción se tienen dos iteraciones
para cada uno de los módulos implementados (Órdenes de Compra, Cuentas Contables, Facturas, Notas de
Recibo), dando un total de 8 iteraciones.
En el siguiente capítulo se describe cómo se aplicó RUP durante el período de pasantía larga, y qué
artefactos se obtuvieron en cada una de las fases desarrolladas.
6. DESARROLLO
En este capítulo se explica detalladamente el desarrollo de la pasantía, explicando en cada sección las
fases de RUP que se ejecutaron: Inicio, Elaboración y Construcción. La última sección corresponde a las pruebas
realizadas del prototipo final.
En esta fase se dio inicio al levantamiento de la información del sistema, por medio de entrevistas al cliente,
y análisis del documento entregado previamente a la Gerencia de Sistemas. Lo primero en establecerse fue un plan
de proyecto, donde se abarcaron las principales tareas y el tiempo estimado de cada una de ellas. Al final se
obtuvieron los primeros artefactos del sistema, los cuales serán explicados de manera general. Esta fase se
desarrolló en conjunto con otro pasante
Para que un proyecto se desarrolle de la manera más ordenada y garantizar el cumplimiento de los
objetivos planteados, es necesario establecer a priori un plan de proyecto, que determine cada una de las tareas a
realizar, así como el tiempo estipulado para cada una de ellas. Hay que resaltar que esta fase se desarrolló en
conjunto con otro pasante, y fue supervisada por el responsable técnico del proyecto.
El plan de proyecto se estableció inicialmente antes de iniciar el período de pasantía larga, pero fue
revisado y modificado a medida del desarrollo de la misma. En la Tabla 1 se muestra lo estipulado para la fase de
Inicio.
24
25
Universo de Discurso 5 1
La visión general de un sistema, permite establecer una idea global de qué representa el sistema que se va
a desarrollar, y que es lo que la empresa espera obtener al terminar el proyecto.
En líneas generales, lo que se quiere desarrollar es una aplicación Web que permita realizar el proceso de
órdenes de compra, recepción, despacho e inventario de suministros internos, que permita optimizar el tiempo
invertido en cada uno de esos procesos y, de esta manera, mejorar la productividad de la compañía, y permitir que la
Coordinación de Suministros, lleve un control más exacto de todos los insumos con los que se cuenta, para así
poder distribuirlos de mejor manera entre las tiendas y departamentos, garantizando el buen funcionamiento de cada
uno de ellos.
Una vez teniendo claro lo que se quiere con este proyecto, se realizó una lista inicial de requerimientos, en
base a las primeras necesidades detectadas.
Los requerimientos son una descripción de las necesidades de un producto. La meta primaria es identificar
y documentar lo que en realidad se necesita, en una forma que claramente se lo comunique al cliente y a los
miembros del equipo de desarrollo [Larman, 1999].
razón que para lograr definir una lista inicial de requerimientos, se tuvo que realizar entrevistas a los usuarios
involucrados, de manera de poder entender mejor el negocio.
Esta primera parte fue realizada en conjunto con otro pasante, y juntos estudiamos un documento inicial
elaborado por el Coordinador de Suministros, donde indica que es lo que el sistema debe manejar. Además se
realizaron varias entrevistas, con el fin de aclarar cualquier duda que haya podido surgir.
Como resultado de este proceso, los requerimientos que se obtuvieron se agruparon en 17 módulos
funcionales: Órdenes de Compra, Notas de Recibo, Facturas, Facturas Internas, Pedidos Internos, Centros de Costo,
Inventario, Insumos, Devoluciones, Cuentas Contables, Condiciones de Pago, Proveedores, Cuentas por pagar,
Solicitudes de Cotización, Despacho, Usuarios, Sesiones de Usuario
En vista de lo extensa que es la lista de requerimientos, en la Tabla 2 se muestra sólo los requerimientos de
los módulos asignados para el período de pasantía larga los cuales fueron: Órdenes de Compra, Notas de Recibo,
Facturas, Cuentas Contables y Cuentas por pagar. Para mayor información sobre los requerimientos y sus
especificaciones, consulte el apéndice II: Especificación de Requerimientos del Software (ERS).
Cuentas por Pagar RF-11 Consultar todas las cuentas por pagar
Descripción: El sistema debe permitir registrar y actualizar los datos de una orden de compra. Debe también permitir registrar una
orden a partir de una solicitud de cotización
Cuando se analizan los requerimientos, se descubren los casos de uso que se tienen que implementar para
satisfacer cada uno de ellos. Los casos de uso son descripciones narrativas textuales de los procesos de un sistema
[Larman, 1999].
Primero se especificaron los actores principales del Sistema, y luego se procedió a determinar los casos de
uso que satisfagan los requerimientos contemplados.
Como resultado, se obtuvieron los casos de uso (entre 180-185), agrupados en los módulos anteriormente
expuestos. En vista de la cantidad de casos de uso que contempla el sistema, un diagrama de casos de uso no
permite visualizar la interacción entre ellos y los actores principales. Es por esta razón que se optó por realizar varios
diagramas de casos de uso, especificando por paquetes o módulos, la interacción entre ellos y los actores, como se
detallan en las Figuras 5, 6 y 7.
Figura 6. Diagramas de paquetes para los actores: Personal de Suministros y Personal de Finanzas
Fuente: Elaboración propia
Figura 7. Diagrama de Paquetes para Inventario, Facturas Internas, Pedidos Internos y Usuarios
Fuente: Elaboración propia
En la Tabla 4 se especifica solo una porción de la lista de casos de uso, debido a que la lista completa es
muy extensa (aproximadamente 180 casos de uso). La lista completa y sus respectivas especificaciones, pueden
consultarse con más detalle en el apéndice II: Especificación de Requerimientos del Software.
29
Tabla 4:Lista de Casos de Uso para los módulos Cuentas Contables y Órdenes de Compra
Fuente: Elaboración propia
30
En la Tabla 5 se muestra una narrativa del CU Generar una orden de compra. Todas las narrativas se
encuentran en el apéndice II: Especificación de Requerimientos del Software.
Descripción: Permite al Coordinador de Suministros generar una orden de compra a partir de una lista de insumos
Requerimiento: RF-30.
Precondiciones:
FLUJOS BASICOS
ACTOR (Coordinador de Suministros) SISTEMA
5. Confirma la información
6. Crea y guarda la nueva orden de compra y muestra un mensaje
de confirmación
FLUJOS ALTERNOS
ACTOR SISTEMA
En todos los sistemas de información, siempre surgen una serie de riesgos que, de no tomarse en cuenta,
puede traer consecuencias negativas para el proyecto, e incluso puede no completarse. Para esta fase se
establecieron los riesgos iniciales a tomar en cuenta durante el desarrollo del sistema.
31
A continuación se muestra la lista de los riesgos iniciales que se consideró durante el desarrollo del
proyecto. Cada uno de estos presenta una importancia que varía del 1 (poco riesgo) al 5 (alto riesgo). Aislamiento
del cliente respecto al Sistema
En la Tabla 6 se muestran los detalles del riesgo “Aislamiento del cliente respecto al Sistema”. La
descripción detallada de todos los riesgos iniciales se encuentra en el apéndice III: Documento de Riesgos
Retraso en el desarrollo del proyecto, surgen nuevas tareas para ajustar el software a lo que
realmente quiere el cliente.
ESTRATEGIA DE MITIGACIÓN Incentivar la realización de reuniones frecuentes entre los intermediarios y el cliente.
Mantener interesado al cliente con entregas parciales, comunicándole regularmente el estado del
proyecto.
PLAN DE CONTINGENCIA Programar una serie de reuniones con el cliente para verificar y establecer los requerimientos que el
solicita, y las funcionalidades que abarcarán cada uno de ellos.
Una vez establecidos los casos de uso iniciales, y haber considerado los riesgos que pueden cambiar el
curso del proyecto, se estudiaron las herramientas de desarrollo que se van a utilizar para la implementación del
prototipo funcional. Las herramientas son importantes, ya que hay que estar al tanto de lo que se utiliza en la
compañía, y de esta manera evitar inconvenientes que puedan cambiar el curso del proyecto, o incluso cancelarlo.
Las herramientas que se utilizan para desarrollar un proyecto son muy importantes, debido a que si se
seleccionan las más adecuadas para el sistema, se puede lograr optimizar cada una de las transacciones que este
haga. CENTROBECO C.A. dispone de herramientas de desarrollo que deben ser utilizadas a la hora de implementar
cualquier sistema. Tales herramientas son las siguientes:
IBM Websphere Studio: Una herramienta propietaria de IBM basada en la tecnología del proyecto
de código abierto Eclipse. Con esta herramienta fue realizada la mayor parte de la codificación del
proyecto.
IBM ISeries Access: Otra herramienta propietaria de IBM utilizada para desarrollar y administrar
sistemas que interactúan o se ejecutan en los servidores AS/400 que comercializa la compañía.
Putty: Herramienta para abrir una línea de comando de un sistema Linux a través de una conexión
con protocolo SSH, que permite operar y administrar el equipo remoto al cual se hace la conexión.
TortoiseSVN: Cliente del manejador de versiones Subversion que fue instalado en los equipos de los
desarrolladores para facilitar el trabajo con los repositorios creados para los módulos y sistemas en
desarrollo.
Además, por propuesta del pasante para facilitar el proceso de análisis y diseño del sistema, se utilizaron
las siguientes herramientas:
StarUML: Herramienta de código abierto propuesta para facilitar el diseño de distintos diagramas
basados en las especificaciones UML. Esta herramienta es excelente en la elaboración de los
33
DIA: Herramienta de código abierto que permitió al pasante diseñar el modelo entidad – interrelación
del sistema completo, así como los diagramas de casos de uso por módulos. Es muy práctica para
diseñar un modelo ER y los diagramas de casos de uso
Se contaba con una infraestructura tecnológica seleccionada previamente antes del proyecto de pasantía
larga, tanto el hardware como del software, por lo que el desarrollo del sistema se abocó a la misma. A continuación
se indican los detalles de la infraestructura:
Hardware:
Servidor AS400: Funciona como servidor central de la compañía y es el banco de datos que agrupa
todas las operaciones de las tiendas de la compañía.
Máquinas clientes: Hardware donde los usuarios se conectarán al sistema por medio de la Intranet
con la que dispone actualmente la compañía
Software
Sistema operativo Microsoft XP: sistema operativo instalado en las máquinas clientes
Navegador Internet Explorer 6.0 o 7.0: navegador Web utilizado en las máquinas clientes
34
Al finalizar los artefactos de esta fase, y luego de haber sido verificados por el responsable técnico del
proyecto, se inició la segunda fase del desarrollo del sistema SOCDISAS: Elaboración. Es importante indicar que los
artefactos obtenidos fueron revisados y modificados en las siguientes fases, por los cambios y mejoras a los mismos
y al sistema en desarrollo.
Antes de culminar la fase de Inicio, fue necesario establecer un plan de desarrollo de la fase de
Elaboración, para tener un estimado del tiempo a invertir en cada tarea y monitorear el plan general del proyecto.
Dicho plan de proyecto se muestra en la Tabla 7
Modelo Relacional 7 1
Scripts y Triggers 7 1
Diagramas de Clases 8 2
Con la definición de este plan culminó la fase de Inicio, especificando todo lo que se haría en la próxima
fase.
35
Esta fase, al igual que la anterior, se desarrolló en conjunto con otro pasante, supervisado por el
responsable técnico del proyecto.
La arquitectura de software, tiene que ver con el diseño y la implementación de estructuras de software de
alto nivel. Es el resultado de ensamblar un cierto número de elementos arquitectónicos de forma adecuada para
satisfacer la mayor funcionalidad y requerimientos de desempeño de un sistema, así como requerimientos no
funcionales, como la confiabilidad, escalabilidad, portabilidad, y disponibilidad.[Krutchen, 1995].
Para el desarrollo del Sistema SOCDISAS y su documentación a través del DAS, se decidió utilizar el
enfoque de las 4+1 vistas, debido a que es el enfoque standard que utilizaron en algunos sistemas ya desarrollados
en la empresa, y ha resultado bastante exitoso. A continuación, en la Figura 8, se muestra el diagrama del modelo de
las 4+1 vistas. Para cualquier información detallada sobre la arquitectura del software, consulte el apéndice IV:
Documento de Arquitectura del Software
A continuación se muestran los elementos que conforman cada una de las vistas de SOCDISAS.
36
Los escenarios se refieren también a la Vista de Casos de Uso, que es la vista que sirve para definir los
comportamientos esperados del sistema, como producto del funcionamiento conjunto de las otras cuatro vistas.
En esta vista van todos los casos de uso generados en la fase de Inicio y documentados en el ERS. Como
durante la fase de Elaboración no se descubrieron nuevos requerimientos funcionales, no se generó ningún caso de
uso nuevo. Por esta razón, el modelo de casos de uso se mantuvo durante esta fase, y los diagramas de paquetes
expuestos en la fase anterior, se mantienen.
En la Vista Lógica, se definen todos los objetos que formar parte del sistema, así como también la manera
en como ellos interactúan entre sí. Esta vista permite determinar de una manera más detallada los elementos
relevantes del sistema. De aquí se obtiene el modelo conceptual o de análisis, el diagrama de clases, el diagrama
entidad- interrelación y su respectivo diccionario de datos.
El modelo conceptual es una representación gráfica de los conceptos del negocio, y de esta manera
entender mejor el dominio del problema. Para diseñar el modelo conceptual o de análisis, primero se determinaron
los principales conceptos del sistema SOCDISAS, así como estos se relacionan. El diagrama resultante se muestra
en la Figura 9.
37
Tener un buen modelo conceptual, permite aclarar los conceptos más importantes y como estos se
relacionan. Un buen modelo conceptual permite diseñar un modelo entidad- interrelación robusto, que contempla
todas las áreas del negocio.
En el modelo entidad- interrelación se especifica la estructura de datos del sistema, y como éstas se
relacionan entre sí. Un buen diseño de la base de datos es importante para garantizar la integridad de todos los
datos que el sistema maneje, evitando de esta manera el riesgo de obtener información errada, y garantizando la
menor redundancia posible.
Luego de tener claro todos los conceptos relacionados con el sistema a desarrollar, y como ellos se relación
a través del modelo conceptual o de análisis, la primera asignación que se tuvo para esta fase, fue la de diseñar el
modelo entidad- interrelación, el cual se muestra en la Figura 10. A partir de este modelo entidad- interrelación, se
38
obtuvo el modelo relacional y los respectivos diccionarios, los cuales pueden ser consultados en el apéndice IV:
Documento de Arquitectura de Software.
Una vez diseñado el modelo entidad interrelación, se procede a establecer las clases necesarias para este
sistema, y como se relacionan entre sí. Dicha relación se refleja en los diagramas de clases.
Diagrama de Clases
Para este sistema, se realizó un diagrama de clases por cada módulo, debido a que un solo diagrama, no
permitiría ver con claridad la relación entre ellas. Es por esta razón que se decidió hacerlo para cada uno de los
módulos asignados durante la pasantía. En la Figura 11 se muestra el diagrama de clases para el Módulo de
Órdenes de Compra.
39
Esta vista es la encargada de determinar los problemas de concurrencia, la integridad y la tolerancia a fallas
que debe presentar el sistema.
Para fines de esta pasantía, esta vista no se contempló debido que en los casos de uso desarrollados, no
se observó ningún caso de concurrencia. Además, al ser una aplicación Web, que va a estar instalada en el servidor
AS/400, cuando se presente una falla en el servidor, no se podrá acceder al sistema.
Cuando la falla sea a nivel del manejador de base de datos, el sistema mostrará un mensaje de error, que
indicará a los usuarios que hay problemas con la conexión a la base de datos.
40
Una vez determinado si el sistema contempla o no concurrencia, se procedió a organizar el software dentro
del hardware con el que se cuenta para SOCDISAS
Esta vista muestra la verdadera organización del software dentro del ambiente de desarrollo. El software
está compuesto por pequeñas partes (subsistemas) que pueden ser desarrolladas por una o más personas. Esos
subsistemas están organizados en una jerarquía de capas, donde cada capa provee una interfaz limitada y bien
definida hacía las otras capas. [Krutchen, 1995].
La organización del sistema SOCDISAS está formada por tres capas: la capa de presentación, la capa de
negocio o controladora y la capa de datos o fachada.
La capa de presentación es la que maneja todos los eventos que genera el usuario. Es la que permite la
interacción entre el usuario y el sistema. Está hecha con el framework Struts, que obedece el patrón MVC.
La capa de negocio determina la lógica del sistema, realizando las operaciones estadísticas y de
información, con los datos obtenidos en la capa anterior. Para la implementación de esta capa, se usará el lenguaje
de programación JAVA.
La capa de datos que maneja todos los procesos que interactúan con la base de datos del Sistema. En esta
capa se accede, se agregan y/o modifican todos los datos que en ella se almacenan. Para la implementación de esta
capa, se usará el lenguaje de programación JAVA.
Una vez determinada la manera en como se organiza el software, corresponde ubicar el mismo dentro del
hardware que se va a utilizar. Esto se explica con más detalle en la vista de Implementación o Física
. Con esta vista e puede determinar que es lo que se instalará en qué componente.
En el caso del proyecto a desarrollar, todo el software que lo compone (cada una de las capas expuestas en
la vista de implementación), estarán instaladas en el servidor AS/400.
La razón por la cual las tres capas están en un mismo servidor es porque en la empresa se dispone de solo
uno para instalar y utilizar los diversos sistemas que se implementan. Dicho servidor es el llamado Servidor de
Producción. En la Figura 13 se muestra la vista de Implantación para este sistema.
42
Al final de la Fase de Elaboración, de la misma manera que en la fase anterior, se estableció el plan de
proyecto de la siguiente y última fase: Construcción. Esto con el fin de tener un plan a priori sobre todas las
actividades que se van a realizar, y el tiempo estimado de cada una de ellas
Tal y como lo sugiere la metodología RUP, al final de la fase de elaboración se elaboró un plan de proyecto
para la siguiente y última fase del proyecto de pasantía: Construcción. El plan de proyecto para la siguiente fase se
muestra en la Tabla 8.
En esta etapa se comienza a implementar todo lo que se ha analizado y diseñado en las fases anteriores.
En vista del poco tiempo con el que se contó para esta fase, además de los cambios que surgieron durante la misma
gracias a las reuniones con el cliente, solo se implementaron los casos de uso riesgosos de los siguientes módulos:
Órdenes de Compra, Notas de Recibo, Facturas, y Cuentas Contables.
Durante esta fase, se descubrieron algunos aspectos, que alteraban el modelo entidad-interrelación
expuesto en la fase de elaboración
Básicamente, en el modelo entidad interrelación se agregó la tabla Presupuesto, en donde se ingresa todo
el presupuesto fiscal asignado a una cuenta contable. Cada tupla de esta tabla representa el presupuesto de una
cuenta, para un mes determinado. Anteriormente el presupuesto estaba como un atributo de la tabla cuenta
contable. Al tenerlo así, no había manera de determinar la distribución de dicho presupuesto entre los centros de
44
costo, ni tampoco se podía conocer el presupuesto disponible para un mes en particular. Es por esta razón que se
creó una nueva tabla, relacionada con cuenta contable, y con centro de costo.
Además, el otro pasante agregó la tabla inventario, necesaria para desarrollar uno de los módulos que le
correspondía, y se agregó la tabla Impuesto, donde se maneja el IVA que se va a utilizar cuando se emita una orden
de compra, o una nota de recibo. De allí se obtiene el IVA más reciente.
Otro aspecto importante que se debe explicar, es la tabla Impuesto que no tiene ninguna relación con el
resto de las entidades. Esta tabla maneja el porcentaje del impuesto al valor agregado (iva) y sus fechas de inicio y
cierre. La razón por la cual se hizo esto, es porque el iva puede cambiar de un momento a otro, y es necesario no
solo llevar un registro del iva anterior (para cuando se quiera modificar una orden de compra ya emitida por ejemplo),
sino además para no tener que actualizar este dato en cada uno de los suministros a los que se aplica. Simplemente
cada vez que se emita una orden o cualquier otro documento, se busca en esa tabla el iva más reciente, y ese será
el que se utilice.
Previo al inicio de la implementación, fue necesario familiarizarse con el uso de la herramienta Websphere
Studio. Además, se instaló la base de datos en el ISeries, utilizando el modelo relacional obtenido para el sistema.
La implementación de los casos de uso riesgosos fue realizada por el pasante, supervisado semanalmente
por el responsable técnico del proyecto.
La planificación sufrió unos ajustes, debido a que surgieron algunos cambios durante el proceso de
desarrollo. En una de las reuniones sostenidas con el cliente, surgieron numerosos cambios en los casos de uso que
se estaban desarrollando. Es por esta razón que el pasante, junto con el responsable técnico, decidieron darle mayor
importancia a la calidad del sistema que se entregaría que a la cantidad de Casos de Uso a implementar, por lo que
se iteró sobre los casos de uso ya desarrollados.
Antes de implementar cada uno de los casos de uso, se diseñaron los diagramas de secuencia a priori, de
manera de poder tener una relación entre todas las clases participantes
45
En la Figura 15 se muestra el diagrama de secuencia para el caso de uso Emitir Orden de Compra. En el
se muestra la interacción entre las clases de interfaz, con la clase de la controladora, y con la clase de la fachada
correspondiente al módulo. El proceso de desarrollo fue de orden ascendente, es decir, se comenzó por la Clase
Fachada, implementando los procedimientos necesarios. Posteriormente se implementó la Clase Controladora, y
luego la interfaz de usuario.
Figura 15. Diagrama de Secuencia para el caso de uso Emitir Orden de Compra
Fuente: Elaboración propia
En lo que se refiere al diseño de interfaz gráfica con el usuario, se contó con cierta libertad a la hora de
seleccionar la herramienta a utilizar. La única restricción era que la interfaz debía de soportar JAVA, puesto que el
46
sistema se desarrollaría en ese lenguaje. En vista de esto, los pasantes que estaban al cargo del sistema, decidieron
por utilizar el framework struts en lugar de código JSP puro, ya que al ser un proyecto de gran envergadura, Struts
permite facilitar la inserción de código, contribuyendo con un mejor mantenimiento para el sistema.
En la Figura 16, se presenta una interfaz Web dividida en varias secciones, el encabezado, el menú
principal, y la pantalla donde se mostrará a información que soliciten.
El encabezado se encuentra en la parte superior de la página, e indica el nombre del proyecto a mano
izquierda, y el logo de CENTROBECO a mano derecha. El menú principal contiene todas las opciones que se
pueden realizar, las cuales dependen del tipo de usuario que haga sesión..
Cuando un usuario hace sesión en el sistema, se mostrará esa pantalla. Para este prototipo solo se
muestran las siglas del sistema en el centro de la pantalla en color gris, con el significado de la misma en un
recuadro azul oscuro. Se espera que esta pantalla muestre las noticias o eventos importantes sucedidos,
dependiendo del usuario conectado (Ejemplo: si es el Coordinador de Suministros, mostrar todos los insumos que
están por escasear. Si es un colaborador, mostrar algún cambio que haya ocurrido con alguno de sus pedidos
internos).
47
Cuando el usuario selecciona del menú alguna de las opciones allí especificadas, la pantalla cambia en
función del evento que se está generando. Por ejemplo, si el usuario desea emitir una orden de compra, se mostrará
una pantalla inicial, donde se solicita los datos generales de la orden. En la Figura 17 se muestra la pantalla inicial al
emitir una orden de compra
Figura 17. Pantalla inicial para el caso de uso Generar Orden de Compra
Fuente: Elaboración propia
Posteriormente se seleccionan los insumos, y luego se muestra una pantalla de confirmación con el
resumen de la orden, de manera que el usuario verifique que toda la información es correcta. En la Figura 18 y 19 se
muestran las pantallas para seleccionar los insumos, y para confirmar la orden.
48
Como no existe un entregable del sistema aún, no se tiene una fase de pruebas que vaya acorde a los
requerimientos de RUP. Solo se hicieron pruebas técnicas sencillas, para verificar la funcionalidad de cada caso de
uso implementado.
. Para desarrollar la fase de transición, es necesario contar con un sistema 100% funcional, y además
seguir las normas que rigen a la compañía en el área de pruebas.
Para poder instalar un módulo en el servidor de producción, es necesario que se hayan desarrollado y
probado todos los casos de uso que integran el módulo.
En vista de que no se desarrollaron todos los casos de uso de un mismo módulo sino solamente los más
riesgosos, además de no disponer con el tiempo suficiente para realizar este tipo de pruebas, no se cuenta con una
fase de transición definida como tal.
Para el período de pasantía, el responsable técnico del proyecto realizó pruebas técnicas sobre los casos
de uso implementados. Esto con el fin de verificar el correcto funcionamiento de los mismos.
Los casos de uso probados siguen la descripción establecida, tanto para el curso normal, como para
los cursos alternos.
En la Tabla 9 se muestra un estimado del estado del sistema para el final del período de pasantía. Tomando
los módulos desarrollados por el otro pasante, se tiene que el sistema tiene un 25 % aproximadamente
implementado.
50
Lógica de la Aplicación 90 El caso de uso modificar notas de recibo fue implementado sólo hasta la fachada y
controladora.
(Casos de uso seleccionados )
Lógica de la Aplicación 25 Hay que implementar las consultas y estadísticas para cada módulo obtenido.
Base de Datos 40 Falta desarrollar la fachada de los módulos: Pedidos Internos, Solicitudes de
Cotización, Centros de Costo, Usuarios, Despacho y Facturas Internas. Además,
hay que implementar el resto de los casos de uso para los módulos asignados en
la pasantía
Con esto se culminó el desarrollo del prototipo funcional del sistema SOCDISAS. Una vez culminadas estas
fases de desarrollo, solo resta exponer los logros obtenidos durante el período de pasantía larga, los cuales se
muestran en el próximo capítulo.
7. CONCLUSIONES Y RECOMENDACIONES
El trabajo realizado durante el período de pasantía larga, permitió al estudiante aprender y tener una noción
más amplia de cómo es la vida laboral, y permitió aplicar los conocimientos adquiridos durante su período de
estudios, en cada una de las situaciones que tuvo que enfrentar durante la misma.
Con la información proporcionada por la empresa, además de disponer de un cliente con una clara
definición de lo que deseaba, se pudo diseñar en conjunto con otro pasante, la arquitectura, requerimientos y casos
de uso que integran este proyecto.
Es importante resaltar que este proyecto, una vez terminado, será de gran utilidad no solo para la
Coordinación de Suministros, sino también para la compañía, puesto que optimizará los procesos que esta lleva, y
ello contribuirá con una mejora de la productividad en cada una de las áreas que se manejan, reflejando el impacto
en las tiendas y departamentos de la empresa.
En función de esto, se muestran los objetivos alcanzados durante el período de pasantía larga:
En vista de esto podemos concluir que se ha cumplido con los objetivos iniciales, obteniendo un prototipo
funcional del módulo órdenes de compra, al que se le dará continuidad.
51
8. REFERENCIAS BIBLIOGRÁFICAS
[HOLMES, 2007] Colmes J. “The Complete Referente Struts”. Segunda Edición. Mc Graw Hill Osborne, 2007.
[HORSTMANN, CORNELL, 1999] Horstmann C, Gary Cornell. “Core JAVA Volume I Fundamentals”. Segunda
Edición. Sun Mycrosystems, 1999.
[KRUCHTEN, 1995] KRUCHTEN, P. “Architectural Blueprints, The 4+1 View Model of Software Architecture”. IEEE
Software. 1995.
[KRUCHTEN, 2000] KRUCHTEN, P. “The Rational Unified Process: An introduction”. Cuarta Edición. Addison-
Wesley, 2000.
[LARMAN, 1999] LARMAN, Craig “UML y patrones” Segunda Edición, Naucalpán de Juárez: Prentice Hall
Hispanoamericana S.A., 1999
REFERENCIAS ELECTRÓNICAS
52
Sistema: CENTROBECO 98 – Modulo: O/C para Suministros, servicios y activos
Responsable Comercial: Alan Isea
Responsable técnico: Ileana Rojas
Fecha: 30/06/2006
Contenido
1. Conceptualización
a. Objetivo General
b. Objetivos Específicos
c. Conceptos Generales
2. Requerimientos
a. Procesos
b. Sistemas
3. Corresponsabilidades
1.- Conceptualización
2.- Requerimientos
Proveedores
• Razón social, Rif, Nit, dirección, telf., fax, móvil, persona contacto, Web, E-
mail.
• Seleccionar por tipo de mercancía: Materiales de oficina, computación,
mantenimiento, eléctricos, accesorios especiales para tiendas, empaque bolsas,
empaque regalo, empaque embalaje, mobiliario, limpieza, uniformes, servicios,
repuestos, alimentos, y otros.
• Permitir código asignado para cada proveedor.
• Condiciones de pago- contado contra entrega, Créditos 15 días, a 30 días, a 7
días, a convenir, pago por deposito bancario, cheque, descuentos por
porcentaje, adelanto de pagos, tipo de moneda, nacional e importado y
comentarios.
Información adicional:
Compras
• Solicitud de cotización.
El sistema debe detectar los artículos que se encuentren en cantidades mínimas, debe
informar por medio de “ALERTAS” al usuario de la situación y debe permitir la
opción de imprimir documentos “Artículos por Comprar” por cada uno o por línea de
producto.
Dicho documento debe tener la siguiente información: fecha, descripción del producto,
línea a la que pertenece, fecha cantidad y precio de la última compra y línea para
posibles observaciones (ejemplo: marca) y columna adicional para respuestas de
cotizaciones.
• Orden de Compra:
Permitir entregas parciales sobre una Orden de Compra, y mostrar los artículos
entregados (fecha, cantidad y Nº de factura relacionada) así como el saldo de la misma.
Devoluciones a Proveedores
• Mismo formato de Orden de Compra, pero que exprese “Devoluciones a
Proveedores” y descargue del Inventario si el articulo ya fue cargado o
elimine de Orden de Compra, según sea el caso.
Los Centros de Costo acceden a formato pedidos, que debe contener la siguiente
información: Centro de Costo solicitante, fecha de pedido, fecha de envío, clave de
acceso, número de documento el cual debe ser correlativo y alfa numérico (Ejemplo:
Tam-001-06), precios unitarios, fecha último despacho, observaciones solo al final del
documento, inventario en tienda, costo total del pedido.
• Centro de Costo detallado por unidad sección y coordinación ( Ejemp: Sistemas 82,
O y M 82-01, Soporte 82-3, Computación 82-4 ( Incluir códigos )
• Incluir a los Centro de Costo por zonas: tiendas Caracas, tiendas del interior.
• Expresar: dirección, teléfonos, gerente responsable.
• Incluir celdas para colocar “Persona contacto”.
• Expresar dirección de entrega “Centro de Costo” y “sub. Centros”
• Días de envió.
• Tipos de cliente: prioritarios (Tiendas) (P) Secundarios (Boleita) (S).
El módulo debe descargar del inventario cada articulo “Facturado” y a su vez cargar al
Inventario y los Centros de Costo y Secciones los artículos entregados.
Al elaborar documento enviar a alertas a los artículos que estén por debajo de los
estándares mínimos, si es posible sonoras, y deben ir a listado adicional para el Sub-
Módulo de Compras; también informar de los artículos que se están despachando con
“Alta Frecuencia” y “Volumen” al mismo Centro de Costo y Sección.
Al final del documento expresar la siguiente leyenda “El monto total de bolívares
entregados se verá reflejado parcial y/o totalmente en los próximos listados de gastos,
que entrega mensualmente el Departamento de Contabilidad”.
SUB-MÓDULO INVENTARIO
• Artículo
• Almacenes
• Inventario físico
• Ajustes al inventario
Crear pantalla con todos los artículos en existencia mínima, permitir selección por
línea y sub-línea (Ver Sub-Módulo de Compras)
Inventario Físico:
• Preparación
• Conteo físico
• Análisis y resultados
• Ajustes.
1. Preparación: Debe permitir inventarios de todos los artículos por líneas, sub.-
línea, procedencia, por rango de precios y por movimientos de productos.
En esta fase se requiere que el sistema liste todos los artículos a inventariar y el
formato debe contener la siguiente información: nombre del artículo, código,
presentación (caja, unidad) y un renglón para expresar el resultado del conteo
físico, fecha de la toma, tomado por, N° de Pág.
2. Conteo Físico: En esta fase se incluyen los resultados del conteo físico, el
sistema debe ir actualizando la información y permitir corregir datos ya guardados.
4. Ajustes: Permitir ajustes por faltantes o sobrantes, según sea el caso, tanto en
cantidades como precios, presentación, etc.
5. Observaciones:
• Este Sub-Módulo debe permitir criterios para Costeo del Inventario.
Costo Promedio
Ultimo Costo
• El manejo del inventario debe ser bajo la premisa de “Primero en entrar,
primero en salir”
• Debe permitir manejo de stock negativo
El Sistema deberá distribuir el gasto por porcentajes (%) de ventas y por artículo
despachado (ver Relación de Facturas Actual).
Pagos con adelantos: el sistema debe “reconocer” los pagos por concepto de adelanto
que se hayan emitido y debe “descargar” del monto final a cancelar
Pagos por Pronto Pago: calculo automático de los % o bolívares por este concepto.
SUB-MÓDULO ESTADISTICAS
En todos los casos permitir elaborar gráficos tipo Excel de los reportes.
En el Sub-Módulo de Inventario:
• Permitir listar artículos con ajustes por toma, periodo de tiempo, tipo, línea,
proveedor.
• Artículos permitir listar o ver en pantalla:
• Articulo por precio, por línea, por ubicación, sub.-línea fecha de registro,
proveedor, procedencia, stock máximo y mínimo, presentación, vencimiento, talla.
• Listado Artículos: por precios a partir de un costo.
En el Sub-Módulo de Despacho
• Facturas despachadas, por centro de costos, completos por despachar, por
fechas, rangos de fechas, rango numérico, despachador, artículos con todos sus
componentes, almacenes, sección, costos, costos totales, cantidades.
• Permitir listar devoluciones por centros de costo, Bs. y despachador.
• Listar documentos que estén pendientes por recibir y recibidos, en los Centros
de Costo solicitantes.
En el Sub-Módulo de Compras
• Consultar documento pendiente por procesar y el % que representan.
• Compra por recibir, por fecha, por proveedor, artículos con sus características,
por rango de fechas, procesadas, devoluciones.
• Estadísticas de compras totales de la compañía.
• Permitir alternar rangos.
• Precisión de entrega de proveedores.
NOTAS GENERALES
H
HIISST
TOOR
RIIA
ALL D
DEE R
REEV
VIIS
SIIÓ
ÓNN
T
TAAB
BLLA
A D
DEE C
COON
NTTE
ENNIID
DOOS
S
1. Introducción 5
1.1 Propósito 5
1.2 Alcance 5
1.3 Definiciones 5
1.4 Referencias 7
1.5 Vista General 8
2. Posicionamiento 8
6. Restricciones 23
7. Rangos de Calidad 23
8. Precedencia y Prioridades 24
V
VIISSIIÓ
ÓNN
1. Introducción
1.1 Propósito
1.2 Alcance
1.3 Definiciones
• Almacén: Depósito donde se guardan los suministros adquiridos por CENTROBECO C.A. en
su sede central en Boleíta.
• Centro de Costo: Se refiere a todos los departamentos y tiendas que conforman la empresa
CENTROBECO C.A. Los departamentos se encuentran ubicados en la sede central de la
empresa en Boleíta. Las tiendas están ubicadas en las principales ciudades del país.
• Cuenta Contable: Relación de dinero asignada por la gerencia general, a cada una de las
actividades que se hacen dentro de la empresa. Ejemplo: Cuenta de gastos de limpieza,
Cuenta de gastos de papelería, etc.
• Cuenta por pagar: Obligación que tiene la empresa CENTROBECO C.A. de pagar una
determinada cantidad de dinero con un proveedor.
• Factura: Documento emitido por un proveedor que muestra la relación de los suministros y
precios comprendidos en una venta.
• Inventario: Conjunto de insumos del que dispone CENTROBECO C.A, y que se despachará
a los diversos centros de costo, de acuerdo a la solicitud que hayan realizado
• Nota de Recibo: Es un documento que informa sobre los insumos que se han recibido de
un proveedor determinado, así como también la cantidad exacta de cada uno de ellos. Con
este documento, junto con la factura que llega, es que se tramita el pago al proveedor que
despachó la mercancía.
• Pago: Es el trámite que el Personal de Finanzas realiza, para cancelar una cuenta por pagar
que se tenga pendiente con un proveedor determinado.
© CENTROBECO, C.A. 2007 Departamento de Sistemas Página 6
Sistema de Orden de Compras, Despacho e Inventario Versión: 4.0
de Suministros, Activos y Servicios Fecha: 30/05/2007
SOCDISAS
Vision
• Pedidos Internos: Son todas aquellas solicitudes que los Centros de Costo realizan a la
Coordinación de Suministros en la sede principal CENTROBECO C.A, indicando los insumos
que necesitan, la cantidad respectiva, y el motivo por el cual lo piden.
• Insumo: Son los artículos que el Coordinador de Suministros compra, para cubrir las
necesidades de cada uno de los Centros de Costo.
• Proveedor: Es una persona o empresa que abastece de los insumos solicitados por el
Coordinador de Suministros, en la sede principal CENTROBECO C.A.
• Secciones: Son todas las áreas o sub-departamentos que integran un Centro de Costo
• Sub-línea: Son todas aquellas sub- categorías que componen una línea.
• Usuarios: Son todas las personas que trabajan en los diversos centros de costo existentes.
1.4 Referencias
Para tener un conocimiento más amplio sobre el sistema, se pueden consultar los
siguientes documentos:
• Documento de arquitectura.
• Documento de riesgos.
En ellos se detallarán otras vistas del sistema y se podrán conocer aspectos relevantes
como los principales escenarios de interacción, la arquitectura del sistema y los principales
riesgos identificados para el desarrollo del sistema.
2. Posicionamiento
Los beneficios para el cliente final, aquel cuyos proyectos serán manejados en un
portafolio, serán:
Colaborador Empleado de las tiendas Se encarga de emitir los pedidos internos, para ser
y/o departamentos de la enviados a su superior inmediato
sede principal
Analista de Trabaja en el Centro de Se encarga de emitir las notas de recibo cuando llegan
Suministros Distribución los insumos
Personal de Trabaja en el Les llega las notas de recibo, junto con su respectiva
Finanzas Departamento de Finanzas factura, y tramita los pagos a los proveedores
• Rol de Colaboradores
• Rol de Gerentes
La plataforma Web que se va a implementar para este sistema permite eliminar las
restricciones ambientales en lo que se refiere a la gestión de orden de compra, despacho e
inventario de suministros. No existen proyecciones que en el futuro este tipo de enfoque cambie.
Representación Aquella persona que es responsable técnica del proyecto, y por lo tanto, es la
encargada de supervisar y llevar el control del proceso de análisis, diseño e
implementación del sistema
Descripción Debe encargarse de supervisar y llevar el control del proceso de análisis, diseño e
implementación del sistema
Tipo Empleado del Departamento de Sistemas
Debe tener cierto conocimiento con la tecnología utilizada, y de mantener contacto
directo con el responsable comercial del proyecto
Responsabilidades Establecer contacto con el responsable comercial del proyecto, a fin de que se
apruebe cada una de las funcionalidades requeridas.
Supervisar el trabajo realizado por los programadores.
Criterios de Éxito Para el Analista de Sistemas, el éxito del producto se basará en que sea aprobado
por el responsable comercial
Relaciones El Analista de Sistema se relaciona íntimamente con el desarrollo del proyecto,
puesto que él deberá marcar las pautas y guías necesarias para que el sistema
pueda mostrar información útil que soporte el proceso de emisión de órdenes de
compra, notas de recibo, distribución de los insumos a los Centros de Costo y
cancelación de las cuentas por pagar.
Entregables ERS
Cometarios Ninguno
3.5.4 Programadores
Representación Aquella persona responsable del conteo manual de los insumos en los almacenes, y
del cotejamiento de ese conteo con el inventario que lleva el sistema.
Descripción Debe contar manualmente los insumos en los almacenes e ingresar los resultados
de este conteo en el sistema, para que el programa compare estos resultados con el
inventario que se lleva contabilizado, y muestre las diferencias en pantalla.
Tipo Asistente de la Coordinación de Suministros
Debe ser meticuloso y responsable al realizar los conteos manuales
Responsabilidades Contar los insumos asignados en el almacén correspondiente
Ingresar los resultados de este conteo en el sistema
Ver las diferencias entre el inventario que lleva el sistema y el conteo que hizo
manualmente
Criterios de Éxito Para el Analista de Suministros, el sistema será óptimo, si automatiza correctamente
el inventario, de acuerdo al ingreso y despacho de insumos, que lo mantenga
siempre actualizado, y que verifique sin errores este inventario con los resultados
del conteo manual.
Relaciones Ingresar los resultados de un conteo físico realizado por él, y estudiar las diferencias
que el sistema muestre.
Entregables Reporte del inventario resaltando las diferencias entre el conteo realizado, y lo
registrado en el sistema.
Cometarios Ninguno
3.6.2 Colaboradores
3.6.4 Gerentes
Representación Trabajador de la planta de distribución que recibe la mercancía y procesa una nota
de recibo a la Coordinación de Suministros
Descripción Al recibir la mercancía, emite una nota de recibo, especificando los insumos que se
están recibiendo y la cantidad para cada uno de ellos, según lo contado y lo
establecido en la factura recibida por el proveedor
Tipo Técnico
Trabaja en la planta de distribución, atendiendo los recibos de mercancía
Responsabilidades Recibir los insumos en la planta de distribución
Cuenta la cantidad por insumo que está recibiendo
Emite una nota de recibo, indicando la cantidad según la orden de compra
correspondiente, la cantidad según la factura recibida, y según el conteo realizado
Criterios de Éxito Será útil en la medida que agilice el proceso de emisión de la nota de recibo.
Relaciones Emite la nota de recibo para la mercancía recibida, e ingresa conjuntamente los
datos de la factura recibida por el proveedor
Entregables La nota de recibo ingresada
Cometarios Ninguno
Representación Empleado del Departamento de Finanzas de CENTROBECO C.A, a quien le llega una
nota de recibo junto con su factura, y tramita los pagos que se hacen a los
proveedores. En caso de los pagos por adelanto, reciben las ordenes de compra
asociadas
Descripción Al recibir una orden de compra, emite un pago por adelanto al proveedor asociado a
la orden.
De igual manera, cuando le llega una nota de recibo y su factura, emite el pago
asociado al proveedor.
Tipo Asistente
Responsabilidades Tramitar pagos de las notas de recibo y/o ordenes de compra a los proveedores
Criterios de Éxito Se genera más rápidamente las facturas y notas de recibo, así como las ordenes de
compra, permitiendo que pueda tramitar los pagos mucho más pronto
Además, se hace más propenso a errores, puesto que se debe revisar numerosos
detalles, y esto genera a la larga no solamente pérdida de tiempo, que puede ser invertido de
mejor manera, sino además de dinero.
Para lograr esto, se quiere automatizar todos los procesos que actualmente maneja la
Coordinación de Suministros. Más específicamente, se quiere automatizar los procesos de:
emisión de órdenes de compra, notas de recibo y facturas, pedidos internos, facturas internas,
proceso de distribución de insumos a los centros de costo, proceso de inventario y conteo físico,
proceso de pagos y adelantos.
momento
determinado
NEC-04 Reducir el tiempo Alta Gestión de pedidos Se hace Permitir al Coordinador de
de emisión de las de insumos a los manualmente, y se Suministros que seleccione los
órdenes de compra proveedores registra en hojas de insumos a comprar, y que el
“Excel” sistema calcule el monto
automáticamente, en función
de los datos ingresados.
NEC-05 Reducir el margen Alta Gestión de pedidos Se hace manualmente Permitir al Coordinador de
de error que ocurre de insumos a los Suministros que seleccione los
durante la emisión proveedores insumos a comprar, y que el
de una orden de sistema calcule el monto
compra automáticamente, en función
de los datos ingresados.
NEC-06 Facilitar la toma de Media Gestión de pedidos Revisa manualmente Permitir al Coordinador de
decisiones al emitir de insumos a los las órdenes de Suministros visualizar de
una compra de proveedores compra emitidas manera rápida y con criterios
insumos anteriormente, al de búsqueda, las órdenes de
igual que las compra emitidas
solicitudes de anteriormente, al igual que las
cotización solicitudes de cotización
NEC-07 Reducir el tiempo Media Los pedidos de Se lleva a cabo Permitir al Coordinador de
de emisión de las precios y ofertas manualmente Suministros seleccionar del
solicitudes de que hace sistema los insumos que desee
cotización CENTROBECO C.A. saber sus precios, para
a las empresas que generar una Solicitud de
venden suministros. Cotización de manera
automática.
NEC-08 Reducir el margen Alta Los pedidos de Se hace manualmente Permitir al Coordinador de
de error que ocurre precios y ofertas Suministros seleccionar del
durante la emisión que hace sistema los insumos que desee
de una solicitud de CENTROBECO C.A. saber sus precios, para
cotización a las empresas que generar una Solicitud de
venden suministros Cotización de manera
automática.
NEC-09 Reducir el margen Alta Dinero que Se hace manualmente Contabilizar las cuenta por
de error que ocurre CENTROBECO C.A. en base a la pagar y los pagos
durante la emisión debe cancelar a los información archivada automáticamente, según la
de pagos y proveedores por la en hojas de “Excel” información que se lleva de las
adelantos mercancía recibida, Órdenes de Compra que se
o que va a recibir hacen a los proveedores.
NEC-10 Facilitar el proceso Alta Dinero que Se hace manualmente Guardar historial de los pagos
de fiscalización de CENTROBECO C.A. en libros pendientes y cancelados
las autoridades debe cancelar a los
tributarias, y proveedores por la
control general de mercancía recibida,
los pagos o que va a recibir
cancelados y
pendientes
NEC-11 Reducir el tiempo Alta Devoluciones de Se hace manualmente Automatizar el proceso de
de emisión de una insumos en base a la devolución de insumos a los
información archivada proveedores. Detectar
establecidos.
NEC-17 Reducir el tiempo Media Centros de Costos y Se lleva a cabo Permitir agregar, modificar,
de que lleva la secciones que manualmente eliminar centros de costos al
gestión de los conforman la sistema.
centros de costo empresa.
NEC-18 Facilitar el proceso Alta Coordinación de Se lleva a cabo Mostrar en el sistema un
de distribución de suministros y manualmente, historial con opciones de
insumos hacia los Centros de Costo revisando información búsqueda de pedidos y envíos
Centros de Costo de los pedidos y internos hacia los centros
envíos internos hacia
estos centros
NEC-19 Reducir el tiempo Alta Manejo de la El Coordinador de Almacenar en el sistema los
de emisión de una cuentas Suministros recibe los datos de la nueva cuenta, y
cuenta contable actualmente activas datos de una nueva calcular en función de los
en la empresa cuenta, así como el datos ingresados por el
presupuesto asignado Coordinador de Suministros, el
Distribución del
durante el próximo presupuesto del año fiscal
presupuesto general
año fiscal, e ingresa asignada para esta cuenta
entre cada una de
manualmente toda la nueva
ellas
información
suministrada en una
hoja de Excel
NEC-20 Reducir el margen Alta Manejo de la El Coordinador de El sistema calculará el
de error que ocurre cuentas Suministros revisa presupuesto mensual asignado
durante la emisión actualmente activas manualmente la a una cuenta, en función de la
y/o asignación de en la empresa distribución del distribución realizada por el
presupuesto de presupuesto realizada Coordinador de Suministros
Distribución del
una cuenta para una cuenta entre
presupuesto general
contable los centros de costo
entre cada una de
asociados, y va
ellas
sumando el
presupuesto
distribuido por mes.
El total debe coincidir
con el presupuesto
asignado para la
cuenta durante el
mismo mes
NEC-21 Facilitar la toma de Alta Manejo de la El Coordinador de El sistema puede almacenar
decisiones en la cuentas Suministros revisa un historial de presupuestos
distribución del actualmente activas manualmente la asignados, y mostrarlos para
presupuesto a los en la empresa distribución del facilitar la toma de decisión a
centros de costo presupuesto realizada la hora de reasignar
Distribución del
para una cuenta entre presupuestos.
presupuesto general
los centros de costo
entre cada una de
asociados, basándose
ellas
en las asignaciones
anteriores
El sistema propuesto tiene un enfoque sólo hacia la gestión del proceso de solicitudes de
cotización, orden de compra, inventario, despacho de suministros, devoluciones, pedidos
internos, notas de recibo, cuentas contables, facturas, facturas internas, cuentas por pagar,
centros de costo y usuarios de la sede principal de CENTROBECO C.A. en Boleíta. No se manejará
el inventario de los Centros de Costos independientemente, sino el inventario central que existe
en el Centro de Distribución de la empresa.
Reducir el margen de error que se genera El sistema mostrará en pantalla aquellos insumos escasos,
al llevar manualmente el proceso de promedios o excedentes, de tal forma que permita al
compra, despacho e inventario de administrador pedir únicamente lo que sea necesario.
suministros y servicios.
Evitar gastos innecesarios que actualmente El sistema automatizará el cálculo de las cuentas por
sufre la empresa, en la medida de que pagar pendientes que se tenga con los proveedores, así
ocurren menos errores a la hora de realizar como también la distribución de gastos por Centros de
compras de suministros. Costos.
Mayor rapidez a la hora de gestionar las El sistema mostrará en pantalla aquellos insumos escasos,
órdenes de compra, despacho y control de y automatizará la realización de solicitudes de cotización y
inventario de los suministros y servicios. órdenes de compra a los proveedores.
Al recibir mercancía, el sistema automatizará el envío de
notas de recibo y facturas desde el Centro de Distribución,
al Departamento de Finanzas y a los Centros de Costo.
El inventario de los insumos se actualizará
automáticamente en la medida que se reciben y
despachan insumos desde el Centro de Distribución
Mejor control del uso y despacho de los El sistema mostrará al Coordinador de Suministros la
suministros que se compran frecuencia de uso de los insumos solicitados por los
Centros de Costos. De esta manera, el Coordinador de
Suministros, según la información mostrada, puede
establecer una mejor distribución de los insumos.
4.3 Dependencias
El sistema estará funcionando en el servidor “AS400” con el que cuenta la empresa. Este
servidor debe soportar “Java Server Pages”, y tener instalado un manejador de Bases de Datos
“DB2” y Java.
4.4 Costos
El costo del desarrollo de este software, depende estrictamente del tiempo invertido por
los programadores, de la aprobación por parte del Responsable comercial de cada uno de los
requerimientos que lo integra, y de los costos de obtener la tecnología que se está
implementando.
6. Restricciones
Por ahora, no habrá ninguna relación de integración o soporte entre este sistema, y los
otros ya existentes en CENTROBECO C.A. Sin embargo, el programa será lo suficientemente
modular para permitir la posibilidad de integración con otros sistemas y esquemas de bases de
datos implementados en la empresa.
7. Rangos de Calidad
Para realizar este proyecto, tomaremos en cuenta los siguientes rangos de calidad:
• USABILIDAD: El sistema debe ser altamente intuitivo y fácil de usar, de modo que no se
invierta mucho tiempo en adiestramiento del personal. Que todas las tareas se hagan en el
menor tiempo posible y de esta forma agilizar cualquier toma de decisión, basado en los datos
más actuales.
• ESTABILIDAD: El sistema no debe interrumpir su ejecución ante cualquier falla, debe poder
manejarlas de forma adecuada. Los datos permitirán mantener informado al Coordinador de
Suministros para la toma de decisiones.
• EFICIENCIA: El sistema debe tener tiempos de respuesta cortos a la hora de manejar cada una
de las funciones que lo integra.
8. Precedencia y Prioridades
Cuando se generan las ordenes de compra y se reciben los insumos de parte de los
proveedores, el Auxiliar de Suministros emite la nota de recibo asociada, indicando cuanto de
cada insumo se recibió. En el caso de haber algún error en la mercancía, se lo notifican al
Coordinador de Suministros, para que analice si aceptarla o no.
Una vez que se emite la nota de recibo, ésta es enviada al Personal de Finanzas para que
proceda a la emisión del pago que se le efectuará al proveedor.
Los Colaboradores solo emiten una solicitud de pedido interno de insumos, de acuerdo a
sus necesidades, para enviarlas a su Gerente.
H
HIIS
STTO
ORRIIA
ALL D
DEE R
REEV
VIIS
SIIÓ
ÓNN
T
TAAB
BLLA
A D
DEE C
COON
NTTE
ENNIID
DOOS
S
1. INTRODUCCIÓN ................................................................................................................................. 7
T
TAAB
BLLA
A D
DEE IIL
LUUS
STTR
RAAC
CIIO
ONNE
ESS
11.. IInnttrroodduucccciióónn
1
1..1
1.. A
Allcca
anncce
e
El documento Especificación de Requerimientos del Software, tiene como finalidad
mostrar los requerimientos funcionales que el sistema debe cumplir, y describir en profundidad
los escenarios o casos de uso que el sistema deberá interactuar con el cliente.
1
1..2
2.. D
Deeffiin
niicciio
onne
ess,, A
Accrró
ónniim
mooss yy a
abbrre
evviia
acciio
onne
ess
• Almacén: Depósito donde se guardan los suministros adquiridos por CENTROBECO C.A. en
su sede central en Boleíta.
• Cuenta: Relación de dinero asignada por la gerencia general, a cada una de las actividades
que se hacen dentro de la empresa. Ejemplo: Cuenta de gastos de limpieza, Cuenta de
gastos de papelería, etc.
• Cuenta por pagar: Obligación que tiene la empresa CENTROBECO C.A. de pagar una
determinada cantidad de dinero con un proveedor.
• Factura: Documento emitido por un proveedor que muestra la relación de los suministros
y precios comprendidos en una venta.
• Inventario: Conjunto de insumos del que dispone CENTROBECO C.A, y que se despachará
a los diversos centros de costo, de acuerdo a la solicitud que hayan realizado
• Nota de Recibo: Es un documento que informa sobre los insumos que se han recibido de
un proveedor determinado, así como también la cantidad exacta de cada uno de ellos. Con
este documento, junto con la factura que llega, es que se tramita el pago al proveedor que
despachó la mercancía.
• Pago: Es el trámite que el Personal de Finanzas realiza, para cancelar una cuenta por
pagar que se tenga pendiente con un proveedor determinado.
• Pedidos Internos: Son todas aquellas solicitudes que los Centros de Costo realizan a la
Coordinación de Suministros en la sede principal CENTROBECO C.A, indicando los insumos
que necesitan, la cantidad respectiva, y el motivo por el cual lo piden.
• Insumo: Son los artículos que el Coordinador de Suministros compra, para cubrir las
necesidades de cada uno de los Centros de Costo.
• Proveedor: Es una persona o empresa que abastece de los insumos solicitados por el
Coordinador de Suministros, en la sede principal CENTROBECO C.A.
• Secciones: Son todas las áreas o sub-departamentos que integran un Centro de Costo
• Usuarios: Son todas las personas que trabajan en los diversos centros de costo existentes
1
1..3
3.. R
Reeffe
erre
enncciia
ass
Este documento hace referencia al documento Visión, el cual tiene una descripción de
las necesidades y características que el sistema debe satisfacer. Estos documentos se
encuentran en las carpetas comerciales y técnicas del proyecto. La carpeta comercial está bajo
la custodia de la Gerencia de Logística, y la carpeta técnica está bajo la custodia de la Gerencia
de Sistemas.
•• M
Maan
neejja
arr A
Allm
maacce
enne
ess
ID Requerimiento: RF-01 Manejar Almacenes
Característica Asociada: Automatización del Inventario y Stock de insumos
Descripción: El sistema debe permitir registrar y actualizar los datos un almacén
Prioridad: () Alta () Media Alta (x) Media () Media Baja () Baja
Tipo: Funcional Condición: Obligatorio
•• A
Annu
ulla
arr yy R
Reeccu
uppe
erra
arr A
Allm
maacce
enne
ess
ID Requerimiento: RF-02 Anular y Recuperar Almacenes
Característica Asociada: Automatización del Inventario y Stock de insumos
Descripción: El sistema debe permitir anular y recuperar un almacén registrado
Prioridad: () Alta () Media Alta (x) Media () Media Baja () Baja
Tipo: Funcional Condición: Obligatorio
•• C
Coon
nssu
ulltta
arr A
Allm
maacce
enne
ess
ID Requerimiento: RF-03 Consultar Almacenes
Característica Asociada: Automatización del Inventario y Stock de insumos
Descripción: El sistema debe permitir consultar todos los datos de un almacén
Prioridad: () Alta () Media Alta (x) Media () Media Baja () Baja
Tipo: Funcional Condición: Obligatorio
•• M
Maan
neejja
arr C
Ceen
nttrro
oss d
deeC
Coosstto
o
ID Requerimiento: RF-04 Manejar Centros de Costo
Característica Asociada: Gestión de Centros de Costos y Secciones. Manejo de pedidos internos. Manejo de
despachos internos
Descripción: El sistema debe permitir registrar y actualizar los datos de un centro de costo y/o de sus secciones
Prioridad: () Alta () Media Alta (x) Media () Media Baja () Baja
Tipo: Funcional Condición: Obligatorio
•• A
Annu
ulla
arr yy R
Reeccu
uppe
erra
arr C
Ceen
nttrro
oss d
deeC
Coosstto
o
ID Requerimiento: RF-05 Anular y Recuperar Centros de Costo
Característica Asociada: Gestión de Centros de Costos y Secciones. Manejo de pedidos internos. Manejo de
despachos internos
Descripción: El sistema debe permitir anular y recuperar un centro de costo registrado, o alguna de sus secciones
Prioridad: () Alta () Media Alta (x) Media () Media Baja () Baja
Tipo: Funcional Condición: Obligatorio
•• C
Coon
nssu
ulltta
arr C
Ceen
nttrro
oss d
deeC
Coosstto
o
ID Requerimiento: RF-06 Consultar Centros de Costo
Característica Asociada: Gestión de Centros de Costos y Secciones. Manejo de pedidos internos. Manejo de
despachos internos. Reportes Estadísticos
Descripción: El sistema debe permitir consultar todos los datos de un centro de costo y de cada una de sus secciones.
Prioridad: () Alta () Media Alta (x) Media () Media Baja () Baja
Tipo: Funcional Condición: Obligatorio
•• D
Diissttrriib
buuiirr llo
oss iin
nssu
ummo
oss d
deeu
unna
a n
nootta
a d
dee rre
ecciib
boo e
ennttrre
e
llo
oss cce
ennttrro
oss d
dee cco
osstto
o
ID Requerimiento: RF-07 Distribuir los insumos de una nota de recibo entre los centros de costo
Característica Asociada: Automatización de Compras y recepción de insumos. Automatización del Inventario y Stock
de insumos. Manejo de pedidos internos. Manejo de despachos internos
Descripción: El sistema debe permitir distribuir los insumos recibidos en una nota de recibo, entre los centros de costo
activos, bien sea por monto o por cantidad, tomando en cuenta los pedidos internos pendientes
Prioridad: (x) Alta () Media Alta () Media () Media Baja () Baja
Tipo: Funcional Condición: Obligatorio
•• D
Diissttrriib
buuiirr P
Prre
essu
uppu
ueesstto
odde
ell a
añ o ffiisscca
ño all d
deeu
unna
aCCu
ueen
ntta
a
C
Coon
ntta
abblle
ee nttrre
en e llo
oss C
Ceen
nttrro
oss d
deeC
Coosstto
o
ID Requerimiento: RF-08 Distribuir Presupuesto del año fiscal de una Cuenta Contable entre los
Centros de Costo
Característica Asociada: Gestión de Centros de Costos y Secciones. Manejo de pedidos internos. Manejo de
despachos internos. Gestión de cuentas contables.
Descripción: El sistema debe permitir distribuir el presupuesto del año fiscal asignado a una cuenta, entre los centros
de costo asociados
Prioridad: () Alta (x) Media Alta () Media () Media Baja () Baja
Tipo: Funcional Condición: Obligatorio
•• R
Reeg
giissttrra
arr C
Cuue
enntta
ass C
Coon
ntta
abblle
ess
ID Requerimiento: RF-09 Manejar Cuentas Contables
Característica Asociada: Gestión de cuentas contables. Manejo de despachos internos
Descripción: El sistema debe permitir registrar los datos de una nueva cuenta contable
Prioridad: () Alta () Media Alta (x) Media () Media Baja () Baja
Tipo: Funcional Condición: Obligatorio
•• C
Coon
nssu
ulltta
arr C
Cuue
enntta
ass C
Coon
ntta
abblle
ess
ID Requerimiento: RF-10 Consultar Cuentas Contables
Característica Asociada: Gestión de cuentas contables. Manejo de despachos internos. Reportes Estadísticos
Descripción: El sistema debe permitir consultar los datos de una cuenta contable registrada
Prioridad: () Alta () Media Alta (x) Media () Media Baja () Baja
Tipo: Funcional Condición: Obligatorio
•• C
Coon
nssu
ulltta
arr tto
odda
ass lla
ass ccu
ueen
ntta
ass p
poorr p
paag
gaarr
ID Requerimiento: RF-11 Consultar todas las cuentas por pagar
Característica Asociada: Cálculo de las Cuenta por pagar y los Pagos. Gestión de los Proveedores. Reportes
Estadísticos
Descripción: El sistema debe permitir la consulta de todas las cuentas por pagar existentes para un proveedor.
Prioridad: () Alta (x) Media Alta () Media () Media Baja () Baja
Tipo: Funcional Condición: Obligatorio
•• M
Maan
neejja
arr D
Deevvo
ollu
ucciió
ónn
ID Requerimiento: RF-12 Manejar Devolución
Característica Asociada: Manejo de Devoluciones.
Descripción: El sistema debe permitir registrar y actualizar los datos de una devolución. Una devolución puede
contemplar el retorno de varios insumos de distintas notas de recibo. Debe permitir el cambio de estado de una
devolución de “No Devuelto” a “Devuelto”
Prioridad: () Alta () Media Alta (x) Media () Media Baja () Baja
Tipo: Funcional Condición: Obligatorio
•• A
Annu
ulla
arr yy R
Reeccu
uppe
erra
arr D
Deevvo
ollu
ucciio
onne
ess
ID Requerimiento: RF-13 Anular Devolución
Característica Asociada: Manejo de Devoluciones
Descripción: El sistema debe permitir anular y recuperar una devolución
Prioridad: () Alta () Media Alta (x) Media () Media Baja () Baja
Tipo: Funcional Condición: Obligatorio
•• C
Coon
nssu
ulltta
arr D
Deevvo
ollu
ucciió
ónn
ID Requerimiento: RF-14 Consultar Devolución
Característica Asociada: Manejo de Devoluciones. Reportes estadísticos
Descripción: El sistema debe permitir consultar todos los datos de una devolución registrada.
Prioridad: () Alta () Media Alta (x) Media () Media Baja () Baja
Tipo: Funcional Condición: Obligatorio
•• M
Maan
neejja
arr FFa
accttu
urra
ass
ID Requerimiento: RF-15 Manejar facturas
Característica Asociada: Automatización de Órdenes de Compra. Cálculo de las Cuenta por pagar y los Pagos.
Descripción: Brinda la opción de registrar y actualizar toda la información relacionada con las facturas recibidas por los
proveedores
Prioridad: () Alta (x) Media Alta () Media () Media Baja () Baja
Tipo: Funcional Condición: Obligatorio
•• C
Coon
nssu
ulltta
arr FFa
accttu
urra
ass
ID Requerimiento: RF-16 Consultar facturas
Característica Asociada: Automatización de Órdenes de Compra. Cálculo de las Cuenta por pagar y los Pagos. Reportes
Estadísticos
Descripción: El Sistema debe permitir consultar la información relacionada con las facturas registradas
Prioridad: () Alta (x) Media Alta () Media () Media Baja () Baja
Tipo: Funcional Condición: Obligatorio
•• M
Maan
neejja
arr FFa
accttu
urra
ass IIn
ntte
errn
naass
ID Requerimiento: RF-17 Manejar Facturas Internas
Característica Asociada: Manejo de pedidos internos. Manejo de despachos internos
Descripción: El sistema debe permitir registrar y actualizar los datos de una factura interna
Prioridad: () Alta () Media Alta (x) Media () Media Baja () Baja
Tipo: Funcional Condición: Obligatorio
•• C
Coon
nssu
ulltta
arr FFa
accttu
urra
ass IIn
ntte
errn
naass
ID Requerimiento: RF-18 Consultar Facturas Internas
Característica Asociada: Manejo de pedidos internos. Manejo de despachos internos
Descripción: El sistema debe permitir consultar los datos de una factura interna registrada
Prioridad: () Alta () Media Alta (x) Media () Media Baja () Baja
Tipo: Funcional Condición: Obligatorio
•• M
Maan
neejja
arr iin
nssu
ummo
oss
ID Requerimiento: RF-19 Manejar Insumos
Característica Asociada: Automatización de Órdenes de Compra. Automatización del Inventario y Stock de insumos.
Descripción: El sistema debe permitir registrar y actualizar los datos un insumo
Prioridad: (x) Alta () Media Alta () Media () Media Baja () Baja
Tipo: Funcional Condición: Obligatorio
•• A
Annu
ulla
arr yy R
Reeccu
uppe
erra
arr IIn
nssu
ummo
oss
ID Requerimiento: RF-20 Anular y Recuperar Insumos
Característica Asociada: Automatización de Órdenes de Compra. Automatización del Inventario y Stock de insumos
Descripción: El sistema debe permitir anular y recuperar los datos un insumo
Prioridad: (x) Alta () Media Alta () Media () Media Baja () Baja
Tipo: Funcional Condición: Obligatorio
•• C
Coon
nssu
ulltta
arr IIn
nssu
ummo
oss
ID Requerimiento: RF-21 Consultar Insumos
Característica Asociada: Automatización de Órdenes de Compra. Automatización del Inventario y Stock de insumos.
Reportes Estadísticos
Descripción: El sistema debe permitir consultar todos los datos de un insumo
Prioridad: (x) Alta () Media Alta () Media () Media Baja () Baja
Tipo: Funcional Condición: Obligatorio
•• IIn
niicciia
arr yy FFiin
naalliizza
arr P
Prro
occe
esso
oss d
dee IIn
nvve
enntta
arriio
o
ID Requerimiento: RF-22 Iniciar y Finalizar Procesos de Inventario
Característica Asociada: Automatización del Inventario y Stock de insumos
Descripción: El sistema debe permitir llevar a cabo un proceso de inventario. Mientras se realiza un proceso de
inventario, el resto de las funciones deben estar deshabilitadas, y solo quedaran habilitadas aquellas relacionadas con el
proceso de inventario en marcha
Prioridad: (x) Alta () Media Alta () Media () Media Baja () Baja
Tipo: Funcional Condición: Obligatorio
•• M
Maan
neejja
arr cco
onntte
eooss d
dee iin
nssu
ummo
oss d
dee u
unn iin
nvve
enntta
arriio
o e
enn
m
maarrcch
haa
ID Requerimiento: RF-23 Ingresar conteos de insumos
Característica Asociada: Automatización del Inventario y Stock de insumos
Descripción: En un proceso de inventario, se deben registrar los insumos que se han contado
Prioridad: (x) Alta () Media Alta () Media () Media Baja () Baja
Tipo: Funcional Condición: Obligatorio
•• C
Coon
nssu
ulltta
arr iin
nvve
enntta
arriio
oss yy cco
onntte
eooss d
dee iin
nssu
ummo
oss
ID Requerimiento: RF-24 Ingresar conteos de insumos
Característica Asociada: Automatización del Inventario y Stock de insumos. Reportes Estadísticos
Descripción: Después de finalizar un proceso de inventario, se debe poder consultar los resultados de procesos de
inventarios anteriores
Prioridad: () Alta (x) Media Alta () Media () Media Baja () Baja
•• M
Maan
neejja
arr U
Ussu
uaarriio
oss yy S
Seessiio
onne
ess
ID Requerimiento: RF-25 Manejar Usuarios
Característica Asociada: Gestión de usuarios.
Descripción: El sistema debe permitir registrar y actualizar los datos de un usuario. A un usuario registrado, el sistema le
brindará acceso, y le dejará ejecutar ciertas funciones dependiendo del tipo de usuario.
Prioridad: (x) Alta () Media Alta () Media () Media Baja () Baja
Tipo: Funcional Condición: Obligatorio
•• A
Annu
ulla
arr yy R
Reeccu
uppe
erra
arr U
Ussu
uaarriio
oss
ID Requerimiento: RF-26 Anular y Recuperar Usuarios
Característica Asociada: Gestión de usuarios
Descripción: El sistema debe permitir anular y recuperar un usuario registrado
Prioridad: () Alta () Media Alta (x) Media () Media Baja () Baja
Tipo: Funcional Condición: Obligatorio
•• C
Coon
nssu
ulltta
arr U
Ussu
uaarriio
oss
ID Requerimiento: RF-27 Consultar Usuarios
Característica Asociada: Gestión de usuarios. Reportes Estadísticos
Descripción: El sistema debe permitir consultar todos los datos de un usuario.
Prioridad: () Alta () Media Alta (x) Media () Media Baja () Baja
Tipo: Funcional Condición: Obligatorio
•• M
Maan
neejja
arr N
Nootta
ass d
deeR
Reecciib
boo
ID Requerimiento: RF-28 Manejar Notas de Recibo
Característica Asociada: Automatización de Compras y recepción de insumos. Manejo de despachos internos. Manejo
de Devoluciones
Descripción: El sistema debe permitir registrar y actualizar los datos de una nota de recibo
Prioridad: (x) Alta () Media Alta () Media () Media Baja () Baja
Tipo: Funcional Condición: Obligatorio
•• C
Coon
nssu
ulltta
arr N
Nootta
ass d
deeR
Reecciib
boo
ID Requerimiento: RF-29 Consultar Notas de Recibo
Característica Asociada: Automatización de Compras y recepción de insumos. Manejo de despachos internos. Manejo
de Devoluciones. Reportes Estadísticos
Descripción: El sistema debe permitir consultar todos los datos de una nota de recibo
Prioridad: (x) Alta () Media Alta () Media () Media Baja () Baja
Tipo: Funcional Condición: Obligatorio
•• M
Maan
neejja
arr Ó
Órrd
deen
neess d
deeC
Coom
mpprra
a
ID Requerimiento: RF-30 Manejar Órdenes de compra
Característica Asociada: Automatización de Órdenes de Compra
Descripción: El sistema debe permitir registrar y actualizar los datos de una orden de compra. Debe también permitir
registrar una orden a partir de una solicitud de cotización
Prioridad: (x) Alta () Media Alta () Media () Media Baja () Baja
Tipo: Funcional Condición: Obligatorio
•• A
Annu
ulla
arr yy R
Reeccu
uppe
erra
arr Ó
Órrd
deen
neess d
deeC
Coom
mpprra
a
ID Requerimiento: RF-31 Anular y Recuperar Órdenes de Compra
Característica Asociada: Automatización de Órdenes de Compra
Descripción: El sistema debe permitir eliminar y/o restaurar cualquier orden registrada
Prioridad: (x) Alta () Media Alta () Media () Media Baja () Baja
•• C
Coon
nssu
ulltta
arr Ó
Órrd
deen
neess d
deeC
Coom
mpprra
a
ID Requerimiento: RF-32 Consultar Órdenes de compra
Característica Asociada: Automatización de Órdenes de Compra
Descripción: El sistema debe permitir consultar los datos de una orden de compra registrada
Prioridad: (x) Alta () Media Alta () Media () Media Baja () Baja
Tipo: Funcional Condición: Obligatorio
•• M
Maan
neejja
arr cco
onnd
diicciio
onne
ess d
deep
paag
goo
ID Requerimiento: RF-33 Manejar condiciones de pago
Característica Asociada: Gestión de los Proveedores. Cálculo de las Cuenta por pagar y los Pagos.
Descripción: Brindar la opción de manejar todas las condiciones de pago aceptadas por los proveedores
Prioridad: () Alta () Media Alta (x) Media () Media Baja () Baja
Tipo: Funcional Condición: Obligatorio
•• M
Maan
neejja
arr P
Peed
diid
dooss IIn
ntte
errn
nooss
ID Requerimiento: RF-34 Manejar Pedidos Internos
Característica Asociada: Manejo de pedidos internos. Manejo de despachos internos
Descripción: El sistema debe permitir registrar y actualizar los datos un pedido interno
Prioridad: () Alta (x) Media Alta () Media () Media Baja () Baja
Tipo: Funcional Condición: Obligatorio
•• A
Annu
ulla
arr yy R
Reeccu
uppe
erra
arr P
Peed
diid
dooss IIn errn
ntte nooss
ID Requerimiento: RF-35 Anular y Recuperar Pedidos Internos
Característica Asociada: Manejo de pedidos internos. Manejo de despachos internos
Descripción: El sistema debe permitir anular y recuperar un pedido interno registrado
Prioridad: () Alta (x) Media Alta () Media () Media Baja () Baja
Tipo: Funcional Condición: Obligatorio
•• C
Coon
nssu
ulltta
arr P
Peed
diid
dooss IIn
ntte
errn
nooss
ID Requerimiento: RF-36 Consultar Pedidos Internos
Característica Asociada: Manejo de pedidos internos. Manejo de despachos internos. Reportes Estadísticos
Descripción: El sistema debe permitir consultar todos los datos de un pedido interno
Prioridad: () Alta (x) Media Alta () Media () Media Baja () Baja
Tipo: Funcional Condición: Obligatorio
•• M
Maan
neejja
arr p
prro
ovve
eeed
doorre
ess
ID Requerimiento: RF-37 Ingresar un proveedor al sistema
Característica Asociada: Gestión de los Proveedores
Descripción: El sistema debe brindar la posibilidad de registrar y actualizar los datos de un proveedor
Prioridad: () Alta (x) Media Alta () Media () Media Baja () Baja
Tipo: Funcional Condición: Obligatorio
•• C
Coon
nssu
ulltta
arr p
prro
ovve
eeed
doorre
ess
ID Requerimiento: RF-38 Consultar proveedores
Característica Asociada: Gestión de los Proveedores. Reportes Estadísticos
Descripción: Brinda la posibilidad de ver los datos de todos los proveedores registrados, con criterios de búsqueda, que
faciliten la ubicación de los proveedores.
Prioridad: () Alta () Media Alta (x) Media () Media Baja () Baja
Tipo: Funcional Condición: Obligatorio
•• A
Annu
ulla
arr yy rre
eccu
uppe
erra
arr p
prro
ovve
eeed
doorre
ess
ID Requerimiento: RF-39 Anular y recuperar proveedores
Característica Asociada: Gestión de los Proveedores
Descripción: Brinda la opción de remover y recuperar proveedores registrados en el sistema
Prioridad: () Alta () Media Alta (x) Media () Media Baja () Baja
Tipo: Funcional Condición: Obligatorio
•• M
Maan
neejja
arr S
Soolliicciittu
udde
ess d
deeC
Coottiizza ón
acciió n
ID Requerimiento: RF-40 Manejar Solicitudes de Cotización
Característica Asociada: Automatización de Solicitudes de Cotización. Automatización de Órdenes de Compra
Descripción: El sistema debe permitir registrar y actualizar los datos de una solicitud de cotización
Prioridad: () Alta () Media Alta (x) Media () Media Baja () Baja
Tipo: Funcional Condición: Obligatorio
•• A
Annu
ulla
arr yy R
Reeccu
uppe
erra
arr S
Soolliicciittu
udde de
ess d eC
Coottiizza
acciió
ónn
ID Requerimiento: RF-41 Anular y Recuperar Solicitudes de Cotización
Característica Asociada: Automatización de Solicitudes de Cotización. Automatización de Órdenes de Compra
Descripción: El sistema debe permitir eliminar y/o restaurar cualquier solicitud registrada
Prioridad: () Alta () Media Alta (x) Media () Media Baja () Baja
Tipo: Funcional Condición: Obligatorio
•• C
Coon
nssu
ulltta
arr S
Soolliicciittu
udde
ess d
deeC
Co acciió
ottiizza ónn
ID Requerimiento: RF-42 Consultar Solicitudes de Cotización
Característica Asociada: Automatización de Solicitudes de Cotización. Automatización de Órdenes de Compra
Descripción: El sistema debe permitir consultar los datos de las solicitudes de cotización registradas
Prioridad: () Alta () Media Alta (x) Media () Media Baja () Baja
Tipo: Funcional Condición: Obligatorio
1
1..1
1.. U
Ussu
uaarriio
oss o
oaacctto
orre
ess
Existen seis actores identificados en el sistema: el Coordinador de Suministros, el
Auxiliar de Suministros, el Analista de Suministros, el Colaborador, el Gerente y el personal de
Finanzas.
Coordinador de Suministros (CS): es el encargado de administrar el proceso de Orden
de Compra y despacho de los insumos que llegan a la Sede Principal de la Compañía.
Auxiliar de Suministros (AXS): es el encargado de la administración de las notas de
recibo, y de las facturas emitidas por parte de los proveedores. Son los encargados de
generar una nueva nota, cada vez que se reciben insumos.
Analista de Suministros (ANS): es el encargado del proceso de chequeo físico para
determinados insumos, guardados en un almacén. Se encarga de contar la cantidad
existente por producto y de ingresar en el sistema los resultados obtenidos.
Colaborador (C): es quien crea los pedidos internos del Centro de Costo donde
pertenece, para que estos sean posteriormente evaluados y, en el caso de que así lo
amerite, aprobarlos por el colaborador autorizado (Gerente).
Gerente (G): es el encargado de gestionar los pedidos internos emitidos por los
colaboradores que trabajan en el Centro de Costo que él gestiona.
Personal de Finanzas (PF): es el encargado de emitir los pagos correspondientes a las
notas de recibo emitidas.
1
1..2
2.. M
Móód
duullo
oss o
oPPa
aqqu
ueette
ess d
deeC
Caasso de
oss d eU
Usso
o
En vista de la magnitud de nuestro sistema, los casos de uso se agruparon en 18
módulos o paquetes:
Los diagramas a continuación, muestran la interacción entre los usuarios y los paquetes
del sistema:
Figura 2. Interacción de Usuarios con los paquetes de: Centros de Costo, Cuentas
Contables y Cuentas por Pagar
Figura 3. Interacción de Usuarios con los paquetes de: Facturas, Insumos, Líneas de
Insumos, Almacenes, Notas de Recibo y Órdenes de Compra
Figura 4. Interacción de Usuarios con los paquetes de: Inventario, Facturas Internas y
Pedidos Internos
Figura 5. Interacción de Usuarios con los paquetes de: Manejo de Usuarios y Sesiones de
Usuario
3..4
3 Re
4.. R um
essu en
me de
nd Ca
eC de
oss d
asso Usso
eU Acctto
o yy A ess
orre
Coordinador de Suministros
CU-CCO-05 Consultar Datos del Centro de Costo Gerente
Colaborador
CU-CCO-08 Distribuir presupuesto de una cuenta entre los Centros de Costo Personal de Finanzas
Coordinador de Suministros
CU-CUP-01 Listar todas las Cuentas por Pagar
Personal de Finanzas
Coordinador de Suministros
CU-CUP-02 Listar las Cuentas por Pagar por Insumo
Personal de Finanzas
Coordinador de Suministros
CU-CUP-03 Listar las Cuentas por Pagar por Proveedor
Personal de Finanzas
Coordinador de Suministros
CU-CUP-04 Listar las Cuentas por Pagar por Centro de Costo
Personal de Finanzas
Coordinador de Suministros
CU-CUP-05 Listar las Cuentas por Pagar por Período
Personal de Finanzas
Coordinador de Suministros
CU-CUP-06 Listar las Cuentas por Pagar en Bolívares
Personal de Finanzas
Coordinador de Suministros
CU-CUP-07 Listar las Cuentas por Pagar por Cuenta Contable
Personal de Finanzas
Coordinador de Suministros
CU-FAC-01 Ingresar Factura
Auxiliar de Suministros
Coordinador de Suministros
CU-FAC-03 Consultar datos de una factura
Personal de Finanzas
Coordinador de Suministros
CU-FAC-04 Listar todas las facturas
Personal de Finanzas
Coordinador de Suministros
CU-FAC-05 Listar facturas por proveedor
Personal de Finanzas
Coordinador de Suministros
CU-FAC-06 Listar facturas por orden de compra
Personal de Finanzas
Coordinador de Suministros
CU-FAC-07 Listar facturas por línea de insumos
Personal de Finanzas
Coordinador de Suministros
CU-FAC-08 Listar facturas por insumos
Personal de Finanzas
Coordinador de Suministros
CU-FAC-09 Listar facturas por rango de fecha
Personal de Finanzas
Coordinador de Suministros
CU-FAI-01 Ingresar factura interna
Analista de Suministros
Coordinador de Suministros
CU-FAI-09 Listar facturas internas por centro de costo
Gerente
CU-FAI-10 Listar facturas internas por rango de fecha de facturación Coordinador de Suministros
Coordinador de Suministros
CU-FAI-11 Listar facturas internas por centro de costo y por insumos
Gerente
Listar facturas internas por centro de costo y por fecha de Coordinador de Suministros
CU-FAI-12
facturación Gerente
Coordinador de Suministros
Analista de Suministros
CU-INS-03 Consultar Insumo Auxiliar de Suministros
Gerente
Colaborador
Coordinador de Suministros
Analista de Suministros
CU-INS-07 Listar todos los Insumos Auxiliar de Suministros
Gerente
Colaborador
Coordinador de Suministros
Analista de Suministros
CU-INS-08 Listar Insumos por Línea Auxiliar de Suministros
Gerente
Colaborador
Coordinador de Suministros
Analista de Suministros
CU-INS-09 Listar Insumos por Proveedor Auxiliar de Suministros
Gerente
Colaborador
Coordinador de Suministros
Analista de Suministros
CU-INS-10 Listar Insumos por Existencia Auxiliar de Suministros
Gerente
Colaborador
Coordinador de Suministros
Analista de Suministros
CU-INS-11 Listar Insumos por Procedencia Auxiliar de Suministros
Gerente
Colaborador
Coordinador de Suministros
Analista de Suministros
CU-INS-12 Listar Insumos por Estado Auxiliar de Suministros
Gerente
Colaborador
Coordinador de Suministros
Analista de Suministros
CU-INS-13 Listar Insumos por Demanda Auxiliar de Suministros
Gerente
Colaborador
Coordinador de Suministros
CU-INS-14 Listar Insumos por Talla
Analista de Suministros
Auxiliar de Suministros
Gerente
Colaborador
Coordinador de Suministros
Analista de Suministros
CU-INS-15 Listar Insumos por Almacén Auxiliar de Suministros
Gerente
Colaborador
Coordinador de Suministros
Analista de Suministros
CU-INS-16 Listar Insumos por Fecha de Registro Auxiliar de Suministros
Gerente
Colaborador
Coordinador de Suministros
Analista de Suministros
CU-INS-17 Listar Insumos por Cantidad Auxiliar de Suministros
Gerente
Colaborador
Coordinador de Suministros
Analista de Suministros
CU-INS-18 Listar Insumos por Precio Auxiliar de Suministros
Gerente
Colaborador
Coordinador de Suministros
CU-INS-19 Listar Insumos No Contados en el Proceso de Inventario
Analista de Suministros
Coordinador de Suministros
CU-INV-04 Ingresar Conteo Físico
Analista de Suministros
Analista de Suministros
Coordinador de Suministros
Analista de Suministros
CU-LIN-02 Consultar los datos de una línea de insumo Auxiliar de Suministros
Gerente
Colaborador
Coordinador de Suministros
Analista de Suministros
CU-LIN-07 Listar todas las líneas de insumos Auxiliar de Suministros
Gerente
Colaborador
Coordinador de Suministros
CU-NRE-01 Emitir nota de recibo
Auxiliar de Suministros
Coordinador de Suministros
CU-NRE-02 Modificar datos de una nota de recibo
Auxiliar de Suministros
Coordinador de Suministros
CU-NRE-03 Consultar nota de recibo Auxiliar de Suministros
Personal de Finanzas
Coordinador de Suministros
CU-NRE-04 Listar todas las notas de recibo
Auxiliar de Suministros
Coordinador de Suministros
CU-NRE-05 Listar las notas de recibo pendientes por pagar
Personal de Finanzas
Listar las notas de recibo pendientes por pagar, por órdenes de Coordinador de Suministros
CU-NRE-06
compra Personal de Finanzas
CU-NRE-08 Listar las notas de recibo pagadas por orden de compra Coordinador de Suministros
Coordinador de Suministros
CU-NRE-09 Listar todas las notas de recibo por orden de compra
Auxiliar de Suministros
Colaborador
CU-PIN-01 Emitir un pedido interno
Gerente
Coordinador de Suministros
CU-PIN-02 Consultar un pedido interno Colaborador
Gerente
Coordinador de Suministros
CU-PIN-03 Anular pedido interno Colaborador
Gerente
Coordinador de Suministros
CU-PIN-04 Aprobar un pedido interno
Gerente
Coordinador de Suministros
CU-PIN-05 Modificar un pedido interno Gerente
Colaborador
Coordinador de Suministros
CU-PIN-06 Listar todos los pedidos internos
Colaborador
Coordinador de Suministros
CU-PIN-10 Listar todos los pedidos por centro de costo
Gerente
Coordinador de Suministros
CU-PIN-11 Listar todos los pedidos por centro de costo y por insumo
Gerente
Coordinador de Suministros
CU-PIN-12 Listar todos los pedidos internos por centro de costo y por estado
Gerente
Coordinador de Suministros
CU-PIN-13 Listar todos los pedidos internos por centro de costo y por línea
Gerente
Coordinador de Suministros
CU-PIN-15 Listar todos los pedidos internos pendientes por aprobar
Gerente
Coordinador de Suministros
Analista de Suministros
Auxiliar de Suministros
CU-SUS-01 Iniciar sesión
Personal de Finanzas
Colaborador
Gerente
Coordinador de Suministros
Analista de Suministros
Auxiliar de Suministros
CU-SUS-02 Consultar mis datos
Personal de Finanzas
Colaborador
Gerente
Coordinador de Suministros
Analista de Suministros
Auxiliar de Suministros
CU-SUS-03 Modificar mis datos
Personal de Finanzas
Colaborador
Gerente
Coordinador de Suministros
Analista de Suministros
Auxiliar de Suministros
CU-SUS-04 Cambiar contraseña
Personal de Finanzas
Colaborador
Gerente
5.. E
3..5
3 pe
Essp on
acciio
ecciiffiicca ne de
ess d Ca
eC asso de
oss d Usso
eU o
Agregar Almacén
i. ID Caso de uso: CU-ALM-01
ii. Requerimiento: RF-01
iii. Descripción
v. Flujo de Eventos
- Almacén registrado
- Almacén anulado
El sistema debe permitir que el registro de un nuevo almacén se realice de forma rápida
y sencilla.
viii. Precondiciones
ix. Poscondiciones
v. Flujo de Eventos
viii. Precondiciones
ix. Poscondiciones
Anular un almacén
i. ID Caso de uso: CU-ALM-03
ii. Requerimiento: RF-02
iii. Descripción
v. Flujo de Eventos
No hay
El sistema debe permitir que la anulación del almacén en cuestión, se realice de forma
rápida y sencilla.
viii. Precondiciones
Para poder anular un almacén, el Coordinador de Suministros debe haber iniciado sesión
en el Sistema.
ix. Poscondiciones
Suministros.
Restaurar un almacén
i. ID Caso de uso: CU-ALM-04
ii. Requerimiento: RF-02
iii. Descripción
v. Flujo de Eventos
No hay
El sistema debe permitir que la restauración del almacén en cuestión, se realice de forma
rápida y sencilla.
viii. Precondiciones
(ver CU-ALM-06)
ix. Poscondiciones
v. Flujo de Eventos
No Hay
El sistema debe permitir que la consulta del almacén en cuestión, se realice de forma
rápida y sencilla.
viii. Precondiciones
Para poder consultar los datos del almacén seleccionado, el Coordinador de Suministros
debe haber iniciado sesión en el Sistema.
ix. Poscondiciones
v. Flujo de Eventos
El sistema debe permitir que la lista de los almacenes, se realice de forma rápida y
sencilla.
viii. Precondiciones
Para poder listar todos los almacenes, el Coordinador de Suministros debe haber iniciado
sesión en el Sistema.
ix. Poscondiciones
El Sistema listó todos los almacenes que están registrados al Coordinador de Suministros.
v. Flujo de Eventos
El sistema debe permitir que la lista de los almacenes, se realice de forma rápida y
sencilla.
viii. Precondiciones
Para poder listar todos los almacenes, el Coordinador de Suministros debe haber iniciado
sesión en el Sistema.
ix. Poscondiciones
El Sistema listó todos los almacenes que están registrados al Coordinador de Suministros.
v. Flujo de Eventos
El sistema debe permitir que la búsqueda de los almacenes, se realice de forma rápida y
© CENTROBECO, C.A. 2007 Departamento de Sistemas Página 40
Sistema de Orden de Compras, Despacho e Inventario Versión: 3.0
de Suministros, Activos y Servicios Fecha: 08/06/2007
SOCDISAS
Especificación de Requerimientos de Software
sencilla.
viii. Precondiciones
Para poder listar todos los almacenes, el Coordinador de Suministros debe haber iniciado
sesión en el Sistema.
El actor debió de haber escogido los insumos de una lista de insumos que estén en los
almacenes para listar (ver del CU-INS-07 al CU-INS-18)
ix. Poscondiciones
El Sistema listó todos los almacenes que contienen el insumo especificado por el
Coordinador de Suministros
v. Flujo de Eventos
© CENTROBECO, C.A. 2007 Departamento de Sistemas Página 41
Sistema de Orden de Compras, Despacho e Inventario Versión: 3.0
de Suministros, Activos y Servicios Fecha: 08/06/2007
SOCDISAS
Especificación de Requerimientos de Software
El sistema debe permitir que la búsqueda de los almacenes, se realice de forma rápida y
sencilla.
viii. Precondiciones
Para poder listar todos los almacenes, el Coordinador de Suministros debe haber iniciado
sesión en el Sistema.
- El actor debió de haber escogido la(s) línea(s) de una lista (ver casos
de uso)
El actor debió de haber escogido las líneas de insumos de una lista que estén en los
almacenes para listar (ver CU-LIN-07)
ix. Poscondiciones
El Sistema listó todos los almacenes que guardan la línea especificada por el Coordinador
de Suministros
9 Coordinador de Suministros
v. Flujo de Eventos
7. Verifica la operación
El sistema debe permitir que el registro de un nuevo Centro de Costo se realice de forma
rápida y sencilla.
viii. Precondiciones
Para poder agregar un nuevo Centro de Costo, el Coordinador de Suministros debe haber
iniciado sesión en el Sistema.
ix. Poscondiciones
9 Coordinador de Suministros(CS)
9 Gerente (G)
v. Flujo de Eventos
El sistema debe permitir que la actualización del Centro de Costo en cuestión, se realice
de forma rápida y sencilla.
ix. Precondiciones
Para poder actualizar un nuevo Centro de Costo, el Usuario debe haber iniciado sesión en
el Sistema.
x. En caso del que el actor sea el Coordinador de Suministros, este debió de haber seleccionado un
Centro de Costo de una lista
xi. Poscondiciones
9 Coordinador de Suministros
v. Flujo de Eventos
No hay
viii. Precondiciones
© CENTROBECO, C.A. 2007 Departamento de Sistemas Página 47
Sistema de Orden de Compras, Despacho e Inventario Versión: 3.0
de Suministros, Activos y Servicios Fecha: 08/06/2007
SOCDISAS
Especificación de Requerimientos de Software
Para poder anular un Centro de Costo, el Coordinador de Suministros debe haber iniciado
sesión en el Sistema.
x. Poscondiciones
v. Flujo de Eventos
No hay
El sistema debe permitir que la restauración del Centro de Costo en cuestión, se realice
de forma rápida y sencilla.
viii. Precondiciones
ix. Poscondiciones
9 Gerente (G)
9 Colaborador (C)
v. Flujo de Eventos
No hay
El sistema debe permitir que la consulta del Centro de Costo en cuestión, se realice de
forma rápida y sencilla.
viii. Precondiciones
Para poder consultar los datos del Centro de Costo seleccionado, el Usuario debe haber
iniciado sesión en el Sistema.
ix. Poscondiciones
Para poder actualizar un nuevo Centro de Costo, el Usuario debe haber iniciado sesión en
el Sistema.
v. Flujo de Eventos
El sistema debe permitir que la búsqueda de los Centros de Costo, se realice de forma
rápida y sencilla.
viii. Precondiciones
ix. Poscondiciones
iii. Descripción
v. Flujo de Eventos
El sistema debe permitir que la búsqueda de los Centros de Costo, se realice de forma
rápida y sencilla.
ix. Precondiciones
Para poder listar todos los Centros de Costo, el Coordinador de Suministros debe haber
iniciado sesión en el Sistema.
© CENTROBECO, C.A. 2007 Departamento de Sistemas Página 53
Sistema de Orden de Compras, Despacho e Inventario Versión: 3.0
de Suministros, Activos y Servicios Fecha: 08/06/2007
SOCDISAS
Especificación de Requerimientos de Software
x. Poscondiciones
El Sistema listó al Coordinador de Suministros, todos los Centros de Costo que están
registrados.
Permite al Personal de Finanzas, distribuir el presupuesto de una cuenta existente, entre cada
uno de los centros de costo.
v. Flujo de Eventos
El sistema debe permitir que la distribución del presupuesto, se realice de forma rápida y
sencilla.
viii. Precondiciones
Para poder distribuir el presupuesto de una cuenta entre los centros de costo, el usuario
debe haber iniciado sesión en el Sistema.
El actor debe seleccionar previamente una cuenta existente de una lista de cuentas
contables (ver CU-CUC-06)
ix. Poscondiciones
i. Descripción
Permite al Coordinador de Suministros crear una nueva Cuenta contable dentro del sistema
v. Requerimientos Especiales
El sistema debe permitir que el registro de una Cuenta contable nueva, se realice de
forma rápida y sencilla.
vi. Precondiciones
Para poder agregar una nueva Cuenta contable, el Coordinador de Suministros debe
haber iniciado sesión en el Sistema.
Para ingresar una nueva cuenta al sistema, no debe existir ningún proceso de inventario
abierto
vii. Poscondiciones
El Sistema creó y guardó una nueva Cuenta contable con el presupuesto asignado para
el año fiscal en curso, y para cada uno de los centros asociados
i. Descripción
Permite al Coordinador de Suministros, consultar toda la información relacionada con una Cuenta
contable seleccionada previamente por él.
Coordinador de Suministros
v. Requerimientos Especiales
vi. Precondiciones
Para poder consultar los datos de una Cuenta contable, el Coordinador de Suministros,
debe haber seleccionado, o ingresado el código de la cuenta contable que quiere
consultar.
Para poder consultar los datos de la Cuenta contable en cuestión, esta debe estar
registrada en el Sistema.
Para ingresar una nueva cuenta al sistema, no debe existir ningún proceso de inventario
abierto
vii. Poscondiciones
i. Descripción
Permite al Coordinador de Suministros, consultar el total de gastos para una Cuenta contable,
durante un período o una fecha seleccionada por él.
el período establecido. El Sistema muestra un mensaje indicando que no hay gastos para
mostrar.
v. Requerimientos Especiales
vi. Precondiciones
Para poder consultar los gastos de una Cuenta contable, el Coordinador de Suministros,
debe haber seleccionado, o ingresado el código de la cuenta contable que quiere
consultar.
Para poder consultar los gastos de la Cuenta contable en cuestión, esta debe estar
registrada en el Sistema.
Para ingresar una nueva cuenta al sistema, no debe existir ningún proceso de inventario
abierto
vii. Poscondiciones
i. Descripción
v. Requerimientos Especiales
El sistema debe permitir que la consulta del presupuesto de una cuenta contable, se
realice de forma rápida y sencilla.
vi. Precondiciones
Para poder consultar los gastos de una Cuenta contable, el Coordinador de Suministros,
debe haber seleccionado, o ingresado el código de la cuenta contable que quiere
consultar.
Para poder consultar los gastos de la Cuenta contable en cuestión, esta debe estar
registrada en el Sistema.
Para ingresar una nueva cuenta al sistema, no debe existir ningún proceso de inventario
abierto
vii. Poscondiciones
ID Requerimiento: RF-10
i. Descripción
Permite al Coordinador de Suministros, ver la lista de todas las Cuentas contables existentes en
el Sistema
9 Coordinador de Suministros
v. Requerimientos Especiales
El sistema debe permitir que la búsqueda de las Cuentas contables, se realice de forma
rápida y sencilla.
vi. Precondiciones
Para poder listar todas las Cuentas contables, el Coordinador de Suministros debe estar
conectado al Sistema.
Para ingresar una nueva cuenta al sistema, no debe existir ningún proceso de inventario
abierto
vii. Poscondiciones
El Sistema listó al Coordinador de Suministros, todas las Cuentas contables que están
registradas.
i. Descripción
v. Requerimientos Especiales
El sistema debe permitir que la búsqueda de las Cuentas contables, se realice de forma
rápida y sencilla.
vi. Precondiciones
Para poder listar todas las Cuentas contables, el Coordinador de Suministros debe estar
conectado al Sistema.
Para ingresar una nueva cuenta al sistema, no debe existir ningún proceso de inventario
abierto
vii. Poscondiciones
i. Descripción
v. Requerimientos Especiales
El sistema debe permitir que la distribución del presupuesto, se realice de forma rápida y
sencilla.
vi. Precondiciones
Para poder distribuir el presupuesto general entre las cuentas contables, el usuario debe
haber iniciado sesión en el Sistema.
Para ingresar una nueva cuenta al sistema, no debe existir ningún proceso de inventario
abierto
vii. Poscondiciones
i. Descripción
Permite al usuario, ver la lista de todas las Cuentas por pagar existentes en el Sistema.
v. Requerimientos Especiales
El sistema debe permitir que la búsqueda de las Cuentas por pagar, se realice de forma
rápida y sencilla.
vi. Precondiciones
Para poder listar todas las Cuentas por pagar, el Actor debe haber iniciado sesión en el
Sistema.
vii. Poscondiciones
El Sistema listó al Actor, todas las Cuentas por pagar que están registradas.
Para ingresar una nueva cuenta al sistema, no debe existir ningún proceso de inventario
abierto
i. Descripción
Permite al usuario, ver la lista de todas las Cuentas por pagar existentes en el Sistema que se
hayan generado por un insumo seleccionado.
v. Requerimientos Especiales
El sistema debe permitir que la búsqueda de las Cuentas por pagar, se realice de forma
rápida y sencilla.
vi. Precondiciones
Para poder listar todas las Cuentas por pagar, el Actor debe estar conectado al Sistema.
Para poder listar todas las Cuentas por pagar, el insumo seleccionado debe estar activo
en el Sistema.
Para ingresar una nueva cuenta al sistema, no debe existir ningún proceso de inventario
abierto
vii. Poscondiciones
El Sistema listó al Coordinador de Suministros, todas las Cuentas por pagar registradas y
asociadas al insumo seleccionado.
i. Descripción
Permite ver la lista de todas las Cuentas por pagar existentes en el Sistema que se hayan
generado para un proveedor seleccionado.
v. Requerimientos Especiales
El sistema debe permitir que la búsqueda de las Cuentas por pagar, se realice de forma
rápida y sencilla.
vi. Precondiciones
Para poder listar todas las Cuentas por pagar, el Actor debe estar conectado al Sistema.
El Actor, debe seleccionar el proveedor sobre el cual se hará la consulta, para poder listar
las Cuentas por pagar asociadas
Para poder listar todas las Cuentas por pagar, el proveedor seleccionado debe estar
activo en el Sistema.
Para ingresar una nueva cuenta al sistema, no debe existir ningún proceso de inventario
abierto
vii. Poscondiciones
El Sistema listó todas las Cuentas por pagar registradas y asociadas al proveedor
seleccionado
i. Descripción
Permite ver la lista de todas las Cuentas por pagar existentes en el Sistema que se hayan
generado para un Centro de Costo seleccionado.
No hay Cuentas por pagar asociadas al Centro de Costo seleccionado. El Sistema muestra
un mensaje indicando que no hay Cuentas por pagar por mostrar
v. Requerimientos Especiales
El sistema debe permitir que la búsqueda de las Cuentas por pagar, se realice de forma
rápida y sencilla.
vi. Precondiciones
Para poder listar todas las Cuentas por pagar, el Actor debe haber estar conectado al
Sistema.
Para poder listar todas las Cuentas por pagar, el Centro de Costo seleccionado debe estar
activo en el Sistema.
Para ingresar una nueva cuenta al sistema, no debe existir ningún proceso de inventario
abierto
vii. Poscondiciones
El Sistema listó al Actor, todas las Cuentas por pagar registradas y asociadas al Centro de
Costo seleccionado
i. Descripción
Permite ver la lista de todas las Cuentas por pagar existentes en el Sistema que se hayan
generado en un período seleccionado.
v. Requerimientos Especiales
El sistema debe permitir que la búsqueda de las Cuentas por pagar, se realice de forma
rápida y sencilla.
vi. Precondiciones
Para poder listar todas las Cuentas por pagar, el Actor debe estar conectado al Sistema.
Para ingresar una nueva cuenta al sistema, no debe existir ningún proceso de inventario
abierto
vii. Poscondiciones
El Sistema listó al Actor, todas las Cuentas por pagar registradas y asociadas al período
seleccionado
i. Descripción
Permite ver el monto en Bolívares de todas las Cuentas por pagar existentes en el Sistema.
No hay Cuentas por pagar existentes. El Sistema muestra un mensaje indicando que no
hay Cuentas por pagar por mostrar
v. Requerimientos Especiales
El sistema debe permitir que la búsqueda de las Cuentas por pagar, se realice de forma
rápida y sencilla.
vi. Precondiciones
Para poder listar todas las Cuentas por pagar, el Actor debe haber iniciado sesión en el
Sistema.
Para ingresar una nueva cuenta al sistema, no debe existir ningún proceso de inventario
abierto
vii. Poscondiciones
El Sistema listó al Actor, el monto total en Bolívares de todas las Cuentas por pagar
registradas en el Sistema
Listar todas las Cuentas por pagar por Cuenta Contable Afectada
i. Descripción
Permite al usuario, ver la lista de todas las Cuentas por pagar existentes en el Sistema que
afecten a una Cuenta Contable seleccionada.
v. Requerimientos Especiales
El sistema debe permitir que la búsqueda de las Cuentas por pagar, se realice de forma
rápida y sencilla.
vi. Precondiciones
Para poder listar todas las Cuentas por pagar, el Actor debe estar conectado al Sistema.
Para ingresar una nueva cuenta al sistema, no debe existir ningún proceso de inventario
abierto
vii. Poscondiciones
El Sistema listó al Actor, todas las Cuentas por pagar registradas y asociadas a la Cuenta
Contable seleccionada
Permite al Coordinador de Suministros, distribuir los insumos o los gastos que se tienen en una
nota de recibo, entre los Centros de costo que tienen pedidos internos sin ser despachados, y
cuyos insumos solicitados sean los que están en la nota.
v. Flujo de Eventos
- Código inválido
El sistema debe permitir que la distribución de gastos y/o insumos, se realice de forma
rápida y sencilla.
viii. Precondiciones
Para poder distribuir los gastos y/o insumos de una nota de recibo entre los centros de
costo, el usuario debe haber iniciado sesión en el Sistema.
ix. Poscondiciones
El Sistema distribuyó satisfactoriamente al actor, todos los gastos y/o insumos de una
nota de recibo entre los centros de costo.
v. Flujo de Eventos
código asociado
- Código inválido
El actor seleccionó una nota, a quien no se le ha hecho una distribución de los insumos
y/o gastos. El Sistema muestra un mensaje de error.
viii. Precondiciones
Para poder consultar la distribución de los gastos y/o insumos de una nota de recibo,
entre los centros de costo, el usuario debe haber iniciado sesión en el Sistema.
ix. Poscondiciones
Permite al Coordinador de Suministros crear una nueva Devolución dentro del sistema
v. Flujo de Eventos
El sistema debe permitir que el registro de una devolución, se realice de forma rápida y
sencilla.
© CENTROBECO, C.A. 2007 Departamento de Sistemas Página 85
Sistema de Orden de Compras, Despacho e Inventario Versión: 3.0
de Suministros, Activos y Servicios Fecha: 08/06/2007
SOCDISAS
Especificación de Requerimientos de Software
viii. Precondiciones
Para poder agregar una nueva Devolución, el Coordinador de Suministros debe haber
iniciado sesión en el Sistema.
ix. Poscondiciones
v. Flujo de Eventos
viii. Precondiciones
Para poder actualizar una Devolución, el Coordinador de Suministros debe haber iniciado
sesión en el Sistema.
Para poder consultar los datos de una Devolución, el Coordinador de Suministros, debe
haber seleccionado la Devolución que quiere consultar.
ix. Poscondiciones
v. Flujo de Eventos
1. Selecciona la Devolución
El sistema debe permitir que la anulación de una Devolución, se realice de forma rápida y
sencilla.
vii. Precondiciones
Para poder consultar los datos de una Devolución, el Coordinador de Suministros, debe
haber seleccionado la Devolución que quiere consultar.
viii. Poscondiciones
v. Flujo de Eventos
vii. Precondiciones
Para poder restaurar una Devolución anulada, el Coordinador de Suministros debe haber
iniciado sesión en el Sistema.
Para poder consultar los datos de una Devolución, el Coordinador de Suministros, debe
haber seleccionado la Devolución que quiere consultar.
viii. Poscondiciones
v. Flujo de Eventos
1. Selecciona la Devolución
El sistema debe permitir que la anulación de una Devolución, se realice de forma rápida y
sencilla.
vii. Precondiciones
Para poder consultar los datos de una Devolución, el Coordinador de Suministros, debe
haber seleccionado la Devolución que quiere consultar.
viii. Poscondiciones
v. Flujo de Eventos
vii. Precondiciones
Para poder consultar los datos de una Devolución, el Coordinador de Suministros, debe
haber seleccionado la Devolución que quiere consultar.
viii. Poscondiciones
v. Flujo de Eventos
El sistema debe permitir que la búsqueda de las Devoluciones, se realice de forma rápida
y sencilla.
viii. Precondiciones
© CENTROBECO, C.A. 2007 Departamento de Sistemas Página 94
Sistema de Orden de Compras, Despacho e Inventario Versión: 3.0
de Suministros, Activos y Servicios Fecha: 08/06/2007
SOCDISAS
Especificación de Requerimientos de Software
Para poder listar todas las Devoluciones, el Coordinador de Suministros debe haber
iniciado sesión en el Sistema.
ix. Poscondiciones
v. Flujo de Eventos
El sistema debe permitir que la búsqueda de las Devoluciones, se realice de forma rápida
y sencilla.
viii. Precondiciones
Para poder listar todas las Devoluciones, el Coordinador de Suministros debe haber
iniciado sesión en el Sistema.
ix. Poscondiciones
v. Flujo de Eventos
El sistema debe permitir que la búsqueda de las Devoluciones, se realice de forma rápida
y sencilla.
viii. Precondiciones
Para poder listar todas las Devoluciones, el Coordinador de Suministros debe haber
iniciado sesión en el Sistema.
- El Actor debe haber seleccionado una Nota de Recibo de una lista (ver
casos de uso CU-NRE-05, CU-NRE-06, CU-NRE-07, CU-NRE-08, CU-NRE-09,
CU-NRE-10)
ix. Poscondiciones
9 Coordinador de Suministros
v. Flujo de Eventos
El sistema debe permitir que la búsqueda de las Devoluciones, se realice de forma rápida
y sencilla.
viii. Precondiciones
Para poder listar todas las Devoluciones, el Coordinador de Suministros debe haber
iniciado sesión en el Sistema.
- El Actor debe haber seleccionado una línea de una lista de líneas (ver
casos de uso CU-LIN-07)
ix. Poscondiciones
9 Coordinador de Suministros
v. Flujo de Eventos
El sistema debe permitir que la búsqueda de las Devoluciones, se realice de forma rápida
y sencilla.
viii. Precondiciones
Para poder listar todas las Devoluciones, el Coordinador de Suministros debe haber
iniciado sesión en el Sistema.
ix. Poscondiciones
v. Flujo de Eventos
El sistema debe permitir que la búsqueda de las Devoluciones, se realice de forma rápida
y sencilla.
viii. Precondiciones
Para poder listar todas las Devoluciones, el Coordinador de Suministros debe haber
iniciado sesión en el Sistema.
ix. Poscondiciones
v. Flujo de Eventos
© CENTROBECO, C.A. 2007 Departamento de Sistemas Página 102
Sistema de Orden de Compras, Despacho e Inventario Versión: 3.0
de Suministros, Activos y Servicios Fecha: 08/06/2007
SOCDISAS
Especificación de Requerimientos de Software
El sistema debe permitir que la búsqueda de las Devoluciones, se realice de forma rápida
y sencilla.
viii. Precondiciones
Para poder listar todas las Devoluciones, el Coordinador de Suministros debe haber
iniciado sesión en el Sistema.
ix. Poscondiciones
i. Descripción
Cuando se emite una nueva nota de recibo, se emite una nueva factura asociada, almacenando
los datos de la factura impresa enviada por el proveedor
v. Requerimientos Especiales
El sistema debe permitir que el registro de una Factura, se realice de forma rápida y
sencilla.
vi. Precondiciones
Para poder agregar una nueva Factura, el usuario debe haber iniciado sesión en el
Sistema.
- El usuario debe iniciar el caso de uso Emitir una nota de Recibo (ver
CU-NRE-01)
Para poder ingresar una nueva factura, el usuario deberá emitir siempre una nota de
recibo.
Para ingresar una nueva cuenta al sistema, no debe existir ningún proceso de inventario
abierto
vii. Poscondiciones
i. Descripción
El usuario cambia los datos de una factura, al modificar los de la nota de recibo asociada
v. Requerimientos Especiales
El sistema debe permitir que la actualización de la Factura en cuestión, se realice de forma rápida
© CENTROBECO, C.A. 2007 Departamento de Sistemas Página 106
Sistema de Orden de Compras, Despacho e Inventario Versión: 3.0
de Suministros, Activos y Servicios Fecha: 08/06/2007
SOCDISAS
Especificación de Requerimientos de Software
y sencilla.
vi. Precondiciones
Para poder actualizar una Factura, el usuario debe haber iniciado sesión en el Sistema.
Para modificar una factura, hay que modificar la nota de recibo asociada
Para ingresar una nueva cuenta al sistema, no debe existir ningún proceso de inventario
abierto
vii. Poscondiciones
i. Descripción
Permite que el usuario, pueda ver los datos de una factura seleccionada previamente por él
v. Requerimientos Especiales
vi. Precondiciones
Para poder consultar los datos de una Factura, el actor debe haber seleccionado la
Factura que quiere consultar.
Para poder consultar los datos la Factura seleccionada, el Actor debe haber iniciado
sesión en el Sistema.
Para ingresar una nueva cuenta al sistema, no debe existir ningún proceso de inventario
abierto
vii. Poscondiciones
El Sistema mostró al Actor, todos los datos relacionados con la Factura especificada.
i. Descripción
v. Requerimientos Especiales
El sistema debe permitir que la búsqueda de las Facturas, se realice de forma rápida y
sencilla.
© CENTROBECO, C.A. 2007 Departamento de Sistemas Página 109
Sistema de Orden de Compras, Despacho e Inventario Versión: 3.0
de Suministros, Activos y Servicios Fecha: 08/06/2007
SOCDISAS
Especificación de Requerimientos de Software
vi. Precondiciones
Para poder listar todas las Facturas, el Actor debe haber iniciado sesión en el Sistema.
Para ingresar una nueva cuenta al sistema, no debe existir ningún proceso de inventario
abierto
vii. Poscondiciones
i. Descripción
Permite al usuario, ver la lista de todas las Facturas existentes en el Sistema que se hayan
recibido de un proveedor seleccionado.
v. Requerimientos Especiales
El sistema debe permitir que la búsqueda de las Facturas, se realice de forma rápida y
sencilla.
vi. Precondiciones
Para poder listar todas las Facturas, el Actor debe haber iniciado sesión en el Sistema.
Para ingresar una nueva cuenta al sistema, no debe existir ningún proceso de inventario
abierto
vii. Poscondiciones
© CENTROBECO, C.A. 2007 Departamento de Sistemas Página 111
Sistema de Orden de Compras, Despacho e Inventario Versión: 3.0
de Suministros, Activos y Servicios Fecha: 08/06/2007
SOCDISAS
Especificación de Requerimientos de Software
i. Descripción
Permite al usuario, ver la lista de todas las Facturas existentes en el Sistema que afecten a una
Orden de Compra seleccionada.
v. Requerimientos Especiales
El sistema debe permitir que la búsqueda de las Facturas, se realice de forma rápida y
sencilla.
vi. Precondiciones
Para poder listar todas las Facturas, el Actor debe haber iniciado sesión en el Sistema.
Para ingresar una nueva cuenta al sistema, no debe existir ningún proceso de inventario
abierto
vii. Poscondiciones
El Sistema listó al Actor, todas las Facturas registradas y asociadas a la Orden de Compra
seleccionada
i. Descripción
Permite al usuario, ver la lista de todas las Facturas existentes en el Sistema que
contengan artículos de la línea seleccionada.
v. Requerimientos Especiales
El sistema debe permitir que la búsqueda de las Facturas, se realice de forma rápida y
sencilla.
vi. Precondiciones
Para poder listar todas las Facturas, el Actor debe haber iniciado sesión en el Sistema.
© CENTROBECO, C.A. 2007 Departamento de Sistemas Página 114
Sistema de Orden de Compras, Despacho e Inventario Versión: 3.0
de Suministros, Activos y Servicios Fecha: 08/06/2007
SOCDISAS
Especificación de Requerimientos de Software
- El Actor debe haber seleccionado una línea de una lista de líneas (ver
caso de uso CU-LIN-07) o introducir el código de una línea
El Actor, debe seleccionar previamente la línea sobre la cual se hará la consulta, para
poder listar las Facturas asociadas
Para ingresar una nueva cuenta al sistema, no debe existir ningún proceso de inventario
abierto
vii. Poscondiciones
i. Descripción
Permite al usuario, ver la lista de todas las Facturas existentes en el Sistema que contengan el
insumo seleccionado.
v. Requerimientos Especiales
El sistema debe permitir que la búsqueda de las Facturas, se realice de forma rápida y
sencilla.
vi. Precondiciones
Para poder listar todas las Facturas, el Actor debe haber iniciado sesión en el Sistema.
El Actor, debe seleccionar previamente el insumo sobre el cual se hará la consulta, para
poder listar las Facturas asociadas
Para ingresar una nueva cuenta al sistema, no debe existir ningún proceso de inventario
abierto
vii. Poscondiciones
i. Descripción
Permite al usuario, ver la lista de todas las Facturas existentes en el Sistema que se
hayan emitido dentro del período seleccionado
v. Requerimientos Especiales
© CENTROBECO, C.A. 2007 Departamento de Sistemas Página 117
Sistema de Orden de Compras, Despacho e Inventario Versión: 3.0
de Suministros, Activos y Servicios Fecha: 08/06/2007
SOCDISAS
Especificación de Requerimientos de Software
El sistema debe permitir que la búsqueda de las Facturas, se realice de forma rápida y
sencilla.
vi. Precondiciones
Para poder listar todas las Facturas, el Actor debe haber iniciado sesión en el Sistema.
Para ingresar una nueva cuenta al sistema, no debe existir ningún proceso de inventario
abierto
vii. Poscondiciones
El Sistema listó al usuario, todas las Facturas registradas y que se hayan emitido dentro
del rango de fecha seleccionado
v. Flujo de Eventos
El sistema debe permitir que el registro de una Factura Interna, se realice de forma
rápida y sencilla.
viii. Precondiciones
Para poder agregar una nueva Factura Interna, el usuario debe haber iniciado sesión en
el Sistema.
ix. Poscondiciones
v. Flujo de Eventos
viii. Precondiciones
Para poder actualizar una Factura Interna, el Coordinador de Suministros debe haber
iniciado sesión en el Sistema.
El Coordinador de Suministros debe haber seleccionado una Factura Interna de una lista,
o bien haber ingresado directamente el código asociado
ix. Poscondiciones
Permite al usuario, consultar toda la información de una Factura Interna emitida anteriormente.
v. Flujo de Eventos
viii. Precondiciones
Para poder consultar los datos la Factura Interna seleccionada, el Actor debe haber
iniciado sesión en el Sistema.
Para poder consultar los datos de una Factura Interna, el actor debe haber seleccionado
la Factura Interna que quiere consultar de una lista, o haber ingresado manualmente el
código asociado.
ix. Poscondiciones
El Sistema mostró al Actor, todos los datos relacionados con la Factura Interna
especificada.
Permite al usuario, ver la lista de todas las Facturas Internas existentes en el Sistema.
v. Flujo de Eventos
El Sistema muestra un mensaje indicando que no hay Facturas Internas por mostrar
El sistema debe permitir que la búsqueda de las Facturas Internas, se realice de forma
rápida y sencilla.
viii. Precondiciones
Para poder listar todas las Facturas Internas, el Actor debe haber iniciado sesión en el
Sistema.
ix. Poscondiciones
iii. Descripción
Permite al usuario, ver la lista de todas las Facturas Internas existentes en el Sistema, que
contengan insumos pertenecientes a la línea seleccionada previamente por él
v. Flujo de Eventos
No hay Facturas almacenadas para dicha línea. El Sistema muestra un mensaje indicando
que no hay Facturas Internas por mostrar
El Actor ingresó un código de líneas no válido, o que corresponde a una línea de insumos
anulada. El Sistema muestra un mensaje de error y no procesa la solicitud.
El sistema debe permitir que la búsqueda de las Facturas Internas, se realice de forma
rápida y sencilla.
viii. Precondiciones
Para poder listar todas las Facturas Internas, el Actor debe haber iniciado sesión en el
Sistema.
Para poder listar todas las Facturas Internas, se debe escoger una línea.
Para poder listar todas las Facturas Internas, la línea de insumos seleccionada por el
Actor, debe estar activa en el sistema.
ix. Poscondiciones
El Sistema listó al Actor, todas las Facturas Internas registradas, con productos que pertenecen a
la línea seleccionada.
Permite al usuario, ver la lista de todas las Facturas Internas existentes en el Sistema, que
contengan el insumo seleccionado previamente por él.
v. Flujo de Eventos
INS-19)
El sistema debe permitir que la búsqueda de las Facturas Internas, se realice de forma
rápida y sencilla.
viii. Precondiciones
Para poder listar todas las Facturas Internas, el Actor debe haber iniciado sesión en el
Sistema.
ix. Poscondiciones
El Sistema listó al Actor, todas las Facturas Internas registradas, que contengan el
insumo seleccionado.
Permite al usuario, ver la lista de todas las Facturas Internas existentes en el Sistema, que
contengan insumos guardados físicamente en el almacén seleccionado por él
v. Flujo de Eventos
El sistema debe permitir que la búsqueda de las Facturas Internas, se realice de forma
rápida y sencilla.
© CENTROBECO, C.A. 2007 Departamento de Sistemas Página 128
Sistema de Orden de Compras, Despacho e Inventario Versión: 3.0
de Suministros, Activos y Servicios Fecha: 08/06/2007
SOCDISAS
Especificación de Requerimientos de Software
viii. Precondiciones
Para poder listar todas las Facturas Internas, el Actor debe haber iniciado sesión en el
Sistema.
El usuario debe primero seleccionar el insumo de una lista, o haber ingresado el código
asociado
ix. Poscondiciones
El Sistema listó al Actor, todas las Facturas Internas registradas, que están asociadas al
Almacén seleccionado
Permite al usuario, ver la lista de todas las Facturas Internas existentes en el Sistema, cuyo
monto total esté dentro del rango de costo seleccionado previamente por él.
- Rango no válido
v. Requerimientos Especiales
El sistema debe permitir que la búsqueda de las Facturas Internas, se realice de forma
rápida y sencilla.
vi. Precondiciones
Para poder listar todas las Facturas Internas, el Actor debe haber iniciado sesión en el
Sistema.
Para poder listar todas las Facturas Internas, el rango de costo debe ser válido, es decir,
el costo mínimo no puede superar al costo máximo.
vii. Poscondiciones
El Sistema listó al Actor, todas las Facturas Internas registradas, que cuyo monto está
contemplado en el rango de costo seleccionado
Para el usuario Gerente, solo podrá consultar las facturas internas del Centro de Costo
que él gestiona.
9 Gerente (G)
v. Flujo de Eventos
El sistema debe permitir que la búsqueda de las Facturas Internas, se realice de forma
rápida y sencilla.
viii. Precondiciones
Para poder listar todas las Facturas Internas, el Actor debe haber iniciado sesión en el
Sistema.
Para listar las facturas respectivas, el Centro de Costo sobre el cual se hará la consulta,
debe estar seleccionado de una lista de centros de costo, o ingresar el código
correspondiente. Para el actor gerente, solo podrá ver las facturas internas de su Centro
de Costo.
Para poder listar todas las Facturas Internas, el Centro de costo debe estar activo en el
Sistema
ix. Poscondiciones
El Sistema listó al Coordinador de Suministros, todas las Facturas Internas registradas, que están
asociadas al Centro de costo seleccionado
El Sistema listó al Gerente, todas las Facturas Internas registradas del Centro de costo que dirige.
Permite al usuario, ver la lista de todas las Facturas Internas existentes en el Sistema,
cuya fecha de facturación, esté dentro del rango seleccionado previamente por él, o haya sido
© CENTROBECO, C.A. 2007 Departamento de Sistemas Página 132
Sistema de Orden de Compras, Despacho e Inventario Versión: 3.0
de Suministros, Activos y Servicios Fecha: 08/06/2007
SOCDISAS
Especificación de Requerimientos de Software
v. Flujo de Eventos
- Rango no válido
El sistema debe permitir que la búsqueda de las Facturas Internas, se realice de forma
rápida y sencilla.
viii. Precondiciones
Para poder listar todas las Facturas Internas, el Actor debe haber iniciado sesión en el
Sistema.
Para poder listar todas las Facturas Internas, el rango de costo debe ser válido, es decir,
la fecha de inicio no puede superar a la fecha tope del rango.
ix. Poscondiciones
El Sistema listó al Actor, todas las Facturas Internas registradas, que han sido facturadas
durante el período seleccionado
9 Gerente (G)
v. Flujo de Eventos
El sistema debe permitir que la búsqueda de las Facturas Internas, se realice de forma
rápida y sencilla.
viii. Precondiciones
Para poder listar todas las Facturas Internas, el Actor debe haber iniciado sesión en el
Sistema.
Para listar las facturas respectivas, el Centro de Costo sobre el cual se hará la consulta, y
el insumo, deben estar seleccionados.
Para listar las facturas respectivas, el actor debe seleccionar primero un insumo
determinado.
Para poder listar todas las Facturas Internas, el Centro de costo y el insumo deben estar
activos en el Sistema.
Para poder listar todas las Facturas Internas, el insumo debe estar activo en el Sistema.
ix. Poscondiciones
El Sistema listó al Gerente, todas las Facturas Internas registradas del Centro de costo
que dirige, que contengan el insumo seleccionado.
Listar todas las Facturas Internas por Centro de costo y por Fecha
de facturación
i. ID Caso de uso: CU-FAI-12
ii. Requerimiento: RF-18
© CENTROBECO, C.A. 2007 Departamento de Sistemas Página 136
Sistema de Orden de Compras, Despacho e Inventario Versión: 3.0
de Suministros, Activos y Servicios Fecha: 08/06/2007
SOCDISAS
Especificación de Requerimientos de Software
iii. Descripción
9 Gerente (G)
v. Flujo de Eventos
No hay Facturas almacenadas para dicho Centro de Costo despachadas en ese rango. El
Sistema muestra un mensaje indicando que no hay Facturas Internas por mostrar
El sistema debe permitir que la búsqueda de las Facturas Internas, se realice de forma
rápida y sencilla.
viii. Precondiciones
Para poder listar todas las Facturas Internas, el Actor debe haber iniciado sesión en el
Sistema.
Para listar las facturas respectivas, el Centro de Costo sobre el cual se hará la consulta, y
el rango, deben estar seleccionados.
Para listar las facturas respectivas, el actor debe seleccionar primero un rango para
poder realizar la búsqueda.
Para poder listar todas las Facturas Internas, el Centro de costo y el insumo deben estar
activos en el Sistema.
Para poder listar todas las Facturas Internas, el período escogido debe ser válido, es
ix. Poscondiciones
El Sistema listó al Gerente, todas las Facturas Internas registradas dentro del rango
seleccionado, del Centro de costo que dirige.
Agregar un Insumo
i. ID Caso de uso: CU-INS-01
ii. Requerimiento: RF-19
iii. Descripción
v. Flujo de Eventos
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
ix. Poscondiciones
Modificar un Insumo
v. Flujo de Eventos
Actor Sistema
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
El actor debe escoger que insumo desea modificar. Lo puede hacer seleccionando el
Insumo mediante una lista de insumos (ver Casos de Uso del CU-INS-07 al CU-INS-18)
ix. Poscondiciones
Consultar un Insumo
i. ID Caso de uso: CU-INS-03
ii. Requerimiento: RF-19
iii. Descripción
v. Flujo de Eventos
No hay
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
El actor debe escoger que insumo desea consultar. Lo puede hacer seleccionando el
Insumo mediante una lista de insumos (ver casos de uso del CU-INS-07 al CU-INS-18)
ix. Poscondiciones
Anular un Insumo
i. ID Caso de uso: CU-INS-04
ii. Requerimiento: RF-19
iii. Descripción
v. Flujo de Eventos
El sistema debe permitir que la operación de anular un insumo sea rápida y sencilla
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
El actor debe escoger que insumo desea anular. Lo puede hacer seleccionando el Insumo
mediante una lista. (ver Casos de Uso del CU-INS-07 al CU-INS-18 )
ix. Poscondiciones
El sistema anula al insumo, y éste no aparecerá reflejado, al menos que sea recuperado.
Recuperar un Insumo
i. ID Caso de uso: CU-INS-05
ii. Requerimiento: RF-19
iii. Descripción
v. Flujo de Eventos
No hay
El sistema debe permitir que la operación de recuperar un insumo sea rápida y sencilla
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
El actor debe escoger que insumo desea recuperar. Lo puede hacer seleccionando el
Insumo mediante una lista de insumos anulados (ver CU-INS-06)
ix. Poscondiciones
Permite al Coordinador de Suministros listar los insumos que hayan sido anulados anteriormente.
v. Flujo de Eventos
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
ix. Poscondiciones
Permite al Coordinador de Suministros listar todos los insumos que no hayan sido anulados.
9 Coordinador de Suministros
v. Flujo de Eventos
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
ix. Poscondiciones
v. Flujo de Eventos
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
El actor debió de haber escogido las líneas de una lista de líneas de insumos de las
insumos para listar (ver CU-LIN-07)
ix. Poscondiciones
v. Flujo de Eventos
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
El actor debió de haber escogido las líneas de una lista de líneas de insumos de las
insumos para listar (ver Casos de Uso del CU-PRO-07 AL CU-PRO-10)
ix. Poscondiciones
v. Flujo de Eventos
© CENTROBECO, C.A. 2007 Departamento de Sistemas Página 152
Sistema de Orden de Compras, Despacho e Inventario Versión: 3.0
de Suministros, Activos y Servicios Fecha: 08/06/2007
SOCDISAS
Especificación de Requerimientos de Software
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
El actor debió de haber escogido si listar los insumos con existencia mínima, promedio o
máxima
ix. Poscondiciones
v. Flujo de Eventos
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
El actor debió de haber escogido si listar los insumos con procedencia nacional o
importada
ix. Poscondiciones
v. Flujo de Eventos
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
El actor debió de haber escogido el estado posible de insumos de una lista desplegable
ix. Poscondiciones
Permite al Coordinador de Suministros listar los insumos no anulados, por mayor, menor
o demanda promedia
v. Flujo de Eventos
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
El actor debió de haber escogido verlos insumos de mayor, menor o demanda promedia
de una lista desplegable
ix. Poscondiciones
v. Flujo de Eventos
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
El actor debió de haber escogido una talla para listar los insumos
ix. Poscondiciones
v. Flujo de Eventos
Actor Sistema
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
El actor debió de haber seleccionado de una lista de almacenes, aquéllos donde quiera
ver los insumos que tienen. (ver CU-ALM-07 al CU-ALM-09)
ix. Poscondiciones
Permite al Coordinador de Suministros listar los insumos no anulados según su fecha de registro
v. Flujo de Eventos
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
El actor debió de haber escogido la fecha, o el rango de fecha para listar los insumos
ix. Poscondiciones
Permite al Coordinador de Suministros listar los insumos no anulados según una cantidad o un
rango de cantidades
v. Flujo de Eventos
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
ix. Poscondiciones
Permite al Coordinador de Suministros listar los insumos no anulados según un precio o un rango
de precios
v. Flujo de Eventos
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
ix. Poscondiciones
Permite al Coordinador de Suministros listar los insumos no anulados que no hayan sido contados
en un proceso de inventario en marcha
v. Flujo de Eventos
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
Este caso de uso estará habilitado solo si hay un proceso de inventario en marcha (ver
CU-INV-01)
- El actor debió haber solicitado ingresar un conteo físico para listar los
insumos no contados en el proceso de inventario
ix. Poscondiciones
v. Flujo de Eventos
No hay
El sistema debe permitir que la operación de actualizar el stock de insumos sea rápida y
sencilla
viii. Precondiciones
El CS emite una devolución (CU-DEV-01), el CS realiza una distribución hacia los Centros
de Costo (CU-DES-01), el AXS o el CS emite una nota de recibo (CU-NRE-01)
ix. Poscondiciones
El sistema anula al insumo, y éste no aparecerá reflejado, al menos que sea recuperado.
v. Flujo de Eventos
NO HAY
El Sistema debe permitir que el inicio del proceso de inventario se realice de forma rápida
y sencilla.
viii. Precondiciones
ix. Poscondiciones
v. Flujo de Eventos
NO HAY
El Sistema debe permitir que el inicio del proceso de inventario se realice de forma rápida
y sencilla.
viii. Precondiciones
Para poder ingresar los resultados del inventario, el Coordinador de Suministros debe
iniciar sesión primero.
Para poder cerrar un proceso de inventario, debe existir un proceso de inventario abierto
ix. Poscondiciones
v. Flujo de Eventos
4. Procesa la información
viii. Precondiciones
Para poder ingresar los resultados del inventario, el actor debe iniciar sesión primero.
Este caso de uso estará habilitado solo si hay un proceso de inventario en marcha (ver
CU-INV-01)
ix. Poscondiciones
inventario, y las diferencias que los insumos presentan con el registro en stock
v. Flujo de Eventos
El sistema debe permitir que la búsqueda de los conteos de insumos, se realice de forma
rápida y sencilla.
viii. Precondiciones
Para poder consultar los conteos realizados en un inventario, el actor debe iniciar sesión
primero.
Este caso de uso estará habilitado solo si hay un proceso de inventario en marcha (ver
CU-INV-01)
ix. Poscondiciones
El Sistema generó un reporte con los resultados de los conteos del inventario
Realizar Ajustes
i. ID Caso de uso: CU-INV-06
ii. Requerimiento: RF-23
iii. Descripción
v. Flujo de Eventos
viii. Precondiciones
Para poder realizar los ajustes, el Coordinador de Suministros debe iniciar sesión primero.
Para poder realizar los ajustes, debe haber un proceso de inventario activo.
Para poder realizar los ajustes, debe haberse realizado al menos un conteo en el
inventario activo.
El actor previamente vio los resultados de un inventario antes de realizar ajustes (Ver
CU-INV-04)
ix. Poscondiciones
El Sistema generó los cambios de acuerdo a los resultados del inventario activo
Permite que el Coordinador de Suministros, o un Analista de Suministros, vean los conteos que
v. Flujo de Eventos
El sistema debe permitir que la búsqueda de los conteos de insumos, se realice de forma
rápida y sencilla.
viii. Precondiciones
Para poder consultar los conteos realizados por el actor, el actor debe iniciar sesión
primero.
Para poder consultar los conteos realizados por el actor, debe haber un inventario
iniciado
ix. Poscondiciones
El Sistema generó un reporte con los resultados de los conteos que el actor realizó
v. Flujo de Eventos
viii. Precondiciones
Para poder eliminar los conteos realizados, el actor debe iniciar sesión primero.
Para poder consultar los conteos realizados por el actor, debe haber un inventario
iniciado
Si el actor es el CS, puede seleccionar los conteos habiendo iniciado el Caso de Uso CU-
INV-06 o CU-INV-04. Si el actor es AS, solo puede seleccionar los conteos del Caso de
Uso CU-INV-06.
ix. Poscondiciones
El Sistema generó un reporte con los resultados de los conteos que el actor realizó
Permite al Coordinador de Suministros, ver una lista de inventarios que se han hecho en la
empresa
v. Flujo de Eventos
© CENTROBECO, C.A. 2007 Departamento de Sistemas Página 177
Sistema de Orden de Compras, Despacho e Inventario Versión: 3.0
de Suministros, Activos y Servicios Fecha: 08/06/2007
SOCDISAS
Especificación de Requerimientos de Software
viii. Precondiciones
Para poder consultar los inventarios, el Coordinador de Suministros debe iniciar sesión
primero.
Para poder ver inventarios anteriores, no debe haber un proceso de inventario activo.
ix. Poscondiciones
v. Flujo de Eventos
viii. Precondiciones
Para poder consultar los inventarios, el Coordinador de Suministros debe iniciar sesión
primero.
Para poder ver los ajustes de inventarios anteriores, se debe seleccionar un inventario de
Para poder ver los ajustes de inventarios anteriores, no debe haber un proceso de
inventario activo.
ix. Poscondiciones
v. Flujo de Eventos
4. Procesa la información
El sistema debe permitir que el registro de una línea de insumos sea rápida y sencilla
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
ix. Poscondiciones
v. Flujo de Eventos
No hay
El sistema debe permitir que el la consulta de una línea de insumos sea rápida y sencilla
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
El actor debe escoger que línea desea consultar. Lo puede hacer seleccionando la línea
mediante una lista de líneas de insumos, (ver CU-LIN-07)
ix. Poscondiciones
9 Coordinador de Suministros
v. Flujo de Eventos
Actor Sistema
4. Procesa la información
El sistema debe permitir que el registro de una línea de insumos sea rápido y sencillo
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
El actor debe escoger que línea desea modificar. Lo puede hacer seleccionando la línea
mediante una lista de líneas de insumos, (ver CU-LIN-07)
ix. Poscondiciones
v. Flujo de Eventos
No Hay
El sistema debe permitir que la operación de anular una línea de insumos sea rápida y
sencilla
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
El actor debe escoger que línea desea anular. Lo puede hacer seleccionando la línea
mediante una lista, (ver CU-LIN-07)
Para poder anular una línea, ningún insumo debe estar relacionado a ésta.
ix. Poscondiciones
El sistema anula la línea de insumos, y ésta no aparecerá reflejada, al menos que sea
recuperada.
Permite al Coordinador de Suministros recuperar una línea de insumos que haya sido anulada
anteriormente.
v. Flujo de Eventos
Actor Sistema
No hay
El sistema debe permitir que la operación de recuperar una línea de insumos sea rápida y
sencilla
viii. Precondiciones
© CENTROBECO, C.A. 2007 Departamento de Sistemas Página 186
Sistema de Orden de Compras, Despacho e Inventario Versión: 3.0
de Suministros, Activos y Servicios Fecha: 08/06/2007
SOCDISAS
Especificación de Requerimientos de Software
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
El actor debe escoger que línea desea recuperar. Lo puede hacer seleccionando la línea
mediante una lista de líneas de insumos anuladas (ver CU-LIN-06).
ix. Poscondiciones
Permite al Coordinador de Suministros listar las líneas de insumos que hayan sido anuladas
anteriormente.
v. Flujo de Eventos
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
ix. Poscondiciones
9 Gerente (GS)
9 Colaborador (C)
v. Flujo de Eventos
El sistema muestra un mensaje indicando que no existen líneas de insumos para listar
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
ix. Poscondiciones
Agregar un Usuario
i. ID Caso de uso: CU-MUS-01
ii. Requerimiento: RF-25
iii. Descripción
v. Flujo de Eventos
sistema
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
ix. Poscondiciones
Consultar un Usuario
i. ID Caso de uso: CU-MUS-02
ii. Requerimiento: RF-27
iii. Descripción
© CENTROBECO, C.A. 2007 Departamento de Sistemas Página 191
Sistema de Orden de Compras, Despacho e Inventario Versión: 3.0
de Suministros, Activos y Servicios Fecha: 08/06/2007
SOCDISAS
Especificación de Requerimientos de Software
v. Flujo de Eventos
No Hay
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
El actor debe escoger que usuario desea consultar. Lo puede hacer seleccionando el
Usuario mediante una lista, (ver CU-MUS-07 y 08)
ix. Poscondiciones
Anular un Usuario
i. ID Caso de uso: CU-MUS-03
ii. Requerimiento: RF-26
iii. Descripción
v. Flujo de Eventos
Actor Sistema
No hay
El sistema debe permitir que la operación de anular un usuario sea rápida y sencilla
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
El actor debe escoger que usuario desea anular. Lo puede hacer seleccionando el Usuario
mediante una lista, (ver CU-MUS-07 y 08).
ix. Poscondiciones
El sistema anula al usuario, y éste no aparecerá reflejado, al menos que sea recuperado.
Recuperar un Usuario
i. ID Caso de uso: CU-MUS-04
ii. Requerimiento: RF-26
iii. Descripción
v. Flujo de Eventos
No hay
El sistema debe permitir que la operación de recuperar un usuario sea rápida y sencilla
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
El actor debe escoger que usuario desea recuperar. Lo puede hacer seleccionando el
Usuario mediante una lista de usuarios anulados (ver CU-MUS-06).
ix. Poscondiciones
Modificar un Usuario
i. ID Caso de uso: CU-MUS-03
ii. Requerimiento: RF-25
iii. Descripción
v. Flujo de Eventos
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
El actor debe escoger que usuario desea modificar. Lo puede hacer seleccionando el
Usuario mediante una lista de usuarios. (ver CU-MUS-07 y 08)
ix. Poscondiciones
Permite al Coordinador de Suministros listar los usuarios que hayan sido anulados anteriormente.
Coordinador de Suministros
v. Flujo de Eventos
Actor Sistema
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
ix. Poscondiciones
Permite al Coordinador de Suministros listar todos los usuarios que no hayan sido anulados.
v. Flujo de Eventos
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
ix. Poscondiciones
9 Coordinador de Suministros
v. Flujo de Eventos
Actor Sistema
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
ix. Poscondiciones
i. Descripción
Permite al usuario registrar una nueva nota de recibo, asociada a una orden de compra
determinada, junto con su respectiva factura
v. Requerimientos especiales
El sistema debe permitir que el registro de una nota de recibo sea rápido y sencillo
vi. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
Para poder listar todas las notas de recibo, no debe existir ningún proceso de inventario
vii. Poscondiciones
El sistema creó y registró una nueva nota de recibo, con los datos que el usuario emitió
i. Descripción
Permite al usuario modificar una nota de recibo existente en el sistema. Para el Auxiliar
de Suministros, solo podrá modificar una nota que haya sido emitida por él
- Flujo de Eventos
3. Actualiza la información
El usuario ingresó un código que no está asociado a una nota. El sistema muestra un
mensaje de error y no procesa la solicitud
El sistema debe permitir que el registro de una nota de recibo sea rápido y sencillo
v. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
Para poder listar todas las notas de recibo, no debe existir ningún proceso de inventario
abierto (ver caso de uso CU-INV-03)
vi. Poscondiciones
i. Descripción
Permite al usuario ver los datos de una nota de recibo. Para el Auxiliar de Suministros, puede
consultar solo las emitidas por él. Para el actor Personal de Finanzas, solo puede consultar las
notas de recibo pendientes por pagar
v. Requerimientos especiales
El sistema debe permitir que la consulta de una nota de recibo sea rápida y sencilla
vi. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
El usuario debió haber seleccionado la nota de una lista, o haber ingresado el código
asociado
Para poder listar todas las notas de recibo, no debe existir ningún proceso de inventario
abierto (ver caso de uso CU-INV-03)
vii. Poscondiciones
ID Requerimiento: RF-29
i. Descripción
Permite al usuario listar todas las notas de recibo existentes. Cuando el usuario es el Auxiliar de
Suministros, se listan todas las notas de recibo registradas emitidas por él
El sistema muestra un mensaje indicando que no existen notas de recibo para listar
v. Requerimientos especiales
vi. Precondiciones
Para poder listar todas las notas de recibo, no debe existir ningún proceso de inventario
abierto (ver caso de uso CU-INV-03)
vii. Poscondiciones
i. Descripción
Permite al usuario, listar todas las notas de recibo pendientes por pagar existentes.
El sistema muestra un mensaje indicando que no existen notas de recibo para listar
v. Requerimientos especiales
vi. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
Para poder listar todas las notas de recibo, no debe existir ningún proceso de inventario
abierto (ver caso de uso CU-INV-03)
vii. Poscondiciones
i. Descripción
Permite al usuario listar todas las notas de recibo que aún no se han cancelado, para una orden
de compra seleccionada previamente por él
El sistema muestra un mensaje indicando que no existen notas de recibo para listar
v. Requerimientos especiales
vi. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
Para poder listar todas las notas de recibo, no debe existir ningún proceso de inventario
abierto (ver caso de uso CU-INV-03)
vii. Poscondiciones
i. Descripción
Permite al Coordinador de Suministros listar todas las notas de recibo pagadas existentes
Actor Sistema
El sistema muestra un mensaje indicando que no existen notas de recibo para listar
v. Requerimientos especiales
vi. Precondiciones
Para poder listar todas las notas de recibo, no debe existir ningún proceso de inventario
abierto (ver caso de uso CU-INV-03)
vii. Poscondiciones
i. Descripción
Permite al Coordinador de Suministros listar las notas de recibo pagadas, por órdenes de
compra relacionadas.
Actor Sistema
El sistema muestra un mensaje indicando que no existen notas de recibo para listar
v. Requerimientos especiales
vi. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
El usuario debió haber seleccionado la orden de una lista, o bien haber ingresado el
código asociado
Para poder listar todas las notas de recibo, no debe existir ningún proceso de inventario
abierto (ver caso de uso CU-INV-03)
vii. Poscondiciones
compra seleccionada
i. Descripción
Permite al usuario listar todas las notas de recibo existentes, para una orden de compra
seleccionada previamente por él.
9 Auxiliar de Suministros
El sistema muestra un mensaje indicando que no existen notas de recibo para listar
v. Requerimientos especiales
vi. Precondiciones
El usuario debió haber seleccionado la orden de una lista, o haber ingresado el código
asociado
Para poder listar todas las notas de recibo, no debe existir ningún proceso de inventario
abierto (ver caso de uso CU-INV-03)
vii. Poscondiciones
i. Descripción
Permite al Coordinador de Suministros generar una orden de compra a partir de una lista de
insumos
5. Confirma la información
v. Requerimientos especiales
El sistema debe permitir que el registro de una orden de compra sea rápida y sencilla
vi. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
Para poder listar todas las notas de recibo, no debe existir ningún proceso de inventario
abierto (ver caso de uso CU-INV-03)
vii. Poscondiciones
ID Requerimiento: RF-30
i. Descripción
Permite al Coordinador de Suministros generar una orden de compra a partir de una solicitud de
cotización
6. Confirma la Operación
y no procesa la solicitud
v.
vi. Requerimientos especiales
El sistema debe permitir que el registro de una orden de compra sea rápida y sencilla
vii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
El usuario debe primero seleccionar una solicitud de cotización a partir de una lista.
Para poder listar todas las notas de recibo, no debe existir ningún proceso de inventario
abierto (ver caso de uso CU-INV-03)
viii. Poscondiciones
ID Requerimiento: RF-32
i. Descripción
Permite al Usuario ver los datos de una orden de compra. Cuando el Usuario es alguien Personal
de Finanzas, este solo puedo ver aquellas órdenes de compra con adelantos de dinero
9 Personal de Finanzas(PF)
El sistema debe permitir que el la consulta de una orden de compra sea rápida y sencilla
v. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
El usuario debe escoger que orden de compra desea consultar. Lo puede hacer
seleccionando la orden mediante una lista.
Para poder listar todas las notas de recibo, no debe existir ningún proceso de inventario
abierto (ver caso de uso CU-INV-03)
vi. Poscondiciones
ID Requerimiento: RF-31
i. Descripción
3. Confirma la operación
No hay
v. Requerimientos especiales
El sistema debe permitir que la operación de anular una orden de compra sea rápida y
sencilla
vi. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
El actor debe escoger de una lista de órdenes de compra no anuladas, aquella desea
anular.
Para poder listar todas las notas de recibo, no debe existir ningún proceso de inventario
abierto (ver caso de uso CU-INV-03)
vii. Poscondiciones
ID Requerimiento: RF-31
i. Descripción
Permite al Coordinador de Suministros recuperar una orden de compra que haya sido
anulada anteriormente.
3. Confirma la operación
No hay
v. Requerimientos especiales
El sistema debe permitir que la operación de recuperar orden de compra sea rápida y
sencilla
vi. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
El actor debe escoger de la lista de órdenes de compra anuladas, aquella que desea
recuperar.
Para poder listar todas las notas de recibo, no debe existir ningún proceso de inventario
abierto (ver caso de uso CU-INV-03)
© CENTROBECO, C.A. 2007 Departamento de Sistemas Página 223
Sistema de Orden de Compras, Despacho e Inventario Versión: 3.0
de Suministros, Activos y Servicios Fecha: 08/06/2007
SOCDISAS
Especificación de Requerimientos de Software
vii. Poscondiciones
ID Requerimiento: RF-32
i. Descripción
Permite al Coordinador de Suministros listar órdenes de compra que hayan sido anuladas
anteriormente.
v. Requerimientos especiales
vi. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
Para poder listar todas las notas de recibo, no debe existir ningún proceso de inventario
abierto (ver caso de uso CU-INV-03)
vii. Poscondiciones
ID Requerimiento: RF-32
i. Descripción
El sistema muestra un mensaje indicando que no existen órdenes de compra para listar
v. Requerimientos especiales
vi. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
Para poder listar todas las notas de recibo, no debe existir ningún proceso de inventario
abierto (ver caso de uso CU-INV-03)
vii. Poscondiciones
ID Requerimiento: RF-32
i. Descripción
v. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
Para poder listar todas las notas de recibo, no debe existir ningún proceso de inventario
abierto (ver caso de uso CU-INV-03)
vi. Poscondiciones
ID Requerimiento: RF-32
i. Descripción
Permite al usuario listar todas las órdenes de compra registradas, en donde se hayan
ordenado insumos pertenecientes a la línea seleccionada.
El sistema muestra un mensaje indicando que no existen órdenes de compra para listar
v. Requerimientos especiales
vi. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
El actor debió de haber escogido las líneas de una lista de líneas de insumos de las
Para poder listar todas las notas de recibo, no debe existir ningún proceso de inventario
abierto (ver caso de uso CU-INV-03)
vii. Poscondiciones
ID Requerimiento: RF-32
i. Descripción
El sistema muestra un mensaje indicando que no existen órdenes de compra para listar
v. Requerimientos especiales
vi. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
- El usuario debió haber seleccionado el insumo de una lista (ver casos de uso
CU-INS-07 / CU-INS-19), o haber ingresado el código asociado
El actor debió de haber escogido el insumo de una lista, o haber ingresado el código
asociado
Para poder listar todas las notas de recibo, no debe existir ningún proceso de inventario
abierto (ver caso de uso CU-INV-03)
vii. Poscondiciones
ID Requerimiento: RF-32
i. Descripción
Permite al Usuario listar las órdenes de compra relacionada con algún proveedor.
El sistema muestra un mensaje indicando que no existen órdenes de compra para listar
v. Requerimientos especiales
vi. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
Para poder listar todas las notas de recibo, no debe existir ningún proceso de inventario
abierto (ver caso de uso CU-INV-03)
vii. Poscondiciones
ID Requerimiento: RF-32
i. Descripción
El sistema muestra un mensaje indicando que no existen órdenes de compra para listar
v. Requerimientos especiales
vi. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
El actor debió de haber escogido una fecha, o un rango de fechas, para las órdenes de
compra que se desean listar
Para poder listar todas las notas de recibo, no debe existir ningún proceso de inventario
abierto (ver caso de uso CU-INV-03)
vii. Poscondiciones
i. Descripción
El usuario ingresó un código que no está asociado a una orden de compra almacenada.
El sistema muestra un mensaje de error y no procesa la solicitud
v. Requerimientos especiales
El sistema debe permitir que la modificación de los datos de la orden de compra, se haga
de manera rápida y sencilla
vi. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
El usuario debe seleccionar la orden a modificar de una lista, o haber ingresado el código
asociado.
Para poder listar todas las notas de recibo, no debe existir ningún proceso de inventario
abierto (ver caso de uso CU-INV-03)
vii. Poscondiciones
Permite al gerente o colaborador emitir un nuevo pedido interno, que será recibido
posteriormente por el coordinador de suministros
9 Gerente (G)
9 Colaborador (C)
v. Flujo de Eventos
5. Confirma la operación
El sistema debe permitir que la emisión de un pedido interno sea rápida y sencilla
vii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
Para poder listar todas las notas de recibo, no debe existir ningún proceso de inventario
abierto (ver caso de uso CU-INV-03)
viii. Poscondiciones
- Si el usuario es un gerente
- Si el actor es un colaborador
Se emite el pedido interno sin ser aprobado. El gerente podrá ver el pedido interno, y
aprobarlo o anularlo. El coordinador de suministros no podrá ver el pedido interno hasta
que el gerente no lo haya aprobado.
Permite al usuario ver los datos de un pedido interno. Cuando el usuario es el Coordinador de
Suministros, puede consultar los pedidos internos de cualquier centro de costo.
Para el usuario Gerente, permite consultar los pedidos internos del centro de costo que gestiona.
Para el usuario colaborador, permite ver los datos completos de un pedido interno emitido por él
9 Gerente (G)
9 Colaborador (C)
v. Flujo de Eventos
El sistema debe permitir que el la consulta de un pedido interno sea rápida y sencilla
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
El gerente puede consultar todos los pedidos emitidos por los colaboradores del centro
de costo que dirige. Para el Coordinador de Suministros, puede ser un pedido de
cualquier centro de costo
Para poder listar todas las notas de recibo, no debe existir ningún proceso de inventario
abierto (ver caso de uso CU-INV-03)
ix. Poscondiciones
iii. Descripción
Cuando es un usuario tipo Gerente, solo puede anular los pedidos internos emitidos por
colaboradores de su centro de costo
Cuando es un usuario tipo Colaborador, solo puede anular los pedidos emitidos por él
9 Gerente (G)
9 Colaborador (C)
v. Flujo de Eventos
3. Confirma la operación
El sistema debe permitir que la operación de anular un pedido interno sea rápida y
sencilla
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
Para poder listar todas las notas de recibo, no debe existir ningún proceso de inventario
abierto (ver caso de uso CU-INV-03)
Para poder anular un pedido interno, este no puede estar aprobado por su Gerente
inmediato
ix. Poscondiciones
Cuando el usuario es de tipo Gerente, permite aprobar el pedido de un colaborador que labore en
9 Gerente (G)
v. Flujo de Eventos
No hay
El sistema debe permitir que la aprobación de un pedido interno sea rápida y sencilla
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión
Para poder listar todas las notas de recibo, no debe existir ningún proceso de inventario
ix. Poscondiciones
El sistema aprobó el pedido interno y podrá ser visto por el coordinador de suministros
Permite al usuario cambiar los datos que se tienen registrados de un pedido interno. Cuando el
usuario es un Coordinador de Suministros, permite modificar cualquier pedido de cualquier centro
de costo.
Cuando el usuario es de tipo Gerente, solo puede modificar los pedidos de su centro de costo.
Cuando el usuario es un Colaborador, permite actualizar los pedidos internos emitidos por él
9 Gerente (G)
9 Colaborador (C)
v. Flujo de Eventos
El sistema debe permitir que el registro de un pedido interno sea rápido y sencillo
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
Para poder listar todas las notas de recibo, no debe existir ningún proceso de inventario
abierto (ver caso de uso CU-INV-03)
ix. Poscondiciones
Permite al usuario listar todos los pedidos internos existentes. Cuando el usuario es un
Coordinador de Suministros, se listan todos los pedidos registrados
9 Colaborador (C)
v. Flujo de Eventos
El sistema muestra un mensaje indicando que no existen pedidos internos para listar
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
Para poder listar todas las notas de recibo, no debe existir ningún proceso de inventario
abierto (ver caso de uso CU-INV-03)
ix. Poscondiciones
© CENTROBECO, C.A. 2007 Departamento de Sistemas Página 245
Sistema de Orden de Compras, Despacho e Inventario Versión: 3.0
de Suministros, Activos y Servicios Fecha: 08/06/2007
SOCDISAS
Especificación de Requerimientos de Software
v. Flujo de Eventos
El sistema muestra un mensaje indicando que no existen pedidos internos para listar
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
© CENTROBECO, C.A. 2007 Departamento de Sistemas Página 246
Sistema de Orden de Compras, Despacho e Inventario Versión: 3.0
de Suministros, Activos y Servicios Fecha: 08/06/2007
SOCDISAS
Especificación de Requerimientos de Software
Para poder listar todas las notas de recibo, no debe existir ningún proceso de inventario
abierto (ver caso de uso CU-INV-03)
ix. Poscondiciones
Permite al Coordinador de Suministros, listar todos los pedidos internos donde se soliciten
insumos pertenecientes a la línea seleccionada por él
v. Flujo de Eventos
Actor Sistema
El sistema muestra un mensaje indicando que no existen pedidos internos para listar
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
- El usuario debió seleccionar una línea de una lista (ver caso de uso CU-
LIN-07), o ingresar el código asociado
El usuario debe seleccionar la línea de una lista, o bien ingresar el código asociado
Para poder listar todas las notas de recibo, no debe existir ningún proceso de inventario
abierto (ver caso de uso CU-INV-03)
ix. Poscondiciones
v. Flujo de Eventos
El sistema muestra un mensaje indicando que no existen pedidos internos para listar
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
- El usuario debe seleccionar el insumo de una lista (ver casos de uso CU-
INS-07 / CU-INS-19), o ingresar el código asociado
El usuario debe seleccionar un insumo para poder listar los pedidos internos asociados
Para poder listar todas las notas de recibo, no debe existir ningún proceso de inventario
ix. Poscondiciones
Permite al Coordinador de Suministros listar los pedidos internos relacionados con algún Centro
de Costo, y que hayan sido aprobados por el gerente.
Cuando el usuario es un Gerente, se lista únicamente los pedidos internos de su Centro de Costo
9 Coordinador de Suministros
9 Gerente
v. Flujo de Eventos
El sistema muestra un mensaje indicando que no existen pedidos internos para listar
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
El usuario debe primero selecciona el centro de costo sobre el cual se listarán los pedidos
internos
Para poder listar todas las notas de recibo, no debe existir ningún proceso de inventario
abierto (ver caso de uso CU-INV-03)
ix. Poscondiciones
iii. Descripción
Permite al usuario listar todos los pedidos internos emitidos por un centro de costo, y en donde
se solicite el insumo seleccionado previamente por él
También permite al gerente, listar únicamente los pedidos internos de su Centro de Costo
9 Gerente (G)
v. Flujo de Eventos
El sistema muestra un mensaje indicando que no existen pedidos internos para listar
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
Para poder listar todas las notas de recibo, no debe existir ningún proceso de inventario
abierto (ver caso de uso CU-INV-03)
ix. Poscondiciones
9 Gerente (G)
v. Flujo de Eventos
El sistema muestra un mensaje indicando que no existen pedidos internos para listar
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
El actor debió de haber escogido un estado del que quiere ver sus pedidos internos
quiere consultar
Para poder listar todas las notas de recibo, no debe existir ningún proceso de inventario
abierto (ver caso de uso CU-INV-03)
ix. Poscondiciones
El sistema muestra una lista de los pedidos internos del centro de costo seleccionado,
agrupados por estado
El sistema muestra una lista de todos los pedidos interno del centro de costo que
gestiona, agrupados por estado
Permite al usuario listar los pedidos internos de un centro de costo, donde se soliciten insumos
de la línea seleccionada previamente por él. Cuando el usuario es un Coordinador de Suministros,
se listan los pedidos de un centro de costo seleccionado previamente por él.
Cuando el usuario es un Gerente, se listan los pedidos internos de su centro de costo, en donde
se soliciten insumos de una línea seleccionada por él
9 Gerente (G)
v. Flujo de Eventos
El sistema muestra un mensaje indicando que no existen pedidos internos para listar
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
Para poder listar todas las notas de recibo, no debe existir ningún proceso de inventario
abierto (ver caso de uso CU-INV-03)
ix. Poscondiciones
Permite al gerente listar los pedidos internos emitidos por un usuario, que labore en su
centro de costo.
9 Gerente (G)
v. Flujo de Eventos
El sistema muestra un mensaje indicando que no existen pedidos internos para listar
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
Para poder listar los pedidos internos, es necesario que se seleccione el usuario sobre el
cual se hará la consulta
Para poder listar todas las notas de recibo, no debe existir ningún proceso de inventario
abierto (ver caso de uso CU-INV-03)
ix. Poscondiciones
El sistema muestra los pedidos internos que hayan sido emitidos por el usuario
seleccionado
9 Gerente (G)
v. Flujo de Eventos
El sistema muestra un mensaje indicando que no existen pedidos internos para listar
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
Para poder listar todas las notas de recibo, no debe existir ningún proceso de inventario
abierto (ver caso de uso CU-INV-03)
© CENTROBECO, C.A. 2007 Departamento de Sistemas Página 259
Sistema de Orden de Compras, Despacho e Inventario Versión: 3.0
de Suministros, Activos y Servicios Fecha: 08/06/2007
SOCDISAS
Especificación de Requerimientos de Software
ix. Poscondiciones
Agregar un Proveedor
i. ID Caso de uso: CU-PRO-01
ii. Requerimiento: RF-37
iii. Descripción
v. Flujo de Eventos
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
ix. Poscondiciones
Consultar un Proveedor
i. ID Caso de uso: CU-PRO-02
v. Flujo de Eventos
No hay
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
El actor debe escoger que proveedor desea consultar. Lo puede hacer seleccionando el
Proveedor mediante una lista de proveedores, (ver CU-PRO-07 al 10)
ix. Poscondiciones
Anular un Proveedor
i. ID Caso de uso: CU-PRO-03
ii. Requerimiento: RF-39
iii. Descripción
9 Coordinador de Suministros
v. Flujo de Eventos
Actor Sistema
No hay
El sistema debe permitir que la operación de anular un proveedor sea rápida y sencilla
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
El actor debe escoger que proveedor desea anular. Lo puede hacer seleccionando el
Proveedor mediante una lista de proveedores (ver CU-PRO-07 al 10)
Para poder anular un proveedor, ningún insumo debe estar relacionado a ésta.
ix. Poscondiciones
Recuperar un Proveedor
i. ID Caso de uso: CU-PRO-04
ii. Requerimiento: RF-39
iii. Descripción
9 Coordinador de Suministros
v. Flujo de Eventos
Actor Sistema
No hay
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
El actor debe escoger que proveedor desea recuperar. Lo puede hacer seleccionando el
Proveedor mediante una lista de proveedores anulados.
ix. Poscondiciones
Modificar un Proveedor
i. ID Caso de uso: CU-PRO-05
ii. Requerimiento: RF-37
iii. Descripción
9 Coordinador de Suministros
v. Flujo de Eventos
Actor Sistema
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
El actor debe escoger que proveedor desea anular. Lo puede hacer seleccionando el
Proveedor mediante una lista de proveedores (ver CU-PRO-07 al 10)
ix. Poscondiciones
Permite al Coordinador de Suministros listar los proveedores que hayan sido anulados
anteriormente.
v. Flujo de Eventos
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
ix. Poscondiciones
Permite al Coordinador de Suministros listar todos los proveedores que no hayan sido anulados.
v. Flujo de Eventos
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
ix. Poscondiciones
Permite al Coordinador de Suministros listar los proveedores relacionada con alguna(s) línea(s)
de insumos.
© CENTROBECO, C.A. 2007 Departamento de Sistemas Página 269
Sistema de Orden de Compras, Despacho e Inventario Versión: 3.0
de Suministros, Activos y Servicios Fecha: 08/06/2007
SOCDISAS
Especificación de Requerimientos de Software
v. Flujo de Eventos
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
El actor debió de haber escogido las líneas de una lista de líneas de insumos de las
proveedores para listar(ver CU-LIN-07)
ix. Poscondiciones
9 Coordinador de Suministros
v. Flujo de Eventos
Actor Sistema
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
El actor debió de haber escogido los insumos de una lista de insumos de los proveedores
para listar(ver CU-INS-07 al 18)
ix. Poscondiciones
Permite al Coordinador de Suministros listar los proveedores por una condición de pago
9 Coordinador de Suministros
v. Flujo de Eventos
Actor Sistema
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
El actor debió de haber escogido una condición de pago de proveedores para listar
ix. Poscondiciones
Iniciar Sesión
i. ID Caso de uso: CU-SUS-01
ii. Requerimiento: RF-25
iii. Descripción
Permite a cualquier usuario iniciar sesión, para poder tener acceso al sistema
v. Flujo de Eventos
viii. Precondiciones
No hay
ix. Poscondiciones
v. Flujo de Eventos
No hay
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
ix. Poscondiciones
v. Flujo de Eventos
viii. Precondiciones
El actor debe poseer una cuenta en el sistema y haber iniciado correctamente su sesión.
ix. Poscondiciones
Cambiar contraseña
i. ID Caso de uso: CU-SUS-04
ii. Requerimiento: RF-25
iii. Descripción
v. Flujo de Eventos
8. Procesa el cambio
viii. Precondiciones
ix. Poscondiciones
v. Flujo de Eventos
No hay
viii. Precondiciones
Para poder listar todas las notas de recibo, no debe existir ningún proceso de
inventario abierto (ver caso de uso CU-INV-03)
ix. Poscondiciones
v. Flujo de Eventos
No hay
viii. Precondiciones
Para poder ver los datos completos de una solicitud, el usuario debe
seleccionarla de una lista
Para poder listar todas las notas de recibo, no debe existir ningún proceso de
inventario abierto (ver caso de uso CU-INV-03)
ix. Poscondiciones
seleccionada.
v. Flujo de Eventos
3. Confirma la operación
No hay
viii. Precondiciones
El actor debe escoger que solicitud de cotización desea anular de una lista
Para poder listar todas las notas de recibo, no debe existir ningún proceso de
inventario abierto (ver caso de uso CU-INV-03)
ix. Poscondiciones
9 Coordinador de Suministros
v. Flujo de Eventos
Actor Sistema
3. Confirma la operación
No hay
viii. Precondiciones
El actor debe escoger que solicitud de cotización desea recuperar de una lista
Para poder listar todas las notas de recibo, no debe existir ningún proceso de
inventario abierto (ver caso de uso CU-INV-03)
ix. Poscondiciones
v. Flujo de Eventos
3. Confirma la operación
No hay
viii. Precondiciones
El actor debe escoger que solicitud desea cambiar el estado de una lista
Para poder listar todas las notas de recibo, no debe existir ningún proceso de
inventario abierto (ver caso de uso CU-INV-03)
ix. Poscondiciones
v. Flujo de Eventos
viii. Precondiciones
Para poder listar todas las notas de recibo, no debe existir ningún proceso de
inventario abierto (ver caso de uso CU-INV-03)
© CENTROBECO, C.A. 2007 Departamento de Sistemas Página 287
Sistema de Orden de Compras, Despacho e Inventario Versión: 3.0
de Suministros, Activos y Servicios Fecha: 08/06/2007
SOCDISAS
Especificación de Requerimientos de Software
ix. Poscondiciones
v. Flujo de Eventos
Actor Sistema
viii. Precondiciones
Para poder listar todas las notas de recibo, no debe existir ningún proceso de
inventario abierto (ver caso de uso CU-INV-03)
ix. Poscondiciones
9 Coordinador de Suministros
v. Flujo de Eventos
Actor Sistema
No hay
viii. Precondiciones
Para poder listar todas las notas de recibo, no debe existir ningún proceso de
inventario abierto (ver caso de uso CU-INV-03)
ix. Poscondiciones
9 Coordinador de Suministros
v. Flujo de Eventos
Actor Sistema
viii. Precondiciones
Para poder listar todas las notas de recibo, no debe existir ningún proceso de
inventario abierto (ver caso de uso CU-INV-03)
ix. Poscondiciones
v. Flujo de Eventos
viii. Precondiciones
Para poder listar todas las notas de recibo, no debe existir ningún proceso de
inventario abierto (ver caso de uso CU-INV-03)
ix. Poscondiciones
v. Flujo de Eventos
viii. Precondiciones
Para poder listar todas las notas de recibo, no debe existir ningún proceso de
inventario abierto (ver caso de uso CU-INV-03)
ix. Poscondiciones
v. Flujo de Eventos
viii. Precondiciones
El actor debió de haber escogido una fecha, o un rango de fechas válido, para
las solicitudes de cotización que se desean listar
Para poder listar todas las notas de recibo, no debe existir ningún proceso de
inventario abierto (ver caso de uso CU-INV-03)
ix. Poscondiciones
funcionales abarcan aspectos legales; de compatibilidad con los ambientes, sistemas operativos
y conectividad con otros sistemas existentes; usabilidad; mantenibilidad; confiabilidad; y
desempeño.
1
1..1
1.. U
Ussa
abbiilliid
daad
d
4.5.2. Amigabilidad
El sistema debe ser fácil de usar, para que el proceso de entrenamiento y aprendizaje
sea bastante rápido. El sistema debe ser intuitivo y flexible, ya que lo usarán algunas personas
acostumbradas a manejar aplicaciones como Microsoft Excel. El sistema también será manejado
por personas que pudieran tener poca destreza en el área de computación.
4
4..6
6.. C
Coon
nffiia
abbiilliid
daad
d
4.6.1. Disponibilidad
El sistema debe estar disponible de lunes a sábado, durante el horario laboral de las
tiendas.
4.6.2. Recuperabilidad
En caso de ocurrir alguna falla, el sistema debe poderse recuperar durante el mismo
día. No se puede esperar más de un día, para el restablecimiento del sistema, ya que retrasaría
considerablemente los procesos de compra y distribución de insumos.
4.6.6. Robusto
En caso de que falle algún módulo o funcionalidad del sistema, el resto de los módulos
y funcionalidades deben seguir operativas.
4
4..7
7.. D
Deesse
emmp
peeñ
ñoo
4.7.3. Concurrencia
El sistema debe manejar una concurrencia leve, ya que existe la posibilidad de que
algunos usuarios hagan operaciones simultáneas. Sin embargo, es poco común que ocurra esta
situación, ya que no serán muchos usuarios que interactúan con el sistema, y la mayoría de
estos usuarios solo accederán al mismo las veces en que necesiten procesar algún pedido de
insumos.
4
4..8
8.. M
Maan
ntte
enniib
biilliid
daad
d
4
4..9
9.. S
Seeg
guurriid
daad
d
4
4..1
100.. R
Reessttrriicccciio
onne
ess d
deeD
Diisse
eñño
o
4.10.1. Portabilidad
El sistema debe estar diseñado y elaborado, de tal manera que pueda ejecutarse desde
cualquier servidor, con ambiente Windows o Linux.
4
4..1
111.. R
Reeq
quue
erriim
miie
enntto
oss d
dee D
Dooccu
umme
en acciió
ntta ónne
enn LLíín
neea
a yy
d
deeS
Siisstte
emma
ass d
de Ayyu
eA udda
a
Apegándose a las normas de la compañía, una vez culminado el sistema, se debe
entregar un Manual de usuario a todas aquellas personas que utilizaran este sistema.
Igualmente, se debe entregar al responsable técnico del proyecto una Carpeta Técnica con el
modelo de datos, el diseño de software, la aprobación de pruebas técnicas (programadores) y
comerciales (usuarios), y las funcionalidades aprobadas por el responsable comercial, en este
caso el Gerente de Logística. Finalmente, se le entregará al responsable comercia, una Carpeta
Comercial con el modelo de datos, la aprobación de pruebas técnicas (programadores) y
comerciales (usuarios), y las funcionalidades aprobadas.
NO SE CONTEMPLA QUE EL SISTEMA MANEJE AYUDAS EN LINEA
4
4..1
122.. C
Coom
mppo
onne
enntte
ess C
Coom
mpprra
addo
oss
Para el desarrollo del software, se usaran componentes que la empresa ha adquirido
para el desarrollo, manejo y funcionamiento de otras aplicaciones elaboradas en el
departamento de Sistemas, como el Manejador de Base de Datos DB2 sobre el servidor IBM
ISeries, la herramienta WebSphere, y el sistema operativo Microsoft Windows
4
4..1
133.. IIn
ntte
errffa
acce
ess
4
4..1
144.. R
Reeq
quue
erriim
miie
enntto
oss d
dee LLiicce
enncciia
ammiie
enntto
o
La empresa CENTROBECO, y el departamento de Sistemas cuentan con las licencias
respectivas para el Manejador de Base de Datos DB2, para la herramienta WebSphere, para las
aplicaciones de Microsoft Office 2003 y para el Sistema Operativo Microsoft Windows.
4
4..1
155.. A
Assp
peecctto
oss LLe
egga
alle
ess,, D
Deerre
ecch
hoo d
dee A
Auutto
orr yy
E
Essttá
ánnd
daarre
ess A
Applliicca
abblle
ess
El software desarrollado será propiedad de CENTROBECO, C.A., y sus funcionalidades
se regirán según indiquen las normas de la Gerencia de Logística. El logo de BECO que será
utilizado en la aplicación, es propiedad y de uso exclusivo de la empresa CENTROBECO, C.A. De
igual forma, la aplicación debe utilizar colores suaves, en su mayoría azules y blancos, que son
los que representan la imagen de la empresa.
H
HIISST
TOOR AL
RIIA L DE
D E R
RE VIIS
EV ÓN
SIIÓ N
T
TA BL
AB LA
A DE
D E C
CO NT
ON EN
TE DO
NIID OS
S
INTRODUCCIÓN 3
1. PROPÓSITO 3
2. ALCANCE 3
3. RESUMEN 3
RIESGOS 4
11.. IInnttrroodduucccciióónn
1.1. Propósito
Determinar los riesgos asociados al desarrollo del sistema SOCDISAS, con el propósito
de que dichos riesgos sean manejados adecuadamente, en caso de que se presenten.
1.2. Alcance
Los riesgos presentados en este documento abordan todas las fases del proceso de
desarrollo.
1.3. Resumen
A continuación se presentan en detalle, cada uno de los riesgos que fueron
determinados durante la fase de inicio del desarrollo del sistema SOCDISAS destinada al control
de compras e inventarios de Suministros e Insumos.
22.. RRiieessggooss
2.1.2. Descripción
Las funcionalidades consideradas para el sistema pueden resultar mucho más difíciles
de implementar que lo esperado y no se hayan considerado la repercusión de algunos aspectos
sobre otros y por tanto se hayan considerado un mayor número de funcionalidades que las
realizables o que no sean presentadas de la forma en la que se esperaba originalmente.
2.1.3. Impacto
• Incompletitud del sistema: De presentarse este riesgo, existe la posibilidad de que no
sean implementadas algunas de las funcionalidades presentadas en el plan original de
requerimientos. También es posible que se realicen de forma incompleta, con algunas
características básicas y no de la forma estipulada.
2.1.4. Indicadores
Que no se estén cumpliendo con las actividades a tiempo, porque la complejidad de
alguna funcionalidad supera considerablemente lo estimado.
Se piensa también utilizar un enfoque que permita atacar las funcionalidades más
complejas desde un principio, e irlas desarrollando paulatinamente.
2.2.2. Descripción
Para la realización del proyecto será necesario el manejo de nuevas tecnologías y
herramientas de desarrollo con las que el grupo no ha tenido o posee escaso manejo. La
adaptación a las mismas será fundamental para el correcto cumplimiento del plan de proyecto y
cualquier dificultad en su manejo presenta un riesgo con respecto a la completitud del sistema.
2.2.3. Impacto
• Atrasos: De presentarse este riesgo es posible que no se cumplan debidamente con los
plazos estipulados en el plan de proyecto, implicando un atraso general de las actividades y
entregas, afectando los estimados.
• Completitud del sistema: De no manejarse debidamente y a tiempo puede ponerse en
cuestionamiento la completitud de todas las funcionalidades pautadas originalmente para el
sistema.
2.2.4. Indicadores
Que se vea de manifiesto la incapacidad de manejar a tiempo y de forma eficaz las
herramientas de desarrollo que fueron fijadas en el plan original.
2.3.2. Descripción
La mala planificación y subestimación de tiempos y esfuerzos en la planificación general
del proyecto.
2.3.3. Impacto
• Atrasos: De presentarse este riesgo conllevará a atrasos en alguna(s) actividad(es) del
plan, ya que si los tiempos no están siendo estipulados correctamente y no es medido el
esfuerzo necesario con algo de precisión pueden estarse fijando entregables o fechas topes
que no sean cumplidas.
2.3.4. Indicadores
Constante incumplimiento de las fechas topes estipuladas en el plan del proyecto.
2.4.2. Descripción
Se elabora un diseño del sistema muy sencillo o muy complejo. Es decir, se consideran
un número muy limitado e insuficiente de funcionalidades que no permiten al sistema cumplir
con el objetivo para el cual fue diseñado. De igual forma se pueden considerar una serie de
funcionalidades innecesarias, que agregan complejidad al problema y dificultan el uso de la
aplicación.
2.4.3. Impacto
• Insatisfacción de los Stakeholders: Se construye un sistema que no cumple con las
expectativas de los entes involucrados en su desarrollo.
2.4.4. Indicadores
• Insatisfacción del cliente ante las propuestas realizadas.
• Las funcionalidades previstas no le permiten al usuario cumplir con los objetivos de sus
roles.
• El exceso de tareas complica u obstaculiza la realización de las tareas de algún usuario o
actor.
2.5.2. Descripción
El cliente tiene muy poca o ninguna participación en el desarrollo del sistema. Las
solicitudes del cliente se diluyen en los intermediarios.
Los requerimientos no reflejan directamente las necesidades del cliente, sino que son la
interpretación de los intermediarios.
2.5.3. Impacto
• El cliente pierde el interés en el desarrollo del software.
• Las necesidades reales del cliente no son satisfechas por el software.
• Retraso en el desarrollo del proyecto, surgen nuevas tareas para ajustar el software a lo
que realmente quiere el cliente.
2.5.4. Indicadores
• Cambios frecuentes y desorganizados de los requerimientos.
• Semanas de muy poco trabajo.
2.6.2. Descripción
Requerimientos que cambian con el transcurso del tiempo, o bien porque el cliente así
lo está solicitando
2.6.3. Impactos:
• Mayor trabajo por parte del desarrollador.
• El avance se hace más lento.
• El desarrollador pierde la motivación o el interés en el desarrollo del software.
• El sistema final se demora mucho tiempo si el proyecto es de una envergadura
considerable.
2.6.4. Indicadores:
• En las reuniones que sostiene el desarrollador con el cliente, se determina que algún
requerimiento ya no es necesario o la forma en la cual se estaba trabajando con éste, no es
la deseada por el cliente.
• El cliente no se encuentra claro en lo que desea que el sistema realice o las funcionalidades
que deberá poseer.
• Evolución del problema que pretende resolver el sistema, con lo cual se está en presencia
de requerimientos que intrínsecamente son cambiantes.
2.7.2. Descripción
La falta de recursos pueden limitar al sistema en el uso simultáneo de varias funciones,
o de “triggers” de la base de datos
2.7.3. Impacto
• Rendimiento del sistema: De no manejarse debidamente y a tiempo puede ponerse en
cuestionamiento el rendimiento del sistema, aumentando la velocidad de respuesta de sus
operaciones
• Rendimiento de otros sistemas: El uso de recursos puede afectar el rendimiento de
otros sistemas en el servidor.
• Atrasos: De presentarse este riesgo conllevará a atrasos en alguna(s) actividad(es) del
plan, ya que se tendrán que buscar otras soluciones que reduzcan los impactos.
2.7.4. Indicadores
Después de las pruebas, se observa el comportamiento de este y otros sistemas en el
servidor
H
HIIS
STTO
ORRIIA
ALL D
DEE R
REEV
VIIS
SIIÓ
ÓNN
T
TAAB
BLLA
A D
DEE C
COON
NTTE
ENNIID
DOOS
S
1. INTRODUCCIÓN ................................................................................................................................. 6
T
TAAB
BLLA
A D
DEE IIL
LUUS
STTR
RAAC
CIIO
ONNE
ESS
11.. IInnttrroodduucccciióónn
1
1..1
1.. P
Prro
oppó
óssiitto
o
El documento de arquitectura de software tiene como finalidad mostrar una visión
global de la arquitectura aplicada al desarrollo del Sistema SOCDISAS (Sistema de Orden de
Compra, Despacho de Insumos, Activos y Servicios). Para este desarrollo se utilizó una
arquitectura basada en el modelo de 4+1 vistas, las cuales serán descritas a lo largo del
documento.
1
1..2
2.. A
Allcca
anncce
e
Este documento tiene como finalidad mostrar el detalle de las decisiones tomadas en
cuanto a la implementación y desarrollo de cada una de las vistas, correspondientes al modelo
de arquitectura de 4+1 vistas.
1
1..3
3.. D
Deeffiin
niicciio
onne
ess,, A
Accrró
ónniim
mooss yy a
abbrre
evviia
acciio
onne
ess
• Almacén: Depósito donde se guardan los suministros adquiridos por CENTROBECO C.A. en
su sede central en Boleíta.
• Cuenta: Relación de dinero asignada por la gerencia general, a cada una de las actividades
que se hacen dentro de la empresa. Ejemplo: Cuenta de gastos de limpieza, Cuenta de
gastos de papelería, etc.
• Cuenta por pagar: Obligación que tiene la empresa CENTROBECO C.A. de pagar una
determinada cantidad de dinero con un proveedor.
• Factura: Documento emitido por un proveedor que muestra la relación de los suministros
y precios comprendidos en una venta.
• Inventario: Conjunto de insumos del que dispone CENTROBECO C.A, y que se despachará
a los diversos centros de costo, de acuerdo a la solicitud que hayan realizado
• Nota de Recibo: Es un documento que informa sobre los insumos que se han recibido de
un proveedor determinado, así como también la cantidad exacta de cada uno de ellos. Con
este documento, junto con la factura que llega, es que se tramita el pago al proveedor que
despachó la mercancía.
• Pago: Es el trámite que el Personal de Finanzas realiza, para cancelar una cuenta por
pagar que se tenga pendiente con un proveedor determinado.
• Pedidos Internos: Son todas aquellas solicitudes que los Centros de Costo realizan a la
Coordinación de Suministros en la sede principal CENTROBECO C.A, indicando los insumos
que necesitan, la cantidad respectiva, y el motivo por el cual lo piden.
• Insumo: Son los artículos que el Coordinador de Suministros compra, para cubrir las
necesidades de cada uno de los Centros de Costo.
• Proveedor: Es una persona o empresa que abastece de los insumos solicitados por el
Coordinador de Suministros, en la sede principal CENTROBECO C.A.
• Secciones: Son todas las áreas o sub-departamentos que integran un Centro de Costo
• Usuarios: Son todas las personas que trabajan en los diversos centros de costo existentes
1
1..4
4.. R
Reeffe
erre
enncciia
ass
Este documento hace referencia al documento ERS, el cual permitirá dar mayor soporte
a la justificación de las vistas del modelo de 4+1 vistas. También hace referencia al documento
de Modelo de Datos, que explica con mayor profundidad el diseño de la estructura de datos
implementada en el sistema.
1
1..5
5.. V
Viissiió
ónng
geen
neerra
all
La estructura que presenta el documento es la siguiente: Vista de casos de uso, Vista
Lógica, Vista de Procesos, Vista de implantación y Vista de Implementación. Adicionalmente, se
hizo uso de la Vista de Datos, para dar una breve descripción de los datos que debe manejar y
almacenar el sistema.
Representaremos cada una de las vistas del modelo de arquitectura usando los
diagramas y documentos que se listan a continuación:
• Vista de Casos de Uso: se expondrán los diagramas de caso de uso de cada uno de los
módulos que integran este Sistema. Cada uno de estos diagramas, muestra las
funcionalidades del módulo correspondiente con respecto a los actores involucrados.
• Vista lógica: expone los requerimientos funcionales que la aplicación debe brindar a los
usuarios. En ella se mostrará el modelo conceptual, el cual explica los elementos más
resaltantes del sistema. Además, se mostrará el modelo de datos, que informa la
distribución del almacenamiento de datos.
• Vista de procesos: se explicarán los requerimientos no funcionales que debe cumplir la
aplicación, así como las ventajas del diseño seleccionado.
• Vista de Implantación: se explicará el “hardware” y el “software” seleccionado para este
sistema, así como también el manejador de bases de datos utilizado.
• Vista de implementación: se expondrá la organización del “software” que compone este
sistema.
33.. M
Meettaass yy RReessttrriicccciioonneess A
Arrqquuiitteeccttóónniiccaass
Para que nuestro sistema sea de gran utilidad para la organización, debe abarcar una
serie de requisitos no funcionales, comunes en todas las aplicaciones existentes.
• Para entrar a producción, debe estar 100% funcional: todas las aplicaciones
desarrolladas, pasan por un proceso de prueba en un servidor llamado “Desarrollo” por
un período de varios meses. Durante este tiempo, los usuarios prueban los módulos ya
desarrollados, mientras se van implementando el resto. Para que salga un sistema a
producción, el sistema debe estar 100% funcional. Es por esta razón, que el sistema
que se va a desarrollar, deberá también estar 100% funcional para poder salir en
producción.
• La organización trabaja con JAVA y JSP: todas las aplicaciones de esta
organización, están desarrolladas en JAVA y JSP, por lo que este sistema debe utilizar la
misma tecnología de la empresa. No está permitido que se desarrolle en otros
lenguajes, ya que no cumple con los estándares establecidos.
• Manejador de Bases de Datos utilizado es DB2: las aplicaciones desarrolladas
deben soportar el manejador de bases de datos DB2, puesto que este es el manejador
que se tiene instalado en los servidores.
• Portabilidad: El sistema debe estar diseñado y elaborado, de tal manera que pueda
ejecutarse desde cualquier servidor, con ambiente Windows o Linux.
• Recuperabilidad de los Datos: El sistema debe permitir siempre poder recuperar la
información eliminada desde el sistema.
• Flexibilidad y Mantenibilidad: El sistema debe ser diseñado de forma tal que
facilite, en un futuro, la inclusión de nuevas funcionalidades, realizar cambios de
manera rápida y sencilla sobre las funcionalidades existentes, y poderse integrar a otros
sistemas.
• Tiempo de respuesta para una transacción: El tiempo de respuesta para una
transacción deberá ser en promedio de 5 segundos o menos.
• Información Centralizada: El sistema debe ser centralizado. Todos los usuarios,
indistintamente si se encuentran en las tiendas BECO, o en la oficina central, manejarán
la misma información.
• Concurrencia: El sistema debe manejar una concurrencia leve, ya que existe la
posibilidad de que algunos usuarios hagan operaciones simultáneas. Sin embargo, es
poco común que ocurra esta situación, ya que no serán muchos usuarios que
interactúan con el sistema, y la mayoría de estos usuarios solo accederán al mismo las
veces en que necesiten procesar algún pedido de insumos.
4
4..1
1.. P
Paaq
quue
ette
ess d
deeC
Caasso
oss d
deeU
Usso
o
Los casos de uso del sistema, se agruparon en 18 módulos o paquetes:
1. Módulo de Sesiones de Usuarios 10. Módulo de Facturas
2. Módulo de Manejo de Usuarios 11. Módulo de Línea de Insumos
3. Módulo de Almacenes 12. Módulo de Insumos
4. Módulo de Centros de Costo 13. Módulo de Notas de Recibo
5. Módulo de Inventario 14. Módulo de Órdenes de Compra
6. Módulo de Cuentas Contables 15. Módulo de Pedidos Internos
7. Módulo de Cuentas por Pagar 16. Módulo de Proveedores
8. Módulo de Devoluciones 17. Módulo de Solicitudes de Cotización
9. Módulo de Facturas Internas 18. Módulo de Despacho
Los diagramas a continuación, muestran la interacción entre los usuarios y los paquetes
del sistema:
Figura 3. Interacción de Usuarios con los paquetes de: Centros de Costo, Cuentas
Contables y Cuentas por Pagar
Figura 4. Interacción de Usuarios con los paquetes de: Facturas, Insumos, Líneas de
Insumos, Notas de Recibo y Órdenes de Compra
Figura 5. Interacción de Usuarios con los paquetes de: Inventario, Facturas Internas y
Pedidos Internos
Figura 6. Interacción de Usuarios con los paquetes de: Manejo de Usuarios y Sesiones de
Usuario
5
5..1
1.. V
Viissiió
ónnG
Geen
neerra
all
La estructura que presenta esta sección es la siguiente: Modelo de análisis o dominio,
paquetes de diseño significativos, diagramas de clases, realizaciones de los casos de uso.
5
5..2
2.. M
Mood
deello
odde
eAAn
náálliissiiss o
oDDo
ommiin
niio
o..
La siguiente figura representa el modelo de análisis donde visualiza la dinámica del
negocio.
Los Centros de Costo son todas las tiendas y departamentos de la sede administrativa,
que conforman la empresa. Cada uno de estos centros solicita a CENTROBECO Suministros, los
insumos que necesitan a través de pedidos internos, previamente autorizados por su
colaborador autorizado inmediato (en el caso de las tiendas es el gerente).
Por otra parte, CENTROBECO Suministros puede directamente realizar una orden de
compra a un proveedor. En ella se solicitan varios insumos, a un precio previamente acordado
con él. Una vez que el proveedor recibió la orden, envía los productos pedidos al Centro de
Distribución, junto con su respectiva factura, contabilizando lo que despachó, y el monto total
del envío.
Una vez que llega la mercancía, se procede a cotejar la factura con lo recibido. Esto es
con el fin de determinar si existen diferencias (déficit o excedente) entre lo despachado y lo
facturado. Cuando hay diferencias, se le notifica a CENTROBECO Suministros, quien decidirá si
devolver o no la mercancía.
Una vez que ha concluido el cotejo, se emite una nota de recibo que muestra, para
cada uno de los insumos, la cantidad exacta recibida, la cantidad aceptada, la cantidad según la
factura recibida, y la cantidad según la orden asociada. Esta nota se envía luego a
CENTROBECO Suministros.
Cada uno de los insumos recibidos se guarda dentro de un almacén, y se organiza entre
las diversas líneas disponibles. Cada uno de ellos es distribuido entre los diversos Centros de
Costo, de acuerdo a lo solicitado en sus pedidos internos.
5
5..3
3.. D
Diia
aggrra
amma
ass d
deeC
Clla
asse
e
5
5..4
4.. D
Diia
aggrra
amma
ass d
deeS
Seeccu
ueen
ncciia
a
• Agregar Almacén
• Anular Almacén
• Modificar Almacén
• Restaurar Almacén
• Listar Inventarios
• Realizar Ajustes
• Anular Devolución
• Emitir Devolución
• Restaurar Devolución
• Consultar Factura
• Listar Facturas
• Agregar Insumo
• Anular Insumo
• Modificar Insumos
• Restaurar Insumos
• Iniciar Sesión
5
5..5
5.. D
Diia
aggrra
amma
ass W
WAAE
E
Actualmente, como es sólo una persona quien emite las órdenes de compra y
solicitudes, además de despacho de insumos, la concurrencia en estos módulos no aplica, ya
que es sólo una persona la encargada de llevar el control de esa información. De la misma
manera ocurre con las notas de recibo emitidas.
7
7..1
1.. S
Seerrvviid
doorre
ess
La aplicación será instalada en un Servidor AS/400, utilizado en la empresa. Este
servidor ofrece una elevada seguridad e integración, pues en el Sistema Operativo, viene ya
incluido todo lo necesario para poder sacarle el máximo rendimiento: Base de datos,
comunicaciones, herramientas de desarrollo, etc. Integra tecnologías como TCP/IP, la mayor
parte de APIS de UNIX, Java. Da soporte a todo tipo de archivo e integra a Novell Netware,
Windows NT, Notes, etc.
Para que el programa funcione, el servidor debe contar con la aplicación servidor que
compile e interprete las clases de “Java” y las páginas en “JSP”., como por ejemplo el “Apache
Tomcat”, o el “JBOSS”.
7
7..2
2.. M
Maan
neejja
addo
orr d
deeb
baasse
ess d
deed
daatto
oss
Utilizaremos para la implementación de la base de datos de la aplicación el manejador
“DB2 de IBM”. La razón de haber escogido este manejador, se debe a que la empresa maneja
todas sus aplicaciones en servidores “AS400”, que tienen incorporado este manejador.
La mayoría de los que utilizan equipos IBM utilizan DB2 porque es confiable y tiene un
muy buen soporte técnico.
7
7..3
3.. E
Esstta
acciio
onne
ess d
deeT
Trra
abba
ajjo
o
Los usuarios de la aplicación podrán acceder a la misma en el servidor, desde sus
computadoras en sus oficinas, conectadas a la “intranet” de la empresa. Esta “intranet” es la
red conformada por las estaciones de trabajo dentro de Beco, y el servidor “AS400”. Los
usuarios, en sus computadoras, deben tener instalado un navegador Web como “Internet
Explorer”, “Mozilla Firefox”, “Netscape Navigator”, etc.
8
8..1
1.. V
Viissiió
ónnG
Geen
neerra
all
En esta sección se explicará las diferentes capas de la arquitectura, las cuales son: capa
de presentación, capa de negocio, capa manejadora de datos, permitiendo de esta manera, una
clara diferenciación entre ellas, y que es lo que cada una contiene. Se muestra un diagrama
que permite determinar la manera en cómo estas capas interactúan entre sí, y las razones por
las cuales se decidió este tipo de arquitectura para la aplicación.
8
8..2
2.. D
Diivviissiió
ónnd
deell S
Siisstte
emma
appo
orr M
Móód
duullo
oss
Como se indicó en la vista de casos de uso, optamos por dividir el sistema en módulos
que agrupan casos de uso que están relacionados a varios objetivos que se deben cumplir.
8
8..3
3.. C
Caap
paass yy o
obbjje
etto
oss q
quue
e cco
ommp
poon
ne n llo
en oss m
móód
duullo
oss d
dee lla
a
a
applliicca
acciió
ónn
Cada uno de los módulos de la aplicación desarrollada presenta una arquitectura de
“Software” basada en un modelo de tres capas. Este modelo se encuentra constituido por:
9 Una capa manejadora de datos que maneja todos los procesos que interactúan con la
base de datos del Sistema. En esta capa se accede, se agregan y/o modifican todos los
datos que en ella se almacenan. Para la implementación de esta capa, se usará el lenguaje
de programación JAVA.
9 Una capa de negocio que determina la lógica del sistema, realizando las operaciones
estadísticas y de información, con los datos obtenidos en la capa anterior. Para la
implementación de esta capa, se usará el lenguaje de programación JAVA.
9 Una capa de presentación que es la interfaz que permite la interacción entre el usuario y
el Sistema. Para desarrollar esta capa, se utilizará el “framework Struts” que obedece el
patrón “MVC (Model View Controller)”. En la interfaz gráfica se implementarán los
paradigmas de “HTML”, “JSP”, “Javascript”, y “AJAX”.
La aplicación utiliza objetos, que representan los conceptos importantes que se deben
manejar. Cada uno de ellos tiene atributos que mantienen en memoria la información obtenida
de la base de datos o del usuario. Estos objetos son conocidos a nivel de programación “JAVA”
como “beans”.
9
9..1
1.. U
Unniivve
errsso
odde
ell D
Diissccu
urrsso
o
CENTROBECO C.A es una empresa que se dedica a la venta de equipos para el hogar,
belleza, deporte y moda a lo largo del país. La Coordinación de Suministros es una sección del
departamento de Logística, ubicada en la sede principal de la compañía, y se encarga del
despacho e inventario de los suministros internos necesarios para el buen funcionamiento de
cada una de las tiendas y departamentos, además de la emisión de las órdenes de compra
necesarias y servicios que se requieran para ello. Actualmente, todos estos procesos se llevan
de manera manual, por lo que se desea construir una base de datos que permita almacenar
todos los datos importantes.
La compañía cuenta con varios Centros de Costo, integrados por todas las tiendas y
departamentos de la sede principal. Cada uno de ellos a su vez, está integrado por secciones,
las cuales tienen una función específica dentro del centro de costo, y para lograrla, necesitan de
insumos que les permitan mejorar su productividad. Se desea almacenar de los centros de
costo el código, nombre, dirección, persona encargada, el correo electrónico de dicha persona,
y las secciones que lo componen.
Para llevar un manejo de los gastos que se llevan, la compañía ha creado varias
cuentas contables. Cada cuenta maneja una variedad determinada de insumos, y tiene un
presupuesto que abarca todo el año fiscal de la compañía (comienza en el mes de Julio, y
termina en el mes de Junio del siguiente año). Este presupuesto es asignado por el
departamento de Contabilidad, en función de varios aspectos, como por ejemplo: la prioridad
de la cuenta, el total de gastos durante el año anterior, etc. Cada cuenta además tiene un
código, un nombre y una descripción, las cuales las provee directamente la Corporación
BECOBLOHM.
Los insumos son todos los artículos de uso interno, que se compran para los centros de
costo, y no son para la venta al público. En particular se desea almacenar los datos de los
insumos, los cuales son: nombre, código, marca, modelo, fecha en la que se registró,
procedencia (nacional o importado), cantidad disponible, cantidad mínima que se debe tener,
cantidad máxima, cantidad promedio los últimos tres precios de compra, precio promedio
presentación (por caja, unidad), talla, color.
Cada insumo pertenece a una línea o categoría. Cada línea tiene un nombre, una
descripción y un código. Toda línea existente, tiene una cuenta asociada (equipo de oficina,
fotocopia, etc).
Todos los insumos se guardan físicamente en los Depósitos o Almacenes, los cuales
tienen un nombre, dirección física, el monto total en Bolívares que se tiene, la cantidad
guardada y el monto total por insumo. De estos almacenes es donde se sacarán la mercancía a
repartir a los centros de costo, cuando así se requiera.
Por otra parte, la Coordinación de Suministros puede comprar insumos, sin tener que
esperar un pedido interno. Existen dos formas de iniciar este proceso:
Los proveedores son personas o compañías a quienes se les compra la mercancía. Cada
proveedor tiene una razón social o nombre, rif, nit, dirección, fax, móvil, persona de contacto,
web, e-mail y tipo de mercancía que despacha.
Una vez que se reciben las cotizaciones, el Coordinador decide si generar una orden de
compra, respecto a la información que se tiene en la cotización.
Cada orden de compra debe llevar: número de la orden, la descripción de los insumos,
la cantidad por insumo, precio unitario y total por insumo, sub-total, impuesto, descuento,
monto total, condición de pago, fecha de emisión y fecha de entrega. La fecha de entrega
puede ser para toda la orden, pero puede darse el caso de que cada insumo tenga su propia
fecha de entrega. Esta decisión la toma el Coordinador de Suministros, en función del
presupuesto con el que se cuente para el mes de emisión de la orden. La orden de compra
debe también reflejar la fecha de entrega por insumos, en caso de tenerla.
El Personal de Distribución cuenta una a una, la cantidad que se recibe por insumo, y lo
compara con la cantidad según la orden de compra asociada, y con la factura recibida, y se
anotan todas las diferencias encontradas entre lo facturado y lo contado. Una vez finalizado
este cotejo, se indica la cantidad que finalmente se va a aceptar, y la cantidad a devolver en el
caso de que aplique.
Al final del proceso se emite una nota de recibo, que es un documento que resume
todo este proceso de cotejo. Más específicamente, la nota de recibo tendrá los siguientes datos:
Orden de Compra asociada, la descripción de los insumos que se recibieron, la cantidad según
orden de compra, la cantidad según la factura, la cantidad según el chequeo, la diferencia entre
lo facturado y lo chequeado, la cantidad aceptada, el sub-total de la nota, el monto total por el
impuesto, el total de la nota, la fecha de emisión, la fecha de facturación (fecha de la factura),
el código de la factura, observaciones en caso de que haya algo que comentar y las condiciones
de entrega. Estas condiciones indican el tipo de entrega (orden total, orden parcial y
excedente).
La orden total ocurre cuando la cantidad aceptada es la misma que se había solicitado
en la orden de compra, por lo que esta pasa de estar pendiente a entregada. Orden Parcial es
cuando no se ha recibido toda la mercancía, por lo que la orden de compra pasa de estar
pendiente, a parcialmente entregada. Excedente es cuando se acepta más cantidad de la que
se había pedido inicialmente y, en este caso, la orden de compra pasa a estado entregada. La
decisión de cuánto se va a aceptar por insumo depende exclusivamente del Coordinador de
Suministros. Este documento es con el que se cancelará la mercancía al proveedor, puesto que
indica claramente el total de la mercancía recibida y aceptada.
Así como se acepta una cantidad por cada insumo, el Coordinador de Suministros
puede ordenar una devolución. Cuando esto ocurre, es necesario emitir un documento que
contenga: la(s) nota(s) de recibo asociada(s), los insumos que se están devolviendo, la
cantidad a devolver y el monto total en Bs. de dicha devolución. Hay que aclarar que, para una
nota de recibo, la cantidad que se devuelve no puede superar la cantidad aceptada. Este
documento se envía al proveedor, junto con la mercancía física, y se actualiza el monto a
cancelar para las notas involucradas. Si la nota ya ha sido cancelada, no se podrá emitir
ninguna devolución para la misma.
Cada vez que se emita una nota de recibo y/o una devolución, se debe actualizar el
inventario, sumando la cantidad aceptada o restando la cantidad devuelta, según sea el caso.
Una vez que se ha emitido la nota de recibo, se puede proceder a realizar el pago de la
misma, pero esto dependerá principalmente de la condición de pago establecida para la orden
asociada (30 días, 45 días, etc), y del convenio o trato (ofertas) que se haya hecho con el
proveedor (en caso de haberlo). De esta manera, el pago puede ser inmediato a la emisión de
la nota, o bien varios días después, pero nunca debe ser mayor que lo señalado en la condición
de pago. Puede haber varios tipos de pago:
• Pagos por adelanto: en este caso, se debe abonar una cantidad para que el
proveedor despache la mercancía hacia la sede principal. En este caso, el personal de
finanzas, genera un nuevo pago, y registrará una nueva cuenta por pagar, asociada a dicha
orden de compra
• Pagos por pronto pago: se contemplan las ofertas o descuentos que realizan los
proveedores, si se cancela la deuda antes de la fecha establecida. En este caso, el personal
de finanzas registra una nueva cuenta por pagar, asociada con la nota de recibo y la
factura emitida por el proveedor.
• Pago normal: se emite un nuevo pago, una vez recibida la mercancía, sin tomar en
cuenta ninguna oferta.
• Por porcentaje de ventas: las tiendas con mayor porcentaje de ventas tienen mayor
prioridad, y se les despachará mayor cantidad de insumos, o mayor monto en Bs. según
sea el caso.
• Manual: el Coordinador de Suministros decide abiertamente cuánto despachar a cada
centro de costo.
• Artículos recibidos: en el caso de que se hayan despachado los insumos, se le
cobrarán los artículos enviados.
Cuando finaliza la distribución, el Coordinador emite una factura a cada centro de costo,
indicando los insumos que se van a despachar, y el monto total del despacho. Esta factura
interna contiene: la sección afectada, el centro de costo asociado, la fecha de emisión, los
insumos a despachar, el precio unitario y total por insumo, el monto total de la factura, el
número del pedido interno, y el tipo de entrega (parcial o total). El monto total será descontado
del presupuesto disponible del centro de costo para la fecha de emisión, y además se
actualizará el presupuesto disponible de todas las cuentas contables que se vean afectadas con
esta distribución. Esto se realiza con la finalidad de poder mantener un control exacto del
dinero con el que se cuenta para todo el proceso de compra y despacho de insumos.
9
9..2
2.. M
Mood
deello
oEEn
nttiid
daad
d IIn
ntte
errrre
ella
acciió
ónnE
Exxtte
ennd
diid
doo((E
ERR--E
E))
9.2.1. Diagrama ER
Tipo del
Entidad Descripción Atributos Descripción del Atributo
Atributo
ADELANTO Los adelantos que se Monto Cantidad total a cancelar Simple
hacen para que la Monovaluado
mercancía de una Primitivo
Orden de Compra Fijo
comience a ser Fecha del abono La fecha de emisión del Simple
despachada por el adelanto Monovaluado
proveedor Primitivo
Fijo
ALMACEN Los depósitos donde Código Identificador del almacén Clave
se guardan Simple
físicamente los Monovaluado
insumos que se Primitivo
reciben Fijo
Dirección Física Donde está ubicado Simple
físicamente el almacén Monovaluado
Primitivo
Fijo
Nombre Nombre del almacén Simple
Monovaluado
Primitivo
Fijo
Anulado Indica si el almacén esta o Simple
no anulado Monovaluado
Primitivo
Fijo
CENTRO_ Tiendas o Código Identificador del centro de Clave
COSTO departamentos que costo Simple
integran la compañía Monovaluado
CENTROBECO C.A. Primitivo
Fijo
Nombre Nombre del centro de costo Simple
Monovaluado
Primitivo
Fijo
Dirección Donde se encuentra Simple
físicamente el centro de Monovaluado
costo Primitivo
Fijo
Teléfono Teléfono del centro de Simple
costo Monovaluado
Primitivo
Fijo
Correo Electrónico Correo electrónico de la Simple
persona de contacto Monovaluado
Primitivo
Fijo
Persona de Contacto Nombre de la persona de Simple
contacto Monovaluado
Primitivo
Fijo
Tipo Tipo de centro de costo Simple
(tienda, departamento Monovaluado
Primitivo
Fijo
Anulado Indica si el centro de costo Simple
está anulado Monovaluado
Primitivo
Fijo
COLABORADOR Empleado de algún Anulado Indica si el colaborador Simple
departamento o está anulado Monovaluado
tienda Primitivo
Fijo
Primitivo
Fijo
IMPUESTO Tasas del IVA Fecha Fecha de inicio del IVA Simple
Monovaluado
Primitivo
Fijo
Tasa porcentual Porcentaje de IVA vigente Simple
Monovaluado
Primitivo
Fijo
Fecha de cierre Fecha de cierre de la tasa Simple
Monovaluado
Primitivo
Fijo
INSUMO Los artículos que se Código Identificador del insumo Clave
compran a los Simple
proveedores Monovaluado
Primitivo
Fijo
Nombre Nombre del Insumo Simple
Monovaluado
Primitivo
Fijo
Marca Marca del insumo Simple
Monovaluado
Primitivo
Fijo
Modelo Modelo del insumo Simple
Monovaluado
Primitivo
Opcional
Color Color del Insumo Simple
Monovaluado
Primitivo
Opcional
Iva Indica si el insumo está o Simple
no exento de IVA Monovaluado
Primitivo
Opcional
Procedencia Indica si le insumo es Simple
nacional o importando Monovaluado
Primitivo
Fijo
Precio promedio Precio derivado de las Simple
últimas tres compras Monovaluado
Derivado
Fijo
Stock mínimo Cantidad mínima con la que Simple
se debe contar físicamente Monovaluado
en almacén Primitivo
Fijo
Stock máximo Cantidad máxima con la Simple
que se debe contar Monovaluado
físicamente en almacén Primitivo
Fijo
Presentación Forma en la que viene el Simple
insumo(caja) Monovaluado
Primitivo
Fijo
Talla Talla del insumo, en caso Simple
de que aplique Monovaluado
Primitivo
Opcional
Anulado Indica si un insumo está o Simple
no anulado Monovaluado
Primitivo
Fijo
INVENTARIO Proceso que se realiza Numero Identificador del inventario Simple
periódicamente para Monovaluado
© CENTROBECO, C.A. 2007 Departamento de Sistemas Página 59
Sistema de Orden de Compras, Despacho e Inventario Versión: 3.1
de Suministros, Activos y Servicios Fecha: 30/05/2007
SOCDISAS
Documento de Arquitectura
Fijo
Nombre Nombre del Usuario Simple
Monovaluado
Primitivo
Fijo
Apellido Apellidos del usuario Simple
Monovaluado
Primitivo
Fijo
Cédula Número de cédula Simple
Monovaluado
Primitivo
Fijo
Dirección Dirección de habitación Simple
Monovaluado
Primitivo
Fijo
Teléfono Teléfono de habitación Simple
Monovaluado
Primitivo
Fijo
Celular Número de celular Simple
Monovaluado
Primitivo
Fijo
Correo Electrónico Correo electrónico del Simple
usuario Monovaluado
Primitivo
Fijo
Anulado Indica si el usuario está Simple
anulado en el sistema Monovaluado
Primitivo
Fijo
Tipo de
Asociación Semántica Atributos Descripción del Atributo
Atributo
abarcan Una cuenta contable C abarca una Anulado Indica si una cuenta Simple
Línea L contable C, sigue abarcando Monovaluado
la línea L Primitivo
Fijo
abona Una Orden de Compra O abona un
adelanto A
NO TIENE ATRIBUTOS
acepta Un proveedor P acepta una Condición Anulado Indica se el proveedor P, Simple
de Pago C sigue aceptando la Monovaluado
condición de pago C Primitivo
Fijo
aprueba Un Gerente G aprueba un Pedido Fecha de envío Indica la fecha en que el Simple
Interno P Gerente G, aprobó el pedido Monovaluado
P Primitivo
Opcional
cierra Un Superior de Suministros S cierra un
inventario I
NO TIENE ATRIBUTOS
contabiliza Una Centro de Costo C1 contabiliza un Presupuesto Monto en Bs. asignado para Simple
presupuesto P1 el centro de costo, durante Monovaluado
un mes del año fiscal Primitivo
Fijo
• La suma de los presupuestos de cada Centro de Costo para una misma cuenta y un
mismo mes del año fiscal, debe ser igual al presupuesto total disponible para la cuenta
asociada durante ese mes.
• El monto total de una devolución, no debe ser mayor al monto total de la nota de
recibo asociada
(∀d,n, i | d ∈ DEVOLUCION ^ n ∈ NOTA_RECIBO ^ i ∈ INSUMO
^ <d,n,i> ∈ reembolsa :
Σ(<d,n,i>.monto) ≤ n.monto)
• El monto de un adelanto, no debe ser mayor que el monto total de la orden de compra
asociada
• La cantidad que se devuelve de un insumo, no debe ser mayor que la cantidad recibida
(∀i,d,n | i ∈ INSUMO ^ d ∈ DEVOLUCION ^ n ∈ NOTA_RECIBO
^ <i,d,n> ∈ reembolsa:
<i,d,n>.cantidad ≤ <i,n>.cantidad)
• El gerente solo puede aprobar pedidos internos del centro de costo que gestiona
(∀g,p,c,e,s | g ∈ GERENTE ^ p ∈ PEDIDO_INTERNO ^ c ∈ CENTRO_COSTO ^
e ∈ COLABORADOR ^ s ∈ SECCIONES:
<g,p> ∈ aprueba ⇒ <g,c> ∈ gerencia ^
<p,e> ∈ emite ^ <c,s> ∈ pertenece ^
<s,e> ∈ se_divide_en )
• Toda cuenta que tenga presupuesto para el año fiscal en curso, no puede inactivarse
¬(Э c, p | c ∈ CUENTA ^ p ∈ PRESUPUESTO ^ <c,p> ∈ se_asigna ^
p.fecha_inicio_mes ≥ fecha_inicio_año_fiscal_actual ^
p.fecha_fin_mes ≤ fecha_inicio_año_fiscal_actual ^
c.estado = “activa”)
• Para asignarle presupuesto a un Centro de costo de una cuenta durante el año fiscal
que comienza, el centro no puede estar anulado, ni la cuenta inactiva
¬(Э c1,c2, p | c1 ∈ CENTRO_COSTO ^ c2 ∈ CUENTA ^ p ∈ PRESUPUESTO:
<c1,p> ∈ contabiliza ^ <c2,p> ∈ se_asigna ^
p.fecha_inicio_mes ≥ fecha_inicio_año_fiscal_actual ^
p.fecha_fin_mes ≤ fecha_inicio_año_fiscal_actual ^
c1.anulado = “N” ^ c2.estado = “inactiva”)
9
9..3
3.. M
Mood
deello
oRRe
ella
acciio
onna
all
9.3.1. Relaciones
CONDICION_PAGO (CONPAG_NOMBRE)
NOTREC_FAC_NUMEROFACTURA, NOTREC_ORDCOM_NUMEROORDEN_COMPRA,
NOTREC_PERSUM_USU_LOGINPERSONAL_SUMINISTROS, NOTREC_BULTOS_RECIBIDOS,
NOTREC_MONTO, NOTREC_MONTO_IVA)
ORDEN_COMPRA_ESTADO (ORDCOMEST_NOMBRE)
SE_CONVIERTE_EN (SECONEN_SOLCOT_CODIGOSOLICITUD_COTIZACION,
SECONEN_ORDCOM_NUMEROORDEN_COMPRA_NUMERO, SECONEN_ANULADO)
Primitivo
Fijo
COL_SEC_ Sección donde trabaja el Clave Foránea
CODIGO colaborador Primitivo
Fijo
COL_SEC_ Centro de costo donde Clave Foránea
CENCOS_ trabaja el colaborador Primitivo
CODIGO Fijo
COL_ Indica si el colaborador está Primitivo
ANULADO anulado Fijo
CONDICION_ CONPAG_ Nombre de la condición de Clave Primaria
PAGO NOMBRE pago aceptada Primitivo
Fijo
CONTABILIZA CON_ Centro de costo que Clave Primaria
CENCOS_ contabiliza Clave Foránea
CODIGO Primitivo
Fijo
CON_PRE_ Cuenta contable asignada Clave Primaria
CUECON_ Clave Foránea
CODIGO Primitivo
Fijo
CON_ Presupuesto inicial fijado Primitivo
PRESUPUESTO Fijo
CON_PRE_ Fecha de inicio del mes del Clave Primaria
FECHA_INICIO_MES presupuesto Clave Foránea
Primitivo
Fijo
CON_PRE_ Fecha fin del mes de Clave Primaria
FECHA_FIN_,ES presupuesto Clave Foránea
Primitivo
Fijo
CON_PRESUPUESTO_ Presupuesto con el que Primitivo
DISPONIBLE cuenta el centro de costo Fijo
para ese mes
CON_ Indica si se anuló el Primitivo
ANULADO presupuesto del mes, para un Fijo
centro de costo
CONTEO_FISICO CONFIS_ID Identificador del conteo físico Clave Primaria
Primitivo
Fijo
CONFIS_INV_ Numero del inventario Clave Primaria
NUMERO Clave Foránea
Primitivo
Fijo
CONFIS_INS_CODIGO Código del insumo contado Clave Primaria
Clave Foránea
Primitivo
Fijo
CONFIS_PERSUM_ Login del colaborador que Clave Foránea
USU_LOGIN_CONTEO ingresa el conteo físico Primitivo
Opcional
CONFIS_CANTIDAD_ Cantidad según el conteo Primitivo
CONTEO Fijo
CONFIS_CANTIDAD_ Cantidad según el sistema Derivado
SISTEMA Fijo
CONFIS_ Comentario adicional sobre el Primitivo
OBSERVACIONES proceso de conteo físico Opcional
CONFIS_ANULADO Indica si el conteo físico está Primitivo
o no anulado Fijo
COTIZA COT_ Código de la solicitud de Clave Primaria
SOLCOT_ cotización asociada Clave Foránea
CODIGO Primitivo
Fijo
COT_ Código del insumo asociado Clave Primaria
INS_CODIGO Clave Foránea
Primitivo
Fijo
COT_ Cantidad cotizada Primitivo
CANTIDAD Fijo
COT_ Indica si la asociación está Primitivo
ANULADO anulada Fijo
CUENTAS_ CUECON_ Código de la cuenta contable Clave Primaria
CONTABLES CODIGO asociada Primitivo
Fijo
CUECON_ Nombre de la cuenta contable Primitivo
NOMBRE Fijo
CUECON_ Descripción de la cuenta Primitivo
DESCRIPCION contable Fijo
CUECON_ Estado de la cuenta contable Primitivo
ESTADO Fijo
DEVOLUCIONES DEV_NUMERO Número de la devolución Clave Primaria
Primitivo
Fijo
DEV_FECHA_ Fecha de emisión de la Primitivo
EMISION devolución Fijo
DEV_ Comentario adicional sobre la Primitivo
OBSERVACIONES devolución Fijo
DEV_SUPSUM_ Login del superior de Clave Foránea
USU_LOGIN suministro que emite la Primitivo
devolución Fijo
DEV_ESTADO Estado de la devolución Primitivo
Fijo
DEV_ANULADO Indica si está o no anulada la Primitivo
devolución Fijo
DISTRIBUIR DIS_INS_ Código del insumo a distribuir Clave Primaria
CODIGO Clave Foránea
Primitivo
Fijo
DIS_ Código de la nota de recibo a Clave Primaria
NOTREC_ distribuir Clave Foránea
CODIGO Primitivo
Fijo
DIS_SEC_ Código de la sección de costo Clave Primaria
CODIGO asociada Clave Foránea
Primitivo
Fijo
DIS_SEC_ Código del centro de costo Clave Primaria
CENCOS_ asociado Clave Foránea
CODIGO Primitivo
Fijo
DIS_FECHA Fecha de emisión de la Primitivo
distribución Fijo
DIS_FORMA Forma de la distribución Primitivo
Fijo
DIS_CANTIDAD Cantidad a despachar del Primitivo
insumo Fijo
DIS_ESTADO Estado de la distribución Primitivo
Fijo
DIS_ANULADO Indica si la distribución está o Primitivo
no anulada Fijo
ENVIADA_ ENVA_ Código del proveedor Clave Primaria
A PRO_ Clave Foránea
NUMERO Primitivo
Fijo
ENVA_ Número de la solicitud de Clave Primaria
SOLCOT_ cotización Clave Foránea
CODIGO Primitivo
Fijo
ENVA_ANULADA Indica si la asociación entre la Primitivo
solicitud y el proveedor está Fijo
anulada
FACTURA FAC_NUMERO Número de la factura Clave Primaria
Primitivo
Fijo
FAC_FECHA_ Fecha en la que se emite la Primitivo
EMISION factura Fijo
CONPAG_ Primitivo
NOMBRE Fijo
ORDCOM_ Login del superior de Clave Foránea
SUPSUM_ suministros que emitió la Primitivo
USU_ orden Fijo
LOGIN
ORDCOM_ Fecha de emisión de la orden Primitivo
FECHA_ Fijo
EMISION
ORDCOM_ Descuento realizado para la Primitivo
DESCUENTO orden Opcional
ORDCOM_ Comentario adicional sobre la Primitivo
OBSERVACIONES orden de compra Opcional
ORDCOM_ Indica si la orden está Primitivo
ANULADO anulada Fijo
ORDCOM_ Estado de la orden de compra Primitivo
ORDCOMEST_ Fijo
NOMBRE
ORDCOM_MONTO Monto total en Bs. para la Derivado
orden Fijo
ORDCOM_FECHA_ Monto total en Bs. para la Primitivo
ENTREGA orden Fijo
ORDEN_ ORDCOMEST_ Nombre del estado Clave Primaria
COMPRA_ NOMBRE Primitivo
ESTADO Fijo
PAGO PAG_ Código del pago Clave Primaria
CODIGO Primitivo
Fijo
PAG_ Código de la nota de recibo Clave Foránea
NOTREC_ Primitivo
CODIGO Fijo
PAG_ Fecha de emisión del pago Primitivo
FECHA_ Fijo
PAGO
PAG_ Monto total en Bs. para el Derivado
MONTO pago Fijo
PAG_ Personal de finanzas que Clave Foránea
PERFIN_ emite el pago Primitivo
USU_ Fijo
LOGIN
PEDIDO_ PEDINT_ Código del pedido interno Clave Primaria
INTERNO CODIGO Primitivo
Fijo
PEDINT_FECHA_ Fecha del pedido Primitivo
PEDIDO Fijo
PEDINT_FECHA_ Fecha en la que el Primitivo
ENVIO colaborador autorizado envió Opcional
el pedido a la Coordinación de
Suministros
PEDINT_ Dirección de entrega del Primitivo
DIRECCION_ pedido Fijo
ENTREGA
PEDINT_ Comentario adicional sobre el Primitivo
OBSERVACIONES pedido Opcional
PEDINT_ Indica si el pedido ha sido Primitivo
APROBADO aprobado Fijo
PEDINT_ Estado del pedido interno Primitivo
ESTADO Fijo
PEDINT_ Indica si el pedido interno ha Primitivo
ANULADO sido anulado Fijo
PEDINT_ Login del gerente que aprobó Clave Foránea
GER_USU_LOGIN el pedido Primitivo
Fijo
PEDINT_ Login del usuario que emite el Clave Foránea
COL_USU_LOGIN pedido Primitivo
Fijo
PERSONAL_ PERFIN_ Login del personal de finanzas Clave Primaria
FINANZAS USU_ Clave Foránea
LOGIN Primitivo
Fijo
PERFIN_ Indica si el usuario está Primitivo
ANULADO anulado Fijo
PERSONAL_ PERSUM_ Login del usuario Clave Primaria
SUMINISTROS USU_ Clave Foránea
LOGIN Primitivo
Fijo
PERSUM_ Tipo de usuario Primitivo
TIPO Fijo
PERSUM_ Indica si el usuario está Primitivo
ANULADO anulado Fijo
PRESUPUESTO PRE_FECHA_INICIO_ Fecha de inicio del mes fiscal Clave Primaria
MES Primitivo
Fijo
PRE_FECHA_FIN_MES Fecha fin del mes fiscal Clave Primaria
Primitivo
Fijo
PRE_ Presupuesto asignado para el Clave Primaria
PRESUPUESTO_MES mes Primitivo
Fijo
PRE_CUECON_ Cuenta contable asociada Clave Primaria
CODIGO Clave Foránea
Primitivo
Fijo
PRE_PRESUPUESTO_ Presupuesto disponible para Primitivo
DISPONIBLE el mes Fijo
PROVEEDOR PRO_ Código del proveedor Clave Primaria
CODIGO Primitivo
Fijo
PRO_RAZON_ Nombre del proveedor Primitivo
SOCIAL Fijo
PRO_RIF Rif del proveedor Primitivo
Fijo
PRO_NIT Nit del proveedor Primitivo
Fijo
PRO_DIRECCION Dirección física del proveedor Primitivo
Fijo
PRO_FAX Número de fax Primitivo
Fijo
PRO_CELULAR1 Celular 1 del proveedor Primitivo
Fijo
PRO_CELULAR2 Celular 2 del proveedor Primitivo
Opcional
PRO_TELEFONO1 Teléfono 1 del proveedor Primitivo
Fijo
PRO_TELEFONO2 Teléfono 2 del proveedor Primitivo
Opcional
PRO_TELEFONO3 Teléfono 3 del proveedor Primitivo
Opcional
PRO_PERSONA_ Nombre de la persona de Primitivo
CONTACTO contacto Fijo
PRO_WEB Página web del proveedor Primitivo
Opcional
PRO_TIPO_ Tipo de mercancía que vende Primitivo
MERCANCIA Fijo
PRO_CORREO_ Correo electrónico de la Primitivo
ELECTRONICO persona de contacto Opcional
PRO_ANULADO Indica si el proveedor está Primitivo
anulado Fijo
REEMBOLSA REE_ Número del reembolso Clave Primaria
DEV_ Clave Foránea
NUMERO Primitivo
Fijo
REE_ Nota de recibo asociada Clave Primaria
NOTREC_ Clave Foránea
CODIGO Primitivo
Fijo
SOLICITUD
SOLCOT_ Fecha de entrega de la Primitivo
FECHA_ cotización de los proveedores Fijo
ENTREGA
SUMINISTRA SUM_PRO_NUMERO Número del proveedor Clave Primaria
Clave Foránea
Primitivo
Fijo
SUM_INS_CODIGO Código del insumo Clave Primaria
Clave Foránea
Primitivo
Fijo
SUM_ANULADO Indica si la asociación entre el Primitivo
insumo y el proveedor está Fijo
anulada
SUPERIOR_ SUPSUM_USU_LOGIN Login del superior de Clave Primaria
SUMINISTROS suministros Clave Foránea
Primitivo
Fijo
SUPSUM_TIPO Tipo de superior suministros Primitivo
Fijo
SUPSUM_ANULADO Indica si el superior de Primitivo
suministros está anulado Fijo
USUARIO USU_LOGIN Login del usuario Clave Primaria
Primitivo
Fijo
USU_CONTRASENA Contraseña del usuario Primitivo
Fijo
USU_CODIGO Identificador del usuario Primitivo
Fijo
USU_NOMBRE Nombre del usuario Primitivo
Fijo
USU_APELLIDO Apellidos del usuario Primitivo
Fijo
USU_CEDULA Cédula del usuario Primitivo
Fijo
USU_DIRECCION Dirección de habitación Primitivo
Opcional
USU_TELEFONO Teléfono de habitación Primitivo
Opcional
USU_CELULAR Celular del usuario Primitivo
Opcional
USU_CORREO_ Correo electrónico Primitivo
ELECTRONICO Opcional
USU_ANULADO Indica si el usuario está Primitivo
anulado Opcional
PEDINT_FECHA_PEDIDO Fecha
PEDINT_FECHA_ENVIO Fecha
PEDINT_DIRECCION_ENTREGA Cadena de caracteres
PEDINT_OBSERVACIONES Cadena de caracteres
PEDINT_APROBADO {APROBADO_COORDINADOR,
RECHAZADO_COORDINADOR,
APROBADO_GERENTE,
RECHAZADO_GERENTE,
EN_ESPERA}
PEDINT_ESTADO {COMPLETO, ADELANTO,
NO_DESPACHADO}
PEDINT_ANULADO {S,N}
PEDINT_GER_USU_LOGIN Cadena de caracteres
PEDINT_COL_USU_LOGIN Cadena de caracteres
PERSONAL_ PERFIN_USU_LOGIN Cadena de caracteres
FINANZAS PERFIN_ANULADO {S,N}
PERSONAL_ PERSUM_USU_LOGIN Cadena de caracteres
SUMINISTROS PERSUM_TIPO {COORDINADOR_SUMINISTROS,
GERENTE_LOGISTICA,
ANALISTA_SUMINISTROS}
PERSUM_ANULADO {S,N}
PROVEEDOR PRO_PROVEEDOR Cadena de caracteres
PRO_RAZON_SOCIAL Cadena de caracteres
PRO_RIF Cadena de caracteres
PRO_NIT Cadena de caracteres
PRO_DIRECCION Cadena de caracteres
PRO_FAX Cadena de caracteres
PRO_CELULAR1 Cadena de caracteres
PRO_CELULAR2 Cadena de caracteres
PRO_TELEFONO1 Cadena de caracteres
PRO_TELEFONO2 Cadena de caracteres
PRO_TELEFONO3 Cadena de caracteres
PRO_PERSONA_CONTACTO Cadena de caracteres
PRO_WEB Cadena de caracteres
PRO_TIPO_MERCANCIA Cadena de caracteres
PRO_CORREO_ELECTRONICO Cadena de caracteres
PRO_ANULADO {S,N}
REEMBOLSA REE_DEV_NUMERO Entero
REE_NOTREC_CODIGO Entero
REE_INS_CODIGO Entero
REE_CANTIDAD Entero
REE_ANULADO {S,N}
REE_MONTO Número Decimal
REGISTRA REG_NOTREC_CODIGO Entero
REG_INS_CODIGO Entero
REG_CANTIDAD Entero
REG_CANTIDAD_CHEQUEO Entero
SECCIONES SEC_CODIGO Entero
SEC_CENCOS_CODIGO Cadena de caracteres
SEC_NOMBRE Cadena de caracteres
SEC_ANULADO {S,N}
SE_ SECONEN_SOLCOT_CODIGO Entero
CONVIERTE_ SECONEN_ORDCOM_NUMERO Entero
EN SECONEN_ANULADO {S,N}
SOLICITA SOL_PEDINT_CODIGO Entero
SOL_INS_CODIGO Entero
SOL_CANTIDAD Entero
SOL_ANULADO {S,N}
SOLICITUD_ SOLCOT_CODIGO Entero
COTIZACION SOLCOT_SUPSUM_USU_LOGIN Cadena de caracteres
SOLCOT_SUPSUM_TIPO {COORDINADOR_SUMINISTROS,
GERENTE_LOGISTICA}
SOLCOT_FECHA_SOLICITUD Fecha
SOLCOT_FECHA_ENTREGA Fecha
SUMINISTRA SUM_PRO_NUMERO Cadena de caracteres
SUM_INS_CODIGO Entero
SUM_ANULADO {S,N}
© CENTROBECO, C.A. 2007 Departamento de Sistemas Página 85
Sistema de Orden de Compras, Despacho e Inventario Versión: 3.1
de Suministros, Activos y Servicios Fecha: 30/05/2007
SOCDISAS
Documento de Arquitectura
• La cantidad cotizada por insumo en una solicitud de cotización, no puede ser negativa
(∀s,i,c |s ∈ SOLICITUD_COTIZACION ^ i ∈ INSUMO ^ c ∈ COTIZA ^
c.COT_SOLCOT_CODIGO = s.SOLCOT_CODIGO ^
c.COT_INS_CODIGO = i.INS_CODIGO:
c.COT_CANTIDAD ≥ 0)
• La cantidad por insumo que se despacha a un centro de costo, no puede ser negativa
(∀c,i,s,n,d |i ∈ INSUMO ^ s ∈ SECCIONES ^
n ∈ NOTA_RECIBO ^ d ∈ DISTRIBUIR ^
d.DIS_INS_CODIGO = i.INS_CODIGO ^
d.DIS_NOTREC_CODIGO = n.NOTREC_CODIGO ^
d.DIS_SEC_CODIGO = s.SEC_CODIGO ^
d.DIS_SEC_CENCOS_CODIGO = s.SEC_CENCOS_CODIGO:
d.DIS_CANTIDAD ≥ 0)
• La cantidad que se registra por insumo en una nota de recibo, no puede ser negativa
(∀i,n,r | i ∈ INSUMO ^ n ∈ NOTA_RECIBO ^ r ∈ REGISTRA ^
r.REG_NOTREC_CODIGO = n.NOTREC_CODIGO ^
r.REG_INS_CODIGO = i.INS_CODIGO:
r.REG_CANTIDAD ≥ 0)
• Para una nota de recibo, el total que se devuelve no puede ser mayor que lo recibido
(∀i,d,nr,r,s | i ∈ INSUMO ^ d ∈ DEVOLUCION ^ nr ∈ NOTA_RECIBO ^
r ∈ REEMBOLSA ^ s ∈ REGISTRA ^
i.INS_CODIGO = r.REE_INS_CODIGO ^
d.DEV_NUMERO = r.REE_DEV_NUMERO ^
nr.NOTREC_CODIGO = r.REE_NOTREC_CODIGO ^
nr.NOTREC_CODIGO = s.REG_NOTREC_CODIGO:
Σ(r.REE_CANTIDAD) ≤ s.REG_CANTIDAD)
• La suma del presupuesto de todos los centro de costo para una misma cuenta, debe
ser igual al presupuesto total de la cuenta asociada
(∀i,j,c,p | i ∈ CENTRO_COSTO ^ j ∈ CUENTA_CONTABLE ^ p ∈
PRESUPUESTO ^ c ∈ CONTABILIZA ^
c.CON_CENCOS_CODIGO = i.CENCOS_CODIGO ^
j.CUECON_CODIGO = c.CON_CUECON_CODIGO ^
j.CUECON_CODIGO = p.PRE_CUECON_CODIGO ^
c.CON_CUECON_CODIGO = p.PRE_CUECON_CODIGO ^
c.CON_PRE_FECHA_INICIO_MES = p.PRE_FECHA_INICIO_MES ^
c.CON_PRE_FECHA_FIN_MES = p.PRE_FECHA_FIN_MES:
Σ(c.CON_PRESUPUESTO) = p.PRE_PRESUPUESTO )
• El monto de un adelanto, no debe ser mayor que el monto total de la orden de compra
asociada
(∀a,o | a ∈ ADELANTO ^ o ∈ ORDEN_COMPRA ^
a.ADE_ORDCOM_NUMERO = o.ORDCOM_NUMERO:
a.ADE_MONTO ≤ o.ORDCOM_MONTO)
• El monto total de una devolución, no debe ser mayor al monto total de la nota de
recibo asociada
(∀i,d,nr,r,s | i ∈ INSUMO ^ d ∈ DEVOLUCION ^ nr ∈ NOTA_RECIBO ^
r ∈ REEMBOLSA ^ s ∈ REGISTRA ^
i.INS_CODIGO = r.REE_INS_CODIGO ^
d.DEV_NUMERO = r.REE_DEV_NUMERO ^
nr.NOTREC_CODIGO = r.REE_NOTREC_CODIGO ^
nr.NOTREC_CODIGO = s.REG_NOTREC_CODIGO:
Σ(r.REE_MONTO) ≤ nr.NOTREC_MONTO)
• El monto total de una nota de recibo es la suma de todos los precios totales por
insumo, registrados en la orden de compra asociada, por la cantidad de recibida para
cada uno
(∀o,n,i,r,j |
o ∈ ORDEN_COMPRA ^ n ∈ NOTA_RECIBO ^ i ∈ INSUMO ^
r ∈ REGISTRA ^ j∈ INCLUYE ^
r.REG_INS_CODIGO = j.INC_INS_CODIGO = i.INS_CODIGO ^
r.REG_NOTREC_CODIGO = n.NOTREC_CODIGO ^
j.INC_ORDCOM_NUMERO = n.NOTREC_ORDCOM_NUMERO = o.ORDCOM_NUMERO:
n.NOTREC_MONTO = Σ (r.REG_CANTIDAD)*(j.INC_PRECIO) )
• El gerente solo puede aprobar pedidos internos del centro de costo que gestiona
(∀p,g,c1,c2 | p ∈ PEDIDO_INTERNO ^ g ∈ GERENTE ^
c1 ∈ CENTRO_COSTO ^ c2 ∈ COLABORADOR ^
p. PEDINT_GER_LOGIN = g.GER_USU_LOGIN ^
p.PEDINT_COL_USU_LOGIN = c2.COL_USU_LOGIN ^
c2.COL_SEC_CENCOS_CODIGO = c1.CENCOS_CODIGO:
c1.CENCOS_GER_USU_LOGIN = g.GER_USU_LOGIN )
• Una cuenta con presupuesto asignado para el año fiscal actual, no puede estar inactiva
(∀c, p | c ∈ CUENTAS_CONTABLES ^ p ∈ PRESUPUESTO ^
p.PRE_CUECON_CODIGO = c.CUECON_CODIGO ^
p.PRE_FECHA_INICIO_MES ≥ FECHA_INICIO_UTIMO_AÑO_FISCAL ^
p.PRE_FECHA_FIN_MES ≤ FECHA_FIN_UTIMO_AÑO_FISCAL:
⇒ c.CUECON_ANULADO = “ACTIVA”)
• No se puede emitir una devolución de una nota de recibo, después de que haya sido
pagada
(∀n, d, r | n ∈NOTA_RECIBO ^ p∈PAGO ^
p.PAG_NOTREC_CODIGO = n. NOTREC_CODIGO:
¬ (∃ d, e | d ∈ DEVOLUCIONES ^ r ∈ REEMBOLSA:
r.REE_DEV_NUMERO = d. DEV_NUMERO ^
r.REE_NOTREC_CODIGO = n. NOTREC_CODIGO) )
• No se puede distribuir más insumos de los que hay en una nota de recibo
(∀ r, d | r ∈ REGISTRA ^ d ∈ DISTRIBUIR ^
r.REG_NOTREC_CODIGO = d.DIS_NOTREC_CODIGO ^
r.REG_INS_CODIGO = d.DIS_INS_CODIGO:
Σ [d.DIS_CANTIDAD] ≤ r.REG_CANTIDAD)
© CENTROBECO, C.A. 2007 Departamento de Sistemas Página 91
Sistema de Orden de Compras, Despacho e Inventario Versión: 3.1
de Suministros, Activos y Servicios Fecha: 30/05/2007
SOCDISAS
Documento de Arquitectura
1100.. D
Deesseem
mppeeññoo
El sistema debe ser confiable, razón por la cual se requiere que la concurrencia entre
los usuarios no afecte la consistencia de los datos que el mismo maneja. El sistema debe hacer
las operaciones de forma rápida (máximo un minuto por operación), y consumir la menor
cantidad de recursos en el servidor, ya que en éste operan también otras aplicaciones de igual
o mayor complejidad.
1111.. CCaalliiddaadd
A lo largo del ciclo de vida de una aplicación, el uso del modelo de 3 capas brinda
beneficios tales como la extensibilidad, fiabilidad, transportabilidad, simplicidad de
administración y mantenimiento, flexibilidad, reusabilidad y escalabilidad del sistema.
Uno de los aspectos claves del diseño de una aplicación es su arquitectura. Esta define
cual es el objetivo de cada uno de los componentes del sistema y el modo en que estos se
relacionan e interactúan entre sí. Por ello es importante que esta y cualquier aplicación cuente
con la adecuada arquitectura, la que se hace referencia en los párrafos anteriores, de lo
contrario el trabajo puede llegar a requerir hasta una reingeniería total de la aplicación,
incluyendo un diseño desde cero y por supuesto la nueva construcción del sistema.
Igualmente, como se evidenció a lo largo del documento, hemos agrupado todos los
casos de uso en diversos módulos. De esta manera, un proyecto de gran envergadura como
este, puede dividirse en pequeños proyectos más simples y manejables, que se pueden
implementar en forma progresiva, agregando o modificando servicios según la medida de
crecimiento del sistema.