PARCIAL 3 ENUNCIADOCU04

DOCENTE: ADOLFO VILORIA

INTEGRANTES:
JULIO AGUILAR
ERICK PAYARES
PEDRO RUA
DANIEL SALAS
SAMUEL GONZALES MENDOZA
JUAN MEDINA CAMARGO

CURSO
3ª

AÑO
2018
 Análisis de Sistemas

Parcial C3 201702

La Universidad CUA en su constante innovación pretende instalar un conjunto de Consolas de

información CI a través de los cuales se pueda facilitar información a la comunidad universitaria.

Las funcionalidades consideradas para instalar en cada CI son:

 Información General: actividades culturales y extra-académicas de la Universidad y de las

diferentes Facultades.
 Información Administrativa: plazos de matriculación, fechas de exámenes, normativas y
avisos.
 Información Privada: esta información se diferenciará según el tipo de usuario final que se
identifique en el CI.
o Profesores: información relativa a su cuerpo, información de asignación horaria de
clases e información económico-contractual.
o Alumnos: información referente a la carrera que están cursando y su currículum,
así como el estado de su matriculación.

La Universidad CUA ha pedido a su departamento de sistemas la elaboración de un sistema

información basado en tic’s que pueda ser utilizado por dos tipos de usuarios diferentes:

1. Administrador: es el responsable de la colocación y carga inicial de las CI en las diferentes

Facultades que componen la Universidad, es decir, se encarga de decidir, las situaciones
físicas más propicias y de activación inicial de los contenidos (funcionalidades a
proporcionar) de cada uno de las CI. Por tanto, el administrador tan sólo utilizará este
sistema informático para notificar la instalación de los distintos dispositivos. Habrá un
administrador de dispositivos por cada turno de mañana y de tarde para solucionar todas
las peticiones realizadas por los responsables de cada centro.

2. Usuarios Finales: este grupo está compuesto por el Profesorado y el Alumnado. Su

conexión al sistema vendrá siempre asociada a una solicitud/servicio de información. Cada
vez que un usuario intente conectarse al sistema deberá introducir sus datos
identificativos, así como la introducción de una contraseña y del tipo de usuario (en caso
de que sea necesario). Las actividades recogidas por el sistema sólo estarán accesibles
para el tipo de usuario responsable de su realización. Para instalar una CI dentro de una
Facultad o Escuela será necesario, en primer lugar, seleccionar la Escuela/Facultad, de tal
modo que sólo puede haber un único dispositivo de un tipo determinado en una misma
Escuela/Facultad. A continuación, se indicará las funcionalidades que soportará dicho PIU.
Será posible que el administrador de las CI cambie la colocación de las mismos, así como el
resto de características propias de la CI.

Los Usuarios Finales realizarán peticiones al sistema guiados a través de la interfaz gráfica del
sistema, su única interrelación con el sistema, consiste en la emisión de dichas peticiones para que
sean procesadas y servidas por el sistema.
DICCIONARIO DE FLUJO DE DATOS

 INFORMACIÓN GENERAL: actividades culturales y extra-académicas de la Universidad y de

las diferentes Facultades.
 INFORMACIÓN ADMINISTRATIVA: plazos de matriculación, fechas de exámenes,
normativas y avisos.
 INFORMACION DEL PROFESOR: información relativa a su cuerpo, información de
asignación horaria de clases e información económico-contractual.
 INFORMACION DEL ALUMNO: información referente a la carrera que están cursando y su
currículum, así como el estado de su matriculación.
 LOGIN: registro de los actores en el sistema.

Lista de Casos de Uso

Actores Casos de uso
administrador *INFORMACION ADMINISTRATIVA.

*INFORMACION GENERAL.

*LOGIN.

Profesor *INFORMACION DEL PROFESOR.

*LOGIN.

alumno *INFORMACION DEL ALUMNO.

*LOGIN.
 Descripción del caso de uso

Actores: ADMINISTRADOR

Descripción: es el responsable de la colocación y carga inicial de las CI en las diferentes

Facultades que componen la Universidad.

Disparador: [Identifica el evento que inicializa este caso de uso. Este puede ser un evento
externo o puede ser el primer paso del flujo normal]
Precondiciones: El administrador debe estar logueado en la BD

Pos condiciones: [Describa el estado del sistema al término de la ejecución de este caso de uso.
Numere cada post condición, ejemplo
1. El documento tiene tags validos de HTML
2. El precio del producto fue actualizado en la base de datos con el nuevo
valor]
Flujo Normal: el administrador tan sólo utilizará este sistema informático para notificar la
instalación de los distintos dispositivos.

Acciones de los Actores Acción del Sistema

<Nombre del actor> <Acción del actor> <Descripción de la respuesta del sistema>

Flujos [Documente otros usos o escenarios que pudieran ocurrir en este caso de uso,
Alternativos: identifique cualquier diferencia en el flujo y las acciones que deben de ser tomadas]

Acciones de los Actores Acción del Sistema

<Nombre del actor> <Acción del actor> <Descripción de la respuesta del sistema>

Excepciones: [Describa cualquier error o condición de error que pudiera ocurrir durante la
ejecución de este caso de uso, defina como debe de responder el sistema a
esta condición.]

Actor Acción
<Nombre del <Descripción de la acción del actor>
actor>
Sistema <Descripción de la respuesta del sistema>

Inclusiones: [Liste cualquier otro caso de uso que se incluya (“Sea llamado”) por este
caso de uso. La funcionalidad común que aparece en múltiples casos de
uso]

Prioridad: [Indique la prioridad de que se implemente este caso de uso]

