[Php-avanzado] Última versión de la SRS

[Lucas Nastri]

Ok Leo, leí lo que me escribiste ... Voy a citar algunas de tus
correcciones:

> " 1. El sistema debe dar de alta y modificar ciudadanos.
>
>        Ok. Esto significa que no hay como borrar un Ciudadano del
> sistema...
> curioso..."
>"Una respuesta posible es "si lo carga mal, que lo edite" ..."


Claro, lo había pesando de esa manera. Pero después decís:

>si cargo mal un Ciudadano, pero ya estaba cargado bien, cuando
>lo quiero editar no me deja porque ya existe.

No había tenido en cuenta que pasaría eso y tenés razón. Y la solución que
me proponés más adelante:

>Una opción posible es dejarlo ahí y acordarse para usarlo editado en un
>nuevo Ciudadano, pero vamos, es muy engorroso, y se soluciona
>simplemente pudiendo borrarlo.

Si, tenés razón, es una posible solución pero como decís es bastante
engorroso.

>Lo que me parece razonable, es que el sistema no permite borrar un
>Ciudadano usado en un Trámite, pero no que no se pueda borrar nunca...

Ok, es una buena idea. Entonces solo podría borrar ciudadanos que no hayan
iniciado trámites. Me parece bien. Bueno, entonces decido optar por
gestionar ciudadanos!.


Mas adelante también me decís (haciendo referencia a que tampoco podía
borrar trámites):

>no estoy pensando ni para esto ni para 1) que
>cualquiera borre cosas, pero tal vez a nivel administrativo sería útil,

Ok, eso me parece bien, podría borrar los trámites solo algún empleado en
especial que yo le dé esa función. No cualquiera!. Eso está bien. Finalmente
también voy a gestionar trámites.


> "... En estos atributos, hacés referencia a las Localidades y al Nivel
> de
> Estudios y a las Ocupaciones, pero como entidades del sistema, debés
> especificarlas antes que al Ciudadano, para clarificar la lectura de
> la
> SRS. ..."
>
> Ok, ahora que lo mencionás tenés razón, hago referencia como entidades
> del sistema. Pero te hago una pregunta ... Tenía pensado, al momento
> de ingresar la localidad de nacimiento, tenerlas cargadas en el
> sistema (por ejemplo en un combo) y no tener que escribirla (aunque es
> obvio que no voy a tener en mi combo todas las localidades del mundo,
> entonces la que no encontrara en el combo si daría la opción para
> ingresarla).

>       Entonces me estás confirmando que hace falta la "gestión de
>localidades". Fijate que decís "tenerlas cargadas" y que si no está
>tener "la opción para ingresarla".
>       Por errores de tipeo o ajustes del sistema tiene sentido que además
se
>editen y borren, con lo que tenés la gestión completa!


Ok, entiendo pero a nivel administrativo también. No había decidido
gestionar localidades porque no me gustaba la idea de que los empleados
anden "toqueteando" cosas del sistema. No se si me entendés. A lo que voy es
que el sistema solo se utilice para realizar trámites. Y me parecía que no
tenía nada que ver gestionar localidades con realizar trámites. Incluso como
te digo existía la posibilidad de que los empleados hicieran un desorden en
el sistema ingresando, editando y borrando cualquier cosa.Pero a nivel
administrativo podría ser. Ya que solo un empleado podría realizar ésta
función cosa que me parece más razonable.


>  De la misma manera había pensado el nivel de estudios (por ejemplo:
> primario incompleto, primario completo, secundario incompleto ...) .

>       Si bien los niveles de estudio serán más fijos y menos cantidad,
poder
>gestionarlos me sigue pareciendo importante. Imaginate que habías
>cargado "Secundaria básica" en uno y justo ahora desaparece... es
>claramente un dato y no deberías ir a tocar el código para cambiarlo

Bueno, eso es verdad. Me doy cuenta que le faltaban un montón de cosas a mi
srs =( .


>  En cuanto a la ocupación si debería ingresarla.

>Ok. Pero a como vamos, será lo mismo que para las demás cosas.
>Esto es bueno, porque una vez que hacés el AMB, copiando y pegando y
>con pocos cambios hacés los demás ;-)

Tal cuál, pero no pienses que no puse todas éstas gestiones porque no quería
escribir tanto código. La verdad no me dí cuenta.

