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

[Leonardo Tadei - Pegasus Tech Supply]

Hola Lucas,


El dom, 06-12-2009 a las 23:04 -0300, Lucas Nastri escribió:
> 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!.

	A mi me parece que a este sistema le hace falta gestionar todas las
cosas que indicás.

> 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.

	Recordá que acá se define solo lo que hace el sistema, y no quien lo
hace.
	Quien lo hace es muy importante, pero esto no aporta funcionalidad al
sistema y por eso no va acá.
	Estamos haciendo solo uno de los apartados de la SRS, y por eso se ve
"que le faltan cosas", pero si aunque sea una única persona en el
planeta lo puede hacer y requiriendo códigos de lanzamiento de misiles
dados por el secretario de defensa de EEUU, es una funcionalidad que el
sistema debe tener.

> > "... 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.

	Entiendo perfecto, pero como te decía arriba, acá va todo lo que hace
el sistema, independientemente de que muchos usuarios no puedan
hacerlo...

>  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.

	Eso mismo!

> >  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 =( .

	Bueno, pero para eso es el ejercicio de escribirla!
	En realidad, les pido la SRS para que definan qué es lo que van a hacer
antes, porque si no dejan muchas cosas sin pensar y el sistema termina
siendo 2 o 3 veces más grande de lo que se imaginaban.

> >  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.

	Pero si casi casi es copiar y pegar!!!

> 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".

	A ver: si borrás un Empleado, lo que pasa es que el id del empleado en
el Trámite queda inválido e introducís un error de consistencia en los
datos.
	Por otra parte, si en vez del id guardás el nombre del empleado, va a
ser una porquería a nivel de la normalización, pero además no podés
garantizar que cuando vez los Trámites de un Empleado los veas
correctamente.

	Pasa lo mismo si querés borrar una Ocupación asignada a un Ciudadano,
etc.

	Para finalizar, si vas a guardar "Trámite realizado por el Renaper", no
hace falta gestionar Empleados!

> >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?

	Sí, pero acá pensamos en qué hace el sistema, qué guarda y qué
información debe recuperar para hacer informes.
	Si un informe requiere algo que no está bien contemplado, ese informe
va a fallar, independientemente de cómo normalicemos.

> Gracias por leer todos los testamentos que te mando :P . 

	Por nada!

> 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 . 

	Es la idea... el mayor problema de escribir software es decidir qué
software se va a escribir!!!
	Uno muchas veces cree que sabe lo que va a hacer el sistema, pero acá
los detalles son importantes y lo cambian todo.

> Mañana sin falta la corrijo y te la mando.

	La espero!!!

> Saludos!.

	=mente.
-- 

Leonardo Tadei
leonardot en pegasusnet.com.ar
http://blog.pegasusnet.com.ar
Firma pública: http://www.pegasusnet.com.ar/LeonardoTadei-public.key