Vous êtes sur la page 1sur 116

UNIVERSIDAD JOSÉ CARLOS MARIÁTEGUI, MOQUEGUA

FACULTAD DE INGENIERÍA Y ARQUITECTURA

Carrera Profesional De Ingeniería De Sistemas E Informática

INFORME DE PRACTICAS PRE PROFESIONALES

“Desarrollo de un Sistema de Administración


De Expedientes para la Universidad José Carlos Mariátegui”

PRESENTADO POR:

Bach. Samir Ivan Benavente Condori

Moquegua, 09 de Noviembre de 2016


DEDICATORIA:

A mis Padres:

Dedico el presente trabajo a mis


padres que me vieron nacer y que
su enseñanza y sus buenas
costumbres han creado en mi
sabiduría haciendo que hoy tenga
el conocimiento de lo que soy.

i
INTRODUCCION

La Universidad José Carlos Mariátegui tiene varios programas de Educación,


entre ellos tenemos, Educación a Distancia, Educación Presencial, Educación
para Adultos, Programa Especial y Complementación académica entre otros.
Para administrar todos los expedientes de todos los alumnos de cada programa
antes mencionados se hace complicado saber que contiene y también se hace
difícil la búsqueda, por lo cual se hacen más lento los trámites que tienen que ver
con documentos de los expedientes.
El sistema de control manual que se tiene en la actualidad hace que los
expedientes hace difícil la búsqueda debido a que diariamente se adjuntan
documentos y se mueven expedientes para algunos trámites como
convalidaciones entre otros.

En el presente Informe, se plantea el desarrollo de un sistema informático


usando tecnologías web para el área de Archivo de Expedientes. Este informe
comienza con la presentación de la Universidad José Carlos Mariátegui en la
cual realicé la práctica Pro profesional. En este se incluye toda la información
necesaria y requerida para la identificación de la Universidad, como su
organización, funciones, objetivos, entre otros.

El capítulo I habla de la organización de la Universidad, funciones, ubicación y


objetivos de la práctica.

En el capítulo II se le dedica al Marco Teórico, donde se realizan estudios de las


metodologías orientadas diseño de sistemas con tecnología web, inicialmente se
describen algunos conceptos.

ii
En el capítulo III comprende el material y método utilizado donde se especifican
métodos, técnicas que se utilizaron para el desarrollo del informe. En el Capítulo
IV están los resultados, se mencionan las ventajas obtenidas con el desarrollo
del sistema informático propuesto en el presente informe. Por último,
encontramos las conclusiones y sugerencias a las que se arribó en el Desarrollo
del informe de prácticas.

En el Capítulo V encontramos las conclusiones y sugerencias a las que se arribó


en el desarrollo del informe de prácticas.

iii
RESUMEN

El presente informe de prácticas se desarrolló dentro de la oficina de Servicios


Académicos (OSA) en el área de Archivos de la Universidad José Carlos
Mariátegui.
Se realizaron estudios de las principales actividades y procesos administrativos y
se pudo apreciar que el área de Archivo de Expedientes que se encuentra a
cargo de la OSA y no es controlada con un sistema Informático, debido a esto,
se pretende desarrollar un sistema de Administración de expedientes.
Se desarrollara el sistema informático de control Evaluación y seguimiento de
los expedientes de cada alumno de la UJCM, esto será capaz de administrar la
información contenida en cada expediente y controlar los movimientos de este
dentro de la UJCM.
Este Sistema presenta alternativas de expansión pudiendo funcionar desde
internet y tener el control a distancia, debido a que se desarrolló usando
tecnologías web y aplicando la ingeniería web

iv
ÍNDICE
DEDICATORIA: ................................................................................................... I
INTRODUCCION ................................................................................................. II
RESUMEN ......................................................................................................... IV
CAPÍTULO I ........................................................................................................ 1
1 GENERALIDADES DE LA INSTITUCIÓN: ............................................... 1
1.1. NOMBRE O RAZÓN SOCIAL: ........................................................... 1
1.2. UBICACIÓN DE LA INSTITUCIÓN: ................................................... 1
1.3. ACTIVIDADES DE LA INSTITUCIÓN: ............................................... 1
1.4. RESEÑA HISTÓRICA: ....................................................................... 2
1.5. FINALIDAD: ....................................................................................... 5
1.6. VISIÓN: .............................................................................................. 5
1.7. MISIÓN: ............................................................................................. 5
1.8. ORGANIGRAMA ................................................................................ 6
1.9. LUGAR DE EJECUCIÓN DE LAS PRÁCTICAS PRE –
PROFESIONALES: ...................................................................................... 7
1.9.1. NOMBRE DEL ÁREA: .................................................................... 7
1.9.2. DESCRIPCIÓN DEL ÁREA DE TRABAJO: .................................... 7
1.9.3. OBJETIVOS OFICINA OSA PRE-GRADO: .................................... 7
1.10. ESTRUCTURA TEMÁTICA: ............................................................... 8
1.10.1. RESUMEN: ................................................................................. 8
1.10.2. DESCRIPCIÓN DEL PROBLEMA: .............................................. 9
1.11. OBJETIVOS DE LAS PRÁCTICAS PRE- PROFESIONALES: ........... 9
1.11.1. OBJETIVO GENERAL: ............................................................... 9
1.11.2. OBJETIVOS ESPECIFICOS: .................................................... 10
1.11.3. JUSTIFICACION: ...................................................................... 10
CAPÍTULO II ..................................................................................................... 11
2 FUNDAMENTO TEÓRICO: .................................................................... 11
2.1. PHP: ................................................................................................ 11
2.2. SISTEMA: ........................................................................................ 12
2.3. MySQL: ............................................................................................ 14
2.4. DBDesigner (Diseñador de una Base de Datos): ............................. 15
2.5. RATIONAL ROSE: ........................................................................... 16
2.6. UML ................................................................................................. 17
2.7. SGBD:.............................................................................................. 24

v
2.8. MODELO OOHDM o Método de Diseño de Hipermedia Orientado .. 25
2.8.1. MODELO CONCEPTUAL: ............................................................ 27
2.8.2. DISEÑO NAVEGACIONAL: .......................................................... 28
2.8.3. DISEÑO DE INTERFAZ ABSTRACTA: ........................................ 29
2.8.4. IMPLEMENTACIÓN: .................................................................... 29
2.9. ANÁLISIS ORIENTADA A OBJETOS: ............................................. 30
CAPÍTULO III .................................................................................................... 31
3 MATERIAL Y MÉTODO UTILIZADO EN LAS PRÁCTICAS
PREPROFESIONALES: ................................................................................ 31
3.1. MATERIALES: ................................................................................. 31
3.1.1. RECURSOS HUMANOS: ............................................................. 31
3.1.2. RECURSOS DE HARDWARE...................................................... 31
3.1.3. RECURSOS DE SOFTWARE: ..................................................... 32
3.2. METODOLOGÍA: ............................................................................. 32
3.3. ANÁLISIS DEL SISTEMA: ............................................................... 33
3.3.1. IDENTIFICACIÓN DEL PROYECTO: ........................................... 33
3.3.2. DESARROLLO DEL SISTEMA SISCOD: ..................................... 33
3.4. MODELO CONCEPTUAL: ............................................................... 58
3.4.1. DIAGRAMA DE CLASES: ............................................................ 58
3.5. DISEÑO NAVEGACIONAL: ............................................................. 59
3.5.1. DIAGRAMA DE COMPONENTES: ............................................... 59
3.5.2. DIAGRAMA DE DESPLIEGUE: .................................................... 62
3.6. DISEÑO DE LA INTERFAZ ABSTRACTA:....................................... 63
3.6.1. MODELO DE LA BASE DE DATOS: ............................................ 67
3.7. |IMPLEMENTACIÓN: ....................................................................... 68
3.7.1. MIGRACIÓN DEL MODELO DE LA BASE DE DATOS EN
DBDESIGNER A MYSQL: ....................................................................... 68
3.7.2. CODIGO DE CONEXIÓN A LA BASE DE DATOS CON PHP: ..... 76
CAPÍTULO IV .................................................................................................... 77
4 RESULTADOS DE LA PRÁCTICA REALIZADA: ................................... 77
4.1. MODULO DE CONSULTA: .............................................................. 79
4.1.1. Datos: Resultados de búsqueda, se muestran datos básicos del
alumno además de 4 pestañas que muestran más datos sobre su
expediente. ............................................................................................. 81
4.1.2. MODULO DE ADMINISTRACION: ............................................... 82
4.1.3. CENTROS EDUCATIVOS: ........................................................... 84
4.1.4. ASOCIACIONES: ......................................................................... 85
4.1.5. SEDES: ........................................................................................ 86

vi
4.1.6. Pantallas de Opciones del menú buscar alumno. ......................... 86
CAPÍTULO V ..................................................................................................... 90
5 CONCLUSIONES Y SUGERENCIAS: .................................................... 90
5.1. CONCLUSIONES: ........................................................................... 90
5.2. RECOMENDACIONES: ................................................................... 91
CAPÍTULO VI .................................................................................................... 92
6 BIBLIOGRAFIA: ..................................................................................... 92
CAPÍTULO VII ................................................................................................... 95
7 ANEXOS:................................................................................................ 95
7.1. CÓDIGO FUENTE: .......................................................................... 95
GLOSARIO ..................................................................................................... 102

ÍNDICE DE FIGURAS
DEDICATORIA: ................................................................................................... I
INTRODUCCION ................................................................................................ IV
1 GENERALIDADES DE LA INSTITUCIÓN: ............................................... 1
Figura 1.1. Organigrama de la Universidad José Carlos Mariátegui ............. 6
2 FUNDAMENTO TEÓRICO: .................................................................... 11
Figura 2.1 Ejemplo de código PHP. ........................................................... 12
Figura 2.2 Diseño de una Base de Datos en DBDesigner. ......................... 16
Figura 2.3 Interfaz de Rational Rose. ......................................................... 17
Figura 2.4 Ejemplo UML Diagrama de Clases. .......................................... 24
3 MATERIAL Y MÉTODO UTILIZADO EN LAS PRÁCTICAS
PREPROFESIONALES: ................................................................................ 31
Tabla 3.1 Recursos Humanos .................................................................... 31
Figura 3.1 Diagrama General del Sistema ................................................. 34
Figura 3.3 Diagrama de Gestión de usuarios ............................................. 36
B) SUB - SISTEMA DE EXPEDIENTES .................................................... 40
Figura 3.4 Diagrama de Gestión de Archivo:.............................................. 40
Figura 3.5 Diagrama de Gestión de Alumnos............................................. 49

vii
Figura 3.6 Diagrama de Administración del Sistema. ................................. 52
Figura 3.7 Diagrama de Administración de Especialidad ........................... 53
Figura 3.8 Diagrama de Administración de Facultad .................................. 53
Figura 3.9 Diagrama de Administración de Sedes ..................................... 53
Figura 3.10 Diagrama de Administración de Documentos.......................... 54
Figura 3.11 Diagrama de clases ................................................................ 58
Figura 3.12 Diagrama de componentes estructura del sistema .................. 59
Figura 3.13 Diagrama de componentes menú del administrador ............... 60
Figura 3.14 Diagrama de componentes menú del usuario ......................... 61
Figura 3.15 Diagrama de despliegue distribución física del sistema .......... 62
Figura 3.16 Interfaz de Documento Emitido ............................................... 63
Figura 3.17 Interfaz de Documento Emitido ............................................... 64
Figura 3.18 Interfaz de Consulta Documento Emitido. ............................... 65
Figura 3.19 Interfaz de Consulta Documento Remite. ................................ 66
Figura 3.20 Modelo de la Base de Datos ................................................... 67
Figura 3.21 Selección de la opción de exportación en el menú .................. 68
Figura 3.22 Selección de las opciones para la exportación ........................ 69
Figura 3.23 Guardando el archivo con la consulta para la creación ........... 70
Figura 3.24 Ventana phpMyAdmin de creación de Base de Datos ............. 71
Figura 3.25: Búsqueda del Archivo exportado en phpMyAdmin. ................ 72
Figura 3.26: Ventana phpMyAdmin con el archivo encontrado. ................. 73
Figura 3.27 Ventana phpMyAdmin con mensaje de ejecución con éxito. ... 74
Figura 3.28: Ventana MyAdmin con la Base de Datos ya importado. ......... 75
Figura 3.39 Código de la clase para la conexión con la base de datos ...... 76
4 RESULTADOS DE LA PRÁCTICA REALIZADA: ................................... 77
Figura 4.1 Página Principal ........................................................................ 77
Figura 4.2 Menú del Sistema. .................................................................... 78
Figura 4.3 Inicio del Sistema. ..................................................................... 79
Figura 4.4 Menú del Administrador. ........................................................... 80
Figura 4.5 Datos Básicos del expediente ................................................... 81
Figura 4.6 Documentos que contiene el expediente................................... 82
Figura 4.10 Control de acceso. .................................................................. 83
Figura 4.11 Panel de Administración.......................................................... 84
Figura 4.12 Ingreso de centros educativos................................................. 85
Figura 4.13 Registrar nueva Asociación. .................................................... 85
Figura 4.14 Registrar nueva Sede. ............................................................ 86
Figura 4.15 Detalles de Búsqueda de Alumno. .......................................... 87
Figura 4.16 Detalles de ingreso de expediente de alumnos ....................... 88
Figura 4.17 Detalle de ingreso de expediente de alumno........................... 89
5 CONCLUSIONES Y SUGERENCIAS: .................................................... 90

