Documentacion SI PAB Perfil de Informe

UNIVERSIDAD AUTONOMA GABRIEL RENE MORENO
FACULTAD DE TECNOLOGIA
ING. INFORMATICA
SISTEMA DE INFORMACIN PARA GESTIONAR SELECCIN DE

PROFESORES Y CREACIN DE GRUPOS Y HORARIOS EN EL REA
ACADMICA DEL DEPARTAMENTO DE PROGRAMA DE ADMISIN BSICA
(P.A.B.) DE LA UNIVERSIDAD AUTNOMA GABRIEL REN MORENO
MATERIA: SISTEMAS DE INFORMACION I
GRUPO: 16
DOCENTE: ING. ANGLICA GARZN CUELLAR
ALUMNOS:
SANDRA AEZ VACA
200754335
RODNEY CESPEDES ESPINOZA
200707256
MARIELA GONZALES SEGOVIA
200753533
FECHA: 04/ 12 / 09
SANTA CRUZ - BOLIVIA
ndice
1. Perfil.................................................................................................................4
1.1. Introduccin .....................................................................................................
1.2. Objetivos........................................................................................................
1.2.1. Objetivo general.....................................................................................
1.2.2. Objetivos especficos............................................................................
1.3. Antecedentes ...................................................................................................
1.4. Estructura Organizacional.............................................................................
1.5. Problemtica...................................................................................................
1.5.1. Descripcin del problema...................................................................
1.5.2. Formulacin del problema..................................................................
1.6. Alcance............................................................................................................
1.6.1. Requerimientos Funcionales..............................................................
1.6.2. Requerimientos No Funcionales....................................................
1.7. Entrevistas......................................................................................................
1.8. Elementos del Sistema..................................................................................
1.9. Metodologa Ishikawa....................................................................................
1.9.1. Identificar el Problema.......................................................................
1.9.2. Identificar Principales Categoras.....................................................
1.9.3. Identificar Causas...............................................................................
1.9.4. Anlisis y Conclusin.........................................................................
2. Marco Terico........................................................................................................
2.1. Lenguaje Unificado de Modelado-UML........................................................
2.1.1. Vocabulario de UML.............................................................................
2.1.2. Aspecto Esttico y Dinmicos...........................................................
2.1.3. Diagrama de Clases.............................................................................
2.1.4. Diagrama de Casos de Uso................................................................
2.1.5. Diagrama de Objetos...........................................................................
2.1.6. Diagrama de Componentes................................................................
3
2.1.7. Diagrama de Distribucin...................................................................

2.1.8. Diagrama de Actividades....................................................................
2.1.9. Diagrama de Estados..........................................................................
2.1.10. Diagrama de Colaboracin...............................................................
2.1.11. Diagrama de Secuencia.....................................................................
2.2. Proceso Unificado de Desarrollo de Software-P.U.D.S. ............................
2.2.1. Fases.....................................................................................................
2.2.2. Flujo de Trabajo...................................................................................
2.2.3. Caractersticas del Modelo................................................................
2.2.4. Las Cuatro Ps......................................................................................
2.2.5. Flujo de Trabajo (Requisitos y Anlisis) ...........................................
3. Modelo de Diseo...................................................................................................
3.1. Identificar Clases...........................................................................................
3.2. Identificar Conexin de Instancia................................................................
3.3 Diagrama de Dominio....................................................................................
3.4. Construccin de la Base de Datos...............................................................
3.4.1. Diseo Lgico......................................................................................
3.4.1.1. Diagrama de Clases.......................................................................
3.4.1.2 Mapeo...............................................................................................
3.4.2. Diseo Fsico........................................................................................
3.4.2.1. Tabla de volumen...........................................................................
3.4.2.2. Script...............................................................................................
3.4.2.3. Diagrama Relacional...................................................................
3.5. Manipulacin de Tuplas..............................................................................
3.6. Consultas......................................................................................................
3.7. Procedimientos Almacenados....................................................................
4. Anlisis y Diseo de Sistema..............................................................................
4.1. Modelo de Negocio......................................................................................
4.1.1. Diagrama de Actividad......................................................................
4.1.1.1. Seleccin de Profesor.................................................................
4.1.1.2. Verificacin de Aulas Disponibles.............................................
4
4.1.1.3. Programacin de Horarios..........................................................

4.1.2. Diagramas de Caso de Uso..............................................................
4.1.2.1. Identificar Casos de Uso y Actores...........................................
4.1.2.2. Priorizacin de Casos de Uso....................................................
4.1.2.3. Detallar Casos de Uso.................................................................
4.1.2.3.1. Disear Caso de Uso.............................................................
4.1.2.3.2. Prototipar Caso de Uso.........................................................
4.1.2.3.3. Detalle Caso de Uso..............................................................
4.1.2.4. Diagrama General de Caso de Uso............................................
5. Anlisis de la Arquitectura...................................................................................
5.1. Identificar Paquetes.....................................................................................
5.2. Vista de Paquetes........................................................................................
5.3. Vista de Escenario.......................................................................................
5.4. Implementacin............................................................................................
5.5. Diagrama de Componentes........................................................................
5.6. Implementacin de Arquitectura de Paquetes..........................................
6. Plataforma de Desarrollo.....................................................................................
6.1. Sistema Operativo........................................................................................
6.2. Base de Datos...............................................................................................
6.3. Lenguaje de Programacin..........................................................................
7. Conclusin.............................................................................................................
8. Recomendacin....................................................................................................
9. Bibliografa............................................................................................................
10. Anexos.................................................................................................................
1. Perfil
5
1.1. Introduccin
La U.A.G.R.M. como una poltica de ingreso de postulantes bachilleres,
de acuerdo a Resolucin I.C.U. 09/90, la 21(B)/91, la 084/93 y la 041/03
implant la creacin y funcionamiento del Programa de Admisin Bsica
(P.A.B.) como un eficaz mecanismo pedaggico de evaluacin y
actualizacin de conocimientos, para un adecuado inicio del proceso de
profesionalizacin.
Es de conocimiento pblico que el P.A.B. curso organizado por la
UAGRM, es una actividad acadmica seria y planificada que busca
alcanzar niveles adecuados de preparacin para el postulante a la
UAGRM y que a travs de los aos se ha mejorado, alcanzando un nivel
de madurez y seriedad. Con apoyo del equipo de COORDINADORES
designados por la UAGRM quienes planifican y apoyan toda la actividad
acadmica, en dicho PAB se apoya a los postulantes con:
-
Clases de repaso y actualizacin.
Textos elaborados y publicados por la UAGRM.
Banco de preguntas.
Prcticos y clases de apoyo.
El P.A.B. se constituye en un instrumento que permite preparar al

estudiante convenientemente con la finalidad de encarar con xito su
formacin profesional.
Para el logro de todos sus objetivos el departamento del P.A.B. se
encarga de la seleccin de profesores calificados que estn dirigidos por
un coordinador en cada rea, adems existe un encargado acadmico el
cual programa los grupos y horarios; que se ofertan a los postulantes del
P.A.B.
6
Toda la informacin que el departamento necesita es registrada en libros

y en planillas hechas en Excel, lo que ha llevado, en varias ocasiones, a
prdidas y errores en los datos que se manejan. Tambin ocasiona
perdidas de tiempo y mucho papeleo al momento de querer sacar
informes.
Debido a esto el departamento del P.A.B, ha optado por automatizar el
control de la informacin que necesita para cumplir con sus objetivos.
1.2. Objetivos
1.2.1.
Objetivo General
Desarrollar un Sistema de Informacin para Gestionar seleccin de

profesores y creacin de grupos y horarios en el rea acadmica del
Departamento de Programa de Admisin Bsica (P.A.B.) de la
Universidad Autnoma Gabriel Ren Moreno.
1.2.2. Objetivos Especficos

Recolectar informacin del funcionamiento del Departamento
mediante diferentes entrevistas y cuestionarios realizados a los
funcionarios del departamento del P.A.B.
Realizar la asignacin de profesores a los grupos ya programados
de acuerdo a su especialidad o formacin acadmica tomando en
cuenta los horarios de los grupos.
Crear distintas vistas y acceso de informacin para los diferentes
usuarios.
Almacenar informacin actualizada de los profesores que estn
trabajando en esa gestin.
Realizar la programacin de aulas para el da de la prueba.
Controlar la creacin de grupos y horarios de acuerdo a los cupos
y aulas que se disponen.
Desarrollar la programacin de los grupos por turno, intercalando
materias fuertes con materias dbiles, es ms las materias fuertes
irn despus de una dbil.
8
Utilizaremos herramientas de programacin VISUAL BASIC.
1.3. Antecedentes
Las polticas de Admisin de nuevos estudiantes en la Universidad

Boliviana
fueron
aprobadas
en
el
VII
Congreso
Nacional
de
Universidades, realizado en la ciudad de Potos, y homologadas en la

Universidad Autnoma Gabriel Ren Moreno mediante Resolucin del
Ilustre Consejo Universitario N084/93, del 09 de diciembre de 1993,
donde se contempla claramente dos modalidades de ingreso para los
bachilleres que deseen continuar sus estudios para adquirir una
profesin.
Primera Modalidad.- Consiste en el ingreso en el primer semestre de
cada gestin acadmica,
Suficiencia
a travs del examen de la Prueba de
Acadmica (P.S.A.) que se realizan todos los aos
equivalentes al 50% y el otro 50% corresponde a las notas adquiridas por

el estudiante durante los ltimos tres aos de nivel secundario.
Segunda Modalidad.- Es el Programa de Admisin Bsica (P.A.B.), que
consiste en el ingreso de los estudiantes a travs de un curso de
capacitacin, preparacin y actualizacin de conocimientos orientado a la
carrera a la cual postulo. Los estudiantes que aprueban este curso,
pueden realizar su inscripcin en la carrera elegida en el segundo periodo
de la gestin acadmica, estos estudiantes ocuparan las plazas de los
alumnos que pasaron al segundo semestre.
A las dos modalidades de ingreso ya nombradas, se ha sumado una
tercera: que consiste en el ingreso directo a la U.A.G.R.M. de el mejor
bachiller de todos los colegios del departamento de Santa Cruz, luego el
ICU fue incrementando esta cantidad a 2 despus a 5 y actualmente es
de 10 estudiantes por colegio
del Departamento de Santa Cruz,
entendiendo por mejores bachilleres a los estudiantes que hayan obtenido

el mayor promedio acumulado en los ltimos 3 aos del ciclo secundario
10
con una nota mayor o igual 55/70 puntos como indica en la Resolucin I.
C. U. 005/97, del 20 de febrero de 1997.
Hace 14 aos que la U.A.G.R.M. aplica las modalidades de P.S.A. al inicio
de cada ao acadmico y P.A.B. para el segundo semestre de cada ao
acadmico.
A partir del ao 2006, basados el la Resolucin I.C.U. 05/2006 artculo #
40, y su respectiva reglamentacin, faculta a la Unidad del PAB/PSA.
Como la nica autorizada a organizar cursos de Nivelacin o Preparacin
para los bachilleres que postularn a la P.S.A. dentro de la UAGRM.
Actividad que antes de la resolucin (cursos de nivelacin) era
desarrollada por INSTITUTOS privados y algunos Centros Internos con
fines de lucro.
Sin embargo esta actividad acadmica nunca fue organizada con la
seriedad, planificacin, transparencia y calidad que el caso requiere,
convirtindose, en algunos casos, en un atractivo negocio de extorsin y
estafa a los postulantes a la UAGRM.
El Programa de Admisin Bsica (P.A.B.), es una de las modalidades de
ingreso a la Universidad Autnoma Gabriel Rene Moreno, que consiste
en un curso pre-universitario y tiene por objetivo actualizar, reforzar y
nivelar a los postulantes sobre los conocimientos recibidos en la
enseanza del nivel secundario. Los alumnos que aprueben este curso,
pueden realizar su inscripcin a la carrera elegida en la siguiente gestin
acadmica que se inicia.
El departamento del P.A.B. se encuentra localizado en el campus
universitario de la Universidad Autnoma Gabriel Rene Moreno, entre
las calles Mxico y Centenario, de la ciudad de Santa Cruz de la Sierra,
mas especifico en el pabelln 145; Telfono 3365544 int. 2606, Telfono
11
Fax 3340106, Casilla de correo N 702, E-mail pab@uagrm.edu.bo, Web

http://pab.uagrm.info/.
Presta atencin en horarios de oficina de lunes a viernes.
12
1.4. Estructura Organizacional
ESTRUCTURA ORGNICA DEL DEPARTAMENTO PAB/PSA - UAGRM

CONVENCIONES:
LNEA DE AUTORIDAD
LNEA DE ASESORA
JEFE DEL DPTO.

PAB/PSA
MBA. Helecto Villarroel
DOCENTES
COORDINADORE
SECRETARIA
Univ. Diana
Bejarano
Administrativo III
INFORMACIONES
Univ. Elizabeth
Rojas
ENCARGADO
PROYECTOS & TIC
Ing. Patricia Raimondi
Tcnico Medio III
APOYO DE
PROYECTOS
Univ. Ral Rodrguez
ENCARGADO ADMINISTRATIVO
Y FINANCIERO
Ing. Co. Rodolfo Bustillos
Contratado Plazo Fijo
ENCARGADO
ACADMICO
Lic. Rosario Santos
Tcnico Medio III
APOYO ACADMICO
I
Univ. Moira Arce
APOYO ACADMICO
II
Univ. Yobany Rivero
13
ASISTENTE FINANCIERO
Lic. Darwin Vlez Soria
Tcnico Medio III
ENCARGADO DE
COMUNICACIN Y
LOGSTICA
Lic. Rafael Sosa
APOYO COMUNICATIVO
Univ. Patricia Montero
Administrativo III
1.5. Problemtica
1.5.1. Descripcin del Problema
Registran la documentacin manualmente y en un libro.

Cuando necesitan algn dato de un docente deben revisar los archivos.
Utilizan Microsoft Excel para gestionar todo tipo de informacin que manejan,
primeramente registrado en distintos cuadernos.
Al momento de la creacin de grupos y horarios hay cruces de aulas, porque no

cuentan con una base de datos que les de informes de aquellas aulas que estn
habilitadas para pasar clases.
La seleccin de profesores no es adecuada, ya que muchas veces hay profesores

que dictan materias que no corresponden a su rea.
Necesitan un sistema que pondere a cada profesor que presenta su hoja de vida de
acuerdo a su conocimiento para ser seleccionado.
No cuentan con un registro de profesores pre-seleccionados en el caso de que algn

profesor que por fuerza mayor no pueda dictar sus clases, habiendo sido ya
contratado.
El departamento contrata a cierto personal, que se encarga del control de asistencia

de los profesores, esto lo hacen de manera manual.
En el caso de las provincias, existe un encargado que necesariamente tiene que venir
al departamento central para la seleccin de los profesores.
En el momento de que ingresa algn documento en el departamento no hay una

constante que apoye esto.
Los contratos para los profesores tienen un mismo formato y se necesita un sistema
que pueda generarlo cuando el profesor ya fue seleccionado, y no como en la
actualidad lo hacen uno por uno manualmente.
El departamento no tiene conocimiento de la cantidad de alumnos que ingresaron al

P.A.B., este debe pedir informes al C.P.D.
14
Para la toma de exmenes el P.A.B. requiere a dos docentes de planta registrados y

en vigencia que tomaran la prueba, algunos hacen caso omiso a la invitacin y es por
ello que hay grupos que no tienen docentes ese da; el departamento no cuenta con
una cifra exacta de dichos docentes.
No todos los profesores y los docentes que se encargan de la toma de pruebas

cuentan con credenciales que los identifiquen como tales, siendo este un requisito
para el ingreso a la universidad.
Deficiencia en la recoleccin y manejo de archivos.

Cuentan con un sistema de archivos que no cumple con sus requerimientos.
Falta comunicacin con los profesores.
A veces las boletas de los alumnos inscritos salen sin grupos o materias incompletas.
No cuentan con un sistema contable ni de inventario.
En el momento de la inscripcin no entregan los textos y a veces no hay suficientes
para todos, tanto as que hay alumnos que dan examen sin tener el material, a
aquellos que entregan los listan con nombre y cedula de identidad en hojas y
manualmente.
Han sufrido en varias ocasiones perdida de informacin y de archivos por falta de

orden.
A veces se necesita ubicar a los profesores con urgencia, pero no se lo puede realizar
debido a que no se cuenta con datos actualizados de ellos.
La manipulacin de la informacin que tiene cada docente registrada en las tablas de

Excel, cuenta con fcil acceso, esto ocasiona que cualquier funcionario pueda
modificar dicha informacin.
15
1.5.2. Formulacin del Problema

El problema se refleja en el manejo manual de la seleccin de profesores y la
creacin de grupos y horarios, entonces viendo estas deficiencias el factor ms
importante es poder contar con un sistema que gestionara informacin de los
profesores que dictan materias y de aquellos que pueden llegar a sustituir a algn
profesor, si se lo requiriera adems de contar con datos precisos que ayudaran en
la creacin de horarios; as de esta forma abra mejor organizacin en la
informacin.
16
1.6. Alcance
1.6.1. Requerimientos Funcionales
Rf1.- Gestionar datos o documentos que presentan los profesores: Nombre, carnet de
identidad, solicitud de docencia, hoja de vida, fotocopia del ttulo legalizado, fotocopia
de su NIT.
Rf2.- Controlar las aulas disponibles tanto para las clases regulares como tambin para el
da de los exmenes, mediante reportes.
Rf3.- Realizar Reportes Sencillos para brindar informacin que facilite la gestin de
archivos y as se organicen ms fcilmente
Rf4.- Control De Variedad de Materias en la programacin de grupos, garantizando que no
se crucen materias de la misma rea en un mismo turno del horario que se le d a los
grupos que se programen ej. Lunes Historia, Orientacin Vocacional y Matemticas
Rf5.- Tener una Actualizacin Constante De Datos De Docentes en cada gestin, para as
ampliar la Cantidad de la Base De Datos De Docentes y as tener una referencia
rpida en caso de que algn docente no pueda cumplir por algn motivo y se tenga
que Buscar Reemplazos y estos datos sean actuales.
Rf6.- Controlar la asistencia de los docentes en horarios de Clases.
Rf7.- Asignarle a los docentes Una Materia De acuerdo a la especialidad que tengan, segn
el rea en la que se encuentre Su profesin.
Rf8.- Controlar Las Vistas y Usuarios de manera que no todos tengan acceso a la
modificacin de informacin sin contrasea, pero si a la visualizacin de la
informacin que se requiera
Rf9.- Gestionar la seleccin de docentes de acuerdo a sus conocimientos con una
ponderacin basada en su hoja de vida.
17
1.6.2. Requisitos No Funcionales

Todo el sistema lo realizaremos en el lenguaje VISUAL BASIC .NET
Utilizaremos Como Herramienta el Sistema Gestor de Base de Datos SQL Server.
Para Elaborar Los Diagramas De Clases usaremos la Herramienta Start UML
18
1.7. Entrevistas
Entrevista al los trabajadores del departamento del P.A.B.
Fecha: 28/08/09
1.- Cmo, porque y de quienes nace la iniciativa de crear el departamento del pab?
Entrevistado: RODOLFO BUSTILLOS
Cargo: ENCARGADO ADMINISTRATIVO Y FINANCIERO
Hace 13 aos en1992 cada facultad generaba su ingreso de alumnos y no lo hacan en
forma discrecional a veces tenan alrededor de 500 a 600 alumnos por semestre de ah nace
el pab q es la prueba de admisin bsica que se encarga de normalizar todo eso.
Entrevistado: VIVIANA ROSARIO SANTOS
Cargo: ENCARGADO ACADEMICO
Desde Un inicio y Mediante la resolucin que deca que de acuerdo a la masificacin y
remuneracin de tantos estudiantes hace que aparezca como departamento se cre en 1991
Entrevistado: DARWIN VELEZ SORIA
Cargo: ASISTENTE FINANCIERO
Nace porque la universidad necesita tener un mecanismo que introduzca a todos los
postulantes preuniversitarios de colegio que egresan cada ao
2.- Qu objetivos a largo, mediano o corto plazo tiene?
Todo es a largo plazo porque esto es para que se quede se genero esta unidad mas con la
de orientacin para que quede a largo plazo porque son los que directamente hacen la
generacin de entrada de lo que son los preuniversitarios la gente que sale de formacin
estudiantil
Entrevistado: ROSARIO SANTOS
Su objetivo es hacer pruebas para el ingreso simplemente En objetivos acadmicos hoy en
da ya mucho mas estructurado y especificando bien la metodologa de que tenga un plan
acadmico u enfocar eso en un sistema
19
El objetivo a corto plazo seria Una Base de datos para tener un registro sistematizado,
automatizado digital Que tengamos para que sea de uso presente y futuro
3.- de qu formas invitan o hacen conocer a los docentes la postulacin para dictar
las clases, que medios utilizan para hacerlo
Se le manda a cada facultad actas licitacin para que se genere todo esto ellos son los que
nos mandan sus catedrticos pero dependiendo de cuanto ganen, que no pase de la ley
financial casi la mayora pasa de la ley financial por eso es q no tenemos catedrticos dentro
del pab son pocos los que nos sobresalen, porque son ms los que ganan ms de 7000 Bs.
En realidad cuando inicie aqu trabajando se lanzaba la convocatoria aqu afuera del pab
aqu en la salida se pona un letrero porque los docentes frecuentemente venan d visita no
se lo haca pblica por que los medios que se utilizan simplemente se lanzan en una
convocatoria cerrada.
Actualmente ya no hay convocatoria trabajamos digamos solo con ese grupo de docentes de
los que ya tenemos formados ya que se quedan como docentes de planta
Se invita por medio de una convocatoria, se lo hace pblico mediante el vicerrectorado ya
que este se encarga del departamento del PAB y se comunica a los docentes de sistema
universitario que estn interesados a q manden una carta de solicitud de docencia, luego el
director de la unidad lo evala y luego se lo llama para comunicarle que est habilitado.
4.- Cules son los requisitos que presenta un profesor postulante?
Los Requisitos Son:
-Solicitud de docencia
-Fotocopia carnet de identidad
-Hoja de Vida
-Fotocopia Legalizada Del Ttulo En Provisin Nacional De Su Profesin
-Informe De Actividades
-NIT (si tiene) para hacer su descargo posterior
20
5.- Cmo organiza los documentos que recolectan de los docentes?

