Trabajo de Metodologia RUP

UNIVERSIDAD NACIONAL DE UCAYALI
Facultad de Ingeniería de Sistemas y de Ingeniería Civil
Escuela Profesional de Ingeniería
de Sistemas
Informe de Práctica Pre Profesional I
DESARROLLO DEL ANÁLISIS Y DISEÑO DE UN SISTEMA WEB

CON TECNOLOGÍA J2EE PARA LOS PROCESOS
ADMINISTRATIVOS DE TRÁMITE DOCUMENTARIO EN LA
UNIVERSIDAD NACIONAL INTERCULTURAL DE LA AMAZONIA
ALUMNO : REÁTEGUI MACEDO, Ruddy Enzo
ASESOR : Ing.Mg. Jorge Luis Hilario Riva
PUCALLPA – PERU
2012
I
Aprobación y firma del Asesor:
______________________________
Ing. Mgs. Jorge Luis Hilario Rivas
Asesor
II
DEDICATORIA
Dedico este trabajo a mi familia que de
una manera u otra contribuyen en el
proceso de mi formación profesional,
gracias a su apoyo incondicional es
posible llevar acabo este proyecto.
III
AGRADECIMIENTOS
En primera instancia agradecer a Dios por la vida y las oportunidades que nos
brinda, para lograr así la ejecución de este proyecto; en segunda al Jefe de la
Oficina de Informática dela Universidad Nacional Intercultural de la Amazonía
“UNIA”por abrirlas puertas de esta reconocida universidad y brindar noción de
los procesos que se realizan en la misma; de igual forma mis agradecimientos al
asesor de practica por brindarme las pautas adecuadas para llevar acabo este
estudio y mantenerse al tanto en el avance del mismo;por ultimo agradecer a
mis padres que dí a adía me brindan el apoyo en mi proceso de formación
profesional.
IV
INTRODUCCIÓN
La información es un activo estratégico, que aporta conocimiento y valor añadido
a las organizaciones actuales ante la sociedad de la información y en la llamada
nueva economía. Las nuevas tecnologías de la información y comunicaciones
(TIC’S) están haciendo aparecer nuevas aplicaciones, nuevas necesidades,
nuevas maneras de entender y gestionar nuestro entorno. Y en este contexto, el
tratamiento y las aplicaciones de trámite documentarioadquieren una importancia
relevante.
La Universidad Nacional Intercultural de la Amazonia, siendo una casa de
superior de estudio que forma profesionales con ética, conocimiento y valores
para servir dentro o fuera de la región, está obligada al uso de la data en
registros, recepción y despacho de documentos, y consultas de trámite. Para ello
el control de documentos y por ende los trámites deben estar administrados de
manera eficaz y parcial; para crear confianza en la región y el país.
Esto nos lleva a pensar que la implementación de un sistema Web con tecnología
J2EE, puede ser la base para mejorar el control de trámite documentario y no
permitir las alteraciones o el uso indebido de la misma. Actualmente no se cuenta
con un sistema de éstas características dentro de la Universidad.
La investigación viene estructurada de la siguiente manera:
En el Capítulo I: Datos generales de la práctica; en esta parte se describe
los datos generales de la práctica pre profesional.
En el Capítulo II: Aspectos Generales de la empresa; en esta parte de detalla
datos de la empresa en la que se desarrolló la práctica.
En el Capítulo III: Objetivos y Justificación; En esta parte se definen los
objetivos generales y específicos, justificación teórica, practica y metodológica.
V
En el Capítulo IV: Marco teórico; En esta parte se describe el fundamento
teórico, donde se hace hincapié en exponer el conocimiento teórico sobre RUP,
UML; además definir los conceptos de Sistemas Web, tecnología J2EE, también
mostrar la arquitectura de implementación es Cliente/Servidor en sus diferentes
modelos, finalmente nos referimos a los Administración de Procesos.
En el Capítulo V: Proceso de desarrollo de software; Sedescribe el
desarrollo de la documentación del análisis y diseño del sistema planteado.
En el Capítulo VI: Fase de elaboración; Sedescribe a detalle la fase de
elaboración del RUP.
En el Capítulo VII: Conclusiones y Recomendaciones; obtenidas en el
desarrollo de la práctica.
Finalmente se presenta; las referencias Bibliográficas, y los Anexos necesarios
del Plan de desarrollo de software.
VI
Índice de Contenido
DEDICATORIA .......................................................................................................................... III

AGRADECIMIENTOS ............................................................................................................... IV
INTRODUCCIÓN ........................................................................................................................ V
CAPÍTULO I................................................................................................................................. 1
DATOS GENERALES DE LA PRÁCTICA.............................................................................. 1
1.1. TIPO DE PRÁCTICA PRE PROFESIONAL .......................................................... 1
1.2. TÍTULO DE LA PRÁCTICA PRE PROFESIONAL .............................................. 1
1.3. AUTOR DE LA PRÁCTICA PRE PROFESIONAL ............................................... 1
1.4. ASESOR ...................................................................................................................... 1
1.5. COLABORADORES.................................................................................................. 1
1.6. PERIODO DE LA PRÁCTICA.................................................................................. 1
1.7. INSTITUCIÓN Y ÁREA DONDE SE DESARROLLÓ LA PRÁCTICA .............. 1
CAPÍTULO II ............................................................................................................................... 2
ASPECTOS GENERALES DE LA EMPRESA ...................................................................... 2
2.1. RAZÓN SOCIAL ........................................................................................................ 2
2.2. ACTIVIDADES ............................................................................................................ 2
2.3. ASPECTOS TÉCNICOS ........................................................................................... 2
2.3.1. UBICACIÓN GEOGRÁFICA .................................................................................. 3
2.3.2. ORGANIZACIÓN INSTITUCIONAL ..................................................................... 4
CAPÍTULO III .............................................................................................................................. 5
OBJETIVOS Y JUSTIFICACIÓN ............................................................................................. 5
3.1. PLANTEAMIENTO DEL PROBLEMA ................................................................... 5
3.1.1. FORMULACIÓN DEL PROBLEMA ...................................................................... 5
3.1.2. JUSTIFICACIÓN...................................................................................................... 6
3.1.3. OBJETIVOS ............................................................................................................. 7
CAPÍTULO IV .............................................................................................................................. 9
MARCO TEÓRICO..................................................................................................................... 9
4.1. ANTECEDENTES DEL ESTUDIO .......................................................................... 9
4.2. PLANTEAMIENTO TEÓRICO DEL PROBLEMA .............................................. 10
4.2.1. SISTEMA WEB ................................................................................................. 10
4.2.1.1. SISTEMA ................................................................................................... 20
4.2.1.2. WEB............................................................................................................ 22
4.2.1.3. SISTEMA INFORMÁTICO ...................................................................... 22
VII
4.2.1.4. INGENIERÍA DE SOFTWARE ............................................................... 23
4.2.1.5. SISTEMA GESTOR DE BASE DE DATOS ......................................... 32
4.2.1.6. PROCESO UNIFICADO DE RATIONAL ............................................. 35
4.2.1.7. LENGUAJE DE MODELO UNIFICADO ............................................... 41
4.2.2. TECNOLOGÍA J2EE ........................................................................................ 46
4.3. DEFINICIÓN DE TÉRMINOS BÁSICOS .............................................................. 52
CAPÍTULO IV ............................................................................................................................ 55
PROCESO DE DESARROLLO DE SOFTWARE ............................................................... 55
4.1. FASE INICIAL ........................................................................................................... 55
A. DOCUMENTO DE VISIÓN DEL NEGOCIO .................................................... 55
A.1. INTRODUCCIÓN .............................................................................................. 55
A.1.1. PROPÓSITO ............................................................................................. 55
A.1.2. ALCANCE ................................................................................................. 55
A.2. POSICIONAMIENTO ....................................................................................... 56
A.2.1. OPORTUNIDADES DEL NEGOCIO ..................................................... 56
A.2.2. EXPOSICIÓN DEL PROBLEMA ........................................................... 57
A.2.3. EXPOSICIÓN DEL PRODUCTO ........................................................... 57
A.3. DESCRIPCIÓN DE STAKEHOLDER Y USUARIOS ................................. 58
A.3.1. MERCADO DEMOGRÁFICO ................................................................. 58
A.3.2. SUMARIO DE STAKEHOLDER ............................................................ 59
A.3.3. SUMARIO DE USUARIOS ..................................................................... 59
A.3.4. AMBIENTE DE USUARIOS ................................................................... 60
A.3.5. NECESIDADES PRINCIPALES DE USUARIOS ............................... 61
A.3.6. ALTERNATIVAS ...................................................................................... 61
A.4. OBJETIVOS DE MODELAMIENTO DEL NEGOCIO ................................ 62
A.5. RANGOS DE CALIDAD .................................................................................. 63
A.6. PANORAMA DEL PRODUCTO .................................................................... 63
A.7. REQUERIMIENTOS ........................................................................................ 63
A.7.1. FUNCIONALES. ....................................................................................... 63
A.7.2. NO FUNCIONALES. ................................................................................ 63
B. PLAN DE DESARROLLO DEL SOFTWARE ................................................. 65
B.1. INTRODUCCIÓN .............................................................................................. 65
B.1.1. PROPÓSITO ............................................................................................. 65
B.1.2. ALCANCE ................................................................................................. 65
B.1.3. REFERENCIAS ........................................................................................ 65
VIII
B.1.4. APRECIACIÓN GLOBAL .......................................................................... 66
B.2. LA APRECIACIÓN GLOBAL DEL PROYECTO ........................................ 66
B.2.1 PROPÓSITO DEL PROYECTO, ALCANCE Y OBJETIVOS ............... 66
B.2.2. ENTREGABLES DEL PROYECTO ......................................................... 66
B.2.3. EVOLUCIÓN DEL PLAN DE DESARROLLO DE SOFTWARE ......... 67
B.3. LA ORGANIZACIÓN DEL PROYECTO....................................................... 67
B.3.1. ESTRUCTURA ORGÁNICA...................................................................... 67
B.3.2. INTERFACES EXTERNAS ........................................................................ 68
B.3.3. PAPELES Y RESPONSABILIDADES ..................................................... 68
B.4. PROCESO DE DIRECCIÓN ........................................................................... 69
B.4.1. ESTIMACIÓN DEL PROYECTO .............................................................. 69
B.4.2. PLAN DE PROYECTO ............................................................................... 69
B.5. RECURSOS PARA EL PROYECTO ............................................................ 72
B.5.1. PLAN DE ADQUISICIÓN DE RECURSOS ECONÓMICOS............. 72
B5.2. ENTRENAMIENTO QUE SE PLANEAN.............................................. 72
B.6. PRESUPUESTO ............................................................................................... 73
B.7. ENTORNO DE TRABAJO .............................................................................. 74
B. 7.1. ELECCIÓN DE EQUIPOS Y ACCESORIOS DE LA RED LAN ......... 74
B.7.1.1. ELECCIÓN DEL SERVIDOR ............................................................. 74
B.7.1.2. IMPRESORA ........................................................................................ 74
B.7.1.3. SWITH .................................................................................................... 74
B.7.1.4. ACCESORIOS DE RED ...................................................................... 74
B.7.1.5. ELECCIÓN DEL PC ADMINISTRADOR ......................................... 75
B.7.1.6. ELECCIÓN DE LAS PC CLIENTE .................................................. 76
B.8. VISTAS CASOS DE USO ............................................................................... 76
B.8.1. MODELO DE CASOS DE USO DEL NEGOCIO ................................ 76
B.8.2. MODELO DE OBJETO DE NEGOCIO................................................. 77
B.8.3. MODELO DE DOMINIO .......................................................................... 79
B.9. DESCRIPCIÓN DEL PROCESO DEL NEGOCIO ...................................... 80
CAPÍTULO V ............................................................................................................................. 81
FASE DE ELABORACIÓN ...................................................................................................... 81
5.1. REQUERIMIENTOS ................................................................................................ 81
A) MODELO USE CASE .......................................................................................... 81
B) ESPECIFICACIONES DE LOS USE CASE .................................................... 84
5.2. ANÁLISIS Y DISEÑO .............................................................................................. 86
IX
A) DIAGRAMAS DE COLABORACIÓN ............................................................... 86
B) DIAGRAMA DE CLASES ................................................................................... 94
C) INTERFAZ Y SECUENCIA ................................................................................. 95
D) DIAGRAMA DE COMPONENTES .................................................................. 121
E) DISEÑO DE LA BASE DE DATOS................................................................. 121
E.1) DICCIONARIO DE DATOS DE TABLAS PRINCIPALES ........................ 121
E.2) DIAGRAMA DE BASE DE DATOS .............................................................. 125
F) SENTENCIAS LÓGICAS PRINCIPALES .......................................................... 126
CLASE cTrámite: .......................................................................................................... 126
CLASE cDeTramite ...................................................................................................... 136
CLASE cDocumento .................................................................................................... 148
CLASE cpersona .......................................................................................................... 153
CAPÍTULO VII ......................................................................................................................... 160
CONCLUSIONES Y RECOMENDACIONES ..................................................................... 160
7.1. CONCLUSIONES ................................................................................................... 160
7.2. RECOMENDACIONES.......................................................................................... 161
BIBLIOGRAFÍA ....................................................................................................................... 162
ANEXOS .................................................................................................................................. 164
X
Índice de Cuadros
TABLA 1: Exposición del problema------------------------------------------------------------------------ 57

TABLA 2: Exposición del producto------------------------------------------------------------------------- 57
TABLA 3: Sumario de Stakeholders----------------------------------------------------------------------- 59
TABLA 4: Sumario de Usuarios. ---------------------------------------------------------------------------- 59
TABLA 5: Necesidades de los usuarios.----------------------------------------------------------------- 61
TABLA 6: Entregables del proyecto. ---------------------------------------------------------------------- 67
TABLA 7: Papeles y Responsabilidades. --------------------------------------------------------------- 68
TABLA 8: Plan de proceso de desarrollo de acuerdo a fases. ---------------------------------- 69
TABLA 9: Fases del proyecto e hitos principales ---------------------------------------------------- 69
TABLA 10: Horario del proyecto ---------------------------------------------------------------------------- 72
TABLA 11: Presupuesto del proyecto -------------------------------------------------------------------- 73
TABLA 12: Características físicas del servidor -------------------------------------------------------- 74
TABLA 13: Características logicas del servidor ------------------------------------------------------- 74
TABLA 14: Características concentradoras ------------------------------------------------------------ 74
TABLA 15: Características del pc Administrador. ---------------------------------------------------- 75
TABLA 16: Características de las estaciones cliente ----------------------------------------------- 76
TABLA 17: Descripción del proceso del negocio. ---------------------------------------------------- 80
TABLA 18: MCU: ADMINISTRACIÓN GENERAL --------------------------------------------------- 84
TABLA 19: MCU: PROCESO DE GESTIÓN DE TRÁMITE DOCUMENTARIO ---------- 84
TABLA 20: TIPODOCUMENTO -------------------------------------------------------------------------- 121
TABLA 21: Tabla Accion------------------------------------------------------------------------------------- 122
TABLA 22: Tabla DETALLETRAMITE ----------------------------------------------------------------- 122
TABLA 23: Tabla AREA ------------------------------------------------------------------------------------- 123
TABLA 24: Tabla OFICINA --------------------------------------------------------------------------------- 123
TABLA 25: Tabla USUARIO ------------------------------------------------------------------------------- 123
TABLA 26: Tabla TRAMITE -------------------------------------------------------------------------------- 124
TABLA 27: MATERIAL PARA EL DESARROLLO DEL SISTEMA -------------------------- 165
TABLA 28: SERVICIOS-------------------------------------------------------------------------------------- 165
TABLA 29: PESOS DE ACTORES ---------------------------------------------------------------------- 166
TABLA 30: PESOS DE USE CASE --------------------------------------------------------------------- 167
TABLA 31: ASIGNACION DEPESOS DE USE CASE ------------------------------------------- 168
TABLA 32: FACTOR TECNICO DE COMPLEJIDAD --------------------------------------------- 169
TABLA 33: FACTOR ENVIROMENT ------------------------------------------------------------------- 171
TABLA 34: MENÚ DEL ADMINISTRADOR ---------------------------------------------------------- 174
TABLA 35: Menú del usuario------------------------------------------------------------------------------- 174
XI
Índice de Gráficos
GRÁFICO 1: CASOS DE USO DE SISTEMA DE TRÁMITE DOCUMENTARIO -------- 76

GRÁFICO 2: MON: Administración General. ---------------------------------------------------------- 77
GRÁFICO 3: MON: Proceso de Gestión de Trámite Documentario --------------------------- 78
GRÁFICO 4: Modelo de Dominio--------------------------------------------------------------------------- 79
GRÁFICO 5: MCU: Administración de Usuario. ------------------------------------------------------ 81
GRÁFICO 6: PROCESO DE GESTIÓN DE TRÁMITE DOCUMENTARIO. ---------------- 82
GRÁFICO 7: INTERFAZ DE MANTENIMIENTO DE ACCIÓN ---------------------------------- 95
GRÁFICO 8: INTERFAZ DE REGISTAR ACCIÓN -------------------------------------------------- 95
GRÁFICO 9: INTERFAZ DE MANTENIMIENTO DE TIPO DOCUMENTO ---------------- 99
GRÁFICO 10: INTERFAZ DE REGISTRAR TIPO DOCUMENTO----------------------------- 99
GRÁFICO 11: INTERFAZ DE MANTENIMIENTO DE USUARIO ---------------------------- 103
GRÁFICO 12: INTERFAZ DE REGISTRAR USUARIO ------------------------------------------ 103
GRÁFICO 13: INTERFAZ DE REGISTRAR TRÁMITE ------------------------------------------ 107
GRÁFICO 14: INTERFAZ DE HOJA DE TRÁMITE ----------------------------------------------- 107
GRÁFICO 15: INTERFAZ DE RECEPCIONAR DOCUMENTO SIN REGISTROS---- 109
GRÁFICO 16: INTERFAZ DE RECEPCIONAR DOCUMENTO RECEPCIONAR ----- 109
GRÁFICO 17: INTERFAZ DE DESPACHAR DOCUMENTO SIN REGISTROS ------- 111
GRÁFICO 18: INTERFAZ DE DESPACHAR DOCUMENTO 1. ------------------------------ 111
GRÁFICO 21: INTERFAZ DE ARCHIVAR DOCUMENTO. ------------------------------------ 114
GRÁFICO 22: INTERFAZ DE REPORTE DE DOCUMENTOS EMITIDOS. ------------- 116
GRÁFICO 23: INTERFAZ DE REPORTE DE DOCUMENTOS RECEPCIONADOS. 116
GRÁFICO 24: INTERFAZ DE REPORTE DE DOCUMENTOS DESPACHADOS. ---- 117
GRÁFICO 25: INTERFAZ DE CONSULTAR TRÁMITE. ---------------------------------------- 119
XII
Índice de Diagramas
DIAGRAMA 1: DC: MANTENIMIENTO DE USUARIOS. ------------------------------------------ 86

DIAGRAMA 2: DC: MANTENIMIENTO TIPO DOCUMENTO ----------------------------------- 87
DIAGRAMA 3: DC: MANTENIMIENTO DE ACCIÓN. ---------------------------------------------- 87
DIAGRAMA 4: DC: REGISTRAR TRAMITE INTERNO -------------------------------------------- 88
DIAGRAMA 5: DC: REGISTRAR TRAMITE EXTERNO------------------------------------------- 89
DIAGRAMA 6: DC: RECEPCIONAR DOCUMENTO ----------------------------------------------- 90
DIAGRAMA 7: DC: DESPACHAR DOCUMENTO --------------------------------------------------- 91
DIAGRAMA 8: DC: ARCHIVAR DOCUMENTO. ----------------------------------------------------- 92
DIAGRAMA 9: DC: REPORTE DE DOCUMENTOS SEGÚN ESTADO (EMITIDOS,
RECEPCIONADOS, DESPACHADOS, ARCHIVADOS). ----------------------------------------- 93
DIAGRAMA 10: DIAGRAMA DE CLASES -------------------------------------------------------------- 94
DIAGRAMA 11: MANTENIMIENTO DE ACCIÓN-REGISTRAR-------------------------------- 96
DIAGRAMA 12: MANTENIMIENTO DE ACCIÓN-MODIFICAR -------------------------------- 97
DIAGRAMA 13: MANTENIMIENTO DE ACCIÓN-ELIMINAR ----------------------------------- 98
DIAGRAMA 14: MANTENIMIENTO DE TIPO DOCUMENTO REGISTRAR------------- 100
DIAGRAMA 15: MANTENIMIENTO DE TIPO DOCUMENTO-MODIFICAR ------------ 101
DIAGRAMA 16: MANTENIMIENTO DE TIPO DOCUMENTO ELIMINAR ---------------- 102
DIAGRAMA 17: MANTENIMIENTO DE USUARIO-REGISTRAR --------------------------- 104
DIAGRAMA 18: MANTENIMIENTO DE USUARIO-MODIFICAR ---------------------------- 105
DIAGRAMA 19: MANTENIMIENTO DE USUARIO-ELIMINAR ------------------------------- 106
DIAGRAMA 20: REGISTRAR TRAMITE -------------------------------------------------------------- 108
DIAGRAMA 21: RECEPCIONAR DOCUMENTO -------------------------------------------------- 110
DIAGRAMA 22: RECEPCIONAR DOCUMENTO -------------------------------------------------- 113
DIAGRAMA 23: ARCHIVAR DOCUMENTO --------------------------------------------------------- 115
DIAGRAMA 24: REPORTE DE DOCUMENTOS EMITIDOS ---------------------------------- 118
DIAGRAMA 25: CONSULTAR TRAMITE ------------------------------------------------------------- 120
DIAGRAMA 26: DIAGRAMA DE COMPONENTES ----------------------------------------------- 121
DIAGRAMA 27: DIAGRAMA DE BASE DE DATOS ---------------------------------------------- 125
XIII
Índice de Ilustraciones
ILUSTRACIÓN 1: UBICACIÓN DE LA UNIA ------------------------------------------------------------3

