[Php-avanzado] Especificación de Requerimientos

Mar Oct 9 14:23:38 ART 2012

Hola Jorge,

	gracias por el envío. Se nota el avance en acotar el proyecto.

El lun, 08-10-2012 a las 19:17 -0300, Jorge Di Iorio escribió:
> Leo, te mando el primer release de la especificación de
> requerimientos. Según lo que hablamos lo que fui corrigiendo fue lo
> siguiente: 
> 
> -> Saqué los tipos de cancha y asocié directamente el deporte a la
> cancha. Sinceramente después de lo que hablamos no me pareció menester
> tener el tipo de cancha, si en realidad la información de la cantidad
> de jugadores y el tipo de piso pueden ser atributos de la cancha en
> sí.  

	Estoy de acuerdo... igual, consultalo con el cliente por si él se
refería a otra cosa, y tenés entre manos un requerimiento oculto.

> -> En cuanto a las tarifas lo dejé de manera que sean por complejo y
> van a tener un valor diurno y otro nocturno. 

	Esto significa que si en un complejo hay varias canchas, todas deberán
cobrar lo mismo por un turno diurno o por un turno nocturno... me habría
imaginado que diferentes canchas del mismo complejo podían tener
diferentes tarifas.

> -> Por otro lado, no voy a dejar que el usuario gestione estados de
> los turnos. En un principio los voy a dejar predefinidos yo. [Libre,
> reservado, Ocupado, Cerrado, Pagado]. 

	Me parece bien para la primer versión del proyecto.
	La metodología que no recordaba el otro día cuando hablábamos de esto
es AOM: Adaptive Object Model
	Si llaman para pedir confirmación de los turnos, acordate de poner un
estado "confirmado".

> Lo que no se como especificar bien es el tema de la prioridad de los
> turnos según el estado de los mismo, es decir, por ejemplo: "que pasa
> cuando quiero alquilar uno que ya esta reservado".

	Bueno, esto te lo debe responder el cliente.
	Si la reserva es una promesa que hace el complejo, no debería tomar
otro turno, porque ya lo tiene comprometido.
	Acá es en dónde entraría en juego la confirmación: podría ser que se
puede reservar varias veces la misma cancha para la misma hora, y que el
que la confirme primero se la queda.

>   Otra cosa que no se como dividir es el tiempo para prorratear el día
> laboral de la cancha en las horas, o sea, le doy un valor de tiempo
> fijo al turno?

	También lo debe responder el cliente, pero generalmente se alquila la
cancha de tal hora a tal hora, con un tiempo mínimo.
	En ese caso si reservo/alquilo una cancha de 16 a 17:30, será una hora
y media, pero si tengo otro turno que empieza a las 17hs, podré
reservar/alquilar solo 1 hora.
	La verdad es que no entiendo bien el problema ni veo la necesidad de
prorrateo: las canchas suelen ofrecerse por un costo la hora, y vos la
alquilás lo que quieras siempre y cuando esté disponible. Cómo lo maneja
tu cliente?

>  y si distintas canchas tienen distintos tiempos de turnos? si con el
> tiempo varía la duración de determinado turno?

	Nada de esto sería problema si el turno tiene un día y hora de inicio y
una duración que se determina al momento de pedirlo... a lo sumo un
encargado piola minimizará los huevos y uno no tan piola te dejará
huecos de media hora por todas partes. Esto se evidenciará en los
informes que emita el sistema de ser necesario.

>  Yo había pensado en dividir el día en lapsos de media hora y que el
> usuario acupe los que quiere... no van a alquilar una predio por 15
> minutos! (le mande un mail a el cliente pidiéndole info detallada
> sobre esto). 

	Esperemos la respuesta. Lo peor que podría pasar es que cada cancha
tenga un lapso mínimo de alquiler, y un fraccionamiento de hora
diferente.

	Te hago unos comentarios sobre la SRS:

> Especificacin de Requerimientos 
> 
> Sistema de Gestin de Turnos de Complejos Deportivos
> 
>         REQUERIMIENTOS FUNCIONALES
> 
>                 1.      El sistema debe gestionar clientes.

	Qué significa el "activo" que está en el diccionario del cliente? Si el
sistema tiene que hacer algo o no dependiendo de si está activo o no,
tendrías que especificarlo, porque hasta esta versión d ela SRS, estar
activo o inactivo no implica nada.

>                 2.      El sistema debe gestionar complejos.
>                 3.      El Sistema debe gestionar deportes.
>                 4.      El sistema debe gestionar Canchas con su
> Complejo[4] y Deporte[6].

	Cachas también tiene un "activo". Si no recuerdo mal, era para sacar
temporariamente una cancha por ejemplo por mantenimiento. Si es así,
tenés que especificar en el RF[7] este comportamiento.

>                 5.      El sistema debe gestionar tarifas con su
> complejo[4].

	Te falta la cancha además del complejo... en el diccionario está. No sé
si estás pensando en que una cancha va a tener dos tarifas definidas,
una diurna y otra nocturna, en cuyo caso tendrías que poner el horario
de validez de dicha tarifa, para evitar que te usen una noche una tarifa
diurna, que es más barata.
	Tal vez sea necesario además especificar la regla de uso de la tarifa:
cuando empieza el turno, el promedio del tiempo, el final del turno,
etc.

>                 6.  El Sistema debe gestionar cotas de tiempo no
> laborales con su cancha[5] o complejo[2].

	No ibas a hacer dos de estos? Uno para todo el complejo, por ejemplo
para un feriado, y otro para una cancha, por ejemplo por mantenimiento?

>                 7.      El sistema debe gestionar Turnos con su
> cancha[7], cliente[3], tarifa[8].
>                         7.1.    El sistema debe mostrar el historial
> de turnos de un determinado cliente.

	Este historial sacalo como un RF aparte, y no como parte de la gestión
de turnos. porque mostrar historiales no forma parte del proceso de
gestión.

>                         7.2.    El sistema debe mostrar los turnos
> dados filtrando por rango de fechas, complejo, cancha o deporte.
>                 
>                 Diccionario:
>                         Cliente: Cdigo, Nombre, dni, domicilio,
> telfono fijo, telfono celular, email, observacin, activo.
>                         Complejo: Cdigo, Nombre, Domicilio,
> Observacin.
>                         Deporte: Cdigo, Nombre.
>                         Cancha: Cdigo, Nombre, Activa, Deporte,
> Cantidad de Jugadores, Piso, Complejo, Observacin.
>                         Tarifa: Cdigo, Nombre,  Cancha, Complejo,
> valor.
>                         Cotas no Laborales: Cdigo, Nombre, Fecha
> Inicio, Fecha Fin, Cancha, Complejo.
>                         Turno: Cliente, Cancha, Tarifa, Descuento,
> Recargo, Observacin, Fecha, Hora Inicio, Hora Fin, Observacin.
> 
>                 
>         REQUERIMIENTOS NO FUNCIONALES   
> 
>                 1.      El sistema debe ser web.
>                         1.1.     El sistema debe solicitar loguin para
> su utilizacin. 
>                 2.      El sistema debe gestionar usuarios.
	El 1.1 es el 2 o el 3: no es una subespecificación más detallada del 1.

>                 Diccionario:
>                                 Usuario: Cdigo, Nombre, Contrasea,
> Agrega Registros, Modifica Registros, Elimina Registros, Modifica
> Usuarios. 

	Bueno.
	Quedo a la espera de la nueva versión.
	Muy buenos los avances Jorge!

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