[Php-avanzado] FW: srs_marco

Mie Dic 9 02:29:21 ARST 2009

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

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

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

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

> # 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. 
> 
> Muy buen inicio!
> Seguimos!!!
> 
> 

Saludos.

Marco.
> 
> PD: el sistema no debe hacer nada "solo" o dependiente de la fecha del
> servidor. El operador dice "es 5/12/2009" (que puede estar ya puesto por
> el sistema como sugerencia) y se le pide que emita su informe de lo que
> hay que facturar o no.
> Esto permite hacerlo tarde o por adelantado de ser necesario, por
> ejemplo para el 29 o 30 de diciembre armar todas las cosas para el
> 01/01/2001, y el 02/01 tenerlas listas para ingresar.
> -- 
> 
> Leonardo Tadei
> leonardot en pegasusnet.com.ar
> http://blog.pegasusnet.com.ar
> Firma pública: http://www.pegasusnet.com.ar/LeonardoTadei-public.key
> 
> _______________________________________________
> Php-avanzado mailing list
> Php-avanzado en pato2.fi.mdp.edu.ar
> http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado

_________________________________________________________________
Windows Live Messenger GRATIS: lo que faltaba en tu BlackBerry
http://www.messengerentublackberry.com?ocid=WL_BB_LandPage_TagLine
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://www3.fi.mdp.edu.ar/cgi-bin/mailman/private/php-avanzado/attachments/20091209/7d8a5fd3/attachment.htm 