[Php-avanzado] FW: srs_marco

Jue Dic 10 01:01:26 ARST 2009

Hola Marco,

El mié, 09-12-2009 a las 02:29 -0200, Marco Frontini escribió:
> Hola Leo, comentarios
>  
> > From: leonardot en pegasusnet.com.ar
> > To: php-avanzado en pato2.fi.mdp.edu.ar
> > Date: Sat, 5 Dec 2009 14:42:37 -0300
> > Subject: Re: [Php-avanzado] FW: srs_marco
> > 
> > Hola Marco,
> > 
> > El sáb, 05-12-2009 a las 14:49 -0200, Marco Frontini escribió:
> > > Leo, revisa cuando puedas el adjunto, es para ver si entendi la
> > > idea de lo que necesitas.
> > 
> > Ok. No sé si soy un "buen cliente" como para que me dejes las cosas
> tan
> > abiertas ;-)
> > 
> > Copio y pego acá la SRS para comentarla. Denoto mis comentarios con
> un
> > asterisco (*):
> > 
> > 
> > Sistema a desarrollar: Administración y control de pagos de
> servicios de
> > hosting.
> > 
> > (*) Lo que te había dicho el jueves quedaba circunscripto a la
> > "administración y control de cobros" excluyendo los pagos.
> > Hagamos lo siguiente: trabajemos en una SRS que contemple los cobros
> > también, y luego vemos si no queda demasiado grande para tesis del
> > curso.
> Perdonane, es obvio que tenia que haber agregado el diccionario, para
> mi pago es lo que hacen los clientes por los servicios. O sea que
> estabamos hablando de lo mismo por ende si te parece el sistema pasa a
> ser ADMINISTRACION Y CONTROL DE COBROS.

	No, de veras me parece mejor que armes la SRS de cobros y pagos, y
después si queda grande le recortamos algo.

> > Requerimientos funcionales:
> > 
> 1
> > # El sistema debe permitir gestionar (ABM) servicios.
> > 
> > (*) Ok.
>  
> > # El sistema debe establecer distintos estados para los servicios.
> “Leo
> > necesito que me digas cuales son los posibles estados de tus
> servicios,
> > ej: activo, suspendido, vigente, etc.”
> >
> 2 
> > (*) Solo 2: Activo o No Activo. De hecho podría no manejarse
> estados,
> > sino simplemente se le borra el Servicio al Cliente cuando no lo
> tiene
> > activo. Con estados queda más lindo, porque se preserva así la fecha
> de
> > alta del servicio y la fecha de baja.
> O sea que no tenes excepciones com dar un tiempo tus servicis gratis.

	No hay esas opciones.
	Pero sin embargo esta SRS o contempla: se define un servicio "prueba
gratis" con valor 0, y se le activa al cliente ;-)

> > # El sistema debe asignar precios a los distintos servicios.
> > 
> > (*) Como los precios son un atributo del servicio, no vale la pena
> > plantearlos como un requerimiento aparte, sino simplemente como un
> > atributo del Servicio especificado en 1)... bueno, en el primero,
> porque
> > no los numeraste ;-)
> 3 
> > # El sistema debe poder asignar clientes a los servicios.
> > 
> > (*) Entonces antes falta especificar que el sistema debe gestionar
> > clientes...
> Yo lo habia pensado como un atributo mas al cliente, porque me parecia
> mas importante el servicio que esta activo, o sea que lo tendria que
> sacar de requerimientos funcionales. 

	No es viable ver al servicio como atributo del cliente, porque un
cliente puede tener varios servicios activos a la vez.
	Como te decía, lo que esto implica es que hay que tener un "el sistema
debe gestionar clientes".

