[Php-avanzado] Requerimientos del sistema
Leonardo Tadei - Pegasus Tech Supply
leonardot en pegasusnet.com.ar
Lun Jul 2 20:36:16 ART 2012
Hola David,
El lun, 02-07-2012 a las 15:26 -0300, David Barraud escribió:
> 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.
Mmm...
> 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.
Se puede mantener: no es la idea de que trabajen de gusto... ahora
bien, los cambios en el código serán tantos y con las funciones de
buscar y reemplazar en proyectos enteros de los editores de código,
tampoco es para tanto.
Si los nombres no coinciden con la SRS, poné una aclaración en alguna
parte y listo.
> 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.
Mmmm... entonces te están faltando tablas en la normalización. Te lo
detallo más abajo:
> Normalización
>
> departamentos(id_depto, nombre)
>
> categoría(id_categoria, nombre)
>
> producto(id_producto, id_categoria, imagen, nombre)
Hasta acá, está bien.
> alta_insumo(id_alta, fecha, cantidad, id_producto)
Cuando Normalizás un comprobante de casi cualquier tipo, te quedan dos
tablas David: una de la cabecera del comprobante, y otra con los Items
que la forman. Esto es porque el ID de alta y la fecha es para todos la
misma, y el Insumo y la cantidad de cada uno son los Items del
comprobante.
Por otra parte, en los Items tenés que guardar los datos mínimos para
identificar al Insumo y no solo el ID, para cumplir con tu RF3 y poder
borrar Insumos sin que se pierdan los detalles de los mismos.
En este caso podría ser:
# RemitoAltaInsumos
id
fecha
# RemitoAltaInsumosDetalle
id
id_remito_alta
id_insumo
nombre
cantidad
De esta forma, además de que es lo que surge de la normalización, podés
ver todos los Insumos que fueron dados de alta con el mismo comprobante.
> solicitudes (id_solicitudes, fecha_inicio, fecha_fin, problema,
> solución, id_estado).
Por lo que decís más arriba, si la Solicitud da de baja Insumos, tu
idea es generar un comprobante de baja de Insumos... esto no se
desprende de la SRS pero digamos que es una idea de implementación...
(sigo abajo)
> estados(id_estado, estado).
>
> baja_insumos (id_baja, fecha, cantidad, id_producto, id_solicitudes).
Bueno, este comprobante tiene que tener la misma forma en los
almacenamientos que el que pongo arriba. Ambos pueden tener más datos,
pero no menos.
Por otra parte, acá figura el id_solicitud (supongo que el plural en el
campo es un error de tipeo y no que un comprobante de baja hace
referencia a varias solicitudes... si supongo mal, hará falta una tabla
más todavía para referenciar a las Solicitudes correspondientes), pero
este comprobante según me aclaraste no va a ser usado solo contra la
Solicitud, sino que podrá ser usado para dar de baja roturas o por otro
concepto, pero si es así, el id_solicitud va a ser nulo en algunos
casos, y faltaría un campo en la cabecera del comprobante para indicar
aunque sea a mano cuál es el motivo de la baja.
Esta idea de implementación es válida, pero es mucho más compleja de
implementar dar de baja Insumos vía la propia Solicitud. Tu cálculo de
stock casi no cambia (Remitos Alta - Solicitudes - Remitos Baja) pero
ahora te ganás el tener que manejar en el código los casos en que la
baja sea por usar el Insumo en respuesta a una Solicitud de Reparación y
las bajas por otros motivos.
A mi me da lo mismo, pero no suele ser buena idea plantear cosas más
complejas de lo necesario.
Mandame de nuevo la Normalización, cambiá el asunto del mail y
seguimos ;-)
> 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
>
> _______________________________________________
> 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
Blog: http://blog.pegasusnet.com.ar
Firma pública: http://www.pegasusnet.com.ar/LeonardoTadei-public.key
Más información sobre la lista de distribución Php-avanzado