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

[Leonardo Tadei - Pegasus Tech Supply]

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