[Php-avanzado] Para Leo

Mar Dic 1 00:52:18 ARST 2009

Hola Lucas!

El lun, 30-11-2009 a las 16:30 -0300, Lucas Nastri escribió:
> Leo, te mando la especificación de la tesis para saber si está bien
> así. 

	Te hago comentarios intercalados.

> Y una pregunta, también tengo que mandarte los dibujos de las ventanas
> del sistema?. Gracias.

	No, ya que solo les pido los requerimientos funcionales, y las
pantallas son "no funcionales", pero está muy bueno que los hayas hecho:
hace que tu proyecto se escriba más fácil y rápido.

> Nos vemos el jueves.
> Lucas.
> documento de texto sencillo adjunto (especificación de
> requerimientos.txt)

	Clarifica mucho ponerles títulos para saber de qué se habla, como
pusiste para el Diccionario y los Requerimientos Funcionales. El párrafo
que sigue podría titularse "Introducción" o "Requerimientos
empresariales"

> - Este sistema se lleva a cabo para informatizar las oficinas
> del registro nacional de las personas. Mediante éste sistema
> se pueden realizar los trámites necesarios que requieran los
> ciudadanos.

	Ok.

> Diccionario:
> Comenzar el trámite con la mesa de entrada: Consiste
> en cargar los datos personales del ciudadano (número
> de dni, apellido, nombre, fecha de nacimiento, telefono,
> tipo de tramite, codigo de tramite, número de boleta).

	Parece el requerimiento funcional de un ABM de trámites...
	No estás mezclando el qué es, que sí va a acá, con el qué hace, que es
el req. funcional?

> El sistema además de comenzar con el trámite también
> guarda los datos de la persona en un tabla ciudadanos
> para dejar registrada al ciudadano que realizó un trámite.

	Decir que "guarda en una tabla" es decir cómo se hace, y en la SRS solo
ha que hablar de qué se hace. No creo que valga la pena indicar que se
guarda y que no, ya que eso se desprende de los requerimientos
funcionales.

> Tomar trámite: Carga datos adicionales al ciudadano y
> genera un formulario con los datos. La toma del trámite se
> realiza mediante el ingreso del número de boleta que se le
> asignó en mesa de entrada. Solo se podrá cargar los datos si
> el número de boleta exista.

	Ok.
	La segunda oración es en rigor un caso de uso, y no una definición del
diccionario.

> Consulta de boletas: Mediante el número de documento del
> ciudadano se exhiben los datos de su trámite (número de
> boleta, que usuario lo registró, y datos personales de la
> persona).

	Ok.

> Proceso de cierre: Consiste en un recuento de los trámites
> existentes (trámites con estado finalizado) según el tipo
> de trámite y genera una tabla con la cantidad de trámites.

	Ok. La parte de que "genera una tabla..." no es del diccionario.

> Requerimientos funcionales del sistema:
> 
> 1. El sistema debe gestionar usuarios.

	No. Los usuarios _no_ son un requerimiento funcional.
	Si querés ponerlos, pasalos a una sección de Requerimientos No
Funcionales".
	Además, "usuario" es un término tan amplio que no dice nada!!!

> 2. El sistema debe diferenciar entre usuarios por medio
> de una categoría (empleado o jefe).

	No. Nada relativo a los usuarios es funcional.

> 3. El sistema debe asignar distintos permisos a acceso a
> funciones mediante la diferencia hecha en 2.

	No. Nada que tenga que ver con accesos es funcional.
	Tu sistema va a tener que realizar las funciones que indiques, y vos
vas a tener que escribirlas, independientemente del tipo de "usuario"
que ingresa.

> 4. El sistema debe comenzar un trámite mediante la mesa
> de entrada.

	Bien... en el diccionario definís "comenzar un trámite mediante la mesa
de entrada" pero la verdad es que si no es la "gestión de trámites" que
parecés indicar en el diccionario, esto no me dice nada.
	Es como que definís en el diccionario "tomar trámite" y tu
requerimiento funcional es "el sistema debe tomar trámite"...

> 5. El sistema debe verificar si existe un trámite con el
> número de boleta ingresado. En caso afirmativo debe poder
> tomar el trámite.

	Está bien, pero cuando reformules el 4, creo que será simple integrarlo
como una restricción ahí mismo.
	Los trámites no pueden borrarse? Qué pasa si alguien los carga mal?

> 6. El sistema debe consultar datos sobre el trámite de un
> ciudadano mediante el sub sistema consulta de boletas.

	Ok... pero a todo esto, no hace falta un "el sistema debe gestionar
ciudadanos" ?

> 7. El sistema debe realizar el proceso de cierre al final del
> día.

	Ok. Con esto y la entrada del diccionario explicando qué es el cierre
al final del día está clarísimo.

> 8. El sistema debe cambiar el estado de un trámite, finalizado
> o dudoso. El sistema solo tendrá en cuenta para el proceso del
> punto 7 los trámites con estado finalizado.

	O sea que los trámites finalizados pueden pasar a dudoso? No te
entiendo :(
	Poné los estados posibles, y de qué estado a qué estado vale pasar.

> 9. El sistema debe enviar mails al desarrollador.

	Ok... pero sin poner qué va en los mails, a esto le falta algo.

> 10. El sistema debe mostrar información de su versión.

	Ok.

> Tablas para la base de datos del sistema:

	No tiene sentido analizar las tablas sin tener terminada la SRS, pero
da la sensación de que falta una relación de los Ciudadanos con la
Ocupación y los Estudios...

	Ahora, para no perder velocidad, reescribila con las indicaciones que
te doy y reenviámela ASAP!!!

	Nos vemos!!!

> Usuarios:
> id		int 		(PK)
> dni		varchar(9)	(ÚNICO)
> ape		varchar(30)
> nom		varchar(30)
> fnac		date
> nick		varchar(20)
> pass		varchar(20)
> mesa		varchar(2)
> toma		varchar(2)
> cierre		varchar(2)
> boleta		varchar(2)
> id_cat		int
> 
> 
> Categorias:
> id		int		(PK)
> puesto		varchar(15)
> 
> 
> Provincias:
> id		int
> nombre		varchar(20)
> 
> 
> Partidos:
> id		int
> nombre		varchar(20)
> id_prov		int
> 
> 
> Localidades:
> id		int
> nombre		varchar(20)
> id_part		int
> 
> 
> Estudios:
> id		int
> nivel		varchar(20)
> titulo		varchar(20)
> 
> 
> Ocupaciones:
> id		int
> nombre		varchar(20)
> 
> 
> Ciudadanos:
> id		int 		(PK)
> dni		varchar(9)	(ÚNICO)
> ape		varchar(30)
> nom		varchar(30)
> fnac		date
> sexo		char
> telefono	varchar(18)
> 
> 
> Tipo_tramite:
> id		int 		(PK)
> tipo		varchar(15)
> 
> 
> Codigo_tramite:
> id		int 		(PK)
> codigo		char
> 
> 
> Tramites_mesa:
> id		int 		(PK)
> id_ciudadano	int
> num_boleta	varchar(18)
> id_tipotram	int
> id_codtram	int
> 
> 
> Tramites_toma:
> id		int 		(PK)
> id_mesa		int
> id_localidad	int
> domicilio	varchar(50)
> domicilio_nuevo varchar(50)
> id_estudios	int
> id_ocupacion	int
> _______________________________________________
> Php-avanzado mailing list
> Php-avanzado en pato2.fi.mdp.edu.ar
> http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado
-- 

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