[Php-avanzado] Especificación de Requerimientos R2

Mie Oct 17 15:31:50 ART 2012

Hola Jorge,

El mié, 17-10-2012 a las 00:03 -0300, Jorge Di Iorio escribió:
> Leo,  
> 
>        Buenas noches, estuve viendo unas cositas con el cliente y
> descubrí que me faltaba un requerimiento, el de los "turnos fijos".

	Justamente parte del proceso de elicitación, es descubrir cosas que se
omitieron. Tener una lista de funcionalidades ayuda muchísimo al cliente
a darse cuenta de que faltaban algo.

>  Creí que es una posible solución es utilizar la misma entidad turnos,
> agregando el atributo día de la semana. Entonces se que si tengo fecha
> es solo por un día en particular, pero si tengo día de la semana voy a
> considerar que todas esas jornadas a la hora estipulada ese turno está
> ocupado. Que te parece? O sería mejor crear una entidad aparate
> turno_fijo???

	Me parece una cuestión completamente equivocada estar pensando
cuestiones de implementación al hacer la SRS.
	En la SRS, Jorge, tenés que poner todo lo que el sistema tenga que
hacer: luego si la implementación del "turno" implementa dos RF o solo
uno, es cuestión de diseño. En este caso, tenés que especificar los
Turnos Fijos.
	Si cada RF que te piden vos lo vas "mapeando" mentalmente a una
solución dada, no solo te vas a perder de un montón de información, sino
que además todo lo que te propongan ya va a estar condicionado por estas
decisiones de implementación tomadas prematuramente.
	En un extremo malo de esta cuestión, te encontrás que gente que dice
mientras releva "esto no se puede hacer" y van descartando cosas o
acomodando la SRS a lo que se imaginan. El cliente, que no tiene que
entender mucho de esto, cree que es cierto que no se puede, y busca
caminos alternativos... y así terminamos con que la gente se tiene que
adaptar al software en vez de el software adaptarse a la gente.

>  (si serían objetos utilizaría herencia, pero acá que te parece mejor,
> tampoco me parece algo muy enroscado ya que lo único que cambia es un
> atributo y algo del comportamiento.)

	La SRS no tiene que estar condicionada por el paradigma de programación
que vayas a usar.
	Si después de especificado decidís hacerlo en POO, contá conmigo para
ver el diseño y validarlo.

>         En cuanto a las tarifas hay varias por complejo y ellos
> aplican la que desean al cliente (porque según el día, la hora, si es
> amigo o no, la cara...... varían). Es más al momento de pasar el turno
> al estado pagado, ahí eligen la tarifa. la misma tiene que quedar
> guardada en el turno de manera histórica por si varía. (no solo el id
> de la tarifa, sino también el nombre y el valor, así como los precios
> de venta en los items de una factura, pero creo que eso no se evalúa
> es esta etapa, nomas lo comento a modo informativo).

	La Normalización determinará esto en base a los atributos del
diccionario de la SRS. Vamos a charlar un rato largo sobre esto (y a
veces remar contracorriente de algunas "prácticas" que andan por ahí).
	Perdoname que te insista que no es momento de pensar esto; es más bien
una pérdida de tu tiempo :-(

	La parte relevante ahora es que la Tarifa se elige por la cara, pero
que corresponde con un Complejo. En esto que es un software
multicomplejo, te da una pauta de qué Tarifas mostrar para ser usada.
	La Tarifa se determina al Reservar o al tomar el Turno?
	Si se reserva con una Tarifa, al usar el Turno esta puede variar?

>         Agregué el estado "confirmado", éste sería un estado que no se
> podría pisar, en cambio el "reservado" u "ocupado (turno fijo caído)"
> si.

	Bien. No estoy seguro de que haya diferencia de funcionalidad entre
"reservado" y "ocupado", con lo que no estoy seguro de que esto quede
así o de que tengas en las manos una repetición del mismo concepto.
	Qué cosas distintas pasan si está Reservado o si está Ocupado?

>         Agregue también que pasa con el atributo activo, es para saber
> si el cliente o la cancha se puede utilizar o no para operar en el
> sistema. 

	Ok.

>          Las cotas de tiempo de inactividad tienen canchas y complejos
> y trabajaría de lo particular a lo general, es decir, si el atributo
> cancha esta completo se refiere a una cancha solamente, pero si el
> complejo está señalado es todo el complejo con sus canchas lo que se
> encuentra inoperante en la cota de tiempo correspondiente.  

	Estás especificando mal: la inactividad de la Cancha es una cosa, y la
inactividad del Complejo es otra cosa.
	Lo estás escribiendo como lo harías si tuvieras que implementarlo!!!

>        Buenos, seguramente me esté olvidando de algo, pero nos vemos
> mañana. Saludos! 

	Nos vemos en un rato.
	Muy bueno como va mejorando la especificación.
	Te comento lo mismo que más arriba entre los RF que veo, para que te
quede más a mano para el R3:

> 
> 
> 
> 
> 
> documento de
> texto sencillo
> adjunto
> (Requerimientos
> JD.txt)
> 
> Especificacin de Requerimientos 
> 
> Sistema de Gestin de Turnos de Complejos Deportivos
> 
>         REQUERIMIENTOS FUNCIONALES
> 
>                 1.      El sistema debe gestionar clientes.
>                         1.1.    El Sistema debe Permitir o no,
> realizar alquileres segn el cliente est activo o inactivo.

	Dos cosas: salvo contados casos, la palabra "permitir" no se usa en los
RF, porque de hecho todo lo enumerado será lo que el sistema "permita"
hacer. Ponerla además de generar dudas sobre los otros RF, no cumple con
el requisito de vocabulario mínimo, y como en este caso suele solapar
funcionalidades que deberías especificar, como la de "alquilar", que
fijate que curiosamente no está mencionado en ninguna parte, pero es a
dónde terminará la Reserva tomada.
	Turnos es una cosa. Alquileres es otra cosa. Se podrá Alquilar sin
Turno si está disponible, se podrá tener un Turno y no ir a Alquilar y
se podrá tener un Turno y sí ir a Alquilar.
	Fijate que hasta esta versión, los Turnos y Alquileres están
entremezclados, cuando pareciera que son cosas independientes: hemos
encontrado un RF más mirando en detalle todo esto ;-)

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

	Solo un Deporte por Cancha? No podía ser más de uno?

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

	Estos son 2 RF, uno para las Cotas de Tiempo de las anchas y otro para
