[Php-avanzado] Para Leo
Lucas Nastri
dex87.mdq en gmail.com
Mie Dic 2 00:10:32 ARST 2009
Ok, entonces no cuento la gestión de los empleados en los requerimientos
funcionales?, sería un requerimiento no funcional?. La gestión de los
empleados quiero que figure en la srs porque después de todo lo voy a
programar ...
Es verdad que los estudios y la ocupación son datos del ciudadano, entonces
lo pondré en la tabla ciudadanos ...
Bueno, entonces mañana arreglo la srs y te la mando.
Gracias por las respuestas =D .
Lucas.
El 1 de diciembre de 2009 22:35, Leonardo Tadei - PegasusTechSupply <
leonardot en pegasusnet.com.ar> escribió:
> Hola Lucas!
>
> On Tue, 1 Dec 2009 22:16:49 -0300, Lucas Nastri wrote
> > Leo, comencé a reformular la srs y me encontré con algunas cosas que no
> me
> quedan muy claras sobre algunas observaciones que hiciste :S . Yo había
> puesto
> ...
> >
> > "El sistema debe gestionar usuarios". Ok, me dí cuenta que estaba
> confundiendo el termino usuario con empleado, porque después de todo un
> empleado va a utilizar el sistema, es un usuario del sistema ... Pero ok,
> voy
> a sustituir el termino usuario por empleado.
>
> Mmmm.... entiendo lo que decís, pero si el sistema gestiona empleados
> únicamente para permitir o no acceder, tampoco es un requerimiento
> funcional y
> por lo tanto tampoco va en la Especificación de Requerimientos Funcionales.
>
> Quién accede y a qué accede no es una funcionalidad!
> (y a mi también me costó mucho darme cuanta de qué significa esto)
>
>
> > Y otra pregunta, ahora sobre las tablas ... Si bien me dijiste que no
> tiene
> sentido analizar las tablas si la srs no está lista todavía me comentaste
> que
> te parecía que faltaba una relación de los ciudadanos con los estudios y la
> ocupación ... La pregunta es la siguiente:
> >
> > A mi en realidad no me interesa guardar la información de los estudios y
> la
> ocupación de la persona hasta que no se haya concluído el trámite ... Por
> eso
> no puse un id de los estudios y la ocupación en la tabla de ciudadanos y si
> en
> la tabla que uso para Toma de trámites. No voy a pedir éstos datos hasta
> que
> llegue a Toma de trámites y los datos del ciudadano los grabo cuando inicio
> el
> trámite en mesa de entrada, por lo tanto hasta ese momento no conozco los
> estudios y la ocupación que tiene. Pero no estoy seguro si es correcto lo
> que
> te digo y me gustaría que me dijeras si está bien que lo haga así ...
>
> A mi me parece que no. Independientemente de cuando cargues estos datos, yo
> creo que la ocupación y los estudios son datos del Ciudadano y no del
> Trámite.
> Que no los cargás al principio significará solamente que al dar de alta al
> Ciudadano, estos campos estarán en NULL o en una entrada que no se pueda
> cambiar que dice "desconocido" o "no ingresado"
>
> Por lo mismo, y si no entiendo mal tu sistema, tampoco habrá dos tablas de
> Trámites, sino una sola con diferentes datos según su estado... pero ahora
> concentrate en definir qué hace el sistema, es decir en terminar la SRS,
> así
> podemos ver como se normaliza lo que querés que haga.
>
> Respecto a la SRS, parecieran faltarle algunos informes...
>
> >
> > Lo de enviar el mail me pareció que estaba bueno implementarlo, pero es
> verdad queda medio colgado ... pensaba, que se podía enviar en mail por
> algun
> error en el sistema o algo así, pero no sé si está bien hacerlo.
>
> Decidir si el sistema manda mails o no, no puede estar bien ni mal. O
> querés
> que el sistema lo haga o no querés que el sistema lo haga.
> Por otra parte, si especificamos que manda mails, hay que especificar
> cuándo,
> con qué contenido y a quien, porque si no ese requerimiento no dice todo lo
> necesario para poder escribirlo.
>
> > Muchas gracias Leo, un abrazo.
>
> Por nada!
> Nos vemos!!!
> Dale que vas bien!!!!
>
>
>
> >
> > El 30 de noviembre de 2009 23:52, Leonardo Tadei - Pegasus Tech Supply
> <leonardot en pegasusnet.com.ar> escribió:
> > 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
>
>
> --
> Leonardo Tadei
> Pegasus Tech Supply <http://www.pegasusnet.com.ar>
> Prometeus Technology <http://www.prometeustech.com.ar>
>
> _______________________________________________
> Php-avanzado mailing list
> Php-avanzado en pato2.fi.mdp.edu.ar
> http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado
>
------------ 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/20091201/b3b07505/attachment-0001.htm
Más información sobre la lista de distribución Php-avanzado