Más adelante, hablando de la coincidencia entre los usuarios y empleados:

>       Hacerlos coincidir tiene una desventaja grande: si un Empleado se
va,
>no lo podés borrar porque es parte de los Trámites, pero si no lo
>borrás, el Empleado se va a poder seguir logueando en el sistema. Se
>entiende?

Mirá, lo había pensado así. Porque digo ... si elimino un empleado ... ya
fué, cuando grabo el nombre de quien hizo el trámite lo reemplazo por alguna
oración como "Trámite realizado por el Renaper".

>Igual esta decisión es para una etapa posterior a la SRS...

Con ésto te referís a un posible conflicto por relaciones entre tablas de la
base de datos?


Gracias por leer todos los testamentos que te mando :P . Ahora que me hacés
pensar mucho con lo que me escribís me doy cuenta que todavía me falta para
terminar la srs, no estoy tan cerca como pensaba =S . Mañana sin falta la
corrijo y te la mando.

Saludos!.
Lucas.



El 6 de diciembre de 2009 21:57, Leonardo Tadei - Pegasus Tech Supply <
leonardot en pegasusnet.com.ar> escribió:

> Hola Lucas!
>
> El dom, 06-12-2009 a las 16:15 -0300, Lucas Nastri escribió:
> > Leo, te mando la srs modificada y de paso te hago algunas aclaraciones
> > y preguntas ...
> >
> > Te comento intercalado! (jaja, no te enojes, va con onda =D )
>
>         Para nada!
>        Los mails largos me es más fácil leerlos con comentarios
> intercalados
> que todo lo nuevo arriba o abajo, haciendo referencia a cosas que están
> lejos del texto.
>
> > " 1. El sistema debe dar de alta y modificar ciudadanos.
> >
> >        Ok. Esto significa que no hay como borrar un Ciudadano del
> > sistema...
> > curioso..."
> >
> > Así es, no puedo eliminar ciudadanos ... De qué me sirve eliminar
> > ciudadanos si yo tengo que trabajar con ellos?. [..]
>
>        y si por error un usuario carga alguno mal?
>
>        Una respuesta posible es "si lo carga mal, que lo edite", pero tiene
> un
> defecto: si cargo mal un Ciudadano, pero ya estaba cargado bien, cuando
> lo quiero editar no me deja porque ya existe. Qué pasa entonces con ese
> ciudadano ya creado?
>        Una opción posible es dejarlo ahí y acordarse para usarlo editado en
> un
> nuevo Ciudadano, pero vamos, es muy engorroso, y se soluciona
> simplemente pudiendo borrarlo.
>        Lo que me parece razonable, es que el sistema no permite borrar un
> Ciudadano usado en un Trámite, pero no que no se pueda borrar nunca...
>
> > "2. El sistema debe permitir dar de alta y modificar trámites.
> >
> >        Ok. Tampoco vas a permitir que se borren Trámites..."
> >
> > Bueno, si querés puedo gestionar trámites (y dar la opción de
> > eliminarlo). No lo había visto de esa manera porque como debo llevar
> > un historial de los trámites que realizó una persona tengo que hacerlo
> > de todos los trámites que hizo en su vida, dejando de lado si éste
> > trámite no fué bien "hecho".
>
>         Podrías hacer esto igual teniendo en cuenta que no se puedan borrar
> los
> trámites finalizados o en algún estado que indique que están listos.
>        Por otra parte, no estoy pensando ni para esto ni para 1) que
> cualquiera borre cosas, pero tal vez a nivel administrativo sería útil,
> y si el sistema lo tienen que hacer, no importa quien puede y quien no,
> es un requerimiento funcional.
>
> > "... En estos atributos, hacés referencia a las Localidades y al Nivel
> > de
> > Estudios y a las Ocupaciones, pero como entidades del sistema, debés
> > especificarlas antes que al Ciudadano, para clarificar la lectura de
> > la
> > SRS. ..."
> >
> > Ok, ahora que lo mencionás tenés razón, hago referencia como entidades
> > del sistema. Pero te hago una pregunta ... Tenía pensado, al momento
> > de ingresar la localidad de nacimiento, tenerlas cargadas en el
> > sistema (por ejemplo en un combo) y no tener que escribirla (aunque es
> > obvio que no voy a tener en mi combo todas las localidades del mundo,
> > entonces la que no encontrara en el combo si daría la opción para
> > ingresarla).
>
>         Entonces me estás confirmando que hace falta la "gestión de
> localidades". Fijate que decís "tenerlas cargadas" y que si no está
> tener "la opción para ingresarla".
>        Por errores de tipeo o ajustes del sistema tiene sentido que además
> se
> editen y borren, con lo que tenés la gestión completa!
>
>        Gestionar la cosa (ABML) dicho en los requerimientos funcionales, no
> dice absolutamente nada de cómo se hace ni en qué parte del sistema ni
> cómo será esa interfaz para el usuario.
>
>        No gestionarlas, significaría que tenés el <select> con los option
> escritos a mano en HTML y que cambiar cosas ahí es cambiar el código
> HTML de la página...
>
> >  De la misma manera había pensado el nivel de estudios (por ejemplo:
> > primario incompleto, primario completo, secundario incompleto ...) .
>
>         Si bien los niveles de estudio serán más fijos y menos cantidad,
> poder
> gestionarlos me sigue pareciendo importante. Imaginate que habías
> cargado "Secundaria básica" en uno y justo ahora desaparece... es
> claramente un dato y no deberías ir a tocar el código para cambiarlo.
>
> >  En cuanto a la ocupación si debería ingresarla.
>
>         Ok. Pero a como vamos, será lo mismo que para las demás cosas.
>        Esto es bueno, porque una vez que hacés el AMB, copiando y pegando y
> con pocos cambios hacés los demás ;-)
>
> > De esa manera que lo pensé no me haría falta gestionar localidades,
> > niveles de estudio y ocupaciones, no?.
>
>         No, al contrario: de la forma que lo expresás indicás que sí te
> hace
> falta la "gestión"... después de todo, es simplemente un ABM.
>
> > " Acá hacés referencia a los Códigos del Trámite, a los Estados y a
> > los
> > Empleados. Por lo mismo que en 1), debés especificarlos antes..."
> >
> > Está bien, entiendo lo de los empleados ... pero había un drama. Lo
> > había puesto pero lo había tenido que sacar porque solo gestionaba
> > empleados para loguearlos y asignarle acceso a distintas funciones
> > (habíamos quedado en que es un requerimiento no funcional). Bueno,
> > decidí poner la gestión de los empleados como un requerimiento no
> > funcional en la srs, decime si está bien ponerlo así o no.
>
>         Si el empleado forma parte de un dato de otro requerimiento del
> sistema, entonces sí es funcional y va acá.
>        No son funcionales si solo son para el login.
>        Sin embargo, fijate que podrías tener empleados por un lado y
> usuarios
> logueados por otro sin ningún problema, lo que avala que los usuarios
> que se loguean no son un requerimiento funcional.
>        Vos acá optás por hacer coincidir a los empleados con los usuarios
> que
> se loguean, pero esto es una decisión de diseño que no debería estar en
> la SRS.
>        Hacerlos coincidir tiene una desventaja grande: si un Empleado se
> va,
> no lo podés borrar porque es parte de los Trámites, pero si no lo
> borrás, el Empleado se va a poder seguir logueando en el sistema. Se
> entiende?
>        Igual esta decisión es para una etapa posterior a la SRS...
>
> > En cuanto a los códigos de trámites y a los estados estará bien que
> > saque lo que escribí en el diccionario referente a ello y lo ponga
> > como un punto en los requerimientos funcionales ántes de hacer
> > referencia donde la hice?.
>
>         Sí. Los cambios de estado siempre son una funcionalidad, y no podés
> hablar de cambiar estados que no aparecen en ninguna especificación
> funcional.
>        Es habitual que los estados sean fijos, y no se puedan "gestionar";
> esto se expresa diciendo "el sistema debe mostrar Estados para los
> Trámites. Los Estados posibles son bla, bla, bla".
>        Incluso vale la pena poner de qué estado a qué estado es válido
> pasar.
>
> > Muchas gracias Leo!.
>
>        Por nada!!!
>
>
> --
>
> Leonardo Tadei
> leonardot en pegasusnet.com.ar
> 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/cgi-bin/mailman/private/php-avanzado/attachments/20091206/eb2adf28/attachment-0001.htm