METODOLOGÍA DE INVESTIGACIÓN
Metodología RUP
Los
orígenes de RUP se remontan al modelo espiral original de Barry Boehm. Ken
Hartman, uno de los contribuidores claves de RUP colaboró con Boehm en la
investigación. En 1995 Rational Software compró una compañía sueca llamada
Objectory AB, fundada por Ivar Jacobson, famoso por haber incorporado los casos
de uso a los métodos de desarrollo orientados a objetos. El Rational Unified Process
fue el resultado de una convergencia de Rational Approach y Objectory (el
proceso de la empresa Objectory AB). El primer resultado de esta fusión fue el
Rational Objectory Process, la primera versión de RUP, fue puesta en el mercado
en 1998, siendo el arquitecto en jefe Philippe Kruchten.
El Proceso Unificado Rupacional (Rational Unified Process en inglés,
habitualmente resumido como RUP)
es un proceso de desarrollo de software y junto con el Lenguaje Unificado de
Modelado UML, constituye la metodología estándar más utilizada para el
análisis, implementación y documentación de sistemas orientados a objetos.
El RUP
no es un sistema con pasos firmemente establecidos, sino un conjunto de
metodologías adaptables al contexto y necesidades de cada organización.
Originalmente se diseñó un proceso
genérico y de dominio público, el Proceso Unificado, y una especificación más
detallada, el Rational Unified Process, que se vendiera como producto
independiente.
Principios de Desarrollo
El RUP está basado en 6 principios clave que son los
siguientes:
ü Adaptar el proceso
El
proceso deberá adaptarse a las necesidades del cliente ya que es muy importante
interactuar con él. Las características propias del proyecto u organización. El
tamaño del mismo, así como su tipo o las regulaciones que lo condicionen,
influirán en su diseño específico. También se deberá tener en cuenta el alcance
del proyecto en un área sub-formal.
ü Equilibrar
prioridades
Los requisitos de los diversos participantes pueden ser
diferentes, contradictorios o disputarse recursos limitados. Debe encontrarse un equilibrio que satisfaga
los deseos de todos. Gracias a este equilibrio se podrán corregir
desacuerdos que surjan en el futuro.
ü Demostrar valor
iterativamente
Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas. En cada iteración se
analiza la opinión de los inversores, la estabilidad y calidad del producto, y
se refina la dirección del proyecto así como también los riesgos involucrados
ü Colaboración entre
equipos
El desarrollo de software no lo hace una única persona sino
múltiples equipos. Debe haber una comunicación fluida para coordinar
requisitos, desarrollo, evaluaciones, planes, resultados, etc.
ü Elevar el nivel de
abstracción
Este principio dominante motiva el uso de conceptos
reutilizables tales como patrón del software, lenguajes 4GL o marcos de referencia
(frameworks) por nombrar algunos. Esto
evita que los ingenieros de software vayan directamente de los requisitos a la
codificación de software a la medida del cliente, sin saber con certeza qué
codificar para satisfacer de la mejor manera los requisitos y sin comenzar
desde un principio pensando en la reutilización del código. Un alto nivel de
abstracción también permite discusiones sobre diversos niveles y soluciones
arquitectónicas. Éstas se pueden acompañar por las representaciones visuales de
la arquitectura, por ejemplo con el lenguaje UML.
ü Enfocarse en la
calidad
El control de calidad no debe realizarse al final de cada
iteración, sino en todos los
aspectos de la producción. El aseguramiento de la calidad forma parte del
proceso de desarrollo y no de un grupo independiente.
Ciclo de vida
El ciclo
de vida RUP es una implementación del Desarrollo en espiral. Fue creado
ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida
organiza las tareas en fases e iteraciones.
RUP
divide el proceso en cuatro fases, dentro de las cuales se realizan varias
iteraciones en número variable según el proyecto y en las que se hace un mayor
o menor hincapié en las distintas actividades.
Las
primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la
comprensión del problema y la tecnología, la delimitación del ámbito del
proyecto, la eliminación de los riesgos críticos, y al establecimiento de una baseline
(Línea Base) de la arquitectura.
Durante
la fase de inicio las iteraciones hacen mayor énfasis en actividades de
modelado del negocio y de requisitos.
En la
fase de elaboración, las iteraciones se orientan al desarrollo de la baseline
de la arquitectura, abarcan más los flujos de trabajo de requisitos, modelo de
negocios (refinamiento), análisis, diseño y una parte de implementación orientado a la baseline de la arquitectura.
En
la fase de construcción, se lleva a cabo la construcción del producto por medio
de una serie de iteraciones.
Para cada iteración se selecciona algunos Casos de Uso, se refina su análisis y
diseño y se procede a su implementación y pruebas. Se realiza una pequeña
cascada para cada ciclo. Se realizan tantas iteraciones hasta que se termine la
implementación de la nueva versión del producto.
En la
fase de transición se pretende garantizar que se tiene un producto preparado
para su entrega a la comunidad de usuarios.
Como se
puede observar en cada fase participan todas las disciplinas, pero que
dependiendo de la fase el esfuerzo dedicado a una disciplina varía.
Características
Sus principales características
son:
ü
Forma disciplinada
de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo)
ü
Pretende
implementar las mejores prácticas en Ingeniería de Software
ü
Desarrollo
iterativo
ü
Administración
de requisitos
ü
Uso de
arquitectura basada en componentes
ü
Control de
cambios
ü
Modelado visual
del software
ü
Verificación de
la calidad del software
Aspectos
RUP comprende 2 aspectos importantes:
Proceso: Las etapas de
esta sección son:
ü
Modelado de
negocio
ü
Requisitos
ü
Análisis y
Diseño
ü
Implementación
ü
Pruebas
ü
Despliegue
Soporte:
En esta parte nos encontramos con las siguientes etapas:
ü
Gestión del
cambio y configuraciones
ü
Gestión del
proyecto
ü
Entorno
Fases
La
estructura dinámica de RUP es la que permite que éste sea un proceso de
desarrollo fundamentalmente iterativo, y se ve inmersa en 4 fases:
ü
Inicio (También
llamado Incepción o Concepción)
ü
Elaboración
ü
Desarrollo(También
llamado Implementación, Construcción)
ü
Cierre (También
llamado Transición)
Fase de Inicio: Esta fase tiene
como propósito definir y acordar el alcance del proyecto con los
patrocinadores, identificar los riesgos asociados al proyecto, proponer una
visión muy general de la arquitectura de software y producir el plan de las
fases y el de iteraciones posteriores.
Fase de elaboración: En la fase de
elaboración se seleccionan los casos de uso que permiten definir la
arquitectura base del sistema y se desarrollaran en esta fase, se realiza la
especificación de los casos de uso seleccionados y el primer análisis del
dominio del problema, se diseña la solución preliminar.
Fase de Desarrollo: El propósito de
esta fase es completar la funcionalidad del sistema, para ello se deben
clarificar los requisitos pendientes, administrar los cambios de acuerdo a las
evaluaciones realizados por los usuarios y se realizan las mejoras para el
proyecto.
Fase de Cierre: El propósito de
esta fase es asegurar que el software esté disponible para los usuarios
finales, ajustar los errores y defectos encontrados en las pruebas de
aceptación, capacitar a los usuarios y proveer el soporte técnico necesario. Se
debe verificar que el producto cumpla con las especificaciones entregadas por
las personas involucradas en el proyecto.
REQUERIMIENTOS FUNCIONALES
Cuadro 21. Requerimiento Funcional 001
ID
Requerimiento
|
001
|
Nombre
Requerimiento
|
Automatizar
la gestión académica con el fin de agilizar dichos procesos y garantizar
fácil acceso a la información
|
Identificación
Requerimiento
|
Requerimiento
Funcional De Negocio
|
Características
|
Automatización
general del proceso de inscripción
Agilizar
registros
Fácil y
rápido acceso
|
Descripción
Requerimiento
|
Automatizar
(dentro de lo posible) lo relacionado a la gestión académica en la
Institución
|
Prioridad
Requerimiento
|
    Alta Media Alta Media Media Baja Baja |
