[Php-avanzado] Requerimientos del sistema

David Barraud davidbarraud en gmail.com
Lun Jul 2 15:26:05 ART 2012


Leo: te estoy pasando la Normalización y quiero aclararte un detalle.
En el diccionario de datos yo tenía un ítem insumos pero como he
re-utilizado el proyecto de la primera etapa del curso, ya había definido
las tablas como producto y no insumos, así mismo tengo una tabla
"categoria" y no "categorias" con s como debiera ser.
Como ya tengo código desarrollado va a ser un lío cambiar los nombres de
las tablas y las referencias a las mismas dentro de este código y necesito
consultarte para ver si hay que cambiarlas sí o sí o se puede mantener esta
inconsistencia de nombres.
La tabla producto (que en el diccionario era insumos) guarda los atributos
ahí escritos y no la cantidad ya qeu a la misma la vamos a sacar de la
diferencia entre la tabla alta_insumos y baja_insumos.
La tabla solicitudes no guarda ni el producto ni la cantidad ya que esos
datos son guardados en la tabla baja_insumos y pueden ser leídos desde ahí
al momento de listar las solicitudes.


Normalización

*departamentos*(id_depto, nombre)

*categoría*(id_categoria, nombre)

*producto*(id_producto, id_categoria, imagen, nombre)

*alta_insumo*(id_alta, fecha,  cantidad,  id_producto)

*solicitudes* (id_solicitudes, fecha_inicio, fecha_fin, problema, solución,
id_estado).

*estados*(id_estado,  estado).

*baja_insumos* (id_baja, fecha, cantidad, id_producto, id_solicitudes).




El 30 de junio de 2012 12:37, Leonardo Tadei - Pegasus Tech Supply <
leonardot en pegasusnet.com.ar> escribió:

> Hola David,
>
>         La SRS se ve consistente y sin ambigüedades.
>         La guardo como futura referencia.
>
>         Es más propio en el RF4 y RF8 que usaras "asentar" en vez de
> "emitir",
> porque no se puede emitir no implica que las cosas se almacenen, pero es
> un detalle menor y sé que la idea es guardar los comprobantes de altas y
> de baja.
>
>         Ahora, a normalizar!
>
> El vie, 29-06-2012 a las 12:08 -0300, David Barraud escribió:
> > Leo, te envío entonces las correcciones finales para luego avanzar en
> > la normalización.
> >
> > Agregué el mecanismo para la baja 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].
> >
> > 8.      El sistema debe emitir un comprobante de baja de insumos[3].
> >
> >
> >
> > 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,categoria). Insumos
> > informáticos (teclados, mouses, monitores, fuentes, etc.).
> >
> > alta_insumos (fecha, cantidad, insumos) Es el comprobante de alta de
> > insumos,  la cantidad de insumos que ingresan al stock
> > solicitudes (fecha_inicio, fecha_fin, problema, solución, insumo,
> > cantidad). 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".
> > baja_insumos (fecha, cantidad, insumos) Es el comprobante de baja de
> > insumos,  la cantidad de insumos que salen del stock.
> >
> >
> >
> >
> > El 29 de junio de 2012 09:19, Leonardo Tadei - Pegasus Tech Supply
> > <leonardot en pegasusnet.com.ar> escribió:
> >         Hola David,
> >
> >         El vie, 29-06-2012 a las 08:59 -0300, David Barraud escribió:
> >         > Hola Leo, supongo que cuando me enviaste la corrección no
> >         habias leído
> >         > todas las especificaciones porque en la RF4 puse el
> >         mecanismo para dar
> >         > de alta los insumos.
> >
> >
> >                Sí, la había leido, pero me pareció importante
> >         detenernos en tu duda y
> >         aclarar ese punto, para seguir avanzando sobre seguro.
> >
> >         > Igualmente te paso nuevamente las correcciones para ir
> >         avanzando.
> >         > Entiendo la explicación que me diste y espero haber hecho
> >         las
> >         > correcciones apropiadas.
> >
> >
> >                Te hago un par de observaciones abajo, intercaladas con
> >         tu texto.
> >
> >         > Ahora surge una pregunta del sistema. Hay un mecanismo para
> >         dar de
> >         > alta a los  insumos y es el "comprobante de alta de insumos"
> >         y se
> >         > desprende de las especificaciones que el mecanismo para
> >         darlo de baja
> >         > es el uso que se le dá en la solicitud. Ahora, se podría
> >         tener otro
> >         > mecanismo de baja, algo así como un "comprobante de baja de
> >         insumos"?
> >         > estoy pensando en un caso en el que el insumo se tenga que
> >         dar de baja
> >         > por algún hecho catastrófico por ejemplo se rompió un caño
> >         de agua, se
> >         > moja el insumo y hay que tirarlo. En este caso una solicitud
> >         de
> >         > trabajo no sería la solución sino que se podría tener algún
> >         mecanismo
> >         > de baja alternativo a la solicitud.
> >         > No sé que te parece.
> >
> >
> >                Me parece bien! Sí se darán casos así, es importante
> >         contemplarlos.
> >         Tiene que haber al menos un mecanismo para altas de Insumos y
> >         al menos
> >         uno para bajas de Insumos, pero no hay restricciones técnicas
> >         para que
> >         haya varios.
> >
> >
> >         > 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, imagen). Insumos informáticos
> >         (teclados, mouses,
> >         > monitores, fuentes, etc.).
> >
> >
> >                Acá te falta la Categoría en la lista de atributos.
> >
> >         > alta_insumos (fecha, cantidad) Es el comprobante de alta de
> >         insumos,
> >         > la cantidad de insumos que ingresan al stock.
> >
> >
> >                Acá te faltan los Insumos en la lista de atributos.
> >
> >         > solicitudes (fecha_inicio, fecha_fin, problema, solución).
> >         Pedidos de
> >         > trabajo que hacen los departamentos cuando hay algún
> >         problema para
> >         > resolver.
> >
> >
> >                Acá te faltan los Insumos  y la cantidad de cada uno en
> >         la lista de
> >         atributos.
> >
> >         > estados( estado). Vista actual del pedido de trabajo. El
> >         estado pueder
> >         > ser: "No resuelto", "En proceso", “pendiente”o
> >         "Solucionado".
> >         >
> >         >
> >         > Muchas gracias.
> >
> >
> >                Por nada!
> >                Con estas pavadas deberíamos estar terminando...
> >
> >         --
> >         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
> >
> > _______________________________________________
> > Php-avanzado mailing list
> > Php-avanzado en pato2.fi.mdp.edu.ar
> > http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado
>
> --
>
> Leonardo Tadei
> leonardot en pegasusnet.com.ar
> Pegasus Tech Supply
> Tel: (+54)(+223) 471-2880
> La Salle 1131 - Mar del Plata - Argentina
> http://www.pegasusnet.com.ar
> http://www.grupopegasus.com
> 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/20120702/293a24a3/attachment-0001.html>


Más información sobre la lista de distribución Php-avanzado