• No se han encontrado resultados

Práctica de Especialidad II Fase de Elaboración: Administración de Cursos de Postgrado UCA - MINED Gema System Grupo 3

N/A
N/A
Protected

Academic year: 2018

Share "Práctica de Especialidad II Fase de Elaboración: Administración de Cursos de Postgrado UCA - MINED Gema System Grupo 3"

Copied!
46
0
0

Texto completo

(1)

1

Universidad Centroamericana

“José Simeón Cañas”

Facultad de Ingeniería y Arquitectura

Práctica de Especialidad II

Fase de Elaboración:

Administración de Cursos de Postgrado UCA - MINED

Gema System

Grupo #3

Catedrático:

Lic. Mauricio Quevedo

Presentado por:

Fátima Haydeé Hernández Brito

Tanya Angélica Nóchez Perdomo

Mónica Beatriz Palacios Torres

Donnina Beatriz Paz Rivera

Fecha de entrega:

(2)

2

ÍNDICE

Actualización de diagramas de casos de uso

3

Descripción y justificación de la arquitectura del Sistema

12

Diagrama de clase

14

Clases

15

Diagrama Entidad – Relación

17

Diagrama relacional

18

Diccionario de datos

19

Esquemas estéticos de las pantallas básicas

31

Correcciones fase inicio

41

(3)

3

ACTUALIZACIÓN DE DIAGRAMAS DE CASOS DE USO

Caso 1: Ingreso al sistema

Adminitrador UCA

Login

Nivel educativo del curso

Administración de datos del curso

Gerencia UCA

<<extend>>

Validación de usuario

<<include>>

<<extend>>

Nombre de Caso de Uso Actores Objetivo Condición inicial

1. El administrador UCA o Gerencia UCA deben ingresar un login y una contraseña para acceder al sistema.

2. Después que cualquier usuario se ha logeado correctamente, el sistema cargará la pantalla principal, la cual permitirá escoger el nivel educativo al que se desea ingresar. 3. El administrador UCA o Gerencia UCA debe escoger el nivel educativo al que desea accesar. 4. El sistema cargará la pantalla de administración de cursos de postgrados con sus

respectivos módulos.

5. Finalmente, el sistema le permite a la gerencia UCA consultar e imprimir los listados generados por la aplicación.

En el paso 1 si los usuarios no ingresan correctamente el login con su correspondiente contraseña, el sistema le mandará un mensaje de error al usuario, indicándole que los datos ingresados no son correctos o no coinciden.

Generación de reportes para administrar la información de cada módulo Excepciones

Condición de salida

Ingreso al Sistema Administrador UCA, Gerencia UCA

Permitir a los usuarios ingresar al sistema, validando su acceso.

Recibir documentación proveniente del MINED sobre cursos de postgrado a impartir.

(4)

4

Caso 2: Administración de datos del curso

Administrador UCA

Administración de datos de sede

Administración de datos de docentes (participantes y especialistas)

Administración de reproduccion y distribución de material

Administración de Notas

Generar listado

Elaboración de reportes Modificación de listados

Gerencia UCA <<include>> <<extend>> <<extend>> <<extend>> <<extend>> <<extend>>

Nombre de Caso de Uso Actores Objetivo Condición inicial

1. El administrador UCA tiene la opción de elegir uno de los siguientes módulos del sistema: * Administración de datos de sede.

* Adminitración de datos de docentes (participantes y especialistas). * Administración de reproducción y distribución de material. * Administración de notas.

2. Al ingresar en cualquiera de los módulos, el administrador UCA puede manipular la información correspondiente a estos, almacenando siempre lo realizado.

3. El sistema generará los listados provenientes de la manipulación que hizo el usuario en el módulo donde ingresó.

4. El administrador UCA puede realizar modificaciones a los listados previamente generados. 5. Luego que el usuario ha hecho modificaciones en los listados, puede guardar los cambios respectivos.

6. El sistema actualiza los datos y genera los nuevos listados.

7. La gerencia UCA tiene la opción de imprimir los listados generados por el sistema. En el paso 2 y 5 si el administrador UCA no guarda lo realizado en el módulo escogido, el sistema no podrá actualizar la información ingresada.

Generación de reportes correspondientes al módulo que ingresó el adminitrador UCA para ser revisados por la gerencia UCA.

Administración de datos de los cursos de postgrados Administrador UCA, Gerencia UCA

Definir cada módulo con los que cuenta el sistema Logeo previamente exitoso

Flujo de eventos

Excepciones

(5)

5

Caso 3: Administración de sedes

Administración de sedes

Administrador UCA

Mostrar datos de sedes Agregar datos de sedes

Eliminación de datos Modificación de datos

<<extend>> <<extend>>

<<include>> <<include>>

Generar reportes

<<extend>>

<<extend>>

Gerencia UCA

Nombre de Caso de Uso Actores Objetivo Condición inicial