viii
6 BIBLIOGRAFIA: ..................................................................................... 92
7 ANEXOS:................................................................................................ 95
GLOSARIO ..................................................................................................... 102

ÍNDICE DE CUADROS
DEDICATORIA: ................................................................................................... I
RESUMEN ......................................................................................................... IV
1 GENERALIDADES DE LA INSTITUCIÓN: ............................................... 1
Figura 1.1. Organigrama de la Universidad José Carlos Mariátegui ............. 6
2 FUNDAMENTO TEÓRICO: .................................................................... 11
Figura 2.1 Ejemplo de código PHP. ........................................................... 12
Figura 2.2 Diseño de una Base de Datos en DBDesigner. ......................... 16
Figura 2.3 Interfaz de Rational Rose. ......................................................... 17
Figura 2.4 Ejemplo UML Diagrama de Clases. .......................................... 24
3 MATERIAL Y MÉTODO UTILIZADO EN LAS PRÁCTICAS
PREPROFESIONALES: ................................................................................ 31
Tabla 3.1 Recursos Humanos .................................................................... 31
Figura 3.1 Diagrama General del Sistema ................................................. 34
Figura 3.3 Diagrama de Gestión de usuarios ............................................. 36
Fuente: Propia ........................................................................................... 36
DESCRIPCIÓN DE CASO DE USO: .......................................................... 36
B) SUB - SISTEMA DE EXPEDIENTES .................................................... 40
Figura 3.4 Diagrama de Gestión de Archivo:.............................................. 40
Figura 3.5 Diagrama de Gestión de Alumnos............................................. 49
Figura 3.6 Diagrama de Administración del Sistema. ................................. 52
Figura 3.7 Diagrama de Administración de Especialidad ........................... 53
Figura 3.8 Diagrama de Administración de Facultad .................................. 53
Figura 3.9 Diagrama de Administración de Sedes ..................................... 53
Figura 3.10 Diagrama de Administración de Documentos.......................... 54
Figura 3.11 Diagrama de clases ................................................................ 58
Figura 3.12 Diagrama de componentes estructura del sistema .................. 59
Figura 3.13 Diagrama de componentes menú del administrador ............... 60
Figura 3.14 Diagrama de componentes menú del usuario ......................... 61
Figura 3.15 Diagrama de despliegue distribución física del sistema .......... 62
Figura 3.16 Interfaz de Documento Emitido ............................................... 63
Figura 3.17 Interfaz de Documento Emitido ............................................... 64
Figura 3.18 Interfaz de Consulta Documento Emitido. ............................... 65

ix
Figura 3.19 Interfaz de Consulta Documento Remite. ................................ 66
Figura 3.20 Modelo de la Base de Datos ................................................... 67
Figura 3.21 Selección de la opción de exportación en el menú .................. 68
Figura 3.22 Selección de las opciones para la exportación ........................ 69
Figura 3.23 Guardando el archivo con la consulta para la creación ........... 70
Figura 3.24 Ventana phpMyAdmin de creación de Base de Datos ............. 71
Figura 3.25: Búsqueda del Archivo exportado en phpMyAdmin. ................ 72
Figura 3.26: Ventana phpMyAdmin con el archivo encontrado. ................. 73
Figura 3.27 Ventana phpMyAdmin con mensaje de ejecución con éxito. ... 74
Figura 3.28: Ventana MyAdmin con la Base de Datos ya importado. ......... 75
Figura 3.39 Código de la clase para la conexión con la base de datos ...... 76
4 RESULTADOS DE LA PRÁCTICA REALIZADA: ................................... 77
Figura 4.1 Página Principal ........................................................................ 77
Figura 4.2 Menú del Sistema. .................................................................... 78
Figura 4.3 Inicio del Sistema. ..................................................................... 79
Figura 4.4 Menú del Administrador. ........................................................... 80
Figura 4.5 Datos Básicos del expediente ................................................... 81
Figura 4.6 Documentos que contiene el expediente................................... 82
Figura 4.10 Control de acceso. .................................................................. 83
Figura 4.11 Panel de Administración.......................................................... 84
Figura 4.12 Ingreso de centros educativos................................................. 85
Figura 4.13 Registrar nueva Asociación. .................................................... 85
Figura 4.14 Registrar nueva Sede. ............................................................ 86
Figura 4.15 Detalles de Búsqueda de Alumno. .......................................... 87
Figura 4.16 Detalles de ingreso de expediente de alumnos ....................... 88
Figura 4.17 Detalle de ingreso de expediente de alumno........................... 89
5 CONCLUSIONES Y SUGERENCIAS: .................................................... 90
6 BIBLIOGRAFIA: ..................................................................................... 92
7 ANEXOS:................................................................................................ 95
GLOSARIO ..................................................................................................... 102

x
CAPÍTULO I

1 GENERALIDADES DE LA INSTITUCIÓN:

1.1. NOMBRE O RAZÓN SOCIAL:

Universidad José Carlos Mariátegui

1.2. UBICACIÓN DE LA INSTITUCIÓN:

Departamento : Moquegua
Provincia : Mariscal Nieto
Distrito : Moquegua
Jirón : Ayacucho Nº 393
Teléfono : (053) - 46 – 1110

1.3. ACTIVIDADES DE LA INSTITUCIÓN:

La Universidad se dedica a:
 La Investigación Científica.
 Estudio constante.
 Educación superior integral.
 Formación académico profesional.
 Difusión de cultura.

Con mira a convertirse en una de las mejores Universidades tanto a


nivel Regional como Nacional, trabaja arduamente en la
Implementación de Infraestructuras tanto en Moquegua como en Ilo, a
la vez está implementando sus laboratorios con tecnología de punta
para así poder formar verdaderos profesionales, capaces de
desenvolverse en cualquier ámbito laboral

1
Ofrece Diplomados, Segundas Especialidades. Pro Títulos, Centro
Pre Universitario, Centro de Computo y Sistemas y de Idiomas
Escuela de Post Grado con Maestrías y Doctorados, campos
deportivos, y en cuanto a carreras a Distancia, contando de esta
manera con alumnado de distintas partes del Perú.

1.4. RESEÑA HISTÓRICA:

Fue creada como UNIVERSIDAD PRIVADA DE MOQUEGUA por ley


Nº 25153 del 23 de diciembre de 1989 con las carreras profesionales:
Ingeniería de Minas, Ingeniería Mecánica, Ingeniería Civil, Ingeniería
Ambiental, Ingeniería Pesquera e Ingeniería
Agroindustrial.

Desde su inicio fue su sede principal en el distrito de Moquegua,


provincia de Mariscal Nieto, departamento de Moquegua, donde
figura como persona jurídica sin fines de lucro y empezó a brindar su
servicio educativo el 15 de abril de 1991. Desde esa fecha se ha
convertido por méritos propios en una progresista ventana hacia el
desarrolla integral de todos aquellos que son conscientes que para
cumplir su sol para con la sociedad, la mejor forma es a través de una
eficiente profesionalización, por la cual se ha convertido en una firme
esperanza de consolidación de metas de grandeza espiritual y calidad
humana.

En el Puerto Industrial de Ilo, en el año 1996 empezaron sus


actividades académicas con tres carreras profesionales: Ingeniería
Mecánica, Derecho y Contabilidad.

El 03 de abril del 2001 La Comisión Organizadora presidida por el


Doctor Miguel Fuentes Chávez y la presidían el Doctor Juan

2
Rodríguez Pantigoso como Vicepresidente Administrativo y el
Licenciado Ramón Vera Robalcaba como Vicepresidente Académico,
asumieron con entrega y convicción el gran compromiso, frente a la
plana docente, la familia estudiantil y el pueblo en conjunto de
institucionalizar la universidad, la misma que se hizo efectiva en un
lapso de 13 meses. Por eso el 28 de mayo del 2002 se consiguió el
gran sueño de su institucionalización mediante resolución Nº 389-
2002-ANR y como fruto de esta resolución el 13 de noviembre del
2002 se promulgó el primer estatuto de la Universidad y
posteriormente el 30 de diciembre del mismo año, fueron elegidos el
Rector y Vicerrector en un ambiente democrático y en estricto
cumplimiento de la ley universitaria y del mencionado estatuto, actos
que garantizan la autonomía y credibilidad de la Universidad Privada
de Moquegua "José Carlos Mariátegui".

Desde aquella memorable fecha, figura en su historial institucional


como autoridades de la Universidad Privada de Moquegua "José
Carlos Mariátegui", su primer Rector Mgr. Alberto Coayla Vilca y
Vicerrector Dr. Javier Flores Arocutipa, quienes por su experiencia y
capacidad en estas lides, se han convertido en auténticos líderes de
avanzada al poner en práctica todo un conjunto de procesos del
sistema de educación superior universitaria, con lo que asegura que
egresen de sus aulas, profesionales de excelente calidad,
competitivos en cualquier latitud regional nacional y del exterior.

Actualmente, nuestra Universidad oferta trece carreras profesionales


y son las siguientes:

 Ingeniería Comercial.
 Ingeniería Agronómica.
 Ingeniería Civil.

3
 Ingeniería Mecánica Eléctrica.
 Ingeniería de Sistemas e Informática.
 Ingeniería Pesquera.
 Ingeniería Ambiental.
 Obstetricia.
 Contabilidad.
 Odontología.
 Derecho.
 Educación.
 Enfermería.
 Ingeniería de Sistemas e Informática
 Ingeniería de Telecomunicaciones y Redes
 Ingeniería Civil
 Ingeniería Mecánica Eléctrica
 Ingeniería Agronómica
 Ingeniería Agroindustrial
 Ingeniería Ambiental
 Arquitectura
 Economía
 Ciencias Administrativas y Marketing Estratégico
 Administración Turística y Hotelera
 Ingeniería Comercial
 Educación Secundaria
 Educación Primaria
 Educación Inicial
 Derecho
 Contabilidad
 Enfermería
 Obstetricia
 Odontología
 Psicología

4
1.5. FINALIDAD:

La Universidad JOSÉ CARLOS MARIÁTEGUI de Moquegua, es una


institución que tiene como finalidad brindar estudios superiores
universitarios tanto presencial como a distancia, utilizando métodos
muy eficaces que permiten lograr formar profesionales capaces,
eficientes, eficaces y con un nivel formativo igual o mejor que el
brindado en otras universidades.

1.6. VISIÓN:

Hacer de cada hombre un profesional o académico de excelencia al


servicio de la equidad social mundial.

1.7. MISIÓN:

Formamos profesionales, académicos, investigadores, tecnólogos.


Creativos, competentes y comprometidos con la solución de los
problemas de la comunidad, generando y desarrollando
conocimientos científicos, humanísticos; a través de los cuales se
formulen alternativas de desarrollo humano, cultura, bienestar y
equidad social.

5
1.8. ORGANIGRAMA

Figura 1.1. Organigrama de la Universidad José Carlos Mariátegui


Fuente: www.ujcm.edu.pe

6
1.9. LUGAR DE EJECUCIÓN DE LAS PRÁCTICAS PRE –
PROFESIONALES:

1.9.1. NOMBRE DEL ÁREA:

OSA: Oficina de Servicios Académicos.

1.9.2. DESCRIPCIÓN DEL ÁREA DE TRABAJO:

La Oficina de Servicios Académicos (Archivo) se encarga de


la administración de los expedientes de admisión de los
alumnos de las modalidades de Presencial, Semi-presencial,
Programa Especial, Distancia y Complementación Académica
de la Universidad José Carlos Mariátegui.

1.9.3. OBJETIVOS OFICINA OSA PRE-GRADO:

 Codificar a los ingresantes de las diferentes modalidades y


Carreras Profesionales.
 Realizar el Proceso de Matrículas el que consta en
Registrar e ingresar las notas de los alumnos de las
diferentes carreras profesionales de la modalidad
Presencial, Semi-presencial, Distancia, Programa Especial
y Complementación Académica.
 Emitir Actas y Registros de Evaluación a la dirección de las
Carreras Profesionales para distribuir a los docentes de las
asignaturas a su cargo, según la carga lectiva
correspondiente al semestre académico.
 Tramitar con la ANR la elaboración de Carnets
Universitarios de los alumnos de la Modalidad Presencial,
Semi-presencial, Distancia, así como los alumnos de la
Escuela de Post-Grado. Elaborar Record Académicos,

7
Constancias de Biblioteca y Conformidad de Documentos
solicitados por los alumnos de Pre Grado.
 Elaborar los certificados de Estudios en conformidad con
las Actas existentes y en estricto acatamiento a las
calificaciones contenidas en las mismas.
 Elaborar Listados de estudiantes y egresados de Pre
Grado pertenecientes al Tercio y Quinto Superior de
acuerdo a las BD existentes en la Oficina.
 Mantener y custodiar los expedientes de admisión de los
