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.<br>Igualmente te paso nuevamente las correcciones para ir avanzando.<br>
Entiendo la explicación que me diste y espero haber hecho las correcciones apropiadas.<br>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.<br>
No sé que te parece.<br><br><br><br>
<p class="MsoNormal" style="margin-bottom:0cm;margin-bottom:.0001pt"><b>Requerimientos
funcionales:</b></p>
<p class="MsoListParagraphCxSpFirst" style="margin-bottom:0cm;margin-bottom:.0001pt"><span style><span style>1.<span style="font:7.0pt "Times New Roman"">
</span></span></span>El sistema debe gestionar departamentos de
trabajo.</p>
<p class="MsoListParagraphCxSpMiddle" style="margin-bottom:0cm;margin-bottom:.0001pt"><span style><span style>2.<span style="font:7.0pt "Times New Roman"">
</span></span></span>El sistema debe gestionar categorías de insumos.</p>
<p class="MsoListParagraphCxSpMiddle" style="margin-bottom:0cm;margin-bottom:.0001pt"><span style><span style>3.<span style="font:7.0pt "Times New Roman"">
</span></span></span>El sistema debe gestionar insumos con sus
categorías [2].</p>
<p class="MsoListParagraphCxSpMiddle" style="margin-bottom:0cm;margin-bottom:.0001pt"><span style><span style>4.<span style="font:7.0pt "Times New Roman"">
</span></span></span>El sistema debe emitir un comprobante de alta de
insumos[3].</p>
<p class="MsoListParagraphCxSpMiddle" style="margin-bottom:0cm;margin-bottom:.0001pt"><span style><span style>5.<span style="font:7.0pt "Times New Roman"">
</span></span></span>El sistema debe mostrar estados de las solicitudes
de trabajo.</p>
<p class="MsoListParagraphCxSpMiddle" style="margin-bottom:0cm;margin-bottom:.0001pt"><span style><span style>6.<span style="font:7.0pt "Times New Roman"">
</span></span></span>El sistema debe asentar solicitudes de trabajo
con su departamento [1] , insumos [3] utilizados y estados[5].</p>
<p class="MsoListParagraphCxSpMiddle" style="margin-top:0cm;margin-right:0cm;margin-bottom:0cm;margin-left:72.0pt;margin-bottom:.0001pt"><span style><span style>a.<span style="font:7.0pt "Times New Roman"">
</span></span></span>El sistema debe asentar una solicitud [6] pedida
y cambiar su estado [5] a “pendiente”.</p>
<p class="MsoListParagraphCxSpMiddle" style="margin-top:0cm;margin-right:0cm;margin-bottom:0cm;margin-left:72.0pt;margin-bottom:.0001pt"><span style><span style>b.<span style="font:7.0pt "Times New Roman"">
</span></span></span>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.</p>
<p class="MsoListParagraphCxSpMiddle" style="margin-top:0cm;margin-right:0cm;margin-bottom:0cm;margin-left:72.0pt;margin-bottom:.0001pt"><span style><span style>c.<span style="font:7.0pt "Times New Roman"">
</span></span></span>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.</p>
<p class="MsoListParagraphCxSpMiddle" style="margin-top:0cm;margin-right:0cm;margin-bottom:0cm;margin-left:72.0pt;margin-bottom:.0001pt"><span style><span style>d.<span style="font:7.0pt "Times New Roman"">
</span></span></span>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. </p>
<p class="MsoListParagraphCxSpLast" style="margin-bottom:12.0pt;line-height:normal"><span style><span style>7.<span style="font:7.0pt "Times New Roman"">
</span></span></span>El sistema debe listar la solicitudes [6] de
acuerdo a su estado[5].<br style>
<br style>
</p>
<b><span style="font-size:11.0pt;line-height:115%;font-family:"Calibri","sans-serif"">Diccionario</span></b><span style="font-size:11.0pt;line-height:115%;font-family:"Calibri","sans-serif""><br>
<b style>Departamentos (nombre).</b> Áreas de
trabajo que tienen un problema y realizan una solicitud de trabajo.<br>
<b style>Categorias (nombre)</b>. Tipos de
insumos informáticos.<br>
<b style>Insumos(fecha,nombre, imagen).</b>
Insumos informáticos (teclados, mouses, monitores, fuentes, etc.).<br><b>alta_insumos (fecha, cantidad) </b>Es el comprobante de alta de insumos, la cantidad de insumos que ingresan al stock.<br>
<b style>solicitudes (fecha_inicio, fecha_fin,
problema, solución).</b> Pedidos de trabajo que hacen los departamentos cuando
hay algún problema para resolver.<br>
<b style>estados( estado).</b> Vista actual del
pedido de trabajo. El estado pueder ser: "No resuelto", "En
proceso", “pendiente”o "Solucionado".<br style>
<br style>
</span><br>Muchas gracias.<br><br><br><br><div class="gmail_quote">El 24 de junio de 2012 23:21, Leonardo Tadei - Pegasus Tech Supply <span dir="ltr"><<a href="mailto:leonardot@pegasusnet.com.ar" target="_blank">leonardot@pegasusnet.com.ar</a>></span> escribió:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hola David,<br>
<br>
<br>
El dom, 24-06-2012 a las 17:11 -0300, David Barraud escribió:<br>
<div class="im">> Hola Leo, muchas gracias por la paciencia te envío las correcciones<br>
> aunque todavái estoy en dudas con respecto al punto de la Alta de<br>
> insumos.<br>
<br>
</div> Paso acá tus preguntas de abajo para responderlas:<br>
<div class="im"><br>
> No logro entender todavía el razonamiento de la alta de los insumos.<br>
> Yo tengo la tabla insumos donde cuando ingreso uno nuevo se coloca la<br>
> fecha, el nombre, la categoria, la cantidad y la imagen de ese insumo.<br>
> No es esto suficiente para el comprobante de alta de insumos? o<br>
> requiere de otra tabla adicional?<br>
> O lo que hay que hacer es tener una tabla insumos con el nombre, la<br>
> categoria, la imagen pero sin la cantidad ni la fecha de ingreso del<br>
> mismo al stock y tener otra tabla ponele alta_insumos en donde esté<br>
> el nombre del insumo, la fecha de ingreso al stock, y la cantidad?<br>
> Muchas gracias!<br>
<br>
</div> En la SRS, estás definiendo el problema. Creo que gran parte de tu<br>
confusión es estar pensando en esta etapa en "tablas"... las tablas<br>
surgirán de la Normalización (que no es un proceso creativo, sino el<br>
aplicar una serio de reglas) luego de definir qué es lo que tiene que<br>
hacer el software.<br>
La Normalización dice que hay que tomar la lista de cosas a guardar (la<br>
cuál será la lista de atributos que tengas enumerada en el diccionario)<br>
y a esta lista aplicarle las 3 reglas de cada una de las formas<br>
normales. Me parece que estás queriendo normalizar una lista de<br>
atributos incompleta, porque tu SRS tiene omisiones y así como está, el<br>
sistema no hará todo lo que tiene que hacer.<br>
<br>
Por lo tanto David, hablar acá de "tablas" no tiene sentido, pero lo<br>
peor es que lleva a confusión :(<br>
<br>
Intentaré elaborar la cuestión con un par de preguntas y respuestas que<br>
te daré yo en los primeros casos:<br>
<br>
1) Tu sistema gestiona Insumos?<br>
R. Sí.<br>
<br>
2) Los Insumos (las cosas) y el Stock de los Insumos (cuanto hay de cada<br>
cosa) son el mismo concepto?<br>
R. No!.<br>
<br>
3) Te hace falta llevar el stock de los Insumos?<br>
R. Sí.<br>
<br>
4) Cómo se calcula el Stock de Insumos?<br>
R. Es la suma de todas las altas de Insumos, menos la suma de todas las<br>
bajas de insumos.<br>
<br>
5) Tenés un RF que especifique la gestión de Insumos?<br>
R. Si, el RF3<br>
<br>
6) Cuál es el RF que especifique que tenés que mostrar la cantidad de<br>
cada Insumo (Stock) ?<br>
R. El RF3 no habla de esto, pero en el diccionario del RF3 aparece la<br>
cantidad, así que hay que asumir que en la lista por pantalla de los<br>
Insumos aparecerá la cantidad (incluso si un Insumo ya fue borrrado)<br>
<br>
7) cuál es el mecanismo en tu software para dar de baja Insumos del<br>
Stock?<br>
R. Serán dados de baja del Stock los Insumos que figuren en el RF6.<br>
<br>
8) cuál es el mecanismo en tu software para dar de alta Insumos del<br>
Stock?<br>
R. Ninguno!<br>
<br>
<br>
Creo David que si te respondés a la pregunta que acá tiene por<br>
respuesta "ninguno", encontrarás las especificaciones omitidas de tu<br>
SRS.<br>
Además, así como está, el RF3 es muy complejo de implementar, porque<br>
tenés que mostrar en la lista cosas que pueden dejar de existir, porque<br>
el RF3 dice que se pueden borrar Insumos, y tu sistema deberá funcionar<br>
bien incluso si se quieren borrar estas cosas.<br>
<br>
Una vez terminada la SRS, y no antes, tenemos que Normalizar. Recordá<br>
por favor que estás definiendo lo que hay que hacer, y no diciendo cómo<br>
lo vas a hacer.<br>
El "qué" será la SRS.<br>
El "cómo" será tu software.<br>
<br>
<br>
Seguimos!<br>
<div class="HOEnZb"><div class="h5"><br>
> Requerimientos funcionales:<br>
><br>
> 1. El sistema debe gestionar departamentos de trabajo.<br>
><br>
> 2. El sistema debe gestionar categorías de insumos.<br>
><br>
> 3. El sistema debe gestionar insumos con sus categorías [2].<br>
><br>
> 4. El sistema debe emitir un comprobante de alta de insumos[3].<br>
><br>
> 5. El sistema debe mostrar estados de las solicitudes de trabajo.<br>
><br>
> 6. El sistema debe asentar solicitudes de trabajo con su<br>
> departamento [1] , insumos [3] utilizados y estados[5].<br>
><br>
> a. El sistema debe asentar una solicitud [6] pedida y cambiar su<br>
> estado [5] a “pendiente”.<br>
><br>
> b. El sistema debe tomar solicitudes [6] pendientes [6.a] y<br>
> cambiar su estado [5] a “en proceso” si se toma la decisión de<br>
> trabajar en esta solicitud.<br>
><br>
> c. El sistema debe cambiar el estado [5] de las solicitudes [6]<br>
> en proceso [6.b] y pasarlos a “solucionado” si se ha resuelto el<br>
> problema.<br>
><br>
> d. El sistema debe cambiar el estado [5] de las solicitudes [6]<br>
> “pendiente” [6.a], “en proceso”[6.b] a “no resuelto” si es que el<br>
> problema de la solicitud[6] no tiene solución.<br>
><br>
> 7. El sistema debe listar la solicitudes [6] de acuerdo a su<br>
> estado[5].<br>
><br>
><br>
><br>
> Diccionario<br>
> Departamentos (nombre). Áreas de trabajo que tienen un problema y<br>
> realizan una solicitud de trabajo.<br>
> Categorias (nombre). Tipos de insumos informáticos.<br>
> Insumos(fecha,nombre, cantidad, imagen). Insumos informáticos<br>
> (teclados, mouses, monitores, fuentes, etc.).<br>
> solicitudes (fecha_inicio, fecha_fin, problema, solución). Pedidos de<br>
> trabajo que hacen los departamentos cuando hay algún problema para<br>
> resolver.<br>
> estados( estado). Vista actual del pedido de trabajo. El estado pueder<br>
> ser: "No resuelto", "En proceso", “pendiente”o "Solucionado".<br>
><br>
><br>
> No logro entender todavía el razonamiento de la alta de los insumos.<br>
> Yo tengo la tabla insumos donde cuando ingreso uno nuevo se coloca la<br>
> fecha, el nombre, la categoria, la cantidad y la imagen de ese insumo.<br>
> No es esto suficiente para el comprobante de alta de insumos? o<br>
> requiere de otra tabla adicional?<br>
> O lo que hay que hacer es tener una tabla insumos con el nombre, la<br>
> categoria, la imagen pero sin la cantidad ni la fecha de ingreso del<br>
> mismo al stock y tener otra tabla ponele alta_insumos en donde esté el<br>
> nombre del insumo, la fecha de ingreso al stock, y la cantidad?<br>
> Muchas gracias!<br>
><br>
><br>
><br>
><br>
><br>
> El 23 de junio de 2012 18:02, Leonardo Tadei - Pegasus Tech Supply<br>
> <<a href="mailto:leonardot@pegasusnet.com.ar">leonardot@pegasusnet.com.ar</a>> escribió:<br>
> Hola David,<br>
><br>
> El vie, 22-06-2012 a las 08:44 -0300, David Barraud escribió:<br>
> > Hola Leo, cambié algunas cosas con respecto a las<br>
> correcciones que me<br>
> > pasaste.<br>
><br>
><br>
> Veamos!<br>
><br>
> > Correcciones<br>
> ><br>
> > Requerimientos funcionales:<br>
> ><br>
> > 1. El sistema debe gestionar departamentos de trabajo.<br>
> ><br>
> > 2. El sistema debe gestionar categorías de insumos.<br>
> ><br>
> > 3. El sistema debe gestionar insumos con sus categorías<br>
> [2].<br>
> ><br>
> > 4. El sistema debe mostrar estados de las solicitudes<br>
> de trabajo.<br>
> ><br>
> > 5. El sistema debe asentar solicitudes de trabajo con<br>
> su<br>
> > departamento [1] e insumos [3] utilizados.<br>
><br>
><br>
> Un detalle menor: falta acá la referencia al Estado...<br>
> igual, mirando<br>
> el desglose que hay debajo, queda claro para quién conoce el<br>
> problema.<br>
><br>
> ><br>
> > a. El sistema debe asentar una solicitud [5] pedida y<br>
> cambiar su<br>
> > estado [4] a “pendiente”.<br>
> ><br>
> > b. El sistema debe tomar solicitudes [5] pendientes<br>
> [5.a] y<br>
> > cambiar su estado [4] a “en proceso” si se toma la decisión<br>
> de<br>
> > trabajar en esta solicitud.<br>
> ><br>
> > c. El sistema debe cambiar el estado [4] de las<br>
> solicitudes [5]<br>
> > en proceso [5.b] y pasarlos a “solucionado” si se ha<br>
> resuelto el<br>
> > problema.<br>
> ><br>
> > d. El sistema debe cambiar el estado [4] de las<br>
> solicitudes [5]<br>
> > “pendiente” [5.a], “en proceso”[5.b] a “no resuelto” si es<br>
> que el<br>
> > problema de la solicitud[5] no tiene solución.<br>
> ><br>
> > 6. El sistema debe listar la solicitudes [5] de acuerdo<br>
> a su<br>
> > estado[4].<br>
> ><br>
> ><br>
> ><br>
> > Diccionario<br>
> > Departamentos (nombre). Áreas de trabajo que tienen un<br>
> problema y<br>
> > realizan una solicitud de trabajo.<br>
> > Categorias (nombre). Tipos de insumos informáticos.<br>
> > Insumos(id_ categoria, nombre, cantidad, imagen). Insumos<br>
> informáticos<br>
> > (teclados, mouses, monitores, fuentes, etc.).<br>
> > solicitudes (fecha_inicio, fecha_fin, problema, id_estado,<br>
> solución,<br>
> > id_insumos_usados). Pedidos de trabajo que hacen los<br>
> departamentos<br>
> > cuando hay algún problema para resolver.<br>
> > estados( estado). Vista actual del pedido de trabajo. El<br>
> estado pueder<br>
> > ser: "No resuelto", "En proceso", “pendiente”o<br>
> "Solucionado".<br>
><br>
><br>
> Recordá David que el Diccionario tiene que tener<br>
> sentido por si mismo y<br>
> ser comprendido por quienes no saben de Software. En este<br>
> contexto, no<br>
> tiene sentido hablar de los ID de nada... sino de la cosa que<br>
> se va a<br>
> usar.<br>
> Además, si esto fuera la normalización, estaría mal.<br>
><br>
> > Hay un detalle que me marcaste tambien: No veo de qué manera<br>
> se dan de<br>
> > alta los Insumos al sistema: tenés un<br>
> > mecanismo solo para darlos de baja, que es la Solicitud de<br>
> Trabajo...<br>
> > te<br>
> > hace falta algo así como un Remito de Alta de Insumos.<br>
> ><br>
> > En qué parte se agregaría el "remito de alta de insumos" en<br>
> el<br>
> > diccionario? porque en las especificaciones se da por<br>
> sentado de que<br>
> > hay que hacer un ABM de los insumos.<br>
><br>
><br>
> Se agragaría como un RF más, y funcionaría como la<br>
> contraparte de las<br>
> Solicitudes de Reparación.<br>
><br>
> Tendría una fecha, unos Insumos y la cantidad que se<br>
> darían de alta.<br>
> Podría llamarse algo así como "Comprobante de ala de stock de<br>
> Insumos" o<br>
> Remito de ala de stock de Insumos".<br>
><br>
> En la especificación sí se da por sentado que hay que<br>
> hacer un ABM de<br>
> Insumos (RF3) y también por ejemplo de Departamentos (RF1),<br>
> pero se hace<br>
> mención a la cantidad de cada uno solo en las Solicitudes de<br>
> Trabajo<br>
> para darlos de baja.<br>
> Se especifica en la RF5 que se utilizan Insumos (baja<br>
> de stock), pero<br>
> lo que te digo es que no hay ningún mecanismo para dar de alta<br>
> el<br>
> stock... y el manejo del stock se desprende claramente como<br>
> necesario en<br>
> el diccionario del RF3 en el que aparece la cantidad (que<br>
> luego cuando<br>
> normalices vas a ver que no quedará ahí).<br>
> En resumen, el concepto de stock (cuantos hay de una<br>
> cosa, sin importar<br>
> qué es esa cosa) está plasmado de forma incompleta si hay una<br>
> baja pero<br>
> no un alta.<br>
><br>
> Supongo que estás pensando en algo así como que al<br>
> tener como atributo<br>
> "cantidad" el Insumo, entrarías ahí y modificarías el valor<br>
> que hay en<br>
> más... pero qué te impediría modificarlo en menos? Si hoy<br>
> agregás 3 y<br>
> ayer 4, hoy hay 7 más, pero no sabés desde cuando ni lo podés<br>
> comparar<br>
> con un comprobante de compra para ver si está bien cargado o<br>
> no... entre<br>
> otros grandes inconvenientes de control que surgirían con el<br>
> concepto de<br>
> stock implementado a medias.<br>
><br>
> A nivel de lo que está planteando, es solo un RF más,<br>
> un par de tablas<br>
> más en la normalización y una interfaz idéntica a la de la<br>
> parte de los<br>
> Insumos de las Solicitudes de Reparación...<br>
><br>
><br>
> Saludos cordiales!<br>
> --<br>
> Leonardo Tadei<br>
> <a href="mailto:leonardot@pegasusnet.com.ar">leonardot@pegasusnet.com.ar</a><br>
> Blog: <a href="http://blog.pegasusnet.com.ar" target="_blank">http://blog.pegasusnet.com.ar</a><br>
> Firma pública:<br>
> <a href="http://www.pegasusnet.com.ar/LeonardoTadei-public.key" target="_blank">http://www.pegasusnet.com.ar/LeonardoTadei-public.key</a><br>
><br>
> _______________________________________________<br>
> Php-avanzado mailing list<br>
> <a href="mailto:Php-avanzado@pato2.fi.mdp.edu.ar">Php-avanzado@pato2.fi.mdp.edu.ar</a><br>
> <a href="http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado" target="_blank">http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado</a><br>
><br>
> _______________________________________________<br>
> Php-avanzado mailing list<br>
> <a href="mailto:Php-avanzado@pato2.fi.mdp.edu.ar">Php-avanzado@pato2.fi.mdp.edu.ar</a><br>
> <a href="http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado" target="_blank">http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado</a><br>
<br>
--<br>
Leonardo Tadei<br>
<a href="mailto:leonardot@pegasusnet.com.ar">leonardot@pegasusnet.com.ar</a><br>
Blog: <a href="http://blog.pegasusnet.com.ar" target="_blank">http://blog.pegasusnet.com.ar</a><br>
Firma pública: <a href="http://www.pegasusnet.com.ar/LeonardoTadei-public.key" target="_blank">http://www.pegasusnet.com.ar/LeonardoTadei-public.key</a><br>
<br>
_______________________________________________<br>
Php-avanzado mailing list<br>
<a href="mailto:Php-avanzado@pato2.fi.mdp.edu.ar">Php-avanzado@pato2.fi.mdp.edu.ar</a><br>
<a href="http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado" target="_blank">http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado</a></div></div></blockquote></div><br>