[Php-objetos] Jorge Re: Tesis - Requerimientos

[castorin en mdp.edu.ar]

> Hola Jorge,
>
> 	Te sumaste a la movida en titular "el sistema debe" y debajo poner los
> tópicos. Copiar y pegar no es tanto en documentos digitales, y para tu
> próxima entrega y para las de los demás, por favor que toda frase
> empiece con "El sistema debe...".
>

Bueno! no soy ni floger ni emo! En alguna movida tenia que estar!

> El vie, 27-02-2009 a las 20:49 -0300, Jorge Castorina escribió:
>> Aqui va un intento de escribir requerimientos para un sistema de
>> biblioteca.
>> Saludos, Jorge
>
> 	Es un muy buen primer borrador de la especificación.
> 	Te marco unas cosas y mañana en clase lo terminamos de acomodar.
>
>> ================================================================================
>>
>> El sistema se construye para implementar el control de circulación de
>> una
>> biblioteca.
>
> 	Ok. Esto es lo macro de la intención del sistema. Acá abajo tiene que
> estar detallada la naturaleza de este control:
>
>> El sistema debe:
>>
>> - Gestionar usuarios de la biblioteca
>
> 	Perfecto. En el diccionario más abajo está el Usuario. Lo paso acá
> arriba para comentar el diccionario en el contexto de este
> requerimiento:
> -----
>> Usuario
>>
>> Persona que puede registrar transacciones en el sistema.
>
> 	"Transacción" es vocabulario de bases de datos... toda cosa que pase,
> pensada así, será una transacción!!!
> 	La idea es determinar cual es el problema a resolver, el sistema a
> construir, en términos del dominio del problema.
>

No se si hay un termino que englobe préstamos, devoluciones, etc... en una
sola palabra, si fuera necesario podriamos usar "movimiento"?


>> Se requieren procedimientos de alta, modificación y baja de los mismos.
>
> 	La frase "Gestión de" hace referencia justamente a las ABM... fijate
> que si vas por este camino, tendrías que nombrar el AMB de todo, lo cual
> es superfluo.
>
>> Estados posibles: sin préstamos, con préstamos, moroso, suspendido,
>> inhabilitado.
>
> 	Que el usuario tenga estados es parte del requerimiento, no del
> diccionario. En el diccionario deben ir solo definiciones de términos y
> no cosas funcionales.
>

Ah, ok para todo lo anterior

>> Categorías posibles docente, alumno, graduado, empleado (según la
>> categoría
>> se establece las cantidades máximas de ítems a prestar y días de
>> préstamo)
> -----
>
> 	Si enumerás ejemplos de categorías... pero no hay un requerimiento que
> diga que el sistema debe manejar categorías...
>
> 	En mi caso "usuario" me resultó algo confuso, porque pensé que eran
> usuarios del sistema, como operadores. En el diccionario me hubiera
> servido más ver qué era el usuario.
>

Deformación profesional. Para mi el que viene a la biblioteca a buscar un
libro es "usuario", pero en este contexto podria ser socio o lector...

> 	Por otra parte, no figura en el diccionario qué datos definen al
> usuario de la biblioteca (nombre, apellido...)
>

Aca di por sobreentendida una cosa que veo no puede quedar asi.


>> - Gestionar el inventario (ítems) la colección
>
> 	Los estados y categorías de los items forman parte del requerimiento,
> no del diccionario. No figuran los datos que definen los Items... tal
> vez requieran una entrada en el diccionario.
>

Otro sobreentendido.

>> - Gestionar las transacciones ocurridas durante las operaciones diarias
>
> 	En el diccionario ponés: "Tipos de transacciones posibles son:
> préstamo, devolución, renovación, reserva, sanción, levantar sanción."
>
> 	Llegado a esta altura me pregunto: no sería mejor expresar los
> requerimientos de la forma
>
> - El sistema debe registrar el préstamo de items por los usuarios...
> - El sistema debe aceptar la devolución de items...
> - El sistema debe tener un mecanismo para la renovación de un prestamos.
> - El sistema debe permitir reservar items para un usuario.
> - El sistema debe determinar las sanciones a los usuarios en caso de no
> devolución y mora.
>
> 	Fijate como así estamos hablando del modelo, del "sistema biblioteca" y
> sus procesos en lugar de hablar de un programa de computadoras...
>
>> - Gestionar operadores del sistema
>
> 	Todo es multiusuario hoy... esto es superfluo.
>
>> - Gestionar las variables operativas del sistema
>
> 	Esto es diseño!!!
> El sistema debe administrar los días de sanción para cada categoría de
> usuario.
> Etc, etc.
>
>> - Permitir cambios globales
>
> 	No dice nada... un requerimiento sería:
> El sistema debe permitir cambiar todas las fechas de devolución en caso
> de feriados o cierre el edificio. El corrimiento de fechas no es
> automático.
>
>> - Emitir listados de control
>
> 	De control de qué?

Bueno, aunque no sea el lugar en el diccionario decia:

"Listados de control
Usualmente se requieren: préstamos diarios, morosos a la fecha,
sancionados e inhabilitados a la fecha."

>
>> - Emitir comprobantes de préstamo y devolución
>
> 	Esto se puede juntar al requerimiento de que "el sistema debe registrar
> el préstamo"...
>
> [..]
>
> 	No pretendo que la SRS sea perfecta ni mucho menos, sino que obtengan
> un buen listado de lo que debe hacer, para después poder modelar algo
> razonable.
>

A Dios rogando...

>
> 	Seguimos!
> --

Hasta mañana

> Leonardo Tadei
> leonardot en pegasusnet.com.ar
> http://blog.pegasusnet.com.ar
> Firma pública: http://www.pegasusnet.com.ar/LeonardoTadei-public.key
>
> _______________________________________________
> Php-objetos mailing list
> Php-objetos en pato2.fi.mdp.edu.ar
> http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-objetos
>