[Php-avanzado] Requerimientos del sistema
Leonardo Tadei - Pegasus Tech Supply
leonardot en pegasusnet.com.ar
Dom Jun 24 23:21:19 ART 2012
Hola David,
El dom, 24-06-2012 a las 17:11 -0300, David Barraud escribió:
> 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.
Paso acá tus preguntas de abajo para responderlas:
> 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!
En la SRS, estás definiendo el problema. Creo que gran parte de tu
confusión es estar pensando en esta etapa en "tablas"... las tablas
surgirán de la Normalización (que no es un proceso creativo, sino el
aplicar una serio de reglas) luego de definir qué es lo que tiene que
hacer el software.
La Normalización dice que hay que tomar la lista de cosas a guardar (la
cuál será la lista de atributos que tengas enumerada en el diccionario)
y a esta lista aplicarle las 3 reglas de cada una de las formas
normales. Me parece que estás queriendo normalizar una lista de
atributos incompleta, porque tu SRS tiene omisiones y así como está, el
sistema no hará todo lo que tiene que hacer.
Por lo tanto David, hablar acá de "tablas" no tiene sentido, pero lo
peor es que lleva a confusión :(
Intentaré elaborar la cuestión con un par de preguntas y respuestas que
te daré yo en los primeros casos:
1) Tu sistema gestiona Insumos?
R. Sí.
2) Los Insumos (las cosas) y el Stock de los Insumos (cuanto hay de cada
cosa) son el mismo concepto?
R. No!.
3) Te hace falta llevar el stock de los Insumos?
R. Sí.
4) Cómo se calcula el Stock de Insumos?
R. Es la suma de todas las altas de Insumos, menos la suma de todas las
bajas de insumos.
5) Tenés un RF que especifique la gestión de Insumos?
R. Si, el RF3
6) Cuál es el RF que especifique que tenés que mostrar la cantidad de
cada Insumo (Stock) ?
R. El RF3 no habla de esto, pero en el diccionario del RF3 aparece la
cantidad, así que hay que asumir que en la lista por pantalla de los
Insumos aparecerá la cantidad (incluso si un Insumo ya fue borrrado)
7) cuál es el mecanismo en tu software para dar de baja Insumos del
Stock?
R. Serán dados de baja del Stock los Insumos que figuren en el RF6.
8) cuál es el mecanismo en tu software para dar de alta Insumos del
Stock?
R. Ninguno!
Creo David que si te respondés a la pregunta que acá tiene por
respuesta "ninguno", encontrarás las especificaciones omitidas de tu
SRS.
Además, así como está, el RF3 es muy complejo de implementar, porque
tenés que mostrar en la lista cosas que pueden dejar de existir, porque
el RF3 dice que se pueden borrar Insumos, y tu sistema deberá funcionar
bien incluso si se quieren borrar estas cosas.
Una vez terminada la SRS, y no antes, tenemos que Normalizar. Recordá
por favor que estás definiendo lo que hay que hacer, y no diciendo cómo
lo vas a hacer.
El "qué" será la SRS.
El "cómo" será tu software.
Seguimos!
> 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
>
> _______________________________________________
> 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