Fuente:
Los Autores (2013)
Cuadro 22. Requerimiento
Funcional 002
ID
Requerimiento
|
002
|
Nombre
Requerimiento
|
Dicho
sistema debe contribuir a decrementar el volumen de trabajo con respecto a lo
que se ejecuta manualmente
|
Identificación
Requerimiento
|
Requerimiento
Funcional De Negocio
|
Características
|
Disminución
de la carga de trabajo
Desincorporación
paulatina de procesos manuales
|
Descripción
Requerimiento
|
Disminución
del volumen de trabajo manual
|
Prioridad
Requerimiento
|
 Alta Media Alta Media Media Baja Baja |
Fuente:
Los Autores (2013)
Cuadro 23. Requerimiento
Funcional 003
ID
Requerimiento
|
003
|
Nombre
Requerimiento
|
Inscripción
de un alumno
|
Identificación
Requerimiento
|
Requerimiento
Funcional De Usuario
|
Características
|
Inscribir
alumno
|
Descripción
Requerimiento
|
Inscribir
alumno en un determinado curso y sección
|
Prioridad
Requerimiento
|
Alta Media Alta Media
Media Baja Baja |
Fuente:
Los Autores (2013)
ID
Requerimiento
|
004
|
Nombre
Requerimiento
|
Actualización
de Recursos
|
Identificación
Requerimiento
|
Requerimiento
Funcional De Usuario
|
Características
|
Registrar,
modificar, eliminar datos personales del alumno
Registrar,
modificar, eliminar datos personales del representante
Registrar,
modificar, eliminar datos personales del profesor
Registrar,
modificar, eliminar usuarios
|
Descripción
Requerimiento
|
Actualización
de recursos de los alumnos, representantes, profesores y usuarios
involucrados
|
Prioridad
Requerimiento
|
 Alta Media Alta Media Media Baja Baja |