1. El adminirador UCA debe ingresar al módulo de sedes para poder gestionar su información. 2. El sistema proporcionará al adminitrador UCA las siguientes opciones:

* Agregar los datos de las sedes. * Consultar de datos de sedes. * Modificación de datos de sedes. * Eliminación de datos de sedes.

3. Al ser modificados los datos de las sedes, el administrador UCA debe guardar los cambios realizados.

4. El sistema actualiza la información que ha sido modificada en dicho módulo.

5. Finalmente, el sistema le permitirá a la gerencia UCA consultar e imprimir los listados generados por el módulo de sedes.

En el paso 3 si el administrador UCA no guarda los cambios realizados en el módulo, el sistema no podrá actualizar la información ingresada.

Generación de reportes de los listados de todas las sedes participantes. Adminitración de sedes Administrador UCA, Gerencia UCA

Condición de salida

Permitir a los usuarios llevar un control de la información correspondiente a las sedes. Ingreso satisfactorio al sistema, que permite elegir el módulo de sedes.

Flujo de eventos

(6)

6

Caso 4: Administración de especialistas

Administrador UCA

Administración de especialistas

Mostrar datos de especialistas Agregar datos de especialistas

Eliminación de datos Modificación de datos

<<extend>> <<extend>>

<<include>> <<include>>

Generar reportes

Gerencia UCA

<<extend>>

<<extend>>

Nombre de Caso de Uso Actores Objetivo Condición inicial

1. El adminirador UCA debe ingresar al módulo docente para poder gestionar a su información. 2. El sistema proporcionará al adminitrador UCA las siguientes opciones:

* Agregar especialistas.

* Consulta datos de especialistas. * Modificación de datos de especialistas. * Eliminación de datos de especialistas.

3. Al ser modificados los datos de los especialistas, el administrador UCA debe guardar los cambios realizados.

4. El sistema actualiza la información que ha sido modificada en dicho módulo.

5. Finalmente, el sistema le permitirá a la gerencia UCA consultar e imprimir los listados generados por el módulo especialista.

En el paso 3 si el administrador UCA no guarda los cambios realizados en el módulo, el sistema no podrá actualizar la información ingresada.

Generación de reportes de los listados de todos los especialistas Flujo de eventos

Excepciones

Condición de salida

Administración de Especialistas Administrador UCA, Gerencia UCA

(7)

7

Caso 5: Administración de reproducción de material

Administración de reproducción de material

Agregar material a reproducir

Modificación de datos del material a reproducir Mostrar datos del material a reproducir Administrador UCA

<<extend>>

<<include>> <<extend>>

Generar reportes

Gerencia UCA

<<extend>> <<extend>>

Nombre de caso de uso Actores Objetivo Condición inicial

1. El administrador UCA ingresa al sistema la información de cada material que se requiere en cada sección de una sede, nombre del material, cantidad requerida, especialidad a la que pertenece. 2. El sistema almacena la información ingresada.

3. El administrador UCA modifica la información que ingreso con anterioridad, ya sea modificando el detalle de cada material o eliminando información.

4. El sistema actualiza los datos y los almacena.

5. El administrador UCA puede ver los cambios realizados.

6. El sistema se encarga de generar el listado de reproducción de cada material.

7. La gerencia UCA revisa la información y tiene la posibilidad de imprimir o guardar los datos. En el paso 1 y 4 si el administrador UCA no guarda los nuevos datos o cambios realizados el sistema no actualizara la información.

Generación de reportes para ser llevada a la imprenta para la reproducción del material después de ser revisados por la gerencia UCA.

Excepciones Condición de salida

Flujo de eventos

El MINED envía el detalle de la cantidad de material requerido por cada sección de una sede. Describir el proceso de reproducción de material.

Administrador UCA, Gerencia UCA

(8)

8

Caso 6: Administración de distribución de material

Administrar Distribución de material

Agregar datos de distribución

Modificar datos de distribución Mostrar datos de distribucion

Administrador UCA

<<extend>>

<<include>> <<extend>>

Gerencia UCA

Generar reportes

<<extend>>

<<extend>>

Nombre de caso de uso Actores Objetivo Condición inicial

1. El administrador UCA ingresa al sistema la cantidad de material que se enviará a cada sede, por especialidad y por nivel educativo.

2. El sistema almacena la información agregada.

3. El administrador UCA selecciona la opción de visualizar los datos ingresados.

4. El administrador UCA selecciona una dato de los mostrados para poder realizar cambios a esa información .

5. El sistema actualiza la información ingresada.

6. El sistema ordena la información que corresponde a cada sede.

7. El gerente UCA revisa la información de distribución del material por sede, la guarda o imprime. En el paso 1 y 4 si el administrador UCA no guarda los nuevos datos o cambios realizados el sistema no actualizara la información.

Generación de reportes de distribucion del material que serán vistos por la gerencia UCA. El MINED envía el detalle de la cantidad de material requerido por cada sección de una sede.

Flujo de eventos

Excepciones