ILUSTRACIÓN 2: ORGANIGRAMA -------------------------------------------------------------------------4
ILUSTRACIÓN 3: PROTOCOLO HTTP ----------------------------------------------------------------- 10
ILUSTRACIÓN 4: ARQUITECTURA DE UN SITIO WEB BÁSICA ---------------------------- 20
ILUSTRACIÓN 5: ARQUITECTURA DE UN SITIO WEB DINÁMICO------------------------ 20
ILUSTRACIÓN 6: FASES RUP ----------------------------------------------------------------------------- 39
ILUSTRACIÓN 7: ORIGEN UML --------------------------------------------------------------------------- 44
ILUSTRACIÓN 8: COMPILACIÓN Y EJECUCIÓN DE PROGRAMAS EN JAVA -------- 47
ILUSTRACIÓN 9: CICLO DE VIDA DE UN SERVLETS------------------------------------------- 50
ILUSTRACIÓN 10: ORGANIGRAMA --------------------------------------------------------------------- 58
ILUSTRACIÓN 11: CRONOGRAMA DE ACTIVIDADES ----------------------------------------- 71
ILUSTRACIÓN 12 INICIO DE SESION: --------------------------------------------------------------- 173
ILUSTRACIÓN 13: PANTALLA DE BIENVENIDA ------------------------------------------------- 174
ILUSTRACIÓN 14: MANTENIMIENTO DE USUARIO ------------------------------------------- 175
ILUSTRACIÓN 15: REGISTRO DE USUARIO ----------------------------------------------------- 176
ILUSTRACIÓN 16: ELIMINAR USUARIO------------------------------------------------------------- 177
ILUSTRACIÓN 17: MANTENIMIENTO DE ACCIÓN --------------------------------------------- 178
ILUSTRACIÓN 18: REGISTRO DE ACCIÓN-------------------------------------------------------- 178
ILUSTRACIÓN 19: BUSCAR ACCION---------------------------------------------------------------- 179
ILUSTRACIÓN 20: RESULTADO DE BUSQUEDA DE ACCIÓN ---------------------------- 179
ILUSTRACIÓN 21: MANTENIMIENTO TIPO DOCUMENTO --------------------------------- 180
ILUSTRACIÓN 22: REGISTRAR TRÁMITE INTERNO ------------------------------------------ 181
ILUSTRACIÓN 23: HOJA DE TRÁMITE -------------------------------------------------------------- 181
ILUSTRACIÓN 24: REGISTRO DE TRÁMITE EXTERNO ------------------------------------- 182
ILUSTRACIÓN 25: DESPACHAR O ARCHIVAR DOCUMENTO ---------------------------- 184
ILUSTRACIÓN 26: REGISTRAR DESPACHO DE DOCUMENTO -------------------------- 184
ILUSTRACIÓN 27: REPORTE DE DOCUMENTOS EMITIDOS ----------------------------- 185
ILUSTRACIÓN 28: REPORTE DE DOCUMENTOS RECIBIDOS --------------------------- 185
ILUSTRACIÓN 29: REPORTE DE DOCUMENTOS DESPACHADOS -------------------- 186
ILUSTRACIÓN 30: CERRAR SESIÓN ----------------------------------------------------------------- 186
ILUSTRACIÓN 31: FIN DE SESIÓN -------------------------------------------------------------------- 187
XIV
CAPÍTULO I
DATOS GENERALES DE LA PRÁCTICA
1.1. TIPO DE PRÁCTICA PRE PROFESIONAL
Área: Desarrollo de Software
Tipo: Practica Pre Profesional I
1.2. TÍTULO DE LA PRÁCTICA PRE PROFESIONAL
“Desarrollo del Análisis y Diseño de un Sistema Web con Tecnología J2EE
para los procesos administrativos de Trámite Documentario en la
Universidad Nacional Intercultural de la Amazonía”.
1.3. AUTOR DE LA PRÁCTICA PRE PROFESIONAL
REÁTEGUI MACEDO, Ruddy Enzo
1.4. ASESOR
Ing. Mg. Hilario Rivas, Jorge Luis
1.5. COLABORADORES
- Ing. Luis Rivera Echegaray
- Est. Henrri Trujillo Romero
- Est. Jelmi Esteban Santamaría
- Est. Carlos Panduro Vía
1.6. PERIODO DE LA PRÁCTICA
Inicio: 4 de Octubre del 2011.
Fin: 5 de enero del 2012.
1.7. INSTITUCIÓN Y ÁREA DONDE SE DESARROLLÓ LA PRÁCTICA
Universidad Nacional Intercultural de la Amazonia
1
CAPÍTULO II
ASPECTOS GENERALES DE LA EMPRESA
2.1. RAZÓN SOCIAL
Universidad Nacional Intercultural de la Amazonia
2.2. ACTIVIDADES
 Conservar, aprender, acrecentar y transmitir la cultura de los pueblos
amazónicos y universales con sentido crítico y creativo, afirmando
preferentemente los valores amazónicos, regionales y nacionales.
 Realizar investigaciones en humanidades, ciencias y tecnología y
fomentar la creación intelectual y artística.
 Formar profesionales humanistas, científicos con alta calidad
académica, de acuerdo con las necesidades del País, desarrollar en
sus miembros los valores éticos y cívicos.
 Extender acciones y servicios a la comunidad y promoviendo su
desarrollo integral.
 Estimular la práctica de los valores éticos, cívicos y culturales,
orientados a la realización humana.
 Atender la formación profesional, la investigación científica y las
actividades de extensión cultural de los grupos etnolingüísticos de la
Región Amazónica.
 Fomentar el desarrollo sostenible de la Amazonía y la preservación
de su riqueza pluricultural.
 Contribuir a comprender, interpretar, preservar y difundir la cultura
indígena en un contexto de pluralidad y diversidad cultural
amazónica.
2.3. ASPECTOS TÉCNICOS
2
2.3.1. UBICACIÓN GEOGRÁFICA
- Carretera a San José km 0.5, Puerto Callao-Yarinacocha
Ilustración 1: Ubicación de la UNIA
3
2.3.2. ORGANIZACIÓN INSTITUCIONAL
Ilustración 2: Organigrama
4
CAPÍTULO III
OBJETIVOS Y JUSTIFICACIÓN
3.1. PLANTEAMIENTO DEL PROBLEMA
3.1.1. FORMULACIÓN DEL PROBLEMA
En la actualidad existen empresas e instituciones dedicadas a
otorgar bienes y servicios, las cuales con el paso del tiempo tienden
a adaptarse a la tecnología del presente siglo XXI, empresas como
universidades, instituciones, etc.
Estas empresas están sometidas a la competitividad del mercado,
no solo local, sino también nacional, ya que existen grandes
demandas en la región o país.
Así estas empresas dedicadas a la formación académica como lo
es una Universidad, requieren adaptarse a dicha tecnología, en la
formación de un profesional aparte de contar con maquinarias y
equipos de actualidad se necesita información rápida, precisa y
confiable.
Las características de las universidades dependen de cada país y
del periodo histórico en cuestión. Los historiadores creen que la
universidad más antigua es la Escuela Superior que se creó en
China durante el periodo Yu (2257 a.C.-2208 a.C.). Más parecidas
a las universidades actuales eran las escuelas persas de Edesa y
Nísibis, desarrolladas entre el siglo IV y finales del siglo V.
La noción de universidad moderna está asociada al pensamiento
empírico y a los descubrimientos científicos que llegaron tras la
revolución industrial comenzada en el siglo XVIII.
5
El desarrollo de Internet permite pensar en una evolución de las
universidades, ya que la educación presencial en las aulas físicas
puede complementarse o hasta ser reemplazada por las clases a
distancia. Con la ayuda de videoconferencias, chat, el correo
electrónico y otras aplicaciones tecnológicas, la universidad está en
condiciones de digitalizarse. De esta forma, se reducen los límites
físicos (como la distancia geográfica) para el acceso a la formación
universitaria.
Las Tic’s juegan un papel importante en la sociedad y en las
universidades, por ello hacer uso de los sistemas de información
para minimizar tiempo y costo en un factor relevante; con los
software adecuado realizar un sistema de información que se
ajusta a la medida del usuario facilitan los procesos a realizarse en
trámite documentario
3.1.2. JUSTIFICACIÓN
TEÓRICA
Un sistema WEB permitirá dar apoyo a tareas de las diferentes
jerarquías de la empresa, como el análisis y el control de los
mismos, además de permitir sistematizar y automatizar procesos
en tiempo real, dado que un Sistema WEB puede ser ejecutado vía
Internet e Intranet desde un navegador WEB, el cual es capaz de
soportar el lenguaje de este sistema.
6
PRÁCTICA
El Sistema planteado mejorará el control de los procesos dando
satisfacción tanto a los colaboradores como a los clientes de la
empresa, así mismo, permitirá integrar las sedes, con la finalidad
de inspeccionar los movimientos realizados en estas.
METODOLÓGICA
Para el desarrollo del proyecto se utilizará el Proceso Unificado
Racional, el cual es un proceso de desarrollo de software que junto
con el Lenguaje Unificado de Modelado UML, constituye la
metodología estándar más utilizada para el análisis,
implementación y documentación de sistemas orientados a
objetos.
Este conjunto de herramientas de desarrollo estará apoyado con la
herramienta de Lenguaje Unificado de Modelado, que permitirá
expresar de forma gráfica los procesos del sistema de manera que
sea reutilizable para mantenimientos futuros.
3.1.3. OBJETIVOS
General
Desarrollar el análisis y diseño de un Sistema Web con Tecnología J2EE
para los procesos administrativos de Trámite Documentario en la
Universidad Nacional Intercultural de la Amazonía.
7
Específicos
1. Identificar los procesos administrativos de trámite documentario en
la Universidad Nacional Intercultural de la Amazonia.
2. Aplicar la metodología RUP y UML para el análisis y diseño de
desarrollo de software en la Universidad Nacional Intercultural de
la Amazonia.
3. Utilizar UML como herramienta para modelar el Sistema WEB con
tecnología J2EE en la Universidad Nacional Intercultural de la
Amazonia.
4. Realizar el documento de requisito para el correcto análisis y
diseño de un sistema web con tecnología .JSP, además de
Framework JQuery para los procesos trámite documentario y
validaciones de la misma en la Universidad Nacional Intercultural
de la Amazonia.
8
CAPÍTULO IV
MARCO TEÓRICO
4.1. ANTECEDENTES DEL ESTUDIO
En estos últimos años el uso de los Sistemas Web en las organizaciones
son de vital importancia ya que constituye una herramienta favorable para
optimizar los procesos y políticas de negocio dentro de ella; existen
Sistemas que brindan reportes o informes que permiten plantearse
diferentes alternativas para toma de decisiones, así también los que
aceleran procesos tediosos.(Ruddy Enzo Reátegui Macedo)
Estos sistemas Web pueden ser desarrollados sobre distintas plataformas
como J2EE, .NET, PHP, etc. A nivel nacional y regional existen
antecedentes de Sistemas Web desarrollados bajo la plataforma J2EE,
por lo que esta investigación se presenta como un desarrollo de estas
investigaciones. (Ruddy Enzo Reátegui Macedo)
9
4.2. PLANTEAMIENTO TEÓRICO DEL PROBLEMA
4.2.1. SISTEMA WEB
Sistema web son aplicaciones que se ejecutan mediante un
servidor WEB, pueden ser ejecutadas vía Internet e Intranet desde
un navegador WEB, el cual es capaz de soportar el lenguaje de
este sistema. (Ruddy Enzo Reátegui Macedo)
En las aplicaciones WEB suelen distinguirse tres niveles (como en
las arquitecturas cliente/servidor de tres niveles): el nivel superior
que interactúa con el usuario (el cliente web, normalmente un
navegador), el nivel inferior que proporciona los datos (la base de
datos) y el nivel intermedio que procesa los datos (el servidor
web).(Lujan Mora, 2007)
Una aplicación web (web-base application) es un tipo especial de
aplicación cliente/servidor, donde tanto el cliente (el navegador,
explorador o visualizador) como el servidor (servidor web) e el
protocolo mediante el que se comunican (HTTP) están
estandarizados y no han de ser creados por el programador de
aplicaciones. (Lujan Mora, 2007)
Ilustración 3: PROTOCOLO HTTP
Fuente: (Lujan Mora, 2007)
10
Arquitectura Cliente/Servidor
Es una arquitectura descentralizada que permite a los usuarios
finales obtener acceso a la información de forma transparente; es
decir que al usuario le es indiferente de donde viene la información.
Clientes y servidores son entidades lógicas independientes que
operan en conjunto a través de una red para realizar una tarea.
Con la proliferación de ordenadores personales de bajo coste en el
mercado, los recursos de sistemas de información existentes en
cualquier organización se pueden distribuir entre ordenadores de
diferentes tipos: ordenadores personales de gama baja, media y
alta, estaciones de trabajo, mini ordenadores o incluso grandes
ordenadores.
El concepto de cliente/servidor proporciona una forma eficiente de
utilizar todos estos recursos de máquina de tal forma que la
seguridad y fiabilidad que proporcionan los entornos mainframe se
traspasa a la red de área local. A esto hay que añadir la ventaja de
la potencia y simplicidad de los ordenadores personales.
La arquitectura cliente/servidor es un modelo para el desarrollo de
sistemas de información en el que las transacciones se dividen en
procesos independientes que cooperan entre sí para intercambiar
información, servicios o recursos. Se denomina cliente al proceso
que inicia el diálogo o solicita los recursos y servidor al proceso que
responde a las solicitudes.
11
En este modelo las aplicaciones se dividen de forma que el servidor
contiene la parte que debe ser compartida por varios usuarios, y en
el cliente permanece sólo lo particular de cada usuario.
Los clientes realizan generalmente funciones como:
 Manejo de la interfaz de usuario.
 Captura y validación de los datos de entrada.
 Generación de consultas e informes sobre las bases de datos.
Por su parte los servidores realizan, entre otras, las siguientes
funciones:
 Gestión de Periféricos compartidos.
 Control de accesos concurrentes a la Base de Datos.
 Enlaces de comunicaciones con otras redes de área local o
extensa.
Siempre que un cliente requiere un servicio lo solicita al servidor
correspondiente y éste le responde proporcionándolo.
Normalmente, pero no necesariamente, el cliente y el servidor
están ubicados en distintos procesadores. Los clientes se suelen
situar en ordenadores personales y/o estaciones de trabajo y los
servidores en procesadores departamentales o de grupo.
Entre las principales características de la arquitectura
cliente/servidor se pueden destacar las siguientes:
12
 El servidor presenta a todos sus clientes una interfaz única y
bien definida.
 El cliente no necesita conocer la lógica del servidor, sólo su
interfaz externa.
 El cliente no depende de la ubicación física del servidor, ni del
tipo de equipo físico en el que se encuentra, ni de su sistema
operativo.
 Los cambios en el servidor implican pocos o ningún cambio
en el cliente.
a) Arquitectura Cliente Servidor 2 capas
La arquitectura Cliente Servidor de dos capas ha sido la más
utilizada con los lenguajes de cuarta generación. En este tipo
de aplicaciones se desarrollan dos capas:
Una capa llamada front-end (la interfaz de usuario), que
normalmente está constituida de aplicaciones de escritorio
que hacen llamadas a un servidor SQL. La otra capa se
conoce como back-end, normalmente constituida por un
servidor de base de datos con interfaz SQL y un sistema
operativo multitarea.
Aunque este tipo de arquitectura es fácil de implementar, el
hecho de que la lógica del negocio y la presentación se
encuentren almacenados en el cliente (front-end), lleva a que
cambios en la base de datos o en la lógica de negocios
13
implique hacer actualizaciones en todos los clientes. Otra
desventaja es la dificultad de compartir procesos comunes.
b) Arquitectura Cliente Servidor 3 capas
Una arquitectura de tres capas provee adicionalmente una
capa explícita para las reglas del negocio, que se sitúa entre
el front-end y el back-end. Esta capa intermedia encapsula el
modelo de negocio asociado con el sistema y lo separa tanto
de la presentación como del manejo de la base de datos.
Normalmente las reglas del negocio se encapsulan en
componentes, en cada uno de los cuales radican servicios al
usuario.
Por regla general, La capa de la presentación es una interfaz
gráfica que muestra los datos a los usuarios.
La capa de la lógica de negocios es responsable de procesar
los datos recuperados y enviarlos a la capa de presentación.
La capa de datos almacena los datos de la aplicación en un
almacén persistente, tal como una base de datos relacional o
archivos XML.
Se pueden alojar todas las capas en el mismo servidor, pero
también es posible alojar cada capa en varios servidores.
Las ventajas de esta arquitectura son:
 Los servidores del negocio pueden compartirse.
14
 Las plataformas de software y hardware entre clientes y
servidores son independientes: precisamente una de las
principales ventajas de esta arquitectura es la posibilidad
de conectar clientes y servidores independientemente de
sus plataformas.
 Se mantiene la independencia entre el código de la
aplicación (reglas y conocimiento del negocio) y los
datos, mejorando la portabilidad de las aplicaciones.
 Se puede modificar la lógica del negocio sin hacer
cambios a la interfaz del usuario o la base de datos.
 Provee escalabilidad horizontal y vertical. La
escalabilidad horizontal permite agregar más estaciones
de trabajo activas sin afectar significativamente el
rendimiento. La escalabilidad vertical permite mejorar las
características del servidor o agregar múltiples
servidores.
15
c) Arquitectura Cliente Servidor n capas
Los sistemas de n capas están formados por múltiples capas
totalmente independientes y que por lo tanto presentan muy
poco acoplamiento. Una división típica de un sistema de n-
capas será la siguiente:
 Capa de cliente: Está formada por los
componentes que se ejecutan en el cliente. Los
tipos de clientes pueden ser muy variados
(aplicaciones de escritorio, navegadores Web,
dispositivos portátiles, etc). Según el cliente se
distingue entre dos tipos de clientes: "gruesos" y
"finos". Los clientes gruesos representan
aplicaciones que acceden directamente a la capa
de lógica de negocio. Los clientes finos, suelen ser
navegadores Web que acceden a la capa de
presentación.
 Capa de presentación: Se encarga de crear la
presentación que renderizará la capa de cliente.
Actúa como un puente entre la capa de cliente y la
capa de lógica de negocio.
 Capa de lógica de negocio: Esta capa contiene a
todos nuestros objetos de negocio y servicios de
procesado de la lógica de negocio. Suelen
representar una vista objetual de la información
16
presente en la base de datos. El servidor de
aplicaciones se encarga de automatizar gran
cantidad de tareas como la gestión de
transacciones, seguridad, redundancia, balanceo
de carga, cachés, pools, etc.
 Capa de integración: En esta capa suelen
colocarse clases u objetos que automaticen el
acceso a base de datos. No es una capa básica
pero sí que suele utilizarse mucho.
 Capa de datos: Representa los sistemas de
información empresarial de nuestra organización.
Suele estar formada por bases de datos, servidores
de sockets, sistemas legacy, etc. La capa de
integración nos ayuda a acceder a estos sistemas
heterogéneos de la forma más transparente
posible.
Algunas características generales de los sistemas
de n-capas son:
 Tienen una buena fiabilidad y disponibilidad ya
que el servidor de aplicaciones ofrece sistemas
de clustering que aseguran que el sistema está
disponible. No existe un único punto de fallo.
17
 La lógica de negocio está separada del resto de
capas. Un cambio a la lógica de negocio no
implica la modificación de todos los clientes.
Asimismo la capa de presentación nos permite
modificar el interfaz de la aplicación sin tener la
necesidad de realizar cambios en los clientes.
 El rendimiento suele ser muy bueno. El servidor
de aplicaciones ofrece automáticamente soporte
de pool de objetos y conexiones, cachés,
balanceo de carga, gestión de múltiples
instancias, etc.
 Es un modelo con muy buena escalabilidad,
tanto horizontal como vertical.
 La extensibilidad es excelente. Existe poco
acoplamiento entre las diferentes capas.
 La seguridad se encuentra centralizada. Por
contra la seguridad suele implicar gran cantidad
de sistemas y tiene una arquitectura compleja.
18
d) Arquitectura Web
La arquitectura de un sitio Web tiene tres componentes: un
servidor Web, una conexión de red y uno o más clientes
(Browsers).
El servidor Web distribuye páginas de información formateada
a los clientes que la solicitan. Los requerimientos son hechos
a través de una conexión de red y para ello se usa el protocolo
HTTP.
La arquitectura de las aplicaciones Web está evolucionando
hacia modelos más avanzados que permitan cumplir los
requisitos de las empresas que invierten en Internet. La
aparición de clientes dinámicos y nuevos dispositivos, y el
compromiso de nuevos servicios Web, están orientando las
tecnologías de desarrollo de aplicaciones para Internet en una
nueva dirección.
La información mostrada en las páginas esta típicamente
almacenada en un archivo. Sin embargo muchas veces esta
información esta almacenada en una base de datos y las
páginas son creadas dinámicamente. Los sitios Web que
usan este esquema son llamados sitios Web dinámicos.
19
Ilustración 4: Arquitectura de un sitio Web básica
Web Server Http Client Browser
Di
e rs
st
nd
ri b
e
ut
R
es
Web Page
Fuente: (Propio, 2012)
Ilustración 5: Arquitectura de un sitio Web dinámico
4.2.1.1. SISTEMA
Un sistema es un todo lo que está definido por la(s) función(es)
que realiza como parte uno o varios sistemas más grandes, y
consiste en dos o más partes esenciales, sin las cuales no
puede llevar a cabo las funciones que lo definen. (Herrsch,
2008)
20
Un sistema es un conjunto de componentes que interactúan
entre sí para lograr un objetivo común. (Fernandez Alarcon,
2006)
Conjunto de cosas que ordenadamente relacionadas entre sí,
contribuyen a determinado objeto. (Arahal, Berenguel Soria, &
Rodriguez Diaz, 2006)
Un sistema es un objeto formado por un conjunto de cosas o
partes, entre las cuales se establece alguna forma de relación
que las articula en la unidad que es el sistema. (Arahal,
Berenguel Soria, & Rodriguez Diaz, 2006)
El término sistema se deriva del griego, que a su vez se deriva
de synistemi que significa: conjugar, combinar, organizar. El
término se encuentra ya en los diálogos de Platón con el
significado de fuerza conjunta (en leyes) y de composición (en
Filebus). (González Casanova & Roitman Rosenmann, 2006)
Un sistema es una combinación de componentes que actúan
juntos y realizan un objetivo determinado. Un sistema no está
necesariamente limitado a los sistemas físicos. (Ogata, 2006)
TIPOS DE SISTEMAS
Según su constitución:
 Físicos. Sistemas formados por objetos reales, que
interactúan con todo su entorno en el cual es utilizado.
21
 Abstractos. Sistemas formados por ideas, que no se