alumnos de las diferentes Carreras Profesionales de la
Modalidad Presencial, Semi-presencial, Distancia,
Programa Especial y Complementación Académica.
 Verificar la correcta convalidación de cursos de los
alumnos ingresantes extraordinarios e ingresar los cuadros
de Convalidación al Sistema Académico utilizado en
OSAERC de los alumnos de Pre Grado.
 Verificar e ingresar la correcta Adecuación al Nuevo Plan
de Estudios de los alumnos que retoman sus estudios y/o
alumnos que se acogen al Nuevo Plan de Estudios.

1.10. ESTRUCTURA TEMÁTICA:

1.10.1. RESUMEN:

El presente proyecto titulado “Desarrollo un Sistema


Informático para gestionar los expedientes en la OSA de la
Universidad José Carlos Mariátegui”. Ha sido desarrollado
con la finalidad de automatizar del control de archivos y así
diversos procesos administrativos, se viene realizando en
varias Universidades nacionales y privadas del Perú.
Logrando una mejora institucional notable.

8
El Sistema de Información que se propone, mantendrá un
control eficiente sobre el monitoreo de los archivos y
expedientes de la universidad y así, apoyar a los diferentes
procesos de gestión y una búsqueda del bienestar y mejor
servicio brindado a la comunidad Universitaria.
La información podrá ser vista en tiempo real, de acuerdo a la
competencia del personal y a la confidencialidad de la
información.
Se tendrá la información necesaria en corto tiempo lo que
permitirá el ahorro de tiempo así como la impresión de
reportes según sean requeridos por los órganos jerárquicos
autorizados.
Reducirá la carga documental de archivos físicos. Y generara
reportes importantes para la toma de decisiones a Nivel
Gerencial.

1.10.2. DESCRIPCIÓN DEL PROBLEMA:

La Universidad José Carlos Mariátegui, Oficina de Servicios


Académicos, Evaluación y Registro Central no cuenta con un
sistema automatizado de Control de Archivos.

1.11. OBJETIVOS DE LAS PRÁCTICAS PRE- PROFESIONALES:

1.11.1. OBJETIVO GENERAL:

 Desarrollar un Sistema Informático para gestionar los


expedientes en la OSA de la Universidad José Carlos
Mariátegui.

9
1.11.2. OBJETIVOS ESPECIFICOS:

 Analizar los principales procesos y actividades del área de


archivo de expedientes, para minimizar tiempos en los
trámites.
 Diseño del sistema informático utilizando la Metodología
OO para la elaboración del sistema web.
 Implementar un prototipo del sistema web utilizando el
lenguaje de programación php.

1.11.3. JUSTIFICACION:

La Universidad José Carlos Mariátegui, apuesta por la


innovación tecnológica y busca alcanzar niveles altos de
calidad en servicios tanto académicos como administrativos
para destacar de entre las universidades.
Por lo tanto la implementación de un Sistema de Información
Web como resultado de una investigación y desarrollo
respectivo, permitirá:

 Agilizar los trámites que se realizan en archivo como


conformidades, envió de documentos que nos solicitan.
 Saber la ubicación exacta del expediente para mejorar el
tiempo de búsqueda.
 Contribuir al desarrollo de la Institución.

10
CAPÍTULO II

2 FUNDAMENTO TEÓRICO:

2.1. PHP:

El PHP (Profesional Home Pages - Páginas Personales


Profesionales) es un lenguaje para la creación de páginas web. Es
una solución para la construcción de Webs con independencia de la
Base de Datos (aunque normalmente se usará MySQL) del servidor
Web (aunque normalmente se usará Apache), válida para cualquier
plataforma (Unix, Windows, Mac). El objetivo final es conseguir la
integración de las páginas HTML con aplicaciones que corran en el
servidor como procesos integrados en el mismo, y no como un
proceso separado, como ocurre con los CGIs (aunque PHP también
puede funcionar como un CGI) . Igualmente interesa que dichas
aplicaciones sean totalmente independientes del navegador (lo que
no ocurre con otros lenguajes basados en scripts como JavaScript o
VisualBasic Script).1

El lenguaje de programación interpretado PHP nació como Personal


Home Page (PHP) Tools. Fue creado por el programador danés
Rasmus Lerdorf en 1994 para la creación de páginas web
dinámicas.2

1
F.Javier Garcia Catellano TUTORIAL DE PHP, disponible en: http://flanagan.urg.es/php/index2.htm.
2
Definicion de PHP – disponible en: http://definicion.de/php/.

11
Figura 2.1 Ejemplo de código PHP.
Fuente: www.flanagan.ugr.es/php/index2.htm.

El acrónimo recursivo, sin embargo, actualmente está vinculado a PHP


Hypertext Pre-Processor. El lenguaje es administrado por The PHP
Group y no cuenta con una especificación formal. La Free Software
Foundation, por lo tanto, considera la licencia PHP como parte del
software libre.

2.2. SISTEMA:

Un sistema es un conjunto de partes o elementos organizados y


relacionados que interactúan entre sí para lograr un objetivo. Los
sistemas reciben (entrada) datos, energía o materia del ambiente y
proveen (salida) información, energía o materia.

Un sistema puede ser físico o concreto (una computadora, un


televisor, un humano) o puede ser abstracto o conceptual (un
software) Cada sistema existe dentro de otro más grande, por lo tanto
un sistema puede estar formado por subsistemas y partes, y a la vez
puede ser parte de un súper sistema.

12
Los sistemas tienen límites o fronteras (Ver: frontera de un sistema),
que los diferencian del ambiente. Ese límite puede ser físico (el
gabinete de una computadora) o conceptual. Si hay algún intercambio
entre el sistema y el ambiente a través de ese límite, el sistema es
abierto, de lo contrario, el sistema es cerrado.3

El ambiente es el medio en externo que envuelve física o


conceptualmente a un sistema. El sistema tiene interacción con el
ambiente, del cual recibe entradas y al cual se le devuelven salidas.
El ambiente también puede ser una amenaza para el sistema.

Sistema es un conjunto de sistemas organizados que interactúan


entre sí y con su ambiente para lograr objetivos comunes, operando
sobre información, sobre energía o materia u organismos para
producir como salida información o energía o materia u organismos.

Elementos de Sistema
Son elementos estructurales de un sistema:
• Elementos: Son los componentes fundamentales del sistema. Un
elemento es la representación simplificada de alguna característica
de la realidad objeto de estudio.
• Relaciones entre elementos o redes de comunicación: Los
elementos o componentes están interrelacionados. En un sistema no
se retienen todas las interacciones entre todos los elementos, sino las
más significativas para los fines concretos con que esté laborando el
sistema. Las redes de comunicación pueden tener un soporte físico o
ser redes o conexiones mentales o abstractas.
• Límites: Un sistema puede tener límites precisos o una zona
llamada interfaz, que lo separa del entorno circundante o de otros

3
Definición de Sistema – disponible en: http://www.alegsa.com.ar/Dic/sistema.php.

13
sistemas, de tal manera que, sin ambigüedad, se sepa si un
determinado elemento o red pertenece o no al sistema.
• El entorno del sistema: aquello que lo rodea, dentro del cual está
ubicado.
Las Elementos funcionales de los sistemas son las siguientes:
• Flujos: Ya sea de materiales, información o energía que circulan
entre variables de estado. Esta circulación se hace a través de las
redes de comunicación y cuenta con dispositivos: válvulas o grifos
que controlan los diversos flujos.
• Redes de retroalimentación: cadenas de causalidad o influencias
circulares entre elementos.

2.3. MySQL:

El software MySQL proporciona un servidor de base de datos SQL


(Structured Query Language) veloz, multi-hilo, multiusuario y robusto.
El servidor está proyectado tanto para sistemas críticos en producción
soportando intensas cargas de trabajo como para empotrarse en
sistemas de desarrollo masivo de software. El software MySQL tiene
licencia dual, pudiéndose usar de forma gratuita bajo licencia GNU o
bien adquiriendo licencias comerciales de MySQL AB en el caso de
no desear estar sujeto a los términos de la licencia GPL. MySQL es
una marca registrada de MySQL AB.

 Uso de MySQL:

MySQL es muy popular en aplicaciones web, y es componente de


las plataformas LAMP, MAMP, WAMP, entre otras. MySQL suele
combinarse con el popular lenguaje PHP.

14
 Características de MySQL:

 MySQL está escrito en C y C++.


 Emplea el lenguaje SQL para consultas a la base de datos.
 MySQL Server está disponible como freeware bajo licencia
GPL.
 MySQL Enterprise es la versión por suscripción para
empresas, con soporte las 24 horas.
 Trabaja en las siguientes plataformas: AIX, BSDi, FreeBSD,
HP-UX, GNU/Linux, Mac OS X, NetBSD, Novell NetWare,
OpenBSD, OS/2 Warp, QNX, SGI IRIX, Solaris, SunOS, SCO
OpenServer, SCO UnixWare, Tru64, Microsoft Windows (95,
98, ME, NT, 2000, XP y Vista).

2.4. DBDesigner (Diseñador de una Base de Datos):

DBDesigner 4 es un sistema visual de diseño de bases de datos que


integra el diseño de bases de datos, modelado, creación u
mantenimiento en un ambiente sencillo y sin complicaciones.
Combina características profesionales con una interfaz de usuario
clara y simple para ofrecer el modo más eficiente de manipular sus
bases de datos.4
DBDesigner 4 es equivalente a productos como Designer de Oracle,
Rational Rose de IBM, ERwinde Computer Associates y DataArchitect
de theKompany pero es un proyecto de código abierto disponible para
Microsoft Windows 2000/XP y Linux KDE/Gnome. Se distribuye bajo
la Licencia Pública General.
DBDesigner 4 está desarrollado y optimizado para la Base de datos
de código abierto MySQL para dar soporte a usuarios de My SQL con
una herramienta de diseño poderosa y disponible en forma gratuita.

4
DBDesigner – disponible en: http//www.freedownloadmanager.org/es/downloads/DBDesigner_4_3178_p/.

15
Todas las características específicas de MySQL han sido construidas
para ofrecer el modo más conveniente de diseñar y mantener el
control de sus bases de da datos de MySQL.

Figura 2.2 Diseño de una Base de Datos en DBDesigner.


Fuente: www.freedownloadmanager.org/es/downloads/DBDesigner_4_3178_p/

2.5. RATIONAL ROSE:

Es una herramienta software para el Modelado Visual mediante UML


de sistemas software.

 Permite Especificar, Analizar, Diseñar el sistema antes de


Codificarlo.

 Características Rational Rose:

 Mantiene la consistencia de los modelos del sistema software.


 Chequeo de la sintaxis UML.
 Generación Documentación automáticamente.
 Generación de Código a partir de los Modelos.
 Ingeniería Inversa (crear modelo a partir código).

16
Figura 2.3 Interfaz de Rational Rose.
Fuente: www.monografias.com/trabajos5/insof/insof.shtml

2.6. 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 información que es utilizada o
producida mediante un proceso de desarrollo de software.

UML se quiere convertir en un lenguaje estándar 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 estándar de
desarrollo, sino únicamente un lenguaje de modelado. Otros métodos
de modelaje como OMT (Object Modeling Technique) o Booch sí
definen procesos concretos. En UML los procesos de desarrollo son
diferentes según los distintos dominios de trabajo; no puede ser el
mismo el proceso para crear una aplicación en tiempo real, que el
proceso de desarrollo de una aplicación orientada a gestión, por
poner un ejemplo.

17
Las diferencias son muy marcadas y afectan a todas las fases del
proceso. El método del UML recomienda utilizar los procesos que
otras metodologías tienen definidos.

 Elementos de UML:

 Diagrama de casos de uso:

Los diagramas de casos de uso describen las relaciones y las


dependencias entre un grupo de casos de uso y los actores
participantes en el proceso.
Es importante resaltar que los diagramas de casos de uso no
están pensados para representar el diseño y no puede
describir los elementos internos de un sistema. Los diagramas
de casos de uso sirven para facilitar la comunicación con los
futuros usuarios del sistema, y con el cliente, y resultan
especialmente útiles para determinar las características
necesarias que tendrá el sistema. En otras palabras, los
diagramas de casos de uso describen qué es lo que debe
hacer el sistema, pero no cómo.

 Caso de uso:

Un caso de uso describe, desde el punto de vista de los


actores, un grupo de actividades de un sistema que
produce un resultado concreto y tangible.
Los casos de uso son descriptores de las interacciones
típicas entre los usuarios de un sistema y ese mismo
sistema. Representan el interfaz externo del sistema y
especifican qué requisitos de funcionamiento debe tener
este (recuerde, únicamente el qué, nunca el cómo).

18
Cuando se trabaja con casos de uso, es importante tener
presentes algunas sencillas reglas:
 Cada caso de uso está relacionado como mínimo con un
actor.
 Cada caso de uso es un iniciador (es decir, un actor).
 Cada caso de uso lleva a un resultado relevante (un
resultado con «valor intrínseco»).
Los casos de uso pueden tener relaciones con otros casos de
uso. Los tres tipos de relaciones más comunes entre casos de
uso son:

 <<include>> que especifica una situación en la que un