Condición de salida

Administración de distribución del material

Administrador UCA, Gerencia UCA

(9)

9

Caso 7: Administración de transportistas

Administrar Transportistas

AgregarTransportistas

Modificar Transportistas Mostrar Transportistas

Administrador UCA

<<extend>>

<<include>> <<extend>>

Generar reportes

Gerencia UCA

<<extend>>

<<extend>>

Nombre de caso de uso Actores Objetivo Condición inicial

1. El administrador UCA ingresa datos personales del transportista, placa del vehículo en el que distribuirá el material.

2. El sistema almacena la información.

3. El administrador UCA visualiza la información ingresada. 4. El administrador UCA modifica datos del transportista 5. El sistema actualiza los datos.

6. La gerencia UCA revisa la información del transportista, la guarda o imprime. En el paso 1 y 4 si el administrador UCA no guarda los nuevos datos o cambios realizados el sistema no actualizará la información.

Condición de salida Generación de reportes del transportista serán vistos por la gerencia UCA. Administrador UCA, Gerencia UCA

Incluir un registro del transportista que se encargará de la distribución del material. Es necesario que el administrador UCA tenga el listado de la distribución de material.

Flujo de eventos

Excepciones

(10)

10

Caso 8: Administrar información de participantes

Administrar información de participantes

Agregar participantes

Modificar participantes Eliminar participantes

Administrador UCA

<<extend>>

<<include>>

Mostrar participantes

Gerencia UCA

Generar reportes

<<include>> <<extend>> <<extend>>

<<extend>>

Nombre de caso de uso Actores Objetivo Condición inicial

1. El administrador UCA ingresa datos personales del participante. 2. El sistema guarda los datos del participante.

3. Administrador UCA ve la información ingresada.

4. Administrador UCA modifica o elimina los datos del participante. 5. El sistema actualiza los datos.

6. La gerencia UCA revisa la información del transportista, la guarda o imprime. En el paso 1 y 4 si el administrador UCA no guarda los nuevos datos o cambios realizados el sistema no actualizara la información.

Condición de salida Generación de reportes de los docentes que participan en un curso.

Flujo de Eventos

Excepciones

Administración de participantes

Administrador UCA, Gerencia UCA

(11)

11

Caso 9: Administración de notas

Administrar notas

Agregar notas Mostrar notas

Modificar notas

Generar reportes

Administrador UCA

Gerencia UCA

<<extend>> <<extend>>

<<extend>>

<<extend>>

<<include>>

Nombre de caso de uso Actores Objetivo Condición inicial

1. El administrador UCA ingresa la nota final del docente. 2. El sistema guarda la nota del participante.

3. Administrador UCA visualiza la información ingresada. 4. Administrador UCA modifica la nota del participante

5. El sistema actualiza los datos y muestra a aquellos docentes que aprobaron el curso a partir de la nota que obtuvo.

6. La gerencia UCA visaliza las notas, las guarda o imprime.

En el paso 1 y 4 si el administrador UCA no guarda los nuevos datos o cambios realizados el sistema no actualizara la información.

Condición de salida Generación de reportes de los docentes que aprueban/reprueban el curso en base a su nota.

MINED envía el listado de notas de los docentes

Flujo de eventos

Excepciones

Administración de notas Administrador UCA, Gerencia UCA

(12)

12

DESCRIPCIÓN Y JUSTIFICACIÓN DE LA ARQUITECTURA

DEL SISTEMA

Arquitectura MVC

Es un estilo de arquitectura de software que separa los datos de una aplicación, la interfaz de

usuario y la lógica de control en tres componentes distintos:

modelo, vista y controlador

. Es más

comúnmente empleada en aplicaciones web.

El modo en el que se desarrolla esta arquitectura es la siguiente:

Modelo:

representa la información con la cual el sistema opera y es responsable de:

 Acceder a la capa de almacenamiento de datos,

haciendo que la vista y las acciones sean

independientes.

 Define las reglas de negocio (la funcionalidad del sistema).  Lleva un registro de las vistas y controladores del sistema.

 Si estamos ante un modelo activo, notificará a las vistas los cambios que en los datos pueda producir un agente externo.

Vista:

se encarga de la interacción entre los usuarios y los datos que se encuentran en el

modelo, comúnmente conocido como interfaz de usuario. En general se encarga de:

 Recibir datos del modelo y se los muestra al usuario.

 Tiene un registro de su controlador asociado (normalmente porque además lo instancia).

 Pueden dar el servicio de "Actualización ()", para que sea invocado por el controlador o por el modelo.

Controlador

: se encarga de responder a los eventos, usualmente acciones del usuario, e invoca

peticiones al modelo y, probablemente, a la vista. Responsable de:

 Recibe los eventos de entrada (un clic, un cambio en un campo de texto, etc.).

 Contiene reglas de gestión de eventos. Estas acciones pueden suponer peticiones al modelo o a las vistas.

(13)

13

Justificación