Los documentos Se recepcionan aqu y se los ponen en orden y luego se los pasa a
recursos humanos luego pasa al DAF y luego a contabilidad y luego pasa a cheques ya
para cancelar
Se tarda mucho debido a dos motivos ya q es una gran cantidad ya q son alrededor de 300
docentes y el tiempo que toman en venir a dejar documentos es muy retardado ya que esto
atrasa el pago por ejemplo.
6.- Cmo realiza la seleccin de los docentes para dictar las clases de nivelacin?
Cuando iniciamos fuimos a tener una capacitacin en escalafn para poder evaluarlos
porque cuando lanzaron la convocatoria presentaban todos su curriculum y fuimos a sacar
los tems para poder avaluarlos para saber qu es lo que necesitan para poder ser docentes
en el PAB,
En realidad es una sola vez y el tiempo que nos dan es de unos solo un mes
Prcticamente una seleccin real o cientfica no se hace en el pab ya que en la seleccin
que se hace se basa en que sea un docente titulado del sistema universitario Titulado y que
sea ms o menos con la materia que va a dar
7.- Cmo realizan el control de la documentacin de los docentes?
Tenemos harta deficiencia en el manejo de archivos y recoleccin de datos, lo hacemos
manualmente
21

Los Organizamos mediante los Cndor pero eso es muy fcil que se entre papelee en casos
que se han dado as que es muy fcil que se pierda la documentacin.
8.- Cmo controla el ingreso de documentacin?
Por Recepcin en la Secretaria
Manualmente y Luego los pasamos a Excel
El ingreso de la documentacin se lo controla mediante una fotocopia q se lleva el docente.
9.- Qu operaciones desea que realice su sistema?
Me gustara tener docentes afiliados ya que si me falla el titular estn ellos ah para poder
ubicarlos
10.- De qu manera manejan toda la informacin sobre los docentes (libro, tablas,
archivo)?
La informacin digital que se maneja es en planillas y tablas de Excel, Los Contratos en
Word y los certificados en Power Point.
22

Fecha: 31/08/09
1.- Le gustara guardar el registro de sus profesores que son contratados?
Obvio que me registre todo en General nos hace falta y que me guarde los datos de
profesores para consultar cualquier momento
2.- Le gustara guardar los datos de los profesores que no han sido contratados, si
por algn motivo tendran que cambiar o reemplazar un profesor?
Obvio, por supuesto que s, Esa es la idea que tenemos en mente tener una base de datos
que nos sirva para siempre por medio de informacin para tenerlo como medio de
informacin
3.- De qu se encargan los coordinadores?
Los Coordinadores se encargan de las materias, cada materia tiene un coordinador, cada
uno de ellos se encarga de hacer los textos de crear el sistema acadmico, cada materia
tiene un coordinador tanto los textos
Los Coordinadores de rea se encargan de elaborar todo lo que es en marco la materia que
van a dictar, ellos elaboran los libros que van a dictar todos los docentes de la misma rea o
materia
4.- Cmo se realiza o como se comunica a los profesores que han sido aceptados
para dictar las clases?
23
La mayora de los docentes ya son antiguos y ellos vienen a ver si ya estn programados y
si se les ha asignado una materia
Mayormente por medio del telfono o mandando por mensajes
5.- Prefiere tener diferentes accesos al sistema, en el que solo usted tenga acceso a
toda la informacin y limitar la informacin que manejen los dems usuarios del
sistema?
Cosa que cada uno debera haber uno que controla pero todos deberamos tener acceso a
esa informacin
6.- Qu informacin le resulta adecuada aparezca en pantalla al registrar un docente?
Lo bsico que aparezca un nombre un grupo y el nmero de telfono y la profesin para
poner un rea
La Bsica y aun ms todava si o si tienen q estar nombre i Ci telfono actualizado y un
correo electrnico tiene q tener de que carrera es y tambin el monto que va a recibir, los
descuentos que se le van a realizar
7.- Qu operaciones realiza manualmente (puede ser una lista de doc. seleccionados,
las planillas el control de hora de trabajos, etc.)?
El Control de horas de trabajo el listado se maneja en Excel pero tambin es manual aunque
hay ah un poco de tecnologa
Manualmente se realiza todo desde la planilla
24
8.- Cules son inconvenientes que tiene al realizar todo el proceso de seleccin de
de profes?
La el embotellamiento que hay a fin de ao no se mira de que rea es porque ingresan
muchos alumnos x q ah no podemos darnos el lujo de elegir por ejemplo Ud. no es de esta
rea no la puede dar.
Vienen de la parte legal ya que por ejemplo este ao con la ley financial y la ley 0181 que
dice que no se puede contratar administrativos
9.- En cuntas provincias trabaja el pab?
Trabaja donde la UAGRM tiene alguna sucursal
10.- Existe alguna diferencia para los profesores de provincia, cules?
Si, es q algunas veces como ellos son de planta porque la mayora que acepta ser docente
en provincia es porque ya trabajan all y es regularizado, se le pide solamente su fotocopia
de carnet y sus solicitudes
25

Fecha: 01/09/09
1.- Cmo programan los grupos y horarios que se ofertan en los cursos del P.A.B.?
Lo programa el encargado de la programacin lo programa aqu el pab como lo programa de
acuerdo a los grupos de acuerdo al curso que se est dando y de acuerdo al curso q se est
dando y de acuerdo de cmo me bien la convocatoria los cursos son diferentes en los cursos
de verano y de invierno
Los cursos son diferentes en materias en tiempo y en la modalidad que se puede dar
2.- Cmo saben que tienen que crear algn nuevo grupo?
Al meter Grupos al Sistema se le asigna una cantidad determinada de cupos, los
transcriptores son los primeros en darse cuenta de ello y mandan a la oficina a un encargado
para que nos llame y nos avisan que ya no hay cupos en un turno entonces aadimos
nuevos grupos desde mi cuenta, que tiene ese privilegio
3.- Cmo los clasifican los grupos, por rea, por turno o por carrera?
Por rea.
4.- Tienen algn sistema que utilizan para crear los grupos?
Ocupamos tanto manual tano como sistema, pero en realidad lo q vale es el sistema porque
todos los datos q se meten tienen q aparece para poder pagar porque de acuerdo a eso se
paga, de acuerdo a eso se programa, por ejemplo en un pab de invierno no se puede
programar aqu adentro
26
5.- El sistema que utilizan para la inscripcin al pab es del departamento?

Es Del Centro de Procesamiento de Datos pero el CPD nos facilita un sistema que solo nos
permite ponerle grupo y horarios los cuales ya preparamos con anticipacin para solo
habilitarlos con una cantidad determinada de cupos
Se lo hace pensando pero sin usar ningn sistema informtico
6.- Cmo podran tener un reporte de los estudiantes inscritos al pab, si lo desearan?
El mismo CPD nos facilita imprimirnos reportes, estadsticas, incluso reportes de notas de
cualquier tipo cuando nosotros queramos pero tenemos que pedrselos un da antes.
27
1.8.
Elementos Del Sistema

Seleccin De docentes PAB
Entrada: Documentos Del Docente: Nombre Completo, CI, Solicitud De Docencia,
Informe de Actividades (Avance), Fotocopia De Titulo Profesional en provisin
Nacional, Horarios Disponibles, Materias que pretende dictar y Hoja De Vida
Objeto: Oficinas del Programa de Admisin Bsica, Documentacin
Sujeto: Secretaria y Docente Postulante
Concepto: Seleccin de Docentes para dictar el Curso del PAB de Verano y/o Invierno
Ambiente interno: Oficinas Del PAB
Ambiente externo: Formas de Ingreso a otras Universidades
Salida: Nota De Recibidos los documentos para la postulacin a Docencia.
PROCESO
ENTRADA
-Nombre
Seleccin de Docentes para

dictar el curso de PAB de
verano y/o invierno.
-CI
SALIDA
Nota De Recibido los
documentos para la
-Solicitud de docencia
postulacin a docencia
-Informe de Actividades (Avance)

-Fotocopia del Ttulo en Provisin
Nacional.
-Hoja De Vida
28
Asignacin de Aulas Para Las Clases del Programa de Admisin Bsica

Entrada: Lista de las Aulas Libres o Colegios Disponibles para que se lleve a cabo los
cursos del Programa de admisin Bsica, Permiso Correspondiente para Ocupar las
Aulas durante cierto periodo
Objeto: Oficinas Del Programa de admisin Bsica, Listas De Las Aulas
Sujeto: Aulas, Encargado De organizacin y asignacin de Aulas
Concepto: Asignacin de Aulas para Pasar Clases De las diferentes reas en grupo
Ambiente Interno: Oficinas del PAB.
Ambiente Externo: Formas De Ingreso a Otras Universidades
Salida: Programacin de aulas para las diferentes materias que se dictaran.
PROCESO
ENTRADA
-Lista De Aulas De
Programacin y Asignacin
De Aulas Para las clases del
programa de admisin bsica
SALIDA
Lista De Aulas Designadas
La universidad
para las diferentes materias
Disponibles
que se dictaran en el
-Lista De Colegios.
Programa de Admisin
Con Aulas Disponibles.
Bsica
29
Programacin de Grupos y Horarios

Entrada: Horarios Disponibles de los docentes en su documentacin para dictar los
cursos del Programa de Orientacin Vocacional
Objeto: Oficinas Del PAB, Ordenador, Software para elaborar tablas (Excel)
Sujeto: Encargado De Organizacin De Grupos, Docentes
Concepto: Programacin de grupos y horarios para los diferentes docentes en todas
las reas Para que dicten los Cursos Del Programa de admisin Bsica
Ambiente interno: Oficinas Del PAB
Ambiente externo: Formas De Ingreso a Otras Universidades
Salida: Grupos Y Horarios Imprimidos y Bien Organizados en Boletas, Pancartas,
para hacer Conocer a Cada Alumno y a cada Docente Donde Se Dictaran Las Clases,
en que horario y que materia Se Cursara en Dicho Horario.
PROCESO
ENTRADA
-Horarios Disponibles
Programacin de Grupos y
Horarios para los diferentes
Cursos Del Programa De
Admisin Bsica
De Los Docentes en su
SALIDA
Lista De Grupos y Horarios
que se Imprime y se da a
Documentacin para
Conocer a todo alumno y
Dictar Los Cursos del
docente que participe del
Programa De Admisin Bsica
Programa De Admisin
Bsica
30
Programacin De Aulas Para Exmenes

Entrada: Lista De Todas Las Aulas disponibles en el Campus y los Mdulos,
autorizacin para el uso de las aulas en fin de semana, Lista De Docentes De Planta
Disponibles para Tomar El Examen.
Objeto: Aulas De la universidad,
Sujeto: Docentes, Coordinadores y Jefe Del PAB
Concepto: Programacin y Organizacin De Las Aulas Para La Toma Del 1er y 2do
Examen
Ambiente interno: Aulas De la universidad.
Ambiente externo: Otras Formas De Ingreso a otras Universidades
Salida: Lista De Los Cursos para el da del examen que se hace conocer en los
diferentes Grupos Con anticipacin y se hace pblica para el Conocimiento de los
postulantes.
PROCESO
ENTRADA
-Lista De Aulas De
Programacin y Asignacin
De Aulas Para los Exmenes
del programa de admisin
bsica
SALIDA
Lista De las Aulas
Disponibles en la
Designadas en La
Universidad En el
Universidad para
Campus y Mdulos
Conocimiento Pblico De
Docentes y estudiantes
Que Participen en el Programa De

Admisin Bsica
31
1.9. Metodologa Ishikawa

1.9.1. Identificar el problema
P1. Desorden en la oficina por el exceso de archivos
P2. Infraestructura Inadecuada con oficinas demasiado pequeas
P3. Escasez de Muebles de Escritorio
P4. Insuficiente equipo de Computacin
P5. Retraso en la entrega de documentos de los docentes que dictan el curso
P6. No hay un mtodo fijo de seleccin de docentes
P7. Poca Coordinacin en el avance del Curso PAB
P8. Inadecuada asignacin de materias a profesores
P9. Dificultad en la asignacin de las aulas Libres
P10. Problemas en la Disponibilidad de Horarios Con respecto a las materias
P11. Poca experiencia por parte de los nuevos docentes
P12. Los profesores tienen una Insuficiente informacin acerca de las actividades
acadmicas a desarrollar
P13. Inadecuada seleccin de los profesores ya muchas veces se lo selecciona solo por
seer de la misma lnea poltica, por el cumplimiento de los requisitos sin tomar en cuenta los
meritos y experiencia indicados en su hoja de vida
P14. El personal que trabaja en el departamento del pab es desorganizado
P15. Poco de inters de parte del personal al realizar su trabajo
P16. Muchos de los que trabajan dentro del departamento son incompetentes ya que no
conocen su rea de trabajo
P17. Los trabajadores no cumplen con el manual de funciones haciendo deficiente todo el
manejo de la informacin sobre los profesores ya que todos hacen de todo
y eso es completamente Ineficaz para el departamento.
32
1.9.2. Identificar las principales categoras

a) El ambiente
b) Economa
c) Recursos humanos (personal)
d) Profesores
e) Mtodos
33
1.9.3. Identificar las causas

Las causas para una inadecuada seleccin de profesores son las siguientes:
a) El ambiente, este es una de las causas ya la infraestructura es inadecuada por el
espacio pequeo adems no cuentan con los muebles de escritorio propicios para
desarrollar su trabajo, adems existe un desorden de los archivos, papeles y documentacin
q presentan los profesores.
b) Economa, este departamento no cuenta con los recursos suficientes ya que las
computadoras que tienen estn en mal estado y fuera de mantenimiento, tanto como sus
accesorios.
c) Recursos humanos (Personal), En este grupo se incluyen los factores que pueden
generar el problema desde el punto de vista del factor humano. Por ejemplo, falta de
experiencia del personal, salario, falta de capacitacin, desinters, incompetencia, falta de
organizacin, incumplimiento del manual de funciones.
d) Profesores, esta es una de las mayores causas del problema por su irresponsabilidad,
retraso en la presentacin de sus documentos, falta de coordinacin con los administrativos
del departamento, falta de informacin ya sea porque no hay los medios y son una gran
cantidad, por no presentar todos sus requisitos, falta de experiencia de parte de los que por
primera vez estn trabajando, poca disponibilidad de horarios.
e) Mtodos, los que utilizan para la seleccin de profesores muy mecnicos adems no
cuentan con un modelo fijo de seleccin ya que lo hacen por poltica, por disponibilidad de
horarios, por el cumplimiento de requisitos y por tanto una inadecuada asignacin materiaprofesor, dejando en segundo plano los meritos ganados o que cuentan en su hoja de vida
siento este el mejor mtodo de seleccin.
34
35
1.9.4. Anlisis y Conclusin