las de los Complejos.
	En el diccionario se llama "Cotas no laborarles": decidite y ponele un
solo nombre a esto!

>                 7.      El sistema debe gestionar Turnos con su
> cancha[7], cliente[3], tarifa[8].
>                         7.2.    El sistema debe mostrar los turnos
> dados filtrando por rango de fechas, complejo, cancha o deporte.
>                         7.3.    El Sistema debe Permitir o no,
> Alquilar una cancha segn est activa o inactiva.

	En un sub RF de Turnos, estás hablando de Alquileres...

>                         7.3.    El Sistema debe impedir el alquilar de
> una cancha si se encuentra en una cota de inactividad.

	Idem.

>                         7.4     El sistema debe gestionar Turnos Fijos
> como acupados si se le especifica un da de la semana en vez de una
> fecha.

	Por lo dicho arriba, el Turno Fijo es, en la SRS, otra cosa
independiente.

>                                 7.4.1           El sistema debe
> mostrar en el calendario todos los turnos fijos segun los das y
> horarios en que estn dados. 

	Idem

>                                 7.4.2           El sistema debe poder
> pisar un turno fijo con otro normal en caso de que ste se caiga. 

	Y dónde están los Estados de Turno ??? Me pareció que la SRS anterior
estaba: no podés hablar de "Turno Caido" si no especificaste qué es
esto...

>                 9.      El sistema debe mostrar el historial de turnos
> de los clientes.
>                         9.1.    El sistema debe mostrar los turnos que
> realizo un cliente y el estado en que quedaron los mismos.  

	Poné una entrada en el diccionario con las cosas que se mostrarían acá.

>                         9.2.    El sistema debe mostrar un listado de
> turnos con su cliente[1] filtrando por Estado y Fecha.

	Idem.

>                         9.3.    El sistema debe mostrar un listado de
> turnos fijos por estado por si se le debe llamar la atencion al
> cliente. 

	Idem.

	Seguimos luego.
	Si podés llevar una versión nueva de tu SRS, la podríamos ver todos
juntos en clase: sé que será provechoso para todos, y además nos podemos
enriquecer con los aportes de los compañeros.

	Saludos!

>                 
>                 Diccionario:
>                         Cliente: Cdigo, Nombre, dni, domicilio,
> telfono fijo, telfono celular, email, observacin, activo.
>                         Complejo: Cdigo, Nombre, Domicilio,
> Observacin.
>                         Deporte: Cdigo, Nombre.
>                         Cancha: Cdigo, Nombre, Deporte, Cantidad de
> Jugadores, Piso, Complejo, Observacin, Activa.
>                         Tarifa: Cdigo, Nombre, Complejo, valor.
>                         Cotas no Laborales: Cdigo, Nombre, Fecha
> Inicio, Fecha fin, Cancha, Complejo.
>                         Turno: Cliente, Cancha, Tarifa, Descuento,
> Recargo, Observacin, Fecha, Dia Fijo, Hora Inicio, Duracin,
> Estado[Reservado, Ocupado(Turno Fijo), Confirmado, Cerrado, Pagado,
> Caido].
>                 
>                 
>         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.
>                 
>                 Diccionario:
>                                 Usuario: Cdigo, Nombre, Contrasea,
> Agrega Registros, Modifica Registros, Elimina Registros, Modifica
> Usuarios. 
-- 
Leonardo Tadei
leonardot en pegasusnet.com.ar
Web: http://leonardo.tadei.com.ar
Firma pública: http://www.pegasusnet.com.ar/LeonardoTadei-public.key