La razón por la cual se ha elegido esta arquitectura es porque permite realizar interfaces

llamativas y amigables para el usuario, así como también, para tener centralizados toda la

información de los cursos de postgrados que administra La Unidad de Proyectos de la UCA, la

cual permite a los usuarios acceder desde distintos ordenadores al sistema desde diversas

plataformas.

Además, la arquitectura MVC proporciona la característica de escalabilidad al sistema, ya que si

en el futuro se requiere de algún tipo de cambio, no necesitaría modificación toda la aplicación,

sino solamente una capa determinada.

Herramientas a usar

PHP5, CSS, Joomla y WampServer

Servidor de Base de Datos Relacional

MySql 5.0.

Servidor de Aplicación Web

(14)

14

DIAGRAMA DE CLASE

Docente +nombreDocente +apellidoDocente +duiDocente +nitDocente +nipDocente +domicilioDocente +telefonoDocente +emailDocente +tipoDocente Materia +nombreMateria +notaMateria Curso +nombreCurso +fechaInicio +fechaFin +nivelCurso Seccion +numSeccion Departamento +nombreDepto +zonaDepto +cabeceraDepto +codigoDepto Transportista +nombreTransportista +duiTransportista +telTransportista +nitTransportista Material +especialidadMaterial +numPagMaterial +fechaPedidoMaterial +fechaRecibidoMatterial +nombreImprenta Sede +nombreSede +direccionSede +nombreContactoSede +telSede +emailSede 1 * Vehiculo +placaVehiculo +tipoVehiculo 1 1 1 * 1 *

1 * * 1

1 * 1

(15)
(16)

16

(17)

Docente Materia Curso Nivel imparte recibe 1,1 se da corresponde 1,n Seccion Sede

Departamento esta en

(18)
(19)

19

DICCIONARIO DE DATOS

Atributo PK FK AK Tipo Precisión Escala Nulo AutoGenerado Dominio Valor por omisión

idDocente x int(10) identity (1,1) [0-9]

nombreDocen varchar(50) [A-Z][a-z][0-9]

apellidoDocen varchar(50) [A-Z][a-z][0-9]

duiDocen x varchar(10) 99999999-9

nitDocen x varchar(17) 9999-999999-999-9

nipDocen x int(7) 9999999

direccionDocen varchar(50) [A-Z][a-z][0-9]

idTipoDocen x int(10) [0-9]

Descripción: almacena todos los datos personales de cada uno de los docentes que participan e imparten los diferentes cursos de postgrados.

DOCENTE

Atributo

idDocente nombreDocen apellidoDocen duiDocen nitDocen direccionDocen

idTipoDocen Identificador que permite saber si se trata del docente que recibe el curso, el docente que es coordinador o especialista

Descripción

Identificador único que se le asigna a cada docente.

Primer y segundo apellido del docente que participa o imparte los diferentes cursos de postgrados. Primer y segundo nombre del docente que participa o imparte los diferentes cursos de postgrados.

Número único de identidad del docente según su Documento Único de Identidad (DUI).

(20)

20

Atributo PK FK AK Tipo Precisión Escala Nulo AutoGenerado Dominio Valor por omisión

idEmailDocente x int(10) identity (1,1) [0-9]

idDocente x int(10) [0-9]

emailDoc varchar(50) [A-Z][a-z][0-9]

Descripción: almacena todos los posibles correos electrónicos que los docentes poseen.

EMAILXDOCENTE

Atributo

idEmailDocente idDocente

emailDocen Correos electrónicos que pertenecen a cada docente que participa o imparte los diferentes cursos de postgrados. Identificador único que corresponde a cada docente que participa o imparte los diferentes cursos de postgrados. Número correlativo que identifica a cada correo electrónico que tiene el docente.

Descripción

Atributo PK FK AK Tipo Precisión Escala Nulo AutoGenerado Dominio Valor por omisión

idTelXDocen x int(10) identity (1,1) [0-9]

idDocente x int(10) [0-9]

numTel varchar(9) 9999-9999

Descripción: guarda todos los posibles tipos de teléfono que tiene cada docente que participa o imparte los diferentes cursos de postgrados.

TELXDOCENTE

Atributo

idTelXDocen idDocente

numTel Número telefónico que pertenece a cada paciente.

Identificador único que permite saber las especificaciones de un labo en particular Número correlativo que identifica cada teléfono que tiene el docente.

Descripción

Atributo PK FK AK Tipo Precisión Escala Nulo AutoGenerado Dominio Valor por omisión

idTipoDocen x int(10) Identity(1,1) [0-9]

tipoDocente varchar(20) [A-Z][a-z][0-9]

Descripción: almacena los tipos de docentes que participan o imparten los diferentes cursos de postgrado.

(21)

21

Atributo

idTipoDocen tipoDocente

Indicador único para cada departamento.

Diferencia entre los docentes que participan e imparten los diferentes cursos de postgrados.

Descripción

