[Php-avanzado] Requerimientos del sistema

[David Barraud]

Hola Leo, muchas gracias por la paciencia te envío las correcciones aunque
todavái estoy en dudas con respecto al punto de la Alta de insumos.

*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 emitir un comprobante de alta de insumos[3].

5.       El sistema debe mostrar estados de las solicitudes de trabajo.

6.       El sistema debe asentar solicitudes de trabajo con su departamento
[1] , insumos [3] utilizados y estados[5].

a.       El sistema debe asentar una solicitud [6] pedida y cambiar su
estado [5] a “pendiente”.

b.      El sistema debe tomar solicitudes [6] pendientes [6.a] y cambiar su
estado [5] a “en proceso” si se toma la decisión de trabajar en esta
solicitud.

c.       El sistema debe cambiar el estado [5] de las solicitudes [6] en
proceso [6.b] y pasarlos a “solucionado” si se ha resuelto el problema.

d.      El sistema debe cambiar el estado [5] de las solicitudes [6]
“pendiente” [6.a], “en proceso”[6.b] a “no resuelto” si es que el problema
de la solicitud[6] no tiene solución.

7.       El sistema debe listar la solicitudes [6] de acuerdo a su
estado[5].

 *Diccionario*
*Departamentos (nombre).* Áreas de trabajo que tienen un problema y
realizan una solicitud de trabajo.
*Categorias (nombre)*. Tipos de insumos informáticos.
*Insumos(fecha,nombre, cantidad, imagen).* Insumos informáticos (teclados,
mouses, monitores, fuentes, etc.).
*solicitudes (fecha_inicio, fecha_fin, problema, solución).* 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".


No logro entender todavía el razonamiento de la alta de los insumos.
Yo tengo la tabla insumos donde cuando ingreso uno nuevo se coloca la
fecha, el nombre, la categoria, la cantidad y la imagen de ese insumo. No
es esto suficiente para el comprobante de alta de insumos? o requiere de
otra tabla adicional?
O lo que hay que hacer es tener una tabla insumos con el nombre, la
categoria, la imagen pero sin la cantidad ni la fecha de ingreso del mismo
al stock y tener otra tabla ponele alta_insumos en donde esté el nombre del
insumo, la fecha de ingreso al stock, y la cantidad?
Muchas gracias!





El 23 de junio de 2012 18:02, Leonardo Tadei - Pegasus Tech Supply <
leonardot en pegasusnet.com.ar> escribió:

> 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
>
> _______________________________________________
> Php-avanzado mailing list
> Php-avanzado en pato2.fi.mdp.edu.ar
> http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://www3.fi.mdp.edu.ar/pipermail/php-avanzado/attachments/20120624/25ed0140/attachment.html>