pueden ver ni tocar, algo que no existe en el medio,
puede ser un software.
Según su naturaleza:
 Cerrados. Sistema que no interactúa con el medio que
los rodea, solo existen teóricamente.
 Abiertos. Sistemas que interactúan con el medio que
los rodea, están en todos lados, desde el universo
hasta una partícula microscópica. (Fernandez Alarcon,
2006)
4.2.1.2. WEB
La Word Wide Web, más conocida como Web, es una de las
áreas de internet que se ha desarrollado más rápidamente.
Nació en 1989, como parte del proyecto del CERN de suiza y
con el objetivo de mejorar el intercambio de información dentro
de Internet, y vea en lo que se ha convertido actualmente.
(Hobbs, 2007)
4.2.1.3. SISTEMA INFORMÁTICO
Un sistema informático es el conjunto de hardware y software
y el equipo humano que puede interactuar con esta
asociación.(Martinez Perales, 2009)
22
Es el conjunto formado por uno o varios ordenadores y sus
periféricos (componentes, físicos o hardware), que ejecutan
aplicaciones informáticas (componente lógico o software) y
que son controlados por cierto personal especializado
(componente humano). (Desonglez Corrales, 2006)
Un conjunto de recursos interrelacionados dinámicamente y
organizados en torno al objetivo de satisfacer las necesidades
de información de una organización mediante la correcta
gestión de datos. (Pablos Heredero, 2006)
4.2.1.4. INGENIERÍA DE SOFTWARE
La ingeniería del software es una disciplina de la ingeniería
que comprende todos los aspectos de la producción de
software desde las etapas iniciales de la especificación del
sistema, hasta el mantenimiento de éste después de que se
utiliza. (Sommerville, 2007)
La ingeniería de software es el establecimiento y uso de
principios robustos de la ingeniería a fin de obtener
económicamente software que sea fiable y que funcione
eficientemente sobre maquinas reales. (Pressman, 2007)
SOFTWARE
Los productos de software se pueden desarrollar para algún
cliente en particular o para un mercado general. (Sommerville,
2007)
23
Muchas personas asocian el término software con los
programas de computadora. Sin embargo, yo prefiero una
definición más amplia donde el software no solo son
programas, sino todos los documentos asociados y la
configuración de datos que se necesitan para hacer que estos
programas operen de manera correcta. (Sommerville, 2007)
El software del sistema es un conjunto de programas
generalizados que administra los recursos de las
computadoras, como el procesador central, los enlaces de
comunicaciones y los dispositivos periféricos. (Laundon &
Laundon, 2004)
Es la parte lógica de un sistema de cómputo. Se define como
programática, ya que incluye todo lo no tangible de la
computación, es decir, son todos los programas del sistema,
de aplicación y los lenguajes de programación. (Orozco
Guzman, Chavez a la Torre, & Chavez a la Torre, 2007)
El software de computadora es el producto que diseñan y
construyen los ingenieros del software. Esto abarca
programas que se ejecutan dentro de una computadora de
cualquier tamaño y arquitectura, documentos que comprenden
formularios virtuales e impresos y datos que combinan
números y texto y también incluyen representaciones de
información de audio, video e imágenes. (Pressman, 2007)
LENGUAJE DE PROGRAMACIÓN
24
Un lenguaje de programación, proporciona métodos para
modificar el flujo del programa permitiendo pasar varias veces
por un conjunto de instrucciones.
Los lenguajes de programación, en los que los programadores
escriben instrucciones para las computadoras, también son
parte del sistema de software. Las instrucciones se traducen a
señales eléctricas que la computadora puede manipular y
procesar.(Besken, Cram, Duffy, Friedrichsen, & Eisner Reding,
2009)
Un lenguaje de programación es un sistema notacional para
describir computaciones en una forma legible tanto para la
maquina como para el ser humano.(Kenneth C., 2006)
Un lenguaje de programación propone un motor de gestión de
un tipo de organización. (Gabillaud, 2008)
Los lenguajes de programación se clasifican en paradigmas,
es decir se refiere a una manera de conceptuar y estructurar
las tareas que realiza una computadora.(Jamrichoja Parsons,
2008)
PROGRAMACIÓN ORIENTADA A OBJETOS
El análisis y diseño orientado a objetos es un enfoque cuyo
propósito es facilitar el desarrollo de sistemas que deben
cambiar con rapidez en respuesta a entornos de negocios
dinámicos.
25
Es difícil trabajar con técnicas orientadas a objetos en
situaciones en las cuales sistemas de información complicados
requieren de mantenimiento, adaptación y rediseño de manera
continua. Los enfoques orientados a objetos utilizan el estándar
de la industria para la modelación (UML, Unified Modeling
Language), para analizar un sistema en forma de modelo de
casos de uso.(Cerezo López, 2007)
La programación orientada a objetos difiere de la programación
tradicional de procedimientos que en la primera examina los
objetos que conforman un sistema. Cada objeto es una
representación en computadora de alguna cosa o suceso real.
(Kendall, Kendall, & Nuñes Ramos, 2006)
La programación orientada a objetos (POO) es una forma de
programación en computadoras que surge en los años 70 pero
tiene un desarrollo sorpréndete los años 90 al utilizarlo en las
microcomputadoras. Se diferencia de la programación clásica
en que las instrucciones hacen referencia a los elementos del
entorno. Esos elementos representan “objetos”, y todos los
datos y todas las acciones que se hagan con ellos, están
encapsuladas u ocultas en el objeto.
26
La POO combina la programación estructurada con conceptos
nuevos con el objetivo de descomponer los datos del programa
en objetos que simplifiquen su tratamiento. La programación
orientada a objetos consiste en organizar el programa en un
conjunto de objetos que interaccionen los unos con los otros,
en donde cada objeto tiene su propio rol en las tareas que deba
realizarse.(Aumaille, 2005)
a) Características
 Abstracción. La abstracción consiste en captar las
características esenciales de un objeto, así como su
comportamiento. Por ejemplo, en los automóviles, ¿Qué
características podemos abstraer de ellos? O lo que es
lo mismo ¿Qué características semejantes tienen todos
los automóviles? Todos tendrán una marca, un modelo,
número de chasis, peso, llantas, puertas, ventanas, etc.
Y en cuanto a su comportamiento todos los automóviles
podrán acelerar, frenar, retroceder, etc.
En los lenguajes de programación orientada a objetos, el
concepto de Clase es la representación y el mecanismo
por el cual se gestionan las abstracciones.
27
 Encapsulamiento. El encapsulamiento consiste en unir
en la Clase las características y comportamientos, esto
es, las variables y métodos. Es tener todo esto en una
sola entidad. En los lenguajes estructurados esto era
imposible. La utilidad del encapsulamiento va por la
facilidad para manejar la complejidad, ya que tendremos
a las Clases como cajas negras donde sólo se conoce el
comportamiento pero no los detalles internos, y esto es
conveniente porque nos interesará será conocer qué
hace la Clase pero no será necesario saber cómo lo
hace.
 Herencia. La herencia es uno de los conceptos más
cruciales en la POO. La herencia básicamente consiste
en que una clase puede heredar sus variables y métodos
a varias subclases (la clase que hereda es llamada
superclase o clase padre). Esto significa que una
subclase, aparte de los atributos y métodos propios, tiene
incorporados los atributos y métodos heredados de la
superclase. De esta manera se crea una jerarquía de
herencia.
28
 Polimorfismo. Es la capacidad de que diferentes objetos
reaccionen de distinta forma a un mismo mensaje. Es la
capacidad de referirse a objetos de clases distintas en
una jerarquía utilizando el mismo elemento de programa
(método) para realizar la misma operación, pero de
manera diferente.
OBJETO
Es una instancia que responde a mensajes activando un
método. (Sabana Mendoza, 2006)
Un objeto es una instancia u ocurrencia concreta de la
abstracción que representa la clase. (Matsukawa Maeda, 2006)
Un objeto es una entidad prevista de un conjunto de
propiedades o atributos (datos) de un comportamiento o
funcionalidad (métodos) y de sus posibles relaciones con otros
objetos.
El concepto de objeto tiene un concepto equivalente al objeto
de nuestro mundo real. En nuestro entorno siempre estamos
en constante relación con objetos: los creamos, los usamos, los
modificamos cambiando sus atributos, características o
propiedades, los relacionamos con otros objetos, etc. Por
ejemplo tenemos el objeto Automóvil. Un automóvil es un
objeto bastante pesado que tiene un conjunto de propiedades
como su identificación (placa), color, marca, modelo,
accesorios, etc. Tiene también un conjunto de funciones como
la desplazarse, detenerse, ponerse en marcha. Podemos
29
cambiarle de color, aumentar o quitar accesorios; es decir
podemos modificar sus propiedades. Tienen de la capacidad
de ser activos para poner en acción sus funcionalidades; es
decir, disponemos de un procedimiento para ponerlo en
marcha, avanzar en retroceso, detenerlo, voltear a la izquierda
o derecha; es decir, mediante un conjunto de métodos
podemos darle uso al objeto automóvil. (Condor, 2007)
Un objeto básico es una «unidad de texto» creado por un
ingeniero de software durante el análisis, diseño, codificación o
pruebas.
Por ejemplo, un objeto básico podría ser una sección de una
especificación de requisitos, un listado fuente de un módulo o
un conjunto de casos prueba que se usan para ejercitar el
código. Un objeto compuesto es una colección de objetos
básicos y de otros objetos compuestos. (Pressman, 2007)
Un objeto pertenece a un tipo específico (que aquí se llama
clase) y tendrá una serie de operaciones (o métodos) definidas
sobre todos los objetos de esa clase. (Galindo Gómez &
Rodríguez Corral, 2006)
30
ORIENTADO A OBJETOS
La orientación a objetos proporciona una solución que conduce
a un universo de objetos, que interactúan entre sí para cumplir
los diferentes requerimientos. (Sabana Mendoza, 2006)
El modelo orientado a objetos se basa en encapsular código y
datos en una unidad lógica, llamada objeto. (Alarcon Herrera &
Crovetto Huerta, 2006)
Es una forma de programación en computadoras que surge los
años 70 pero tiene un desarrollo sorprendente en los años 90
al utilizarlo en microcomputadores. Se deferencia de la
progresión clásica o estructurada en que las instrucciones
hacen referencia a los elementos del entorno. Esos momentos
representan “objetos”; y todos los datos y acciones que se
hagan con ellos o sobre ellos, están encapsuladas u ocultas en
el objeto. “Un objeto es una entidad provista de un conjunto de
propiedades o atributos (datos), de un comportamiento o
funcionalidad (métodos) y de sus posibles relaciones con otros
objetos”.
31
4.2.1.5. SISTEMA GESTOR DE BASE DE DATOS
Es una aplicación que permite a los usuarios definir, crear,
y mantener la base de datos, y proporciona acceso controlado
a la misma. (Alarcon Herrera & Crovetto Huerta, 2006)
El SGBD es la aplicación que interacciona con los usuarios de
los programas de aplicación y la base de datos. (Pantigoso
Silva, 2009)
DBMS es una colección de numerosas rutinas de software
interrelacionadas, cada una de las cuales es responsable de
una tarea específica. (Pantigoso Silva, 2009)
Son un tipo de software muy específico, dedicado a servir de
interfaz entre las bases de datos y las aplicaciones que la
utilizan, consiguiendo, que el acceso a los datos se realice de
una forma más eficiente, más fácil de implementar, sobretodo
más seguro. (Sabana Mendoza, 2006)
BASE DE DATOS
Una base de datos es un conjunto de datos almacenados entre
los que existen relaciones lógicas y ha sido diseñada para
satisfacer los requerimientos de información de una empresa u
organización. (Pantigoso Silva, 2009)
La base de datos es un gran almacén de datos que se define
una sola vez y que se utiliza al mismo tiempo por muchos
departamentos y usuarios. (Pantigoso Silva, 2009)
32
Es una colección de archivos interrelacionados, son creados
con un DBMS. El contenido de una base de datos engloba a la
información concerniente (almacenadas en archivos) de una
organización, de tal manera que los datos estén disponibles
para los usuarios, una finalidad de la base de datos es eliminar
la redundancia o al menos minimizarla. (Pantigoso Silva, 2009)
Una base de datos es una colección de datos estructurados
según un modelo que refleje las relaciones y restricciones
existentes en el mundo real. (Sabana Mendoza, 2006)
Una base de datos es un conjunto de datos almacenados entre
los que existen relaciones lógicas y ha sido diseñada para
satisfacer los requerimientos de información de una empresa u
organización. (Alarcon Herrera & Crovetto Huerta, 2006)
DATO
Es una información que refleja el valor de una característica de
un objeto real, sea concreto o abstracto, o imaginario. Debe
permanecer en el tiempo, debe tener un significado y debe ser
manipulable mediante operadores. (Sabana Mendoza, 2006)
33
Conjunto de caracteres con algún significado, pueden ser
numéricos, alfabéticos, o alfanuméricos. (Pantigoso Silva,
2009)
Es un concepto básico elemental que es susceptible de ser
captado por la mente, es decir, son los hechos, la materia prima
de la información. (Orozco Guzman, Chavez a la Torre, &
Chavez a la Torre, 2007)
Los datos consisten en hechos y cifras que tienen de algún
modo de existencia propia e independiente y que tiene poco
significado para el usuario. Una característica más significativa
de los datos es que por ellos mismos no indican ni son
relevantes o irrelevantes, ya que es necesario definir un
contexto en donde establecerla. (Fernandez Alarcon, 2006)
SQL SERVER
Es un administrador de base de datos relacional de arquitectura
cliente/servidor (RDPMS) que usa órdenes SQL, conocidas
como Transact-SQL, para mandar requerimientos desde un
cliente al SQL Server. (Sabana Mendoza, 2006)
SQL Server es un sistema de gestión de base de datos
relacionales (SGBDR), desarrollados por Microsoft, que
permite, como su propio nombre indica, la gestión de un
entorno de bases de datos relacional. (Pantigoso Silva, 2009)
34
4.2.1.6. PROCESO UNIFICADO DE RATIONAL
Concepto
El Proceso Unificado Rational es un proceso de Ingeniería de
software. Este provee un enfoque disciplinado de tareas y
responsabilidades dentro de una organización para su
desarrollo. Su meta es asegurar la producción de software de
una calidad superior que satisfaga las necesidades de sus
usuarios finales, dentro de una administración y cronograma
establecido.
El Proceso Unificado Rational realiza la productividad del
equipo, proporcionándole el acceso fácil a cada miembro del
equipo que está desarrollando el sistema, a una base de
conocimientos con las pautas, plantillas y guías de la
herramienta para toda actividad crítica de desarrollo. Teniendo
todos los miembros del equipo el acceso a la misma base de
conocimiento, no importa si se trabaja con los requerimientos,
diseño, prueba, administración del proyecto, o administración
de la configuración, se asegura que todos los miembros del
equipo comparten un lenguaje común, un proceso común y una
visión de cómo se desarrollará el software.
Las actividades del Proceso Unificado Rational crean y
mantienen modelos más que enfocarse en cantidades de
producción de documentos en general. El Proceso Unificado
Rational enfatiza el desarrollo y mantenimiento de modelos,
para una representación rica en semántica para el desarrollo
del software del sistema.
35
Orígenes
El antecedente más importante lo ubicamos en 1967 con la
Metodología Ericsson (Ericsson Approach), ésta es una
aproximación de desarrollo basada en componentes, que
introdujo el concepto de caso de uso; entre los años de 1987 a
1995 Jacobson funda la compañía “Objectory AB” y lanza el
proceso de desarrollo Objectory (abreviación de Object
Factory), posteriormente en 1995 “Rational Software
Corporation” adquiere “Objectory AB” y es entre 1995 y 1997
que se desarrolla “Rational Objectory Process (ROP)” fruto del
encuentro y evolución de Objectory 3.8 y la Metodología
Rational (Rational Approach) que adopta por primera vez UML
como lenguaje de modelamiento.
A principios de los noventas, la guerra de los métodos hizo
evidente la necesidad de unificar criterios, es así como Grady
Booch autor del método Booch y James Rumbaugh
(desarrollador para General Electric) se unieron en Rational en
1994, después en 1995 se une Jacobson y gracias al esfuerzo
de varias compañías y metodologistas evolucionó UML hasta
ser un estándar en 1997, el cual es adoptado en todos los
modelos del ROP. Desde ese entonces y a la cabeza de Booch,
Jacobson y Rumbaugh, Rational ha desarrollado e incorporado
diversos elementos para expandir el ROP, destacándose
especialmente el flujo de trabajo conocido como modelamiento
del negocio, es así como en junio del 1998 se lanza Rational
36
Unified Process 5.0 evolucionado hasta el momento de
elaboración de este documento bajo el nombre de RUP.
Características
a) Guiado/Manejado por casos de uso: La razón de ser de un
sistema software es servir a usuarios ya sean humanos u otros
sistemas; un caso de uso es una facilidad que el software debe
proveer a sus usuarios. Los casos de uso reemplazan la
antigua especificación funcional tradicional y constituyen la
guía fundamental establecida para las actividades a realizar
durante todo el proceso de desarrollo incluyendo el diseño, la
implementación y las pruebas del sistema.
b) Centrado en arquitectura: La arquitectura involucra los
elementos más significativos del sistema y está influenciada
entre otros por plataformas software, sistemas operativos,
manejadores de bases de datos, protocolos, consideraciones
de desarrollo como sistemas heredados y requerimientos no
funcionales. Los casos de uso guían el desarrollo de la
arquitectura y la arquitectura se realimenta en los casos de uso,
los dos juntos permiten conceptualizar, gestionar y desarrollar
adecuadamente el software.
c) Iterativo e Incremental: Para hacer más manejable un
proyecto se recomienda dividirlo en ciclos. Para cada ciclo se
establecen fases de referencia, cada una de las cuales debe
ser considerada como un mini proyecto cuyo núcleo
fundamental está constituido por una o más iteraciones de las
37
actividades principales básicas de cualquier proceso de
desarrollo.
d) Desarrollo basado en componentes: La creación de
sistemas intensivos en software requiere dividir el sistema en
componentes con interfaces bien definidas, que posteriormente
serán ensamblados para generar el sistema. Esta
característica en un proceso de desarrollo permite que el
sistema se vaya creando a medida que se obtienen o que se
desarrollen y maduran sus componentes.
e) Utilización de un único lenguaje de modelamiento: UML
es adoptado como único lenguaje de modelamiento para el
desarrollo de todos los modelos.
f) Proceso Integrado: Se establece una estructura que
abarque los ciclos, fases, flujos de trabajo, mitigación de
riesgos, control de calidad, gestión del proyecto y control de
configuración; el proceso unificado establece una estructura
que integra todas estas facetas. Además esta estructura cubre
a los vendedores y desarrolladores de herramientas para
soportar la automatización del proceso, soportar flujos
individuales de trabajo, para construir los diferentes modelos e
integrar el trabajo a través del ciclo de vida y a través de todos
los modelos.
38
Fases en el Ciclo de Desarrollo
Este proceso de desarrollo considera que cualquier desarrollo
de un sistema software debe pasar por cuatro fases que se
describirán a continuación, la figura muestra las fases de
desarrollo y los diversos flujos de trabajo involucrados dentro
de cada fase con una representación gráfica en cuál de los
flujos se hace mayor énfasis según la fase, cabe destacar el
flujo de trabajo concerniente al negocio.
Ilustración 6: Fases RUP
Fuente: IBM
FASE DE INICIACIÓN
Esta fase es el punto de inicio del proyecto y consiste
básicamente en recoger información y desarrollar concepto del
proyecto para tener una visión global del mismo. En esta fase
se analiza que recursos se requieren para llevar a cabo el
proyecto, y su factibilidad. Al finalizar el estudio preliminar se
tomará la decisión de iniciar o no el proyecto. (Matsukawa
Maeda, 2006)
39
Su objetivo principal es establecer los objetivos para el ciclo de
vida del producto. En esta fase se establece el caso del negocio
con el fin de delimitar el alcance del sistema, saber qué se
cubrirá y delimitar el alcance del proyecto.
FASE DE ELABORACIÓN
Esta fase está determinada por el análisis, planificación y
elaboración de la arquitectura del sistema. Lo que se busca es
determinar lo que el sistema debe hacer; es decir, especificar
el comportamiento del sistema. (Matsukawa Maeda, 2006)
Su objetivo principal es plantear la arquitectura para el ciclo de
vida del producto. En esta fase se realiza la captura de la mayor
parte de los requerimientos funcionales, manejando los riesgos
que interfieran con los objetivos del sistema, acumulando la
información necesaria para el plan de construcción y
obteniendo suficiente información para hacer realizable el caso
del negocio.
FASE DE CONSTRUCCIÓN
En esta fase el sistema es construido siguiendo las etapas del
proceso de desarrollo de software: análisis, diseño, codificación
y prueba. (Matsukawa Maeda, 2006)
Su objetivo principal es alcanzar la capacidad operacional del
producto. En esta fase a través de sucesivas iteraciones e
incrementos se desarrolla un producto software, listo para
operar, éste es frecuentemente llamado versión beta.
40
FASE DE TRANSICIÓN
Esta fase se inicia cuando el sistema se ha completado y está
listo para ser entregado a los usuarios. Incluye tareas como:
ejecución de la prueba de aceptación final, finalización de la
documentación del sistema, y capacitación de los usuarios.
(Matsukawa Maeda, 2006)
Su objetivo principal es realizar la entrega del producto
operando, una vez realizadas las pruebas de aceptación por un
grupo especial de usuarios y habiendo efectuado los ajustes y
correcciones que sean requeridos. (Propio, 2012)
4.2.1.7. LENGUAJE DE MODELO UNIFICADO
El UML (Unified Modeling Language o Lenguaje Unificado de
Modelado) es un lenguaje gráfico para la especificación,
visualización, construcción y documentación de piezas de
información usadas o producidas durante el desarrollo de
software.(Liza Avila, 2007)
El Lenguaje Unificado de Modelado (UML), es un lenguaje para
representar modelos de sistemas especialmente intensivos en
el uso de software. (Liza Avila, 2007).
En todas las disciplinas de la Ingeniería se hace evidente la
importancia de los modelos ya que describen el aspecto y la
conducta de "algo". Ese "algo" puede existir, estar en un estado
de desarrollo o estar, todavía, en un estado de planeación. Es
en este momento cuando los diseñadores del modelo deben
41
investigar los requerimientos del producto terminado y dichos
requerimientos pueden incluir áreas tales como funcionalidad,
performance y confiabilidad. Además, a menudo, el modelo es
dividido en un número de vistas, cada una de las cuales
describe un aspecto específico del producto o sistema en
construcción.
El modelado sirve no solamente para los grandes sistemas,
aun en aplicaciones de pequeño tamaño se obtienen beneficios
de modelado, sin embargo es un hecho que entre más grande
y más complejo es el sistema, más importante es el papel de
que juega el modelado por una simple razón: "El hombre hace
modelos de sistemas complejos porque no puede entenderlos
en su totalidad".
UML es una técnica para la especificación sistemas en todas
sus fases. Nació en 1994 cubriendo los aspectos principales de
todos los métodos de diseño antecesores y, precisamente, los
padres de UML son Grady Booch, autor del método Booch;
James Rumbaugh, autor del método OMT e Ivar Jacobson,
autor de los métodos OOSE y Objectory. La versión 1.0 de UML
fue liberada en Enero de 1997 y ha sido utilizado con éxito en
sistemas construidos para toda clase de industrias alrededor
del mundo: hospitales, bancos, comunicaciones, aeronáutica,
finanzas, etc.
42
UML es un Lenguaje, que proporciona un vocabulario y las
reglas para combinar palabras de ese vocabulario con el
objetivo de posibilitar la comunicación.
UML es un Lenguaje para Visualizar, es algo más que un
simple montón de símbolos gráficos; detrás de cada símbolo
en la notación UML hay una semántica bien definida. De esta
manera, un desarrollador puede escribir un modelo en UML y
otro desarrollador o incluso otra herramienta, puede interpretar
este modelo sin ambigüedad.
UML es un Lenguaje para especificar, significa construir
modelos precisos y completos.
UML es un Lenguaje para construir, sus modelos pueden
conectarse de forma directa a una gran variedad de lenguajes
de programación.
UML es un lenguaje para documentar, una organización
produce toda clase de artefactos que incluyen requisitos,
arquitectura, diseño, código fuente, planificación de proyectos,
pruebas, prototipos y versiones. (Propio, 2012)
43
Ilustración 7: Origen UML
Los principales beneficios de UML son:
 Mejores tiempos totales de desarrollo (de 50 % o más).
 Modelar sistemas (y no sólo de software) utilizando