Atributo PK FK AK Tipo Precisión Escala Nulo AutoGenerado Dominio Valor por omisión

codMateria x int(2) Identity(1,1) [0-9]

nombreMateria varchar(20) [A-Z][a-z][0-9]

MATERIA

Descripción: contiene la información correspondiente de cada una de las materias que son impartidas en los cursos de postgrados.

Atributo

codMateria nombreMateria

Descripción

Identificador correspondiente a cada materia impartida en los cursos de postgrados. Nombre de la especialidad de cada materia.

Atributo PK FK AK Tipo Precisión Escala Nulo AutoGenerado Dominio Valor por omisión

codMateria x int(2) [0-9]

idCurso x int(2) [0-9]

MATERIAXCURSO

Descripción: almacena identificadores de las materias por cada curso

Atributo

codMateria idCurso

Identificador corespondiente a cada materia impartida en los cursos de postgrados.

Identificador corespondiente a cada uno de los cursos de postgrados impartidos en las diferentes sedes.

(22)

22

Atributo PK FK AK Tipo Precisión Escala Nulo AutoGenerado Dominio Valor por omisión

idCurso x int(2) Identity(1,1) [0-9]

numCurso int(2) [0-9]

fechaInicio date dd/mm/yyyy

fechaFin date dd/mm/yyyy

CURSO

Descripción: guarda la información de cada curso de postgrados impartidos en las diferentes zonas del país.

Atributo

idCurso numCurso fechaInicio fechaFin

Identificador único que pertenece a cada uno de los cursos de postgrados impartidos.

Nivel al que pertenece cada curso de postgrado impartido para educación básica (tecer ciclo) y media.

Descripción

fecha exacta del inicio de cada curso que se imparte. fecha exacta de la finalización de cada curso impartido.

Atributo PK FK AK Tipo Precisión Escala Nulo AutoGenerado Dominio Valor por omisión

idCurso x int(10) [0-9]

idNivel x int(10) [0-9]

CURSOXNIVEL

Descripción: almacena los diferentes cursos con su respectivo nivel al que pertenecen.

Atributo

idCurso idNivel

Descripción

Identificador único que pertenece a cada uno de los cursos de postgrados impartidos. Identificador único que pertenece al nivel de cada curso de postgrado que se imparte.

Atributo PK FK AK Tipo Precisión Escala Nulo AutoGenerado Dominio Valor por omisión

idNivel x int(10) Identity(1,1) [0-9]

nombreNivel varchar [A-Z][a-z][0-9]

NIVEL

(23)

23

Atributo

idNivel

nombreNivel Nombre que identifica el nivel al que pertenece cada curso.

Descripción

Indicador único que pertenece al nivel de cada curso de postgrado que se imparte.

Atributo PK FK AK Tipo Precisión Escala Nulo AutoGenerado Dominio Valor por omisión

idDocente x int(10) [0-9]

idNota x int(8) identity (1,1) [0-9]

nota float [0-9] 0.0

NOTADOC

Descripción: almacena las notas que obtuvo un docente al llevar una materia

Atributo

idDocente

idNota identificador de la nota que obtuvo el docente

nota

Descripción

identificador del docente que llevo una materia y obtuvo una nota

valor final de la nota que obtuvo el docente al llevar una materia

Atributo PK FK AK Tipo Precisión Escala Nulo AutoGenerado Dominio Valor por omisión

codDepto x int(10) identity(1,1) [0-9]

nombreDepto varchar(20) [A-Z][a-z][0-9]

zonaDepto varchar(20) [A-Z][a-z][0-9]

cabeceraDepto varchar(30) [A-Z][a-z][0-9]

DEPARTAMENTO

(24)

24

Atributo

codDepto

nombreDepto nombre con el que se distingue un departamento de otro zonaDepto

cabeceraDepto

Descripción

numero único con el que puede identificarse un departamento

nombre de la ubicación que se le ha dado a un departamento en el país nombre de la ciudad principal del departamento

Atributo PK FK AK Tipo Precisión Escala Nulo AutoGenerado Dominio Valor por omisión

idSede x int(10) 1,1 [0-9]

nombreSede varchar(25) [A-Z][a-z][0-9]

direccionSede varchar(50) [A-Z][a-z][0-9]

emailSede varchar(30) x [A-Z][a-z][0-9]

contactoSede varchar(30) [A-Z][a-z][0-9]

codDepto x int(10) [0-9]

SEDE

Descripción: lugar(es) en el que se desarrolla un curso en un departamento determinado

Atributo

idSede

nombreSede nombre con el que se conoce la sede, usualmente es el nombre del centro escolar en el que se impartira direccionSede

emailSede

contactoSede nombre de la persona que servira de enlace entre el ministerio y la sede codDepto identificador único que corresponde a un departamento

Descripción

número único con el que se identificara una sede

ubicación fisica de la sede

nombre del medio con el que podemos comunicarnos con la sede via web