caso de uso tiene lugar dentro de otro caso de uso.

 <<extends>> que especifica que en ciertas situaciones, o


en algún punto (llamado punto de extensión) un caso de
uso será extendido por otro.

 Generalización que especifica que un caso de uso hereda


las características del «super» caso de uso, y puede volver
a especificar algunas o todas ellas de una forma muy
similar a las herencias entre clases.

 Actor:

Un actor es una entidad externa (de fuera del sistema) que


interacciona con el sistema participando (y normalmente
iniciando) en un caso de uso. Los actores pueden ser

19
gente real (por ejemplo, usuarios del sistema), otros
ordenadores o eventos externos.5
Los actores no representan a personas físicas o a
sistemas, sino su rol. Esto significa que cuando una
persona interactúa con el sistema de diferentes maneras
(asumiendo diferentes papeles), estará representado por
varios actores. Por ejemplo, una persona que proporciona
servicios de atención telefónica a clientes y realiza pedidos
para los clientes estaría representada por un actor «equipo
de soporte» y por otro actor «representante de ventas».

 Descripción de casos de uso:

Las descripciones de casos de uso son reseñas textuales


del caso de uso. Normalmente tienen el formato de una
nota o un documento relacionado de alguna manera con el
caso de uso, y explica los procesos o actividades que
tienen lugar en el caso de uso.

 Diagrama de Clases:

Los diagramas de clases muestran las diferentes clases que


componen un sistema y cómo se relacionan unas con otras.
Se dice que los diagramas de clases son diagramas
«estáticos» porque muestran las clases, junto con sus
métodos y atributos, así como las relaciones estáticas entre
ellas: qué clases «conocen» a qué otras clases o qué clases
«son parte» de otras clases, pero no muestran los métodos
mediante los que se invocan entre ellas.

5
Ingeniería de Software UML – disponible en: http://www.monografia.com/trabajos5/insof/insof.shtml.

20
 Clase:

Una clase define los atributos y los métodos de una serie


de objetos. Todos los objetos de esta clase (instancias de
esa clase) tienen el mismo comportamiento y el mismo
conjunto de atributos (cada objetos tiene el suyo propio).
En ocasiones se utiliza el término «tipo» en lugar de clase,
pero recuerde que no son lo mismo, y que el término tipo
tiene un significado más general.

 Diagramas de Colaboración:

Los diagramas de colaboración muestran las interacciones


que ocurren entre los objetos que participan en una situación
determinada. Esta es más o menos la misma información que
la mostrada por los diagramas de secuencia, pero destacando
la forma en que las operaciones se producen en el tiempo,
mientras que los diagramas de colaboración fijan el interés en
las relaciones entre los objetos y su topología.

En los diagramas de colaboración los mensajes enviados de


un objeto a otro se representan mediante flechas, mostrando
el nombre del mensaje, los parámetros y la secuencia del
mensaje. Los diagramas de colaboración están indicados para
mostrar una situación o flujo programa específicos y son unos
de los mejores tipos de diagramas para demostrar o explicar
rápidamente un proceso dentro de la lógica del programa.
 Diagrama de Estado:
Los diagramas de estado muestran los diferentes estados
de un objeto durante su vida, y los estímulos que provocan
los cambios de estado en un objeto.

21
Los diagramas de estado ven a los objetos como máquinas
de estado o autómatas finitos que pueden estar en un
conjunto de estados finitos y que pueden cambiar su
estado a través de un estímulo perteneciente a un conjunto
finito. Por ejemplo, un objeto de tipo NetServer puede tener
durante su vida uno de los siguientes estados:

 Listo.
 Escuchando.
 Trabajando.
 Detenido.

y los eventos que pueden producir que el objeto cambie de


estado son

 Se crea el objeto.
 El objeto recibe un mensaje de escucha.
 Un cliente solicita una conexión a través de la red.
 Un cliente finaliza una solicitud.
 La solicitud se ejecuta y ser termina.
 El objeto recibe un mensaje de detención, etc.

 Diagrama de Actividad:

Los diagramas de actividad describen la secuencia de las


actividades en un sistema. Los diagramas de actividad son
una forma especial de los diagramas de estado, que
únicamente (o mayormente) contienen actividades.
Los diagramas de actividad soportan actividades tanto
secuenciales como paralelas. La ejecución paralela se

22
representa por medio de iconos de fork/espera, y en el caso
de las actividades paralelas, no importa en qué orden sean
invocadas (pueden ser ejecutadas simultáneamente o una
detrás de otra).6

 Diagramas de Componentes:

Los diagramas de componentes muestran los componentes


del software (ya sea las tecnologías que lo forman como
Kparts, componentes CORBA, Java Beans o simplemente
secciones del sistema claramente distintas) y los artilugios de
que está compuesto como los archivos de código fuente, las
librerías o las tablas de una base de datos.

Los componentes pueden tener interfaces (es decir clases


abstractas con operaciones) que permiten asociaciones entre
componentes.

 Diagramas de Implementación:

Los diagramas de implementación muestran las instancias


existentes al ejecutarse así como sus relaciones. También se
representan los nodos que identifican recursos físicos,
típicamente un ordenador así como interfaces y objetos
(instancias de las clases).

6
Introducción a UML – disponible en: http://docs.kde.org/stable/es/kdesdk/umbrello/uml-elements.html.

23
Figura 2.4 Ejemplo UML Diagrama de Clases.
Fuente: www.fabforce.net/dbdesigner4/images/ss/dbd4_ss_simplemodel.png

2.7. SGBD:

Sistema de Gestión de Base de Datos o en Ingles Database


management system (DBMS), es una agrupación de programas que
sirven para definir, construir y manipular una Base de Datos.7

En la manipulación de la base de datos, los SGBD deben incluir un


control de concurrencia, ósea deben permitir a varios usuarios tener
acceso “simultaneo” a la base de datos. Controlar la concurrencia
implica que si varios usuarios acceden a la base de datos, la
actualización de los datos se haga de forma controlada para que no
haya problemas.

7
Carmen B. Navarrete – Centro de Referencia Linux UAM – IBM, Publicación “Introducción a las Bases de Datos”.2003, pág 35.

24
2.8. MODELO OOHDM o Método de Diseño de Hipermedia Orientado

a. Objetos:

El modelo OOHDM u Object Oriented Hypermedia Design


Methodology, para diseño de aplicaciones hipermedia y para la Web,
fue diseñado por D. Schwabe, G. Rossi, and S. D. J. Barbosa y es
una extensión de HDM con orientación a objetos, que se está
convirtiendo en una de las metodologías más utilizadas. Ha sido
usada para diseñar diferentes tipos de aplicaciones hipermedia como
galerías interactivas, presentaciones multimedia y, sobre todo,
numerosos sitios web.

Al igual que RMM, este método se inspira en el modelo HDM, pero lo


que le distingue claramente del primero es el proceso de concepción
orientado a objetos. OOHDM propone el desarrollo de aplicaciones
hipermedia mediante un proceso de 4 etapas:

- Diseño Conceptual.
- Diseño Navegacional.
- Diseño de Interfaces Abstractas.
- Implementación.

Cada etapa de la concepción define un esquema objeto específico en


el que se introducen nuevos elementos (clases).

En la primera etapa se construye un esquema conceptual


representado por los objetos de dominio o clases y las relaciones
entre dichos objetos. Se puede usar un modelo de datos semántico
estructural (como el modelo de entidades y relaciones). El modelo
OOHDM propone como esquema conceptual basado en clases,
relaciones y subsistemas.

25
En la segunda etapa, el diseñador define clases navegacionales tales
como nodos, enlaces y estructuras de acceso (índices y visitas
guiadas) inducidas del esquema conceptual. Los enlaces derivan de
las relaciones y los nodos representan ventanas lógicas (views) sobre
las clases conceptuales. A continuación, el diseñador describe la
estructura navegacional en términos de contextos navegacionales. Un
contexto navegacional es un conjunto de nodos, enlaces, clases de
contextos y otros contextos navegacionales (contextos anidados) -
igual que en HDM definen agrupaciones- que pueden ser definidos
por comprensión o extensión, o por enumeración de sus miembros.

Los nodos se enriquecen con un conjunto de clases especiales que


permiten presentar atributos así como métodos o comportamientos
cuando se navega en un contexto particular. Durante esta etapa, es
posible adaptar los objetos navegacionales para cada contexto, de
forma similar a las perspectivas de HDM.

OOHDM no propone un modelo enriquecido para el dominio de la


aplicación, por lo que deja libre al diseñador para elegir el modelo de
especificación del dominio. Sin embargo, el modelo hipermedia está
definido en dos niveles de abstracción: las clases navegacionales y
los contextos navegacionales. En el momento de la especificación de
las clases navegacionales es cuando el diseñador define las
correspondencias y, aunque OOHDM sugiere algunas, no impone
metáforas preestablecidas tan sistemáticamente como RMM. Los
nodos inducidos de las clases del modelo del dominio y los enlaces
inducidos de las relaciones del modelo del dominio se pueden
precisar. Como el segundo nivel está consagrado a la especificación
de la navegación, expresada exclusivamente sobre los objetos
navegacionales (no sobre los elementos del modelo del dominio),

26
constituye un mecanismo que permite enriquecer el modelo
hipermedia.

La tercera etapa está dedicada a la especificación de la interfaz


abstracta. Así, se define la forma en la cual deben aparecer los
contextos navegacionales. También se incluye aquí el modo en que
dichos objetos de interfaz activarán la navegación y el resto de
funcionalidades de la aplicación, esto es, se describirán los objetos de
interfaz y se los asociará con objetos de navegación. La separación
entre el diseño navegacional y el diseño de interfaz abstracta
permitirá construir diferentes interfaces para el mismo modelo
navegacional.

Por fin, la cuarta etapa, dedicada a la puesta en práctica, es donde se


hacen corresponder los objetos de interfaz con los objetos de
implementación.

Aunque los ejemplos que ilustran el método sean siempre del mismo
tipo, OOHDM es un método abierto porque, por una parte, el modelo
del dominio no viene impuesto y por otra parte, el soporte en objetos
del método permite la especialización de las clases navegacionales y
de los contextos navegacionales. El objetivo de OOHDM es cubrir la
concepción de todo tipo de aplicaciones hipermedia.8

2.8.1. MODELO CONCEPTUAL:

“Durante la primera fase se realiza el modelado del dominio


del hiperdocumento utilizando algún método análisis orientado
a objetos de Sistemas de Información, por ejemplo OMT,
obteniendo así un esquema conceptual de clases en el que,

8
Modelado OOHDM - disponible en: http//www.hipertexto.info/documentos/oohdm.htm

27
además de clases abstractas y objetos, se representan las
relaciones entre ellas, incluidas las de herencia y agregación,
y los correspondientes atributos (que pueden ser de cualquier
tipo, desde simples cadenas de caracteres a gráficos,
imágenes, texto, sonido, etc.) y métodos asociados a las
clases”.9

2.8.2. DISEÑO NAVEGACIONAL:

La primera generación de aplicaciones de multimedia


intentaba realizar la navegación a través de un espacio de
información usando un solo modelo de datos de hipermedia.
A pesar de estos problemas que son bien conocidos en la
comunidad de la hipermedia, ellos raramente han sido
tomados en cuenta por los diseñadores de Multimedia y Web
Sites.

El mayor esfuerzo de diseño normalmente se ha puesto en


aspectos de interfaz del usuario y la estructura de la
navegación se construye en jerarquías simples. Ahora que los
navegadores (Browser) de Web son la interfaz, y a veces el
Host, para los tipos diferentes de aplicaciones, hay un riesgo
en la navegación a ser considerada simplemente otro tipo de
comportamiento de aplicación. En OOHDM, la navegación es
considerada un paso crítico en el diseño de una aplicación de
hipermedia. Un Modelo de navegación se construye como
una vista más de un modelo conceptual y permite la
construcción de modelos diferentes según los perfiles

9
Daniel Schwabe y Gustavo Ross, disponible en: http://www.di.inf.puc-rio.br/schwabe/papers/TAPOSRevised.pdf

28
diferentes de los usuarios. Cada modelo de navegación
proporciona una vista "Subjetiva" del modelo conceptual.10

2.8.3. DISEÑO DE INTERFAZ ABSTRACTA:11

Una vez que las aplicaciones de estructura navegacional han


sido definidos, se debe especificar ahora aspectos de la
interfaz. Esto significa definir la manera en que diferentes
objetos de navegación aparecerán, qué objetos de
navegación de la interfaz se activara y otra funcionalidad de
aplicación, y qué transformaciones de la interfaz tendrán lugar
y cuando.

Una separación ordenada entre ambas preocupaciones, de


navegación y diseño de interfaz abstracta, permite construir
interfaces diferentes para el mismo modelo de navegación,
llevando a un grado más alto de independencia de tecnología
de la interfaz de usuario. En suma, esta separación permite
entender mejor la aplicación global de la estructura para
indicar qué transformaciones claramente en la interfaz serán
transformaciones navegacionales.