> 4
> > # El sistema debe establecer tiempos de duración de los servicios
> > individualmente.
> > 
> > (*) No entiendo que es esto. Los servicios, mientras estén vigentes,
> > existen, así que no tienen un tiempo de duración. Si te referís a
> cada
> > cuanto se cobran (mensual, bimestral, trimestral, etc, no parece
> > pertinente llamarlo "tiempo de duración".
> Pregunta: para vos, de que depende la fecha de vencimiento del cobro,
> del precio que le asignaste al servicio, del tipo de servicio que
> brindas, de lo que al cliente le conviene...?

	No depende de nada: son los 10 de cada mes.
	En tal caso, se le podría poner como atributo a cada servicio el día de
vencimiento con un simple número: el 1, el 15...
	Lo que pasa es que estamos hablando de "tiempo de duración", pero me
parece que estamos llamando a distintas cosas con ese nombre.

> > # El sistema debe calcular vencimientos a partir de los tiempos de
> > duración de los servicios. 
> > 
> > (*) Acá queda claro que te referís a la periodicidad del cobro y no
> a la
> > duración, como sospechaba en el anterior.
> > Hay que buscar una palabra o frase que se ajuste mejor a lo que
> estás
> > queriendo decir, como "Frecuencia de cobro del servicio" o algo por
> el
> > estilo.
> > 
> > # El sistema debe permitir modificar los vencimientos.
> > 
> > (*) No hace falta... en tal caso, basta con que un atributo del
> servicio
> > sea el día del mes que se vence, por ejemplo el "10" o el "15".
> > Todos los servicios comienzan el 1ro de mes y son por mes
> calendario.
> > Aclaración irrelevante para la SRS pero sí para entender esto: si un
> > cliente arranca el 18, se le cobra el proporcional de los 12 días, y
> > luego sigue con el mes calendario.
> > 
> > # El sistema debe avisar del vencimiento del servicio 10 y 5 días
> antes.
> > 
> > (*) No hace falta ni que avise ni que mande mails: la salida debe
> ser un
> > listado de los servicios que hay que cobrar el mes seleccionado, a
> > quién, por qué importes.
> > Si un cliente tiene más de un servicio activo, simplemente aparece
> dos
> > veces en este listado.
> > 
> > # El sistema debe dar aviso de un servicio vencido.
> > 
> > (*) No hace falta.
> > 
> > # El sistema debe permitir registrar el pago de los servicios.
> >
> # El sistema debe permitir registrar el "cobro" de los servicios.
> > (*) Ok. Esto es lo que tal vez recortemos si la SRS indica que el
> > sistema es demasiado grande para el curso.
> > 
> > # El sistema debe calcular saldos en los pagos de los servicios.
> >
> > (*) Ok. Idem anterior.
> > 
> # El sistema debe calcular saldos en los "cobros" de los servicios.

	Me perdí de vuelta... siendo así, hace falta poder registrar los pagos,
además de "qué cobrar", porque si no no se obtiene el saldo.
	(a esta altura creo que lo charlaremos un rato mañana en clase ;-)

> > # El sistema debe recalcular precios de los servicios en base a los
> > saldos de los servicios.
> > 
> > (*) No entiendo qué es este recálculo. :(
> > Si te referís a que lo que se debe un mes, es el servicio que se
> venza
> > ese mes + los adeudado anterior sin pagar, no parece un "recálculo".
> > A qué te referís?
> > 
> Este punto estaba mal esxpresado y no hacia falta, en el saldo ya va a
> salir si el cliente debe o tiene plata a su favor.

	Ok.

> > # El sistema debe permitir ver reportes de históricos del pago de
> los
> > servicios.
> > 
> # El sistema debe permitir ver reportes de históricos del "cobro" de
> los
>  servicios.
> > (*) Ok. Otra cosa posiblemtne para recortar
> > Esto se redacta mejor con la fórmula "El sistema debe emitir..."
> > Todo lo que dice la SRS es lo que el sistema "permitirá" hacer, así
> que
> > poner "permitir" es redundante y genera ambigüedades.
> > 
> > # El sistema debe permitir ver reportes de servicios pagados en
> término.
> > 
> > (*) Idem anterior.
> > 
> > # El sistema debe permitir ver reportes de servicios pagados fuera
> de
> > término.
> > 
> > (*) Idem anterior.
> > Estos últimos dos podrían ser el mismo reporte. En realidad con un
> > "adeuda a la fecha" y poder ver los conceptos adeudados es
> suficiente,
> > independientemente de si se pagó en término o no.
> 
> OK despues lo voy a poner de esta manera.
> Una consulta mas, como decidis, calculas o asignas el recargo a cobrar
> por fallta de pago total o parcial del servicio. 

	Se cobra una cantidad fija mensual dependiente del servicio por cada
periodo no pagado en término.
	Por ejemplo: si pagás tarde un periodo bimestral, $1.00 peso de
recargo. Si se vence un segundo periodo, el peso anterior + $1.00 por el
vencido de antes + $1.00 por el vencido nuevo.

Octubre			Abono $10 = 10
Octubre vencido		Abono $10 + Mora $1 = 11
Noviembre		Abono $10 + Octubre $10 + Mora $1 = 21
Noviembre vencido	Abono $10 + Mora $1 + Octubre $10 + Mora $2 = 23
Etc.

> 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