Atributo PK FK AK Tipo Precisión Escala Nulo AutoGenerado Dominio Valor por omisión

idTelxSede x int(10) 1,1 [0-9]

idSede x int(10) [A-Z][a-z][0-9]

numTel varchar(10) [A-Z][a-z][0-9]

TELxSEDE

(25)

25

Atributo

idTelxSede

idSede indica la sede a la cual pertenece el número telefonico

numTel es el número telefonico de una sede

Descripción

identificador único para cada uno de los números que posea una sede

Atributo PK FK AK Tipo Precisión Escala Nulo AutoGenerado Dominio Valor por omisión

idSeccion x int(10) (1,1) [0-9]

numSeccion varchar(25) [A-Z][a-z][0-9]

codMateria x int(10) [A-Z][a-z][0-9]

idSede x int(10) [A-Z][a-z][0-9]

SECCION

Descripción: distribución que se hace para que una materia sea impartida en varias aulas

Atributo

idSeccion

numSeccion número asignado por el mined a la sección codMateria

idSede

número único para cada una de las secciones que hayan en una sede

identificador de la materia que se impartira en una sección número que indica la sede a la cual pertenece la sección

(26)

26

Atributo PK FK AK Tipo Precisión Escala Nulo AutoGenerado Dominio Valor por omisión

idMaterialDidáctico x int(10) identity 1,1 [0-9]

nombreMaterial varchar(20) [A-Z][a-z][0-9]

numPagMaterial int(4) [0-9]

fechaPedidoMat varchar(30) [A-Z][a-z][0-9]

fechaRecibidoMat datatime dd/mm/yy

nombreImprenta datatime dd/mm/yy

idEspecialidad x int(10) [0-9]

MATERIAL DIDACTICO

Descripción: almacena los datos que identifican al material usado en un curso

Atributo

idMaterialDidáctico

nombreMaterial nombrecon el que se conoce el material de apoyo a usar en un curso numPagMaterial

fechaPedidoMat

fechaRecibidoMat fecha en la que se recibe el material solicitado

nombreImprenta nombre de la imprenta encargada de la reproducción del material de apoyo idEspecialidad identificador de la especialidad a la que corresponde un material

Descripción

identificador de cada material usado en un curso determinado

total de paginas que posee un material

fecha en la que se realizara el pedido para la elaboración de cada material

Atributo PK FK AK Tipo Precisión Escala Nulo AutoGenerado Dominio Valor por omisión

idEspecialidad x int(10) identity 1,1 [0-9]

nombreEspecialidad varchar(30) [A-Z][a-z][0-9]

ESPECIALIDADM

(27)

27

Atributo

idEspecialidad

nombreEspecialidad nombre que identificara la diferencia entre un tipo de material y otro para los diferentes cursos

Descripción

identificador que se le asigna a las especialidades de los materiales didacticos

Atributo PK FK AK Tipo Precisión Escala Nulo AutoGenerado Dominio Valor por omisión

idMaterialDidáctico x int(10) [0-9]

idTransportista x int(10) [0-9]

rutaTraslado varchar(50) [A-Z][a-z][0-9]

cantidadMaterial int(10) [0-9]

personaRecibe varchar(50) [A-Z][a-z][0-9]

zonaAentregar varchar(20) [A-Z][a-z][0-9]

distanciaRecorrida varchar(15) [A-Z][a-z][0-9]

MATERIALxTRANSPORTISTA

Descripción: guarda el dato de los materiales que seran entregados por un transportista

Atributo

idMaterialDidáctico

idTransportista identificador que se le asigna a un transportista rutaTraslado

cantidadMaterial

personaRecibe nombre de la persona responsable de recibir el material que lleva el transportista a una sede zonaAentregar ubicación en la que sera entregado el material por un transportista

distanciaRecorrida total de kilometros que el transportista recorre para entregar el material en una sede

Descripción

identificador único que corresponde a un material determinado

(28)

28

Atributo PK FK AK Tipo Precisión Escala Nulo AutoGenerado Dominio Valor por omisión

idTransportista x int(10) identity (1,1) [0-9]

nombreTransportista varchar(50) [A-Z][a-z][0-9]

duiTransp varchar(10) 99999999-9

nitTransp varchar(17) 9999-999999-999-9

TRANSPORTISTA

Descripción: se encarga de almacenar los datos de las personas que trasladaran los materiales a las diferentes sedes

Atributo

idTransportista

nombreTransportista nombre con el que es conocido el transportista duiTransp

nitTransp

Descripción

identificador que se le asignara a un transportista

numero único de identidad personal asignado a una persona (DUI) número único de identificación tributaria asignado a una persona

Atributo PK FK AK Tipo Precisión Escala Nulo AutoGenerado Dominio Valor por omisión

idTransportista x int(10) [0-9]

idTelxTransp x int(10) identity (1,1) [0-9]

numTelefono varchar(9) 9999-9999

TELxTRANSP

Descripción: tabla que contiene los números telefonicos mediante los cuales se puede contactar a un transportista en particular