2.8.4. IMPLEMENTACIÓN:

En esta fase, el diseñador realmente implementará el diseño.


Hasta ahora, todos los modelos fueron deliberadamente
construidos de semejante manera en lo que se refiere a ser
independiente de la plataforma de implementación; en esta

10
Carvalho, G Rossi, disponible en: http://www.di.inf.puc-rio.br/schwabe/HT96WWW/section3.html
11
Coleman Introducción Orientado a Objetos, disponible en http://www.di.inf.puc-rio.br/schwabe/HT96WWW/section3.html

29
fase el ambiente particular de (tiempo de ejecución) runtime
se toma el derecho de acceso a un servidor o a la red
internet. A continuación se fijará cómo los diseños de
OOHDM pueden ser implementados en el WWW, tener
cuidado para no arreglar una sola alternativa, desde que hay
muchos acercamientos posibles a través de los cuales esto
puede ser logrado.

Cuando la fase de implementación se alcanza, el diseñador


ya tiene definido los artículos de información que son parte
del dominio del problema.

2.9. ANÁLISIS ORIENTADA A OBJETOS:

El análisis orientado a objetos, es desarrollar una serie de modelos


que describan el software de computadora al trabajar para satisfacer
un conjunto de requisitos definidos por el cliente. El AOO forma un
modelo de análisis multiparte para satisfacer este objetivo. El modelo
de análisis ilustra información, funcionamiento y comportamiento
dentro del contexto de los elementos del modelo de objetos.12

12
Ingeniería de software, un enfoque práctico, Roger S. Pressman, 5aEdición, pág. 133

30
CAPÍTULO III

3 MATERIAL Y MÉTODO UTILIZADO EN LAS PRÁCTICAS


PREPROFESIONALES:

3.1. MATERIALES:

3.1.1. RECURSOS HUMANOS:


CANTIDAD RECURSO HUMANO
CANTIDAD RECURSO HUMANO
01 Analista de Sistemas.
01 Diseñador de Sistemas
01 Programador de Sistemas
Todos los Roles son Asumidos por:
Bachiller. Samir Iván Benavente Condori

Tabla 3.1 Recursos Humanos


Fuente: Propia

3.1.2. RECURSOS DE HARDWARE

 01 Laptop Intel(R) Core(TM)i7 CPU


 Procesador : Intel(R) Core(TM) i7 CPU
Q720 @ 1.60GHz.
 Memoria : RAM de 4.00 GB
 Disco Duro : 500 GB
 Sistema Operativo : Windows 10
 Tarjeta de Sonido y Audio :NVIDIA High
Definition Audio.
 01 Impresora Láser Jet 1610.

31
3.1.3. RECURSOS DE SOFTWARE:

 Microsoft Windows 7.
 Microsoft Office 2007 (Microsoft Excel y Microsoft Word).
 DBDesigner, para el modelamiento Web.
 Rational Rose Enterprise Edition v.2003.
 XAMPP Para Windows.
 Apache Web Server Version 2.2.4.
 PHP Script Language Version 5.2.3.
 MySQL Database Version 5.0.45.
 Notepad++ v5.6.6 para la programación, tanto para el
código HTML como código PHP.
 Navicat 8 for MySQL.

3.2. METODOLOGÍA:

La Metodología utilizada es OOHDM (Object Oriented Hypermedia


Design Method), por lo que la metodología elegida es un método para
el desarrollo de aplicaciones web.

Los modelos orientados a objetos se construyen en cada paso que


mejora los modelos diseñados en iteraciones anteriores y consta de
las siguientes fases:

 Análisis del Sistema.


 Fase Conceptual.
 Fase Navegacional.
 Fase de Interfaz Abstracta.

32
 Fase de Implementación.

3.3. ANÁLISIS DEL SISTEMA:

3.3.1. IDENTIFICACIÓN DEL PROYECTO:

a) TÍTULO:
Desarrollo de un Sistema Informático para la
Administración de Expedientes de la Universidad José
Carlos Mariátegui.

b) DESCRIPCIÓN:
Es un sistema Web que mediante sus módulos se puede
administrar los expedientes de los alumnos de la UJCM.

c) AUTOR:
Bach. Samir Iván Benavente Condori

3.3.2. DESARROLLO DEL SISTEMA SISCOD:

3.3.2.1. DIAGRAMA GENERAL DEL SISTEMA

33
Figura 3.1 Diagrama General del Sistema
Fuente: Propia

34
3.3.2.2. DIAGRAMA DE CASO DE USO:

 A) SUB - SISTEMA DE OFICINAS

Figura 3.2 Diagrama de Gestión de Actores


Fuente: Propia

ACT 001 PERSONAL DE ARCHIVO

Descripción Actor que representa a la persona


que tiene permisos para
gestionar todo el sistema.

Comentario También llamado personal.

ACT 001 PERSONAL DE ARCHIVO

Descripción Actor que representa a la oficina que


solicita o interactúa con los
expedientes.

Comentario También llamado usuario.

35
Figura 3.3 Diagrama de Gestión de usuarios
Fuente: Propia

DESCRIPCIÓN DE CASO DE USO:

CU-001 NUEVO USUARIO

Versión 1.0

Actor ACT 001

Descripción El sistema deberá comportarse


tal como se describe en
este C.U. cuando
seleccione “nuevo”.

CU-002 BUSCAR

Versión 1.0

Actor ACT 001

Descripción El sistema deberá comportarse tal como


se describe en este C.U. cuando
seleccione “BUSCAR”.

36
Dependencias -

Precondición -

Secuencias Normal N Acción

1 El Actor (ACT 001) realiza la


búsqueda

2 El sistema muestra los resultados


de la búsqueda.

3 El Actor (ACT 001) selecciona de


entre los resultados el
expediente deseado y el caso
de uso finaliza correctamente.

Post condición -

Excepciones N Acción

1 Si el sistema no encuentra
resultados para la búsqueda,
el sistema se lo indica al actor
y vuelve al paso 1, a
continuación este caso de uso
continúa.

Comentarios Ninguno.

CU-003 MODIFICAR

Versión 1.0

Actor ACT 001

Descripción El sistema deberá comportarse tal como


se describe en este C.U. cuando
seleccione “MODIFICAR”.

Dependencias -

Precondición -

Secuencia normal N Acción

1 Se realiza el caso de uso Buscar


(CU-002)

37
2 El Actor (ACT 001) realiza los
cambios.

3 El Actor (ACT 001) selecciona


Aceptar cambios.

4 El sistema evalúa si los datos


introducidos son válidos.

5 El sistema pide confirmación sobre


los datos introducidos.

6 El Actor (ACT 001) confirma la


petición

7 El sistema realiza las


modificaciones y el caso de
uso finaliza con éxito.

Post condición La base de datos ha de estar en un


estado consistente

Excepciones N Acción

1 Si la búsqueda no finalizo
exitosamente, el sistema
finaliza el caso de uso, a
continuación este caso de uso
queda sin efecto.

4 Si los datos introducidos no son


válidos, el sistema vuelve al
paso 2, a continuación este
caso de uso continua.

6 Si el actor (ACT-001) no confirma la


modificación, el sistema
finaliza el caso de uso, a
continuación este caso de uso
queda sin efecto.

Comentarios En cualquier momento el Actor (ACT 001)


puede seleccionar “Cancelar” y salir
del caso de uso sin realizar ningún
cambio (la cancelación deberá
confirmarse).

38
CU-004 ELIMINAR

Versión 1.0

Actor ACT 001

Descripción El sistema deberá comportarse tal como


se describe en este C.U. cuando
seleccione “ELIMINAR USUARIO”.

Dependencias -

Precondición -

Secuencia normal N Acción

1 Se realiza el caso de uso Buscar


(CU-002)

2 El Actor (ACT 001) confirma que


desea eliminar un Usuario.

3 El sistema elimina el usuario de la


B.D.

4 El sistema finaliza el caso de uso.

Post condición La base de datos ha de estar en un


estado consistente

Excepciones N Acción

1 Si la búsqueda no finalizo
exitosamente, el sistema
finaliza el caso de uso, a
continuación este caso de
uso queda sin efecto.

2 Si no lo confirma, el sistema refleja


la excepción, a continuación
este caso de uso queda sin
efecto.

Comentarios Ninguno.

39
B) SUB - SISTEMA DE EXPEDIENTES

 BÚSQUEDA DE DOCUMENTO RECIBIDO:

Figura 3.4 Diagrama de Gestión de Archivo:


Fuente: Propia

CU-005 MODIFICAR EXPEDIENTE

Versión 1.0

Actor ACT 001

Descripción El sistema deberá comportarse tal como se


describe en este C.U. cuando seleccione
“MODIFICAR EXPEDIENTE” En este

40
módulo se podrá agregar más documentos
al expediente del Alumno.

Dependencias -

Precondición El alumno debe estar registrado en la Base


de Datos.

Secuencias N° Acción
Normal
1 El Actor (ACT 001) realiza la
búsqueda (CU 002)

2 El sistema muestra los resultados de


la búsqueda.

3 El Actor (ACT 001) selecciona de


entre los resultados el expediente del
alumno deseado.

4 Agrega los documentos a su


expediente.

5 Confirma y finaliza el caso de Uso.

Post condición -

Excepciones N Acción

1 Si el sistema no encuentra resultados


para la búsqueda, el sistema se lo
indica al actor y vuelve al paso 1, a
continuación este caso de uso
continúa.

5 Si el Actor (ACT 001) no confirma, no


se guardaran los cambios.

Comentarios El Actor (ACT 001) podrá cancelar en


cualquier momento el caso de Uso.

CU-006 ELIMINAR EXPEDIENTE

Versión 1.0

Actor ACT 001

Descripción El sistema deberá comportarse tal como se


describe en este C.U. cuando seleccione

41
“ELIMINAR EXPEDIENTE” En este caso de
uso se podrá eliminar documentos en caso
de haber llenado mal.

Dependencias -

Precondición El alumno debe estar registrado en la Base


de Datos.

Secuencias N Acción
Normal
1 El Actor (ACT 001) realiza la
búsqueda (CU 002)

2 El sistema muestra los resultados de


la búsqueda.

3 El Actor (ACT 001) selecciona de


entre los resultados el expediente del
alumno deseado.

4 Elimina el expediente seleccionado.

5 Confirma y finaliza el caso de Uso.

Post condición -

Excepciones N Acción

1 Si el sistema no encuentra resultados


para la búsqueda, el sistema se lo
indica al actor y vuelve al paso 1, a
continuación este caso de uso
continúa.

5 Si el Actor (ACT 001) no confirma, no


se guardaran los cambios.

Comentarios  El Actor (ACT 001) podrá cancelar en


cualquier momento el caso de Uso.
 Al eliminar un expediente se eliminara
al alumno así como también todos los
movimientos y traslados que el alumno
realizo; por lo cual esta función deberá
de usarse con la seguridad del caso.

42
CU-007 VER EXPEDIENTE

Versión 1.0

Actor ACT 001

Descripción El sistema deberá comportarse tal como se


describe en este C.U. cuando seleccione
“VER EXPEDIENTE”.

Dependencias -

Precondición El alumno debe estar registrado en la Base


de Datos.

Secuencias N Acción
Normal
1 El Actor (ACT 001) realiza la
búsqueda (CU 002)

2 El sistema muestra los resultados de


la búsqueda.

3 El Actor (ACT 001) selecciona de


entre los resultados el expediente del
alumno deseado.

4 El sistema muestra detalles del


expediente.

Post condición -

Excepciones N Acción

1 Si el sistema no encuentra resultados


para la búsqueda, el sistema se lo
indica al actor y vuelve al paso 1, a
continuación este caso de uso
continúa.

Comentarios Ninguno

CU-008 TRASLADAR EXPEDIENTE

43
Versión 1.0

Actor ACT 001

Descripción El sistema deberá comportarse tal como se


describe en este C.U. cuando seleccione
“TRASLADAR EXPEDIENTE”

Dependencias -

Precondición El alumno debe estar registrado en la Base


de Datos.

Secuencias N Acción
Normal
1 El Actor (ACT 001) realiza la
búsqueda (CU 002)

2 El sistema muestra los resultados de


la búsqueda.

3 El Actor (ACT 001) selecciona de


entre los resultados el expediente del
alumno deseado.

4 El Actor (ACT 001) modifica la


ubicación del expediente según el
documento.

5 Confirma y finaliza el caso de Uso.

Post condición -

Excepciones N Acción

1 Si el sistema no encuentra resultados


para la búsqueda, el sistema se lo
indica al actor y vuelve al paso 1, a
continuación este caso de uso
continúa.

5 Si el Actor (ACT 001) no confirma, no


se guardaran los cambios.

Comentarios El Actor (ACT 001) podrá cancelar en


cualquier momento el caso de Uso.

44
CU-009 AGREGAR DOCUMENTOS

Versión 1.0

Actor ACT 001

Descripción El sistema deberá comportarse tal como se


describe en este C.U. cuando seleccione
“AGREGAR DOCUMENTOS”

Dependencias (CU 005) Modificar Expediente.

Precondición El alumno debe estar registrado en la Base