conceptos orientados a objetos.
 Establecer conceptos y artefactos ejecutables.
 Encaminar el desarrollo del escalamiento en sistemas
complejos de misión crítica.
 Crear un lenguaje de modelado utilizado tanto por
humanos como por máquinas.
 Mejor soporte a la planeación y al control de proyectos.
 Alta reutilización y minimización de costos.
UML se puede usar para modelar distintos tipos de sistemas:
sistemas de software, sistemas de hardware, y organizaciones
del mundo real. UML ofrece nueve diagramas en los cuales
modelar sistemas.
44
 Diagramas de Casos de Uso para modelar los procesos
'business'.
 Diagramas de Secuencia para modelar el paso de
mensajes entre objetos.
 Diagramas de Colaboración para modelar interacciones
entre objetos.
 Diagramas de Estado para modelar el comportamiento de
los objetos en el sistema.
 Diagramas de Actividad para modelar el comportamiento
de los Casos de Uso, objetos u operaciones.
 Diagramas de Clases para modelar la estructura estática
de las clases en el sistema.
 Diagramas de Objetos para modelar la estructura estática
de los objetos en el sistema.
 Diagramas de Componentes para modelar componentes.
 Diagramas de Implementación para modelar la distribución
del sistema.
ACTORES
Un actor es un conjunto uniforme de personas, sistemas o
maquinas externos al sistema que estamos modelando, que
cumplen un rol determinado y que interactúan con él. (Liza
Avila, 2007)
Un actor es un rol que el usuario juega con respecto al sistema.
(Liza Avila, 2007)
45
CASOS DE USO
Un caso de uso (Use Case) es una secuencia de acciones
realizadas por el sistema que producen un resultado
observable y valioso para alguien en particular. (Liza Avila,
2007)
Los casos de uso son acciones que debe realizar el sistema,
es por ello que debe nombrárseles mediante un verbo seguido
con el principal objeto que es afectado por la acción. (Liza Avila,
2007)
CLASE
Una clase es un conjunto de cosas que tienen los mismos
atributos y comportamiento. (Liza Avila, 2007)
Una clase es un conjunto de objetos que comparten los mismos
atributos, operaciones, relaciones y semántica. (Liza Avila,
2007)
Una clase es un conjunto de datos (variables o campos) y de
las funciones (los métodos) utilizadas para acceder a estos
datos. (Matsukawa Maeda, 2006)
4.2.2. TECNOLOGÍA J2EE
a) Lenguaje de Programación Java
La tecnología Java consta de un lenguaje de programación y
una plataforma. Java es un lenguaje de programación de alto
nivel que tiene las siguientes características:
46
 Orientado a objetos
 Distribuido y dinámico
 Robusto
 Seguro
 Multitarea
 Portable
La mayoría de los lenguajes de programación se caracterizan
por ser interpretados o compilados, lo que determina la manera
en cómo serán ejecutados en una computadora. Java tiene la
característica de ser al mismo tiempo compilado e interpretado.
El compilador es el encargado de convertir el código fuente de
un programa en un código intermedio llamado bytecode que es
independiente de la plataforma en que se trabaje y que es
ejecutado por el intérprete de Java que forma parte de la
Máquina Virtual de Java.
Gráfico 4: Compilación y ejecución de programas en Java
Ilustración 8: Compilación y ejecución de programas en Java
Fuente: Introducción al Lenguaje Java
47
Entre las características más importantes del lenguaje se
encuentra la robustez. Justamente por la forma en que está
diseñado, Java no permite el manejo directo del hardware ni de
la memoria (inclusive no permite modificar valores de punteros,
por ejemplo). El intérprete siempre tiene el control. El
compilador es suficientemente inteligente como para no
permitir cosas que podrían traer problemas, como usar
variables sin inicializarlas, modificar valores de punteros
directamente, acceder a métodos o variables en forma
incorrecta, etc. Además, Java implementa mecanismos de
seguridad que limitan el acceso a recursos de las máquinas
donde se ejecuta, especialmente en el caso de los Applets (que
son aplicaciones que se cargan desde un servidor y se ejecutan
en el cliente). También está diseñado específicamente para
trabajar sobre una red, de modo que incorpora objetos que
permiten acceder a archivos en forma remota (vía URL por
ejemplo). Además, con el JDK (Java Development Kit) vienen
incorporadas muchas herramientas, entre ellas un generador
automático de documentación.
b) Java Servlets
Los servlets son aplicaciones Java que se ejecutan en el
servidor bajo una arquitectura cliente-servidor-Web,
extendiendo las capacidades del servidor Web. El servidor
donde se ejecutan los servlets debe contar con una máquina
virtual de Java (JVM). Los servlets responden a eventos
generados en las estaciones clientes desde requerimientos
48
HTML, y permiten construir una respuesta dinámica a dichos
requerimientos. Permiten además retornar una respuesta
dinámica a los requerimientos, estos constituyen una mejor
alternativa frente a otras tecnologías como los CGI´s, aunque
ambos permiten generar respuestas dinámicas para los
requerimientos de los clientes, los servlets presentan ventajas
sobre los CGI’s, como por ejemplo la portabilidad e
independencia de la plataforma.
Los servlets al ser componentes escritos en Java, tienen
acceso al conjunto completo de API’s Java que les permiten
interactuar con diferentes tipos de interfaces, como por ejemplo
aquellas que acceden a Bases de Datos. Además pueden
encontrarse en muchos tipos de servidores diferentes pues el
API definido para los servlets, al igual que las demás API’s
Java, no dependen del ambiente del servidor o de los
protocolos utilizados.
Un servletes cargado una sola vez en el servidor Web e
invocado en cada requerimiento. Esto se debe a que los
servlets son programas multihilos (multithread). Los servlets
pueden entonces mantener recursos del sistema como
conexiones a Bases de Datos.
Como los servlets son cargados y ejecutados completamente
en el servidor, sin comunicarse directamente con los usuarios
Web, no requieren la funcionalidad de una interfaz gráfica,
estos implementan una forma simple de interacción entre el
49
cliente y el servidor a través del intercambio de mensajes del
tipo request/response (requerimiento/respuesta).
Ilustración 9: Ciclo de Vida de un Servlets
Fuente: Introducción al Lenguaje Java (10)
c) Java Server Pages
JavaServerPages (JSP), en el campo de la Informática, es una
tecnología para crear aplicaciones Web. Es un desarrollo de la
compañía Sun Microsystems, y su funcionamiento se basa en
scripts, que utilizan una variante del lenguaje java.
JSP, es una tecnología Java que permite a los programadores
generar contenido dinámico para Web, en forma de
documentos HTML, XML, o de otro tipo. Los JSP's permite al
código Java y a algunas acciones predefinidas ser incrustadas
en el contenido estático del documento Web.
En los JSP, se escribe el texto que va a ser devuelto en la salida
(normalmente código HTML) incluyendo código java dentro de
él para poder modificar o generar contenido dinámicamente. El
código java se incluye dentro de las marcas de etiqueta <% y
%>, a esto se le denomina scriptlet.
50
En una posterior especificación, se incluyeron taglib; esto es, la
posibilidad de definir etiquetas nuevas que ejecuten código de
clases java. La asociación de las etiquetas con las clases java
se declara en archivos de configuración en XML.
La principal ventaja de JSP frente a otros lenguajes es que
permite integrarse con clases Java (.class) lo que permite
separar en niveles las aplicaciones Web, almacenando en
clases java las partes que consumen más recursos así como
las que requieren más seguridad, y dejando la parte encargada
de formatear el documento html en el archivo jsp.
Independientemente de la certeza de la aseveración, Java es
conocido por ser un lenguaje muy portable (su lema publicitario
reza: escríbelo una vez, córrelo donde sea), y sumado a las
capacidades de JSP se hace una combinación muy atractiva.
Sin embargo JSP no se puede considerar un script al 100% ya
que antes de ejecutarse el servidor Web compila el script y
genera un servlet, por lo tanto, se puede decir que aunque este
proceso sea transparente para el programador no deja de ser
una aplicación compilada. La ventaja de esto es algo más de
rapidez y disponer del API de Java en su totalidad.
Debido a esto la tecnología JSPJ, así como Java está teniendo
mucho peso en el desarrollo Web profesional (sobre todo en
intranets).
51
4.3. DEFINICIÓN DE TÉRMINOS BÁSICOS
Arquitectura. Un entramado de componentes funcionales que
aprovechando diferentes estándares, convenciones, reglas y
procesos, permite integrar una amplia gama de productos y
servicios informáticos.
Atributo. Es una característica de interés o un hecho sobre una
entidad o sobre una relación. (Alarcon Herrera & Crovetto Huerta,
2006)
Componentes. Que compone o entra en la composición de un
todo.
Confiabilidad. Cualidad de fiable
Eventos. Suceso importante y programado.
Encriptación. Es el proceso para volver ilegible información
considera importante. La información una vez encriptado sólo
puede leerse aplicándole una clave.
Factibilidad. Cualidad o condición de factible
Framework.Una estructura conceptual y tecnológica de soporte
definida, normalmente con artefactos o módulos de
softwareconcretos.
Funciones. Tarea que corresponde realiza una determinada
acción.
52
Implementación. Poner en funcionamiento, aplicar métodos,
medidas, etc., para llevar algo a cabo.
Incertidumbre. Falta de certidumbre.
Incremental. Que crece
Inspección. Cargo y cuidado de velar por algo.
Integrar. Aunar, fusionar dos o más conceptos, corrientes, etc.,
divergentes entre sí, en una sola que las sintetice.
Iterativo. Dicho de una palabra: Que indica repetición o reiteración.
Modelamiento. Ajustarse a un modelo abstracto algo real.
Modelo. Arquetipo o punto de referencia para imitarlo o
reproducirlo.
Nativo. Innato, propio y conforme a la naturaleza de cada cosa.
Operaciones. Conjunto de reglas que permiten, partiendo de una
o varias cantidades o expresiones, llamadas datos, obtener otras
cantidades o expresiones llamadas resultados.
Protocolo. Serie ordenada de escrituras matrices y otros
documentos que un notario o escribano autoriza y custodia con
ciertas formalidades.
Relaciones. Conexión, correspondencia de algo con otra cosa.
53
Requisito. Circunstancia o condición necesaria para algo.
Rol. Cargo o función que alguien o algo cumple en alguna situación
o en la vida.
Servidor. Es una computadoraque, formando parte de una red,
provee servicios a otras computadoras denominadas clientes.
Tecnología. Lenguaje propio de una ciencia o de un arte.
Usuario. Que usa ordinariamente algo.
Universidad. Es una institución de enseñanza superior, dividida en
facultades según las especialidades de estudio que la misma
pueda ofrecer.
Versión. Cada una de las formas que adopta la relación de un
suceso, el texto de una obra o la interpretación de un tema.
54
CAPÍTULO IV
PROCESO DE DESARROLLO DE SOFTWARE
4.1. FASE INICIAL
A. DOCUMENTO DE VISIÓN DEL NEGOCIO
A.1. INTRODUCCIÓN
A.1.1. PROPÓSITO
El propósito de este documento es ofrecer un esquema del
funcionamiento del sistema, a nivel de procesos, actores,y
diagramas del “Desarrollo del Análisis y Diseño de un Sistema
Web con Tecnología J2EE para los procesos administrativos
de Trámite Documentario en la Universidad Nacional
Intercultural de la Amazonía”.
A.1.2. ALCANCE
En este trabajo se realizó el modelamiento del Sistema Web
con Tecnología J2EE para los procesos académicos de
registro de notas y evaluaciones en la Universidad Nacional
Intercultural de la Amazonia; desarrollado por un equipo de
alumnos con una arquitectura cliente servidor es decir de tres
capas.
El sistema permitirá a los usuarios lo siguiente:

 Registrar Trámite.
 Recepionar Documento
 Despachar Documento
 Archivar Documento
55
 Anular Documento
 Registrar Documento
 Registrar Área
 Registrar Oficina.
 Consultar Trámite.
 Generar reportes.
A.2. POSICIONAMIENTO
A.2.1. OPORTUNIDADES DEL NEGOCIO
En la actualidad las organizaciones o empresas reconocen
que los Sistemas de Información son de vital importancia
para la toma de decisiones y para mejorar los procesos que
se realizan en la organización.
Por esto es necesario que la Universidad Nacional
Intercultural de la Amazonía, cuente con un sistema
informático que ayude a realizar los trámites documentarios
de forma efectiva en tiempo real.
Es así que se justifica el desarrollo del Sistema de Trámite
documentario, el cual mejorará el servicio de atención a los
usuarios, además permitirá a la UNIA mejorar la imagen
institucional frente a las demás universidades del País.
La empresa tiene como actividad el control del trámite
documentario, en todo lo concerniente al registro, recepción,
despacho y consulta de documentos.
56
A.2.2. EXPOSICIÓN DEL PROBLEMA
Tabla 1: Exposición del problema
El problemade Inadecuado control de los documentos.

Demora en el flujo de los documentos.
Limitada integración de la información
Los procesos de los trámites no están
automatizados.
Afecta a A la empresa.
Público en General.
El impacto asociado es Al tener un mal control de los
documentos, implica un desorden total
y aumenta el esfuerzo por obtener el
documento deseado, llegando incluso a
la pérdida de estos.
Consultas de trámites ralentizados.
Una solución adecuada La implementación de un Software que
sería sistematice los procesos a realizarse en
la empresa, optimizando el tiempo de la
misma.
A.2.3. EXPOSICIÓN DEL PRODUCTO
Tabla 2: Exposición del producto
Para Universidad Nacional Intercultural de la

Amazonía “UNIA”.
Quienes Personal administrativo de la
Universidad Nacional Intercultural de la
Amazonía.
El nombredel producto SISTRAUNIAv1.0
Que Teniendo la información requerida para
el desarrollo del Sistema, se elaborara
un sistema ajustado a los procesos y
políticas de la Empresa.
Nuestro producto Nuestro producto será desarrollado en
plataforma WEB, con base de datos
SQL Server 2005, se trabajará con
Internet realizando las operaciones en
tiempo real
57
A.3. DESCRIPCIÓN DE STAKEHOLDER Y USUARIOS
A.3.1. MERCADO DEMOGRÁFICO
LaUniversidad Nacional Intercultural de la
Amazoníaactualmente cuentaconun ampliopersonal, quienes
solicitan que el flujo de los documentos sea de una manera
rápida, segura y eficaz, y que actualmente tiene uncontrol
obsoletopararealizar estos procesos.
Ilustración 10: Organigrama
58
A.3.2. SUMARIO DE STAKEHOLDER
Tabla 3: Sumario de Stakeholders
NOMBRE REPRESENTANTE ROL

Directores de Director de o Jefe de Solicita
Oficinas cada oficina de la UNIA información de sus
documentos en
trámites
Público en Docentes, alumnos o Entregar
General instituciones externos a documentos para
la UNIA su respectivo
tramite
UNIA.
Secretaria Persona encargada de Entregar

entregar los documentos a las
documentos demás oficinas
A.3.3. SUMARIO DE USUARIOS
Tabla 4: Sumario de Usuarios.
NOMBRE REPRESENTANTE ROL

Secretarias que se Registran los
Secretarias encuentran en cada documentos, consultan
oficina la ruta del documento.
Directores de Director de o Jefe de Registra los documentos
Oficinas cada oficina de la para su respectivo
UNIA trámite.
Director de Dirección ejecutiva de Administrar los usuarios,
Computo e Computo e Informática registrar documentos.
Informática
59
A.3.4. AMBIENTE DE USUARIOS
Secretarias: Tendrá acceso al sistema de Trámite
Documentario vía Intranet, identificándose con un nombre
de usuario y su respectiva contraseña, que será de tipo de
usuario común, para ello tendrá que tener un ordenador que
se encuentre en su oficina o área que tenga acceso a la red
de la UNIA, en la que podrá registrar los documentos para
hacerle su respectivo trámite.
Jefe de Computo e Informática: Tendrá los privilegios de
acceder a la base de datos realizada en SQL.
Identificándose con un nombre de usuario y su respectiva
contraseña en la cual será de tipo Administrador, que tendrá
todos los privilegios que contempla el sistema.
Directores de Oficina: Tendrá acceso al sistema de
Trámite Documentario vía Intranet, identificándose con un
nombre de usuario y su respectiva contraseña, que será de
tipo de usuario común, para ello tendrá que tener un
ordenador que se encuentre en su oficina o área que tenga
acceso a la red de la UNIA, en la que podrá registrar los
documentos para hacerle su respectivo trámite.
60
A.3.5. NECESIDADES PRINCIPALES DE USUARIOS
Tabla 5: Necesidades de los usuarios.
NECESIDAD PRIORID CONCERNIE SOLUCIÓN SOLUCIÓN

AD NTES ACTUAL PROPUESTA
Realizar Tramite Tiempo de Es un sistema El sistema
Interno o respuesta manual que se tramite
Externo lento y carga registra en documentario
ALTA
del trabajo cuadernos se
automatizará
en su totalidad
ConsultarDocum Tiempo de El sistema El sistema de
entos respuesta estotalmentem trámite
ALTA lento e anual documentario
ineficiente automatizará
este proceso.
Saber la Hoja Tiempo de El sistema es El sistema de
deruta, del respuesta totalmente trámite
tramite ALTA lento manual documentario
automatizará
este proceso.
Anular Es una tarea Se espera una Utilizarunabas
documento muy trabajosa mejora de esta ede
MEDIA
por no existir necesidad datosparareali
un orden zar esta tarea
Generar El reporte es Se espera una Utilizarunabas
reportes obtenido de mejora de esta ede
MEDIA un cuaderno necesidad datospararepo
de rtarlo
anotaciones requerido
A.3.6. ALTERNATIVAS
 Alternativa 1: El sistema puede realizarse en plataforma WEB
con formato Jsp en NetBeans, y con base de datos en SQL
Server 2008.
 Alternativa 2: El sistema puede realizarse en plataforma
WEB con formato php en Dreamwiever, con Base de datos en
MySQL.
 Alternativa 3: El sistema puede ser desarrollado en Visual
Basic .NET, con Base de datos SQL Server 2008.
61
Conclusiones:
La alternativa que se adecua más a la experiencia obtenida en el
desarrollo de la carrera profesional, sería la Alternativa 1. Dicha
elección se debe netamente a la experiencia con las herramientas
planteadas.
A.4. OBJETIVOS DE MODELAMIENTO DEL NEGOCIO
Proceso de Gestión del Trámite Documentario

 Registrar Tramite Interno
 Registrar Tramite Externo
 Registrar Acción
 Registrar Tipo de Documento
 Recepcionar Documento
 Despachar o Archivar un Documento
 Consultar Hoja de Ruta del Documento
 Reportes
Proceso de Administración General

 Registrar usuarios del sistema.
Proceso de mantenimiento
 Registrar usuario
 Registrar oficina.
 Registrar área.
 Registrar tipo de documento.
 Registrar acción.
62
A.5. RANGOS DE CALIDAD
DISPONIBILIDAD.Elsistemaseoperaraexclusivamenteenlas
sedesdela Universidad Nacional Intercultural de la Amazoniaen
horariodeatención.
USABILIDAD.Elsistemacontaráconiconosquefacilitaránsu uso,
además mostrarámensajesdeayudaencadaicono,para quelos
usuarios seadecuenrápidamentea dichosistema.
A.6. PANORAMA DEL PRODUCTO
El programa estará realizado en un entorno visual orientado a
objetos, para llevarnos a un análisis rápido de los requerimientos,
las funciones se limitaran a los perfiles de los usuarios.
A.7. REQUERIMIENTOS
A.7.1. FUNCIONALES.
 Registrar Tramite Interno.
 Registrar Tramite Externo.
 Registrar Tipo de documento.
A.7.2. NO FUNCIONALES.
Son aquellos que no afectan la funcionalidad del sistema. En
este caso los requerimientos serían:
 Registrar Acción.
 Recepcionar Documento.
 Despachar Documento.
 Archivar Documento
63
 Consulta Documentos por Asunto, Numero de Tramite,
por la Persona que entrego el documento.
 Registrar Usuarios.
 Reporte de documentos emitidos, recibidos,
despachados.
 Control de flujo de caja.
 Generar reportes.
 Niveles de prioridad del uso del software.
 Desarrollar con Netbeans 6.9.1 y SQL Server 2005.