Atributo

idTransportista

idTelxTransp correlativo que indicará el número de telefono que le corresponde a un transportista numTelefono

Descripción

identificador que se le asignara a un transportista

(29)

29

Atributo PK FK AK Tipo Precisión Escala Nulo AutoGenerado Dominio Valor por omisión

idVehiculo x int(10) identity (1,1) [0-9]

tipoVehiculo varchar(65) [A-Z][a-z]

placaVehiculo varchar(7) 9999-9999

idTransportista x int(10) [0-9]

VEHICULO

Descripción: tabla que contiene los números telefonicos mediante los cuales se puede contactar a un transportista en particular

Atributo

idVehiculo

tipoVehiculo descripción del tipo de vehiculo que posee el transportista placaVehiculo

idTransportista permite relacionar que vehiculo pertenece al transportista

Descripción

correlativo que se le asignará a cada vehiculo

número único que es asignado por el VMT a un carro

Atributo PK FK AK Tipo Precisión Escala Nulo AutoGenerado Dominio Valor por omisión

idUsuario x int(10) identity (1,1) [0-9]

nombreUsuario varchar(30) [A-z][a-z][0-9]

apellidoUsuario varchar(30) [A-z][a-z][0-9]

loginUsuario varchar(10) [A-z][a-z][0-9]

passUsuario varchar(10) [A-z][a-z][0-9]

tipoUsuario varchar(30) [A-z][a-z][0-9]

USUARIO

(30)

30

Atributo

idUsuario

nombreUsuario nombre con el que es conocido el usuario apellidoUsuario

loginUsuario sera el nombre que el usuario tendrá en el sistema para poder acceder al mismo, el cual debe ser único passUsuario representa la contraseña que el usuario tiene para logearse en el sistema

tipoUsuario indica el tipo de usuario que puede acceder a la aplicación, en este caso tenemos al AdminUCA y al GerenteUCA

Descripción

identificador único que se le asignara a cada usuario que acceda al sistema

(31)

Área de navegación entre

módulos Área de

despliegue de la información

Título del sistema

Logos del Sistema

Área de navegación en el sistema

Las pantallas que se utilizarán para el sistema son las siguientes:

(32)

32

(33)

33

(34)

34

(35)

35

(36)

36

(37)

37

(38)

38

(39)

39

(40)

40

(41)

41

CORRECCIONES FASE DE INICIO

1) Cambio de forma de ingreso a la aplicación

Se realizó un cambio en la forma en que inicialmente estaba pensado el ingreso a la aplicación,

la cual siempre coincide con el uso de una página inicial que válida el ingreso de los usuarios. A

continuación se detalla del método inicial contemplado y de la corrección efectuada:

INICIAL

El usuario ingresa a la página inicial de la aplicación, que consistía en la validación de los datos

que lo identifican, mediante su nombre de usuario y su contraseña. Se designa una casilla para el

ingreso de cada uno de estos datos.

Luego que el usuario se ha logeado correctamente, la aplicación desplegará la pantalla de

elección de nivel educativo y el número de curso, la cual contiene dos casillas para la selección

tanto del nivel como para el curso, en donde se determinaría a que datos se tendría acceso, entre

los datos se distingue el nivel (Bachillerato o Tercer Ciclo) y el número de curso al que se

pretende acceder.

Finalmente al haber realizado la etapa anterior, el usuario tendría acceso a los datos que desea

administrar. Para cambiar el nivel y curso actual, se tenía que reiniciar la aplicación, es decir

saliendo de ésta e ingresando nuevamente.

CORRECCIÓN

El usuario ingresa a la página inicial de la aplicación, ingresa los datos que lo identifican como

tal, mediante su nombre de usuario y su contraseña. Se designa una casilla para el ingreso de

cada uno de estos datos.

(42)

42

2) Cambio en la distribución y contenido de uno de los casos de uso

Se realizó un cambio en los Casos de Uso Especialistas y Participantes, junto con las notas de los

Participantes.

INICIAL

Inicialmente existía un Módulo de Especialistas y Participantes, donde las notas de los

participantes se trabajarían de forma independiente a este módulo. Además, este módulo era uno

solo, el cual identificaría en una sola lista a los Especialistas y los Participantes.

CORRECCIÓN

Se separó el módulo de Especialistas y Participantes por dos módulos independientes, en los

cuales el módulo Especialista solo contendrá la lista de los Especialistas y los datos requeridos, y

en el caso del módulo de Participantes, además de incluir sus datos personales también se

manejará dentro de este módulo las notas de cada Participante, para que de esta forma se pueda

tener en un solo módulo la información necesaria de los Participantes.

3) Corrección en el manejo de uno de los casos de uso

Subdivisión del Caso de Uso:

Reproducción y distribución de material

.

La división se realizó en tres módulos llamados:

Reproducción de Material, Distribución de

Material y Transportistas

INICIAL

(43)

43