de Datos.

Secuencias N Acción
Normal
1 El Actor (ACT 001) realiza la búsqueda
(CU 002)

2 El sistema muestra los resultados de la


búsqueda.

3 El Actor (ACT 001) selecciona de entre


los resultados el expediente del
alumno deseado.

4 El Actor (ACT 001) agrega nuevos


documentos.

5 Confirma y finaliza el caso de Uso.

Post condición -

Excepciones N Acción

1 Si el sistema no encuentra resultados


para la búsqueda, el sistema se lo
indica al actor y vuelve al paso 1, a
continuación este caso de uso
continúa.

5 Si el Actor (ACT 001) no confirma, no


se guardaran los cambios.

45
Comentarios El Actor (ACT 001) podrá cancelar en
cualquier momento el caso de Uso.

CU-010 RETIRAR EXPEDIENTE

Versión 1.0

Actor ACT 001

Descripción El sistema deberá comportarse tal como se


describe en este C.U. cuando seleccione
“RETIRAR EXPEDIENTE”. Este caso de
uso se dará cuando un alumno tramite su
retiro de la Universidad por razones
personales.

Dependencias (CU 005) Modificar Expediente.

Precondición El alumno debe estar registrado en la Base


de Datos.

Secuencias N Acción
Normal
1 El Actor (ACT 001) realiza la
búsqueda (CU 002)

2 El sistema muestra los resultados de


la búsqueda.

3 El Actor (ACT 001) selecciona de


entre los resultados el expediente del
alumno deseado.

4 El Actor (ACT 001) ejecuta retiro de


alumno.

5 Confirma y finaliza el caso de Uso.

Post condición -

46
Excepciones N Acción

1 Si el sistema no encuentra resultados


para la búsqueda, el sistema se lo
indica al actor y vuelve al paso 1, a
continuación este caso de uso
continúa.

5 Si el Actor (ACT 001) no confirma, no


se guardaran los cambios.

Comentarios El Actor (ACT 001) podrá cancelar en


cualquier momento el caso de Uso.

CU-011 EGRESAR

Versión 1.0

Actor ACT 001

Descripción El sistema deberá comportarse tal como se


describe en este C.U. cuando seleccione
“EGRESAR”. Este caso de uso se dará
cuando un alumno tramite constancia de
Egresado.

Dependencias (CU 005) Modificar Expediente.

Precondición El alumno debe estar registrado en la Base


de Datos.

47
Secuencias N Acción
Normal
1 El Actor (ACT 001) realiza la
búsqueda (CU 002)

2 El sistema muestra los resultados de


la búsqueda.

3 El Actor (ACT 001) selecciona de


entre los resultados el expediente del
alumno deseado.

4 El Actor (ACT 001) modifica el


estado del expediente.

5 Confirma y finaliza el caso de Uso.

Post condición -

Excepciones N Acción

1 Si el sistema no encuentra resultados


para la búsqueda, el sistema se lo
indica al actor y vuelve al paso 1, a
continuación este caso de uso
continúa.

5 Si el Actor (ACT 001) no confirma, no


se guardaran los cambios.

Comentarios El Actor (ACT 001) podrá cancelar en


cualquier momento el caso de Uso.

C) SUB - SISTEMA DE ALUMNOS

 BÚSQUEDA DE DOCUMENTO EMITIDO:

48
Figura 3.5 Diagrama de Gestión de Alumnos
Fuente: Propia.

CU-012 NUEVO ALUMNO

Versión 1.0

Actor ACT 001

Descripción El sistema deberá comportarse tal


como se describe en este C.U.
cuando seleccione “NUEVO
ALUMNO”.

CU-013 MODIFICAR

Versión 1.0

Actor ACT 001

49
Descripción El sistema deberá comportarse tal como se
describe en este C.U. cuando seleccione
“MODIFICAR” (Datos del Alumno) En este
modulo se modificaran datos del Alumno.

Dependencias -

Precondición El alumno debe estar registrado en la Base


de Datos.

Secuencias N Acción
Normal
1 El Actor (ACT 001) realiza la
búsqueda (CU 002)

2 El sistema muestra los resultados de


la búsqueda.

3 El Actor (ACT 001) selecciona de


entre los resultados al alumno
deseado.

4 Modifica datos del alumno.

5 Confirma y finaliza el caso de Uso.

Post -
condición

Excepciones N Acción

1 Si el sistema no encuentra
resultados para la búsqueda, el
sistema se lo indica al actor y
vuelve al paso 1, a continuación
este caso de uso continúa.

5 Si el Actor (ACT 001) no confirma,


no se guardaran los cambios.

Comentarios El Actor (ACT 001) podrá cancelar en


cualquier momento el caso de Uso.

CU-014 ELIMINAR

50
Versión 1.0

Actor ACT 001

Descripción El sistema deberá comportarse tal como se


describe en este C.U. cuando seleccione
“ELIMINAR” (Datos del Alumno).

Dependencias -

Precondición El alumno debe estar registrado en la Base de


Datos.

Secuencias N Acción
Normal
1 El Actor (ACT 001) realiza la búsqueda
(CU 002)

2 El sistema muestra los resultados de la


búsqueda.

3 El Actor (ACT 001) selecciona de entre


los resultados al alumno deseado.

4 Elimina registro del alumno.

5 Confirma y finaliza el caso de Uso.

Post condición -

Excepciones N Acción

1 Si el sistema no encuentra resultados


para la búsqueda, el sistema se lo indica
al actor y vuelve al paso 1, a
continuación este caso de uso continúa.

5 Si el Actor (ACT 001) no confirma, no se


guardaran los cambios.

Comentarios El Actor (ACT 001) podrá cancelar en cualquier


momento el caso de Uso.

51
D) SUB - SISTEMA DE ADMINISTRACIÓN

Figura 3.6 Diagrama de Administración del Sistema.


Fuente: Propia

Podemos hallar las siguientes relaciones:

52
Figura 3.7 Diagrama de Administración de Especialidad
Fuente: Propia.

Figura 3.8 Diagrama de Administración de Facultad


Fuente: Propia

Figura 3.9 Diagrama de Administración de Sedes


Fuente: Propia

53
Figura 3.10 Diagrama de Administración de Documentos
Fuente: Propia

DIAGRAMA DE ADMINISTRACIÓN DEL SISTEMA:

CU-015 MODIFICAR

Versión 1.0

Actor ACT 001

Descripción El sistema deberá comportarse tal como se


describe en este C.U. cuando seleccione
“MODIFICAR” En este modulo se
modificaran datos.

Dependencias -

Precondición

Secuencias N Acción
Normal

1 El Actor (ACT 001) realiza la


búsqueda (CU 002)

54
2 El sistema muestra los resultados de
la búsqueda.

3 El Actor (ACT 001) selecciona de


entre los resultados el deseado.

4 Modifica datos del Sistema.

5 Confirma y finaliza el caso de Uso.

Post condición -

Excepciones N Acción

1 Si el sistema no encuentra resultados


para la búsqueda, el sistema se lo
indica al actor y vuelve al paso 1, a
continuación este caso de uso
continúa.

5 Si el Actor (ACT 001) no confirma, no


se guardaran los cambios.

Comentarios El Actor (ACT 001) podrá cancelar en


cualquier momento el caso de Uso.

CU-016 NUEVO

Versión 1.0

Actor ACT 001

Descripción El sistema deberá comportarse


tal como se describe en este
C.U. cuando seleccione
“nuevo”.

CU-017 ELIMINAR

55
Versión 1.0

Actor ACT 001

Descripción El sistema deberá comportarse tal como se


describe en este C.U. cuando seleccione
“ELIMINAR”.

Dependencias -

Precondición -

Secuencia N Acción
normal
1 Se realiza el caso de uso Buscar (CU-
002)

2 El Actor (ACT 001) confirma que


desea eliminar.

3 El sistema elimina de la B.D.

4 El sistema finaliza el caso de uso.

Post condición La base de datos ha de estar en un estado


consistente

Excepciones N Acción

1 Si la búsqueda no finalizo
exitosamente, el sistema finaliza el
caso de uso, a continuación este caso
de uso queda sin efecto.

2 Si no lo confirma, el sistema refleja la


excepción, a continuación este caso
de uso queda sin efecto.

Comentarios Ninguno.

56
Personal de Archivo

ACT-001 PERSONAL DE ARCHIVO

Versión: 1.0 ( 27/009/2016 )

Autor: Samir Ivan Benavente Condori

Fuentes:

Descripción: Este actor representa la


persona que tiene permisos
para gestionar todo el sistema

Comentarios: Ninguno

Administrativo

ACT-002 Administrativo

Versión: 1.0 ( 27/09/2016 )

Autor: Samir Ivan Benavente Condori

Fuentes:

Descripción: Este actor representa la


persona que interacciona con
los expedientes

Comentarios: Ninguno

57
3.4. MODELO CONCEPTUAL:

3.4.1. DIAGRAMA DE CLASES:

SEDE ALUMNO
ALUCOD: INTEGER ESPECIALIDAD
SEDECOD: INTEGER FACULTAD
ALUCOD: INTEGER (FK) ADMCOD: INTEGER (FK) ESPCOD: CHAR(18)
FACCOD: INTEGER FACCOD: INTEGER (FK)
ADMCOD: INTEGER (FK) ALUAPE: CHAR(50) ALUCOD: INTEGER (FK) ALUCOD: INTEGER (FK)
SEDENOM: CHAR(18) ALUNOM: CHAR(50) ADMCOD: INTEGER (FK) ADMCOD: INTEGER (FK)
ESPCOD: CHAR(10)
FACCOD: CHAR(10) FACNOM: CHAR(18) ESPNOM: CHAR(18)
ADMIN
SEDECOD: CHAR(10)
ADMCOD: INT
ADMAPE: VARCHAR(20)
ADMNOM: VARCHAR(20)
ADMUSER: VARCHAR(20) EXPEDIENTE
ADMPASS: VARCHAR(20) DOCUMENTO EXPCOD: INTEGER
DOCCOD: INTEGER ALUCOD: INTEGER (FK) TRASLADO
TIPODOCUMENTO EXPCOD: INTEGER (FK) ADMCOD: INTEGER (FK) TRASCOD: INTEGER
TIPODOCCOD: CHAR(50) ALUCOD: INTEGER (FK) ALUCOD: INTEGER (FK)
EXPUBIC: CHAR(18)
DOCCOD: CHAR(10) (FK) ADMCOD: INTEGER (FK) ADMCOD: INTEGER (FK)
EXPEST: CHAR(18)
EXPCOD: INTEGER (FK) MODODOCCOD: CHAR(18) TRASDOC: CHAR(18)
ALUCOD: INTEGER (FK) TIPODOCCOD: CHAR(18) FACCODO: CHAR(18)
ADMCOD: INTEGER (FK)
PRESTAMO FACCODD: CHAR(18)
TIPODOCNOM: CHAR(18) PRESCOD: INTEGER ESPCODO: CHAR(18)
EXPCOD: INTEGER (FK) ESPCODD: CHAR(18)
ALUCOD: INTEGER (FK) SEDECODO: CHAR(18)
MODODOCUMENTO OFICINA ADMCOD: INTEGER (FK) SEDECODD: CHAR(10)
MODODOCCOD: INTEGER TRASFEC: CHAR(18)
OFICOD: INTEGER ESPCOD: CHAR(10) TRASCOM: CHAR(50)
DOCCOD: INTEGER (FK) PRESCOD: INTEGER (FK) PRESFECP: CHAR(18)
EXPCOD: INTEGER (FK) EXPCOD: INTEGER (FK) PRESFECD: CHAR(18)
ALUCOD: INTEGER (FK) ALUCOD: INTEGER (FK) PRESDOCP: CHAR(50)
ADMCOD: INTEGER (FK) ADMCOD: INTEGER (FK) PRESDOCD: CHAR(50)
MODODOCNOM: CHAR(18) OFINOM: CHAR(50) PRESCOMP: CHAR(50)
PRESCOMD: CHAR(18)

Figura 3.11 Diagrama de clases


Fuente: Propia

58
3.5. DISEÑO NAVEGACIONAL:
3.5.1. DIAGRAMA DE COMPONENTES:
A. ESTRUCTURA DEL SISTEMA:

Figura 3.12 Diagrama de componentes estructura del sistema


Fuente: Propia

59
3.5.1.1. MENÚ DEL ADMINISTRADOR:

Figura 3.13 Diagrama de componentes menú del administrador


Fuente: Propia

60
3.5.1.2. MENÚ DEL USUARIO:

Figura 3.14 Diagrama de componentes menú del usuario


Fuente: Propia

61
3.5.2. DIAGRAMA DE DESPLIEGUE:
A. DISTRIBUCIÓN FÍSICA DEL SISTEMA:

Figura 3.15 Diagrama de despliegue distribución física del sistema


Fuente: Propia

62
3.6. DISEÑO DE LA INTERFAZ ABSTRACTA:

Figura 3.16 Interfaz de Documento Emitido


Fuente: Propia

63
Figura 3.17 Interfaz de Documento Emitido
Fuente: Propia