Fuente:
Los Autores (2013)
ID
Requerimiento
|
005
|
Nombre
Requerimiento
|
Reinscripción
de un alumno
|
Identificación
Requerimiento
|
Requerimiento
Funcional De Negocio
|
Características
|
Reinscribir
alumno
|
Descripción
Requerimiento
|
Reinscribir
alumno de acuerdo a los criterios académicos
|
Prioridad
Requerimiento
|
Alta Media Alta Media
Media Baja Baja |
Cuadro 25. Requerimiento
Funcional 005
Fuente:
Los Autores (2013)
Cuadro 26. Requerimiento
Funcional 006
ID
Requerimiento
|
006
|
Nombre
Requerimiento
|
Emitir
reportes de datos personales
|
Identificación
Requerimiento
|
Requerimiento
Funcional De Usuario
|
Características
|
Emitir
reporte de datos personales del alumno
Emitir
reporte de datos personales del representante
Emitir
reporte de datos personales del profesor
|
Descripción
Requerimiento
|
Emisión
de reporte con los datos personales de los alumnos, representantes y
profesores involucrados
|
Prioridad
Requerimiento
|
 Alta Media Alta Media Media Baja Baja |
Fuente:
Los Autores (2013)
ID
Requerimiento
|
008
|
Nombre
Requerimiento
|
Registro
de materias
|
Identificación
Requerimiento
|
Requerimiento
Funcional De Usuario
|
Características
|
Registrar
materias
|
Descripción
Requerimiento
|
Registro
de cada materia impartida en la institución
|
Prioridad
Requerimiento
|
Alta Media Alta Media
Media Baja Baja |
Fuente:
Los Autores (2013)
ID
Requerimiento
|
009
|
Nombre
Requerimiento
|
Registrar
secciones
|
Identificación
Requerimiento
|
Requerimiento
Funcional De Usuario
|
Características
|
Registrar
secciones
|
Descripción
Requerimiento
|
Registro
de secciones según las existentes en cada curso
|
Prioridad
Requerimiento
|
Alta Media Alta Media
Media Baja Baja |
Fuente:
Los Autores (2013)
Cuadro 30. Requerimiento
Funcional 010
ID Requerimiento
|
011
|
Nombre Requerimiento
|
Emitir reporte de notas
|
Identificación Requerimiento
|
Requerimiento Funcional De Usuario
|
Características
|
Emisión de reporte de notas anual
Emisión de reporte de notas globales
|
Descripción Requerimiento
|
Emisión anual y global de las notas del alumno
|
Prioridad Requerimiento
| Alta Media Alta Media Media Baja Baja |
Fuente:
Los Autores (2013)
Cuadro 32. Requerimiento
Funcional 012
ID
Requerimiento
|
012
|
Nombre
Requerimiento
|
Respaldar
la data periódicamente
|
Identificación
Requerimiento
|
Requerimiento
Funcional De Sistema
|
Características
|
Respaldo
periódico de la data ingresada en sistema
|
Descripción
Requerimiento
|
Respaldo
automático y periódico de toda la data
|
Prioridad
Requerimiento
|
Alta Media Alta Media
Media Baja Baja |
Fuente:
Los Autores (2013)
Cuadro 33. Requerimiento
No Funcional 001B
ID
Requerimiento
|
001B
|
Nombre
Requerimiento
|
Tomar
el Estándar 9126
|
Identificación
Requerimiento
|
Requerimiento
No Funcional De Restricción
|
Características
|
Funcionalidad
Usabilidad
Fiabilidad
Eficiencia
Mantenibilidad
Portabilidad
|
Descripción
Requerimiento
|
Tratar
de contar en lo posible con los atributos antes mencionados
|
Prioridad
Requerimiento
|
 Alta Media Alta Media Media Baja Baja |