Frecuencia de uso: [Estimación de la cantidad de veces que este caso se uso será llamando en
alguna unidad de tiempo]

Reglas de negocio: [Lista de las reglas de negocio que pudieran influenciar este caso de uso]

Requerimientos [Identifique los requerimientos adicionales, como requerimientos no funcionales

especiales: que deben cubrirse durante la implementación de este caso de uso, estos pueden
incluir performance, o calidad]
Suposiciones: [Lista de suposiciones que fueron hechas durante el análisis que llevaron a
la aceptación de este caso de uso en la descripción del producto] Ej:
Usuario válido con permiso

Notas y Asuntos: [Lista de comentarios adicionales acerca de este caso de uso o asunto
abierto para ser determinado y que debe de ser resuelto]

Descripción del caso de uso

Actores: PROFESOR

Descripción: Su conexión al sistema vendrá siempre asociada a una solicitud/servicio de

información.

Disparador: [Identifica el evento que inicializa este caso de uso. Este puede ser un evento
externo o puede ser el primer paso del flujo normal]
Precondiciones: El edificio debe estar logueado en la BD

Pos condiciones: [Describa el estado del sistema al término de la ejecución de este caso de uso.
Numere cada post condición, ejemplo
1. El documento tiene tags validos de HTML
2. El precio del producto fue actualizado en la base de datos con el nuevo
valor]
Flujo Normal: El professor solo puede acceder a la informacion de asignaturas y horarios de
clases.

Acciones de los Actores Acción del Sistema

<Nombre del actor> <Acción del actor> <Descripción de la respuesta del sistema>

Flujos [Documente otros usos o escenarios que pudieran ocurrir en este caso de uso,
Alternativos: identifique cualquier diferencia en el flujo y las acciones que deben de ser tomadas]
Acciones de los Actores Acción del Sistema
<Nombre del actor> <Acción del actor> <Descripción de la respuesta del sistema>

Excepciones: [Describa cualquier error o condición de error que pudiera ocurrir durante la
ejecución de este caso de uso, defina como debe de responder el sistema a
esta condición.]

Actor Acción
<Nombre del <Descripción de la acción del actor>
actor>
Sistema <Descripción de la respuesta del sistema>

Inclusiones: [Liste cualquier otro caso de uso que se incluya (“Sea llamado”) por este
caso de uso. La funcionalidad común que aparece en múltiples casos de
uso]

Prioridad: [Indique la prioridad de que se implemente este caso de uso]

Frecuencia de uso: [Estimación de la cantidad de veces que este caso se uso será llamando en
alguna unidad de tiempo]

Reglas de negocio: [Lista de las reglas de negocio que pudieran influenciar este caso de uso]

Requerimientos [Identifique los requerimientos adicionales, como requerimientos no funcionales

especiales: que deben cubrirse durante la implementación de este caso de uso, estos pueden
incluir performance, o calidad]
Suposiciones: [Lista de suposiciones que fueron hechas durante el análisis que llevaron a
la aceptación de este caso de uso en la descripción del producto] Ej:
Usuario válido con permiso

Notas y Asuntos: [Lista de comentarios adicionales acerca de este caso de uso o asunto
abierto para ser determinado y que debe de ser resuelto]
 Descripción del caso de uso

Actores: ALUMNO

Descripción: Su conexión al sistema vendrá siempre asociada a una solicitud/servicio de

información.

Disparador: [Identifica el evento que inicializa este caso de uso. Este puede ser un evento
externo o puede ser el primer paso del flujo normal]
Precondiciones: El alumno debe estar logueado en la BD

Pos condiciones: [Describa el estado del sistema al término de la ejecución de este caso de uso.
Numere cada post condición, ejemplo
1. El documento tiene tags validos de HTML
2. El precio del producto fue actualizado en la base de datos con el nuevo
valor]
Flujo Normal: El alumno solo puede accede a la Carrera a la cual pertenece, su curriculum y su
estado de matricula.

Acciones de los Actores Acción del Sistema

<Nombre del actor> <Acción del actor> <Descripción de la respuesta del sistema>

Flujos [Documente otros usos o escenarios que pudieran ocurrir en este caso de uso,
Alternativos: identifique cualquier diferencia en el flujo y las acciones que deben de ser tomadas]

Acciones de los Actores Acción del Sistema

<Nombre del actor> <Acción del actor> <Descripción de la respuesta del sistema>

Excepciones: [Describa cualquier error o condición de error que pudiera ocurrir durante la
ejecución de este caso de uso, defina como debe de responder el sistema a
esta condición.]

Actor Acción
<Nombre del <Descripción de la acción del actor>
actor>
Sistema <Descripción de la respuesta del sistema>
 Inclusiones: [Liste cualquier otro caso de uso que se incluya (“Sea llamado”) por este
caso de uso. La funcionalidad común que aparece en múltiples casos de
uso]

Prioridad: [Indique la prioridad de que se implemente este caso de uso]

Frecuencia de uso: [Estimación de la cantidad de veces que este caso se uso será llamando en
alguna unidad de tiempo]

Reglas de negocio: [Lista de las reglas de negocio que pudieran influenciar este caso de uso]

Requerimientos [Identifique los requerimientos adicionales, como requerimientos no funcionales

especiales: que deben cubrirse durante la implementación de este caso de uso, estos pueden
incluir performance, o calidad]
Suposiciones: [Lista de suposiciones que fueron hechas durante el análisis que llevaron a
la aceptación de este caso de uso en la descripción del producto] Ej:
Usuario válido con permiso

Notas y Asuntos: [Lista de comentarios adicionales acerca de este caso de uso o asunto
abierto para ser determinado y que debe de ser resuelto]