64
Figura 3.18 Interfaz de Consulta Documento Emitido.
Fuente: Propia

65
Figura 3.19 Interfaz de Consulta Documento Remite.
Fuente: Propia

66
3.6.1. MODELO DE LA BASE DE DATOS:

SEDE FACULTAD ESPECIALIDAD


ALUMNO
SEDECOD: int FACCOD: int ESPCOD: char(18)
ALUCOD: int FACCOD: int (FK)
ALUCOD: int (FK) ADMCOD: int (FK) ALUCOD: int (FK)
ADMCOD: int (FK) ADMCOD: int (FK) ALUCOD: int (FK)
ADMCOD: int (FK)

ADMIN
ADMCOD: int

TIPODOCUMENTO
DOCUMENTO
TIPODOCCOD: char(50) EXPEDIENTE
DOCCOD: int
DOCCOD: char(10) (FK) EXPCOD: int
EXPCOD: int (FK)
EXPCOD: int (FK) ALUCOD: int (FK)
ALUCOD: int (FK)
ALUCOD: int (FK) ADMCOD: int (FK)
ADMCOD: int (FK)
ADMCOD: int (FK) TRASLADO
TRASCOD: int
ALUCOD: int (FK)
MODODOCUMENTO ADMCOD: int (FK)
PRESTAMO
MODODOCCOD: int
PRESCOD: int
DOCCOD: int (FK)
OFICINA EXPCOD: int (FK)
EXPCOD: int (FK)
OFICOD: int ALUCOD: int (FK)
ALUCOD: int (FK)
PRESCOD: int (FK) ADMCOD: int (FK)
ADMCOD: int (FK)
EXPCOD: int (FK)
ALUCOD: int (FK)
ADMCOD: int (FK)

Figura 3.20 Modelo de la Base de Datos


Fuente: Propia

67
3.7. |IMPLEMENTACIÓN:
3.7.1. MIGRACIÓN DEL MODELO DE LA BASE DE DATOS EN
DBDESIGNER A MYSQL:
A. PROCESO DE EXPORTACION DEL DBDESIGNER:
1. Damos click en el menu File->Export->SQL créate
Scrit

Figura 3.21 Selección de la opción de exportación en el menú


Fuente: Propia

2. En la ventana que aparece seleccionamos las


siguientes opciones:
 All Tables.
 Define Primary Keys.
 Create Indices.
 Output Table Options.
 Output Estándar Inserts.
y damos click en el botón Save Script to file.

68
Figura 3.22 Selección de las opciones para la exportación
Fuente: Propia

69
3. Seleccionamos la ubicación donde se guardara el
archivo bdsisdoc.sql, el cual contiene la consulta
para crear la base de datos, y damos click en el
botón Guardar.

Figura 3.23 Guardando el archivo con la consulta para la creación


Fuente: Propia

70
B. PROCESO DE IMPORTACIÓN AL MYSQL:

1. Desde el phpMyAdmin, creamos una Base de Datos


con el nombre “BDSISCOD” y presionamos Crear

Figura 3.24 Ventana phpMyAdmin de creación de Base de Datos


Fuente: Propia

71
2. Luego seleccionamos la opción Importar y luego
Examinar_, para abrir el archivo generado con la
exportación del DBDesigner.

Figura 3.25: Búsqueda del Archivo exportado en phpMyAdmin.


Fuente: Propia

72
3. Después presionamos el botón Continuar.

Figura 3.26: Ventana phpMyAdmin con el archivo encontrado.


Fuente: Propia

73
4. Listo, ya contamos con nuestra Base datos en mysql,
y listo para interactuar con PHP.

Figura 3.27 Ventana phpMyAdmin con mensaje de ejecución con éxito.


Fuente: Propia

74
Figura 3.28: Ventana MyAdmin con la Base de Datos ya importado.
Fuente: Propia

75
3.7.2. CODIGO DE CONEXIÓN A LA BASE DE DATOS CON PHP:

Figura 3.39 Código de la clase para la conexión con la base de datos


Fuente: Propia

76
CAPÍTULO IV

4 RESULTADOS DE LA PRÁCTICA REALIZADA:

En este capítulo se realizará la descripción del Sistema de Administración de


los expedientes de la UJCM SIARCH (Sistema de Administración de
Archivo).
El sistema se subdivide de dos módulos básicos para el control y verificación
del sistema:

• Modulo de Administración.
• Modulo de Consulta.

Figura 4.1 Página Principal


Fuente: Propia

 El sistema de Control Expedientes cuenta con un menú, el cual se


encuentra en la parte superior y permanente un espacio donde se
hace la búsqueda de los expedientes mediante su código, apellidos
del alumno.

77
 Ya que el menú se modifica cuando se inicia sesión, apareciendo
más opciones de acuerdo a los permisos que tiene el empleado.

Figura 4.2 Menú del Sistema.


Fuente: Propia.

78
4.1. MODULO DE CONSULTA:

El administrador tiene todas las opciones del sistema. Para el acceso


al sistema de EXPEDIENTES, se tiene que ingresar el usuario y
Password, el cual es:

Usuario : SAMIR
Password : 54879314

Figura 4.3 Inicio del Sistema.


Fuente: Propia

79
Luego de iniciar sesión con la cuenta del ADMINISTRADOR, el
menú que aparece por defecto varía apareciendo más opciones
en la barra de menú, la misma que se puede observar a
continuación.

Figura 4.4 Menú del Administrador.


Fuente: Propia.

80
4.1.1. Datos: Resultados de búsqueda, se muestran datos
básicos del alumno además de 4 pestañas que muestran
más datos sobre su expediente.

Permite el mantenimiento y búsqueda de los documentos


emitidos.
Para registrar los documentos emitidos es necesario llenar
obligatoriamente los campos del formulario que tienen
asterisco.

Figura 4.5 Datos Básicos del expediente


Fuente: Propia

 Datos: Muestra datos básicos del alumno.


 Documentos: Muestra los documentos que tiene el alumno en su
expediente.
 Documentos: Muestra donde está ubicado el expediente.

81
Figura 4.6 Documentos que contiene el expediente
Fuente: Propia

4.1.2. MODULO DE ADMINISTRACION:

Para entrar al sistema primero tiene que teclear el usuario y


Password para tener acceso en este caso para ingresar al
sistema tendrá que escribir:
Usuario: admin
Password: admin

82
Figura 4.10 Control de acceso.
Fuente: Propia

Para poder acceder a este módulo deberá escribir esta dirección:


http://localhost/siarch/admin/index.php
La dirección del sistema web es variable depende de la
configuración del servidor, ya sea a nivel local o a través de internet.
Panel de Administración:
Desde aquí se administra todo el sistema, como se muestra en la
imagen:

83
Figura 4.11 Panel de Administración
Fuente: Propia

 Sede.
 Oficina.
 Tipo de Documento.
 Modo de Documento.
 Buscar Alumno.
 Ingresar Alumno.

4.1.3. CENTROS EDUCATIVOS:

En esta pestaña nosotros podremos registrar los centros educativos


donde el alumno estudio ya sea colegio, instituto, universidad.

84
Figura 4.12 Ingreso de centros educativos.
Fuente: Propia

4.1.4. ASOCIACIONES:

Permite personalizar y listar las Asociaciones de la UJCM

Figura 4.13 Registrar nueva Asociación.


Fuente: Propia

85
4.1.5. SEDES:

Permite personalizar y listar las Sedes de la UJCM

Figura 4.14 Registrar nueva Sede.


Fuente: Propia

4.1.6. Pantallas de Opciones del menú buscar alumno.

86
Figura 4.15 Detalles de Búsqueda de Alumno.
Fuente: Propia

Ingresar Alumno. Mediante es modulo ingresaremos los alumnos al


sistema de archivo en el cual especificaremos nombres, apellidos,
carrera, facultad, además de los documentos que contiene sus
expediente y el lugar de ubicación en donde será colocado el
expediente para una búsqueda más rápida mediante el sistema.

87
Figura 4.16 Detalles de ingreso de expediente de alumnos
Fuente: Propia

Esta es una parte muy importante del sistema dado a que es aquí
donde inicia todo el ingreso de datos al sistema para brindar
información para realizar los trámites correspondientes.
• Para iniciar ubicamos el icono de ingreso de alumnos situado en la
página principal del módulo de administración.
• Al acceder a este vínculo nos mostrara campos básicos del
alumno que se muestran en la siguiente imagen.
• La pestaña Expediente. Hace referencia a la ubicación del
expediente en la oficina de archivo.
• Después de completar los datos básicos continuamos con la
siguiente pestaña, que se refiere a los documentos que contiene
cada expediente.

88
• Una vez completado todos estos datos, guardamos y tenemos
todos los datos ingresados al sistema.

Figura 4.17 Detalle de ingreso de expediente de alumno.


Fuente: Propia

89
CAPÍTULO V

5 CONCLUSIONES Y SUGERENCIAS:

5.1. CONCLUSIONES:

Objetivo general

 Se logró desarrollar el sistema informático obteniendo resultados


positivos, en la Oficina de Servicios Académicos., con lo cual se
cumple con el objetivo general, puesto que el sistema informático
de gestión de expedientes desarrollado ha contribuido de manera
eficiente en minimizar el tiempo en la búsqueda, ubicación y la
actualización de documentos.

Objetivos Específicos

 Se analizó los procesos de administración de archivos y se


desprende que muchos de ellos son factibles de informatización.
No solo en lo que respecta a control de documentos, sino
también, dentro de las diversas funciones que se realizan dentro
de la Oficina de Servicios Académicos.

 Se logró diseñar el sistema informático usando la metodología


OOHDM, por ser esta metodología una de las más usadas y de
gran popularidad dentro del grupo de Metodologías Estructuradas.

90
 Se logró desarrollar e implementar el sistema Informático para
administrar los expedientes de la Universidad José Carlos
Mariátegui con el lenguaje de Programación php que permite
diseñar sistemas dinámicos.

5.2. RECOMENDACIONES:

 Evaluar constantemente el sistema para detectar las nuevas


necesidades y/o requerimientos que se presenten para
posteriormente actualizar el sistema.

 Utilizando técnicas para análisis se lograra obtener una adecuada


imagen de los procesos que se realiza en la oficina para así tener
un mejor entendimiento de lo que se quiere lograr en el sistema.

 Se recomienda la utilización de la metodología OOHDM, ya que


es un método para desarrollar aplicaciones web.

 El lenguaje que se recomienda utilizar para desarrollar un sistema


web es el lenguaje de programación PHP, el mismo que sirve para
manejar base de datos, y también para controlar la información
que llega desde el usuario.

91
CAPÍTULO VI

6 BIBLIOGRAFIA:

 LIBROS IMPRESOS:

 Vázquez Mollo Virginia, Molina Cáceres Juan José, Ríos López


Cecilia (2004), Metodología de Objetos UML y RUP, I Edición,
Universidad José Carlos Mariátegui, 507 páginas, Perú, Pág. 3 al 45,
50 al 85.

 Burch Jhon G. - Grudnitski,Gary (2007) “Diseño de Sistemas de


Información”, Wesley Iberoamericana, S.A. Quinta Edición. cita Pág.
23, U.S.A.

 Roger S. Presuman (2007), Ingeniería de Software un enfoque, 5ª


Edición, Colombia, Pág. 20, 50,75.

 Roger Pressman. Ingeniería de Software un enfoque práctico. Quinta


Edición. McGRAW-HILL. 2002. pp. 25, 166, 132, 324-325, 524-526,
499.

 Sergio Matsukawa Maeda (2004), Análisis y Diseño Orientados a


Objetos con UML y Rational Rose, 1ra Edición: Diciembre 2004,
Empresa Editora Macro E.I.R.L., Perú, Pág. 20 al 80.

 Xavier Ferré Grau - María Isabel Sánchez, (2007), Desarrollo


Orientado a Objetos con UML, II Edición, S. Editorial, Pág. 5 al 25.

92
 LIBROS DIGITALES:

 GÓMEZ A. (2004), “Metodología de Desarrollo lo de Aplicaciones


Web”, Disponible en: agomez@micorp.com.ve, [descargado].

 Autor: Xavier Ferré Grau - María Isabel Sánchez Segura (2004),


Lenguaje Unificado de Modelado, España, disponible en:
http://www.clikear.com/manuales/uml, [web en línea].

 Curso Visual de Computación, Alberto Martínez De Arredondo (2000).


Lexus Editores S.A.

 Lars Torben (2004), “Manual de PHP 4”, Disponible en:


http://www.php.net/docs.php, [descargado].

 DIRECCIONES ELECTRÓNICAS:

 WIKIPEDIA (2007), “PHPMYADMIN”, Disponible en:


http://es.wikipedia.org/wiki/phpmyadmin, [web en línea].

 TUTORIAL DE PHP, Autor: Javier García Castellano, Disponible en:


http://flanagan.ugr.es/php/index2.htm, [web en línea].

 WIKIPEDIA (2007), “APACHE”, Disponible en:


http://es.wikipedia.org/wiki/servidor_http_apache, [web en línea].

 DEFINICIÓN Y USO DE CLASES EN PHP, Disponible en:


http://www.webtaller.com/construccion/lenguajes/php/lecciones/de
finicion-uso-clases-php.php, [web en línea].

 MODELO OOHDM, Disponible en:


http://www.hipertexto.info/documentos/oohdm.htm, [web en línea].

93
 METODOLOGÍAS WEB OOHDM, Disponible en:
http://es.scribd.com/doc/55661469/OOHDM, [web en línea].

 INGENIERÍA DE SOFTWARE UML, Disponible en:


http://www.monografias.com/trabajos5/insof/insof.shtml, [web en
línea].
 WIKIPEDIA PHP, Disponible en: http://es.wikipedia.org/wiki/PHP, [web
en línea].

94
CAPÍTULO VII

7 ANEXOS:

7.1. CÓDIGO FUENTE:

 PÁGINA DE INICIO:

 Index.php

<?php
session_start();
if ($_SESSION['autenticado']=='SI')
{
$nombres=$_SESSION['usuario'];
$cargo=$_SESSION['cargo'];
// $idAdministrador=$_SESSION['idAdministrado'];
$BV="<span>".strtoupper("$nombres")." ($cargo)"." <a
target='gutierrez' href='public/w.php' class='leo' >Cerrar Sesion
</a></span>";

}
?>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>

<title>Sistema de Control Documentario- SISCOD</title>


<meta name="Universidad Jose Carlos Mariategui"
content="sisdoc,contactenos">
<meta name="keywords" content="UJCM, Universidad,
Mariategui, sisdoc">
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
<link rel="stylesheet" type="text/css"
href="public/css/estilos.css">
<script type="text/javascript"
src="public/js/codigo.js"></script>
<script
type="text/javascript"src="public/js/jquery.js"></script><meta http-
equiv="content-type" content="application/xhtml+xml;
charset=UTF-8">

95
<link rel="stylesheet" type="text/css" media="screen"
href="public/css/layout1.css">
<link rel="stylesheet" type="text/css" media="screen"
href="public/css/stack-example3.css">
<link href="public/css/dropdown/dropdown.css" media="all"
rel="stylesheet" type="text/css" />

<link
href="public/css/dropdown/themes/nvidia.com/default.advanced.cs
s" media="all" rel="stylesheet" type="text/css" />
<script type="text/javascript"
src="public/js/swfobject.js"></script>
<noscript>
<style type="text/css">
#dock { top: -32px; }
a.dock-item { position: relative; float: left;
margin-right: 10px; }
.dock-item span { display: block; }
.stack { top: 0; }
.stack ul li { position: relative; }
</style>
</noscript>
<script type="text/javascript"
src="public/js/jquery.min.js"></script>
<script type="text/javascript" src="public/js/fisheyeiutil.
min.js"></script>
<script type="text/javascript" src="public/js/dock
example1.js"></script>
<script type="text/javascript" src="public/js/stack-
1.js"></script>
<script>
function ajustar(){
var altura =
window.frames['gutierrez'].document.body.scrollHeight;// Obtengo
altura del documento
document.getElementById('gutierrez').height =
altura+400;// Cambio altura de iframe
}
</script>
</head>
<body
onload="menuSlider.init('menucabecera','menucabeceraslide')"
bgcolor="#ffffff" onresize="ajustar()">
<table border='0' id="ujcmhead" align="center" cellpadding="0"
cellspacing="0" width="860">
<tbody>
<tr>
<td width="95" bgcolor="#DEE7F7">

96
</td>
<td height="31" bgcolor="#DEE7F7"></td>
<td align="right" bgcolor="#DEE7F7"><script
type="text/javascript">fecha();</script><span
id="fecha"></span></td>
</tr>
<tr>
<td colspan='3'>
<div id="header">
<div style="color:blue; font: 20px Broadway BT;">
<CENTER>
<P style="color:red; font: 35px Broadway
BT;">SISTEMA DE CONTROL DOCUMENTARIO</P>
<P style="color:blue; font: 20px Britannic
Bold;">"UNIVERSIDAD JOSÉ CARLOS MARIÁTEGUI"</P>
<H1></H1>
</CENTER>
</div>
<h1>
<table width="860">
<tr><td width="180">
<img src="public/img/logo.png" alt="SISCOD" width="70" />
SISCOD
</td><td align="CENTER" style="color:#81BE18; font: 20px Comic
Sans MS;">OSAERC</BR> PRE-GRADO
</td><td width="180" align="right">
<img src="public/img/ujcm.gif" width="70"/>
</td></tr>
</h1>

<table width="860">
<tr><td>
<ul class="dropdown dropdown-horizontal">
<li>
<a href="./" class="dir">Inicio</a>
</li>

<?php
if ($_SESSION['autenticado']=='SI')
{
switch($_SESSION['cargo']){
case 'USUARIO':
require_once
('public/menu/menuUser.php');
break;
case 'ADMINISTRADOR':
require_once
('public/menu/menuAdmin.php');

97
break;
}
}else{
?>
<li>
<a href="presentacion/FrmLogin.php" target='gutierrez'
class="dir">Ingresar</a>
</li>
<li><a href="./" class="dir">Consulta</a>
<ul>
<li><a
href="presentacion/FrmConsultaEmitido.php"
target='gutierrez'>Documento Emitido</a></li>
<li><a
href="presentacion/FrmConsultaRecibido.php"
target='gutierrez'>Documento Recibido</a></li>
</ul>
</li>
<?php
}
?>
<li>
<a href="public/manual.pdf" target='gutierrez'
class="dir">Manual</a>
</li>
<li>
<a href="public/acerca.php" target='gutierrez'
class="dir">Acerca de..</a>
</li>
</ul>
</td>
<td><div style="font-size: 9;">
Programaddr: Bach. Beyker Albert Gutierrez
Quispe.</br>E-mail: beyker_gutierre@hdtmail.cdm
</div>
</td>
</tr>

<tr><td colspan='2' bgcolor="#E7EBF7"><div id="session">


<?php echo "</br>"; ?>
</div></td>
</tr>
</table>
</div><?php echo $BV."</br>"; ?>
</td>
</tr>
<tr>
<td colspan="3">

98
<div id="ini">
<?php include
"presentacion/FrmLogin.php"; ?>
</div>
<iframe src="" frameborder="0"
marginheight="0" marginwidth="0" scrolling="no"
width="100%" id="gutierrez"
name="gutierrez"
onload="ajustar();">
</iframe>
</td>
</tr>
</tbody>
</table>
<div id="contenidos">
<table border="0" cellpadding="0" cellspacing="0">
<tbody>
<tr>
<td><img src="public/img/spacer.gif" alt=""
border="0" height="1" width="12"></td>
</tr>
<tr>
<td rowspan="7" colspan="4">
<td><img src="public/img/spacer.gif" alt=""
border="0" height="77" width="1"></td>
</tr>
</tbody>
</table>

</div>
<?php
if ($_SESSION['autenticado']=='SI')
{
switch($_SESSION['cargo']){
case 'USUARIO':
require_once
('public/menu/menuUser.php');
break;
case 'ADMINISTRADOR':
require_once
('public/menu/menuAdmin.php');
break;
}
?>
<?php
}
?>

99
<center>
<table border='0' cellpadding="0" cellspacing="0" width="860">
<tr>
<td bgcolor="#DEE7F7" width='100%'
height='10'></td>
</tr>
<tr>
<td colspan="3" background="public/partes_r25_c4.jpg">
<strong>SISCOD © 2011</strong><br>
Prdgramaddr: Bach. Beyker Albert Gutierrez Quispe.</br>
E-mail: beyker_gutierre@hdtmail.cdm
<br><br>
</td>
<tr>
</table>
</center>
<script src="index.js" type="text/javascript"></script>
</body></html>

 Index.js:
$('.leo').click(function(){
$.ajax({
type: "POST",
url: "presentacion/CSession.php",
data: "boton=cerrar",
success: function(html)
{
$('#session').html(html);
}
})
});

 CLASE CONEXIÓN:
 Conexión.php:
<?php
class conexion
{
var $server="localhost";
var $user="root";
var $pass="";
var $bd="BDSISCOD";
public $conn;
function conectar()
{
$this->conn=new mysqli($this->server,$this-
>user,$this->pass,$this->bd);
}
function cerrar()

100
{
$this->conn->close();
}
}
?>

 FORMULARIO DOCUMENTO RECIBIDO:


 FrmDocumentoRecibido.php:
<?php
session_start();
if ($_SESSION['autenticado']=='SI')
{
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0
Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-
transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
<title>DocumentoRecibido</title>
<script src="../public/js/jquery.js"
type="text/javascript"></script>
<script src="../public/js/jquery.validate.js"
type="text/javascript"></script>
<script src="../public/js/tab.js" type="text/javascript"
></script>
<link href="../public/css/insidestyle.css" rel="stylesheet"
type="text/css"/>
<style>
.dropdownEffect
{
width: 170px;
}
table.tmin th {

101
GLOSARIO

1. Freeware:

Freeware Software de distribución gratuita. Programas que se distribuyen


a través de Internet de forma gratuita.

2. LSAPILSAPI (Licensing Service API):

Interfaz de programación de Microsoft que permite a un servidor con


licencia rastrear aplicaciones en uso para administrar licencias de
software multiusuario.

3. DualDual:

La palabra Dual hace referencia a una dúplica o espejo de algo que se


está haciendo, por ejemplo la dual de una tabla en Oracle.

4. Dual ChannelDual Channel:

Doble canal de datos. Es una característica que nos indica que el


procesador puede acceder a su memoria por dos caminos distintos y los
puede usar de forma.

5. Apache:

Servidor web de código abierto. Su desarrollo comenzó en febrero de


1995, por Rob McCool.

6. Aplicación:

Cualquier programa que corra en un sistema operativo y que haga una


función específica para un usuario.

102
7. FTP:

File Transfer Protocol. Protocolo de transferencia de archivos. Por medio


de programas que usan este protocolo, se permite la conexión entre dos
computadoras y se pueden cargar y descargar archivos entre el cliente y
el host (servidor).

8. Hosting:

El servicio de Web Hosting consiste en el almacenamiento de datos,


aplicaciones o información dentro de servidores diseñados para llevar a
cabo esta tarea.

9. JSP:

Siglas de Java Server Pages o Páginas de servidor de Java, es la


tecnología para generar páginas web de forma dinámica en el servidor,
desarrollado por Sun Microsystems, basado en scripts que utilizan una
variante del lenguaje java para construir páginas HTML en servidores.

10. MySQL:

My SQL es uno de los Sistemas Gestores de Bases de Datos más


populares. Su ingeniosa arquitectura lo hace extremadamente rápido y
fácil de personalizar.

11. NCSA:

Centro Nacional de Aplicaciones de Supercómputo (National Center for


Supercomputing Applications). Desarrolladores del visualizador Mosaic
para el World Wide Web. Localizado en. http://www.ncsa.uiuc.edu/

12. ODBC:

Open Database Connectivity. Estándar de acceso a Bases de Datos


desarrollado por Microsoft cuyo objetivo es hacer posible el acceder a

103
cualquier dato de cualquier aplicación, sin importar qué Sistema Gestor
de Bases de Datos (DBMS por sus siglas en inglés) almacene los datos.

13. Open source:

Código fuente abierto software libre, se refiere a un programa cuyo


código fuente está disponible al público general, gratis, para usar y
modificar.

14. Paquete:

Un paquete es un pedazo de información enviada a través de la red. La


unidad de datos que se envía a través de una red la cual se compone de
un conjunto de bits que viajan juntos.

15. PHP:

Hypertext Preprocessor. Lenguaje de script diseñado para la creación de


páginas web activas (similares a ".asp" de Microsoft), multiplataforma
(puede correr en Windows, Mac, Linux). Usualmente se usa en conjunto
con la base de datos MySQL, pero puede usar cualquier otro tipo de base
de datos como por ejemplo Oracle, SQL o Postgres.

16. Protocolo:

Descripción formal de formatos de mensaje y de reglas que dos


computadoras deben seguir para intercambiar dichos mensajes. Un
protocolo puede describir detalles de bajo nivel de las interfaces máquina
a máquina o intercambios de alto nivel entre programas de asignación de
recursos.

17. Proxy:

Servidor especial encargado, entre otras cosas, de centralizar el tráfico


entre Internet y una red privada, de forma que evita que cada una de las

104
máquinas de la red interior tenga que disponer necesariamente de una
conexión directa a la red.
18. Servidor:

Un servidor es una computadora que maneja peticiones de data, email,


servicios de redes y transferencia de archivos de otras computadoras
(clientes).

19. Servidor Web:

Un servidor web es el programa, y la computadora que lo corre, que


maneja los dominios y páginas web, interpretando lenguajes como html y
php, entre otros. Ejemplos: Apache y Microsoft IIS.

20. Servlet:

Pequeña aplicación Java (applet) la cual se ejecuta en un servidor web y


se envía al usuario junto a una página web con objeto de realizar
determinadas funciones.

21. Sesión Remota:

Uso de los recursos de una computadora desde una terminal la cual no


se encuentra cercana a dicha computadora.

105

Vous aimerez peut-être aussi