Fuente:
Los Autores (2013)
Cuadro 34. Requerimiento
No Funcional 002B
ID
Requerimiento
|
002B
|
Nombre
Requerimiento
|
Debe
contar alta escala de confiabilidad superior al 80%
|
Identificación
Requerimiento
|
Requerimiento
No Funcional De Atributos de Calidad
|
Características
|
Disminución
de la carga de trabajo
Desincorporación
paulatina de procesos manuales
|
Descripción
Requerimiento
|
Disminución
del volumen de trabajo manual
|
Prioridad
Requerimiento
|
Alta Media Alta Media
Media Baja Baja |
Fuente:
Los Autores (2013)
Cuadro 35. Requerimiento
No Funcional 003B
ID
Requerimiento
|
003B
|
Nombre
Requerimiento
|
Garantizar
acceso solo a personal autorizado
|
Identificación
Requerimiento
|
Requerimiento
No Funcional De Atributos de Calidad
|
Características
|
Dar
acceso solo a personal autorizado
Restringir
módulos y ventanas según los privilegios establecidos
|
Descripción
Requerimiento
|
Garantizar
el acceso solo a usuarios registrados y establecer permisos según el tipo de
usuario
|
Prioridad
Requerimiento
|
Alta Media Alta Media Media
Baja Baja |
Fuente:
Los Autores (2013)
ID
Requerimiento
|
004B
|
Nombre
Requerimiento
|
Realizado
bajo un entorno Web
|
Identificación
Requerimiento
|
Requerimiento
No Funcional De Interfaz
|
Características
|
Trabajo
bajo ambiente Web
|
Descripción
Requerimiento
|
Trabajar
el sistema bajo un entorno Web
|
Prioridad
Requerimiento
|
Alta Media Alta Media
Media Baja Baja |
Fuente:
Los Autores (2013)
Cuadro 37. Requerimiento
No Funcional 005B
ID
Requerimiento
|
005B
|
Nombre
Requerimiento
|
Cumplimiento
del Decreto 3390
|
Identificación
Requerimiento
|
Requerimiento
No Funcional De Regla de Negocio
|
Características
|
Desarrollo
del sistema bajo estándares libres
|
Descripción
Requerimiento
|
Uso de
herramientas bajo ambiente libre para la formación del sistema
|
Prioridad
Requerimiento
|
Alta Media Alta Media Media Baja Baja |
Fuente:
Los Autores (2013)
Cuadro 38. Requerimiento
No Funcional 006B
ID
Requerimiento
|
006B
|
Nombre
Requerimiento
|
Metodología
RUP
|
Identificación
Requerimiento
|
Requerimiento
No Funcional De regla de Negocio
|
Características
|
Metodología
basada en RUP
|
Descripción
Requerimiento
|
Aplicación
de las metodologías contenidas en RUP
|
Prioridad
Requerimiento
|
Alta Media Alta Media
Media Baja Baja |
Fuente:
Los Autores (2013)
CASOS DE USO DEL SISTEMA
Habiéndose realizado un profundo análisis de los
requerimientos funcionales y no funcionales, basado en las especificaciones y
en las necesidades actuales del Liceo Bolivariano "Miguel Antonio
Caro", a continuación de describe los Casos De Uso que contendrán el
sistema propuesto, así como sus niveles de accesos y responsabilidades o atributos
de cada actor.
Este sistema podrá ser gestionado por 4 tipos de
usuarios, mencionados a continuación:
ü Junta Directiva: Es
la encargada y responsable de gestionar los usuarios que manejarán el sistema
(agregar, modificar, consultar, eliminar), además de gestionar otras áreas
diferentes a los usuarios (especialidades, materias, entre otros). Este es un
usuario tipo "Nivel 1", que posee todas las perisologías y accesos al
sistema. Este tipo de usuario deberá velar por el correcto funcionamiento del
sistema, así como por el buen respaldo y uso de la Base de Datos.
ü Coordinadores: Son
los encargados de supervisar y velar por la carga correcta de los datos en el
sistema, además de corregir datos erróneos cargados por sus supervisados.
Determinará en conjunto con la Junta Directiva que acciones tomar en caso de
alguna falla con el sistema, tales como:
-
Fallas en la conexión.
-
Fallos en el sistema.
-
Problemas con la impresión.
-
Respaldos de las Bases de
Datos
-
Asistencia al Usuario final
ü Docentes: Estos
serán todos los profesores activos de la Institución, los cuales realizarán las
cargas de todas las notas correspondientes a las materias dictadas. Cada
docente deberá dirigirse a la Junta Directiva para hacer solicitud formal de
una cuenta de usuario. Una vez registrado ingresará al sistema con su Nombre de
Usuario y Contraseña.
ü Analistas: Estos
comprenden todo el restante del personal administrativo que requiera el acceso
al sistema para cumplir con sus funciones diarias. Ejemplo: Las secretarias,
las seccionales y los encargados de subir al sistema todos los datos
involucrados en la Gestión Académica. Cada persona deberá poseer un Usuario
único con su respectiva clave de acceso, para monitorear los cambios que
registren en el sistema una vez puedan accesar.
A continuación se muestran los distintos diagramas de
caso de uso en el que se presentan cada uno de los actores y las tareas
requeridas por el Sistema de Gestión Académica para el Liceo Bolivariano “Miguel Antonio
Caro”.
Se identifican inicialmente los actores que van a interactuar
de alguna forma con el sistema obteniendo la siguiente lista:
-
Junta Directiva
-
Coordinadores
-
Docentes
-
Analistas
Una vez identificados a los
distintos usuarios se registran las operaciones que cada uno de ellos debe de
poder realizar al interactuar con el sistema. Así pues se indican las
funcionalidades del sistema desde el punto de vista del usuario del mismo.
- La Junta Directiva es
quien se encarga de:
-
Registrar usuarios (Agregar,
Modificar, Consultar, Eliminar).
-
Registrar los datos de
alumnos, representantes, docentes (Agregar, Modificar, Consultar, Eliminar).
-
Registrar materias (Agregar,
Modificar, Consultar, Eliminar).
-
Registrar especialidades
(Agregar, Modificar, Consultar, Eliminar).
-
Registrar cursos (Agregar,
Modificar, Consultar, Eliminar).
-
Registrar secciones
(Agregar, Modificar, Consultar, Eliminar).
-
Registrar inscripciones
(Agregar, Modificar, Consultar, Eliminar).
-
Emitir reportes
-
Emitir constancias.
-
Preservar integridad física,
programática y funcional del servidor donde se ubica el sistema.
- Los Coordinadores son
los encargados de:
-
Registrar los datos de
alumnos, representantes, docentes (Agregar, Modificar, Consultar, Eliminar).
-
Registrar materias (Agregar,
Modificar, Consultar, Eliminar).
-
Registrar especialidades (Agregar,
Modificar, Consultar, Eliminar).
-
Registrar cursos (Agregar, Modificar,
Consultar, Eliminar).
-
Registrar secciones (Agregar,
Modificar, Consultar, Eliminar).
-
Registrar inscripciones (Agregar,
Modificar, Consultar, Eliminar).
-
Emitir reportes
-
Emitir constancias.
- Los Docentes son los
que podrán:
-
Registrar calificaciones (Agregar,
Modificar, Consultar, Eliminar).
- Los Analistas se
encargarán de:
-
Registrar los datos de
alumnos, representantes, docentes (Agregar, Modificar, Consultar).
-
Registrar inscripciones
(Agregar, Modificar, Consultar).
-
Emitir constancias
Cada una de estas actividades están representadas como un caso de uso relacionado y asociado con el actor que tiene que determinarla.
ARQUITECTURA DEL SISTEMA
El Patrón MVC por sus
siglas en ingles Model View Controller
que significa Modelo Vista Controlador,
es una arquitectura de Software que
define la separación de los datos que conforman la vista de la lógica de una
aplicación.
Este
paradigma, en resumen se trata de separar la programación en tres partes:
- Modelo:
Aquí se programan todo aquello relacionado con las bases de datos, es
decir, las entradas y salidas de datos y se devuelven como se necesiten
desde el programa principal. Siendo imaginativos sería como acceder a los
datos de algo a través de un API y el API sería el modelo.
- Vista:
Aquí se programa la parte visual del software, o lo que es lo mismo, la
parte que usa el usuario. En el caso de un sitio web la parte de HTML, CSS
y JavaScript normalmente.
- Controlador: Es
la lógica del programa. Aquella que le pide al modelo los datos y los
muestra en la vista. Vamos, lo que viene a ser el núcleo.
Este modelo facilita algunas partes de la
programación para hacerlas más, mucho más, ágiles, como que al tener separado
el código en diferentes capas, cuando se hacen modificaciones sobre la
plantilla (por ejemplo) solo hay que tocar esta parte que tiene un tipo de
código más homogéneo y el resto no hace falta tocarlo para que funcione bien.
Ventajas / Justificación
Una
separación total entre lógica de negocio y presentación. A esto se le pueden
aplicar opciones como el multilenguaje, distintos diseños de presentación, etc.
sin alterar la lógica de negocio. La separación de capas como presentación,
lógica de negocio, acceso a datos es fundamental para el desarrollo de
arquitecturas consistentes, reutilizables y más fácilmente mantenibles, lo que
al final resulta en un ahorro de tiempo en desarrollo en posteriores proyectos.
Al existir la separación de vistas, controladores y modelos es más sencillo
realizar labores de mejora como:
ü Agregar
nuevas vistas.
ü Agregar
nuevas formas de recolectar las órdenes del usuario (interpretar sus modelos
mentales).
ü Modificar
los objetos de negocios bien sea para mejorar el performance o para migrar a
otra tecnología.
ü Las
labores de mantenimiento también se simplifican y se reduce el tiempo necesario
para ellas. Las correcciones solo se deben hacer en un solo lugar y no en
varios como sucedería si tuviésemos una mezcla de presentación e implementación
de la lógica del negocio.
ü Las
vistas también son susceptibles de modificación sin necesidad de provocar que
todo el sistema se paralice. Adicionalmente el patrón MVC propende a la
especialización de cada rol del equipo, por tanto en cada liberación de una nueva
versión se verán los resultados.
Cuadro 39. Tabla Alumnos
Columna
|
Tipo
|
Nulo
|
Predeterminado
|
Enlaces a
|
id_alumno
|
int(5)
|
No
|
||
cedula_alumno
|
varchar(10)
|
No
|
||
ruta_cedula
|
varchar(100)
|
Sí
|
NULL
|
|
ruta_foto
|
varchar(100)
|
Sí
|
NULL
|
|
apellidos
|
varchar(50)
|
No
|
||
nombres
|
varchar(50)
|
No
|
||
cod_sexo
|
varchar(1)
|
No
|
||
fecha_nac
|
date
|
No
|
||
cod_lugar_nac
|
varchar(5)
|
No
|
lugar_nacimiento
-> cod_lugar_nac
|
|
direccion
|
varchar(100)
|
No
|
||
telf_hab
|
varchar(10)
|
No
|
||
telf_celular
|
varchar(10)
|
No
|
||
email
|
varchar(50)
|
No
|
Fuente:
Los Autores (2013)
Cuadro 40. Tabla Aulas
Columna
|
Tipo
|
Nulo
|
Predeterminado
|
id_aula
|
int(11)
|
No
|
|
cod_aula
|
int(2)
|
No
|
|
ubicacion
|
varchar(40)
|
No
|
|
estado
|
varchar(15)
|
No
|
Fuente:
Los Autores (2013)
Cuadro 41. Tabla Cursos
Columna
|
Tipo
|
Nulo
|
Predeterminado
|
id_curso
|
int(11)
|
No
|
|
cod_curso
|
varchar(10)
|
No
|
|
descripcion
|
varchar(30)
|
No
|
Fuente:
Los Autores (2013)
Cuadro 42. Tabla Departamentos
Columna
|
Tipo
|
Nulo
|
Predeterminado
|
id_departamento
|
int(11)
|
No
|
|
cod_departamento
|
varchar(5)
|
No
|
|
descripcion
|
varchar(50)
|
No
|
Fuente:
Los Autores (2013)
Columna
|
Tipo
|
Nulo
|
Predeterminado
|
Enlaces a
|
id_inscripcion
|
int(11)
|
No
|
||
cod_inscripcion
|
varchar(30)
|
No
|
||
cedula_alumno
|
varchar(15)
|
No
|
alumnos
-> cedula_alumno
|
|
cedula_representante
|
varchar(15)
|
No
|
representantes
-> cedula_representante
|
|
cod_parentesco
|
varchar(5)
|
No
|
parentesco
-> cod_parentesco
|
|
ruta_autorizacion
|
varchar(100)
|
Sí
|
NULL
|
|
cod_curso
|
varchar(10)
|
No
|
cursos
-> cod_curso
|
|
cod_seccion_x_curso
|
varchar(10)
|
No
|
secciones_x_curso
-> cod_seccion_x_curso
|
|
cod_periodo_academico
|
varchar(15)
|
No
|
periodos_academicos
-> cod_periodo_academico
|
|
cod_usuario
|
varchar(15)
|
No
|
usuarios
-> cod_usuario
|
Fuente:
Los Autores (2013)
Cuadro 44. Tabla Lugar_nacimiento
Columna
|
Tipo
|
Nulo
|
Predeterminado
|
id_lugar_nac
|
int(11)
|
No
|
|
cod_lugar_nac
|
varchar(10)
|
No
|
|
descripcion
|
varchar(30)
|
No
|
Fuente:
Los Autores (2013)
Cuadro 45. Tabla Materias
Columna
|
Tipo
|
Nulo
|
Predeterminado
|
Enlaces a
|
id_materia
|
int(11)
|
No
|
||
cod_materia
|
varchar(10)
|
No
|
||
descripcion
|
varchar(30)
|
No
|
||
cod_curso
|
varchar(10)
|
No
|
cursos
-> cod_curso
|
|
Fuente:
Los Autores (2013)
Cuadro 46. Tabla Materias_arrastre_x_insc
Columna
|
Tipo
|
Nulo
|
Predeterminado
|
Enlaces a
|
id_mat_a_x_alum
|
int(11)
|
No
|
||
cod_mat_a_x_insc
|
varchar(30)
|
No
|
||
cod_materia
|
varchar(10)
|
No
|
materias
-> cod_materia
|
|
cod_inscripcion
|
varchar(30)
|
No
|
inscripciones
-> cod_inscripcion
|
Fuente:
Los Autores (2013)
Cuadro 47. Tabla Materias_x_profesor
Columna
|
Tipo
|
Nulo
|
Predeterminado
|
Enlaces a
|
id_mat_x_prof
|
int(5)
|
No
|
||
cod_mat_x_prof
|
varchar(20)
|
No
|
||
cod_materia
|
varchar(10)
|
No
|
materias
-> cod_materia
|
|
cedula_profesor
|
varchar(10)
|
No
|
profesores
-> cedula_profesor
|
Fuente:
Los Autores (2013)
Cuadro 48. Tabla Notas_x_inscripcion
Columna
|
Tipo
|
Nulo
|
Predeterminado
|
Enlaces a
|
id_nota_x_i
|
int(11)
|
No
|
||
cod_nota_x_inscripcion
|
varchar(30)
|
No
|
||
nota
|
int(2)
|
No
|
||
cod_inscripcion
|
varchar(30)
|
No
|
inscripciones
-> cod_inscripcion
|
|
cod_mat_x_prof
|
varchar(20)
|
No
|
materias_x_profesor
-> cod_mat_x_prof
|
Fuente:
Los Autores (2013)
Cuadro 49. Tabla Parentesco
Columna
|
Tipo
|
Nulo
|
Predeterminado
|
id_parentesco
|
int(11)
|
No
|
|
cod_parentesco
|
varchar(5)
|
No
|
|
descripcion
|
varchar(30)
|
No
|
Fuente:
Los Autores (2013)
Cuadro 50. Tabla Periodos_academicos
Columna
|
Tipo
|
Nulo
|
Predeterminado
|
id_periodo_academia
|
int(11)
|
No
|
|
cod_periodo_academico
|
varchar(10)
|
No
|
Fuente:
Los Autores (2013)
Columna
|
Tipo
|
Nulo
|
Predeterminado
|
id_pregunta
|
int(11)
|
No
|
|
cod_pregunta
|
varchar(5)
|
No
|
|
descripcion
|
varchar(40)
|
No
|
Fuente:
Los Autores (2013)
Cuadro 52. Tabla Profesores
Columna
|
Tipo
|
Nulo
|
Predeterminado
|
Enlaces a
|
id_profesor
|
int(5)
|
No
|
||
cedula_profesor
|
varchar(10)
|
No
|
||
ruta_cedula
|
varchar(100)
|
Sí
|
NULL
|
|
ruta_foto
|
varchar(100)
|
Sí
|
NULL
|
|
apellidos
|
varchar(50)
|
No
|
||
nombres
|
varchar(50)
|
No
|
||
cod_sexo
|
varchar(1)
|
No
|
||
fecha_nac
|
date
|
No
|
||
cod_lugar_nac
|
varchar(5)
|
No
|
lugar_nacimiento
-> cod_lugar_nac
|
|
direccion
|
varchar(100)
|
No
|
||
telf_hab
|
varchar(10)
|
No
|
||
telf_celular
|
varchar(10)
|
No
|
||
email
|
varchar(50)
|
No
|
Fuente:
Los Autores (2013)
Columna
|
Tipo
|
Nulo
|
Predeterminado
|
Enlaces a
|
id_representante
|
int(5)
|
No
|
||
cedula_representante
|
varchar(10)
|
No
|
||
ruta_cedula
|
varchar(100)
|
Sí
|
NULL
|
|
ruta_foto
|
varchar(100)
|
Sí
|
NULL
|
|
apellidos
|
varchar(50)
|
No
|
||
nombres
|
varchar(50)
|
No
|
||
cod_sexo
|
varchar(1)
|
No
|
||
fecha_nac
|
date
|
No
|
||
cod_lugar_nac
|
varchar(5)
|
No
|
lugar_nacimiento
-> cod_lugar_nac
|
|
direccion
|
varchar(100)
|
No
|
||
telf_hab
|
varchar(10)
|
No
|
||
telf_celular
|
varchar(15)
|
No
|
||
telf_trabajo
|
varchar(10)
|
No
|
||
email
|
varchar(50)
|
No
|
Fuente:
Los Autores (2013)
Cuadro 54. Tabla Secciones_x_curso
Columna
|
Tipo
|
Nulo
|
Predeterminado
|
Enlaces a
|
id_seccion_x_curso
|
int(11)
|
No
|
||
cod_seccion_x_curso
|
varchar(10)
|
No
|
||
descripcion
|
varchar(10)
|
No
|
||
cod_curso
|
varchar(10)
|
No
|
cursos
-> cod_curso
|
Fuente:
Los Autores (2013)
Cuadro 55. Tabla Tipo_usuarios
Columna
|
Tipo
|
Nulo
|
Predeterminado
|
id_tipo_usuario
|
int(11)
|
No
|
|
cod_tipo_usuario
|
varchar(5)
|
No
|
|
descripcion
|
varchar(20)
|
No
|
Fuente:
Los Autores (2013)
Cuadro 56. Tabla Turnos
Columna
|
Tipo
|
Nulo
|
Predeterminado
|
id_turno
|
int(11)
|
No
|
|
cod_turno
|
varchar(1)
|
No
|
|
descripcion
|
varchar(20)
|
No
|
Fuente:
Los Autores (2013)
Cuadro 57. Tabla Usuarios
Columna
|
Tipo
|
Nulo
|
Predeterminado
|
Enlaces a
|
id_usuario
|
int(11)
|
No
|
||
cod_usuario
|
varchar(15)
|
No
|
||
apellidos
|
varchar(50)
|
No
|
||
nombres
|
varchar(50)
|
No
|
||
cod_sexo
|
varchar(1)
|
No
|
||
fecha_nac
|
date
|
No
|
||
cod_lugar_nac
|
varchar(5)
|
No
|
lugar_nacimiento
-> cod_lugar_nac
|
|
direccion
|
varchar(100)
|
No
|
||
telf_hab
|
varchar(10)
|
No
|
||
telf_celular
|
varchar(10)
|
No
|
||
email
|
varchar(50)
|
No
|
||
cod_departamento
|
varchar(5)
|
No
|
departamentos
-> cod_departamento
|
|
cargo
|
varchar(30)
|
No
|
||
cod_tipo_usuario
|
varchar(2)
|
No
|
tipo_usuarios
-> cod_tipo_usuario
|
|
password
|
varchar(20)
|
No
|
||
cod_pre1
|
varchar(10)
|
No
|
preguntas_secretas
-> cod_pregunta
|
|
respuesta_pre1
|
varchar(20)
|
No
|
||
cod_pre2
|
varchar(10)
|
No
|
preguntas_secretas
-> cod_pregunta
|
|
respuesta_pre2
|
varchar(20)
|
No
|
Fuente:
Los Autores (2013)
No hay comentarios:
Publicar un comentario