64
B. PLAN DE DESARROLLO DEL SOFTWARE
B.1. INTRODUCCIÓN
B.1.1. PROPÓSITO
El objetivo de este Plan de Desarrollo de Software es definir
las actividades realizadas durante el desarrollo de las fases
e iteraciones requeridas para llevar a cabo el Sistema
Propuesto.
B.1.2. ALCANCE
Este Plan de Desarrollo de Software describe el plan global
a ser usado por los encargados del proyecto para trabajar
en la implementación de un Desarrollo del Análisis y Diseño
de un Sistema Web con Tecnología J2EE para los procesos
administrativos de Trámite Documentario en la Universidad
Nacional Intercultural de la Amazonía, se describirán los
detalles de los procesamientos individuales del plan. Los
planes que se dan en éste documento se basan en los
requisitos del producto como está especificado en el
documento visión.
B.1.3. REFERENCIAS
Las referencias aplicables son: La visión para la
implementación del Desarrollo del Análisis y Diseño de un
Sistema Web con Tecnología J2EE para los procesos
administrativos de Trámite Documentario en la Universidad
Nacional Intercultural de la Amazonía.
65
B.1.4. APRECIACIÓN GLOBAL
Este Plan de Desarrollo de Software contiene la información
siguiente:
 Proyecto de Apreciación Global: Proporciona la
descripción del propósito del proyecto, alcance y objetivos.
También determina el entregable que se espera en el
proyecto en determinados periodos.
 El Proceso de Dirección: Explica el costo estimado y lo fija,
define las fases mayores e hitos para el proyecto, y describe
el modo de supervisión para el proyecto.
 Los Planes del Proceso Técnicos: Proporciona un
panorama global del proceso de desarrollo de Software,
incluso los métodos, herramientas y técnicas para ser
seguido.
B.2. LA APRECIACIÓN GLOBAL DEL PROYECTO
B.2.1 PROPÓSITO DEL PROYECTO, ALCANCE Y OBJETIVOS
El propósito, alcance y objetivo de este Informe de Practica Pre
Profesional I, es definir las actividades realizadas durante el
desarrollo de las fases e iteraciones requeridas para
implementar el Sistema a realizar.
B.2.2. ENTREGABLES DEL PROYECTO
Los entregables siguientes se desarrollaran durante el
proyecto.
66
Tabla 6: Entregables del proyecto.
Fases WorkFlows Artefactos

Inicial Modelo del  Documento de visión
negocio  Plan de desarrollo de
software
 Modelo USE CASE de
negocio
 Modelo de dominio
Elaboración Requerimientos  Modelo de Use Case
 Especificación de los Use
Case
Análisis y diseño  Diagrama de colaboración
 Diagrama de clases
 Diagrama de secuencias
 Diagrama de Paquetes
Construcción Análisis de diseño  Diseño de base de datos
 Prototipo inicial
Implementación  Diagrama de
componentes
 Diagrama de despliegues
 Prototipo de software final
Transición Prueba  Prueba por Use Case
B.2.3. EVOLUCIÓN DEL PLAN DE DESARROLLO DE SOFTWARE
El Plan de Desarrollo de Software se revisará anterior a la
salida de cada proceso de iteración.
B.3. LA ORGANIZACIÓN DEL PROYECTO
B.3.1. ESTRUCTURA ORGÁNICA
El equipo de trabajo comprende de unalumno practicante de la
Escuela de Ingeniería de Sistemas de la Universidad Nacional
de Ucayali, el asesor de práctica y dos colaboradores de la
organización en estudio, para el desarrollo del proyecto.
67
B.3.2. INTERFACES EXTERNAS
El equipo encargado del proyecto también interactuara con otro
stakeholder para solicitar las entradas y revisión del software.
B.3.3. PAPELES Y RESPONSABILIDADES
Tabla 7: Papeles y Responsabilidades.
PAPEL RESPONSABILIDAD
Practicante Responsabilidad del manejo del
proyecto global.
Responsable principal de manejar
el flujo de trabajo de los requisitos.
Responsable principal para el
análisis y diseño
Organizar turnos para el
mantenimiento del software.
Asesor del Proyecto Brinda asesoría, seguimiento y las
correcciones correspondientes
para el proceso de desarrollo del
proyecto.
68
B.4. PROCESO DE DIRECCIÓN
B.4.1. ESTIMACIÓN DEL PROYECTO
Está basado en el estudio de factibilidad aplicado en el
proyecto. El tiempo del esfuerzo estimado en este informe, es
la base del presupuesto.
B.4.2. PLAN DE PROYECTO
a) PLAN DE FASE
Cuadro 1. Plan de proceso de desarrollo de acuerdo a fases.
Tabla 8: Plan de proceso de desarrollo de acuerdo a fases.
FASE EMPIEZA TERMINA

Fase de Inicio (40%)
04/10/11 18/11/11
Fase de la Elaboración (60%)
21/11/11 05/01/12
Tabla 9: Fases del proyecto e hitos principales
FASE DESCRIPCIÓN HITO
Determina la
Factibilidad del
proyecto desde un
En esta etapa se define el modelo del punto de vista del
negocio, los requerimientos del producto, negocio.
INICIO
se elabora el plan de desarrollo de Se definen los
Software. requerimientos,
características, claves
y principales
restricciones.
La fase de Elaboración analizará los
requisitos y se desarrollará el prototipo
arquitectónico. En la realización de la
fase de la Elaboración todos los casos
de uso seleccionados para una primera
versión 1.0 habrán completado el análisis El hito del Prototipo
y el plan. Arquitectónico marca
ELABORACIÓN
Además se habrán analizado los casos el término de la Fase
de uso de alto riesgo que para una de la Elaboración.
Versión 2.0 ya se habrán diseñado. El
prototipo arquitectónico probará la
viabilidad y actuación de la arquitectura
que se requiere para la Versión 1.0.
Actualización con
Durante la Fase de la construcción se
todos los elementos
CONSTRUCCIÓN analizó los casos de uso restantes y se
necesarios para dar
diseñarán estos. La versión beta para la
soporte a la
69
Versión 1.0 se desarrollará y se implantación de la
distribuirá para la evaluación. persistencia
Completa en la
concordancia con los
requerimientos del
En esta fase se probará, empaquetará,
producto definidas en
distribuirá e instalará el producto con
TRANSICIÓN el documento de
todos los manuales respectivos.
Visión del Negocio. El
producto final debe
estar disponible para
los usuarios.
Cada fase es dividida en las interacciones del desarrollo.

Se espera que la duración del proyecto sea de 3 meses,
el cálculo de esta estimación de tiempo se muestra en el
ANEXO 1.
70
b) Cronograma de Actividades
Ilustración 11: Cronograma de Actividades
71
c) HORARIO DEL PROYECTO
El horario del proyecto que contiene el nombre de las
labores, las fecha de inicio y fin se muestran a
continuación.
Tabla 10: Horario del proyecto
Tareas Empieza Termina
Modelamiento 04/10/11 04/11/11
del negocio
Requerimientos 07/11/11 02/12/11
o trabajo
Análisis y 05/12/11 05/01/12
diseño
B.5. RECURSOS PARA EL PROYECTO
B.5.1. PLAN DE ADQUISICIÓN DE RECURSOS ECONÓMICOS
La Universidad Nacional Intercultural de la Amazonia ha
proyectado asignar a personal especializado para lograr el
objetivo.
B5.2. ENTRENAMIENTO QUE SE PLANEAN
Se entrenará al equipo del proyecto en las siguientes
habilidades, al comienzo de las actividades del plan:
 Análisis Orientado al Objeto
 Proceso Unificado Rational (V 7.0)
 NetBeans 7.1
 SQL Server 2008
 Servidor Web GlassFish
72
B.6. PRESUPUESTO
El siguiente presupuesto se basa en estimaciones iniciales (Ver
Anexo 6):
Tabla 11: Presupuesto del proyecto
Sistema de Trámite Documentario
Trabajo del Personal
Actividades Esfuerzo Costo
Desarrollo del 1612.42 S/.4,000.00

sistema de Trámite horas/hombres*Use
Documentario Vía Case ( Ver Anexo Nº
Web 2)
Total Trabajo del Personal
Gastos de
Aprovisionamiento (
Ver anexo Nº 1 )
Otros gastos 944.00

directos
Total Gastos de S/.944.00

Aprovisionamiento
Total del S/.4,944.00

Presupuesto
73
B.7. ENTORNO DE TRABAJO
B. 7.1. ELECCIÓN DE EQUIPOS Y ACCESORIOS DE LA RED LAN
B.7.1.1. ELECCIÓN DEL SERVIDOR

Tabla 12: Características físicas del servidor
CARACTERÍSTICAS OPCIONES
Procesador IntelXeonIV3.60GHz
Memoria Cachéinterna Caché Interna 1GB
Memoria RAM 2 GB
Disco Duro 500 GBx3
Tarjeta de RED D-linkEthernet10/100
Teclado y Mouse Delux
Monitor 17”FLATRONDigitalLG
Tabla 13: Características logicas del servidor
Sistema Operativo Windows Server
Servidor Web GlassFish
Gestor de Base de Datos SQLServer 2008 R2
B.7.1.2. IMPRESORA
Matricial EpsonLX300+
B.7.1.3. SWITH
Tabla 14: Características concentradoras
Marca DLink
Tecnología Ethernet
TipodeSwitch Activo
Numero de Puertos 24UTP/STP-RJ45
Administración SNMP,RMON
Soporte deotrastecnologías Si
Fuente de Alimentación Si
redundante
B.7.1.4. ACCESORIOS DE RED

Se ha tomado en consideración el estándar de
instalaciones comerciales de red ANSI/EIA/TIA 568-
A.
74
Tipos de Cable a Usar:
 Cable par trenzado (UTP – RJ-45 DE 100 W).
 El cable de par trenzado UTP, tiene 4 partes de hilos
trenzados juntos a seis vueltas por pulgada para producir
protección de inferencias eléctricas más impedancia
consistente, o resistencia eléctrica.
 El Cable par trenzado UTP es cómodo, fácil de instalar y
puede funcionar en red. En la actualidad es muy usado en
redes locales Ethernet (UTP) de 8 hilos.
 Conectores RJ-45 Categorías 5, soportan 4 pares de cables
UTP categoría 5.
 Caja toma de datos (Rosetas) RJ-45 Categoría 5.
 Roseta simple (1 jack) por cada estación de trabajo.
 Montaje con tornillo para facilitar la instalación.
B.7.1.5. ELECCIÓN DEL PC ADMINISTRADOR

Tabla 15: Características del pc Administrador.
Procesador IntelCORE i7 1.73 Ghz
Memoria Cachéinterna 8Mb
Memoria RAM 4 GB
Disco Duro 500 GB
Tarjeta de RED DlinkEthernet 10/100
Teclado y Mouse Genius
Monitor 17”DigitalSony
75
B.7.1.6. ELECCIÓN DE LAS PC CLIENTE
Tabla 16: Características de las estaciones cliente
Procesador IntelCORE i7 1.73 Ghz
Memoria Cachéinterna 8Mb
Memoria RAM 4 GB
Disco Duro 500 GB
Tarjeta de RED DlinkEthernet 10/100
Teclado y Mouse Genius
Monitor 17”DigitalSony
B.8. VISTAS CASOS DE USO
B.8.1. MODELO DE CASOS DE USO DEL NEGOCIO
Gráfico 1: Casos de Uso de Sistema de Trámite Documentario
Administracion General
Jefe de la oficina de Informatica
Proceso de Gestion de tramite documentario

Secretaria
Publico
Director de Oficina
76
B.8.2. MODELO DE OBJETO DE NEGOCIO
Gráfico 2: MON: Administración General.
Persona
CRUDR
CRUD
Usuario
Oficina
R
Administrador General
CRUD
Area
CRUD
Tipo de Documentos
Accion
77
Gráfico 3: MON: Proceso de Gestión de Trámite Documentario
Consultar Tramite
Registrar
Publico Tipo de Documentos
(f rom Business Use-Case Model)

R
Operador
Consultar
Accion
Consultar
Director de Oficina
(f rom Business Use-Case Model)
Oficina
Area
78
B.8.3. MODELO DE DOMINIO
Gráfico 4: Modelo de Dominio
TIPO DOCUMENTO, TRAMITE, ACCION,
1 1..* 1..* 1
OFICINA, AREA, PERSONA,
1..* 1 1 1..*
79
B.9. DESCRIPCIÓN DEL PROCESO DEL NEGOCIO
Tabla 17: Descripción del proceso del negocio.
ESTEREOTIPO DESCRIPCION
En este proceso se realiza los
registros, consultas, reportes,
Gestion
PROCESOdeDE
m GESTION
antenimiento
DE
recepción, hoja de ruta, despacho y
TRÁMITE DOCUMENTARIO
archivado de documentos.
Se asignan a los usuarios que
tendrán acceso al sistema, pero de
solo sus respectivas oficinas, como

Registro y Control de Notas
ADMINISTRACION
también mantenimiento de los tipos
GENERAL
de documentos y acción.
80
CAPÍTULO V
FASE DE ELABORACIÓN
5.1. REQUERIMIENTOS
A) MODELO USE CASE
Gráfico 5: MCU: Administración de Usuario.
Crear
Registrar Accion
<<extend>>
Modificar
<<extend>>
Mantener Usuario
Jefe de la oficina
<<extend>>
de informatica
Eliminar
<<extend>>
Registrar tipo de documentos
Buscar Personal
81
Gráfico 6: Proceso de Gestión de Trámite Documentario.
Registrar tramite
director de oficina secretaria de
oficina
Documentos recepcionados
<<extend>>
Despachar documento
Documentos emitidos
<<extend>>
usuario
Reportes
<<include>>
<<extend>>
Recepcionar documento
<<include>>
Buscar tramite jefe de la oficina Documentos despachados
<<extend>>
de informatica
<<include>>
Archivar documento
<<include>> Documentos Archivados

Consultar estado de tramite
documentario
publico
82
83
B) ESPECIFICACIONES DE LOS USE CASE
Tabla 18: MCU: ADMINISTRACIÓN GENERAL
Caso de Uso Mantener Usuario

Descripción Realiza el mantenimiento de los usuarios al
sistema
Actor Jefe de la oficina de informática
Precondición Existir la persona registrada en la tabla
personal
Secuencia 1. Buscar Personal
Normal 2. Crear usuario del sistema
3. Modificar usuario
4. Eliminar usuario
Caso de Uso Registrar Tipo de Documento

Descripción Realiza el mantenimiento de los tipos de
documentos
Precondición Ninguna
Secuencia 1. Buscar Tipo Documento
Normal 2. Crear Tipo Documento
3. Modificar Tipo Documento
4. Eliminar Tipo Documento
Caso de Uso Registrar Acción

Descripción Realiza el mantenimiento de las posibles
acciones del trámite documentario
Precondición Ninguna
Secuencia 1. Buscar Acción
Normal 2. Crear Acción
3. Modificar Acción
4. Eliminar Acción
Tabla 19: MCU: PROCESO DE GESTIÓN DE TRÁMITE DOCUMENTARIO
Caso de Uso Registrar Trámite

Descripción Realiza el registro del trámite del documento
Actor Usuario
Precondición Existir Área, Tipo de Documento, Acción
Secuencia 1. Buscar Área
Normal 2. Buscar Tipo Documento
3. Buscar Acción.
4. Crear Tramite
84
Caso de Uso Despachar Documento
Descripción Realiza el traslado de un documento a otra
área u oficina
Actor Usuario
Precondición Existir trámite, Área, Tipo de Documento,
Acción
Secuencia 1. Buscar Trámite
Normal 2. Buscar Área
3. Buscar Tipo Documento
4. Buscar Acción.
5. Crear Despacho a otra área
Caso de Uso Recepcionar Documento

Descripción Realiza la recepción de un documento
Actor Usuario
Precondición Existir Trámite
Secuencia 1. Buscar Trámite
Normal 2. Recepcionar documento
85
5.2. ANÁLISIS Y DISEÑO
A) DIAGRAMAS DE COLABORACIÓN
Diagrama 1: DC: Mantenimiento de Usuarios.
2: Buscar Persona 3: Leer
4: ObjPersona
: Buscador de Personal : Personal
: Registrador Usuario
5: Registrar Usuario
6: Crear
1: Manteniendo Usuario 7: Actualizar Usuario 8: Actualizar
: Jefe de : Mantenedor de Usuarios : Actualizador Usuario : Usuario.

Informatica
9: Eliminar Usuario
10: Eliminar
: Eliminador Usuario
86
Diagrama 2: DC: Mantenimiento Tipo Documento
2: Verificar Tipo Documento 3: Leer
4: ObjTipoDocumento
: Buscador Tipo Documento
5: Registrar Tipo Documento 6: Crear
1: Manteniendo Tipo Documento

: Registrador Tipo Documento
: Jefe de : Mantenedor Tipo Documento : Tipo Documento

Informatica
7: Actualizar Tipo Documento 8: Actualizar
: Actualizador Tipo Documento
9: Eliminar Tipo Documento 10: Eliminar
: Eliminador Tipo Documento
Diagrama 3: DC: Mantenimiento de Acción.
2: Verificar Accion 3: Leer
4: ObjAccion
: Buscador de Accion
5: Registrar Accion 6: Crear
: Registrador de Accion
1: Manteniendo Accion
: Jefe de : Mantenedor de Accion

Informatica 7: Actualizar Accion 8: Actualizar : Accion
: Actualizador de Accion
9: Eliminar Accion 10: Eliminar
: Eliminador de Accion
87
Diagrama 4: DC: Registrar Tramite Interno
2: Buscar Destino 3: Leer
4: VecArea
: Buscador de Destino : Area
5: Buscar Tipo Documento 6: Leer
7: VecTipoDoc
: Buscador Tipo Documento : Tipo Documento
1: Registrando tramite interno
: Usuarios : Registrador de Trámite
8: Buscar Accion 9: Leer
10: VecAccion
: Buscador de Accion : Accion
11: Crear tramite 12: Crear
: Registrador de Documento : Tramite
88
Diagrama 5: DC: Registrar Tramite Externo
2: Buscar Origen 3: Leer
4: VecArea
: Buscador de Origen
5: Buscar Destino 6: Leer
7: VecArea
: Buscador de Destino : Area
1: Registrando tramite externo 8: Buscar Tipo Documento 9: Leer
10: VecTipDoc
: Usuarios : Registrador de Trámite : Buscador Tipo Documento : Tipo Documento
13: VecAccion
14: Registrar Documento 15: Crear
: Registrador de Documento : Tramite
89
Diagrama 6: DC: Recepcionar Documento
2: Buscar Documento 3: Leer
4: VecTramite
: Buscador de Documento
5: Buscar Area 6: Leer

: Tramite
7: ObjArea
: Buscador de Area : Area.
1: Recepcionando documento 8: Buscar Tipo Documento 9: Leer
10: ObjTipDoc
: Usuarios : Recepcionador de Documento : Buscador Tipo Documento : Tipo Documento
13: ObjAccion
14: Recepcionar 15: Actualizar
: Recepcionar Docuemento
90
Diagrama 7: DC: Despachar Documento
4: VecTramite
5: Buscar Area 6: Leer

: Tramite
7: ObjArea
: Buscador de Area : Area
1: Despachando Documento 8: Buscar Tipo Documento 9: Leer
10: ObjTipDoc
: Usuarios : Despachador de Documento : Buscador Tipo Documento : Tipo Documento
13: ObjAccion
14: Despachar 15: Actualizar
: Despachar Documento
91
Diagrama 8: DC: Archivar Documento.
4: VecTramite
5: Buscar Area 6: Leer : Tramite
7: ObjArea
: Buscador de Area : Area
1: Archivador de Documento 8: Buscar Tipo Documento 9: Leer
10: ObjTipDoc
: Usuarios : Archivador de Documento : Buscador Tipo Documento : Tipo Documento
13: ObjAccion
14: Despachar 15: Actualizar
: Archivar Documento
92
Diagrama 9: DC: Reporte de Documentos según estado (Emitidos, Recepcionados, Despachados,
Archivados).
12: Ingresa datos
14: Enlaza
frmNuevoCliente : Boundary frmNuevoCliente.cs :

Control
15: CrearCliente
13: clic en guardar
11: redirect
17: redirect 24: Modifica()
16: crear()
10: Clic en nuevo 7: Enlaza 9: Eliminar()
6: Clic en eliminar 8: Eliminar(cod)
1: clic en buscar 2: enlaza 3: BuscarCliente 4: leer()
18: clic en modificar

5: ObjCliente
: Empleado. frmCliente : Boundary frmCliente.cs : Control Cliente : Entidad tCliente : Tabla
21: clic en guardar

19: redirect
25: redirect
20: Modifica dato
23: ModificarCliente
22: Enlaza
frmModificarCliente : Boundary frmModificarCliente.cs :

