[Php-avanzado] Requerimientos del sistema

[Leonardo Tadei - Pegasus Tech Supply]

Hola David,

El vie, 22-06-2012 a las 08:44 -0300, David Barraud escribió:
> Hola Leo, cambié algunas cosas con respecto a las correcciones que me
> pasaste. 

	Veamos!

> Correcciones
> 
> Requerimientos funcionales:
> 
> 1.      El sistema debe gestionar departamentos de trabajo.
> 
> 2.      El sistema debe gestionar categorías de insumos.
> 
> 3.      El sistema debe gestionar insumos con sus categorías [2].
> 
> 4.      El sistema debe mostrar estados de las solicitudes de trabajo.
> 
> 5.      El sistema debe asentar solicitudes de trabajo con su
> departamento [1] e  insumos [3] utilizados.

	Un detalle menor: falta acá la referencia al Estado... igual, mirando
el desglose que hay debajo, queda claro para quién conoce el problema.

> 
> a.      El sistema debe asentar una solicitud [5] pedida y cambiar su
> estado [4] a “pendiente”.
> 
> b.     El sistema debe tomar solicitudes [5] pendientes [5.a] y
> cambiar su estado [4] a “en proceso” si se toma la decisión de
> trabajar en esta solicitud.
> 
> c.      El sistema debe cambiar el estado [4] de las solicitudes [5]
> en proceso [5.b] y pasarlos a “solucionado” si se ha resuelto el
> problema.
> 
> d.     El sistema debe cambiar el estado [4] de las solicitudes [5]
> “pendiente” [5.a], “en proceso”[5.b] a “no resuelto” si es que el
> problema de la solicitud[5] no tiene solución. 
> 
> 6.      El sistema debe listar la solicitudes [5] de acuerdo a su
> estado[4].
> 
> 
> 
> Diccionario
> Departamentos (nombre). Áreas de trabajo que tienen un problema y
> realizan una solicitud de trabajo.
> Categorias (nombre). Tipos de insumos informáticos.
> Insumos(id_ categoria, nombre, cantidad, imagen). Insumos informáticos
> (teclados, mouses, monitores, fuentes, etc.).
> solicitudes (fecha_inicio, fecha_fin, problema, id_estado, solución,
> id_insumos_usados). Pedidos de trabajo que hacen los departamentos
> cuando hay algún problema para resolver.
> estados( estado). Vista actual del pedido de trabajo. El estado pueder
> ser: "No resuelto", "En proceso", “pendiente”o "Solucionado".

	Recordá David que el Diccionario tiene que tener sentido por si mismo y
ser comprendido por quienes no saben de Software. En este contexto, no
tiene sentido hablar de los ID de nada... sino de la cosa que se va a
usar.
	Además, si esto fuera la normalización, estaría mal.

> Hay un detalle que me marcaste tambien: No veo de qué manera se dan de
> alta los Insumos al sistema: tenés un
> mecanismo solo para darlos de baja, que es la Solicitud de Trabajo...
> te
> hace falta algo así como un Remito de Alta de Insumos.
> 
> En qué parte se agregaría el "remito de alta de insumos" en el
> diccionario? porque en las especificaciones se da por sentado de que
> hay que hacer un ABM de los insumos.

	Se agragaría como un RF más, y funcionaría como la contraparte de las
Solicitudes de Reparación.

	Tendría una fecha, unos Insumos y la cantidad que se darían de alta.
Podría llamarse algo así como "Comprobante de ala de stock de Insumos" o
Remito de ala de stock de Insumos".

	En la especificación sí se da por sentado que hay que hacer un ABM de
Insumos (RF3) y también por ejemplo de Departamentos (RF1), pero se hace
mención a la cantidad de cada uno solo en las Solicitudes de Trabajo
para darlos de baja. 
	Se especifica en la RF5 que se utilizan Insumos (baja de stock), pero
lo que te digo es que no hay ningún mecanismo para dar de alta el
stock... y el manejo del stock se desprende claramente como necesario en
el diccionario del RF3 en el que aparece la cantidad (que luego cuando
normalices vas a ver que no quedará ahí).
	En resumen, el concepto de stock (cuantos hay de una cosa, sin importar
qué es esa cosa) está plasmado de forma incompleta si hay una baja pero
no un alta. 

	Supongo que estás pensando en algo así como que al tener como atributo
"cantidad" el Insumo, entrarías ahí y modificarías el valor que hay en
más... pero qué te impediría modificarlo en menos? Si hoy agregás 3 y
ayer 4, hoy hay 7 más, pero no sabés desde cuando ni lo podés comparar
con un comprobante de compra para ver si está bien cargado o no... entre
otros grandes inconvenientes de control que surgirían con el concepto de
stock implementado a medias.	

	A nivel de lo que está planteando, es solo un RF más, un par de tablas
más en la normalización y una interfaz idéntica a la de la parte de los
Insumos de las Solicitudes de Reparación...


	Saludos cordiales!
-- 
Leonardo Tadei
leonardot en pegasusnet.com.ar
Blog: http://blog.pegasusnet.com.ar
Firma pública: http://www.pegasusnet.com.ar/LeonardoTadei-public.key