Existe una gran cantidad de problemas en este departamento, sin embargo nosotros
no nos encargaremos de los problemas P1, P2, P3, P4, P5, P7, P11, P12, P14, P15 y
P16 nos abocaremos a los ms mecnicos y adems que necesitan automatizacin
en ese trabajo, los cuales son el P6, P8, P9, P10, P13 y P17 por lo tanto nuestro
sistema de informacin administrara el problema Determinacin de los factores de la
seleccin inadecuada de Docentes en el cual los problemas y sern solucionados
Desarrollando Un Sistema de Informacin.
36
2. Marco Terico
2.1. Lenguaje Unificado de Modelado-UML
UML [UML] es un lenguaje para especificar, construir, visualizar y documentar los artefactos
de un sistema de software orientado a objetos (OO). Un artefacto es una informacin que es
utilizada
producida
mediante
un
proceso
de
desarrollo
de
software.
UML se quiere convertir en un lenguaje estndar con el que sea posible modelar todos los
componentes del proceso de desarrollo de aplicaciones. Sin embargo, hay que tener en
cuenta un aspecto importante del modelo: no pretende definir un modelo estndar de
desarrollo, sino nicamente un lenguaje de modelado. Otros mtodos de modelaje como
OMT (Object Modeling Technique) o Booch s definen procesos concretos. En UML los
procesos de desarrollo son diferentes segn los distintos dominios de trabajo; no puede ser
el mismo el proceso para crear una aplicacin en tiempo real, que el proceso de desarrollo
de
una
aplicacin
orientada
gestin,
por
poner
un
ejemplo.
Las diferencias son muy marcadas y afectan a todas las fases del proceso. El mtodo del
UML recomienda utilizar los procesos que otras metodologas tienen definidos.
Historia de UML
A partir del ao 1994, Grady Booch [Booch96](precursor de Booch '93) y Jim Rumbaugh
(creador de OMT) se unen en una empresa comn, Rational Software Corporation, y
comienzan a unificar sus dos mtodos. Un ao ms tarde, en octubre de 1995, aparece UML
(Unified Modeling Language) 0.8, la que se considera como la primera versin del UML. A
finales de ese mismo ao, Ivan Jacobson, creador de OOSE (Object Oriented Software
Engineer)
se
aade
37
al
grupo.
Como objetivos principales de la consecucin de un nuevo mtodo que aunara los mejores
aspectos de sus predecesores, sus protagonistas se propusieron lo siguiente:
o
El mtodo deba ser capaz de modelar no slo sistemas de software sino otro
tipo de sistemas reales de la empresa, siempre utilizando los conceptos de la
orientacin a objetos (OO).
Crear un lenguaje para modelado utilizable a la vez por mquinas y por

personas.
Establecer un acoplamiento explcito de los conceptos y los artefactos

ejecutables.
Manejar los problemas tpicos de los sistemas complejos de misin crtica.
Lo que se intenta es lograr con esto que los lenguajes que se aplican siguiendo los mtodos
ms utilizados sigan evolucionando en conjunto y no por separado. Y adems, unificar las
perspectivas entre diferentes tipos de sistemas (no slo software, sino tambin en el mbito
de los negocios), al aclarar las fases de desarrollo, los requerimientos de anlisis, el diseo,
la implementacin y los conceptos internos de la OO.
La notacin UML se deriva y unifica las tres metodologas de anlisis y diseo OO ms
extendidas:
1. Metodologa de Grady Booch para la descripcin de conjuntos de objetos y sus
relaciones.
2. Tcnica de modelado orientada a objetos de James Rumbaugh (OMT: ObjectModeling Technique).
3. Aproximacin de Ivan Jacobson (OOSE: Object- Oriented Software Engineering)
mediante la metodologa de casos de uso (use case).
38
El desarrollo de UML comenz a finales de 1994 cuando Grady Booch y Jim Rumbaugh
de Rational Software Corporation empezaron a unificar sus mtodos. A finales de 1995,
Ivan Jacobson y su compaa Objectory se incorporaron a Rational en su unificacin,
aportando el mtodo OOSE.
De las tres metodologas de partida, las de Booch y Rumbaugh pueden ser descritas
como centradas en objetos, ya que sus aproximaciones se enfocan hacia el modelado de
los objetos que componen el sistema, su relacin y colaboracin. Por otro lado, la
metodologa de Jacobson es ms centrada a usuario, ya que todo en su mtodo se
deriva de los escenarios de uso. UML se ha ido fomentando y aceptando como estndar
desde la formacin de OMG, que es tambin el origen de CORBA, el estndar lder en la
industria para la programacin de objetos distribuidos. En 1997 UML 1.1 fue aprobada
por la OMG convirtindose en la notacin estndar de facto para el anlisis y el diseo
orientado a objetos.
UML es el primer mtodo en publicar un meta-modelo en su propia notacin, incluyendo
la notacin para la mayora de la informacin de requisitos, anlisis y diseo. Se trata
pues de un meta-modelo auto-referencial (cualquier lenguaje de modelado de propsito
general debera ser capaz de modelarse a s mismo). En la actualidad
Existe actualmente una Revision Task Force (RTF) responsable de la generacin de
revisiones menores de la especificacin UML 1.1. La primera RTF de UML termin su
revisin en Junio de 1999 con el draft final UML 1.3, actualmente ya se public la revisin
1.5. Adems de estas revisiones menores tambin se est trabajando en una revisin
mayor en lo que sera el UML 2.0.
39
Objetivos
Durante el desarrollo del UML sus autores tuvieron en cuenta:
1. Proporcionar una notacin y semnticas suficientes para poder alcanzar una gran
cantidad de aspectos del modelado contemporneo de una forma directa y
econmica.
2. Proporcionar las semnticas suficientes para alcanzar aspectos del modelado que
son de esperar en un futuro, como por ejemplo aspectos relacionados con la
tecnologa
de
componentes,
el
cmputo
distribuido,
etc.
Proporcionar mecanismos de extensin de forma que proyectos concretos puedan

extender el meta-modelo a un coste bajo.
3. Proporcionar mecanismos de extensin de forma que aproximaciones de
modelado futuras podran desarrollarse encima del UML.
4. Permitir el intercambio de modelos entre una gran variedad de herramientas.
40
5. Proporcionar semnticas suficientes para especificar las interfaces a bibliotecas

para la comparticin y el almacenamiento de componentes del modelo.
Mediante el fomento del uso de UML OMG pretende alcanzar los siguientes objetivos:
1. Proporcionar a los usuarios un lenguaje de modelado visual expresivo y utilizable
para el desarrollo e intercambio de modelos significativos.
2. Proporcionar mecanismos de extensin y especializacin.
3. Ser independiente del proceso de desarrollo y de los lenguajes de programacin.
4. Proporcionar una base formal para entender el lenguaje de modelado.
5. Fomentar el crecimiento del mercado de las herramientas OO.
6. Soportar conceptos de desarrollo de alto nivel como pueden ser colaboraciones,
frameworks, patterns, y componentes.
7. Integrar las mejores prcticas utilizadas hasta el momento.
El UML debe entenderse como un estndar para modelado y no como un estndar de
proceso software. Aunque UML debe ser aplicado en el contexto de un proceso, la
experiencia ha mostrado que organizaciones diferentes y dominios del problema
diferentes requieren diferentes procesos. Por ello se han centrado los esfuerzos en un
meta-modelo comn (que unifica las semnticas) y una notacin comn que proporcione
una representacin de esas semnticas. De todas formas, los autores de UML fomentan
un proceso guiado por casos de uso, centrado en la arquitectura, iterativo e incremental.
Bajo estas lneas genricas proponen el proceso software definido en una de las
extensiones del UML (Objectory Extension for Software Engineering), pero en general el
proceso software es fuertemente dependiente de la organizacin y del dominio de
aplicacin.
Por ltimo mencionar que aunque UML abarca todas las tcnicas existentes, es de
esperar que aparezcan nuevas tcnicas. El UML se puede adaptar a estas nuevas
41
tcnicas ya que dispone de mecanismos de extensin que no necesitan redefinir el

ncleo UML.
OMG
El OMG (Object Management Group) se form en 1989 con el propsito de crear una
arquitectura estndar para objetos distribuidos en redes (componentes). En Octubre de 1989
empez a funcionar como una corporacin independiente y sin nimo de lucro. El
compromiso asumido por el OMG busca el desarrollo de especificaciones para la industria
del software que sean tcnicamente ``excelentes'', comercialmente viables e independientes
del vendedor.
Hoy en da el consorcio incluye unos 800 miembros (compaas en la industria del software).
La primera arquitectura resultante de esta colaboracin fue CORBA (Common Objet Request
Broker Arquitecture). El elemento central de esta arquitectura es el ORB (Object Request
Broker). Un ORB permite que un objeto cliente haga una peticin a un servidor sin conocer
la interfaz ni la localizacin del objeto servidor. OMG define "object management" como el
desarrollo software que modela el mundo real mediante su representacin como objetos.
Estos objetos no son ms que la encapsulacin de atributos, relaciones y mtodos de
componentes software identificable.
2.1.1. Vocabulario de UML

Los bloques bsicos de construccin de UML son tres, los elementos, las relaciones y los
diagramas.
Los elementos son abstracciones que actan como unidades bsicas de

construccin. Hay cuatro tipos, los estructurales, los de comportamiento, los de
agrupacin y los de notacin. En cuanto a los elementos estructurales son las partes
estticas de los modelos y representan aspectos conceptuales o materiales. Los
elementos de comportamiento son las partes dinmicas de los modelos y representan
comportamientos en el tiempo y en el espacio. Los elementos de agrupacin son las
partes organizativas de UML, establecen las divisiones en que se puede fraccionar un
42
modelo. Slo hay un elemento de agrupacin, el paquete, que se emplea para

organizar otros elementos en grupos. Los elementos de notacin son las partes
explicativas de UML, comentarios que pueden describir textualmente cualquier
aspecto de un modelo. Slo hay un elemento de notacin principal, la nota.
Las relaciones son abstracciones que actan como unin entre los distintos
elementos. Hay cuatro tipos, la dependencia, la asociacin, la generalizacin y la
realizacin.
Los diagramas son la disposicin de un conjunto de elementos, que representan el sistema

modelado desde diferentes perspectivas. UML tiene nueve diagramas fundamentales,
agrupados en dos grandes grupos, uno para modelar la estructura esttica del sistema y otro
para modelar el comportamiento dinmico. Los diagramas estticos son: el de clases, de
objetos, de componentes y de despliegue. Los diagramas de comportamiento son: el de
Casos de Uso, de secuencia, de colaboracin, de estados y de actividades.
43
Elementos
Describe un conjunto de objetos
que comparten los mismos
atributos, mtodos, relaciones y
semntica. Las clases
implementan una o ms
interfaces.
Se trata de una clase, en la que
existe procesos o hilos de
ejecucin concurrentes con otros
elementos. Las lneas del
contorno son ms gruesas que en
la clase normal
Clase
Clase activa
E
L
E
M
E
N
T
O
S
E
S
T
R
U
C
T
U
R
A
L
E
S
Agrupacin de mtodos u
operaciones que especifican un
servicio de una clase o
componente, describiendo su
comportamiento, completo o
parcial, externamente visible.
UML permite emplear un crculo
para representar las interfaces,
aunque lo ms normal es emplear
la clase con el nombre en
cursiva.
Define una interaccin entre
elementos que cooperan para
proporcionar un comportamiento
mayor que la suma de los
comportamientos de sus
elementos.
Describe un conjunto de
secuencias de acciones que un
sistema ejecuta, para producir un
resultado observable de inters.
Se emplea para estructurar los
aspectos de comportamiento de
un modelo.
Parte fsica y por tanto
reemplazable de un modelo, que
agrupa un conjunto de interfaces,
archivos de cdigo fuente,
clases, colaboraciones y
proporciona la implementacin
de dichos elementos.
Elemento fsico que existe en
tiempo de ejecucin y representa
un recurso computacional con
capacidad de procesar.
Interfaz
Colaboracin
Caso de uso
Componente
Nodo
44
Comprende un conjunto de
mensajes que se intercambian
entre un conjunto de objetos,
para cumplir un objetivo
especifico.
Especifica la secuencia de
estados por los que pasa un
objeto o una interaccin, en
respuesta a eventos.
Se emplea para organizar otros
elementos en grupos.
Interaccin
Elementos
de
comportamiento
Mquinas
de
estados
Elementos
de
agrupacin
Elementos
de
notacin
Paquete
Partes explicativa de UML, que

puede describir textualmente
cualquier aspecto del modelo
Nota
Relaciones
Dependencia
Es una relacin entre dos elementos, tal que un

cambio en uno puede afectar al otro.
Asociacin
Es una relacin estructural que resume un conjunto

de enlaces que son conexiones entre objetos.
Generalizacin
Realizacin
Es una relacin en la que el elemento generalizado

puede ser substituido por cualquiera de los
elementos hijos, ya que comparten su estructura y
comportamiento.
Es una relacin que implica que la parte realizante
cumple con una serie de especificaciones propuestas
por la clase realizada (interfaces).
45
Diagramas
Muestra un conjunto de clases,
interfaces y colaboraciones, as como
sus relaciones, cubriendo la vista de
diseo esttica del sistema.
Clases
M
O
D
E
L
A
N
E
S
T
R
U
C
T
U
R
A
Anlogo al diagrama de clases,

muestra un conjunto de objetos y sus
relaciones, pero a modo de vista
instantnea de instancias de una clase
en el tiempo.
Muestra la organizacin y
dependencias de un conjunto de
componentes. Cubren la vista de
implementacin esttica de un sistema.
Un componente es un mdulo de
cdigo, de modo que los diagramas de
componentes son los anlogos fsicos a
los diagramas de clases.
Muestra la configuracin del hardware
del sistema, los nodos de proceso y los
componentes empleados por stos.
Cubren la vista de despliegue esttica
de una arquitectura.
Objetos
Componentes
Despliegue
Muestra un conjunto de casos de uso,

los actores implicados y sus relaciones.
Son diagramas fundamentales en el
modelado y organizacin del sistema.
Casos de Uso
M
O
D
E
L
A
N
Son diagramas de interaccin,

muestran un conjunto de objetos y sus
relaciones, as como los mensajes que
se intercambian entre ellos. Cubren la
vista dinmica del sistema. El
diagrama de secuencia resalta la
ordenacin temporal de los mensajes,
mientras que el de colaboracin resalta
Secuencia
46
C
O
M
P
O
R
T
A
M
I
E
N
T
O
la organizacin estructural de los

objetos, ambos siendo equivalentes o
isomorfos. En el diagrama de
colaboracin de la figura de la
izquierda, se puede ver que los
elementos grficos no son cajas
rectangulares, como cabra esperar, y
en su lugar encontramos sus versiones
adornadas. Estas versiones tienen
como finalidad evidenciar un rol
especfico del objeto siendo modelado.
En la figura encontramos de izquierda
a derecha y de arriba abajo un Actor,
una Interfaz, un Control (modela un
comportamiento) y una Instancia
(modela un objeto de dato).
Muestra una mquina de estados, con
sus estados, transiciones, eventos y
actividades. Cubren la vista dinmica
de un sistema. Modelan
comportamientos reactivos en base a
eventos.
Tipo especial de diagrama de estados
que muestra el flujo de actividades
dentro de un sistema.
Colaboracin
Estados
Actividades
47
2.1.2. Aspecto Esttico y Dinmicos

Se Dispone de dos tipos diferentes de diagramas los que dan una vista esttica del sistema
y los que dan una visin dinmica. Los diagramas estticos son:
Diagrama de clases: muestra las clases, interfaces, colaboraciones y sus

relaciones. Son los ms comunes y dan una vista esttica del proyecto.
Diagrama de objetos: Es un diagrama de instancias de las clases mostradas en el

diagrama de clases. Muestra las instancias y como se relacionan entre ellas. Se
da una visin de casos reales.
Diagrama de componentes: Muestran la organizacin de los componentes del

sistema. Un componente se corresponde con una o varias clases, interfaces o
colaboraciones.
Diagrama de despliegue.: Muestra los nodos y sus relaciones. Un nodo es un

conjunto de componentes. Se utiliza para reducir la complejidad de los diagramas
de clases y componentes de un gran sistema. Sirve como resumen e ndice.
Diagrama de casos de uso: Muestran los casos de uso, actores y sus relaciones.
Muestra quien puede hacer que y relaciones existen entre acciones (casos de
uso). Son muy importantes para modelar y organizar el comportamiento del
sistema.
Lo diagramas dinmicos son:
Diagrama de secuencia, Diagrama de colaboracin: Muestran a los diferentes

objetos y las relaciones que pueden tener entre ellos, los mensajes que se envan
entre ellos. Son dos diagramas diferentes, que se puede pasar de uno a otro sin
prdida de informacin, pero que nos dan puntos de vista diferentes del sistema.
En resumen, cualquiera de los dos es un Diagrama de Interaccin.
48
Diagrama de estados: muestra los estados, eventos, transiciones y actividades de

los diferentes objetos. Son tiles en sistemas que reaccionen a eventos.
Diagrama de actividades: Es un caso especial del diagrama de estados. Muestra

el flujo entre los objetos. Se utilizan para modelar el funcionamiento del sistema y
el flujo de control entre objetos.
Como podemos ver el nmero de diagramas es muy alto, en la mayora de los casos
excesivos, y UML permite definir solo los necesarios, ya que no todos son necesarios en
todos los proyectos. En el documento se dar una breve explicacin de todos,
amplindose para los ms necesarios.
2.1.3. Diagrama de Clases

Los diagramas de clases representan un conjunto de elementos del modelo que son
estticos, como las clases y los tipos, sus contenidos y las relaciones que se establecen
entre ellos.
Algunos de los elementos que se pueden clasificar como estticos son los siguientes:
Paquete: Es el mecanismo de que dispone UML para organizar sus elementos en grupos,
se representa un grupo de elementos del modelo. Un sistema es un nico paquete que
contiene el resto del sistema, por lo tanto, un paquete debe poder anidarse, permitindose
que un paquete contenga otro paquete.
Clases: Una clase representa un conjunto de objetos que tienen una estructura, un
comportamiento y unas relaciones con propiedades parecidas. Describe un conjunto de
objetos que comparte los mismos atributos, operaciones, mtodos, relaciones y significado.
En UML una clase es una implementacin de un tipo. Los componentes de una clase son:
Atributo: Se corresponde con las propiedades de una clase o un tipo. Se identifica mediante
un nombre. Existen atributos simples y complejos.
Operacin. Tambin conocido como mtodo, es un servicio proporcionado por la clase que
49
puede ser solicitado por otras clases y que produce un comportamiento en ellas cuando se
realiza.
Las clases pueden tener varios parmetros formales, son las clases denominadas plantillas.
Sus atributos y operaciones vendrn definidos segn sus parmetros formales. Las plantillas
pueden tener especificados los valores reales para los parmetros formales, entonces
reciben el nombre de clase parametrizada instanciada. Se puede usar en cualquier lugar en
el que se podra aparecer su plantilla.
Relacionando con las clases nos encontramos con el trmino utilidad, que se corresponde
con una agrupacin de variables y procedimientos globales en forma de declaracin de
clase, tambin puede definirse como un estereotipo (o nueva clase generada a partir de otra
ya existente) de un tipo que agrupa variables globales y procedimientos en una declaracin
de clase. Los atributos y operaciones que se agrupan en una utilidad se convierten en
variables y operaciones globales. Una utilidad no es fundamental para el modelado, pero
puede ser conveniente durante la programacin.
Meta-clase: Es una clase cuyas instancias son clases. Sirven como depsito para mantener
las variables de clase y proporcionan operaciones (mtodo de clase) para inicializar estas
variables. Se utilizan para construir meta-modelos (modelos que se utilizan para definir otros
modelos).
Tipos: Es un descriptor de objetos que tiene un estado abstracto y especificaciones de
operaciones pero no su implementacin. Un tipo establece una especificacin de
comportamiento para las clases.
Interfaz: Representa el uso de un tipo para describir el comportamiento visible externamente
de cualquier elemento del modelo.
Relacin entre clases: Las clases se relacionan entre s de distintas formas, que marcan
los tipos de relaciones existentes:
50
Asociacin:
Es una relacin que describe un conjunto de vnculos entre clases. Pueden ser binarias o narias, segn se implican a dos clases o ms. Las relaciones de asociacin vienen
identificadas por los roles, que son los nombres que indican el comportamiento que tienen
los tipos o las clases, en el caso del rol de asociacin (existen otros tipos de roles segn la
relacin a la que identifiquen). Indican la informacin ms importante de las asociaciones. Es
posible indicar el nmero de instancias de una clase que participan en una relacin mediante
la llamada multiplicidad. Cuando la multiplicidad de un rol es mayor que 1, el conjunto de
elementos que se relacionan puede estar ordenado. Las relaciones de asociacin permiten
especificar qu objetos van a estar asociados con otro objeto mediante un calificador. El
calificador es un atributo o conjunto de atributos de una asociacin que determina los valores
que indican cuales son los valores que se asociarn.
Una asociacin se dirige desde una clase a otra (o un objeto a otro), el concepto de
navegabilidad se refiere al sentido en el que se recorre la asociacin.
Existe una forma especial de asociacin, la agregacin, que especifica una relacin entre las
clases donde el llamado "agregado" indica l todo y el "componente" es una parte del
mismo.
Composicin:
Es un tipo de agregacin donde la relacin de posesin es tan fuerte como para marcar otro
tipo de relacin. Las clases en UML tienen un tiempo de vida determinado, en las relaciones
de composicin, el tiempo de vida de la clase que es parte del todo (o agregado) viene
determinado por el tiempo de vida de la clase que representa el todo, por tanto es
equivalente a un atributo, aunque no lo es porque es una clase y puede funcionar como tal
en otros casos.
Generalizacin:
Cuando se establece una relacin de este tipo entre dos clases, una es una Superclase y la
otra es una Subclase. La subclase comparte la estructura y el comportamiento de la
superclase. Puede haber ms de una clase que se comporte como subclase.
51
Dependencia:
Una relacin de dependencia se establece entre clases (u objetos) cuando un cambio en el
elemento independiente del modelo puede requerir un cambio en el elemento dependiente.
2.1.4. Diagrama de Casos de Uso

Unos casos de uso es una secuencia de transacciones que son desarrolladas por un
sistema en respuesta a un evento que inicia un actor sobre el propio sistema. Los diagramas
de casos de uso sirven para especificar la funcionalidad y el comportamiento de un sistema
mediante su interaccin con los usuarios y/o otros sistemas. O lo que es igual, un diagrama
52
que muestra la relacin entre los actores y los casos de uso en un sistema. Una relacin es
una conexin entre los elementos del modelo, por ejemplo la relacin y la generalizacin son
relaciones.
Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al
mostrar cmo reacciona una respuesta a eventos que se producen en el mismo. En este tipo
de diagrama intervienen algunos conceptos nuevos: un actor es una entidad externa al
sistema que se modela y que puede interactuar con l; un ejemplo de actor podra ser un
usuario o cualquier otro sistema. Las relaciones entre casos de uso y actores pueden ser las
siguientes:
o
Un actor se comunica con un caso de uso.
Un caso de uso extiende otro caso de uso.
Un caso de uso usa otro caso de uso
Este modelo, se emplea para visualizar el comportamiento del sistema, una parte de l o de
una sola clase. De forma que se pueda conocer cmo responde esa parte del sistema. El
diagrama de uso es muy til para definir como debera ser el comportamiento de una parte
del sistema, ya que solo especifica cmo deben comportarse y no como estn
implementadas las partes que define. Por ello es un buen sistema de documentar partes del
cdigo que deban ser reutilizables por otros desarrolladores. El diagrama tambin puede ser
utilizado para que los expertos de dominio se comuniquen con los informticos sin llegar a
niveles de complejidad. Un caso de uso especifica un requerimiento funcional, es decir
indica esta parte debe hacer esto cuando pase esto.
En el diagrama nos encontramos con diferentes figuras que pueden mantener diversas
relaciones entre ellas:
53
Casos de uso: representado por una elipse, cada caso de uso contiene un nombre, que
indique su funcionalidad. Los casos de uso pueden tener relaciones con otros casos de uso.
Sus relaciones son:
Include: Representado por una flecha, en el diagrama de ejemplo podemos ver como un
caso de uso, el de totalizar el coste incluye a dos casos de uso.
Extends: Una relacin de una caso de Uso A hacia un caso de uso B indica que el caso de
uso B implementa la funcionalidad del caso de uso A.
Generalization: Es la tpica relacin de herencia.
Actores: se representan por un mueco. Sus relaciones son:
Communicates: Comunica un actor con un caso de uso, o con otro actor.
Parte del sistema (System boundary): Representado por un cuadro, identifica las diferentes
partes del sistema y contiene los casos de uso que la forman.
En este grafico encontramos tres casos de usos Crear producto utiliza Validar producto, y
Crear pack productos es una especializacin de Crear productos.
Podemos emplear el diagrama de dos formas diferentes, para modelar el contexto de un
sistema, y para modelar los requisitos del sistema.
54
Modelado del contexto.

Se debe modelar la relacin del sistema con los elementos externos, ya que son estos
elementos los que forman el contexto del sistema.
Los pasos a seguir son:
Identificar los actores que interactan con el sistema.
Organizar a los actores.
Especificar sus vas de comunicacin con el sistema.
Modelado de requisitos.
La funcin principal, o la ms conocida del diagrama de casos de uso es documentar los
requisitos del sistema, o de una parte de l.
Los requisitos establecen un contrato entre el sistema y su exterior, definen lo que se espera
que realice el sistema, sin definir su funcionamiento interno. Es el paso siguiente al
modelado del contexto, no indica relaciones entre autores, tan solo indica cuales deben ser
las funcionalidades (requisitos) del sistema. Se incorporan los casos de uso necesarios que
no son visibles desde los usuarios del sistema.
Para modelar los requisitos es recomendable:
Establecer su contexto, para lo que tambin podemos usar un diagrama de casos de

uso.
Identificar las necesidades de los elementos del contexto (Actores).
Nombrar esas necesidades, y darles forma de caso de uso.
Identificar que casos de uso pueden ser especializaciones de otros, o buscar

especializaciones comunes para los casos de uso ya encontrados.
55
Como podemos ver se incluyen nuevos casos de uso que no son visibles por ninguno de los
actores del sistema, pero que son necesarios para el correcto funcionamiento.
2.1.5. Diagrama de Objetos

Los diagramas de objetos modelan las instancias de elementos contenidos en los diagramas
de clases. Un diagrama de objetos muestra un conjunto de objetos y sus relaciones en un
momento concreto. En UML, los diagramas de clase se utilizan para visualizar los aspectos
estticos del sistema y los diagramas de interaccin se utilizan para ver los aspectos
dinmicos de los sistemas, y constan de instancias de los elementos del diagrama de clases
y mensajes enviados entre ellos. En un punto intermedio podemos situar los diagramas de
objetos, que contiene un conjunto de instancias de los elementos encontrados en el
diagrama de clases, representando slo la parte esttica de un interaccin, consistiendo en
los objetos que colaborar pero sin ninguno de los mensajes intercambiados entre ellos.
Los diagramas de objetos se emplean para modelar la vista de diseo esttica o la vista de
procesos esttica de un sistema al igual que se hace con los diagramas de clases, pero
56
desde la perspectiva de instancias reales o prototpicas. Esta vista sustenta principalmente

los requisitos funcionales de un sistema. Los diagramas de objetos permiten modelar
estructuras de datos estticas,
En general los diagramas de objetos se utilizan para modelar estructuras de objetos, lo que
implica tomar una instantnea de los objetos de un sistema en un cierto momento. Un
diagrama de objetos representa una escena esttica dentro de la historia representad a por
un diagrama de interaccin. Los diagramas de objetos se utilizan para visualizar, especificar,
construir y documentar la existencia de ciertas instancias en el sistema, junto a las
relaciones entre ellas.
Tendramos un diagrama de objetos con dos instancias de Mensaje, mas concretamente con
una instancia de Mensaje DIR y otra de Mensaje ADM, con todos sus atributos valorados.
Tambin tendramos una instancia de cada una de las otras clases que deban tener
instancia. Como CanalEnt, INS, Distr, y el Buzn correspondiente a la instancia de mensaje
que se est instanciando. En la instancia de la clase INS se deber mostrar en su miembro
Estado, que est ocupado realizando una insercin.
57
En un diseo no podemos encontrar con multitud de diagramas de objetos, cada uno de

ellos representando diferentes estados del sistema.
2.1.6. Diagrama de Componentes

Se utilizan para modelar la vista esttica de un sistema. Muestra la organizacin y las
dependencias entre un conjunto de componentes. No es necesario que un diagrama incluya
todos los componentes del sistema, normalmente se realizan por partes. Cada diagrama
describe un apartado del sistema.
En el situaremos libreras, tablas archivos, ejecutables y documentos que formen parte del
sistema.
Uno de los usos principales es que puede servir para ver que componentes pueden
compartirse entre sistemas o entre diferentes partes de un sistema.
Aqu tenemos un componente del sistema de Windows. En el diagrama de componentes de

Windows debe salir este componente, ya que sin el sistema no funcionara.
En esta otra figura tenemos el mismo componente, pero indicamos que dispone de un
interface. Al ser una Dll el interface nos da acceso a su contenido. Esto nos hace pensar que
la representacin anterior es incorrecta, pero no es as solo corresponde a un nivel diferente
de detalle.
Como ya hemos indicado antes todo objeto UML puede ser modificado mediante
estereotipos, el standard que define UML son:
Executable
Library
Table
File
Document.
58
Aunque por suerte no estamos limitados a estas especificaciones. Qu pasa si queremos

modelar un proyecto de Internet donde nuestros componentes son ASP, HTML, y Scripts, y
queremos marcarlo en el modelo. Pues utilizamos un estereotipo. Existen ya unos definidos
WAE (Web Applications Extensin).
Podemos modelar diferentes partes de nuestro sistema, y modelar diferentes entidades que
no tiene nada que ver entre ellas.
Ejecutables y bibliotecas.
Tablas.
API
Cdigo fuente.
Hojas HTML.
2.1.7. Diagrama de Distribucin
59
EL diagrama de distribucin muestra la arquitectura fsica de un sistema de informacin.

Se representan los equipos y dispositivos, adems la conexin entre ellos.
2.1.8. Diagrama de Actividades

Son similares a los diagramas de flujo de otras metodologas OO. En realidad se
corresponden con un caso especial de los diagramas de estado donde los estados son
estados de accin (estados con una accin interna y una o ms transiciones que suceden al
finalizar esta accin, o lo que es lo mismo, un paso en la ejecucin de lo que ser un
procedimiento) y las transiciones vienen provocadas por la finalizacin de las acciones que
tienen lugar en los estados de origen. Siempre van unidos a una clase o a la implementacin
de un caso de uso o de un mtodo (que tiene el mismo significado que en cualquier otra
metodologa OO). Los diagramas de actividad se utilizan para mostrar el flujo de
operaciones que se desencadenan en un procedimiento interno del sistema.
60
2.1.9. Diagrama de Estados

Representan la secuencia de estados por los que un objeto o una interaccin entre objetos
pasa durante su tiempo de vida en respuesta a estmulos (eventos) recibidos. Representa lo
que podemos denominar en conjunto una mquina de estados. Un estado en UML es
cuando un objeto o una interaccin satisface una condicin, desarrolla alguna accin o se
encuentra esperando un evento.
Cuando un objeto o una interaccin pasa de un estado a otro por la ocurrencia de un evento
se dice que ha sufrido una transicin, existen varios tipos de transiciones entre objetos:
simples (normales y reflexivas) y complejas. Adems una transicin puede ser interna si el
estado del que parte el objeto o interaccin es el mismo que al que llega, no se provoca un
cambio de estado y se representan dentro del estado, no de la transicin. Como en todas las
61
metodologas OO se envan mensajes, en este caso es la accin de la que puede enviar

mensajes a uno o varios objetos destino
2.1.10. Diagrama de Colaboracin

Muestra la interaccin entre varios objetos y los enlaces que existen entre ellos. Representa
las interacciones entre objetos organizadas alrededor de los objetos y sus vinculaciones. A
diferencia de un diagrama de secuencias, un diagrama de colaboraciones muestra las
relaciones entre los objetos, no la secuencia en el tiempo en que se producen los mensajes.
Los diagramas de secuencias y los diagramas de colaboraciones expresan informacin
similar, pero en una forma diferente.
Formando parte de los diagramas de colaboracin nos encontramos con objetos, enlaces y
mensajes. Un objeto es una instancia de una clase que participa como una interaccin,
existen objetos simples y complejos. Un objeto es activo si posee un thread o hilo de control
y es capaz de iniciar la actividad de control, mientras que un objeto es pasivo si mantiene
datos pero no inicia la actividad.
Un enlace es una instancia de una asociacin que conecta dos objetos de un diagrama de
62
colaboracin. El enlace puede ser reflexivo si conecta a un elemento consigo mismo. La

existencia de un enlace entre dos objetos indica que puede existir un intercambio de
mensajes entre los objetos conectados.
Los diagramas de interaccin indican el flujo de mensajes entre elementos del modelo, el
flujo de mensajes representa el envo de un mensaje desde un objeto a otro si entre ellos
existe un enlace. Los mensajes que se envan entre objetos pueden ser de distintos tipos,
tambin segn como se producen en el tiempo; existen mensajes simples, sincrnicos,
balking, timeout y asncronos. Durante la ejecucin de un diagrama de colaboracin se crean
y destruyen objetos y enlaces.
2.1.11. Diagrama de Secuencia

Muestran las interacciones entre un conjunto de objetos, ordenadas segn el tiempo en que
tienen lugar. En los diagramas de este tipo intervienen objetos, que tienen un significado
parecido al de los objetos representados en los diagramas de colaboracin, es decir son
instancias concretas de una clase que participa en la interaccin. El objeto puede existir slo
durante la ejecucin de la interaccin, se puede crear o puede ser destruido durante la
ejecucin de la interaccin. Un diagrama de secuencia representa una forma de indicar el
perodo durante el que un objeto est desarrollando una accin directamente o a travs de
un procedimiento.
En este tipo de diagramas tambin intervienen los mensajes, que son la forma en que se
comunican los objetos: el objeto origen solicita (llama a) una operacin del objeto destino.
Existen distintos tipos de mensajes segn cmo se producen en el tiempo: simples,
sncronos, y asncronos.
63
Los diagramas de secuencia permiten indicar cul es el momento en el que se enva o se

completa un mensaje mediante el tiempo de transicin, que se especifica en el diagrama.
El diagrama de secuencia forma parte del modelado dinmico del sistema. Se modelan las
llamadas entre clases desde un punto concreto del sistema. Es til para observar la vida de
los objetos en sistema, identificar llamadas a realizar o posibles errores del modelado
esttico, que imposibiliten el flujo de informacin o de llamadas entre los componentes del
sistema.
En el diagrama de secuencia se muestra el orden de las llamadas en el sistema. Se utiliza
un diagrama para cada llamada a representar. Es imposible representar en un solo diagrama
de secuencia todas las secuencias posibles del sistema, por ello se escoge un punto de
partida. El diagrama se forma con los objetos que forman parte de la secuencia, estos se
sitan en la parte superior de la pantalla, normalmente en la izquierda se sita al que inicia la
accin. De estos objetos sale una lnea que indica su vida en el sistema. Esta lnea simple
se convierte en una lnea gruesa cuando representa que el objeto tiene el foco del sistema,
es decir cuando l est activo.
64
2.2. Proceso Unificado de Desarrollo de Software-P.U.D.S.

El Proceso Unificado de Desarrollo Software o simplemente Proceso
Unificado es un marco de desarrollo de software que se caracteriza por estar
dirigido por casos de uso, centrado en la arquitectura y por ser iterativo e
incremental. El refinamiento ms conocido y documentado del Proceso Unificado
es el Proceso Unificado de Rational o simplemente RUP.
El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo
extensible que puede ser adaptado a organizaciones o proyectos especficos. De
la misma forma, el Proceso Unificado de Rational, tambin es un marco de trabajo
extensible, por lo que muchas veces resulta imposible decir si un refinamiento
particular del proceso ha sido derivado del Proceso Unificado o del RUP. Por dicho
motivo, los dos nombres suelen utilizarse para referirse a un mismo concepto.
El nombre Proceso Unificado se usa para describir el proceso genrico que incluye
aquellos elementos que son comunes a la mayora de los refinamientos
existentes. Tambin permite evitar problemas legales ya que Proceso Unificado
de Rational o RUP son marcas registradas por IBM (desde su compra de Rational
Software Corporation en 2003). El primer libro sobre el tema se denomin, en su
versin espaola, El Proceso Unificado de Desarrollo de Software (ISBN 84-7829036-2) y fue publicado en 1999 por Ivar Jacobson, Grady Booch y James
Rumbaugh, conocidos tambin por ser los desarrolladores del UML, el Lenguaje
Unificado de Modelado. Desde entonces los autores que publican libros sobre el
tema y que no estn afiliados a Rational utilizan el trmino Proceso Unificado,
mientras que los autores que pertenecen a Rational favorecen el nombre de
Proceso Unificado de Rational.
Proceso de desarrollo de software basado en el Lenguaje Unificado de Modelado y que es
iterativo, centrado en la arquitectura y dirigido por los casos de uso y los riesgos. Proceso
que se organiza en cuatro fases: inicio, elaboracin, construccin y transicin, y que se
estructura en torno a cinco flujos de trabajo fundamentales: recopilacin de requisitos,
anlisis, diseo, implementacin y pruebas. Proceso que se describe en trminos de un
modelo de negocio, el cual est a su vez estructurado en funcin de tres bloques de
construccin primordiales trabajadores, actividades y artefactos.
2.2.1. Fases
65
El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto de cuatro

fases denominadas Inicio, Elaboracin, Construccin y Transicin. Cada una de estas fases
es a su vez dividida en una serie de iteraciones (la de inicio slo consta de varias iteraciones
en proyectos grandes). Estas iteraciones ofrecen como resultado un incremento del producto
desarrollado que aade o mejora las funcionalidades del sistema en desarrollo.
Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que recuerdan
a las definidas en el ciclo de vida clsico o en cascada: Anlisis de requisitos, Diseo,
Implementacin y Prueba. Aunque todas las iteraciones suelen incluir trabajo en casi todas
las disciplinas, el grado de esfuerzo dentro de cada una de ellas vara a lo largo del
proyecto.
Fase de Inicio: Primera fase del ciclo de vida del software, en la que la idea inicial para el
desarrollo es refinada hasta el punto de quedar lo suficientemente bien establecida como
para garantizar la entrada en la base de elaboracin.
Fase de Elaboracin: Segunda fase del ciclo de vida, en la que se define la arquitectura.
Fase de Construccin: Tercera fase del ciclo de vida del software, en la que el software es
desarrollado a partir de una lnea base de la arquitectura ejecutable, hasta el punto en el que
se est listo para ser transmitido a las comunidades de usuarios.
Fase de Transicin: Cuarta fase del ciclo de vida del software es puesto en manos de la
comunidad de usuarios.
66
2.2.2. Flujo de Trabajo

Cada fase se subdivide en iteraciones. En cada iteracin se desarrolla en secuencia
Un conjunto de disciplinas o flujos de trabajos.
67
Cada disciplina es un conjunto de actividades relacionadas (flujos de trabajo)

Vinculadas a un rea especfica dentro del proyecto total. Las ms importantes son:
Requerimientos, Anlisis, Diseo, Codificacin, y Prueba.
El agrupamiento de actividades en disciplinas es principalmente una ayuda para
Comprender el proyecto desde la visin tradicional en cascada.
Cada disciplina est asociada con un conjunto de modelos que se desarrollan. Estos
Modelos estn compuestos por artefactos. Los artefactos ms importantes son los
Modelos que cada disciplina realiza: modelo de casos de uso, modelo de diseo,
Modelo de implementacin, y modelo de prueba.
68
El Proceso Unificado consiste en una serie de disciplinas o flujos de trabajo que van
Desde los requisitos hasta las pruebas. Los flujos de trabajo desarrollan modelos
Desde el modelo de casos de uso hasta el modelo de pruebas.
Disciplina Modelos
Requisitos Modelo de Casos de Uso
Anlisis Modelo de Anlisis
Diseo Modelo de Diseo - Modelo de Despliegue
Implementacin Modelo de Implementacin
Prueba Modelo de Prueba
2.2.3. Caractersticas del Modelo

El Proceso Unificado es un proceso de desarrollo de software: conjunto de
Actividades necesarias para transformar los requisitos del usuario en un
Sistema software.
69
RUP es un marco genrico que puede especializarse para una variedad de

Tipos de sistemas, diferentes reas de aplicacin, tipos de organizaciones,
Niveles de aptitud y diferentes tamaos de proyectos.
RUP est basado en componentes. El sw est formado por componentes
Software interconectado a travs de interfaces.
RUP est dirigido por casos de uso, centrado en la arquitectura, y es
Iterativo e incremental.
Dirigido por Casos de Uso
Un caso de uso es un fragmento de funcionalidad del sistema que proporciona
Un resultado de valor a un usuario. Los casos de uso modelan los
Requerimientos funcionales del sistema.
Todos los casos de uso juntos constituyen el modelo de casos de uso.
Los casos de uso tambin guan el proceso de desarrollo (diseo,
Implementacin, y prueba). Basndose en los casos de uso los desarrolladores
Crean una serie de modelos de diseo e implementacin que llevan a cabo los
Casos de uso. De este modo los casos de uso no solo inician el proceso de
Desarrollo sino que le proporcionan un hilo conductor, avanza a travs de una
Serie de flujos de trabajo que parten de los casos de uso.
Centrado en la Arquitectura
La arquitectura de un sistema software se describe mediante diferentes vistas del
Sistema en construccin.
El concepto de arquitectura software incluye los aspectos estticos y dinmicos ms
Significativos del sistema.
La arquitectura es una vista del diseo completo con las caractersticas ms
Importantes resaltadas, dejando los detalles de lado.
Arquitectura: Conjunto de decisiones significativas acerca de la organizacin de un
Sistema software, la seleccin de los elementos estructurales a partir de los cuales se
Compone el sistema, las interfaces entre ellos, su comportamiento, sus
Colaboraciones, y su composicin.
Los casos de uso y la arquitectura estn profundamente relacionados. Los casos de
70
Uso deben encajar en la arquitectura, y a su vez la arquitectura debe permitir el

Desarrollo de todos los casos de uso requeridos, actualmente y a futuro.
El arquitecto desarrolla la forma o arquitectura a partir de la comprensin de un
Conjunto reducido de casos de uso fundamentales o crticos (usualmente no ms del
10 % del total). En forma resumida, podemos decir que el arquitecto:
- Crea un esquema en borrador de la arquitectura comenzando por la
Parte no especfica de los casos de uso (por ejemplo la plataforma) pero
Con una comprensin general de los casos de uso fundamentales.
- A continuacin, trabaja con un conjunto de casos de uso claves o
Fundamentales. Cada caso de uso es especificado en detalle y realizado
En trminos de subsistemas, clases, y componentes.
- A medida que los casos de uso se especifican y maduran, se descubre
Ms de la arquitectura, y esto a su vez lleva a la maduracin de ms
Casos de uso.
Este proceso contina hasta que se considere que la arquitectura es estable.
Iterativo e Incremental
Es prctico dividir el esfuerzo de desarrollo de un proyecto de software en partes mas
Pequeas o mini proyectos.
Cada mini proyecto es una iteracin que resulta en un incremento.
Las iteraciones hace referencia a pasos en el flujo de trabajo, y los incrementos a
Crecimientos en el producto.
Las iteraciones deben estar controladas. Esto significa que deben seleccionarse y
Ejecutarse de una forma planificada.
Los desarrolladores basan la seleccin de lo que implementarn en cada iteracin en
Dos cosas: el conjunto de casos de uso que amplan la funcionalidad, y en los riesgos
Mas importantes que deben mitigarse.
En cada iteracin los desarrolladores identifican y especifican los casos de uso
Relevantes, crean un diseo utilizando la arquitectura seleccionada como gua, para
Implementar dichos casos de uso. Si la iteracin cumple sus objetivos, se contina con
La prxima. Si no deben revisarse las decisiones previas y probar un nuevo enfoque.
71
Beneficios del enfoque iterativo

- La iteracin controlada reduce el riesgo a los costes de un solo incremento.
- Reduce el riesgo de retrasos en el calendario atacando los riesgos ms importantes
Primero.
- Acelera el desarrollo. Los trabajadores trabajan de manera ms eficiente al obtener
Resultados a corto plazo.
- Tiene un enfoque ms realista al reconocer que los requisitos no pueden definirse
Completamente al principio.
2.2.4. Las Cuatro Ps
Personas: Los principales autores de un proyecto de software son los arquitectos,

desarrolladores, ingenieros de prueba, y el personal de gestin que les da soporte,
adems de los usuarios, clientes, y otros interesados. Las personas son realmente
seres humanos, a diferencia del trmino abstracto trabajadores.
Proyecto: Elemento organizativo a travs del cual se gestiona el desarrollo de

software. El resultado de un proyecto es una versin de un producto.
Producto: Artefactos que se crean durante la vida del proyecto, como los modelos,
cdigo fuente, ejecutables, y documentacin.
Proceso: Un proceso de ingeniera de software es una definicin del conjunto de

actividades necesarias para transformar los requisitos de usuario en un producto. Un
proceso es una plantilla para crear proyectos.
2.2.5. Flujo de Trabajo (Requisitos y Anlisis)

Fase de captura de requisitos
La captura de requisitos es el acto de descubrir y averiguar, normalmente en situaciones
difciles, lo que se debe construir.
72
Artefactos de requisitos
Los artefactos fundamentales en la captura de requisitos son: el modelo de casos de uso,
que incluye los casos de uso y los actores, la descripcin de la arquitectura, el glosario y el
prototipo de la interfaz de usuario.
Artefactos:
Modelo de casos de uso: permite a los desarrolladores de software y a los clientes

que lleguen a un acuerdo sobre los requisitos que debe cumplir el sistema. Un modelo
de casos de uso contiene actores, casos de uso y las relaciones que existen entre s.
o
Actor: el modelo de casos de uso describe lo que hace el sistema para cada
tipo de usuario. Cada uno de estos usuarios se representa por medio de un
actor. Un sistema externo es considerado tambin un actor que interacta con
el sistema. Los actores representan a terceros que interactan con el sistema.
Un actor juega un papel por cada caso de uso con el que colabora.
Casos de uso: un caso de uso describe cmo utilizar el sistema por parte de
los actores. Los casos de uso especifican una secuencia de acciones que el
sistema puede llevar a cabo incluyendo las alternativas dentro de la secuencia.
Un caso de uso puede especificarse con diagramas de estados, diagramas de
actividad,... Una instancia de un caso de uso es la realizacin de un caso de
73
uso. Cuando se lleva a cabo una instancia de un caso de uso se ejecuta una
serie de acciones, algunas de las cuales pueden tener caminos alternativos.
Descripcin de la arquitectura: contiene una vista de la arquitectura del modelo de

casos de uso, que representa los casos de uso significativos para la arquitectura. La
vista de la arquitectura debera incluir aquellos casos de uso que describan alguna
funcionalidad importante o crtica, o que impliquen algn requisito importante.
Glosario: es importante utilizar un glosario de trminos comunes para describir el

sistema y as alcanzar un consenso entre los desarrolladores.
Prototipo de interfaz de usuario: los prototipos de interfaz de usuario nos ayudan a

comprender y especificar las interaccione entre actores humanos y el sistema.
Flujos de trabajo de la captura de requisitos

A continuacin se presenta el flujo de trabajo de la captura de requisitos mediante un
diagrama de actividad.
El analista de sistemas se encarga de encontrar actores y casos de uso en funcin de tres

artefactos de entrada: el modelo de negocio, los requisitos adicionales y la lista de
caractersticas. A partir de stos genera un esbozo del modelo de casos de uso y el glosario
de trminos.
74
El arquitecto se encarga de priorizar los casos de uso en funcin de tres artefactos de

entrada: el modelo de negocio, los requisitos adicionales y el glosario de trminos. A partir de
stos genera la descripcin de la arquitectura.
El especificador de casos de uso se encarga de detallar los casos de uso en funcin de tres
artefactos de entrada: el modelo de casos de uso, los requisitos adicionales y el glosario de
trminos. A partir de stos genera los casos de uso detallados.
El diseador de la interfaz se encarga de prototipar la interfaz de usuario en funcin de
cuatro artefactos de entrada: el modelo de casos de uso, los requisitos adicionales, los
casos de uso detallados y el glosario de trmino. A partir de stos genera el prototipo de la
interfaz de usuario.
Finalmente, el analista de sistemas se encarga de estructurar el modelo de casos de uso en
funcin de cuatro artefactos de entrada: el modelo de casos de uso, los requisitos
adicionales, los casos de uso detallados y el glosario de trminos. A partir de stos genera el
modelo de casos de uso estructurado.
Fase de anlisis
Durante la fase de anlisis, analizamos los requisitos que se describieron en la captura de
requisitos, refinndolos y estructurndolos. El objetivo es conseguir una mayor comprensin
de los requisitos que nos ayude a estructurar el sistema entero. La diferencia primordial con
la captura de requisitos radica en que en esta fase podemos utilizar el lenguaje de los
desarrolladores. En la fase de anlisis se trabaja con conceptos y se crea una primera
aproximacin al modelo de diseo.
A continuacin se muestra una breve comparativa entre el modelo de casos de uso y el
modelo de anlisis.
75
Modelo de Casos de Uso
Modelo de Anlisis
Lenguaje del cliente
Lenguaje del desarrollador
Vista externa del sistema
Vista interna del sistema
Estructurado por casos de uso
Estructurado por clases y paquetes
Contrato entre cliente-desarrollador
Usado por desarrolladores
Redundancias, inconsistencias,...
No debera contener redundancias
Captura la funcionalidad del sistema Captura cmo realizar la funcionalidad

Define casos de uso
Define realizaciones de casos de uso
Artefactos de anlisis
Los artefactos fundamentales de la fase de anlisis son: el modelo de anlisis, la descripcin
de la arquitectura, la realizacin de los casos de uso-anlisis, clase de anlisis y el paquete
de anlisis.
Artefactos:
Modelo de anlisis: es una jerarqua de paquetes de anlisis que contienen clases de

anlisis y realizaciones de casos de uso.
Clases de anlisis: se centran en el tratamiento de los requisitos funcionales y

pospone los no funcionales. Son ms evidentes en el dominio del problema. Sus
atributos, operaciones y relaciones estn a un nivel mayor de abstraccin. Pueden
clasificarse fcilmente en clases de entidad, interfaz y control.
76
Paquetes de anlisis: son un medio para organizar los artefactos del modelo de
anlisis en piezas manejables. Son cohesivos y dbilmente acoplados. Basados en
requisitos funcionales y en el dominio del problema.
Realizacin de casos de uso-anlisis: define como se lleva a cabo y se ejecuta un

caso de uso en trmino de clases de anlisis y de sus objetos de anlisis. Quedan
definidos por: diagramas de clases de anlisis, diagramas de interaccin de objetos
de anlisis y una descripcin textual del flujo de sucesos.
77
Diagrama de clases:
Diagrama de colaboracin:
3. Modelo de Diseo
3.1. Identificar Clases
Postulante
78
-CodigoPos
-CI
-Sexo
-Nacionalidad
-Telefono
-Celular
1.- Postulante.-
Esta clase contendr los datos principales de la persona que desea ser
profesor del Programa De Admisin Bsica, as como los requisitos que exige el Programa
de Admisin Bsica de la Universidad Autnoma Gabriel Ren Moreno.
2.- Estado
de Seleccin.- Es la clase que Permitir Saber Si El
Docente postulante esta Seleccionado para Dictar Clases en el

Programa De Admisin Bsica.
3.- Hoja
de Vida.- Es la clase que permite saber La Experiencia Del
Docente, sus horarios Disponibles, Si ya trabajo en el Programa De

Admisin Bsica.
4.- Ponderacin.-
Esta Clase Permite Evaluar De Forma Superficial
pero eficazmente la al Docente De Tal Forma Que Tiene Cierto

Puntaje Dependiendo de las Caractersticas de Su hoja de vida.
5.- Experiencia.-
Esta Clase permite Saber Ciertas Caractersticas
sobre los aos de experiencia de los docentes y la ponderacin que

merecen de acuerdo a los mismos.
6.- Tipo
de Formacin.- En esta clase se encuentra el tipo de
-Cod_Est_Sel
-Nom_Est_Sel
-Caracteristicas
Hoja de Vida
-Cod_Hoja
-Fecha_ingreso
+
Ponderacion
+Cod_Puntaje
+PUntaje
Experiencia
+Puesto
+Tiempo
Tipo de Formacion
+Cod_Tipo
+Nombre
formacin de docente.
7.- Formacin.-
Estado de seleccion
En Esta clase intermedia en la clase tipo formacin
y hoja de vida donde solo se guarda una observacin sobre la

Formacin del docente postulante al programa de Admisin Bsica.
79
Grado
+Cod_Grado
+Nom_Grado
Formacion
+Obs
8.- Grado.-
Esta Clase almacena el grado Que ha alcanzado el
Docente a lo largo de su formacin Profesional.
9.- Estado
de Formacin.- Esta Clase Guarda los nombres de
estados de formacin que tenga cada Docente que pretenda dar

cursos del Programa de Admisin Bsica.
10.- Profesor.-
Estado de Formacion
los
+Cod_Estado
+Nom_Estado
los
Esta clase almacena la lista de Cdigos de los
Profesor
docentes asignados en la presente Gestin.
11.- Prof_Mat_Hor.-
+Cod_Profe
Esta clase especifica la materia y
El horario, que ser asignado a cada uno De los
Prof_ Mat_ Hor

+IdDicta
Profesores Con cdigo asignado para dictar cursos en el

Programa de admisin Bsica.
12.- Materia.-
Esta Clase Contiene LA lista De materias que
+IdAsignatura
+Sigla
se van a dictar en el curso del PAB

13.- rea.-
Materia
Esta Clase especifica las reas que Comprende el Programa
Admisin Bsica
14.- Disponibilidad.-
En esta clase se especifica la disponibilidad de cada
docente que postula para dictar un Curso en el Programa de admisin
Area
+IdArea
+descripcion
Disponibilidad
+Turno
Bsica
Horario
+IdHorario
+Estado
80
de
15.- Horario.-
En esta clase se muestra el Horario que tiene disponible cada docente para
poder ser analizado y procesado para programar los horarios para las clases Del PAB
16.- Da.-
Esta clase especificara que das tiene libre cada docente que Dictara Los cursos en
el Programa de admisin Bsica
Dia
+Ide_Dia
+Descripcion
17.- Aula_Turno_Grupo.-
Esta clase especificara cada aula en cada
+Id_Aula_Turno_Grupo
+Capacidad
turno Programado Pro Grupo
18.- Turno.-
En esta Clase se encuentran los turnos disponibles de los
docentes que van a dictar los cursos del Programa de Admisin

Bsica.
19.- Hora.-
En esta Clase se especifican las Horas disponibles de los
docentes que van a dictar los cursos del Programa de Admisin

Bsica.
20.- Aula.-
En esta clase estn todas las Aulas Disponibles para ser
programadas en diferentes Grupos para los docentes que vayan a

los cursos en el Programa de admisin Bsica.
21.- Grupo.-
Aula_ Turno_ Grupo
En esta Clase se encuentran Los Grupos Que se irn
Turno
+Id_Turno
+Descripcion
+Estado
Hora
+IdHora
+HoraInicio
+HoraFin
Aula
+Id_Aula
+Descripcion
+Estado
Grupo
+IdGrupo
+Descripcion
+Estado
Creando Luego de la seleccin de docentes
Gestion
+IdGestion
+FechaInicio
+FechaCierre
+Habilitado
+Estado
81
dictar
22.- Gestin.-
En esta Clase Se Especifica La Gestin que se est llevando a cabo ya Sea
PAB de Verano o PAB de Invierno, Las Fechas de Inicio y Fin de los Mismos Y desde
Cuando Estn Habilitadas las Clases.
23.- Periodo.-
En esta clase se especifica que periodos estn Habilitados en las Gestiones

Periodo
hechas en el Programa de Admisin Bsica.
24.- Modulo.-
+Id_Peridodo
+Nombre
+Estado
En Esta Clase Se especfica los mdulos donde estarn
Las Aula para un mismo grupo durante el transcurso del periodo

Habilitado para la gestin del Programa
Modulo
+NroModulo
+Ubicacion
De Admisin Bsica.
3.2. Identificar Conexin de Instancia

Las conexiones de instancia entre clases serian:
Las clases 1 y 2 tienen una relacin de Asociacin con un rol posee y una
cardinalidad de 1 a 0..*.
Las clases 1 y 3 tienen una relacin de Asociacin con un rol presenta y una
cardinalidad de 1 a 1.
Las clases 1 y 10 tienen una relacin de Asociacin con un rol es y una

Las clases 3 y 4 tienen una relacin de Asociacin con un rol tiene y una
82
Las clases 3 y 5 tienen una relacin de Asociacin con un rol basada y una
cardinalidad de 0..1 a 0..*.
Las clases 3 y 6 tienen una relacin de Asociacin con un rol existe y una
cardinalidad de * a 1..* es por esto que se crea una relacin intermedia la 7.
cardinalidad de * a 1.
cardinalidad de * a 1..*.
Las clases 10 y 11 tienen una relacin de Asociacin con un rol asignado y una
Las clases 11 y 12 tienen una relacin de Asociacin con un rol asignada y una
Las clases 11 y 15 tienen una relacin de Composicin con un rol posee y una
Las clases 15 y 16 tienen una relacin de Asociacin con un rol basado y una
Las clases 15 y 17 tienen una relacin de Asociacin con un rol asignado y una
Las clases 17 y 18 tienen una relacin de Asociacin con un rol forma y una
Las clases 17 y 22 tienen una relacin de Asociacin con un rol crea y una
83
Las clases 24 y 20 tienen una relacin de Composicin con un rol tiene y una
Las clases 21 y 13 tienen una relacin de Asociacin con un rol pertenece y una
3.3 Diagrama de Dominio
84
3.4. Construccin de la Base de Datos

3.4.1. Diseo Lgico
3.4.1.1. Diagrama de Clases
85
3.4.1.2 Mapeo
ESTADO DE SELECCION
Cod_Est_Sel Nom_Est_Sel Caractersticas
P.K.
HORA
Id_Hora
HoraInicio
HoraFin
P.K.
DIA
Id_Dia
Descripcin
86
P.K.
MATERIA
Id_Materia
Nombre_mat
Sigla
Estado
P.K.
POSTULANTE
Cod_Pos CI Sexo Nacionalidad Telf
Cel
Email
Cod_Est_Sel
P.K.
F.K.
DISPONIBILIDAD
Cod_Disponibilidad
ID_Hora
P.K.
GRADO
Cod_Grado
F.K.
Id_Mat
Cod_Pos
F.K.
Nombre_Grado
P.K.
ESTADO DE FORMACION
Cod_Estado Nombre_Estado
P.K.
TIPO_FORMACION
Cod_Tipo
Nombre
87
F.K.
Id_Dia
P.K
HOJA_VIDA
Cod_Hoja_Vida
Fecha_Ingreso
Cod_Pos
P.K.
F.K.
EXPERIENCIA
Cod_Exp
Tiempo
Cod_Hoja_Vida
P.K.
F.K.
FORMACION
Cod_Hoja_Vida Cod_Tipo Observacion Cod_Grado Cod_Estado
P.K.
F.K.
P.K.
F.K.
F.K.
PONDERACION
Cod_Ponderacion Promedio Cod_Hoja_Vida
P.K.
F.K.
PROFESOR
Cod_Prof Cod_Hoja_Vida
P.K.
F.K
88
F.K.
GRUPO
ID_Grupo
Descripcin
Estado
P.K.
AREA
ID_Area
Descripcin
P.K.
GESTION
ID_Gestion
Fecha_Inicio
Fecha_Fin
Habilitado
P.K.
PERIODO
ID_Periodo
Nombre
Estado
P.K.
ID_Gestion
F.K.
TURNO
ID_Turno Descripcin Estado
P.K.
MODULO
89
Estado
Nro_Modulo Ubicacion Observacion

F.K.
AULA
ID_Aula
P.K.
F.K.
Nro_Modulo
Descripcin
P.K.
F.K.
PROF_MAT_HOR
ID_Dicta
Cod_Profesor
F.K
HORARIO
ID_Horario Id_Aula_turno_Grup
o
P.K.
Tipo
Capacidad
P.K.
F.K.
AULA_TURNO_GRUPO
ID_Aula_Turno_Grup ID_Grup
o
o
P.K.
Estado
ID_Gestio
n
Nro_Modulo
F.K.
F.K.
ID_Horario
F.K.
Estado
ID_Turno
F.K.
90
ID_Mat
F.K.
ID_Dia
P.K.
F.K.
ID_Hora
F.K.
F.K.
3.4.2. Diseo Fsico

3.4.2.1. Tabla de volumen
ESTADO DE SELECCION
ATRIBUTOS
TIPOS_DE_DATOS
Cod_Est_Sel
Entero
LONGITUD
4
NULO LLAVE
No
P.K.
Nom_Est_Sel
Carcter
20
No
Caractersticas Carcter
50
No
HORA
ATRIBUTOS
ID_Hora
TIPOS_DE_DATOS
Entero
LONGITUD
4
NULO
No
LLAVE
P.K.
HoraInicio
HoraFin
Tiempo
Tiempo
No
No
91
DESCRIPCION
Identificador de
Estado de
seleccin
Nombre del
Estado de
seleccin
Caractersticas del
estado
DESCRIPCION
Identificador de
la hora
Hora de inicio
Hora de
finalizacin del
periodo
DIA
ATRIBUTOS
ID_Dia
TIPOS_DE_DATOS
Entero
LONGITUD
4
NULO
No
LLAVE
P.K.
Descripcin
Carcter
50
No
MATERIA
ATRIBUTOS
ID_Materia
TIPOS_DE_DATOS
Entero
LONGITUD
4
NULO
No
LLAVE
P.K.
Nombre_Mat
Carcter
20
No
Sigla
Carcter
No
Estado
Carcter
No
POSTULANTE
ATRIBUTOS
TIPOS_DE_DATOS
Cod_Pos
Entero
LONGITUD
10
NULO
No
LLAVE
P.K.
CI
Entero
No
Sexo
Carcter
No
Nacionalidad
Carcter
20
No
Telf
Entero
Si
Cel
Email
Entero
Carcter
8
30
Si
Si
Cod_Est_Sel
Entero
No
DISPONIBILIDAD
ATRIBUTOS
TIPOS_DE_DATOS
ID_disponobilidad Entero
LONGITUD
4
92
F.K.
NULO LLAVE
No
P.K.
DESCRIPCION
Identificador de
dia
Nombre del dia
DESCRIPCION
Identificador de
la materia
Nombre de la
materia
Sigla de la
materia
Estado de la
materia
DESCRIPCION
Identificador de
un postulante
Carnet de
identidad
Sexo del
postulante
Describe la
nacionalidad
Nro Telf fijo del
postulante
Nro de celular
Correo
electronico
Identificador de
estado de
seleccin
DESCRIPCION
Identificador de
disponibilidad
Id_Hora
Entero
No
F.K.
Id_Mat
Entero
No
F.K.
Cod_Pos
Entero
No
F.K.
Id_dia
Entero
No
F.K.
GRADO
ATRIBUTOS
Cod_Grado
TIPOS_DE_DATOS
Entero
Nombre_Gardo Carcter
LONGITUD
4
NULO LLAVE
No
P.K.
20
No
ESTADO FORMACION
ATRIBUTOS
TIPOS_DE_DATOS
Cod_Estado
Entero
LONGITUD
4
NULO LLAVE
No
P.K.
Nomb_Estado Carcter
20
No
TIPO FORMACION
ATRIBUTOS TIPOS_DE_DATOS
Cod_Tipo
Entero
LONGITUD
4
NULO LLAVE
No
P.K.
Nombre
50
No
Carcter
Identificador de
hora
Identificador de
materia
Identificador de
postulante
Identificador de
dia
DESCRIPCION
Identificador de
grado
Fecha de Entrega
del Pedidos
DESCRIPCION
Identificador de
estado
Nombre del estado
DESCRIPCION
Identificador de tipo
de formacin
Nombre de la
formacin
HOJA DE VIDA
ATRIBUTOS
TIPOS_DE_DATOS
Cod_Hoja_Vida Entero
LONGITUD
4
NULO LLAVE
No
P.K.
Fecha_Ingreso
Fecha
No
Cod_Pos
Entero
20
No
TIPOS_DE_DATOS
LONGITUD
NULO LLAVE
DESCRIPCION
Identificador de
hoja de vida
Fecha de ingreso
de la hoja de vida
Identificador del
postulante
EXPERIENCIA
ATRIBUTOS
93
DESCRIPCION
Cod_Exp
Entero
No
Tiempo
Entero
No
20
No
ATRIBUTOS
TIPOS_DE_DATOS
Cod_Hoja_vida Entero
LONGITUD
4
NULO LLAVE
No
P.K.
Cod_Tipo
Entero
No
P.K.
Observacion
Carcter
20
No
F.K
Cod_Grado
Entero
No
F.K
Cod_Estado
Entero
No
F.K
Cod_Hoja_Vida Carcter
P.K.
Identificador de
experiencia
Tiempo o aos de
experiencia
Identificador de
hoja de vida
F.K
FORMACION
DESCRIPCION
Identificador de
hoja de vida
Identificador de
tipo de formacin
Observacin
sobre formacin
Identificador de
grado
Identificador de
estado de
formacin
PONDERACION
ATRIBUTOS
TIPOS_DE_DATOS
Cod_Ponderacion Entero
LONGITUD
4
NULO LLAVE
No
P.K.
Promedio
entero
No
Cod_hoja_Vida
Entero
20
No
F.K
DESCRIPCION
Identificador de
ponderacin
Promedio del
postulante
Identificador de
hoja de vida
PROFESOR
ATRIBUTOS
Id_Prof
TIPOS_DE_DATOS
Entero
LONGITUD
4
NULO LLAVE
No
P.K.
Cod_pos
Fecha
No
ATRIBUTOS
Id_Grupo
TIPOS_DE_DATOS
Entero
LONGITUD
4
NULO LLAVE
No
P.K.
Descripcin
Carcter
50
No
Estado
AREA
Carcter
No
F.K
DESCRIPCION
Identificador de
profesor
Identificador de
postulante
GRUPO
94
DESCRIPCION
Identificador de de
grupo
Descripcin del
grupo
Estado del grupo
ATRIBUTOS
Id_Area
TIPOS_DE_DATOS
Entero
LONGITUD
4
NULO LLAVE
No
P.K.
Descripcin
Carcter
30
No
ATRIBUTOS
Id_Gestion
TIPOS_DE_DATOS
Entero
LONGITUD
4
NULO LLAVE
No
P.K.
Fecha_Incio
Fecha
No
Fecha_Fin
Fecha
No
Habilitado
Estado
Carcter
Carcter
10
10
No
No
ATRIBUTOS
ID_Periodo
TIPOS_DE_DATOS
Entero
LONGITUD
4
NULO LLAVE
No
P.K.
Nombre
Estado
Id_gestion
Carcter
Carcter
Entero
20
20
4
No
No
No
ATRIBUTOS
Id_Turno
TIPOS_DE_DATOS
Entero
LONGITUD
4
NULO LLAVE
No
P.K.
Descripcion
Carcter
20
No
Estado
Carcter
No
TIPOS_DE_DATOS
LONGITUD
NULO LLAVE
DESCRIPCION
Identificador de de
rea
Nombre de rea
GESTION
DESCRIPCION
Identificador de de
gestin
Fecha de inicio de
la gestin
Fecha de fin de la
gestin
Gestin habilitada
Estado de gesstion
PERIODO
F.K
DESCRIPCION
Identificador de
periodo
Nombre del periodo
Estado del periodo
Identificador de
gestion
TURNO
DESCRIPCION
Identificador de
turno
Descripcin del
turno
Estado del turno
MODULO
ATRIBUTOS
95
DESCRIPCION
Nro_Modulo
Entero
No
P.K.
Ubicacin
Carcter
30
No
Observacin
Carcter
20
No
ATRIBUTOS
IDCompra
Nro_modulo
TIPOS_DE_DATOS
Entero
Entero
LONGITUD
4
4
NULO LLAVE
No
P.K.
No
P.K.
Descripcin
Estado
Tipo
Capacidad
Carcter
Carcter
Carcter
Carcter
20
2
10
3
No
No
No
No
Identificador de
modulo
Ubicacin del
modulo
Describe el tipo de
modulo
AULA
DESCRIPCION
Identificador de aula
Identificador de
modulo
Descripcin del aula
Estado del aula
Tipo de aula
Capacidad del aula
AULA_TURNO_GRUPO
ATRIBUTOS
TIPOS_DE_DATOS
ID_Aula_Turno_Grupo Entero
LONGITUD NULO LLAVE

4
No
P.K.
Nro_modulo
Entero
No
F.K.
Id_grupo
Entero
No
F.K.
Id_gestion
Entero
No
F.K.
Id_turno
Entero
No
F.K.
DESCRIPCION
Identificador de
aula_turno_grupo
Identificador de
modulo
Identificador de
grupo
Identificador de
gestin
Identificador de
turno
PROF_MAT_HOR
ATRIBUTOS
Id_dicta
TIPOS_DE_DATOS
Entero
LONGITUD
4
NULO LLAVE
No
P.K.
Cod_prof
Entero
No
F.K.
Id_horario
Entero
No
F.K.
96
DESCRIPCION
Identificador de
prof_mat_hor
Identificador de
profesor
Identificador de
horario
Id_mat
Entero
No
F.K.
Identificador de
materia
HORARIO
ATRIBUTOS
Id_Horario
TIPOS_DE_DATOS
Entero
LONGITUD NULO LLAVE

4
No
P.K.
Id_dicta
Entero
46
No
F.K.
Estado
Id_Hora
Carcter
Entero
2
4
No
No
F.K.
Id_Dia
Entero
No
F.K.
Id_Aula_turno_Grup
o
Entero
No
F.K.
DESCRIPCION
Identificador de
horario
Identificador de
prof_mat_hor
Estado el horario
Identificador de
hora
Identificador de
da
Identificador de
aula_turno_grupo
3.4.2.2. Script
CREATE DATABASE [PAB]
Use [PAB]
CREATE TABLE [dbo].[Area] (
[Id_Area] [int] NOT NULL ,
[Descripcion] [varchar] (20) COLLATE Modern_Spanish_CI_AS NOT NULL
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[Aula_Turno_Grupo] (
[Id_Aula_Turno_Grupo] [int] NOT NULL ,
[Id_Grupo] [varchar] (5) COLLATE Modern_Spanish_CI_AS NOT NULL ,
[Id_Gestion] [int] NOT NULL ,
[Id_Aula] [int] NOT NULL ,
[Id_Turno] [char] (1) COLLATE Modern_Spanish_CI_AS NOT NULL ,
[Id_Modulo] [int] NOT NULL
) ON [PRIMARY]
GO
97
CREATE TABLE [dbo].[Aula] (

[Id_Aula] [int] NOT NULL ,
[Id_Modulo] [int] NOT NULL ,
[Descripcion] [varchar] (20) COLLATE Modern_Spanish_CI_AS NOT NULL ,
[capacidad] [int] NOT NULL ,
[Estado] [char] (1) COLLATE Modern_Spanish_CI_AS NOT NULL
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[Dia] (
[Id_Dia] [int] NOT NULL ,
[Descripcion] [varchar] (20) COLLATE Modern_Spanish_CI_AS NOT NULL
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[Disponibilidad] (
[Cod_Disponibilidad] [int] NOT NULL ,
[Id_Hora] [int] NOT NULL ,
[Id_Materia] [int] NOT NULL ,
[Id_Postulante] [int] NOT NULL ,
[Id_Dia] [int] NOT NULL
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[Estado_Formacion] (
[Cod_Estado] [int] NOT NULL ,
[Nombre_Estado] [varchar] (20) COLLATE Modern_Spanish_CI_AS NOT NULL
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[Estado_Seleccion] (
[Cod_Est_Sel] [int] NOT NULL ,
[Nom_Est_Sel] [varchar] (50) COLLATE Modern_Spanish_CI_AS NOT NULL ,
[Caracteristicas] [varchar] (50) COLLATE Modern_Spanish_CI_AS NOT NULL
98
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[Experiencia] (
[Cod_Exp] [int] NOT NULL ,
[Tiempo] [varchar] (40) COLLATE Modern_Spanish_CI_AS NOT NULL ,
[Cod_Hoja_Vida] [int] NOT NULL
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[Formacion] (
[Cod_Hoja_Vida] [int] NOT NULL ,
[Cod_Tipo] [int] NOT NULL ,
[Observacion] [varchar] (40) COLLATE Modern_Spanish_CI_AS NOT NULL ,
[Cod_Grado] [int] NOT NULL ,
[Cod_Estado] [int] NOT NULL
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[Gestion] (
[Id_Gestion] [int] NOT NULL ,
[Fecha_Inicio] [datetime] NOT NULL ,
[Fecha_Fin] [datetime] NOT NULL ,
[Habilitado] [char] (1) COLLATE Modern_Spanish_CI_AS NOT NULL ,
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[Grado] (
[Id_Grado] [int] NOT NULL ,
[Nombre_Grado] [varchar] (20) COLLATE Modern_Spanish_CI_AS NOT NULL
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[Grupo] (
[Id_Grupo] [varchar] (5) COLLATE Modern_Spanish_CI_AS NOT NULL ,
99
[Id_Area] [int] NOT NULL ,

[Estado] [bit] NOT NULL
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[Hoja_Vida] (
[Cod_Hoja_Vida] [int] NOT NULL ,
[Fecha_Ingreso] [datetime] NULL ,
[Cod_Pos] [int] NULL
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[Hora] (
[Hora_Inicio] [datetime] NOT NULL ,
[Hora_Fin] [datetime] NOT NULL
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[Horario] (
[Id_Horario] [int] NOT NULL ,
[Id_Dicta] [int] NOT NULL ,
[Estado] [char] (1) COLLATE Modern_Spanish_CI_AS NOT NULL ,
[Id_Dia] [int] NOT NULL ,
[Id_Aula_Turno_Grupo] [int] NOT NULL
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[Materia] (
[Id_Materia] [int] NOT NULL ,
[Nombre_Materia] [varchar] (20) COLLATE Modern_Spanish_CI_AS NOT NULL ,
[Sigla] [varchar] (3) COLLATE Modern_Spanish_CI_AS NOT NULL ,
) ON [PRIMARY]
100
GO
CREATE TABLE [dbo].[Modulo] (
[Nro_Modulo] [int] NOT NULL ,
[Ubicacion] [varchar] (40) COLLATE Modern_Spanish_CI_AS NOT NULL ,
[Observacion] [varchar] (40) COLLATE Modern_Spanish_CI_AS NOT NULL
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[Periodo] (
[Id_Periodo] [varchar] (3) COLLATE Modern_Spanish_CI_AS NOT NULL ,
[Nombre] [varchar] (40) COLLATE Modern_Spanish_CI_AS NOT NULL ,
[Estado] [char] (1) COLLATE Modern_Spanish_CI_AS NOT NULL ,
[Id_Gestion] [int] NOT NULL
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[Ponderacion] (
[Cod_Ponderacion] [int] NOT NULL ,
[Promedio] [int] NULL ,
[Cod_Hoja_Vida] [int] NULL
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[Postulante] (
[Cod_Postulante] [int] NOT NULL ,
[CI] [int] NULL ,
[Procedencia CI] [char] (3) COLLATE Modern_Spanish_CI_AS NULL ,
[Apellidos] [varchar] (40) COLLATE Modern_Spanish_CI_AS NULL ,
[Nombres] [varchar] (40) COLLATE Modern_Spanish_CI_AS NULL ,
[Sexo] [char] (1) COLLATE Modern_Spanish_CI_AS NULL ,
[Nacionalidad] [varchar] (20) COLLATE Modern_Spanish_CI_AS NULL ,
[Telefono] [int] NULL ,
[Celular] [int] NULL ,
101
[Direccion] [varchar] (50) COLLATE Modern_Spanish_CI_AS NULL ,

[Email] [varchar] (50) COLLATE Modern_Spanish_CI_AS NULL ,
[Cod_Est_Sel] [int] NULL
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[Profesor] (
[Cod_Prof] [int] NOT NULL ,
[Cod_Postulante] [int] NOT NULL
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[Profesor_Materia_Horario] (

[Id_Dicta] [int] NOT NULL ,
[Cod_Prof] [int] NOT NULL ,
[Id_Materia] [int] NOT NULL
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[Tipo_Formacion] (
[Cod_Tipo] [int] NOT NULL ,
[Nombre] [varchar] (20) COLLATE Modern_Spanish_CI_AS NOT NULL
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[Turno] (
[Id_Turno] [char] (1) COLLATE Modern_Spanish_CI_AS NOT NULL ,
[Descripcion] [varchar] (50) COLLATE Modern_Spanish_CI_AS NOT NULL ,
) ON [PRIMARY]
102
GO
3.4.2.3. Diagrama Relacional
3.5. Manipulacin de Tuplas

3.6. Consultas
3.7. Procedimientos Almacenados
103
3.5 Manipulacin de Tuplas

Insercin De Datos
INSERT INTO POSTULANTE
VALUES('100000','3874902','SCZ','AbalColumba','Jhonny','M','Boliviana',null,'73141860','C
/manuelignaciosalvatierra#929','jhonny_columba@hotmail.com','1');
VALUES('100001','4583035','SCZ','AcebedoChoque','CintiaLorena','F','Boliviana','3622221'
,'70068445','B/Cordecruz/C#2-4to/Anillo','cinlorace@yahoo.com','1');
VALUES('100002','5411130','SCZ','AguileraCernandes','Jhonny','M','Boliviana','3580427','7
0283101','B-lasvegas/C-11','jonny-inge@hotmail.com','1');
VALUES('100003','6302745','SCZ','AguileraMontenegro','Rosa','F','Boliviana','3582263','70
201404','B-Caadaelcarmen/C#10','rosita0075hotmail.com','1');
VALUES('100004','3833139','SCZ','AlbaMontero','Nancy','F','Boliviana','3503840','7265912
9','Av:Santosdumont','nancyalba@hotmail.com','1');
104

VALUES('100005','5342447','SCZ','AlconSaldias','Alex','M','Boliviana','3511283','79475792'
,'C/Destacamento132#3705','alico97@gmail.com','1');
VALUES('100006','5873900','SCZ','AlfaroBarba','LuisFernando','M','Boliviana',null,'798791
69','C/diegoconteras#75','fer-ab@hotmail.com','1');
VALUES('100007','3827110','SCZ','AliagaHoward','HellenGigliola','F','Boliviana','3471909','
70883626','Av:mutualista/C-tiluchi#2100','hellen_aliaga@hotmail.com','1');
VALUES('100008','4732142','SCZ','AlizaresZumoya','Richard','M','Boliviana','3495870','721
61547','B/24dejunio','pepih_2008@hotmail.com','1');
VALUES('100009','4703941','SCZ','AnaguaLopez','Felipe','M','Boliviana',null,'71666128','B/
NuevaJerusalenC/SanPedro#28','anagual@hotmail.com','1');
VALUES('100010','3207266','SCZ','AndiaSalces','Jorge','M','Boliviana','3203660','7716454
5','Urb-Espaa/C-belen','jorgearmengo@hotmail.com','1');
VALUES('100011','3206716','SCZ','AnteloAguilera','DeisyZulema','F','Boliviana','3424327','
70442642','Av:Beni/C-Tajibo#6010','deisiantelo@uagrm.edu.com','1');
VALUES('100012','4588773','SCZ','AntezanaOvando','AlexAdy','M','Boliviana',null,'760900
09',null,'alex.antezana@gmail.com','1');
VALUES('100013','2335451','LPZ','AranaGonzales','RodolfoErasmo','M','Boliviana','354482
6','77672577','AvPirai#343','rodolfoarana@gmail.com','1');
VALUES('100014','3918952','SCZ','ArancibiaAguilera','Matilde','F','Boliviana',null,'7900812
5','Urbtarope#2',null,'1');
VALUES('100015','4678838','SCZ','ArancibiaAnagua','lisethpatricia','F','Boliviana','3544177
','70868685','B/4denoviembrec/9#3300','paranabia2008@gmail.com','1');
VALUES('100016','1056295','CHS','ArceLara','MariaRosilde','F','Boliviana','3322166','7082
3443','MgnacioSalvatierra#569','rosildearce@hotmail.com','1');
VALUES('100017','3879016','SCZ','ArceRibera','JoannaPaola','F','Boliviana','3506640','709
79029','Urb/Paititi#6365',null,'1');
105

VALUES('100018','3275762','SCZ','ArezConcha','ElhidPaul','M','Boliviana','3503840','726
57700','Urb/Elpalmar','eparnez@hotmail.com','1');
VALUES('100019','5337961','SCZ','ArteagaAyala','Amelia','F','Boliviana','3507208','726129
09','Av.Centenario/Cterebinto#165','amelart@hotmail.com','1');
VALUES('100020','7660119','SCZ','ArteagaOrtiz','LuisFernando','M','Boliviana',null,'708608
05',null,'fer_art_ort@gmail.com','1');
VALUES('100021','3646756','CHS','AvendaoGonzales','DorisMargoth','F','Boliviana','3622
221','77685380','B/15deseptiembre/C-11#23','margoth_1016@hotmail.com','1');
VALUES('100022','2809141','SCZ','BalboaSalvatierra','Betty','F','Boliviana','3585758','7310
6864','Urb/ElPalmar/C-3#15','6balboa@hotmail.com','1');
VALUES('100023','2991032','SCZ','BarbaChavez','Ricardo','M','Boliviana','3496288','70052
414',null,'mariorichar_47@hotmail.com','1');
VALUES('100024','2974313','SCZ','BarbaPaz','MariaHelen','F','Boliviana','3564176','70284
626',null,'helenbarbapaz@hotmail.com','1');
VALUES('100025','3234916','SCZ','BejaranoSuarez','MariaAlejandra','F','Boliviana','364648
5','77690211','B/lostusequis/C-conred#5040','m_alejandrabs@hotmail.com','1');
VALUES('100026','3184059','SCZ','BurgoaMolina','AlfonsoCarlos','M','Boliviana','3200079','
70927810','Urb/Patuju/Closjasmines#34','carlosbm@hotmail.com','1');
VALUES('100027','2376745','LPZ','BustillosCoritza','Rodolfocarlos','M','Boliviana','3332025'
,'70827192','C/Buenosaires#300','rodolfo_bustillo@hotmail.com','1');
VALUES('100028','2376744','SCZ','BustillosCoritza','Vladimircarlos','M','Boliviana','333202
5','70283348','C/Buenosaires#300','vladimir_bustillos@hotmail.com','1');
VALUES('100029','4690829','SCZ','CalvoLara','JorgeFidel','M','Boliviana','3532470','71042
114','B-lamorita/C-domingoavila#3050','jorge-fcl@hotmail.com','1');
VALUES('100030','4640829','SCZ','CalzadillaOsinaga','JuanitoYuset','M','Boliviana','35344
29','70871069','Avcentinelasdelchaco#56',null,'1');
106

VALUES('100031','4606141','SCZ','CamachoGutierrez','Arminda','F','Boliviana','3539553','7
0857611','C/Azubi#56','a_camacho1@gmail.com','1');
VALUES('100032','5335594','SCZ','CamachoValverde','Johys','M','Boliviana','3582897','710
07706','B/santaana/C-5-CarreteraCBBA','johys_c@hotmail.com','1');
VALUES('100033','2995339','SCZ','CamachoZambrana','David','M','Boliviana','3473297','7
6095191','B/Labelgica/C:BasilioDuran#3225','deibica@hotmail.com','1');
VALUES('100034','1032107','SCZ','CastellonPardo','JuanaNancy','F','Boliviana','3506966','
73161155','C/darioleigue#3300',null,'1');
VALUES('100035','4687632','SCZ','CasteloLopez','Roxana','F','Boliviana','3648414','70861
807','Av:Cumavi#226',null,'1');
VALUES('100036','2834601','SCZ','CastroSuarez','Azalea','F','Boliviana','3644192','702498
98','4toanillobrasilcondlatrinifesa',null,'1');
VALUES('100037','1532893','SCZ','CerrutodeBarbeito','JosefinaLourdes','F','Boliviana','342
2330','77071101','B/Oriental/C-1#8','lource@hotmail.com','1');
VALUES('100038','1979597','SCZ','CespedesRomero','Roberto','M','Boliviana','3503338','7
7038411','C/parabano#154','r-cespedes_rhotmail.com','1');
VALUES('100039','2822879','SCZ','ChocloBravo','NoemyDeborah','F','Boliviana','3522209',
null,'C/naico#38',null,'1');
VALUES('100040','3589191','CBB','ChugarSubieta','LuisRodrigo','M','Boliviana','3509378','
73180635','B/SantaRositac/Azubi#27','rodrigochugar@hotmail.com','1');
VALUES('100041','3242399','SCZ','ClaureBarron','EricaRoxana','F','Boliviana','3521601','7
6047767','RocaCoronadoC/Yuracare387','erikaclaure@hotmail.com','1');
VALUES('100042','3860959','SCZ','ContrerasJankori','GermanLuis','M','Boliviana','3649672
','77064348','4anilloB/Corbecrus#2','gercojan@hotmail.com','1');
VALUES('100043','3870870','SCZ','CortezOtuvo','DarolEduaedo','M','Boliviana','3304545','
77351044','Urb/flamingo/C-3/#205','eduardo_cortez1@hotmail.com','1');
107

VALUES('100044','5859579','SCZ','DelgadilloRocha','Miguel','M','Boliviana','3505474','7907
5560','Av:Piray','ingecome@hotmail.com','1');
VALUES('100045','8068740','SCZ','DoradoVasques','LuisEnrique','M','Boliviana','3640379','
3467179',null,'mundofilatelico@gmail.com','1');
VALUES('100046','2945137','SCZ','DuranCaspedes','AngelJorge','M','Boliviana',null,'72696
386','B/conavic/diegomartinez#3325',null,'1');
VALUES('100047','2963314','SCZ','DuranRibera','Agustin','M','Boliviana','3424773','726624
54','B/HamacasCalle#1','agustinduran@hotmail.com','1');
VALUES('100048','3255259','SCZ','ErazoMartinaz','HugoAlfredo','M','Boliviana',null,'70208
093','B/est-arg/Av:sanrafael#639',null,'1');
VALUES('100049','4686173','SCZ','FarelLopez','DamianaDorys','F','Boliviana','3484545','7
7619754','B/SCZC/Patuju#2005','totaitu@hotmail.com','1');
VALUES('100050','6355372','SCZ','FernandezCorneo','RaquelVeronica','F','Boliviana','336
2264','70284210','Av:2deagosto/B8dediciembre','rumverito_16@hotmail.com','1');
VALUES('100051','3191692','SCZ','FicherLijeron','PabloJesus','M','Boliviana','3400392','70
834493','B/retooAvprincipal#8240','ficher323@hotmail.com','1');
VALUES('100052','1420062','SCZ','FloresLlampa','Ruben','M','Boliviana','3443111','798859
41','Av:BanzerKm7','ruben_flores07@hotmail.com','1');
VALUES('100053','4566697','SCZ','FuenteQuispe','FelixBernardo','M','Boliviana','3518877',
'76310320','BarrioLasAmericas#120','ffuentesq@hotmail.com','1');
VALUES('100054','4586352','SCZ','FulgueraMamani','Saul','M','Boliviana','3498535','70251
478','B/banzervilla1demayo','saul_fulguera74@hotmail.com','1');
VALUES('100055','5354062','SCZ','GilPea','AlbaRocio','F','Boliviana','3203511','70995770'
,'3eranilloAV.Grigota','prettyalba_11@hotmail.com','1');
VALUES('100056','2931063','SCZ','GonzalesBarriga','Jaime','M','Boliviana','3568115',null,'
Urb/chiriguano-C/sayubu#30','jaimegonzalesbarriga@hotmail.com','1');
108

VALUES('100057','3923916','SCZ','GonzalesMendoza','MariaBlanca','F','Boliviana',null,'71
307872','B/palmira','blanca_01_08@hotmail.com','1');
VALUES('100058','4721496','SCZ','GutierrezPaz','MariaJose','F','Boliviana','3522988','7738
2968','Av:santosdumon/C-Antonioabaca#3074','mj.gpaz@hotmail.com','1');
VALUES('100059','5408095','SCZ','GuzmanFranco','AdaMarcela','F','Boliviana',null,'72640
542','B-VillaBrigidac-1','adamarguzman@hotmail.com','1');
VALUES('100060','5028040','TJA','HumerezTorrez','CarlaJimena','F','Boliviana','3350028','
70205633','Av:Buch-3y4/anillo-C/4#3','carlahomereztorrez@yahoo.com','1');
VALUES('100061','4601620','SCZ','HurtadoEguez','Jorge','M','Boliviana','3646411','721100
33','C/lipori#3420/4anillo,mutualista/alemana','johueg@hotmail.com','1');
VALUES('100062','5394793','SCZ','IbarraHuallpa','Julian','M','Boliviana',null,'77044429','B/
4denoviembre/C-2',null,'1');
VALUES('100063','3932558','SCZ','Javier','BeltranLira','M','Boliviana','3345034','76370720',
'Av:Santosdumot/BvillafatimaIII','jumelan3@hotmail.com','1');
VALUES('100064','3770222','SCZ','JimenezRojas','OscarRaul','M','Boliviana','3418767','72
648854','Av:Buchs/C#2-esq/nicolasortiz','oscarrauljimenez@hotmail.com','1');
VALUES('100065','3923549','SCZ','JustinianoCoimbra','EduardoRemy','M','Boliviana','3418
219','70047323','AvLaSalleC/SanSilvestre#91','rjmicroempresas@hotmail.com','1');
VALUES('100066','1625852','TJA','LafuenteArraya','MariaFatima','F','Boliviana','3398049',n
ull,'C/carmelolopez-maquinavieja','fatimalafuente@hotmail.com','1');
VALUES('100067','3701096','SCZ','LapacaMollo','HenryJosue','M','Boliviana','3646752','72
698378','C/ciquisa#2140','henryjlmster@gmail.com','1');
VALUES('100068','1737136','SCZ','LecaroBecerra','Katerine','F','Boliviana','3608610','7318
5850','Av:Brasil',null,'1');
VALUES('100069','2853929','SCZ','LinoVillarroel','CarmenCecilia','F','Boliviana','3922388','
76003109',null,'usbcarmenlino@yahoo.com','1');
109

VALUES('100070','3239470','SCZ','MarinChambi','Javier','M','Boliviana','3399841','770504
27','Villa1deMayoC/3#45','javier_marin_ch@hotmail.com','1');
VALUES('100071','2348982','SCZ','MartinezOrtiz','WalterRamiro','M','Boliviana','3560396','
71638168','Urb/espaa/C-adolfobecker#13','wrmo_1@hotmail.com','1');
VALUES('100072','8393303','SCZ','MartinezValda','Fernando','M','Boliviana',null,'71365906
','C/Venezuela#78','martinezvalda@hotmail.com','1');
VALUES('100073','1581742','SCZ','MedinaJustiniano','Glover','M','Boliviana','3404634','700
50848','B/universitarionorte/C#16','globermedina@hotmail.com','1');
VALUES('100074','3181298','SCZ','MelendresParraga','Hilton','M','Boliviana','3335404','700
03672','C/renemoreno#643',null,'1');
VALUES('100075','6218232','SCZ','MelgarMartinez','LilibethBeily','F','Boliviana','3362640','
79039175','B/panamericano/C-Venezuela#228','lilibeth_melgar@hotmail.com','1');
VALUES('100076','1577503','SCZ','MendozaClaro','Nilda','F','Boliviana','3547866','7097200
2','B/FlamingoC/2#11','niliterae@hotmail.com','1');
VALUES('100077','6224684','SCZ','MendozaMercado','Adan','M','Boliviana','3536716','760
50350','B/Branift-C/Villamonte#278','nanita.vip@gmail.com','1');
VALUES('100078','5374794','SCZ','MontaoCruz','Ana','F','Boliviana','3532611','79044517',
'6toanilloentrerad17ymedio','ing_anamc@hotmail.com','1');
VALUES('100079','4588140','SCZ','MontaoMeneses','Salustio','M','Boliviana',null,'726295
39','B/amacas/C-7este#133','saulo_mon@hotmail.com','1');
VALUES('100080','1253719','PND','MonteroPrado','Jorge','M','Boliviana','3578349','726158
01','C/facudoflores#52','jormonpra@hotmail.com','1');
VALUES('100081','4418066','SCZ','MontoyaTorrez','JoseMiguel','M','Boliviana',null,'731501
63',null,'josmi_motog@hotmail.com','1');
VALUES('100082','3121293','ORU','MoralesVaegas','GabyMaria','F','Boliviana','3516877','7
110
0000358','Urb/espaa/Av:migueldecervante#18','gabymariamoralesvargas85@hotmail','1')
;
VALUES('100083','1930638','BEN','MoyaRodriguez','LindaEsther','F','Boliviana','3508642','
72691077','B/sanjorge-santosdumontfinal','linda.moya@hotmail.com','1');
VALUES('100084','3286936','SCZ','NeryElHage','Lorenronald','M','Boliviana',null,'7265909
4','av.Rolandodechazal#4185b/Guaracachi',null,'1');
VALUES('100085','1025278','CHS','OrellanaAvila','Walter','M','Boliviana','3412183','726289
99','B/guapayC/c',null,'1');
VALUES('100086','3920366','SCZ','OroscoMariscal','Willy','M','Boliviana','3606941','736930
01','Av:CarmeloOrtiz/C#4','woroscom@hotmail.com','1');
VALUES('100087','2986210','SCZ','OrtuoMartinez','Rolando','M','Boliviana','3421642','721
87402','Av:Busch/C10#86',null,'1');
VALUES('100088','5385343','SCZ','OvandoAlvarez','Nancy','F','Boliviana','3335007','79028
653','C/mamertoolloa#116','nancyovando1@hotmail.com','1');
VALUES('100089','5384041','SCZ','PadillaUlloa','AnaJoselin','F','Boliviana','3365533',null,n
ull,'ana_jau@hotmail.com','1');
VALUES('100090','3874707','SCZ','PadillaValdivia','Orlando','M','Boliviana','3401515','7109
8766','Av:Beni4toanillo/BlaMerced#4370','orlando_padilla@hotmail.com','1');
VALUES('100091','755336','SCZ','PalmaLino','JoseHelpide','M','Boliviana','3537072','72657
500','AntinioSuarez#239',null,'1');
VALUES('100092','4688376','SCZ','PaaVargas','JulioCesar','M','Boliviana',null,'77021757',
'B/lacolorada/C-siringuero#4130','juliocesar.pv@hotmail.com','1');
VALUES('100093','4607451','SCZ','PazAlvarez','RomanoBismack','M','Boliviana','3700565',
'70824414','Urbsantaana/C#2pasillo1','mack.paz@hotmail.com','1');
VALUES('100094','5828958','SCZ','PedrazaMercado','Oscar','M','Boliviana','3302743','7211
3454','C/Espaa232','opedraza@santacruz.gob.com','1');
111

VALUES('100095','3912679','SCZ','PeaSuarez','BlancaElena','F','Boliviana','3300958','72
615355','C/Republiqueta#658','blaneps@hotmail.com','1');
VALUES('100096','3275841','SCZ','PeaValverde','Ruben','M','Boliviana','3320281','70921
310','Urb/espaasur',null,'1');
VALUES('100097','2992793','SCZ','PeaZurita','Nelly','M','Boliviana','3557691','72659526','
B-santaana3/Clasgarzas#6','nelly_p_2807@hotmail.com','1');
VALUES('100098','3322153','SCZ','PostigoGarcia','ZdenkaFatima','F','Boliviana','3326423','
70977116','Av:Busch/C-2#84','fapoga3@hotmail.com','1');
VALUES('100099','590820','ORU','QuintanaMonroy','Guillermo','M','Boliviana','3521609','71
323548','B/4denov.#3135-esq-C/2',null,'1');
VALUES('100100','4586716','SCZ','QuispeLucana','Luis','M','Boliviana',null,'77671059','B/C
oopacabanaC/4Av.Elmechero','luis_ql1@hotmail.com','1');
VALUES('100101','5842821','SCZ','RamirezAlbuquerque','LadyDiana','F','Boliviana','33278
74','79841751','Av:mutualista#2425','lidy_diana2103@gmail.com','1');
VALUES('100102','3185601','SCZ','ReyesCespedes','Marlene','F','Boliviana',null,'70497027
','C/Charcas#855','marlenereyesmontero@hotmail.com','1');
VALUES('100103','3876846','SCZ','RipaldaToledo','Lily','F','Boliviana',null,'73678810','Avlac
ampana','lilyrpaldatoles@hotmail.com','1');
VALUES('100104','6298593','SCZ','RochaClaure','Vanessa','F','Boliviana','3441720','76685
552','Av:Piray','vaninz_ure@hotmail.com','1');
VALUES('100105','3935684','SCZ','RodriguezOvando','GiovannaMarlene','F','Boliviana',nul
l,'70908143','B/sanjuan/C-2#3Villa','giovana_xro@hotmail.com','1');
VALUES('100106','3928722','SCZ','RojasGalarza','Georgina','F','Boliviana',null,'72157266','
B/paraisoC/Cronenvol#40',null,'1');
VALUES('100107','2820498','SCZ','RojasSantos','TrifonAndres','M','Boliviana','3400826','7
0058185','C/bibosi#13','aandresmojos_scz@hotmail.com','1');
112

VALUES('100108','3168595','SCZ','SalazarPerez','TomasAlberto','M','Boliviana','3464330','
70900666','B/Corecruz-C/2oeste#8','asalazar85@hotmail.com','1');
VALUES('100109','4687307','SCZ','SalcesCuellar','ClaudiaCecilia','F','Boliviana','79821738'
,'76386032','AvCentenariofrentecanal11','elmanaclaudia@hotmail.com','1');
VALUES('100110','3279956','SCZ','SalvatierraPaesano','GermanNilson','M','Boliviana','360
1056','76633232','C/LutherKingesq/asdra','gralvatierra@baneco.com.bo','1');
VALUES('100111','4176452','BEN','SantaCruzRico','JuanPablo','M','Boliviana','3901189','75
001030','Av:paragua/C-F#3125','c/yasociado@hotmail.com','1');
VALUES('100112','2723625','ORU','SaraviaGonzales','DavidRene','M','Boliviana','3402428'
,'70445870','4anilloN510alemana/mutualista','davidsago@hotmail.com','1');
VALUES('100113','3233847','SCZ','SaucedoNues','Eva','F','Boliviana','3396155','7769816
5','C/tarija#555','evasaucedo@hotmail.com','1');
VALUES('100114','2844098','SCZ','SejasUgartechi','FelyMarcela','F','Boliviana','3534871','
77029129','C/Felixtabera','sumarcela81@hotmail.com','1');
VALUES('100115','3897533','SCZ','SelemeGalarza','LizielZarina','F','Boliviana','3356560','7
1047100','C/espaa#232','lizy01412@gmail.com','1');
VALUES('100116','678928','ORU','SerranoEstevez','Gonzalo','M','Boliviana','3556847','726
88658','Urb/lamadre/C-8#176',null,'1');
VALUES('100117','5344229','SCZ','SolizChoque','Jacqueline','F','Boliviana','3343437','7028
4849','Av:buchs/C-9/pasillo#2','negrita_sc26@hotmail.com','1');
VALUES('100118','3888968','SCZ','SolizEysele','NorkaElizabeth','F','Boliviana','3597773','7
0949924','C/guenda#345','nese06@hotmail.com','1');
VALUES('100119','4562202','SCZ','SomozaRodriguez','ManuelJesus','M','Boliviana','75005
756','72123252','B/bolivia#5055-Km4alnorte','manuel_somoza3@hotmail.com','1');
VALUES('100120','5336424','SCZ','SosaCaballero','Rafael','M','Boliviana','3537188','70987
179','C/lapea#70','r_aelito@hotmail.com','1');
113

VALUES('100121','5352515','SCZ','SuarezEspada','Wilmar','M','Boliviana','3499273','70846
116','B/lapascana#9',null,'1');
VALUES('100122','4624348','SCZ','SuarezRivas','ShirleyKalajan','F','Boliviana',null,'716706
66','Av:Palmar',null,'1');
VALUES('100123','3451069','SCZ','TelleriaGutierres','HugoAlexaxnder','M','Boliviana','3467
061','72686397','urb/jardinlatino#13c/14','alexandertelleria@gmail.com','1');
VALUES('100124','4615782','SCZ','TorricoVelasqus','AmparoSosy','F','Boliviana','3745273',
'70833319','Av:ParaguaC/Pando#2055','suebombom@gmail.com','1');
VALUES('100125','972753','SCZ','TrujilloCoronado','Normaly','F','Boliviana',null,'70245400',
'B/petrolerosurC/9','nor_mit@hotmail.com','1');
VALUES('100126','977216','CBB','UreySalinas','MariaDelcarmen','F','Boliviana','3342704','
71620990','MonseorSalvatierra#59','madelca@cotas.com.bo','1');
VALUES('100127','3194197','SCZ','UrquidiFarel','Elizabeth','F','Boliviana','3621816','76079
094','Av:Belen#7','gody4669@hotmail.com','1');
VALUES('100128','6295984','SCZ','VacaManfredi','Roxana','F','Boliviana','3647545','72663
114','Av:VirgendeCotoca/CEmilioMolina',null,'1');
VALUES('100129','3191924','SCZ','VallejosCamacho','Anamaria','F','Boliviana','3323753','7
6632270','B/milagroC:Rodriguez/4an.centenario','anamariavc5@hotmail.com','1');
VALUES('100130','2964927','SCZ','ValverdeTeran','Mario','M','Boliviana',null,'72615779','Ur
b/entelnorte/C-A#1',null,'1');
VALUES('100131','4627579','SCZ','VargasCruz','Eliana','F','Boliviana','3351144','76025070'
,'AvAlemana/5-anillo/C-11#5400','elianavargacruz@hotmail.com','1');
VALUES('100132','3803050','SCZ','VargasGarcia','Gregorio','M','Boliviana',null,'77657610','
K-14UVbalcon#1','gayitovargas2009@hotmail.com','1');
VALUES('100133','1020511','SCZ','VargasGuerrero','HaydeeNilda','F','Boliviana','3460979',
'79490203','4toanilloAv:nicolassuarez#190','hanivar@hotmail.com','1');
114

VALUES('100134','2807190','SCZ','VargasMoreno','VictoriaWilma','F','Boliviana','3469592','
76073890','B/Magisterionorte/C2#14',null,'1');
VALUES('100135','2834248','SCZ','VargasRomero','MariaRaquel','F','Boliviana','3459477','
72602724','7mo-anillo/2deagosto/alemana','raquelvaro@hotmail.com','1');
VALUES('100136','4654271','SCZ','VargasTejerina','Rebeca','F','Boliviana',null,'70934825','
B/ConaviC/prolongacionG#3225','rebe_var@hotmail.com','1');
VALUES('100137','3900449','SCZ','VediaGusman','ElbaLuisa','F','Boliviana','3526818','709
92604','B/braniff/C-abapo#222','elbaluisavedia@hotmail.com','1');
VALUES('100138','5345452','SCZ','VeizagaCalvimonte','LuisAlberto','M','Boliviana','352994
8','70838949','C/ipota#26',null,'1');
VALUES('100139','3188563','SCZ','VillalobosLora','RuthElzabeth','F','Boliviana','3365544','
79809501','Condominiobellavista#13','ruth_villalobos_l@hotmail.com','1');
VALUES('100140','5406720','SCZ','VillarroelLatorre','MarcoAntonio','M','Boliviana','390019
7','79475992','5anilloB/lostusequisC/Edgarpoe#5025','coc_80@hotmail.com','1');
VALUES('100141','5388168','SCZ','VillegasNavarro','LuisGustavo','M','Boliviana','3422065',
'70830256','3/anillo-radial-26','guillesgas_n@gmail.com','1');
VALUES('100142','4730061','SCZ','YucraFalon','Ernesto','M','Boliviana','3546476','7004362
0','VillaSanLuisC/Bibosi#190','ernesto_yucraf@hotmail.com','1');
VALUES('100143','994250','CBB','ZapataHeredia','CarlosMax','M','Boliviana',null,'7104096
3','b-Lacolorada5anillo',null,'1');
VALUES('100144','3289730','SCZ','ZeballosSoliz','JoseAntonio','M','Boliviana','3522489','7
0967337','Av:Piray/C-yacuse#40',null,'1');
VALUES('100145','3279415','SCZ','ZunaguaCibeles','Sandra','F','Boliviana','3529614','766
46011',null,null,'1');
115
3.6. Consultas
1) Mostrar Todos Los Postulantes Que Han Sido Aceptados
select *
from postulante,Profesor
Where postulante.Cod_postulante=Profesor.Cod_Postulante;
2) Mostrar Los Nombres de Todos Los Profesores que tienen Masterado
Select P.Nombres,P.Apellidos
From
3) Mostrar todos los profesores:Sus Nombres y Sus Carnets que tienen ms de 10 aos
de experiencia
116
Select P.Nombres, P.Apellidos,P.CI

From Postulante P,Hoja_Vida HV,Experiencia E
Where P.Cod_Postulante=HV.Cod_Pos and
HV.Cod_Hoja_Vida=E.Cod_Hoja_Vida and
E.Tiempo>10;
4) Mostrar Todas Las Aulas Con Su Capacidad y descripcin
SELECT A.Descripcion, A.Capacidad, A.Descripcion
FROM Aula A;
5) Mostrar Las Materias que se dictan
Postulante P, Hoja_Vida HV,Tipo_Formacion TF,Formacion F
Where P.Cod_Postulante=HV.Cod_Pos and
HV.Cod_Hoja_Vida=F.Cod_Hoja_Vida and
F.Cod_Tipo=TF.Cod_Tipo and
TF.Nombre='Masterado';
SELECT M.Nombre_Materia from materia M;
6) Mostrar Todos Los Grupos Que Hay
SELECT G.Id_Grupo FROM GRUPO G;
7) Mostrar Los Profesores que fueron Rechazados Con Todos Sus datos Recopilados
SELECT * FROM Postulante P Where P.Cod_Postulante not in (SELECT
Pr.Cod_Postulante From Profesor Pr);
8) Mostrar La Cantidad De Postulantes
10) Mostrar Los Profesores que dictan Matemticas por la maana
11) Mostrar Las Aulas Ocupadas por La Tarde
12) Mostrar Las Materias que se Dictan A las 7:00 a.m.
117
13) Mostrar Los Postulantes Con Disponibilidad De 20:30 a 22:00 para dictar Fsica
14) Mostrar Los Postulantes Para Dictar Realidad Nacional
15) Mostrar Los Postulantes a Fsica Que Fueron Rechazados
16) Mostrar Los Grupos que Dicta El Profesor Simn
17) Mostrar los Profesores que dictan ms de una materia
18) Seleccionar Grupos de las materias que son dictadas
19) Ordenar A los Profesores Por Apellido
20) Mostrar Todos Los Docentes Que Pasan Clases De 2p.m. a 6:00 p.m.
21) Mostrar Todos Los Profesores Que No Sean Boliviano
3.7. Procedimientos Almacenados

--Area-------------------------------------------------------------------------------------------CREATE PROC P_INSERTAR_Area(@Descripcion varchar(20))
AS
INSERT INTO Area VALUES(@Descripcion)
GO
CREATE PROC P_MODIFICAR_Area(@Id_Area int,@Descripcion varchar(20))
AS
UPDATE Area SET Descripcion=@Descripcion WHERE Id_Area= @Id_Area
GO
CREATE PROC P_ELIMINAR_Area(@Id_Area INT)
AS
DELETE FROM Area WHERE @Id_Area=Id_Area
GO
118
--Aula-------------------------------------------------------------------------------------------CREATE PROC P_INSERTAR_Aula(@Id_Modulo int,@Descripcion varchar(20),@Estado

char)
AS
INSERT INTO Aula VALUES(@Id_Modulo,@Descripcion,@Estado)
GO
CREATE PROC P_MODIFICAR_Aula(@Id_Aula int,@Id_Modulo int,@Descripcion
varchar(20),@Estado char)
AS
UPDATE Aula SET
Id_Modulo=@Id_Modulo,Descripcion=@Descripcion,Estado=@Estado WHERE Id_Aula=
@Id_Aula
GO
CREATE PROC P_ELIMINAR_Aula(@Id_Aula INT)
AS
DELETE FROM Aula WHERE @Id_Aula=Id_Aula
GO
--Dia-------------------------------------------------------------------------------------------CREATE PROC P_INSERTAR_Dia(@Descripcion varchar(20))
AS
INSERT INTO Dia VALUES(@Descripcion)
GO
CREATE PROC P_MODIFICAR_Dia(@Id_Dia int,@Descripcion varchar(20))
AS
UPDATE Dia SET Descripcion=@Descripcion WHERE Id_Dia= @Id_Dia
GO
CREATE PROC P_ELIMINAR_Dia(@Id_Dia INT)
AS
DELETE FROM Dia WHERE @Id_Dia=Id_Dia
GO
119
--Disponibilidad-------------------------------------------------------------------------------------------CREATE PROC P_INSERTAR_Disponibilidad(@Id_Hora int,@Id_Materia

int,@Id_Postulante int,@Id_Dia int)
AS
INSERT INTO Disponibilidad
VALUES(@Id_Hora,@Id_Materia,@Id_Postulante,@Id_Dia)
GO
CREATE PROC P_MODIFICAR_Disponibilidad(@Cod_Disponibilidad int,@Id_Hora
int,@Id_Materia int,@Id_Postulante int,@Id_Dia int)
AS
UPDATE Disponibilidad SET
Id_Hora=@Id_Hora,Id_Materia=@Id_Materia,Id_Postulante=@Id_Postulante,Id_Dia=@Id
_Dia WHERE Cod_Disponibilidad= @Cod_Disponibilidad
GO
CREATE PROC P_ELIMINAR_Disponibilidad(@Cod_Disponibilidad INT)
AS
DELETE FROM Disponibilidad WHERE @Cod_Disponibilidad=Cod_Disponibilidad
GO
--Grupo-------------------------------------------------------------------------------------------CREATE PROC P_INSERTAR_Grupo(@Descripcion varchar(20),@Estado
char,@Id_Area int)
AS
INSERT INTO Grupo VALUES(@Descripcion,@Estado,@Id_Area)
GO
CREATE PROC P_MODIFICAR_Grupo(@Id_Grupo int,@Descripcion
varchar(20),@Estado char,@Id_Area int)
AS
UPDATE Grupo SET Descripcion=@Descripcion,Estado=@Estado,Id_Area=@Id_Area
WHERE Id_Grupo= @Id_Grupo
GO
CREATE PROC P_ELIMINAR_Grupo(@Id_Grupo INT)
AS
120
DELETE FROM Grupo WHERE @Id_Grupo=Id_Grupo

GO
--Estado_Seleccion-------------------------------------------------------------------------------------------CREATE PROC P_INSERTAR_Estado_Seleccion(@Nom_Est_Sel
varchar(50),@Caracteristicas varchar(50))
AS
INSERT INTO Estado_Seleccion VALUES(@Nom_Est_Sel,@Caracteristicas)
GO
CREATE PROC P_MODIFICAR_Estado_Seleccion(@Cod_Est_Sel int,@Nom_Est_Sel
varchar(50),@Caracteristicas varchar(50))
AS
UPDATE Estado_Seleccion SET
Nom_Est_Sel=@Nom_Est_Sel,Caracteristicas=@Caracteristicas WHERE Cod_Est_Sel=
@Cod_Est_Sel
GO
CREATE PROC P_ELIMINAR_Estado_Seleccion(@Cod_Est_Sel INT)
AS
DELETE FROM Estado_Seleccion WHERE @Cod_Est_Sel=Cod_Est_Sel
GO
--Postulante-------------------------------------------------------------------------------------------CREATE PROC P_INSERTAR_Postulante(@CI int,@Procedencia CI char,@Apellidos
varchar(40),@Nombres varchar(40),@Sexo char,@Nacionalidad varchar(20),@Telefono
int,@Celular int,@Direccion varchar(50),@Email varchar(50),@Cod_Est_Sel int)
AS
INSERT INTO Postulante VALUES(@CI,@Procedencia
CI,@Apellidos,@Nombres,@Sexo,@Nacionalidad,@Telefono,@Celular,@Direccion,@Em
ail,@Cod_Est_Sel)
GO
CREATE PROC P_MODIFICAR_Postulante(@Cod_Postulante int,@CI int,@Procedencia
CI char,@Apellidos varchar(40),@Nombres varchar(40),@Sexo char,@Nacionalidad
varchar(20),@Telefono int,@Celular int,@Direccion varchar(50),@Email
varchar(50),@Cod_Est_Sel int)
AS
121
UPDATE Postulante SET CI=@CI,Procedencia CI=@Procedencia

CI,Apellidos=@Apellidos,Nombres=@Nombres,Sexo=@Sexo,Nacionalidad=@Nacionalid
ad,Telefono=@Telefono,Celular=@Celular,Direccion=@Direccion,Email=@Email,Cod_Est
_Sel=@Cod_Est_Sel WHERE Cod_Postulante= @Cod_Postulante
GO
CREATE PROC P_ELIMINAR_Postulante(@Cod_Postulante INT)
AS
DELETE FROM Postulante WHERE @Cod_Postulante=Cod_Postulante
GO
4. Anlisis y Diseo de Sistema

4.1. Modelo de Negocio
4.1.1. Diagrama de Actividad
4.1.1.1. Seleccin de Profesor
122
4.1.1.2. Verificacin de Aulas Disponibles
123
4.1.1.3. Programacin de Horarios
124
4.1.2. Diagramas de Caso de Uso

4.1.2.1. Identificar Casos de Uso y Actores
a) Identificar Actores
Postulante
Coordinador Acadmico
DUA Tcnica
Programador de horario
b) Describir Actores
Postulante.- Es la persona que presenta su Hoja de Vida, y presenta su

disponibilidad para ser aceptado como profesor del P.A.B.
Coordinador Acadmico.- Es la persona que elabora el plan acadmico, adems de

calcular la ponderacin para ver que postulante es aprobado para llegar a dictar
alguna materia durante las clases del P.A.B.
125
DUA Tcnica.- Es el Departamento de la Universidad que elabora un informe sobre

las aulas disponibles, las cuales sern usadas durante las clases del P.A.B.
Programador de horario.- Es la persona que se encarga de crear los horarios y los

grupos y asigna los profesores correspondientes a cada grupo y tambin las aulas
disponibles para dicho horario.
c) Identificar Casos de Uso
CU1: Registrar postulante.
CU2: Gestionar hoja de vida.
CU3: Calcular ponderacin.
CU4: Recibir resultado Ponderacin.
CU5: Generar informe general de perfil de postulante.
CU6: Generar informe de hoja de vida.
CU7: Registrar gestin.
CU8: Registrar periodo.
CU9: Generar plan Acadmico.
CU10: Procesar horario.
CU11: Registrar da.
CU12: Registrar hora.
CU13: Registrar turno.
CU14: Registrar materia.
CU15: Registrar aula.
CU16: Registrar modulo.
CU17: Registrar grupo.
CU18: Registrar rea.
CU19: Gestionar disponibilidad.
CU20: Gestionar profesor.
CU21: Generar Agenda de Contactos
126
CU22: Generar Listado Horarios.
CU23: Generar Listado Estados.
CU24: Generar Listado de Ponderaciones.
4.1.2.2. Priorizacin de Casos de Uso

Caso de Uso
CU4: Recibir resultado.
CU5: Generar informe general de perfil de
Estado
Aprobado
Aprobado
Incorporado
Incorporado
Incorporado
Prioridad
Importante
Importante
Importante
Importante
Accesoria
Riesgo
Normal
Normal
Normal
Critico
Significativo
postulante.
CU11: Registrar da.
Incorporado
Aprobado
Aprobado
Incorporado
Incorporado
Aprobado
Aprobado
Accesoria
Importante
Importante
Accesoria
Importante
Importante
Importante
Significativo
Normal
Normal
Significativo
Critico
Normal
Normal
127

CU21: Generar Agenda Contactos
CU22: Generar Listado de Horarios
CU23: Generar Listado de Estados
CU24: Generar Listado de Ponderaciones
Aprobado
Aprobado
Aprobado
Aprobado
Aprobado
Aprobado
Aprobado
Incorporado
Incorporado
Incorporado
Incorporado
Incorporado
Importante
Importante
Importante
Importante
Importante
Importante
Importante
Importante
Accesoria
Importante
Importante
Accesoria
Normal
Normal
Normal
Normal
Normal
Normal
Normal
Normal
Significativo
Significativo
Significativo
Significativo
4.1.2.3. Detallar Casos de Uso

4.1.2.3.1. Disear Caso de Uso
CU2:Gestionar Hoja de Vida
<<include>>
CU1:Registrar Postulante
Coordinador Academico
Postulante

Postulante
128

CU2:Gestionar Hoja Vida
<<include>>
CU3:Calcular Ponderacion
Coordinador academico

<<include>>
Lee, Minkyu
CU4:Recibir Resultado Ponderacion

<<include>>
<<include>>
CU5:Generar Informe Perfil
<<include>>
CU4:Recibir Resultado Ponderacin
129
CU6:Generar Informe Hoja de Vida

<<include>>
CU7:Registrar Gestion
CU8:Registrar periodo
Encargado academico
130
CU13:Registrar Turno
<<include>>
<<include>>
CU9:Generar Plan Academico

<<include>>
CU18:Registrar Grupo
CU15:Registrar Aula

CU11:Registrar Dia
CU12:Registrar Hora
<<include>>
<<include>>
<<include>>
CU10:Procesar Horario
CU13:Registrar turno
<<include>>
Programador de Horario
<<include>>
CU17:Registrar grupo
CU14:Registrar Materia
CU11: Registrar da.
CU11:Registrar dia
Programador de horarios
CU12:Registrar hora
131
CU13:Registrar turno
CU15:Registrar aula
Progragramador de horarios
CU15:Registrar aula
CU16:Registrar Modulo
<<extend>>
<<include>>
CU:Verificar Aula
DUA Tecnica
132
CU19: Registrar Area

<<include>>
<<include>>
CU15: Registrar Aula
CU17: Registrar grupo
<<include>>
<<include>>
CU14: Registrar Materia
CU: Verificar Hora
CU18:Registrar area
Progragramador de horarios

CU1: Registrar Postulante
Postulante
<<include>>
CU19:Gestionar Disponibilidad
133
coordinador academico

<<include>>
CU20: Gestionar Profesor

<<include>>
CU10: Procesar Horario

<<include>>
CU22: Generar Listado Horarios

CU3: Calcular Ponderacion
<<include>>
CU23: Generar Listado Estados
134
CU3: Calcular Ponderacion

<<include>>
CU24: Generar Listado Ponderaciones
4.1.2.3.2. Prototipar Caso de Uso

135

CU11: Registrar da.
136


4.1.2.3.3. Detalle Caso de Uso
137
Caso de Uso
Propsito
Actor
Actor Iniciador
Pre Condicin
Flujo Principal
Post Condicin
Excepciones
Caso de Uso
Propsito
Actor
Actor Iniciador
Pre Condicin

Almacenar los datos del Postulante en la Base de Datos.
Coordinador Acadmico, Postulante
Postulante
Presentar Datos de Postulante.
1.Registrar datos Postulante
1.1 Introducir los datos de Postulante.
1.2 Validar los datos
1.3 Guardar registro
2. Modificar datos Postulante
2.1 Introducir cdigo de Postulante
2.2 Modificar datos del Postulante
2.3 Actualizar cambios habilitados
2.4 Guardar el registro
3. Eliminar Postulante
3.1 Introducir cdigo de Postulante
3.2 Mostrar Postulante
3.3 Actualizar campo lgico
3.4 Guardar datos de Postulante
Tener en la Base de Datos registrados todos los datos de
Postulante.
1.2 Error de tipo de datos
1.2 El Postulante ya existe
2.1 Incorrecto cdigo inexistente
2.3 No se actualiza por incompatibilidad de datos
3.1 Postulante no existe en BD

Almacenar la informacin de la Hoja de Vida en la Base de
Datos.
Postulante
Presentar Hoja de Vida, Tener registrado el Postulante
138
Flujo Principal
Post Condicin
Excepciones
Caso de Uso
Propsito
Actor
Actor Iniciador
Pre Condicin
Flujo Principal
Post Condicin
Excepciones
Caso de Uso
Propsito
Actor
Actor Iniciador
Pre Condicin
Flujo Principal
Si Hoja de Vida Nueva

1Registrar Foto.
2 Registra Formacin.
2.1Seleccionar Formacin
3 Registrar Experiencia.
3.1Seleccionar Experiencias
4 Registrar Disponibilidad.
5 Registrar Materia a Dictar.
Caso contrario
Actualizar Hoja de Vida.
Tener las Hojas de Vida de los Postulantes actualizadas.
2 No haya sido tomada en cuenta
3 No est registrada

Calcular la ponderacin del Postulante de acuerdo a su
experiencia y nivel de formacin; para decidir si es seleccionado
como Profesor.
Coordinador Acadmico.
Haber registrado Experiencia y Formacin.
1 Registrar en Formulario Experiencia
2 Registrar en Formulario Formacin
3 Calcular Ponderacin
4 Guarda Resultado
Guarda en la base de datos la ponderacin de cada Postulante.
1 Experiencia no haya sido tomada en cuenta
2 Formacin no haya sido tomada en cuenta

Conocer el Resultado de la Ponderacin del Postulante.
Haber Calculado Ponderacin de Postulante
1 Registrar Cdigo Postulante
139
Post Condicin
Excepciones
Caso de Uso
Propsito
Actor
Actor Iniciador
Pre Condicin
Flujo Principal
Post Condicin
Excepciones
Caso de Uso
Propsito
Actor
Actor Iniciador
Pre Condicin
2 Mostrar el Resultado del clculo de la Ponderacin.

Obtener resultado, para elegir que postulante llegara a ser
profesor.
1 Datos Incompatibles
1 No exista en la base de datos

Generar informe general del perfil con los datos del postulante.
Tener registrados los datos del Postulante, Haber calculado
ponderacin.
1Identificar Postulante.
2 Identificar N de Ponderacin.
3 Obtener caractersticas de Perfil.
4 Generar Vista Previa de Impresin
Si opcin
Caso1: Realizar impresin.
Caso2: Cancelar impresin.
5Finalizar
Impresin del Perfil
1 No exista
2 Tipo dato Incompatible

Generar la impresin del la Hoja de Vida del Postulante.
Tener Almacenada la Hoja de Vida del postulante.
140
Flujo Principal
Post Condicin
Excepciones
Caso de Uso
Propsito
Actor
Actor Iniciador
Pre Condicin
Flujo Principal
Post Condicin
Excepciones
Caso de Uso
Propsito
Actor
Actor Iniciador
Pre Condicin
1Identificar Postulante.
2 Identificar Cdigo Hoja de Vida.
3 Obtener caractersticas de Hoja de Vida.
Si opcin
5Finalizar
Impresin del Perfil
1 No exista
2 Tipo dato Incompatible

Registrar gestin en la base de datos.
------------1 El sistema registra la Gestin.
1.1Insertar datos de la gestin
1.2 Guardar registro de gestin
2 Modificara los datos existentes de Gestin.
3 Eliminara una asistencia, previa confirmacin.
Tener guardado en la base de datos la gestin
1.1 Inconsistencia de datos
1.2No se ha logrado guardar los datos

Registrar en la Base de Datos los periodos
Coordinador acadmico
Tener registrado la gestin
141
Flujo Principal
Post Condicin
Excepciones
Caso de Uso
Propsito
Actor
Actor Iniciador
Pre Condicin
Flujo Principal
Post Condicin
Excepciones
Caso de Uso
Propsito
Actor
1 Registrar periodo
1.1Insertar datos del periodo , nombre, descripcin, estado
2 Modificar datos del periodo
2.1 El nombre del periodo, ampliar descripcin
3 Eliminar datos del periodo
Guardar correctamente los datos del periodo
1.1 No ingreso descripcin del periodo
3 No se pudo guardar correctamente el periodo

Generar el plan acadmico de un determinado ao
Tener registrado el turno, aula, grupo
1 Generar Plan Acadmico
2 Modificar Plan Acadmico
Plan acadmico actualizado
2 Tipo de Datos Incompatible

Verificar si las materias, hora, da, aulas, grupos, gestin para
poder procesar horario
142
Actor Iniciador
Pre Condicin
Flujo Principal
Post Condicin
Excepciones
Caso de Uso
Propsito
Actor
Actor Iniciador
Pre Condicin
Flujo Principal
Post Condicin
Excepciones
Caso de Uso
Propsito
Actor
Actor Iniciador
Pre Condicin
Flujo Principal
Verificar si estn registrada materia
Verificar da
Verificar hora
Verificar si se registraron las aulas
Verificar si se registraron los grupos
Verificar la gestin
1 Registrar horario
1.1 Insertar datos de horario
1.2 Guardar horarios
2 Modificar Horarios
3 Eliminar horarios, con previa confirmacin
Guardar satisfactoriamente el procesamiento de horario para
luego realizar la asignacin de profesores
1.1 No se han ingresado todos los requisitos principales para
procesar el horario
1.2Tipos de datos Inconsistentes
CU11: Registrar da.
Registrar todos los das que se programaran las clases
-----1 Registrar datos del da, cdigo del da y su descripcin
2 Modificar datos de un da determinado
3 Eliminar del sistema el da, previa confirmacin
Das guardados en la base de Datos
1Incorrecto tipo de dato
Post Condicin
Excepciones
Registrar la hora
-------------1 Registrar datos de la hora, hora inicio, hora fin
2 Modificar los daros existentes de una hora
3 Eliminara del sistema los datos de una hora
Horas guardadas en la base de Datos
1 Tipo de dato incorrecto
Caso de Uso
Propsito
Registrar turno
143
Actor
Actor Iniciador
Pre Condicin
Flujo Principal
Post Condicin
Excepciones
Caso de Uso
Propsito
Actor
Actor Iniciador
Pre Condicin
Flujo Principal
Post Condicin
Excepciones
Caso de Uso
Propsito
Actor
-------------1 Registrar datos de turno
2 Modificar los datos existentes de un determinado turno
3 Eliminara del sistema el turno, con previa confirmacin.
Turno guardados en la base de Datos
1 Tipo datos ingresados incorrectos

Registrar materia
----------1 Registrar datos de materia, identificador, sigla y, nombre y
guardar
2 Modificar datos de la materia ya registrada
3 Eliminar del sistema materia, previa confirmacin
4 Buscar materia por su cdigo, seleccin y agregar a la lista
de bsqueda
Guardar correctamente las materias que sern referenciadas
1 Incorrectos Tipos de datos ingresados

Registrar aula
Programador De Horarios, DUA Tcnica
144
Actor Iniciador
Pre Condicin
Flujo Principal
Post Condicin
Excepciones
Caso de Uso
Propsito
Actor
Actor Iniciador
Pre Condicin
Flujo Principal
Post Condicin
Excepciones
Caso de Uso
Propsito
Programador De Horarios
Estado De Aula Habilitado por DUA Tcnica
Capacidad Necesaria Habilitada por DUA Tcnica
1 Registrar datos de aula, cdigo modulo, cdigo aula y guardar
2 Modificar datos del aula ya registrada
3 Eliminar del sistema aula, previa confirmacin
4 Buscar aula por su cdigo, seleccin y agregar a la lista
de bsqueda
Si Aula habilitada Entonces Habilitado para la Creacin De
Grupos
Guardar correctamente las aulas que sern referenciadas
4 No exista aula
Si Aula Deshabilitada Entonces No Se puede Crear Grupos Con
Esta Aula

Registrar Modulo
Modulo habilitado
1 Registrar datos de modulo, cdigo modulo y guardar
2 Modificar datos de modulo ya registrado
3 Eliminar del sistema modulo, previa confirmacin
4 Buscar modulo por su cdigo, seleccin y agregar a la lista
de bsqueda
Guardar correctamente los mdulos que sern referenciadas
4 No exista modulo

Registrar Grupo
145
Actor
Actor Iniciador
Pre Condicin
Flujo Principal
Post Condicin
Excepciones
Caso de Uso
Propsito
Actor
Actor Iniciador
Pre Condicin
Flujo Principal
Post Condicin
Excepciones
Caso de Uso
Propsito
Programador de Horarios
Aula Habilitada
Materia Registrada
rea Registrada
Hora Habilitada
1 Registrar datos de grupo, cdigo grupo y guardar
2 Modificar datos de grupo ya registrado
3 Eliminar del sistema grupo, previa confirmacin
4 Buscar grupo por su cdigo, seleccin y agregar a la lista
de bsqueda
Guardar correctamente los grupos que sern referenciadas
Si Grupo Creado Entonces Agregar Profesor Habilitado
4 No exista grupo
Si Grupo Creado No se le puede asignar un Profesor Entonces
Comunicar a Coordinador Acadmico

Almacenar Las diferentes reas en la base de datos
----------1 Registrar datos de rea, cdigo rea y guardar
2 Modificar datos de rea ya registrado
3 Eliminar del sistema rea, previa confirmacin
4 Buscar rea por su cdigo, seleccin y agregar a la lista
de bsqueda
Las Materias Para Los Grupos Creados Se Acomodan Por rea
4 No exista grupo

Almacenar la Disponibilidad del Postulante en la Base de Datos.
146
Actor
Actor Iniciador
Pre Condicin
Flujo Principal
Post Condicin
Excepciones

Postulante.
Recepcin de Disponibilidad por parte de Postulante
1Registrar Disponibilidad.
1.1 Registrar Da
1.2 Registrar Hora
1.3 Registrar Materia
Postulante con Disponibilidad Registrada.
1 Tipo de datos incompatibles
1.1 No exista
1.2 No exista
1.3 No est registrada
Caso de Uso
Propsito
Actor
Actor Iniciador
Pre Condicin
Flujo Principal
Post Condicin
Excepciones

Almacenar los Datos del Profesor en la Base de Datos.
Programador de Horario, Postulante
Programador de Horario.
Estado de Postulante Aceptado.
Registrar ID de Profesor.
Profesor almacenado correctamente en la base de datos
Tipo de dato incompatible
Caso de Uso
Propsito
Post Condicin
Excepciones

Generar la Agenda de contactos muestra el celular y email de
los postulantes.
Coordinador Acadmico, Base Datos
Gestionar Postulante.
1 Obtener caractersticas de telfono y email.
Si opcin
3Finalizar
Listado de Agenda de Contacto impreso
No genere por base de datos vaca
Caso de Uso
Propsito

Mostrar e Imprimir en listado de horarios.
Actor
Actor Iniciador
Pre Condicin
Flujo Principal
147
Actor
Actor Iniciador
Pre Condicin
Flujo Principal
Post Condicin
Excepciones
Caso de Uso
Propsito
Actor
Actor Iniciador
Pre Condicin
Flujo Principal
Post Condicin
Excepciones
Caso de Uso

Procesar Horario.
1 Obtener caractersticas de Horarios.
Si opcin
3Finalizar
Listado de Horarios impreso
CU23: Generar Listado de Estados

Mostrar e Imprimir en listado de Estados.
Gestionar Postulante
Obtener Estado Postulante
1 Obtener caractersticas de Estados.
Si opcin
3Finalizar
Listado de Estados impreso
CU24: Generar Listado de Ponderaciones
148
Propsito
Actor
Actor Iniciador
Pre Condicin
Mostrar e Imprimir en listado de Ponderaciones.

Calcular Ponderacin
Flujo Principal
Post Condicin
Excepciones
1 Obtener caractersticas de Ponderaciones.

Si opcin
3Finalizar
Listado de ponderaciones impreso
149
4.1.2.4. Diagrama General de Caso de Uso

<<include>>
CU2:Gestionar Hoja Vida

<<include>>
<<include>>
<<include>>
Postulante
CU4:Recibir Resultado Ponderacion

CU8:Registrar Periodo
CU21:Generar Agenda de Contactos
<<include>>
CU24:Generar Listado Ponderaciones

DUA Tecnica
CU23:Generar Listado Estados
CU18:Registrar Area
CU15:Registrar Aula
<<extend>>
CU20:Gestionar Profesor
<<include>>
CU11:Registrar Dia
<<include>>
CU12:Registrar Hora
<<extend>>
CU22:Generar Listado Horarios
150
5. Anlisis de la Arquitectura
5.1. Identificar Paquetes
Registra postulante, Registra Hoja de Vida, Registra

P1
disponibilidad del postulante, Pondera Hoja de Vida; genera

informes de perfil, de hoja de vida del postulante adems de
generar listado de ponderaciones y los estados de los
postulantes.
P2
Gestionar Plan Academico
Registra Gestin, Registra Periodo, Registra Profesor,

Registra Aula, Registra Modulo, Registra rea, Registra
Materia, Registra Hora, Registra Grupo, adems de generar
listados de Horarios y generar el Plan Acadmico.
151
5.2. Vista de Paquetes

P1 Gestionar Postulante
CU1:Gestionar Postulante
<<trace>>
P1

<<trace>>
<<trace>>
P1.1
Administrar Informes G.P.
<<trace>>
<<trace>>
<<trace>>
CU23:Generar Listado Estados
CU24:Generar Listado Ponderaciones
152
P2 Gestionar Plan Acadmico
<<trace>>
<<trace>>
P2
<<trace>>
<<trace>>
CU12:Registrar Hora
<<trace>>
<<trace>>
<<trace>>
<<trace>>
CU18:Registrar Area
P2.1
Administrar Informes G.P.A.
<<trace>>
<<trace>>
CU22:Generar Listado Horarios
153
5.3. Vista de Escenario

P1: Gestionar Postulante
CU4: Recibir Resultado Ponderacion

<<include>>
<<include>>
<<include>>
CU5:Generar Informe General de Perfil
Postulante
<<include>>
CU23:Generar Listado de Estados
CU24:Generar Listado de Ponderacion
P2: Gestionar Plan Academico

CU15:Registrar Aula
<<extend>>
CU20:Gestionar Profesor
CU22:Generar Listado de Horarios
<<include>>
CU11:Registrar dia
<<include>>
<<include>>
CU18:Registrar Area
CU12:Registrar Hora
154
5.4. Implementacin (Prototipo Principal)
155
Acoplamiento
P2:Gestionar plan Academico

CU20:Gestionar profesor
CU4:Recibir resultado de Ponderacion
Describir Acoplamiento entre Paquetes

P2: Gestionar Plan Acadmico
CU4: Recibir resultado de Ponderacin: Interacta por Gestionar profesor al actualizar los
datos del profesor.
Cohesin
P1
P2
156
5.5. Diagrama de Componentes
Gestionar Informes
SI PAB.exe
form1.vb
Conexion.vb
Gestionar Informes
157
5.6. Implementacin de Arquitectura de Paquetes
AgendaContactos.rpt
Lestados.rpt
<<Librerias>>
CrystalDecision.CrystalReport.Engine
CrystalDecision.ReportSource
CrystalDecision.Shared
CrystalDecision.window.forms
sistema
system.data
system.data.SqlClient
IHojadeVida.rpt
LPonderaciones.rpt
FormHojadeVida.vb
nPostulante.vb
Fdisponibilidad.vb
nHojadeVida
dPostulante.vb
Fpostulante.vb
158
nDisponibilidad.vb
FProfesor.vb
FHora.vb
FArea.vb
nHora.vb
nArea.vb
nProfesor.vb
FprogramarHorario.vb
<<Librerias>>
CrystalDecision.CrystalReport.Engine
CrystalDecision.ReportSource
CrystalDecision.Shared
CrystalDecision.window.forms
sistema
system.data
system.data.SqlClient
Fgestion.vb
nProgramarHorario.vb
nModulo.vb
Fmodulo.vb
nGestion.vb
nGrupo.vb
nMateria.vb
nPeriodo.vb
Fgrupo.vb
Fmateria.vb
Fperiodo.vb
159
6. Plataforma de Desarrollo
6.1. Sistema Operativo
El sistema de informacin puede ser ejecutado en Windows XP y Windows Vista elegimos
esto sistemas operativos debido a que son plataformas con facilidad en la administracin de
los software.
6.2. Base de Datos

Las caractersticas que pueda tener el Gestor de base de datos son muy importantes, ya
que tienen que cumplir con exigencias transaccionales y de ella depende en gran medida el
buen funcionamiento de la base de datos y su vida til, entre las ms importantes se pueden
mencionar las siguientes:
Control de redundancia de datos que evita que los usuarios tengan informacin
repetida y que provoca problema en la administracin.
Restriccin de acceso no autorizado para crear cuentas y asignar privilegios, de

acceso evitando el ingreso de personas no autorizadas a ciertas operaciones, esta
caracterstica es vital en un Gestor de Base de Datos.
Representacin de vnculos complejos entre datos sin perder los enlaces

manteniendo los vnculos complejos de los datos, obtener y actualizar con rapidez y
eficiencia datos que estn mutuamente relacionados.
Cumplir con las restricciones de integridad, como el tamao de los datos establecidos
en la base de datos, no todas las restricciones podrn ser especificadas en el Gestor
de Base de Datos, otras pueden requerir verificacin mediante programas de
actualizacin cuando se introducen los datos.
Respaldo y recuperacin de los datos cuando ocurren fallas en el sistema.
Caractersticas operacionales
transacciones (transactions)
Disparadores(triggers)
Backus y recuperacin(Backus & Recovery)

160
Procedimientos almacenados
Integridad Referencial
Tomando en cuenta las caractersticas analizadas elegimos como gestor de Base de Datos
Microsoft SQL Server 2000.
6.3. Lenguaje de Programacin

El lenguaje utilizado para el desarrollo del S.I. P.A.B. Es Microsoft Visual Studio.NET 2005
ya que este posee las caractersticas necesarias para el desarrollo de este sistema, teniendo
las siguientes caractersticas principales:
Facilita el manejo y generacin de reportes utilizando el componente Crystal Report.
Proporciona fcil acceso y manejo de la Base de Datos.
Es una plataforma rpida y sencilla.
Posee una variedad de componentes que ayudan a la implementacin del sistema.
Facilita el manejo de tablas.
161
7. Conclusin
Despus de haber cumplido con el desarrollo del Sistema de Informacin para Gestionar
seleccin de profesores y creacin de grupos y horarios en el rea acadmica del
Departamento de Programa de Admisin Bsica (P.A.B.) de la Universidad Autnoma
Gabriel Ren Moreno se establece lo siguiente:
El sistema proporciona una herramienta que puede ser utilizada por los encargados
acadmicos del P.A.B. u otras instituciones que requieran este tipo de informacin.
Durante el desarrollo del sistema se utilizo el Proceso Unificado de Desarrollo del
Software(PUDS) y el Lenguaje Unificado de Modelado (UML) para la representacin grafica
de los distintos modelos obtenidos durante el proceso de desarrollo, obtenindose de esta
manera una forma estndar de representar los modelos que compone un sistema
En vista de que todos los objetivos trazados inicialmente se ha cumplido satisfactoriamente,
se puede concluir que el Sistema de Informacin para Gestionar seleccin de profesores y
creacin de grupos y horarios en el rea acadmica del Departamento de Programa de
Admisin Bsica (P.A.B.) de la Universidad Autnoma Gabriel Ren Moreno Presenta
soluciones a sus problemas presentados y cumple con los requerimientos solicitados por el
departamento del P.A.B.
162
8. Recomendacin
Las recomendaciones para el sistema son las siguientes:
Para la inicializacin de las operaciones del sistema el personal requiere un conocimiento
mnimo del proceso de seleccin de profesor universitario basado en la metodologa de
escalafn y un pequeo taller para la introduccin del usuario al sistema ya que las
interfaces de usuarios del sistema se adaptan gradualmente.
Mediante el proceso de desarrollo del sistema, se obtuvo una documentacin consistente, se
recomienda utilizar los modelos de esta para cualquier posibilidad de adaptacin de algn
modulo del sistema segn sea necesario, en funcin a los nuevos requerimientos que
puedan surgir.
163
9. Bibliografa
Rumbaugh Jacobson, Booch PROCESO UNIFICADO DE DESARROLLO DEL

SOFTWARE UML (1era Edicin) Addson Wesley Iberoamericana Madrid, 1999.
Rumbaugh Jacobson, Booch EL LENGUAJE UNIFICADO DE MODELADO (1era

Edicin) Addson Wesley Iberoamericana Madrid, 1999.
www.elprisma.com/reclutamientodepersonal
TEORA DE SISTEMAS, Johansen Bertoglio.
INGENIERA DE SOFTWARE, Roger Presman.
INGENIERA DE REQUERIMIENTOS, Wieringa IEEE.
MANUAL DE REFERENCIA DE UML, Rumbaugh Jacobson, Booch.
164
Anexos
165

Documentacion SI PAB Perfil de Informe

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Documentacion SI PAB Perfil de Informe

Загружено:

Авторское право:

Доступные форматы

UNIVERSIDAD AUTONOMA GABRIEL RENE MORENO

SISTEMA DE INFORMACIN PARA GESTIONAR SELECCIN DE

SANTA CRUZ - BOLIVIA

2.1.7. Diagrama de Distribucin...................................................................

4.1.1.3. Programacin de Horarios..........................................................

Clases de repaso y actualizacin.

Textos elaborados y publicados por la UAGRM.

Prcticos y clases de apoyo.

El P.A.B. se constituye en un instrumento que permite preparar al

Toda la informacin que el departamento necesita es registrada en libros

Desarrollar un Sistema de Informacin para Gestionar seleccin de

1.2.2. Objetivos Especficos

Utilizaremos herramientas de programacin VISUAL BASIC.

Las polticas de Admisin de nuevos estudiantes en la Universidad

Universidades, realizado en la ciudad de Potos, y homologadas en la

a travs del examen de la Prueba de

Acadmica (P.S.A.) que se realizan todos los aos

equivalentes al 50% y el otro 50% corresponde a las notas adquiridas por

del Departamento de Santa Cruz,

entendiendo por mejores bachilleres a los estudiantes que hayan obtenido

Fax 3340106, Casilla de correo N 702, E-mail pab@uagrm.edu.bo, Web

1.4. Estructura Organizacional

ESTRUCTURA ORGNICA DEL DEPARTAMENTO PAB/PSA - UAGRM

JEFE DEL DPTO.

Registran la documentacin manualmente y en un libro.

Al momento de la creacin de grupos y horarios hay cruces de aulas, porque no

La seleccin de profesores no es adecuada, ya que muchas veces hay profesores

No cuentan con un registro de profesores pre-seleccionados en el caso de que algn

El departamento contrata a cierto personal, que se encarga del control de asistencia

En el momento de que ingresa algn documento en el departamento no hay una

El departamento no tiene conocimiento de la cantidad de alumnos que ingresaron al

Para la toma de exmenes el P.A.B. requiere a dos docentes de planta registrados y

No todos los profesores y los docentes que se encargan de la toma de pruebas

Deficiencia en la recoleccin y manejo de archivos.

Han sufrido en varias ocasiones perdida de informacin y de archivos por falta de

La manipulacin de la informacin que tiene cada docente registrada en las tablas de

1.5.2. Formulacin del Problema

1.6.2. Requisitos No Funcionales

5.- Cmo organiza los documentos que recolectan de los docentes?

Cargo: ASISTENTE FINANCIERO

Entrevista al los trabajadores del departamento del P.A.B.

Entrevista al los trabajadores del departamento del P.A.B.

5.- El sistema que utilizan para la inscripcin al pab es del departamento?

Elementos Del Sistema

Seleccin de Docentes para

-Informe de Actividades (Avance)

Asignacin de Aulas Para Las Clases del Programa de Admisin Bsica

para las diferentes materias

Con Aulas Disponibles.

Programacin de Grupos y Horarios

Conocer a todo alumno y

Dictar Los Cursos del

docente que participe del

Programa De Admisin Bsica

Programacin De Aulas Para Exmenes

Que Participen en el Programa De

1.9. Metodologa Ishikawa

1.9.2. Identificar las principales categoras

1.9.3. Identificar las causas

1.9.4. Anlisis y Conclusin

Crear un lenguaje para modelado utilizable a la vez por mquinas y por

Establecer un acoplamiento explcito de los conceptos y los artefactos

Manejar los problemas tpicos de los sistemas complejos de misin crtica.