Control
93
B) DIAGRAMA DE CLASES
Diagrama 10: Diagrama de Clases
94
C) INTERFAZ Y SECUENCIA
Gráfico 7: INTERFAZ DE MANTENIMIENTO DE ACCIÓN
Gráfico 8: INTERFAZ DE REGISTAR ACCIÓN
95
Diagrama 11: Mantenimiento de Acción-Registrar
cAccion :
: CP RegAccion : T ACCION
: CP manAccion : SP manAccion : SP sAccion cAccion
: Jefe de Informatica, : CP menu : FRM manAccion : FRM RegAccion
1: Click Mantener Accion
2: Link
3: Buscar Acciones
4: Buscar
5: VecAccion
6: ListaAccion
7: Construir
8: Mostrar
9: Click Boton Nuevo
10: Enviar
11: Mostrar
12: Ingresa Datos
13: ...
14: Click en Boton Grabar
15: Enviar
16: Generar Codigo
17: Crear
18: Crear
96
Diagrama 12: Mantenimiento de Acción-Modificar
cAccion :
: SP RegAccion : T ACCION
: CP manAccion : CP RegAccion : SP manAccion : SP sAccion cAccion
: Jefe de Informatica, : CP menu : FRM manAccion : FRM RegAccion
2: Link
3: Buscar Acciones
4: Buscar
5: VecAccion
6: ListaAccion
7: Construir
8: Mostrar
9: Click en modificar
10: Link
11: BuscaridAccion
12: Buscar
13; ObjAccion
14: ObjAccion
15: Construir
16: Mostrar
17: Modifica Datos
18: ...
19: Click en Boton Guardar
20: Enviar
21: Modificar
22: Actualiza
97
Diagrama 13: Mantenimiento de Acción-Eliminar
cAccion :
: CP menu : CP manAccion : CP RegAccion : SP manAccion : SP sAccion cAccion : T ACCION
: Jefe de Informatica,
2: Link
3: Buscar Acciones
4: Buscar
5: VecAccion
6: Lis taAccion
7: Construir
8: Mos trar
9: Click en Elim inar
10: Ms j. de confirmacion
11: Mostrar
12: Click en Aceptar
13: Enviar
14: Elim inar()
Eliminar
98
Gráfico 9: INTERFAZ DE MANTENIMIENTO DE TIPO DOCUMENTO
Gráfico 10: INTERFAZ DE REGISTRAR TIPO DOCUMENTO
99
Diagrama 14: Mantenimiento de Tipo Documento Registrar
:
: Jefe de Informatica, : CP menu : CP manTipoDoc : CP RegTipoDoc : FRM manTipoDoc : FRM RegTipDoc : SP manTipDoc : SP : T TIPODOCUMENTO
cTipoDocum ento
sTipoDocumento
1: Click Mantener Tipo Docum ento
2: Link
3: BuscarTipoDocum entos()
4: Buscar
5: VecTipDoc
6: ListaTipDoc
7: Construir
8: Mostrar
9: Click en Boton Nuevo
10: Link
11: Mostrar
12: Ingresa Datos
13: ...
15: Enviar
16: GenerarCodigo()
17: Crear()
18: Crea
100
Diagrama 15: Mantenimiento de Tipo Documento-Modificar
: cUs uario : cArea : cPers onal

: Jefe de Informatica, : CP menu : CP manUs uario : CP RegUs uario : FRM manUs uario : FRM RegUs uario : SP RegUsuario : SP manUs uario : SP sUsuario : T USUARIO : T Pers onal : T Area
1: ClickMantener Us uario
2: Link
3: BuscarUs uario()
4: Buscar
5: VecUs uarios
6: Buscar idPersona
7: Buscar
8: ObjPers ona
9: Lis ta Usuarios
10: Construir
11: Mostrar
12: Click en Modificar
13: Enviar
14: Buscar idUs uario
15: Buscar
16: ObjUs uario
17: Buscar idPers ona
18: Buscar
19: ObjPers ona
20: Buscar idArea
21: Buscar
22: ObjArea
23: Construir
24: Mostrar
25: Modifica Datos
26: ...
28: Enviar
29: Modificar
30: Actualiza
101
Diagrama 16: Mantenimiento de Tipo Documento Eliminar
: TIPO
: Jefe de Informatica, : CP menu : CP manTipoDoc : CP RegTipoDoc : SP manTipDoc : SP : T TIPODOCUMENTO
DOCUMENTO
s TipoDocumento
1: Click Mantener Tipo Docum ento
2: Link
3: Buscar TipoDocumentos ()
4: Buscar
5: VecTipDoc
6: Lis ta TipDoc
7: Construir
8: Mos trar
10: Ms j, de Confirmacion
11: Mostrar
13: Enviar
14: Elim inar
15: Elim ina
102
Gráfico 11: INTERFAZ DE MANTENIMIENTO DE USUARIO
Gráfico 12: INTERFAZ DE REGISTRAR USUARIO
103
Diagrama 17: Mantenimiento de Usuario-Registrar
: cUs uario, : cArea : cPers onal

: Jefe de Informatica, : CP menu : CP manUs uario : CP RegUs uario : FRM manUs uario : FRM RegUs uario : s AjaxPers ona : SP RegUsuario : SP manUs uario : SP sUsuario : T USUARIO : T Pers onal : T Area
1: Click Mantener Us uario
2: Link
3: Buscar Us uarios ()
4: Buscar
5: VecUs uarios
6: Buscar idPersona
7: Buscar
8: ObjPers ona
9: Lis ta Usuarios
10: Cons truir
11: Mostrar
12: Click en Boton Nuevo
13: Enviar
14: Bus car Areas ()
15: Bus car
16: VecAreas
17: Lis ta Areas
18: Cons truir
19: Mostrar
20: Ingres a Codigo de Pers ona
21: ...
22: Click en Boton Bus car Codigo
23. Enviar
24: Bus car idPers ona
25: Bus car
26: ObjPers ona
27: ObjPers ona
28: Llenar Dato
29: Mostrar
30: Ingres a Datos
31: ...
32: Click en Guardar
33: Enviar
34: Crear
35: Crea
104
Diagrama 18: Mantenimiento de Usuario-Modificar
: cUsuario : cArea : cPersonal

: Jefe de Informatica, : CP menu : CP manUsuario : CP RegUsuario : FRM manUsuario : FRM RegUsuario : sAjaxPersona : SP RegUsuario : SP manUsuario : SP sUsuario : T USUARIO : T Personal : T Area
1: Click Mantener Usuario
2: Link
3: BuscarUsuario()
4: Buscar
5: VecUsuarios
6: BuscaridPersona
7: Buscar
8: ObjPersona
9: ListaUsuarios
10: Construir
11: Mostrar
12: Click en m odificar
13: Enviar
14: BuscaridUsuario
15: Buscar
16: ObjUsuario
17: BuscaridPersona
18: Buscar
19: ObjPersona
20: BuscaridArea
21: Buscar
22: ObjArea
23: Construir
24: Mostrar
25: Modifica Datos
26: ...
28: Enviar
29: Modificar
30: Actualiza
105
Diagrama 19: Mantenimiento de Usuario-Eliminar
: cUs uario : cPers onal

: Jefe de Informatica, : CP menu : CP manUs uario : SP manUs uario : SP sUsuario : T USUARIO : T Pers onal
1: Click Mantener Us uario
2: Link
3: BuscarUs uario()
4: Buscar
5: VecUs uarios
6: BuscaridPers ona
7: Buscar
8: ObjPers ona
9: Lis taUs uarios
10: Cons truir
11: Mostrar
13: Ms j. de Confirmacion
14: Mostrar
16: Enviar
17: Elim inar()
18: Elim inar
106
Gráfico 13: INTERFAZ DE REGISTRAR TRÁMITE
Gráfico 14: INTERFAZ DE HOJA DE TRÁMITE
107
Diagrama 20: Registrar Tramite
: cTipoDocumento : cAccion : cArea : cTramite : cDetalleTramite : cTemporal : cCopia

: Usuario, : CP menu : CP RegTramite : CP ListaCopia : CP hojaTramite : FRM RegTramite : sAjaxCompletaArea : SP RegTramite : SP hojaTramite : SP sTramite : SP sListaCopia : SP ListaCopia : T ACCION : T TIPODOCUMENTO : T Area : T TEMPORAL : T COPIA : T TRAMITE : T DETALLETRAMITE
1: Click en Registrar Tramite Interno
2: Link
3: BuscarTipoDocumentos
4: Buscar
5: VecTipDoc
6: BuscarAcciones()
7: Buscar
8: VecAccion
9: ListaAccion
10: ListaTipDoc
11: Construir
12: Mostrar
13: Busca Area de Destino
14: Enviar
15: BuscarNombreArea()
16: Buscar
17: VecAreas
18: ListaAreas
19: Construir
20: Mostrar
21: Ingresa Datos
22: ...
23: Busca Area Destino con Copia
24: Paso14-19
25: Click en agregar
26: Enviar
27: Crear()
28: Crear
29: VecCopia
30: Construir
31: Include
31: Mostrar
34: Enviar
35: Crear()
36: Crea
37: Crear()
38: Crea
39: BuscarLista()
40: Buscar
41: VecTemCopia
42: Crear()
43: Crea
44: EminaTemp
45: Elimina
108
Gráfico 15: INTERFAZ DE RECEPCIONAR DOCUMENTO SIN REGISTROS
Gráfico 16: INTERFAZ DE RECEPCIONAR DOCUMENTO RECEPCIONAR
109
Diagrama 21: Recepcionar Documento
: cDetalleTram ite : cArea : cTipoDocum ento : cCopia

: Us uario, : CP m enu : CP m anRecepcionar
: FRM m anRecepcionar : SP : SP sRecepcionar : T DETALLETRAMITE : T Area : T TIPODOCUMENTO : T COPIA
m anRecepcionar
1: Click en Recepcionar Docum ento
2: Link
3: Mos trar
4: Ingres a Codigo de Tram ite
5: Click en Bus car
6: Enviar
7: BuscaridTram iteAreaDes tino
8: Buscar
9: ObjDetTram ite
10: Bus caridDocum ento
11: Bus car
13: BucaridArea()
12: ObjTipDoc
14: Bus car
15: ObjAreaOrigen
16: Bus caridTram iteAreaDes tino
17: Bus car
18: ObjCopia
19: Bus caridDocum ento()
20: Bus car
21: ObjTipDoc
22: Bus caridArea()
23: Bus car
24: ObjAreaOrigen
25: Lis taCodigo
26: Lis taOrigen
27: Lis taAs unto
28: Lis taTipoDoc
29: Cons truir
30: Mostrar
31: Click en Recepcionar
32: Mens aje de Confirm acion
33: Mostrar
35: Enviar
36: ActualizaridDeTram iteEs tado()
37: Actualiza
38: ActualizaridCopiaEstado
39: Actualiza
110
Gráfico 17: INTERFAZ DE DESPACHAR DOCUMENTO SIN REGISTROS
Gráfico 18: INTERFAZ DE DESPACHAR DOCUMENTO 1.
111
112
Diagrama 22: Recepcionar Documento
: cDetalleTramite : cArea : cTipoDocumento : cAccion

: Us uario, : CP menu : CP manDes pachar : CP frmDes pachar : FRM manDes pachar : FRM frmDes pachar : SP manDes pachar : SP frm Des pachar : SP sDes pachar
: T DETALLETRAMITE : T Area : T TIPODOCUMENTO : T ACCION
1: Click en Despachar Docum ento
2: Link
3: Mos trar
4: Ingres a Codigo de Tram ite
5: Click en Bus car
6: Enviar
7: BuscaridTramiteAreaDes tino()
8: Buscar
9: ObjDeTram it
10: Bus caridDocum ento()
11: Bus car
12: ObjTipDoc
13: Bus caridArea()
14: Bus car
15: ObjArea
16: Lis taCodigo
17: Lis taOrigen
18: Lis taAs unto
19: Lis taTipoDoc
20: Cons truir
21: Mostrar
22: Click en Des pachar
23: Enviar
24: Bus carTipoDocum ento()
25: Bus car
26: VecTipDoc
27: Bus carAcciones ()
28: Bus car
29: VecAccion
30: Lis taAccion
31: Lis taTipDoc
32: Cons truir
33: Mostrar
34: Ingres a Datos
35: ...
36: Click en Enviar
37: Enviar
38: Crear()
39: Crea
40: Actualizar()
41: Actualiza
113
Gráfico 21: INTERFAZ DE ARCHIVAR DOCUMENTO.
114
Diagrama 23: Archivar Documento
: cDetalleTram ite : cArea : cTipoDocumento : cTram ite

: Us uario, : CP menu 5: Click en Guardar : CP : FRM manDes pachar : SP manDes pachar : SP sDes pachar : T DETALLETRAMITE : T Area : T TIPODOCUMENTO : T TRAMITE
manDes pachar
1: Click en Des pachar Docum ento
2: Link
3: Mos trar
4: Ingres a Codigo de tramite
5: Click en Guardar
6: Enviar
7: BuscaridAreaTram iteDes tino()
8: Buscar
9: ObjDetTramite
10: BucaridDocumento
11: Bus car
12: ObjTipDoc
13: Bus caridArea
14: Bus car
15: ObjArea
16: Lis taCodigo
17: Lis taOrigen
18: Lis taAs unto
19: Lis taTipoDoc
20: Cons truir
21: Mostrar
22: Click en Archivar
23: Mens aje de Confirm acion
24: Mostrar
26: Enviar
27: AcualizarEs tado()
28: Actualiza
29: ActualizaridDeTramiteEs tado() 30: Actualiza
115
Gráfico 22: INTERFAZ DE REPORTE DE DOCUMENTOS EMITIDOS.
Gráfico 23: INTERFAZ DE REPORTE DE DOCUMENTOS RECEPCIONADOS.
116
Gráfico 24: INTERFAZ DE REPORTE DE DOCUMENTOS DESPACHADOS.
117
Diagrama 24: Reporte de Documentos Emitidos
: cArea : cTram ite : cDetalleTramite

: Usuario, : CP menu : CP repDocEmi : FRM repDocEmi : Sp repDocEm i : SP sConsulta : T Area : T TRAMITE : T DETALLETRAMITE
1: Click en reportes de docum entos Emitidos
2: Link
3: Mostrar
4: Ingresa Fecha
5: Tiempo
6: Buscar
7: Enviar
8: BuscarEmitidos(idAreaSesion,FechaI,FechaF)
9: Buscar
10: VecTram ite
11: BuscaridDetalle()
12: Buscar
13: ObjDet
14: BuscaridArea()
15: Buscar
16: ObjArea
17: ListaEmitidos
18: Construir
19: Mostrar
20: Click en link Imprimir
118
Gráfico 25: INTERFAZ DE CONSULTAR TRÁMITE.
119
Diagrama 25: Consultar Tramite
: cTramite : cDetalleTramite : cArea : cTipoDocumento : cAccion

: Publico : CP PortalUnia : CP ConTramite : FRM ConTramite : SP ConTramite : T TRAMITE : T DETALLETRAMITE : T Area : T TIPODOCUMENTO : T ACCION
1: Click en Consultar Tramite
2: Link
3: Mostrar
4: Ingresa Codigo de Tramite
5: Tiempo
6: Click en Buscar
7: Enviar
8: BuscaridTramite(idTramite)
9: Buscar
10: ObjTramite
11: BuscarDetalleidTramite(idTramite)
12: Buscar
13: VecTramite
14: BuscaridArea(idArea)
15: Buscar
16: ObjArea
17: BuscaridTipDoc(idTipDoc)
18: Buscar
19: ObjTipDoc
20: BuscaridAccion(idAccion)
21: Buscar
22: ObjAccion
23: Construir
24: Mostrar
120
D) DIAGRAMA DE COMPONENTES
Diagrama 26: Diagrama de Componentes
IndexIntranetUNIA.html
SYSTRAMITE
Servlets.jar
Socket_Servidor.jar
JSTL 1.1-
standard.jar
Gestio_Tramite.jar
Escalafon.jar
Admi_General
.jar JSTL 1.1-jstl.jar
commons-
lang-2.2.jar
AjaxTags.j
ar
Socket_Cliente.jar
IntranetUNIA.mdb
E) DISEÑO DE LA BASE DE DATOS
E.1) Diccionario de datos de tablas principales

Tabla 20: TIPODOCUMENTO
TABLA TIPODOCUMENTO
Sirve para el modelado de un tipo de documento, un
TIPODOCUMENTO pude estar en uno o muchos
DEFIN.: DETALLETRAMITE
DEFINICIONES DE COLUMNAS
NOMBRE TYPE LOG. DESCRIPCIÓN
Código de identificación de la tabla,
su valor se genera correlativamente
idTipDoc CHAR 2 01,02,…
Puede ir: SOLICITUD, OFICIO,
Nombre VARCHAR 35 MEMORÁNDUM, etc.
121
Tabla 21: Tabla Accion
TABLA ACCIÓN
Sirve para el modelado de una acción a tomar respecto
a un documento, una ACCIÓN pude estar en uno o
DEFIN.: muchos DETALLETRAMITE
idAccion CHAR 2 01,02,…
Nombre VARCHAR 35 Puede ir: TRAMITE, OPINIÓN, etc.
Tabla 22: Tabla DETALLETRAMITE
TABLA DETALLETRAMITE
DEFIN.: Sirve de complemento para la tabla TRAMITE
Código de identificación de la
tabla, su valor se genera
idDeTra CHAR 2 correlativamente 01,02,…
Es el área de procedencia del
idAreaOrigen CHAR 35 documento
Es el área de destino del
idAreaDestino CHAR documento
VAR Es el tema o descripción que se
Asunto CHAR basa el documento.
Es el número de documento
numdoc CHAR físico
Es la fecha de registro del
FecReg DATE documento
Es la hora de registro del
HorReg DATE documento
Es la fecha de despacho del
FecDesp DATE documento
Es la hora de despacho del
HorDesp DATE documento
numfolio VARCHAR Es el número de documento
Opcional descripción que se
observ VARCHAR agrega al documento
estado VARCHAR Es el estado del documento
122
Tabla 23: Tabla AREA
TABLA AREA
Sirve para representar las áreas que constituyen una
DEFIN.: oficina
idArea CHAR 2 01,02,…
Nombre VARCHAR 35 Nombre del area
Tabla 24: Tabla OFICINA
TABLA OFICINA
DEFIN.: Sirve para representar las oficinas de la universidad
idOficina CHAR 2 01,02,…
Nombre VARCHAR 35 Nombre del oficina.
Tabla 25: Tabla USUARIO
TABLA USUARIO
Sirve para indicar quienes tienes acceso al sistema pero
DEFIN.: según tipo de usuario para las respectivas restricciones
idPersona CHAR 6 es también un código correlativo
usu_clave VARCHAR 20 Clave del usuario
Hay 2 tipos A=Administrador y
U=Usuario, dependiendo de esto se
usu_tipo CHAR 1 mostrará un determinado menú
Nos indica de que área u oficina
idArea CHAR 5 pertenece
123
Tabla 26: Tabla TRAMITE
TABLA TRAMITE
Esta tabla es cabecera de un trámite que nos indica
quien lo ha registrado ( el área de registro), el tipo de
DEFIN.: tramite ( Interno o Externo)
compuesta por idArea + año + mes
idTramite CHAR 12 correlativo de 3 dígitos
Área de registro o área donde se
idAreaReg CHAR 5 origina el documento
Es la fecha en la que se emitió el