CORRECCIÓN

Se realizó en el caso de uso inicial llamado

Reproducción y Distribución de Material

una

división, la cual consiste en subdividir este caso de uso en tres partes, las cuales son:

Reproducción de Material, Distribución de Material y Transportistas

, ya que estos últimos

módulos que se realizaron, ayudarán al usuario a visualizar con mayor detalle cada información,

ya sea del material didáctico (como reproducción y distribución), así como también la

información personal y requerida de los transportistas que llevarán el material didáctico a sus

respectivas sedes. Además, al separar los módulo se tendrá una información más precisa, la cual

estará contemplada en cada módulo que se realizará

4) Cambio de nombre a caso de uso

Se contempló además un cambio referido a uno de los casos de uso. A continuación el detalle:

INICIAL

El nombre del caso de uso

Organización de la reproducción y distribución de material

no

indicaba en realidad los objetivos que se buscan dentro de este proceso, pues aunque la actividad

dentro de la oficina de proyectos se realiza mediante la organización y logística del proceso de

verificación de la reproducción y distribución de material didáctico, el proceso dentro de nuestra

aplicación no se realiza a modo únicamente de organización.

CORRECCIÓN

(44)

44

5) Diagrama de clases

Al diagrama de clases que se tenía previamente diseñado se le agregaron más clases, debido a

todos los cambios que se realizaron para que en la fase de implementación, la aplicación cuente

con todo lo necesario para su desarrollo.

(45)

Horas Estimadas VRS Horas Reales

Id. Acitividad Comienzo Fin Duración

26 sep 2010 3 oct 2010

9

2 5

28

26 29 30 1 4 6 7 8

25 27 3

2 Actualización de Diagramas de Caso 02/10/2010 04/10/2010 3d de Uso

4 Descripción y justificación de 25/09/2010 25/09/2010 1d arquitectura

6 Diagrama de Clases 05/10/2010 06/10/2010 2d

8 Diagrama Entidad-Relación y 09/10/2010 11/10/2010 3d Relacional

10 Esquemas de pantallas 13/10/2010 17/10/2010 5d

12 Correcciones etapa anterior 12/10/2010 14/10/2010 3d

Encargado

Mónica Palacios y Tania Nochez

Donnina Paz y Fátima Hernández

Donnina Paz y Fátima Hernandez

Fátima Hernández y Donnina Paz

Todas

Todas

Numero de Horas

10h 6h 7h 20h 40h 12h

14 Actualización de cronograma Todas 18/10/2010 18/10/2010 1d 3h 1 Actualización de Diagramas de Caso Todas las integrantes 04/10/2010 06/10/2010 3d 13h

de Uso

3 Donnina Paz y Fátima 09/10/2010 09/10/2010 1d 2h

Hernández Descripción y justificación de

arquitectura

5 Donnina Paz y Fátima 09/10/2010 12/10/2010 4d 6h

Hernández Diagrama de Clases

7 Donnina Paz y Fátima 27/09/2010 09/10/2010 13d 24h

Hernández Diagrama Entidad-Relación y

Relacional

9 Esquemas de pantallas Todas las integrantes 27/09/2010 18/10/2010 22d 58h

11 Correcciones etapa anterior Todas 17/10/2010 18/10/2010 2d 5h

13 Actualización de cronograma Donnina Paz 18/10/2010 18/10/2010 1d 2h

15 Entrega Fase de Elaboración Todas 19/10/2010 19/10/2010 1d

Tiempo Real: 110 h

Tiempo Estimado: 98 h

10 oct 2010 17 oct 2010

(46)

90 95 100 105 110

Tiempo Real

Tiempo Estimado

Referencias

Documento similar

Cedulario se inicia a mediados del siglo XVIL, por sus propias cédulas puede advertirse que no estaba totalmente conquistada la Nueva Gali- cia, ya que a fines del siglo xvn y en

Abstract: This paper reviews the dialogue and controversies between the paratexts of a corpus of collections of short novels –and romances– publi- shed from 1624 to 1637:

Entre nosotros anda un escritor de cosas de filología, paisano de Costa, que no deja de tener ingenio y garbo; pero cuyas obras tienen de todo menos de ciencia, y aun

The part I assessment is coordinated involving all MSCs and led by the RMS who prepares a draft assessment report, sends the request for information (RFI) with considerations,

o Si dispone en su establecimiento de alguna silla de ruedas Jazz S50 o 708D cuyo nº de serie figura en el anexo 1 de esta nota informativa, consulte la nota de aviso de la

This section provides guidance with examples on encoding medicinal product packaging information, together with the relationship between Pack Size, Package Item (container)

d) que haya «identidad de órgano» (con identidad de Sala y Sección); e) que haya alteridad, es decir, que las sentencias aportadas sean de persona distinta a la recurrente, e) que

De hecho, este sometimiento periódico al voto, esta decisión periódica de los electores sobre la gestión ha sido uno de los componentes teóricos más interesantes de la