[Php-avanzado] Última versión de la SRS
Lucas Nastri
dex87.mdq en gmail.com
Mie Dic 9 01:00:14 ARST 2009
Buenisimo. Gracias Leo!. Voy a hacer algunas modificaciones que me marcaste
y te muestro la SRS terminada en clase el jueves. Por cierto, hay un detalle
que me faltó agregar y vos me hiciste acordar :P ...
" ... i) y hablando de fechas, el punto 13 no se puede implementar porque
los
Trámites no tiene fecha ;-) ... "
En realidad si tienen que tener fecha, solo que la olvidé!.
Bueno, voy a modificar todo bien y poner todo en orden y el jueves la veo
con vos en clase.
Muchas gracias =D . Nos vemos!.
Lucas.
El 8 de diciembre de 2009 23:23, Leonardo Tadei - Pegasus Tech Supply <
leonardot en pegasusnet.com.ar> escribió:
> Hola Lucas!
>
> El mar, 08-12-2009 a las 20:39 -0300, Lucas Nastri escribió:
> > Leo, te hago una pregunta ...
> > No entiendo que me quisiste decir cuando ponés
> >
> > > 3. El sistema debe gestionar las ocupaciones de los ciudadanos.
> >
> > > Le sobre el "de los ciudadanos".
> >
> > " ... Le sobre el "de los ciudadanos" ... ".
>
> Es que dejando "de los ciudadanos" en las ocupaciones, si por
> ejemplo
> las tuvieras que usar el el futuro para los empleados, resulta que tenés
> que especificar unas nuevas ocupaciones.
> Al sacar esto, las ocupaciones son tales, y las puede usar cualquier
> otra entidad definida en la SRS.
> Haceme acordar en clase y te tiro 2 o 3 ejemplos más para clarificar
> el
> tema.
>
> > > *Tipo de trámite a realizar.
> > > 6.1.1. Tipos disponibles: Nuevo ejemplar, Cambio de
> > domicilio.
> >
> > > Entonces falta especificar los tipos de trámites.
> > > Es posible que no impliquen una "gestión", ya que los pondrás
> > en una
> > >tabla solo para ser usados, sin posibilidad de ABM. En este caso se
> > >especifica "el sistema debe mostrar Tipos de Trámites".
> >
> > No entiendo ésto: "Entonces falta especificar los tipos de trámites."
> >
> > Querés decir que tengo que especificar como un punto más que el
> > sistema debe mostrar los tipos de trámites?.
>
> Claro! Porque si no los especificás, cuando los referenciás en el
> Trámite, estás haciendo referencia a algo que no existe y la SRS se
> vuelve inconsistente.
>
> > Bueno, modifiqué la SRS y te la mando como entendí que tenía que
> > corregirla.
>
> Genial!
> Así vamos avanzando!
>
> > Hasta luego, saludos!.
>
> Te pongo los comentarios acá:
>
> Para este curso, esta especificación es suficiente y la podés dejar
> así
> y pasar a la normalización de las tablas.
> Misión cumplida!
>
>
> Te hago unos comentarios ahora respecto a cosas que no son
> funcionales
> y que por tanto no van acá y a un par de detalles:
>
> a) en una versión anterior, para 5, había costos de los trámites, pero
> en esta solo está la descripción. Me da lo mismo, pero si vas a poner
> costos deberían estar en alguna parte.
>
> b) en 7, poner el nick y la contraseña es una decisión de diseño
> respecto a cómo vas a hacer funcionar las autorizaciones. La SRS debe
> definir el "qué" y no el "cómo" y por eso esto es un vicio en el
> documento, ya que excede su ámbito.
>
> c) los puntos 10, 11 y 12 no son una especificación funcional, sino un
> caso de uso. Cómo yo les pido solo la especificación funcional, esto no
> debería estar acá, pero naturalmente podés dejarlo en otro apartado bajo
> el título "Casos de uso".
>
> d) el 11.2 necesita un modelo del formulario a generar en un apéndice o
> algo, porque así no alcanza para saber cómo escribirlo.
>
> e) el 15 no existe en realidad, ya que es parte del 13 "El sistema debe
> realizar el proceso de cierre al final del día con los trámites en
> Estado 'finalizado'".
>
> f) el listado del proceso de cierre necesita tener en el apéndice un
> modelo de cómo es el informe.
>
> g) la definición de Empleado en el diccionario no es correcta. Sería
> algo como "Persona que inicia un Trámite", ya que es la única función
> que cumple en el sistema (esto te pasa por querer hacer que los
> Empleados sean los usuarios logueados...)
>
> h) la definición de " Nick del empleado" es completamente superflua,
> sobre todo porque no cumple ninguna funcionalidad del sistema... es como
> que definas "Fecha de Nacimiento", pero no porque es un término que se
> entiende, sino porque no participa de ningún proceso!
>
> i) y hablando de fechas, el punto 13 no se puede implementar porque los
> Trámites no tiene fecha ;-)
>
>
> Nos vemos!!!
>
>
> > Introducción:
> >
> > Éste sistema se lleva a cabo para informatizar las oficinas
> > del registro nacional de las personas. Mediante éste sistema
> > es posible realizar cambios de domicilio y nuevos ejemplares
> > de documentos a los ciudadanos que lo requieran.
> >
> >
> >
> > Requerimientos funcionales del sistema:
> >
> > 1. El sistema debe gestionar localidades.
> >
> >
> > 2. El sistema debe gestionar niveles de estudio.
> >
> >
> > 3. El sistema debe gestionar ocupaciones.
> >
> >
> > 4. El sistema debe mostrar tipos de trámite.
> > 4.1. Tipos disponibles: Nuevo ejemplar, Cambio de domicilio.
> >
> >
> > 5. El sistema debe mostrar códigos de trámite.
> > 5.1. Códigos disponibles: 52 para Nuevo ejemplar, 40 para un
> > cambio de domicilio, 52 40 para Nuevo ejemplar con cambio de
> > domicilio.
> >
> >
> > 6. El sistema debe mostrar estados de un trámite.
> > 6.1. Estados disponibles: Finalizado, dudoso.
> >
> >
> > 7. El sistema debe gestionar empleados.
> > 7.1. Los atributos del empleado tenidos en cuenta por el sistema
> > serán lo siguientes:
> > *Número de documento.
> > *Apellido.
> > *Nombre.
> > *Fecha de nacimiento.
> > *Nick del empleado.
> > *Contraseña.
> >
> >
> > 8. El sistema debe gestionar ciudadanos.
> > 8.1. Los atributos del ciudadano que tendrá en cuenta el sistema
> > serán lo siguientes:
> > *Número de documento.
> > *Apellido.
> > *Nombre.
> > *Fecha de nacimiento.
> > *Localidad de nacimiento.
> > *Sexo.
> > *Teléfono.
> > *Nivel de estudios cursados por el ciudadano.
> > *Ocupación del ciudadano.
> >
> >
> > 9. El sistema debe gestionar trámites.
> > 9.1. Los atributos del trámite que tendrá en cuenta el sistema
> > serán lo siguientes:
> > *Número de boleta.
> > *Los atributos del ciudadano mencionados en 8.1.
> > *Tipo de trámite a realizar.
> > *Código del trámite.
> > *Estado del trámite.
> > *Empleado que comenzó el trámite en mesa de entrada.
> > *Domicilio actual.
> > *Domicilio nuevo (en caso de cambiar el domicilio).
> >
> >
> > 10. El sistema debe comenzar un trámite mediante la mesa
> > de entrada.
> > 10.1. Se cargan los siguientes datos del ciudadano:
> > *Número de dni.
> > *Apellido.
> > *Nombre.
> > *Fecha de nacimiento.
> > *Telefono.
> >
> > 10.2. Se cargan los siguientes datos correspondientes al
> > trámite:
> > *Tipo de tramite.
> > *Código de tramite.
> > *Número de boleta.
> > *Nombre del empleado que comenzó el trámite.
> >
> >
> > 11. Al momento de tomar el trámite, el sistema debe verificar
> > si existe un trámite con el número de boleta ingresado. En caso
> > afirmativo:
> > 11.1.Toma de trámites tendrá en cuenta los siguientes datos:
> > *Domicilio actual del ciudadano.
> > *Domcilio nuevo en caso de cambiarlo.
> > *Nivel de estudios cursados por el ciudadano.
> > *Ocupación del ciudadano.
> >
> > 11.2. Al finalizar el trámite el sistema debe generar un
> > formulario con los datos del trámite y del ciudadano.
> >
> >
> > 12. El sistema debe consultar datos sobre el trámite de un
> > ciudadano por medio del subsistema consulta de boletas mediante
> > el ingreso del número de documento y sexo.
> >
> >
> > 13. El sistema debe realizar el proceso de cierre al final del
> > día.
> >
> >
> > 14. El sistema debe cambiar el estado de un trámite dudoso.
> > Cuando un trámite es inciado su estado se incia en dudoso y éste
> > se cambia a finalizado solo cuando se haya concluido.
> >
> >
> > 15. El sistema debe tener en cuenta, para el proceso del punto 13,
> > los trámites con estado finalizado.
> >
> >
> > 16. El sistema debe mostrar un historial de trámites finalizados que ha
> > realizado un ciudadano.
> >
> >
> > 17. El sistema debe poder enviar por mail el resultado del proceso de
> > cierre.
> >
> >
> > 18. El sistema debe mostrar información de su versión.
> >
> >
> >
> >
> > Diccionario:
> >
> > Empleado: Persona que interactúa con alguno de los subsistemas
> > disponibles.
> >
> >
> > Ciudadano: Persona que concurre a la oficina para realizar un
> > trámite.
> >
> >
> > Mesa de entrada: Donde un empleado inicia el trámite de un ciudadano
> > ingresando los datos respectivos.
> >
> >
> > Tomar trámite: Continua el trámite que se inició en la mesa de
> > entrada para generar un formulario con los datos del ciudadano.
> >
> >
> > Consulta de boletas: Visualiza los datos del trámite de un ciudadano.
> >
> >
> > Boleta: Comprobante de trámite que posee un número único para asociar
> > los datos de un trámite a ese número.
> >
> >
> > Comprobante: Documento que prueba la existencia de un trámite.
> >
> >
> > Proceso de cierre: Proceso que recuenta los trámites existentes según
> > el tipo de trámite.
> >
> >
> > Nick del empleado: Nombre que es asignado por el sistema al empleado
> > para iniciar una sesión.
> >
> >
> > Código del trámite: El código del trámite es un número (asignado al
> > tipo de trámite) que determina el precio a abonar por realizar el mismo.
>
> --
>
> 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
>
------------ 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/2344c9a9/attachment-0001.htm
Más información sobre la lista de distribución Php-avanzado