fecEmi DateTime tramite
Es la hora en la que se emitió el
horEmi VARCHAR 11 tramite
Es opcional en caso de que sea un
trámite externo, se ingresa el nombre
de la persona quien entrega el
documento o la empresa de donde
razon VARCHAR 50 proviene
Hay 2 tipo: T=Tramite, A=Archivado,
cuando se crea un documento por
estado CHAR 1 defecto está en trámite
Para indicar si es trámite es externo
tipo CHAR 1 o interno
124
E.2) Diagrama de base de datos
Diagrama 27: Diagrama de Base de Datos
125
F) SENTENCIAS LÓGICAS PRINCIPALES
CLASE cTrámite:
package clases;
import java.sql.*;
import java.util.*;
public class cTramite {
protected String idTramite;

protected String idArea;
protected String idDocumento;
protected String asunto;
protected String fecing;
protected String horing;
protected String nrodoc;
protected String observ;
protected String estado;
private static String error;
public cTramite() {
}
public cTramite(String idTramite, String idArea, String idDocumento, String asunto, String
fecing, String horing, String nrodoc, String observ, String estado) {
this.idTramite = idTramite;
this.idArea = idArea;
this.idDocumento = idDocumento;
this.asunto = asunto;
this.fecing = fecing;
this.horing = horing;
this.nrodoc = nrodoc;
this.observ = observ;
this.estado = estado;
}
public Vector BuscarNumDocumento(String vtipodoc, String vnumdoc, String vanio) {

Vector listadetramite = null;
error = null;
try {
DBManager dbm = new DBManager();
Connection con = dbm.getConnection();
CallableStatement st;
if (con == null) {
throw new NullPointerException(dbm.geterror());
}
if (vanio.equals("todos")) {
vanio = "2";
}
if (vtipodoc.equals("vacio")) {
st = con.prepareCall("{CALL spTramite_TNDT(?,?)}");
126
st.registerOutParameter(1, Types.VARCHAR);
st.setString(1, vnumdoc);
st.setString(2, vanio);
} else {
st = con.prepareCall("{CALL spTramite_TND(?,?,?)}");
st.registerOutParameter(1, Types.CHAR);
st.setString(1, vtipodoc);
st.setString(2, vnumdoc);
}
ResultSet rs = st.executeQuery();
listadetramite = new Vector();
while (rs.next()) {
listadetramite.add(new cTramite(rs.getString("idTramite"),
rs.getString("idArea"),
rs.getString("idDocumento"),
rs.getString("asunto"),
rs.getString("fecing"),
rs.getString("horing"),
rs.getString("nrodoc"),
rs.getString("observ"),
rs.getString("estado")));
}
rs.close();
st.close();
dbm.closeConnection(con);
return listadetramite;
} catch (Exception e) {
error = e.getMessage();
}
return null;
}
public Vector BuscarAsunto(String vtipodoc, String vasunto, String vanio) {

error = null;
try {
CallableStatement st;
if (con == null) {
}
if (vanio.equals("todos")) {
vanio = "2";
}
System.out.println("vanio=" + vanio);
if (vtipodoc.equals("vacio")) {
System.out.println("ejecutando TAST");
st = con.prepareCall("{CALL spTramite_TAST(?,?)}");
127
st.setString(1, vasunto);
} else {
st = con.prepareCall("{CALL spTramite_TAS(?,?,?)}");
st.setString(1, vtipodoc);
}
while (rs.next()) {
}
rs.close();
st.close();
System.out.println(error);
}
return null;
}
public String GenerarCodigo(String vidArea, String vfecha) {

int vcorre = 1;
String sql, vCeros = "";
String vfec = "";
try {
if (con == null) {
}
sql = "SELECT idTramite FROM tramite WHERE idArea=? "
+ "and YEAR(fecing)=? AND MONTH(fecing)=?"
+ " order by idTramite";
PreparedStatement st = con.prepareStatement(sql, 1005, 1007);
st.setString(1, vidArea);
st.setInt(2, 2000 + Integer.parseInt(vfecha.substring(0, 2)));
128
st.setInt(3, Integer.parseInt(vfecha.substring(2, 4)));
rs.afterLast();
if (rs.previous()) {
vcorre = Integer.parseInt(rs.getString("idTramite").substring(9));
vcorre++;
System.out.println("vCorre:" + vcorre);
}
for (int i = 1; i < 4 - String.valueOf(vcorre).length(); i++) {
vCeros = vCeros + "0";
}
rs.close();
st.close();
con.close();
e.getMessage();
System.out.println(e.getMessage());
}
return (vidArea + vfecha + vCeros + vcorre);
}
public boolean BuscarIdTramite(String vidTramite) {

boolean res = false;
try {
if (con == null) {
}
CallableStatement st = con.prepareCall("{CALL spTramite_TC(?)}");
st.setString(1, vidTramite);
if (rs.next()) {
this.idTramite = rs.getString("idTramite");
this.idArea = rs.getString("idArea");
this.idDocumento = rs.getString("idDocumento");
this.asunto = rs.getString("asunto");
this.fecing = rs.getString("fecing");
this.horing = rs.getString("horing");
this.nrodoc = rs.getString("nrodoc");
this.observ = rs.getString("observ");
this.estado = rs.getString("estado");
res = true;
}
rs.close();
st.close();
e.getMessage();
res = false;
}
129
return res;
}
public boolean BuscarIdTramiteEstado(String vidTramite, String vestado) {

try {
if (con == null) {
}
CallableStatement st = con.prepareCall("{CALL spTramite_TCE(?,?)}");
st.setString(2, vestado);
if (rs.next()) {
this.asunto = rs.getString("asunto");
this.fecing = rs.getString("fecing");
this.horing = rs.getString("horing");
this.nrodoc = rs.getString("nrodoc");
res = true;
}
rs.close();
st.close();
e.getMessage();
res = false;
}
return res;
}
public Vector BuscarIdArea(String vidArea) {

Vector areas = null;
error = null;
try {
if (con == null) {
}
CallableStatement st = con.prepareCall("{CALL spTramite_TA(?)}");

130
areas = new Vector();
while (rs.next()) {
areas.add(new cTramite(rs.getString("idTramite"),
}
rs.close();
st.close();
return areas;
}
return null;
}
public static Vector BuscarTramiteDocumento(String vidDocumento) {

Vector tramites = null;
error = null;
try {
if (con == null) {
}
CallableStatement st = con.prepareCall("{CALL spTramite_TC(?)}");

st.setString(1, vidDocumento);
tramites = new Vector();
while (rs.next()) {
tramites.add(new cTramite(rs.getString("idTramite"),
}
rs.close();
st.close();
131
return tramites;
}
return null;
}
public boolean Crear(String vidTramite, String vidArea, String vidDocumento, String vasunto,
String vfecing, String vhoring, String vnrodoc, String vobserv, String vestado) {
try {
error = null;
if (con == null) {
}
CallableStatement st = con.prepareCall("{CALL spTramite_A(?,?,?,?,?,?,?,?,?)}");
st.setString(5, vfecing);
st.setString(6, vhoring);
st.setString(7, vnrodoc);
st.setString(8, vobserv);
if (st.execute()) //devuelve verdadero si fallo
{
error = "No se puede registrar el tramite";
}
st.close();
con.close();
error = e.toString();
}
return (error == null);
}
public boolean ActualizarEstado(String vidTramite, String estado) {

try {
132
error = null;
if (con == null) {
}
CallableStatement st = con.prepareCall("{CALL spTramite_AE(?,?)}");
st.setString(2, estado);

{
error = "No se puede Actualizar el Tramite";
}
st.close();
con.close();
}
}
public Vector BuscarFechas(String vidArea, String vfecrecI, String vfecrecF) {

error = null;
try {
if (con == null) {
}
CallableStatement st = con.prepareCall("{CALL spTramite_TF(?,?,?)}");

st.setString(2, vfecrecI);
st.setString(3, vfecrecF);
while (rs.next()) {
133
}
rs.close();
st.close();
}
return null;
}
public String getIdTramite() {

return idTramite;
}
public String getIdArea() {

return idArea;
}
public String getIdDocumento() {

return idDocumento;
}
public String getAsunto() {

return asunto;
}
public String getFecing() {

return fecing;
}
public String getHoring() {

return horing;
}
public String getNrodoc() {

return nrodoc;
}
public String getObserv() {

return observ;
}
public String getEstado() {

return estado;
}
public void setIdTramite(String idTramite) {

}
134
public void setIdArea(String idArea) {
}
public void setIdDocumento(String idDocumento) {

}
public void setAsunto(String asunto) {

this.asunto = asunto;
}
public void setFecing(String fecing) {

this.fecing = fecing;
}
public void setHoring(String horing) {

this.horing = horing;
}
public void setNrodoc(String nrodoc) {

this.nrodoc = nrodoc;
}
public void setObserv(String observ) {

}
public void setEstado(String estado) {

}
}
135
CLASE cDeTramite
package clases;
import java.sql.*;
import java.util.*;
public class cDetramite {
protected String idTramite;

protected String idDetramite;
protected String idAreaEmi;
protected String idAreaDes;
protected String idAccion;
protected String fecrec;
protected String horrec;
protected String estado;
protected String docres;
protected String observ;
/** Creates a new instance of cDetramite */

public cDetramite() {
}
public cDetramite(String idTramite, String idDetramite, String idAreaEmi, String idAreaDes,

String idAccion, String fecrec, String horrec, String estado, String docres, String observ) {
this.idDetramite = idDetramite;
this.idAreaEmi = idAreaEmi;
this.idAreaDes = idAreaDes;
this.idAccion = idAccion;
this.fecrec = fecrec;
this.horrec = horrec;
this.docres = docres;
}
public String GenerarCodigo(String vidTramite) {

int vcorre = 1;
try {
if (con == null) {
}
sql = "SELECT idDetramite FROM detramite WHERE idTramite=? order by idTramite";
rs.afterLast();
136
vcorre = Integer.parseInt(rs.getString("idDetramite"));
vcorre++;
}
}
rs.close();
st.close();
con.close();
e.getMessage();
}
return (vCeros + vcorre);
}
public boolean Crear(String vidTramite, String vidDetramite, String vidAreaEmi, String

vidAreaDes, String vidAccion, String vfecrec, String vhorrec, String vestado, String vdocres,
String vobserv) {
try {
error = null;
if (con == null) {
}
CallableStatement st = con.prepareCall("{CALL spDetramite_A(?,?,?,?,?,?,?,?,?,?)}");
st.setString(2, vidDetramite);
st.setString(3, vidAreaEmi);
st.setString(4, vidAreaDes);
st.setString(5, vidAccion);
st.setString(6, vfecrec);
st.setString(7, vhorrec);
st.setString(9, vdocres);
st.setString(10, vobserv);
{
error = "No se puede registrar el tramite";
}
137
st.close();
con.close();
}
}
public static Vector BuscarDetalles(String vidDocumento) {

Vector tramites = null;
error = null;
try {
if (con == null) {
}
CallableStatement st = con.prepareCall("{CALL spDetramite_TD(?)}");

tramites = new Vector();
while (rs.next()) {
tramites.add(new cDetramite(rs.getString("idTramite"),
rs.getString("idDetramite"),
rs.getString("idAreaEmi"),
rs.getString("idAreaDes"),
rs.getString("idAccion"),
rs.getString("fecrec"),
rs.getString("horrec"),
rs.getString("estado"),
rs.getString("docres"),
rs.getString("observ")));
}
rs.close();
st.close();
return tramites;
}
return null;
}
public static Vector BuscarDetramiteAccion(String vidAccion) {

Vector detramites = null;
error = null;
try {
138
if (con == null) {
}
CallableStatement st = con.prepareCall("{CALL spDetramite_TCA(?)}");

st.setString(1, vidAccion);
detramites = new Vector();
while (rs.next()) {
detramites.add(new cDetramite(rs.getString("idTramite"),
}
rs.close();
st.close();
return detramites;
}
return null;
}
public boolean ActualizarIdTramite(String vidTramite, String vidDetramite, String vfecha,

String vhora) {
try {
error = null;
if (con == null) {
}
CallableStatement st = con.prepareCall("{CALL spDetramite_AE(?,?,?,?)}");
st.setString(3, vfecha);
st.setString(4, vhora);
139
{
error = "No se puede Actualizar el Tramite de Recepcion";
}
st.close();
con.close();
}
}
public Vector BuscarIdArea(String vidArea, String vestado) {

error = null;
try {
if (con == null) {
}
CallableStatement st = con.prepareCall("{CALL spDetramite_TA(?,?)}");

while (rs.next()) {
listadetramite.add(new cDetramite(rs.getString("idTramite"),
}
rs.close();
st.close();
}
return null;
}
140
public Vector BuscarIdAreaFecha(String vidArea, String vestado, String vFechaInicio, String
vfechaFin) {
error = null;
try {
if (con == null) {
}
CallableStatement st = con.prepareCall("{CALL spDetramite_TAF(?,?,?,?)}");

st.setString(3, vFechaInicio);
st.setString(4, vfechaFin);
while (rs.next()) {
}
rs.close();
st.close();
}
return null;
}
public Vector BuscarIdAreaTramite(String vidArea, String vestado, String vidtramite) {

error = null;
try {
if (con == null) {
141
}
CallableStatement st = con.prepareCall("{CALL spDetramite_TAI(?,?,?)}");
st.setString(3, vidtramite);
while (rs.next()) {
}
rs.close();
st.close();
}
return null;
}
public Vector BuscarIdAreaTramiteFecha(String vidArea, String vestado, String vidtramite,

String vFechaInicio, String vFechaFin) {
error = null;
try {
if (con == null) {
}
CallableStatement st = con.prepareCall("{CALL spDetramite_TAIF(?,?,?,?,?)}");
142
st.setString(3, vidtramite);
st.setString(4, vFechaInicio);
st.setString(5, vFechaFin);
while (rs.next()) {
}
rs.close();
st.close();
}
return null;
}
public Vector BuscarFechas(String vidArea, String vestado, String vfecrecI, String vfecrecF) {
error = null;
try {
if (con == null) {
}
CallableStatement st = con.prepareCall("{CALL spDetramite_TF(?,?,?,?)}");

st.setString(3, vfecrecI);
st.setString(4, vfecrecF);
while (rs.next()) {
143
}
rs.close();
st.close();
}
return null;
}
public boolean Despachar(String vidTramite, String vidDetramite, String estado) {

try {
error = null;
if (con == null) {
}
CallableStatement st = con.prepareCall("{CALL spDetramite_DD(?,?,?)}");
st.setString(3, estado);

{
error = "No se puede Actualizar el Tramite de Recepcion";
}
st.close();
con.close();
}
}
public boolean BuscarDetramite(String vidTramite, String vidDetramite) {

try {
144
if (con == null) {
}
CallableStatement st = con.prepareCall("{CALL spDetramite_TC(?,?)}");
if (rs.next()) {
this.idDetramite = rs.getString("idDetramite");
this.idAreaEmi = rs.getString("idAreaEmi");
this.idAreaDes = rs.getString("idAreaDes");
this.idAccion = rs.getString("idAccion");
this.fecrec = rs.getString("fecrec");
this.horrec = rs.getString("horrec");
this.docres = rs.getString("docres");
res = true;
}
rs.close();
st.close();
e.getMessage();
res = false;
}
return res;
}
public String getIdTramite() {

return idTramite;
}
public String getIdDetramite() {

return idDetramite;
}
public String getIdAreaEmi() {

return idAreaEmi;
}
public String getIdAreaDes() {

return idAreaDes;
}
public String getIdAccion() {

return idAccion;
}
145
public String getFecrec() {
return fecrec;
}
public String getHorrec() {

return horrec;
}
public String getEstado() {

return estado;
}
public String getDocres() {

return docres;
}
public String getObserv() {

return observ;
}
public void setIdTramite(String idTramite) {

}
public void setIdDetramite(String idArea) {

this.idDetramite = idDetramite;
}
public void setIdAreaEmi(String idAreaEmi) {

this.idAreaEmi = idAreaEmi;
}
public void setIdAreaDes(String idAreaDes) {

this.idAreaDes = idAreaDes;
}
public void setIdAccion(String idAccion) {

this.idAccion = idAccion;
}
public void setFecrec(String fecrec) {

this.fecrec = fecrec;
}
public void setHorrec(String horrec) {

this.horrec = horrec;
}
public void setEstado(String estado) {

}
public void setDocres(String docres) {
146
this.docres = docres;
}
public void setObserv(String observ) {

}
}
147
CLASE cDocumento
package clases;
import java.sql.*;
import java.util.*;
public class cDocumento {
protected String idDocumento;

protected String nombre;
public cDocumento() {
}
public cDocumento(String idDocumento, String nombre) {

this.nombre = nombre;
}
public String GenerarCodigo() {

int vcorre = 1;
try {
if (con == null) {
}
sql = "SELECT idDocumento FROM documento order by idDocumento";
rs.afterLast();
vcorre = Integer.parseInt(rs.getString("idDocumento"));
System.out.println(vcorre);
vcorre++;
}
}
rs.close();
st.close();
con.close();
e.getMessage();
}
}
public boolean BuscarIdDocumento(String vidDocumento) {

148
try {
if (con == null) {
}
CallableStatement st = con.prepareCall("{CALL spDocumento_TC(?)}");
if (rs.next()) {
this.nombre = rs.getString("nombre");
res = true;
}
rs.close();
st.close();
e.getMessage();
res = false;
}
return res;
}
public static Vector BuscarDocumentos() {

Vector documento = null;
error = null;
try {
if (con == null) {
}
CallableStatement st = con.prepareCall("{CALL spDocumento_TT}");

documento = new Vector();
while (rs.next()) {
documento.add(new cDocumento(rs.getString("idDocumento"),
rs.getString("nombre")));
}
rs.close();
st.close();
return documento;
}
return null;
}
149
public static Vector BuscarDocumentoNombre(String vnombre) { //Buscar por nombre de
documento
Vector listadoc = null;
error = null;
try {
if (con == null) {
}
CallableStatement st = con.prepareCall("{CALL spDocumento_TN('" + vnombre + "')}");

listadoc = new Vector();
while (rs.next()) {
listadoc.add(new cDocumento(rs.getString("idDocumento"),
rs.getString("nombre")));
}
rs.close();
st.close();
return listadoc;
}
return null;
}
public boolean Crear(String vidDocumento, String vnombre) {

try {
error = null;
if (con == null) {
}
CallableStatement st = con.prepareCall("{CALL spDocumento_A(?,?)}");
st.setString(2, vnombre);

{
error = "No se puede registrar el tipo de documento";
}
st.close();
con.close();
150
}
}
public boolean Modificar(String vidDocumento, String vnombre) {

try {
error = null;
if (con == null) {
}
CallableStatement st = con.prepareCall("{CALL spDocumento_M(?,?)}");

{
error = "No se puede modificar el tipo de documento";
}
st.close();
con.close();
}
}
public boolean Eliminar(String vidDocumento) {

try {
error = null;
if (con == null) {
}
CallableStatement st = con.prepareCall("{CALL spDocumento_E(?)}");
{
error = "No se puede eliminar el documento";
}
st.close();
con.close();
151
}
}
public String getIdDocumento() {

return idDocumento;
}
public String getNombre() {

return nombre;
}
public void setIdDocumento(String idDocumento) {

}
public void setNombre(String nombre) {

}
}
152
CLASE cpersona
* cOficina.java
package clases;
import java.sql.*;
import java.util.*;
/**
public class cPersona {
protected String idPersona;

protected String nombre;
protected String apepat;
protected String apemat;
protected String direccion;
protected String telef;
protected String sexo;
protected String fecnac;
protected String email;
protected String idlugnac;
protected String idArea;
/** Creates a new instance of cPersona */

public cPersona() {
}
public cPersona(String idPersona,

String nombre,
String apepat,
String apemat,
String direccion,
String telef,
String sexo,
String fecnac,
String email,
String idlugnac,
String idArea) {
this.idPersona = idPersona;
this.apepat = apepat;
this.apemat = apemat;
this.direccion = direccion;
this.telef = telef;
this.sexo = sexo;
this.fecnac = fecnac;
this.email = email;
this.idlugnac = idlugnac;
}
public Vector BuscarAreaPersona(String vIdarea) {
153
Vector areper = null;
error = null;
try {
if (con == null) {
}
CallableStatement st = con.prepareCall("{CALL spPersona_TA(?)}");

st.setString(1, vIdarea);
areper = new Vector();
while (rs.next()) {
areper.add(new cPersona(rs.getString("idpersona"),
rs.getString("nombre"),
rs.getString("apepat"),
rs.getString("apemat"),
rs.getString("direccion"),
rs.getString("telef"),
rs.getString("sexo"),
rs.getString("fecnac"),
rs.getString("email"),
rs.getString("idlugnac"),
rs.getString("idArea")));
}
rs.close();
st.close();
return areper;
}
return null;
}
public boolean BuscarIdPersona(String vidPersona) { //Buscar por codigo de Oficina

try {
if (con == null) {
}
CallableStatement st = con.prepareCall("{CALL spPersona_TC(?)}");
st.setString(1, vidPersona);
if (rs.next()) {
this.idPersona = rs.getString("idPersona");
this.nombre = rs.getString("nombre");
154
this.apepat = rs.getString("apepat");
this.apemat = rs.getString("apemat");
this.direccion = rs.getString("direccion");
this.telef = rs.getString("telef");
this.sexo = rs.getString("sexo");
this.fecnac = rs.getString("fecnac");
this.email = rs.getString("email");
this.idlugnac = rs.getString("idlugnac");
res = true;
}
rs.close();
st.close();
e.getMessage();
res = false;
}
return res;
}
public boolean Crear(String vidPersona,

String vnombre,
String vapepat,
String vapemat,
String vdireccion,
String vtelef,
String vsexo,
String vfecnac,
String vemail,
String vidlugnac,
String vidArea) {
try {
error = null;
if (con == null) {
}
CallableStatement st = con.prepareCall("{CALL spPersona_A(?,?,?,?,?,?,?,?,?,?,?)}");
155
st.setString(1, vidPersona);
st.setString(3, vapepat);
st.setString(4, vapemat);
st.setString(5, vdireccion);
st.setString(6, vtelef);
st.setString(7, vsexo);
st.setString(8, vfecnac);
st.setString(9, vemail);
st.setString(10, vidlugnac);

{
error = "No se puede registrar la Oficina";
}
st.close();
con.close();
}
}
public String GenerarCodigo() {

int vcorre = 1;
try {
System.out.println("Conectando");
if (con == null) {
}
sql = "SELECT idpersona FROM persona ORDER BY idpersona";
rs.afterLast();
vcorre = Integer.parseInt(rs.getString(1));
System.out.println(vcorre);
vcorre++;
}
}
rs.close();
st.close();
con.close();
156
e.getMessage();
}
}
// public boolean Modificar(String vidOficina, String vnombre) {

// try{
// error = null;
// DBManager dbm = new DBManager();
// Connection con = dbm.getConnection();
// if ( con == null )
// throw new NullPointerException( dbm.geterror() );
// CallableStatement st = con.prepareCall("{CALL spOficina_M(?,?)}");
// st.registerOutParameter(1,Types.CHAR);
// st.registerOutParameter(2,Types.VARCHAR);
//
// st.setString(1,vidOficina);
// st.setString(2,vnombre);
//
// if ( st.execute() ) //devuelve verdadero si fallo
// error = "No se puede modificar la Oficina";
// st.close();
// con.close();
// }catch(Exception e){error=e.toString(); System.out.println(e.getMessage());}
// return (error == null);
// }
// public boolean Eliminar(String vidOficina){
// try{
// error = null;
// DBManager dbm = new DBManager();
// Connection con = dbm.getConnection();
// if ( con == null )
// throw new NullPointerException( dbm.geterror() );
// CallableStatement st = con.prepareCall("{CALL spOficina_E(?)}");
// st.registerOutParameter(1,Types.CHAR);
// st.setString(1,vidOficina);
// if ( st.execute() ) //devuelve verdadero si fallo
// error = "No se puede eliminar la Oficina";
// st.close();
// con.close();
// dbm.closeConnection( con );
// }catch(Exception e){error=e.toString(); }
// return (error == null);
// }
//
public String getIdPersona() {
return idPersona;
}
public String getNombre() {

return nombre;
}
157
public String getApepat() {
return apepat;
}
public String getApemat() {

return apemat;
}
public String getDireccin() {

return direccion;
}
public String getTelef() {

return telef;
}
public String getSexo() {

return sexo;
}
public String getFecnac() {

return fecnac;
}
public String getEmail() {

return email;
}
public String getIdlugnac() {

return idlugnac;
}
public String getIdArea() {

return idArea;
}
public void setIdPersona(String idPersona) {

this.idPersona = idPersona;
}
public void setNombre(String nombre) {

}
public void setApepat(String apepat) {

this.apepat = apepat;
}
public void setApemat(String apemat) {

this.apemat = apemat;
}
158
public void setDireccion(String direccion) {
this.direccion = direccion;
}
public void setTelef(String telef) {

this.telef = telef;
}
public void setSexo(String sexo) {

this.sexo = sexo;
}
public void setFecnac(String fecnac) {

this.fecnac = fecnac;
}
public void setEmail(String email) {

this.email = email;
}
public void setIdlugnac(String idlugnac) {

this.idlugnac = idlugnac;
}
public void setIdArea(String idArea) {

}
}
159
CAPÍTULO VII
CONCLUSIONES Y RECOMENDACIONES
7.1. CONCLUSIONES
1. Se logró Identificar los procesos administrativos de trámite documentario
en la Universidad Nacional Intercultural de la Amazonia.
2. Se aplicó la metodología RUP de acuerdo a sus fases de desarrollo de
software y UML para el análisis y diseño con sus respectivos diagramas
de ayuda en la Universidad Nacional Intercultural de la Amazonia.
3. Se utilizó para el modelamiento del Sistema WEB UML,
resultandomuyprácticoyeficaz, para lograr concluir el análisis ydiseño del
sistema WEB con tecnología J2EE en la Universidad Nacional
Intercultural de la Amazonia.
4. Se realizó el documento de requisito para el desarrollo del análisis y
diseño de un sistema web con tecnología .JSP, además de Framework
JQuery para los procesos tramite documentario y validaciones de la
misma en la Universidad Nacional Intercultural de la Amazonia..
160
7.2. RECOMENDACIONES
1. Se recomienda al jefe de informática de la Universidad Nacional
Intercultural de la Amazonía trabajar con diseño WEB para los
modelados de sistemas, que es recomendable para sistemas con
arquitectura Cliente/Servidor.
Intercultural de la Amazoníadocumentar software mediante la
metodología RUP para desarrollar software de gran envergadura, ya que
las iteraciones engloban muchos procesos que en otras metodologías
agiles son analizadas específicamente.
Intercultural de la Amazonía implantar sistemas que faciliten los
procesos de las empresas, para así estar al alcance de las empresas
que encabezan los mercados nacionales e internacionales.
4. Se recomienda a los desarrolladores conocer bien un lenguaje de
programación para lograr un análisis, diseño y modelado correcto de los
sistemas a crear.
Intercultural de la Amazoníaobtener un servidor adecuado para asegurar
la base de datos de los sistemas a implantar.
6. Se recomiendo al jefe de informática de la Universidad Nacional
Intercultural de la Amazoníarealizar las pruebas necesarias en lo que
respecta al entorno de trabajo para que este tipo de sistemas funcionen
en su totalidad.
161
BIBLIOGRAFÍA
Alarcon Herrera, E., & Crovetto Huerta, C. (2006). Modelamiento de Base
de Datos con ERWIN. Lima: Megabyte.
Arahal, M. R., Berenguel Soria, M., & Rodriguez Diaz, F. (2006). Técnicas
de predicción con Aplicaciones en Ingeniería. Sevilla: Universidad de
Sevilla 2006.
Duque Ramirez, L. G., & Rubio Vanegas, H. (2006). Semiología médica
integral. Colombia: Universidad de Antioquia.
Fernandez Alarcon, V. (2006). Desarrollo de Sistemas de Información.
Barcelona: Edicions UPC, 2006.
Fortaleza Soler, K., & Lopez de Viñaspre, P. (2004). El entrenador
personal. Madrid: HISPANO EUROPEA.
Gabillaud, J. (2008). SQL Server 2008 SQL Transact SQL. Barcelona:
ENI.
Hobbs, L. (2007). Diseñar su propia pagina WEB. Barcelona:
MARCOMBO.
Jamrichoja Parsons, J. (2008). Conceptos de computación: nuevas
perspectivas. Mexico: Cengage Learning.
Kendall, K. E., Kendall, J. E., & Nuñes Ramos, A. (2006). Análisis y Diséño
de sistemas. Mexico: Pearson.
Kenneth C., L. (2006). Lenguajes de programación: Principios y Prácticas.
Mexico: Cengage Learning.
Krajewski, L. J., & Ritzman, L. P. (2005). Administración de operaciones:
estrategia y análisis. Mexico: Adam Hamel.
Laundon, K. C., & Laundon, J. P. (2004). Sistemas de Información
Gerencial. Mexico: Person Educación.
162
Liberty, J., & Xie, D. (2008). Programing C# 3.0. United States of America:
RepKover.
Liza Avila, C. (2007). Modelando con UML. Lima: SJ S.R. Ltda.
Llanos Feraris, D. R. (2006). Fundamentos de informática y programación
en C. Mexico: Adam Hamet.
Orozco Guzman, M. A., Chavez a la Torre, M. d., & Chavez a la Torre, J.
(2007). Informatica I. Mexico D.F.: THOMSON.
Sabana Mendoza, M. (2006). Modelamiento e Implementacion de BASE
DE DATOS. Lima: Megabyte.
Sommerville, I. (2007). Ingeniería de Software. Madrid: Pearson
Educacion S.A.
Weitzenfeld, A. (2005). Ingeniería de software orientada a objetos con
UML, Java e Internet. Cengage Learning
163
ANEXOS
164
ANEXO 01: GASTO EN MATERIALES
Tabla 27: MATERIAL PARA EL DESARROLLO DEL SISTEMA
Descripción Cantidad Precio Unit. Subtotal(S/.)
Millar de Papel 1 24.00 24.00
Útiles de oficina 1 20.00 20.00
Otros improvistos 1 100.00 100.00
Total Materiales (S/.) 144.00

Fuente: RUP
Tabla 28: SERVICIOS
Descripción Subtotal (S/.)
Transporte 450.00
Total Servicios (S/.) 450.00

Fuente: RUP
Diario en Transporte S/. 6.00, por 25 días calendarios, durante 3 meses, entonces en
transporte por el tiempo del proyecto es =6*(25*3)=450
Total Gasto en Materiales: S/. 594.00
165
ANEXO 02: CÁLCULO DE ESFUERZO Y COSTO PARA EL PRESUPUESTO
DEL PROYECTO Y DIAGRAMAS DE DURACIÓN PARA EL MISMO
1. Peso de los actores
Primero empezamos considerando los actores de nuestro sistema y determinamos

para cada Actor si estos son simples, promedio o complejos; para esto nos guiarnos
de la siguiente tabla:
Tabla 29: PESOS DE ACTORES
Tipo de Actor Descripción Factor
Simple Interfaz del programa 1

(API)
Promedio Interactivo o manejador 2

de interfaz con protocolo
Complejo Interfaz gráfica 3

Fuente: RUP
166
Asignamos a cada actor su tipo:
 Secretaria - Simple
 Jefe de Informática - Simple
 Público en general - Simple
 Directores de Oficina - Simple
Por tanto:
4 Simple * 1= 4
0 Promedio * 2 =0
0 Complejo * 3 = 0
Total de peso de actores = 4 + 0 + 0 = 4
2. Peso de los Use Case
Ahora hacemos algo similar para la lista de Use Case; con la diferencia
que esto basado en el Número de transacciones que realiza cada
Use Case. Determinando si estos son simples, Promedios o
complejos.
Tabla 30: PESOS DE USE CASE
Tipo de Use Case Descripción Factor

Simple 3 o menos 5
Transacciones
Promedio 4 a 7 Transacciones 10
Complejo Más de 7 15
Transacciones
Fuente: RUP
167
Asignamos a cada use case su tipo:
Tabla 31: ASIGNACION DEPESOS DE USE CASE
1 Registrar Tramite Interno. Simple

2 Registrar Tramite Externo Simple
3 Despachar Documento Promedio
4 Recepcionar Documento Promedio
5 Buscar Área Simple
6 Buscar Tramite Promedio
7 Consultar estado de trámite del documento Promedio
8 Registrar Acción Simple
9 Registrar tipo Documento Simple
10 Reporte de Documentos Recepcionados Promedio
11 Reporte de Documentos Emitidos Promedio
12 Reporte de Documentos Despachados Promedio
13 Mantenimiento de Tramite Promedio
14 Mantener Usuario Simple
Fuente: Elaboración Propia
Entonces:
6 simples * 5 = 30
8 promedio * 10 = 80
0 complejo * 15 = 0
Total de peso de Use Case = 30 + 80 + 0 = 110
3. Calculando UUCP
Para encontrar el Ajuste de Puntos para el Use Case (UUCP); el cual
refleja la complejidad del proyecto y la experiencia de las personas en
el proyecto, para estos utilizamos los pesos de los actores y de los use
case: 4 + 110 =114 UUCP
168
4. Calculando el TCF
Ahora necesitamos calcular la complejidad técnica para este

proyecto, a esto se le llama Factor Técnico de Complejidad (TFC).
Para calcular el TFC lo hacemos a través de la siguiente tabla, que
llenamos con factores de O a 5 un puntaje de O significa que el factor
es irrelevante, -un puntaje de 5 significa que el factor es significante
para este proyecto:
Tabla 32: FACTOR TECNICO DE COMPLEJIDAD
NUMERO DESCRIPCION DE FACTOR PESO DE VALOR VALOR

DE FACTOR ASIGNADO TOTAL
FACTOR
T1 Sistema Distribuido 2 3 6
T2 Respuesta o rendimiento de los 1 4 4

objetivos cumplidos
T3 Eficiencia de los usuarios finales (en 1 4 4

línea)
T4 Procesamiento interno complejo 1 3 3
T5 Código debe ser reusable 1 3 3
T6 Fácil de instalar 0.5 3 1.5
T7 Fácil de usar 0.5 3 1.5
T8 Portable 2 3 6
T9 Fácil de cambiar 1 4 4
T10 Concurrente 1 2 2
T11 Incluye característica especiales de 1 3 3

seguridad
T12 Provee acceso directo a terceros 1 3 3
T13 Capacitación especial 1 3 3
TOTAL 44
169
TFactor = Sumatoria (Peso del Factor) * (TValores Asignados) TFactor = 44
TFC = 0.6 + (0.01 *Factor)
TFC = 0.6 + (0.01 * 44) = 1.04
5. Calculando el EF
En este punto calcularemos el nivel de experiencia de las personas

del proyecto, a esto se Llama el Factor Environment. Para calcular
esto lo hacemos a través de la siguiente tabla; Teniendo en
consideración los siguientes puntos:
 De F1 a F4; 0 es no experiencia, 3 es más o menos y 5 es experto.

 F5; 0 no motivado, 3 más o menos y 5muy motivado.
 F6; 0 requerimientos inestables, 3 más o menos y 5
requerimientos estables.
 F7;'0 no hay staff de medio tiempo, 3 más o menos y 5 todos
trabajan medio tiempo.
 F8; 0 fácil uso de la programación, 3 más o menos y 5
mucha dificultad para la programación.
170
Tabla 33: FACTOR ENVIROMENT
NUMERO DESCRIPCION DE PESO DE VALOR VALOR

DE FACTOR FACTOR FACTOR ASIGNADO TOTAL
F1 Manejo de proceso 1.5 4 6

unificados
F2 Experiencia en 0.5 4 2
aplicaciones
F3 Experiencia en 1 5 5
orientación a objetos
F4 Capacidad d análisis 0.5 4 2

y liderazgo
F5 Motivación 1 5 5
F6 Requerimientos 2 5 10
estables
F7 Trabajadores a medio -1 5 -5
tiempo
F8 Dificultad en el -1 1 -1
lenguaje de
programación
TOTAL 24
Fuente: RUP
EFactor = Sumatoria (Valor Asignado * Peso del Factor) EFactor = 24

EF =1.4 + (-0.03 * EFactor)
EF =0.35 + (-0.03*24)= 0.68
6. Calculando el UCP
Finalmente para calcular los puntos

de Use Case; UCP = UUCP * TCF
* EF
UCP =114 * 1.04* 0.68 = 80.6208
171
7. Para elegir el factor hombre / horas
Para esto examinamos los datos en los EF y contamos del F1 a F6 los

factores que son menores a tres y contamos de F7 a F8 son a partir
de tres. Si el total es 2 o menos utilizamos 20 hombres/horas por
UCP, si son mayores a tres usamos 28 hombres/horas por UCP. En
nuestro caso utilizaremos 20 hombres/horas, por lo que multiplicaremos; 20
hombres/horas *80.6208 UCP = 1612.42, que nosotros consideramos que
es el esfuerzo que vamos a necesitar para el proyecto.
Con esto también podemos calcular el tiempo aproximado que

necesitaremos para el Proyecto en lo que corresponde a la documentación;
considerando que la semana tiene 48 horas (6 días *8) entonces:
1612.42 / 48 = 33.59 Semanas, entre 1 persona que desarrollará este
trabajo de investigación el tiempo calculado es en 33.59 semanas que en
meses es 8 meses pero en la realidad estaremos condicionado a 3 meses.
El costo del Proyecto se calculó; en base a un sueldo mensual para los
integrantes del Equipo (650 c/u) que multiplicado por el tiempo no
estimado para dicho proyecto (3 meses) Hacen un total de S/. 1,950.00; a
este costo se le suma los gastos de aprovisionamiento que Hace un total
de S/. 594.00, llegando así a un Costo Total Estimado de S/. 2,544.00 por
todo el Proyecto.
172
ANEXO 03: MANUAL DE USUARIO
MANUAL DE USUARIO
En el Sistema de Trámite Documentado Vía Web, hay 2 tipos de usuario: el

Administrador y Usuarios Comunes.
Pantalla de Inicio: Identificación de Usuario al Sistema
En la ilustración N° 12, es la pantalla de Inicio de Sesión, donde el usuario

del sistema debe ingresar su código y su contraseña, el código y la clave son
asignados por el área de unidad informática en la UNIA.
Ilustración 12 Inicio de sesion:
173
Ilustración 13: Pantalla de Bienvenida
MENÚ DEL SISTEMA:

Tabla 34: Menú del administrador
MENÚ DEL ADMINISTRADOR
REGISTRO MANTENIMIENTO CONSULTA REPORTES CERRAR

Trámite Trámite Asunto Documentos ---
Interno Emitidos
Trámite Usuarios Hoja de Documentos ---
Externo Ruta Recepcionados
Recepcionar Acción --- Documentos ---
Documento Despachados
Despachar Tipo de --- --- ---
Documento Documento
Tabla 35: Menú del usuario
MENU DEL ADMINISTRADOR

REGISTRO MANTENIMIENTO CONSULTA REPORTES CERRAR
Trámite Trámite Asunto Documentos ---
Interno Emitidos
Trámite Usuarios Hoja de Documentos ---
Externo Ruta Recepcionados
Recepcionar Acción --- Documentos ---
Documento Despachados
Despachar Tipo de --- --- ---
Documento Documento
174
El Administrador será el encargado de asignar los usuarios del sistema,
entregándoles sus respectivas contraseñas de acuerdo al área a que
corresponda, también será el encargado de registrar y mantener los tipos de
documentos, y Acciones a seguir de los documentos.
MANEJO DE LOS FORMULARIOS:
Mantenimiento de Usuarios:
En la ilustración N° 14, se puede observar todos los usuarios del sistema, a

que áreas corresponden, el tipo de usuario y sus claves.
Ilustración 14: Mantenimiento de Usuario
Cuando se desea crear un nuevo usuario del sistema, se hace click en el

botón "Nuevo", que se encuentra en la parte inferior izquierda de la tabla,
como se puede apreciar en la figura N° 14, también se puede modificar y
Eliminar el usuario, haciendo click en las respectivas columnas de la tabla y
el registro (fila de la tabla) que desea hacer una acción.
Después que se ha presionado el botón "Nuevo", se mostrará una pantalla

similar al que se muestra en la ilustración N° 15, es ahí donde se registra un
nuevo usuario del sistema.
175
Ilustración 15: Registro de Usuario
Una vez ingresado el código del personal, rellenamos todos los campos
obligatorios y le damos click en Guardar
Para Modficar los datos el usuario, solo basta hacer click en el link
"Modificar", de la tabla como se muestra en la figura N° 14, y se mostrara
una pantalla casi similar al de nuevo, con la diferencia que estará lleno todos
los campos del formulario, donde podrá modificar esos datos, y
seguidamente darle "Guardar".
Para Eliminar un usuario solo bastará hacer click en el link Eliminar de la

tabla como se muestra en la figura N° 16, donde nos enviara a una pantalla
con todos los datos del usuario y luego se da click en "Aceptar", se eliminará
el usuario del sistema.
176
Ilustración 16: Eliminar Usuario
Mantenimiento de Acción:
En esta interfaz (figura N° 17), se muestra todas las acciones que se puede
hacer cuando se registra un documento, se tiene la opción de registrar una
acción, también se tiene la opción de buscar, modificar y eliminar.
Cuando se hace click en el botón "Nuevo", se mostrar una pantalla como se

muestra en la figura N° 18, donde se podrá ingresar un nuevo registro,
seguidamente se hace click en el botón "Guardar".
177
Ilustración 17: Mantenimiento de Acción
Ilustración 18: Registro de Acción
178
Ilustración 19: Buscar Accion
Ilustración 20: Resultado de Busqueda de Acción
Tambien se puede hacer click en el link “Modificar” o “Eliminar”, que sigue

el mismo funcionamiento de la interfaz de Mantenimiento de Usuario
179
Mantenimiento de Tipo Documento:
En esta interfaz (figura N° 21) se podrá registrar los tipos de documentos,

hacerle su mantenimiento, como modificar, eliminar, y buscar. Para hacerle
los mantenimientos se sigue los mismos pasos que se hicieron en
mantenimiento de usuarios y acción.
Ilustración 21: Mantenimiento Tipo Documento
Registrar Trámite Interno:
En esta interfaz (figura N° 22) se podrá registrar los trámites internos (que
se dan dentro de la institución), se ingresa el destino (a donde va dirijido el
documento), se selecciona el tipo de documento y la acción a seguir del
documento, se ingresa también, el número de folios, y el número que tiene
el documento, como también el asunto, algunas observaciones, y también
se puede registrar.
Después de haber llenado los campos, se hace click en el botón "Guardar",

y seguidamente nos mostrará una pantalla (figura N° 23), que es la Hoja de
Tramite del documento.
180
Ilustración 22: Registrar Trámite Interno
Ilustración 23: Hoja de Trámite
181
Registrar Trámite Externo:
En el registro de trárnite externo, se diferencia del trámite interno solo de un

campo, que es la "razón", como se puede apreciar en la figura N° 24, en el
campo razón se ingresa el nombre de la persona o institución de donde viene
el documento.
Ilustración 24: Registro de Trámite Externo
182
Recepcionar Documento:
Esta interfaz (figura N° 25), podemos recepcionar todos los documentos, que
son derivados a nuestra área, tenemos la opción de "Mostrar todo", si
domos click en ese botón nos mostrar una lista de documentos que están en
nuestra área para recepcionar, pero si es una lista demasiado grande lo
podemos buscar por su código, tener en cuanto que solo recepcionar cuando
el documento real ya este en su área u oficina.
Despachar o Archivar Documento:
Esta interfaz (figura N° 26), tenemos dos opciones despachar o archivar

un documento, tener en cuenta que solo podemos hacer estas operaciones,
siempre y cuando el documento ya fue recepcionado en su area y por el
sistema, si no es así, no podrá verlo en esta interfaz.
Para Archivar, solo hacer click en el link de "Archivar", y nos mostrará un

mensaje de confirmación, antes de ejecutar esta acción, si la respuesta es
"si", entonces el documento se actualiza y ya esta archivado y
automáticamente desaparece esta interfaz.
183
Ilustración 25: Despachar o archivar documento
Ilustración 26: Registrar despacho de documento
Para despachar, solo hacer click en el link de "Despachar" (ilustración N°

25), y nos mostrará un nueva pantalla (ilustración N° 26), donde podemos
registrar los despachos de documentos a otra área u oficina.
184
Reportes de Documentos: Emitidos, Recibidos y Despachados:
En las ilustraciónes N° 27, 28, 29, son los reportes que podemos obtener del
sistema: como los documentos emitidos, Recepcionados y despachados en
mi área, solo ingresamos las fecgas en el calendario mostrado para obtener
los reportes y damos click en el botón "buscar"
Ilustración 27: Reporte de documentos emitidos
Ilustración 28: Reporte de documentos recibidos
185
Ilustración 29: Reporte de documentos despachados
CERRAR SESIÓN:
Ilustración 30: Cerrar sesión
186
Ilustración 31: Fin de sesión
187

Trabajo de Metodologia RUP

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Trabajo de Metodologia RUP

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD NACIONAL DE UCAYALI

Facultad de Ingeniería de Sistemas y de Ingeniería Civil

Escuela Profesional de Ingeniería

Informe de Práctica Pre Profesional I

DESARROLLO DEL ANÁLISIS Y DISEÑO DE UN SISTEMA WEB

ALUMNO : REÁTEGUI MACEDO, Ruddy Enzo

ASESOR : Ing.Mg. Jorge Luis Hilario Riva

Dedico este trabajo a mi familia que de

una manera u otra contribuyen en el

proceso de mi formación profesional,

gracias a su apoyo incondicional es

posible llevar acabo este proyecto.

brinda, para lograr así la ejecución de este proyecto; en segunda al Jefe de la

Oficina de Informática dela Universidad Nacional Intercultural de la Amazonía

“UNIA”por abrirlas puertas de esta reconocida universidad y brindar noción de

los procesos que se realizan en la misma; de igual forma mis agradecimientos al

estudio y mantenerse al tanto en el avance del mismo;por ultimo agradecer a

mis padres que dí a adía me brindan el apoyo en mi proceso de formación

La información es un activo estratégico, que aporta conocimiento y valor añadido

a las organizaciones actuales ante la sociedad de la información y en la llamada

nueva economía. Las nuevas tecnologías de la información y comunicaciones

(TIC’S) están haciendo aparecer nuevas aplicaciones, nuevas necesidades,

nuevas maneras de entender y gestionar nuestro entorno. Y en este contexto, el

tratamiento y las aplicaciones de trámite documentarioadquieren una importancia

La Universidad Nacional Intercultural de la Amazonia, siendo una casa de

superior de estudio que forma profesionales con ética, conocimiento y valores

para servir dentro o fuera de la región, está obligada al uso de la data en

registros, recepción y despacho de documentos, y consultas de trámite. Para ello

el control de documentos y por ende los trámites deben estar administrados de

manera eficaz y parcial; para crear confianza en la región y el país.

J2EE, puede ser la base para mejorar el control de trámite documentario y no

permitir las alteraciones o el uso indebido de la misma. Actualmente no se cuenta

con un sistema de éstas características dentro de la Universidad.

La investigación viene estructurada de la siguiente manera:

En el Capítulo I: Datos generales de la práctica; en esta parte se describe

los datos generales de la práctica pre profesional.

En el Capítulo II: Aspectos Generales de la empresa; en esta parte de detalla

datos de la empresa en la que se desarrolló la práctica.

En el Capítulo III: Objetivos y Justificación; En esta parte se definen los

objetivos generales y específicos, justificación teórica, practica y metodológica.

teórico, donde se hace hincapié en exponer el conocimiento teórico sobre RUP,

mostrar la arquitectura de implementación es Cliente/Servidor en sus diferentes

modelos, finalmente nos referimos a los Administración de Procesos.

En el Capítulo V: Proceso de desarrollo de software; Sedescribe el

desarrollo de la documentación del análisis y diseño del sistema planteado.

En el Capítulo VI: Fase de elaboración; Sedescribe a detalle la fase de

elaboración del RUP.

En el Capítulo VII: Conclusiones y Recomendaciones; obtenidas en el

Finalmente se presenta; las referencias Bibliográficas, y los Anexos necesarios

del Plan de desarrollo de software.

DEDICATORIA .......................................................................................................................... III

TABLA 1: Exposición del problema------------------------------------------------------------------------ 57

GRÁFICO 1: CASOS DE USO DE SISTEMA DE TRÁMITE DOCUMENTARIO -------- 76

DIAGRAMA 1: DC: MANTENIMIENTO DE USUARIOS. ------------------------------------------ 86

ILUSTRACIÓN 1: UBICACIÓN DE LA UNIA ------------------------------------------------------------3

DATOS GENERALES DE LA PRÁCTICA

1.1. TIPO DE PRÁCTICA PRE PROFESIONAL

Área: Desarrollo de Software

Tipo: Practica Pre Profesional I

1.2. TÍTULO DE LA PRÁCTICA PRE PROFESIONAL

“Desarrollo del Análisis y Diseño de un Sistema Web con Tecnología J2EE

para los procesos administrativos de Trámite Documentario en la