Sistema de información web para procesos de investigación

REPBLICA BOLIVARIANA DE VENEZUELA
UNIVERSIDAD RAFAEL BELLOSO CHACN

FACULTAD DE INGENIERA
ESCUELA DE INFORMTICA
SISTEMA DE INFORMACIN BAJO AMBIENTE WEB PARA LOS

PROCESOS DE INVESTIGACIN DEL PROGRAMA POSGRADO
DE LA UNIVERSIDAD NACIONAL EXPERIMENTAL
RAFAEL MARA BARALT
PRESENTADO POR:
Garca, Yeimaira
Molina, Freddy
Pirela, Jorge
ASESORADO POR:
Dra. Ordez, Maribel
Tutora Metodolgica
Ing. Fonseca, Roraxy
Tutora Acadmica
Dra. Faras, Yaritza
Tutora Industrial
MARACAIBO, JULIO DE 2011
SISTEMA DE INFORMACIN BAJO AMBIENTE WEB PARA LOS

PROCESOS DE INVESTIGACIN DEL PROGRAMA POSGRADO
DE LA UNIVERSIDAD NACIONAL EXPERIMENTAL
RAFAEL MARA BARALT
VEREDICTOS
DEDICATORIAS
A DIOS:
Por darme la fuerza y voluntad que

necesitaba para triunfar.
A MIS PADRES:
Jos y Berta, por acompaarme a lo

largo del camino.
A MI HIJOS:
Marco Antonio, Enmanuel y Freddy

mi fuente de inspiracin.
Yeimaira Garca
A DIOS:
Creador del Cielo y la Tierra.
A MIS PADRES:
Freddy y Norma, sin ustedes no

hubiese llegado a ser el hombre de
bien que soy en la actualidad.
A MI HIJOS:
Marco Antonio, Enmanuel y Freddy,

mis tesoros.
Freddy Molina
A DIOS PADRE:
Por ser fuente de luz y sabidura.
A MIS PADRES:
Zadid y Adelfa, por todo el apoyo

que me brindaron, s que esto lo
esperaban hace mucho tiempo.
Gracias por no perder la fe.
A MI ESPOSA:
Mi Julieta, sin tu impulso no hubiese

alcanzado esta meta en mi vida,
eres mi todo. Gracias por tu
paciencia y comprensin.
A MI HIJA:
Mara Jos, mi muchacha, mi nia

bonita, mi corazn es tuyo para que
lo guardes y lo atesores en tu
pecho.
Jorge Pirela Rivas
vi
AGRADECIMIENTOS
Agradecemos a la Universidad Rafael Belloso Chacn por ser la fuente
de conocimientos, en donde pudimos saciar nuestra sed por aprender y
desarrollar nuestras futuras habilidades profesionales.
Le damos gracias a nuestras tutoras, Dra. Maribel Ordez e Ing.
Roraxy Fonseca por todos los conocimientos que nos transmitieron.
Agradecemos tambin a la Universidad Rafael Mara Baralt por apoyar
la presente investigacin, especialmente le damos gracias a la Dra. Yaritza
Faras, por sus valiosos aportes.
Agradecemos a todo el personal del Programa Posgrado de la
UNERMB, Kitty Jimnez, Nancy Ruz, Dr. Luis Castro y Dra. Carmen Leal,
gracias por toda la colaboracin prestada para el desarrollo de esta
investigacin.
Por ltimo, les damos las gracias al personal de la Direccin de
Informtica del a UNERMB, a su director Ing. Delvis Lpez por su apoyo y
especialmente a los Ingenieros Luis Vsquez e Ileana Becerra, sin ellos no
hubiese sido posible este logro.
vii
Garca, Yeimaira; Molina, Freddy; Pirela, Jorge (Autores); Dra. Ordez,

Maribel (Tutora Metodolgica); Ing. Fonseca, Roraxy (Tutora Acadmica);
Dra. Faras, Yaritza (Tutora Industrial): SISTEMA DE INFORMACIN BAJO
AMBIENTE WEB PARA LOS PROCESOS DE INVESTIGACIN DEL
PROGRAMA
POSGRADO
DE
LA
UNIVERSIDAD
NACIONAL
EXPERIMENTAL RAFAEL MARA BARALT. Maracaibo, Venezuela:
Universidad Rafael Belloso Chacn. Julio de 2011
RESUMEN
Con el presente proyecto de investigacin, se pretende construir un
sistema de informacin el cual esta basado en ambiente web para apoyar las
actividades de investigacin a nivel universitario, especficamente a las
actividades referidas a la inscripcin de los proyectos de investigacin. El
estudio tiene como objetivo desarrollar un Sistema de Informacin bajo
ambiente Web para los Procesos de Investigacin del Programa Posgrado
de la Universidad Experimental Rafael Mara Baralt (UNERMB). Se plantea
realizar una investigacin descriptiva, de proyecto factible con estudio de
campo, orientado por las metodologas de ingeniera de requisitos segn
Escalona y Koch (2004) y Lowe y Eklund (2002) y el desarrollo rpido de
aplicaciones bajo SymfonyPHP segn Potencier y Zaninotto (2008). Se
evidenci la existencia de un contexto de alta complejidad de interrelaciones,
en donde se observ la necesidad de crear un sistema que permitiera
resolver el problema de dispersin geogrfica y la complejidad de los
procesos. Se aplic la ingeniera de requisitos como una alternativa para que
los usuarios no solamente participaran en la fase de anlisis sino que
tambin se tomaran en cuenta sus ideas en la fase de diseo, lo cual
permiti desarrollar la aplicacin en funcin a los requerimientos funcionales
negociados.
Palabras clave: Sistema de Informacin, Ambiente Web, NDT, DDDR,
Prototipos
viii
Garca, Yeimaira; Molina, Freddy; Pirela, Jorge (Authors), Dr. Ordoez,

Maribel (Methodological Tutor); Ing. Fonseca, Roraxy (Academic Tutor); Dr.
Farias, Yaritza (Industrial Tutor): WEB INFORMATION SYSTEM FOR
PROCESSES RESEARCH OF GRADUATE PROGRAM AT NATIONAL
UNIVERSITY EXPERIMENTAL "RAFAEL MARIA BARALT" Maracaibo,
Venezuela: Dr. Rafael Belloso Chacin University. July 2011
ABSTRACT
The present research project aims to build an information system which
is web-based environment to support research activities at the college level,
specifically on activities related to the registration of research projects. The
study aims to develop an information system on Web Environment for
Processes Research Graduate Program at the University Experimental
Rafael Mara Baralt (UNERMB). It plans to carry out a descriptive research
project feasible with field study, guided by the requirements engineering
methodologies as Escalona & Koch (2004) and Lowe & Eklund (2002) and
rapid application development under SymfonyPHP according to Potencier &
Zaninotto (2008). It revealed the existence of a highly complex context of
relationships, where there was a need to create a system that would solve the
problem of geographic dispersion and complexity of the processes. Was
applied to requirements engineering as an alternative for users to not only
participate in the analysis phase but also take into account their ideas for the
design of the application, allowing to develop the application according to the
functional requirements negotiated.
Keywords: Information System, Web Environment, NDT, DDDR, Prototypes
ix
NDICE GENERAL
p.p.
VEREDICTOS................................................................................................ iii
DEDICATORIAS ............................................................................................ vi
AGRADECIMIENTOS .................................................................................. vii
RESUMEN ................................................................................................... viii
ABSTRACT ................................................................................................... ix
NDICE GENERAL ......................................................................................... x
NDICE DE CUADROS ................................................................................. xv
NDICE DE ILUSTRACIONES..................................................................... xvi
INTRODUCCIN ............................................................................................ 1
CAPTULO
I
EL PROBLEMA ................................................................................. 3
1. PLANTEAMIENTO DEL PROBLEMA ..................................................... 4
1.1. FORMULACIN DEL PROBLEMA ................................................ 10
2. OBJETIVOS DE LA INVESTIGACIN ................................................. 10
2.1. OBJETIVO GENERAL ................................................................... 10
2.2. OBJETIVOS ESPECFICOS .......................................................... 10
3. JUSTIFICACIN E IMPORTANCIA DE LA INVESTIGACIN .............. 11
4. DELIMITACIN DE LA INVESTIGACIN ............................................ 12
II
MARCO TERICO .......................................................................... 14

1. ANTECEDENTES ................................................................................ 15
2. BASES TERICAS .............................................................................. 19
2.1. SISTEMAS DE INFORMACIN .................................................... 20
2.1.1. DEFINICIONES DE SISTEMAS DE INFORMACIN ........... 20
2.1.2. CLASIFICACIN DE LOS SISTEMAS DE INFORMACIN . 21
2.1.3. COMPONENTES DE LOS SISTEMAS DE INFORMACIN . 22
2.1.4. ENFOQUES DE LOS SISTEMAS DE INFORMACIN......... 24
2.1.4.1. ENFOQUE INDEPENDIENTE ................................ 24
2.1.4.2. ENFOQUE CENTRALIZADO .................................. 24
2.1.4.3. ENFOQUE DISTRIBUIDO ...................................... 25
2.1.5. CICLO DE VIDA DE LOS SISTEMAS DE INFORMACIN... 25
2.1.5.1. MODELO CLSICO O CASCADA .......................... 26
2.1.5.2. MODELO DE ANLISIS ESTRUCTURADO ........... 29
2.1.5.3. MODELO EN ESPIRAL .......................................... 30
2.1.5.4. MODELO DE DESARROLLO INCREMENTAL ....... 32

2.1.5.5. MODELO DE PROTOTIPADO RPIDO ................. 34
2.1.5.6. MODELO DE PROTOTIPADO EVOLUTIVO........... 35
2.1.6. ARQUITECTURA DE SOFTWARE ...................................... 37
2.1.6.1. EL PATRN DE DISEO MODELO VISTA
CONTROLADOR .................................................... 38
2.1.6.2. LOS FRAMEWORKS .............................................. 43
2.1.6.3. EL FRAMEWORK DE DESARROLLO
SYMFONYPHP ....................................................... 44
2.1.7. POSTGRESQL ..................................................................... 61
2.1.7.1. CARACTERSTICAS .............................................. 63
2.1.7.2. LIMITACIONES....................................................... 65
2.2. AMBIENTE WEB ........................................................................... 66
2.2.1. DEFINICIONES .................................................................... 66
2.2.2. RESEA HISTRICA DE LA INTERNET ............................. 66
2.2.3. PROTOCOLOS DE INTERNET ............................................ 69
2.2.4. LA WORLD WIDE WEB ....................................................... 70
2.2.5. HYPERTEXT MARKUP LANGUAGE ................................... 70
2.2.6. SITIOS WEB......................................................................... 71
2.1.6.1. DEFINICIONES ...................................................... 71
2.1.6.2. TIPOS DE SITIOS WEB ......................................... 72
2.1.6.3. PLANIFICACIN DE UN SITIO WEB ...................... 73
2.1.6.4. CONSTRUCCIN DE UN SITIO WEB.................... 75
2.2.7. APLICACIONES WEBS ........................................................ 76
2.2.7.1. CATEGORAS DE APLICACIONES WEB .............. 77
2.2.7.2. CARACTERSTICAS DE LAS APLICACIONES
WEB ....................................................................... 79
2.2.8. INGENIERA DE REQUISITOS ............................................ 84
2.2.8.1. TIPOS DE REQUISITOS ......................................... 84
2.2.8.2. ESPECIFICACIN DE REQUISITOS ..................... 85
2.2.8.3. TCNICAS PARA LA CAPTURA DE
REQUISITOS .......................................................... 87
2.2.8.4. DEFINICIN DE REQUISITOS............................... 91
2.2.8.5. VALIDACIN DE REQUISITOS.............................. 93
2.2.9. METODOLOGAS PARA EL DESARROLLO DE
SISTEMAS DE INFORMACIN BASADOS EN WEB .......... 95
2.2.9.1. DESARROLLO RPIDO DE APLICACIONES
(RAD) ...................................................................... 95
2.2.9.2. NAVIGATIONAL DEVELOPMENT TECHNIQUES
(NDT) ...................................................................... 97
xi
2.2.9.3. DESIGN-DRIVEN REQUIREMENTS

ELICITATION (DDRE) .......................................... 101
2.3. PROCESOS DE INVESTIGACIN .............................................. 111
2.3.1. DEFINICIONES .................................................................. 111
2.3.1.1. PROCESOS ......................................................... 111
2.3.1.2. GESTIN.............................................................. 111
2.3.2. ACTIVIDADES ADMINISTRATIVAS ................................... 112
2.3.2.1. PLANIFICACIN .................................................. 113
2.3.2.2. ORGANIZACIN .................................................. 113
2.3.2.3. CONTROL ............................................................ 114
2.3.2.4. COMUNICACIN ................................................. 115
2.3.2.5. DIRECCIN .......................................................... 116
2.3.2.6. COORDINACIN .................................................. 116
2.3.3. PROCESOS ACADMICOS .............................................. 117
2.3.2.1. DEFINICIONES .................................................... 117
2.3.2.2. LA ADMINISTRACIN EN LA EDUCACIN
SUPERIOR ........................................................... 118
3. SISTEMA DE VARIABLES ................................................................. 120
3.1. VARIABLE NOMINAL .................................................................. 120
3.2. VARIABLE CONCEPTUAL .......................................................... 120
3.2.1. SISTEMA DE INFORMACIN ............................................ 120
3.2.2. AMBIENTE WEB ................................................................ 120
3.2.3. PROCESOS DE INVESTIGACIN..................................... 121
3.3. VARIABLE OPERACIONAL ........................................................ 121
3.3.1. SISTEMA DE INFORMACIN ............................................ 121
3.3.2. AMBIENTE WEB ................................................................ 121
3.3.3. PROCESOS DE INVESTIGACIN..................................... 122
4. DEFINICIN DE TRMINOS BSICOS ............................................ 122
III
MARCO METODOLOGICO ........................................................... 124

1.
2.
3.
4.
IV
TIPO DE INVESTIGACIN ................................................................ 125

DISEO DE LA INVESTIGACIN ...................................................... 127
TCNICAS PARA LA RECOLECCIN DE DATOS ........................... 128
METODOLOGA ................................................................................. 132
RESULTADOS DE LA INVESTIGACIN ...................................... 136

1. ANLISIS DE LOS DATOS ................................................................ 137
1.1. DESCUBRIMIENTO DE REQUISITOS........................................ 137
1.1.1. DOMINIO DE LA APLICACIN .......................................... 138
1.1.2. OBJETIVOS DEL NEGOCIO .............................................. 142
1.1.3. PROCESOS DE NEGOCIO (CADENA DE VALOR) ........... 145
xii
1.1.4. REGLAS DE NEGOCIO ..................................................... 146

1.1.5. ACTORES DEL PROYECTO ............................................. 148
1.1.6. DESCRIPCIN DEL PROBLEMA ...................................... 150
1.1.7. RECOLECCIN DE REQUISITOS FUNCIONALES........... 153
1.2. ANLISIS DE REQUISITOS ........................................................ 156
1.3. EVALUACIN DE REQUISITOS DE PROTOTIPOS ................... 158
1.3.1. OBJETIVOS DEL SISTEMA ............................................... 158
1.3.2. CATALOGO DE REQUISITOS FUNCIONALES ................. 161
1.3.2.1. REQUISITOS TRANSACCIONALES .................... 161
1.3.2.2. REQUISITOS DE SALIDA .................................... 163
1.3.2.3. REQUISITOS DE DATOS ..................................... 163
1.3.3. REQUISITOS NO FUNCIONALES ..................................... 163
1.3.3.2. REQUISITOS DE INTERFAZ ................................ 164
1.3.3.2. REQUISITOS NAVEGACIONALES ...................... 165
1.3.3.3. REQUISITOS DE PERSONALIZACIN ............... 165
1.3.3.4. REQUISITOS GENERALES ................................. 166
1.3.4. DEFINICIN DE ACTORES ............................................... 166
1.3.5. CASOS DE USO DEL SISTEMA ........................................ 167
1.3.6. EL PROTOTIPO ................................................................. 169
1.4. CONSTRUCCIN DE LA APLICACIN ...................................... 172
1.4.1. CONFIGURACIN DEL SERVIDOR WEB ......................... 173
1.4.1.1. PRE-REQUISITOS PARA EL SERVIDOR WEB ... 174
1.4.1.2. INSTALACIN DE SYMFONY .............................. 176
1.4.1.3. INSTALACIN DEL SITIO WEB ........................... 177
1.4.2. CREACIN DEL PROYECTO Y SUS COMPONENTES .... 178
1.4.2.1. CREACIN DEL PROYECTO .............................. 179
1.4.2.2. CREACIN DE LAS APLICACIONES .................. 179
1.4.3. CONSTRUCCIN DEL MODELO DE DATOS Y LOS
MODULOS ......................................................................... 179
1.4.3.1. CONFIGURACIN DE LA CONEXIN CON
POSTGRESQL ..................................................... 179
1.4.3.2. EL ESQUEMA DE DATOS.................................... 180
1.4.3.3. CREACIN DE LOS MDULOS .......................... 181
1.4.3.4. CONFIGURACIN DE LOS MDULOS ............... 182
1.4.4. ESTABLECIMIENTO LAS VISTAS ..................................... 190
1.5. ESTABLECIMIENTO DE LOS CONTROLADORES .................... 194
1.6. CIERRE DE LA APLICACIN ..................................................... 210
1.6.1. PRUEBAS UNITARIAS ...................................................... 210
1.6.2. PRUEBAS FUNCIONALES ................................................ 211
2. DISCUSIN DE LOS RESULTADOS................................................. 212
xiii
3. CONCLUSIONES ............................................................................... 212

4. RECOMENDACIONES....................................................................... 214
REFERENCIAS BIBLIOGRAFICAS .......................................................... 215

ANEXOS ..................................................................................................... 221
1
MANUAL DE IDENTIDAD VISUAL PARA LOS PORTALES

WEBS DE LA UNIVERSIDAD NACIONAL EXPERIMENTAL
RAFAEL MARA BARALT............................................................ 222
MANUAL DE USUARIO ................................................................. 227
DICCIONARIO DE DATOS ............................................................ 234
LOS PLUGINS PARA EL CONTROL DE ACCESO Y

AUTENTICACIN .......................................................................... 260
ESQUEMA DE LA BASE DE DATOS (SCHEMA.YML) ................. 268
xiv
NDICE DE CUADROS
CUADRO
p.p.
ESTRUCTURA DEL DIRECTORIO RAZ DE LOS

PROYECTOS EN SYMFONY ........................................................ 50
ESTRUCTURA DEL SUBDIRECTORIO DE LAS

APLICACIONES EN SYMFONY .................................................... 51
ESTRUCTURA DEL SUBDIRECTORIO DE LOS MDULOS

EN SYMFONY ............................................................................... 52
ESTRUCTURA DEL DIRECTORIO WEB EN SYMFONY ............. 53
LIMITACIONES DE POSTGRESQL .............................................. 65
CUADRO DE ACTIVIDADES ....................................................... 134
REGLAS DE NEGOCIO DE LA UNIDAD DE ATENCIN A LA

INVESTIGACIN ......................................................................... 146
ACTORES DEL PROYECTO ....................................................... 149
LISTA PRELIMINAR DE REQUISITOS FUNCIONALES ............. 155
10
LISTA PRELIMINAR DE REQUISITOS FUNCIONALES

(NEGOCIADOS) .......................................................................... 157
11
DEFINICIN DE ACTORES ........................................................ 167
xv
NDICE DE ILUSTRACIONES
FIGURA
p.p.
COMPONENTES GENRICOS DE UNA ARQUITECTURA

WEB ................................................................................................ 23
MODELO CLSICO O CASCADA .................................................. 27
EJEMPLO DEL MODELO DE ANLISIS ESTRUCTURADO ......... 30
MODELO DE DESARROLLO EN ESPIRAL ................................... 31
MODELO DE DESARROLLO INCREMENTAL............................... 33
MODELO DE PROTOTIPADO RPIDO ......................................... 34
MODELO DE PROTOTIPADO EVOLUTIVO .................................. 36
EL PATRN DE DISEO MODELO VISTA CONTROLADOR ...... 39
CICLO DE VIDA DEL MVC ............................................................. 41
10
IMPLEMENTACIN DE MVC EN SYMFONY ................................ 48
11
OBJECT RELATION MAPER ......................................................... 54
12
UNA EXCEPCIN EN EL ENTORNO DE DESARROLLO ............. 59
13
UNA EXCEPCIN EN EL ENTORNO DE PRODUCCIN ............. 59
14
APLICACIN SYMFONY EN ENTORNO DE DESARROLLO........ 60
15
COMPONENTES DEL POSTGRESQL .......................................... 61
16
CATEGORAS DE LAS APLICACIONES WEB .............................. 77
17
DIMENSIONES PARA LA CATEGORIZACIN DE LAS

APLICACIONES WEB .................................................................... 80
18
PROCESO DE INGENIERA DE REQUISITOS.............................. 86
19
DESCRIPCIN GENERAL DE LAS ACTIVIDADES DE NDT ...... 101
20
ESTRUCTURA DEL DOCUMENTO DE REQUISITOS DEL

SISTEMA ...................................................................................... 103
21
PORTADA DEL DOCUMENTO DE REQUISITOS DEL

SISTEMA ...................................................................................... 104
22
LISTA DE CAMBIOS DEL DOCUMENTO DE REQUISITOS

DEL SISTEMA .............................................................................. 105
23
PLANTILLA DE OBJETIVOS DEL SISTEMA ............................... 106
24
PLANTILLA PARA LOS REQUISITOS DE ALMACENAMIENTO

DE INFORMACIN....................................................................... 107
xvi
25
PLANTILLA PARA LOS REQUISITOS FUNCIONALES ............... 108
26
PLANTILLA PARA LOS ACTORES DEL SISTEMA ..................... 109
27
PLANTILLA PARA LOS REQUISITOS NO FUNCIONALES ........ 110
28
MATRIZ DE RASTREABILIDAD DEL DOCUMENTO DE

REQUISITOS DEL SISTEMA ....................................................... 110
29
MODELO DE DILOGO PARA LA EDUCCIN DE

REQUISITOS ................................................................................ 129
30
MODELO DE DOMINIO DE LA APLICACIN .............................. 138
31
MODELO DE LOS OBJETIVOS DE NEGOCIO DE LA UNIDAD

DE ATENCIN A LA INVESTIGACIN UNERMB ....................... 144
32
MODELO DE PROCESOS NEGOCIO DE LA UNIDAD DE

ATENCIN A LA INVESTIGACIN .............................................. 145
33
DIAGRAMA DE SUBSISTEMAS................................................... 167
34
CASO DE USO DE LA INSCRIPCIN DE PROYECTOS DE

INVESTIGACIN .......................................................................... 168
35
MODULO REGISTRO DE PROYECTO DE INVESTIGACIN ..... 169
36
MODULO PRESENTACIN DE RESULTADOS .......................... 170
37
MODULO VALIDACIN DE PROYECTOS DE

INVESTIGACIN .......................................................................... 171
xvii
INTRODUCCIN
El presente trabajo de investigacin est orientado a la creacin de un
Sistema de Informacin basado en Ambiente Web para apoyar los procesos
de investigacin del Programa Posgrado de la Universidad Nacional
Experimental Rafael Mara Baralt (UNERMB), referidos a la inscripcin de
los proyectos de investigacin de los participantes de las distintas maestras
que lo conforman.
Segn Arribas (2000, p. 154):
El sistema de informacin de una organizacin no es slo un centro de
proceso de datos sino que ste forma parte de los recursos de
informacin; sera una parte de las actividades de informacin y una
parte de las relaciones, de las estructuras y fines que tiene que ver con
el soporte fsico del sistema de informacin.
Coincidiendo con el autor, se propone un sistema basado en ambiente
web para dar respuesta a la problemtica planteada, facilitando las
actividades acadmicas y administrativas tanto a los participantes de las
maestras, como tambin para el personal administrativo y autoridades
acadmicas adscritos a las Unidades de Atencin a la Investigacin de todas
las sedes y a la Coordinacin de Investigacin del Programa Posgrado de la
UNERMB.
Para el logro de estas metas, el trabajo se dividi en cuatro captulos:
El primer captulo, concerniente al problema, donde se presenta el
planteamiento
formulacin
del
problema,
justificacin y delimitacin de la investigacin.
objetivos,
importancia,
El segundo captulo hace referencia a la fundamentacin terica, donde

se plasmaron los antecedentes y bases tericas, y finalmente la
operacionalizacin de la variable de investigacin;
El tercer captulo detalla el marco metodolgico, donde se caracteriz a
la investigacin, la poblacin objeto de estudio y se describe el instrumento
de investigacin a travs de la validacin y confiabilidad del mismo.
En el cuarto captulo se presenta los resultados de la investigacin y la
discusin de los mismos, adems se especifican las conclusiones y
recomendaciones de la investigacin.
CAPITULO I
EL PROBLEMA
CAPTULO I
EL PROBLEMA
En este captulo se describe el contexto de la situacin problemtica
planteada, se definieron los objetivos del estudio y por ltimo, se definieron la
importancia, justificacin y delimitacin de la investigacin.
1.
PLANTEAMIENTO DEL PROBLEMA

Los cambios suscitados a escala mundial y en la medida en que los
avances cientficos y tecnolgicos van surgiendo, las instituciones educativas

se enfrentan a uno de los retos ms desafiantes de todos los tiempos, ser
ms productivas, eficientes y competitivas en una plataforma global que
exige nuevos esquemas e induce a su personal a mejorar los procesos
acadmicos y administrativos, facilitando a los estudiantes los procesos de
investigacin desarrollados por ellos durante el recorrido acadmico.
Luego de la aparicin de la internet se han producido cambios sociales
y econmicos que han incrementado su popularidad, la sociedad en pleno ha
adoptado esta tecnologa, incorporndola en todos los aspectos de la vida
cotidiana; tambin las organizaciones se han valido de esta nueva plataforma
para disponer de productos y servicios informativos cualitativamente
superiores para satisfacer las necesidades informacionales de los usuarios.
5
De acuerdo a Laudon (2004, p. 31): los sistemas de informacin estn
arraigados
en
las
organizaciones,
un
resultado
de
la
estructura
organizacional, cultura, flujos de trabajo y procedimientos operativos

estandarizado.
En este sentido, los sistemas de informacin son una parte activa de las
organizaciones, son instrumentos para el cambio organizacional y la creacin
de valor, hacen posible transformar estos elementos de la organizacin en
nuevos modelos de negocios y redefinir los lmites de la misma.
A la luz de estos conceptos, los sistemas de informacin basados en la
web son parte de la red global, se dedican a dar apoyo a grupos de personas
de
una
mas
organizaciones
en
sus
diferentes
actividades
de
intercomunicacin, sobre estos sistemas se radican las operaciones

informticas dentro de un contexto mundial y dirigido a mltiples sectores
humanos.
En otro orden de ideas, dentro de la amalgama de actividades
producidas en los entornos universitarios, cabe decir que los procesos de
investigacin son todas las actividades desarrolladas por los estudiantes con
el fin de producir investigacin cientfica, las cuales ameritan seguimiento y
control basado en los aspectos y normativas legales de cada institucin.
En el mbito mundial, Orozco y Cardoso (2004, p. 8), sealan: en la
Organizacin de las Naciones Unidas para la Educacin, la Ciencia y la
Cultura (UNESCO) hay una preocupacin constante por el mejoramiento de
la calidad del servicio pblico de la educacin.
En este sentido, las instituciones educativas deben brindar servicios de

calidad, estos sern medidos como el valor resultante de la satisfaccin de
sus miembros con relacin a dichos servicios, la meta es mejorar
constantemente los procesos para agilizar sus servicios ofreciendo rapidez y
facilidad a todos los miembros de la comunidad universitaria.
A nivel latinoamericano, a finales del siglo pasado, se observ un
aumento vertiginoso de la matrcula estudiantil universitaria, esto trajo como
consecuencia el proceso de masificacin de la matrcula en las universidades
pblicas, que aunado a la reduccin del gasto pblico en este sector de la
educacin, ha provocado la disminucin de la calidad de los servicios
acadmicos administrativos debido a la poca o nula inversin en recursos
humanos, materiales y equipos. (Bergamin, 2008; Klas, 2008 y Riley, 2005).
Sobre estos sealamientos, puede inferirse entonces que cualquier
servicio ofrecido por una institucin educativa puede desmejorar debido a
lentitud en los procesos de atencin, registro, consultas y publicacin de
resultados, causando largas colas de personas, entre otros problemas; los
cuales deben ser evitados a priori con el propsito de eliminar los retrasos y
molestias a los estudiantes.
En el mbito nacional, se destaca la Biblioteca Marcel Roche del
Instituto Venezolano de Investigaciones Cientficas (IVIC), en la cual reside el
mantenimiento de la ms importante coleccin cientfica y tecnolgica de
Amrica Latina y el Caribe debido a las innovaciones permanentes
incorporadas tanto en la prestacin de servicios, como en la organizacin y
desarrollo de sus colecciones y el Servicio de Conmutacin Bibliogrfica por

la va electrnica, atendiendo la demanda informacional tanto del pas como
de la regin, al digitalizarse los artculos cientficos y enviarlos a su destino
en formato PDF. (Romano, 2007, p. 14).
A nivel regional, se observa el caso de la Universidad Rafael Belloso
Chacn (URBE), la cual estableci como norte la digitalizacin de todos sus
procesos y servicios entre los cuales estn la consulta de tesis, videos y
publicaciones, normativas, entre otros servicios, proporcionados a travs de
su portal web, facilitando el acceso a todos sus estudiantes quienes pueden
obtener informacin rpidamente bajo la forma de archivos PDF, MPEG,
WAV, entre otros. (www.urbe.edu - Vida Universitaria).
En este contexto se encuentra la Universidad Nacional Experimental
Rafael Mara Baralt (UNERMB), enraizada en los Municipios que conforman
a la subregin Costa Oriental del Lago de Maracaibo, creada en el ao 1983,
con el propsito de elevar, dentro de dicha subregin nuevos niveles
educativos, aportando profesionales a la comunidad y a la industria para
contribucin de su desarrollo. (www.unermb.edu.ve Resea Histrica)
Dentro de la referida institucin se encuentra el Programa Posgrado,
adscrito al Vice Rectorado Acadmico, dicho programa tiene como misin
formar a los profesionales a nivel del posgrado en las maestras Educacin
Superior, Administracin de la Educacin Bsica, Gerencia de Recursos
Humanos y Gerencia Financiera, las mismas se imparten en muchas sedes:
en Cabimas estn las sedes Quinta Yoly (sede principal), Miraflores y
Carretera H, tambin existen las sedes de Maracaibo (Valle Fro y Dr.

Portillo), Trujillo, Valera, Coro, Dabajuro, Capatrida, Los Puertos de
Altagracia, Bachaquero, Mene Grande, Maracaibo y La Caada.
Asimismo, la Coordinacin de Investigacin y las Coordinaciones de
las maestras del Posgrado UNERMB se ubican en Cabimas, desde donde
se coordinan todas las actividades referentes a los procesos de
investigacin: inscripcin de proyectos de investigacin y tesis de grado.
En base a entrevistas elaboradas de manera no estructurada, y de
apreciaciones realizadas por observaciones realizadas en las sedes
Maracaibo y Cabimas, se pudo determinar que los participantes (estudiantes
de postgrado) de las diferentes maestras se deban dirigir a las Unidades de
Atencin a Investigacin en las sedes, para consignar los recaudos de la
inscripcin del proyecto de investigacin, luego de ser aprobado, los
participantes estaban autorizados a ejecutar el proyecto como tesis de grado,
al culminarla deban inscribirla en la antes referidas instancias para
posteriormente defenderla y obtener la aprobacin definitiva de la materia.
Con el tiempo, el nivel de solicitudes de inscripcin para proyectos de
investigacin y tesis de grado fue tan alto que se originaban prolongadas
colas y largos tiempos de espera, provocando molestias en los participantes
de posgrado, ms cuando provenan de sedes lejanas. Adems se iba
acumulando en forma excesiva papeleo, esto trajo como consecuencia un
estado de parlisis administrativa, desde las unidades de atencin en las
sedes, hasta la Coordinacin de Investigacin y la Direccin del Posgrado.
En virtud a esta situacin, a mediados del ao 2005, el Programa

Postgrado descentraliz el servicio de atencin de los participantes, las
sedes se encargaran de servir de enlace entre los participantes y la
Coordinacin de Investigacin; desde las sedes se recopilan todos los
recaudos para la inscripcin del proyecto de investigacin, asignacin de
evaluadores de proyectos, inscripcin de tesis, recepcin de currculos de
profesores tutores y jurados de tesis, entre otros recaudos.
Al principio, se elimin del traslado de las participantes pero aument la
complejidad, las decisiones siguen dependiendo de la Coordinacin de
Investigacin, las sedes deben consignar los recaudos va correo electrnico
escaneando los instrumentos de los evaluadores de los proyectos y los
instrumentos de investigacin, para ser revisados y analizados para evitar la
duplicidad en los ttulos e instrumentos para mantener la originalidad.
A pesar de los problemas observados no se ha instrumentado un
mecanismo que evite los inconvenientes a los participantes y elimine la
complejidad de los procesos, no existe un mecanismo de recepcin, ni
control y validacin, ni tampoco hay un procedimiento automtico para
comunicar a los participantes los resultados de dichos procesos.
Sobre este contexto, es legtimo formularse preguntas que permitan
esclarecer la situacin actual de los servicios acadmicos y administrativos
de la Universidad Nacional Experimental Rafael Mara Baralt, sobre los
procesos de investigacin del Programa Posgrado, y de esa forma, obtener
respuestas que arroje una luz para resolver el problema planteado.
10
1.1. FORMULACIN DEL PROBLEMA

Si la evidencia de estos planteamientos apunta a los procesos y
procedimientos acadmicos del Programa Posgrado de la UNERMB los
cuales no apoyan en forma automatizada los procesos de investigacin de
los estudiantes de sus diferentes maestras, entonces:
Es necesario desarrollar un Sistema de Informacin bajo ambiente
Web para los Procesos de Investigacin del Programa Posgrado de la
Universidad Experimental Rafael Mara Baralt?
2.
OBJETIVOS DE LA INVESTIGACIN
2.1. OBJETIVO GENERAL

Desarrollar un Sistema de Informacin bajo ambiente Web para los
Procesos de Investigacin del Programa Posgrado de la Universidad
Experimental Rafael Mara Baralt.
2.2. OBJETIVOS ESPECFICOS
Analizar la situacin actual de los procesos y procedimientos
acadmicos de la Coordinacin de Investigacin del Programa Posgrado de
la Universidad Experimental Rafael Mara Baralt.
Determinar los requerimientos del Sistema de Informacin para su
desarrollo en la Coordinacin de Investigacin del Programa Posgrado de la
Universidad Experimental Rafael Mara Baralt.
11
Disear lgica y fsicamente un sistema de informacin bajo el ambiente

Web tomando en cuenta los requerimientos encontrados en la recopilacin
de datos.
Evaluar la operatividad del sistema de informacin mediante pruebas
pertinentes.
3.
JUSTIFICACIN E IMPORTANCIA DE LA INVESTIGACIN

En funcin de lo antes expuesto, se consider presentar una
investigacin que haga posible el desarrollo de un software basado en

ambiente web para los procesos de investigacin del Programa Posgrado de
la UNERMB.
Desde el punto de vista prctico, la investigacin beneficiar a todos los
participantes del Posgrado ofrecindoles servicios acadmicos basados en la
web que les permitirn agilizar los procesos de investigacin de inscripcin
de los proyectos de investigacin.
Por otro lado, desde el punto de vista terico, se proporcionarn nuevos
aportes a la comunidad cientfica, en virtud a que se aplicaron conceptos y
teoras del Software Libre (Free Software) y el Cdigo Abierto (OpenSource),
brindando (a) Transparencia ya que la calidad del cdigo est a la vista de
quien la quiera y sepa controlar; (b) Seguridad: imposibilidad de usar
software malicioso que pueda perjudicar a la institucin; (c) aprendizaje, la
complejidad en el desarrollo del sistema ser suprimida por la sencillez en la
elaboracin del cdigo; (d) Herencia cultural: todo el cdigo disponible pasa a
12
formar parte de los recursos pblicos de los que dispone la Humanidad.

Igualmente, se aplicaron conceptos referidos a la Arquitectura de Software,
especficamente el patrn de diseo Modelo Vista Controlador, el cual
ofrece una nueva perspectiva para el desarrollo de sistemas de informacin
basados en ambiente web.
Desde el punto de vista metodolgico en la presente la investigacin se
aplicaron las nuevas metodologas basadas en el desarrollo rpido de
aplicaciones
Development
(Rapid
Aplication
Techniques
Development
(Escalona
otros,
RAD):
2004),
Navigational
Design-driven
Requirements Elicitation (Lowe y Eklund, 2002) y Desarrollo de Aplicaciones

Web bajo SymfonyPHP (Potencier y otros, 2008). Asimismo, todas las tareas
referidas al diseo, codificacin y pruebas e implementacin del sistema
propuesto fueron realizadas siguiendo los estndares libres.
4.
DELIMITACIN DE LA INVESTIGACIN
El presente estudio se llev a cabo en la Universidad Nacional
Experimental Rafael Mara Baralt, especficamente en la sede Quinta Yoly

del Programa Posgrado, ubicada en el Municipio Cabimas del Estado Zulia.
Se realiz en el lapso comprendido desde enero hasta julio 2011.
La teora que recopilada en esta investigacin se ajust a la carrera
Ingeniera en Informtica y se fundamenta en los autores Escalona y Koch
(2002), Lowe y Eklund (2002), Potencier (2008), Reenskaug (1978), Kappel
(2003), Yourdon (1993), Senn (1992), Laudon y Laudon (2004), Surhone
13
(2010), Heredia (2001), Stoner, Robbins y DeCenzo (2002), entre otros.
CAPTULO II
MARCO TERICO
CAPTULO II
MARCOTERICO
En este captulo se explican las bases tericas que orientaron la
investigacin;
se
realiz
un
estudio
bibliogrfico
partiendo
de
los
antecedentes, fundamentos tericos y finalmente la operacionalizacin de las

variables de estudio.
1.
ANTECEDENTES
Albarracn (2009, p. 1), refiere que la Escuela de Economa de la
Universidad de Carabobo, comienza a incentivar la investigacin a travs de

la presentacin de trabajos de grado como requisito para obtener el ttulo de
economista de sus estudiantes. La realizacin y presentacin de estos
trabajos de investigacin requiere de personal humano, recursos tcnicos y
econmicos que apoyen todo este proceso.
As, el o los estudiantes que ingresen a ste deben contar con un tutor,
asesor y finalmente con un jurado idneo para la evaluacin de su trabajo,
este proceso se ha realizado de forma manual: la asignacin del tutor, la
designacin de los jurados, y toda la labor administrativa que esto conlleva,
en consecuencia, se incrementaban los lapsos entre la inscripcin del
proyecto de investigacin y la defensa de la tesis.
15
16
En base a la situacin antes descrita, la autora propuso el diseo de un

sistema que permita el registro de los trabajos de grado por parte de sus
autores (estudiantes), para su posterior presentacin ante el Consejo de
Escuela, el cual tomar decisiones sobre la asignacin del jurado con la
informacin recolectada por el mismo sistema de informacin a travs del
manejo de una base de datos sobre tutores, jurados, temas y otras variables
a considerar.
El tipo de investigacin desarrollado est clasificada como un proyecto
factible y los resultados obtenidos se pueden observar en la direccin web
http://www.faces.uc.edu.ve/siaju/, en dicho enlace est prototipo del sistema,
el cual se ha probado e implementado en dos procesos de asignacin de
jurados con resultados muy favorables.
Se concluyo que, es importante y de urgente necesidad la aplicacin y
puesta en marcha de este sistema, para mejorar los niveles de eficiencia en
la logstica de este importante proceso dentro de cualquier institucin
educativa que presente estas caractersticas.
El anterior estudio es pertinente con la presente investigacin debido a
que, a pesar de que fue un trabajo de ascenso estuvo enmarcado en
ingeniera de sistemas, aunque difieren con respecto al entorno de
programacin y el manejador de base de datos y que se aplic para la
actividad de seleccin de jurados, coincide en la aplicacin de sistemas de
informacin basado en ambiente web implementados en el nivel del
postgrado para el apoyo de las actividades de investigacin.
17
Quintero (2008, p. 2), present el desarrollo de un sistema de

informacin web que dar soporte a algunos de los procesos fundamentales
que se llevan en la oficina de registros estudiantiles de la facultad de
ingeniera (OREFI) de la Universidad de Los Andes. Dicho sistema se
desarroll utilizando UML 2.0 (Unified Modeling Language) para el modelado
y como gua en su desarrollo, el mtodo Watch para desarrollo de
aplicaciones empresariales.
A travs del referido sistema, los estudiantes pueden llevar a cabo las
solicitudes de constancias (constancia de notas, constancia de buena
conducta, constancia de inscripcin, entre otras), retirar materias y a los
profesores les permite hacer reservaciones de salones para sus actividades
acadmicas, adems facilita los procesos que se llevan acabo dentro de
OREFI, as mismo provee las herramientas necesarias para controlar el
trabajo y ayuda a la toma de decisiones sobre los procesos internos y
externos.
A pesar de que la
referida investigacin difiere en relacin a la
metodologa y el modelo aplicado y que estuvo enmarcada en el nivel de

pregrado, es pertinente a la presente investigacin debido a que est basada
en la ingeniera de sistemas.
En este sentido, se tom el enfoque efectuado sobre los procesos
acadmicos para extrapolarlos a los procesos de investigacin para elaborar
el enfoque particular sobre los procesos de investigacin y finalmente poder
realizar la comparacin de resultados.
18
Por otra parte, en la Carrera de Ingeniera de Sistemas de la Pontificia

Universidad Javeriana surgi la necesidad de implementar un sistema de
informacin para la administracin de proyectos de grado que facilite la
administracin de este proceso, fundamental para la culminacin satisfactoria
de la carrera, por ello, Chaparro y Forero (2005, p. 13), realizaron un trabajo
de investigacin para implementar un Sistema de Informacin para
Administracin de Proyectos de Grado el cual basado en el entorno web.
El objetivo del antes referido proyecto fue brindar un sistema de
informacin completo, sencillo y autnomo para la administracin y
mantenimiento de los diferentes proyectos de grado con el propsito de llevar
a cabo el control, seguimiento y gestin de los mismos bajo web, dichas
actividades se hacan de una forma manual almacenando la informacin en
archivos en formato de hoja de clculo.
El anterior estudio es pertinente con la presente investigacin ya que
tambin se enmarc en ingeniera de sistemas. Asimismo, como en el trabajo
de investigacin de Albarracn, el estudio efectuado por Chaparro y Forero
tambin sirvi de referencia para la presente investigacin, ya que se aplic
a sistemas de informacin basado en web implementados en el nivel del
postgrado para el apoyo de las actividades de investigacin.
Reao (2005, pp. 1 2), realiz un diseo de sistema de informacin
documental en plataforma web bajo el concepto de base de informacin que
permita integrar los diversos aspectos de informacin de los diferentes
procesos inherentes al postgrado, a todo lo largo y ancho de su estructura
19
organizativa, donde se incluya el uso de elementos tecnolgicos de punta

para garantizar una mejor utilidad de los recursos por medio de una gestin
dinmica y moderna basada en el uso de tecnologas de informacin.
Se concluy que la utilizacin de tecnologa Web para desarrollar
sistemas de informacin, es una solucin efectiva para el manejo eficiente de
la gestin en la organizacin, manifestndose caractersticas resaltantes en
su aplicacin al medio educativo en mbitos de alta tecnologa, donde el
objetivo de rebasar la fronteras espacio tiempo en pos de difundir el
conocimiento cientfico.
El anterior estudio es pertinente con la presente investigacin ya que, a
pesar de que fue un trabajo de postgrado, se enmarc en ingeniera de
sistemas. Por otra parte, se tomaron las recomendaciones de la misma, para
as aplicarlas en todos los aspectos del diseo del sistema web que se desea
desarrollar en el presente estudio. En tal sentido, se har nfasis primordial
en todos los mdulos a fin de que se centre en las necesidades de los
usuarios y que facilite la toma de decisiones para el coordinador de
investigacin del Posgrado de la UNERMB.
2.
BASES TERICAS
Las definiciones y conceptos que se presentan a continuacin sirven
para orientar los conocimientos relacionados directamente con el proyecto,

todos ellos con el propsito de alcanzar los objetivos planteados a fin de
darles las bases necesarias para el desarrollo del proyecto.
20
2.1. SISTEMAS DE INFORMACIN

En este apartado se hace referencia al estudio documental realizado
sobre la variable de investigacin Sistemas de Informacin, en este sentido
se plasmaron todos los conocimientos recolectados haciendo nfasis en
sistemas de informacin bajo ambiente web.
2.1.1. DEFINICIONES DE SISTEMAS DE INFORMACIN
De acuerdo a Laudon y Laudon (2004, p. 8) un sistema de informacin
se puede definir como un conjunto de componentes interrelacionados que
recolectan (o recuperan), procesan, almacenan y distribuyen informacin
para apoyar la toma de decisiones y el control en una organizacin.
Igualmente, Senn (2003, p. 23), define los Sistemas de Informacin,
como cualquier otro sistema dentro de la organizacin, cuyas funciones son
procesar entradas, mantener archivos de datos relacionados con la
organizacin y producir informacin, reportes y otras salidas.
Por otra parte, Surhone y otros (2010, p. 25) refieren que un sistema
de informacin basado en web es aquel que utiliza tecnologas de Internet
para proporcionar informacin y servicios a los usuarios u otros sistemas de
informacin y aplicaciones. Puede decirse que un sistema de informacin es
una combinacin de tecnologa de informacin y actividades realizadas por
personas para apoyar las operaciones, la gestin y toma de decisiones en
las organizaciones.
21
Entonces, el trmino sistema de informacin se utiliza para referirse a la

interaccin entre las personas, procesos algortmicos, los datos y la
tecnologa con el fin de procesar datos para ser convertidos en informacin
til para los usuarios, especialmente para los procesos de toma de decisin.
2.1.2. CLASIFICACIN DE LOS SISTEMAS DE INFORMACIN
De acuerdo a las anteriores definiciones se estableci que los sistemas
de informacin son una parte ntegra de las organizaciones, en virtud a que
existen una diversidad de las mismas puede inferirse que debe haber
muchos tipos de sistemas de informacin. En este sentido, Ramrez (2005, p.
3) estableci una divisin categrica de los sistemas automatizados:
a) Sistemas en lnea: es aquel que acepta el material de entrada
directamente del rea donde se cre. Tambin es el sistema en que el
material de salida, o resultado de la automatizacin, se devuelve
directamente a donde es requerido.
b) Sistemas de tiempo real: puede definirse como aquel que controla un
ambiente recibiendo datos, procesndolos y devolvindolos con la suficiente
rapidez como para influir en dicho ambiente en ese momento.
c) Sistemas de apoyo a decisiones: estos sistemas informatizados no
toman decisiones por s mismos, sino que ayudan a los profesionales y a
otros tcnicos superiores "trabajadores de la informacin" de una
organizacin a tomar decisiones inteligentes y documentadas acerca de los
diversos aspectos de la operacin.
22
d) Sistemas basados en el conocimiento: estos sistemas contienen

grandes cantidades de distintos conocimientos que emplean en el
desempeo de una tarea dada. Los sistemas expertos son una especie de
sistemas basados en el conocimiento, aunque ambos trminos se utilizan
indistintamente.
2.1.3. COMPONENTES DE LOS SISTEMAS DE INFORMACIN
En este sentido, Capa (2008), refiere que la comunicacin entre estos
componentes est generalmente basada en el principio de peticin y
respuesta. A continuacin se describen brevemente algunos de estos
componentes:
a) Cliente (Client): Generalmente un navegador controlado por un
usuario para operar la aplicacin web. Puede ser mejorado por plugins y
applets.
b) Servidor Cortafuegos (Firewall): Software, hardware o la combinacin
de estos dos para regular la comunicacin entre redes inseguras y redes
seguras mediante reglas de acceso.
c)
Servidor
Proxy:
Usualmente
utilizado
como
sistema
de
almacenamiento temporal para las pginas web. Sin embargo, un proxy

puede asumir otras funcionalidades.
d) Servidor Web (Web Server): Software, hardware o la combinacin de
estos dos, que soportan varios protocolos web para procesar las peticiones
delos clientes.
23
f) Servidor de Base de Datos (Database Server): Mantiene los datos en

una forma estructurada para el uso de la organizacin.
g) Servidor Media (Media Server): Usado para volmenes de contenido
no estructurado.
h) Servidor de Gestin de Contenidos (Content Management Server):
Similar a un servidor de bases de datos, los contenidos almacenados
generalmente provienen en forma de datos semi estructurados en XML.
i) Servidor de Aplicacin (Application Server): Mantiene la funcionalidad
requerida por algunas aplicaciones.
j) Aplicaciones Integradas (Legacy Applications): Son aquellos sistemas
antiguos que deberan ser integrados como un componente interno o
externo. La figura 1 muestra los componentes bsicos de una arquitectura
web.
Figura 1
Componentes Genricos de una arquitectura Web
Fuente: Kappel (2003, p. 93)
24
2.1.4. ENFOQUES DE LOS SISTEMAS DE INFORMACIN

Los enfoques de los sistemas de informacin se refieren a diferentes
escenarios que pueden adoptar segn su diseo funcional y su relacin con
los usuarios finales. De acuerdo a ello los enfoques estn clasificados en
centralizado, independiente y distribuidos, los cuales se definen a
continuacin.
2.1.4.1. ENFOQUE INDEPENDIENTE
Segn Contreras y Galea (2001, p. 13) el enfoque independiente es
aquel donde un grupo de una o ms unidades funcionales estrechamente
vinculadas por factores tales como operaciones comunes, contigidad
geogrfica, datos comunes, entre otros, poseen un computador para realizar
el procesamiento de datos, propio de sus funciones. La integracin de los
diferentes subsistemas as constituidos, se logra por el intercambio de datos
e informacin en forma manual.
2.1.4.2. ENFOQUE CENTRALIZADO
Arribas (2000, p. 2) seala
La centralizacin de los sistemas de informacin tiene la cualidad de
permitir un control ms sencillo, ya que es la mejor forma de captar,
manipular y usar la informacin cuando es necesario que un gran
nmero de usuarios puedan acceder a ella. Otra de sus ventajas es que
evita la inconsistencia de las aplicaciones y de los programas de los
departamentos. Su mximo inconveniente radica en que genera
retrasos y prdidas de tiempo al establecer prioridades entre usuarios, a
la vez que anula la iniciativa individual.
25
En este sentido, puede decirse que este enfoque es el adecuado para

los proyectos que cumplen un objetivo especfico, los usuarios pueden ser
numerosos pero se clasifican en grupos, las necesidades son especficas.
Por ello, se centralizan los recursos para una mejor gestin de los mismos y
las aplicaciones responden a una imagen corporativa o institucional.
2.1.4.3. ENFOQUE DISTRIBUIDO
Arribas (2000, p.2) refiere que el enfoque distribuido (o descentralizado)
permite adaptar las necesidades del usuario, por lo tanto, motiva al usuario,
facilita el reparto de las tareas y multiplica la eficacia de las funciones
directivas. El centro de informacin pasa a tener una funcin consultora. El
gran inconveniente es que la tecnologa no satisface siempre en coste y
calidad a los requerimientos de cada usuario.
Este enfoque responde a sistemas donde los usuarios tienen muchas y
variadas necesidades, por ello, los requerimientos tecnolgicos pueden ser
complejos y los sistemas deben poseer variadas caractersticas para
responder a muchos objetivos.
2.1.5. CICLO DE VIDA DE LOS SISTEMAS DE INFORMACIN
Segn el Instituto de Ingenieros Elctricos y Electrnicos el ciclo de vida
de un sistema de informacin es, una aproximacin lgica a la adquisicin,
el suministro, el desarrollo, la explotacin y el mantenimiento del software
(IEEE 1074-1995. Standard for Developing Software Life Cycle Processes).
26
La Norma ISO 12207:2008 (ISO/IEC 12207:2008. Systems and

software engineering -- Software life cycle processes) establece que el ciclo
de vida de los sistemas de informacin es:
Un marco de referencia que contiene los procesos, las actividades y las
tareas involucradas en el desarrollo, la explotacin y el mantenimiento
de un producto de software, abarcando la vida del sistema desde la
definicin de los requisitos hasta la finalizacin de su uso.
Para Senn (2003, p. 33), el ciclo de vida para el desarrollo de sistemas
es el conjunto de actividades que los analistas, diseadores y usuarios
realizan para desarrollar e implantar un sistema de informacin.
Puede decirse que el ciclo de vida de un sistema de informacin es un
enfoque por fases el cual sostiene que los sistemas son desarrollados
mediante el uso de un ciclo de actividades desarrollados entre analista y el
usuario, el cual inicia en el momento en que el sistema es solicitado al
analista y finaliza cuando es entregado a los usuarios y est en
funcionamiento.
2.1.5.1. MODELO CLSICO O CASCADA
Laudon y Laudon (2004, p. 395) refieren que el modelo clsico del ciclo
de vida de los sistemas de informacin es una metodologa tradicional para
desarrollar un sistema de informacin que divide el proceso de desarrollo de
sistemas en fases formales que deben completarse secuencialmente con
una divisin muy formal de las actividades de los usuarios finales y los
especialistas de sistemas de informacin.
27
Por su parte, Taboada y Cotos (2005, p. 9) refieren que esta estrategia
suele ser utilizada cuando el sistema no es de gran complejidad y puede ser
manejable como proyecto, cuando los requerimientos del sistema pueden
predecirse fcilmente.
En la figura 2 se puede apreciar el modelo Cascada o Clsico del Ciclo
de Vida de los Sistemas de Informacin.
Figura 2
Modelo Clsico o Cascada
Fuente: Taboada y Cotos (2005, p. 9)
En este orden de ideas, Senn (1992, pp. 33 37) seala que el modelo
clsico del ciclo de vida de los sistemas de informacin consta de las
siguientes actividades: investigacin preliminar, determinacin de los
requerimientos del sistema, diseo del sistema, desarrollo de software,
prueba de los sistemas, implantacin y evaluacin.
28
1. Investigacin Preliminar: La solicitud para recibir ayuda de un sistema

de informacin puede originarse por varias razones; sin importar cules sean
stas, el proceso se inicia siempre con la peticin de una persona
(administrador, empleado o especialista en sistemas).
Cuando se formula la solicitud comienza la primera actividad de
sistemas: investigacin preliminar, sta consiste en el estudio que el analista
de sistemas realiza para abordar el contexto en el cual est inmerso el
problema.
2. Determinacin de los requerimientos del sistema: tambin llamada
investigacin detallada, es la que realiza el analista en colaboracin con los
empleados y administradores, con el fin de estudiar los procesos de una
empresa.
3. Diseo del sistema: en esta actividad se produce los detalles que
establecen la forma en la que el sistema cumplir con los requerimientos
identificados durante la fase de anlisis. Los analistas refieren a esta etapa
como diseo lgico.
4. Desarrollo de Software. En esta actividad los encargados de
desarrollar software pueden instalar (o modificar y despus instalar) software
comprado a terceros o escribir programas diseados a la medida del
solicitante. La documentacin en esta actividad es fundamental.
5. Prueba de los Sistemas: Esta actividad consiste en emplear el
sistema de manera experimental para asegurarse de que el software no
tenga fallas, es decir, que funciona de acuerdo con las especificaciones.
29
6. Implantacin y Evaluacin: La implantacin es el proceso de verificar

e instalar nuevo equipo, entrenar a los usuarios, instalar la aplicacin y
construir todos los archivos de datos necesarios para utilizarla. La evaluacin
de un sistema se lleva a cabo para identificar puntos dbiles y fuertes, la
evaluacin puede ser:
a) Operacional (funcionamiento del sistema).
b) Organizacional (beneficios para la organizacin).
c) Opinin de los administradores (actitudes de los directivos y
administradores).
d) Desempeo del desarrollo.
2.1.5.2. MODELO DE ANLISIS ESTRUCTURADO
Senn (1992, pp. 33 37), al referirse sobre el anlisis estructurado,
seala que:
El anlisis estructurado se concentra en especificar lo que se requiere
que haga el sistema o la aplicacin. No se establece cmo se cumplirn
los requerimientos o la forma en que se implantar la aplicacin, mas
bien permite que las personas observen los elementos lgicos (lo que
har el sistema) separados de los componentes fsicos (computadoras,
terminales, sistemas de almacenamiento, entre otros).
Por su parte, Taboada y Cotos (2005, p. 12) coinciden al referir que
este modelo se vale de la notacin grfica para desarrollar las
especificaciones del sistema, para ello su herramienta principal es el
diagrama estructurado.
En la figura 3 se puede apreciar un ejemplo de este modelo.
30
Figura 3
Ejemplo del Modelo de Anlisis Estructurado
Fuente: Taboada y Cotos (2005, p. 12)
Se infiere que este modelo se concentra en especificar lo que se
requiere que haga el sistema, permitiendo que las personas observen los
elementos lgicos (lo que har el sistema) separados de los componentes
fsicos.
2.1.5.3. MODELO EN ESPIRAL
Sobre el modelo en espiral, Alonso y otros (2005, p. 112) refieren que
Barry Boehm lo ide en 1988, diferencindolo del modelo en cascada en
cuanto a que evoluciona a travs de ciclos de experimentacin y aprendizaje,
incorporando un nuevo elemento en el desarrollo de software como lo es el
anlisis de riesgos. Este modelo define cuatro actividades principales
representadas por los cuatro cuadrantes de la figura 4:
31
a) Planificacin: Determinar objetivos, alternativas y restricciones.

b) Anlisis de riesgo: Evaluar alternativas, identificar y resolver riesgos.
c) Ingeniera: Desarrollar y verificar el producto del siguiente nivel.
d) Evaluacin del cliente: Planificar las fases siguientes.
Figura 4
Modelo de Desarrollo en Espiral
Fuente: FernndezMedina (2006, p. 13) http://alarcos.inf-cr.uclm.es
Sobre las ventajas del modelo en espiral, FernndezMedina (2006, p.
25) seala:
a) Trata de mejorar los ciclos de vida clsicos y prototipos.
b) Permite acomodar otros modelos.
c) Incorpora objetivos de calidad y gestin de riesgos.
d) Elimina errores y alternativas no atractivas al comienzo.
32
e) Permite iteraciones, vuelta atrs y finalizaciones rpidas.

f) Cada ciclo empieza identificando: Los objetivos de la porcin
correspondiente, Las alternativas, Restricciones.
g) Cada ciclo se completa con una revisin que incluye todo el ciclo
anterior y el plan para el siguiente.
Puede observarse que el modelo de desarrollo en espiral no es una
alternativa del modelo de cascada, ambos son completamente compatibles,
se puede decir entonces que el modelo de desarrollo en espiral se aplica
cuando se desea realizar nuevas adaptaciones o mejoras al sistema,
aplicando el modelo en cascada iterativamente.
2.1.5.4. MODELO DE DESARROLLO INCREMENTAL
Este modelo surge como una forma de reducir la repeticin del trabajo
en el proceso de desarrollo y dar oportunidad de retrasar la toma de
decisiones en los requisitos hasta adquirir experiencia con el sistema.
Entre las ventajas del modelo de desarrollo incremental, Fernndez
Medina (2006, p. 15), refiere:
a) Se evitan proyectos largos y se entrega a los usuarios con cierta
frecuencia.
b) El usuario se involucra ms.
c) Difcil de evaluar el coste total.
d) Difcil de aplicar a sistemas transaccionales que tienden a ser
integrados y a operar como un todo.
33
e) Requiere gestores experimentados.

f) Los errores en los requisitos se detectan tarde.
g) El resultado puede ser muy positivo.
A continuacin en la figura 5 se muestra el modelo incremental
Figura 5
Modelo de Desarrollo Incremental
Fuente: FernndezMedina (2006, p. 20)
El modelo de desarrollo incremental es 100% compatible con el modelo
cascada ya que no demanda una forma especfica de observar el desarrollo
de algn otro incremento, As, el modelo cascada puede ser usado para
administrar cada esfuerzo de desarrollo.
34
2.1.5.5. MODELO DE PROTOTIPADO RPIDO

Laudon y Laudon (2004, p. 395) refieren que la creacin de prototipos
consiste en construir rpida y econmicamente un sistema experimental para
que lo evalen los usuarios finales, interactuando con el prototipo, los
usuarios pueden darse una mejor idea de sus requerimientos de
informacin.
Figura 6
Modelo de Prototipado Rpido
Entre las ventajas del modelo de prototipo rpido que se muestra en la
figura 6, FernndezMedina (2006, p. 18), estn:
35
a) No modifica el flujo del ciclo de vida.

b) Reduce el riesgo de construir productos que no
satisfagan las
necesidades de los usuarios.

c) Reduce costos y aumenta la probabilidad de xito.
d) Exige disponer de las herramientas adecuadas.
e) No presenta calidad ni robustez.
g) Una vez identificados todos los requisitos mediante el prototipo, se
construye el producto de ingeniera.
Sin embargo, Fernndez Medina (2006, p. 20), advierte:
a) El cliente ve funcionando lo que para el es la primera versin del
prototipo que ha sido construido con plastilina y alambres, y puede
desilusionarse al decirle que el sistema aun no ha sido construido.
b) El desarrollador puede caer en la tentacin de ampliar el prototipo
para construir el sistema final sin tener en cuenta los compromisos de calidad
y de mantenimiento que tiene con el cliente.
Se infiere que para este modelo la ventaja se debe conocer
exactamente y concretamente lo que se quiere, siendo sencillo de construir
un prototipo que identifique en forma casi completa los requisitos del
proyecto minimizando el riesgo de construir un producto no satisfactorio.
2.1.5.6. MODELO DE PROTOTIPADO EVOLUTIVO
Segn Gmez De Silva (2008 p. 368), el modelo de prototipado
evolutivo:
36
Es una extensin al modelo incremental en la que los incrementos se

hacen de manera secuencial, en lugar de en paralelo. Desde el punto
de vista del cliente, el sistema evoluciona segn vayan entregados los
incrementos, desde el punto de vista del desarrollador, los
requerimientos que son claros al principio del proyecto dictan el
incremento inicial, mientras que los incrementos para cada uno de los
siguientes ciclos de desarrollo se clarifican a travs de la experiencia de
los incrementos anteriores.
Fernndez Medina (2006, p. 21), refiere que en este modelo, la
construccin de una implementacin parcial que cubre los requisitos
conocidos, para ir aprendiendo el resto y, paulatinamente, incorporarlos al
sistema, reduciendo el riesgo y aumentando la probabilidad de xito. Sin
embargo, en la aplicacin de este modelo, no se conocen niveles apropiados
de calidad y documentacin lo que puede traer problemas de gestin de
configuracin. En la figura 7 se puede apreciar grficamente este modelo.
Figura 7
Modelo de Prototipado Evolutivo
37
El punto de vista evolutivo del ciclo de vida del software, el modelo de

prototipado evolutivo considera a la primera entrega como un prototipo inicial
en el campo, modificaciones y mejoras subsecuentes resultan en nuevas
entregas de prototipos ms maduros, este proceso contina hasta que se
haya desarrollado el producto final.
Para la presente investigacin se seleccion el modelo de prototipado
evolutivo ya que se adapta al contexto de estudio en el que los usuarios
participan en el desarrollo del proyecto y van aportando nuevos requisitos en
el transcurso del mismo. Por otro lado, el mtodo desarrollo rpido de
aplicaciones (RAD) es una variacin del prototipado evolutivo (Ortiz, 2004, p.
7), el cual ser presentado ms adelante durante el desarrollo terico.
2.1.6. ARQUITECTURA DE SOFTWARE
La Arquitectura del Software es la organizacin fundamental de un
sistema formada por sus componentes, las relaciones entre ellos y el
contexto en el que se implantarn, y los principios que orientan su diseo y
evolucin (IEEE 1471-2000. Recommended Practice for Architectural
Description for Software-Intensive Systems).
Se puede decir que la Arquitectura de Software, sistematiza todos los
elementos de un sistema de informacin y sus interrelaciones para conformar
un marco en el que se desenvuelve el sistema. La Arquitectura del Software
aporta una visin abstracta de alto nivel, posponiendo el detalle de cada uno
de los mdulos definidos a pasos posteriores del diseo.
38
De acuerdo a Booch y otros (2000), la arquitectura de software

orientada a objetos bien estructurada est llena de patrones. La calidad de
un sistema orientado a objetos se mide por la atencin que los diseadores
han prestado a las colaboraciones entre sus objetos. Los patrones conducen
a arquitecturas ms pequeas, ms simples y ms comprensibles
2.1.6.1. EL PATRN DE DISEO MODELO VISTA CONTROLADOR
Bascon (2004, p. 493) refiere que durante el proceso del aprendizaje,
los programadores han desarrollado el hbito natural de solucionar los
problemas en largas, desordenadas, incomprensibles y enormes cantidades
de cdigo que mezclan algoritmos, mensajes al usuario, combinaciones de
colores, iconos animados, grficos de barras y otras cosas ms que hacen
de ese cdigo difcil de leer, de comprender y ser modificado.
Se puede decir tambin que otro origen del problema son las
herramientas de desarrollo rpido de aplicaciones (RAD) como Delphi, Visual
Basic y los lenguajes de scripting de desarrollo de aplicaciones web (ASP,
JSP o PHP) que contribuyen a crear esa clase de aplicaciones muy fciles de
implementar, pero muy desorganizadas y difciles de comprender y modificar.
El patrn de diseo Modelo Vista Controlador, plantea un mtodo
formal para separar los mdulos de entrada, de procesamiento y de salida de
datos en una aplicacin y la forma de comunicacin entre dichos mdulos. A
continuacin se presenta la referencia documental sobre el patrn de diseo
Modelo Vista Controlador.
39
A) DEFINICIONES
El Modelo Vista Controlador (MVC) fue creado por Trygve
Reenskaug en 1978, en su sitio web http://heim.ifi.uio.no/~trygver, el autor
destaca El propsito esencial de MVC es cerrar la brecha entre el modelo
mental del usuario humano y el modelo digital que existe en el equipo. La
solucin ideal MVC soporta la ilusin del usuario de ver y manipular la
informacin directamente. La estructura es til si el usuario necesita para ver
el elemento mismo modelo al mismo tiempo en diferentes contextos y / o de
puntos de vista diferentes. La figura 8 ilustra la idea:
Figura 8
El patrn de diseo Modelo Vista Controlador
Fuente: http://heim.ifi.uio.no/~trygver
Por su parte, Rivera (2008, p. 11), refiere que el MVC es un patrn de
diseo de arquitectura de software usado principalmente en aplicaciones que
manejan gran cantidad de datos y transacciones complejas donde se
requiere una separacin de conceptos para que el desarrollo est
estructurado de una mejor manera, facilitando la programacin en diferentes
capas de manera paralela e independiente.
40
continuacin,
Reenskaug,
en
su
pagina
web
personal
http://heim.ifi.uio.no/~trygver, define cada uno de los componentes del MVC:

El Modelo: representa el conocimiento. Un modelo podra ser un nico
objeto, o podra ser algn tipo de estructura de los objetos. La
implementacin del mismo se apoya el conocimiento representado en algo
parecido a las redes semnticas. Debe haber una correspondencia uno-auno entre el modelo y sus partes, por un lado, y el mundo representado tal y
como es percibido por el propietario del modelo por otro lado. Los nodos de
un modelo, por tanto, representan una parte identificable del problema.
La Vista: es una representacin visual de su modelo. Es normalmente
resaltar ciertos atributos del modelo y suprimir otros, por lo tanto, acta como
un filtro de presentacin. Una vista se une a su modelo (o parte del modelo) y
obtiene los datos necesarios para la presentacin del modelo haciendo
preguntas. Tambin puede actualizar el modelo mediante el envo de
mensajes apropiados. Todas estas preguntas y los mensajes tienen que
estar en la terminologa del modelo, la vista por lo tanto, tiene que saber la
semntica de los atributos del modelo que representa. Se puede, por
ejemplo, pedir el modelo de identificador y espera una instancia de texto, no
puede asumir que el modelo es de la clase de texto.
El Controlador: es el vnculo entre el usuario y el sistema. Se ofrece al
usuario la entrada por la organizacin vistas relevantes para presentarse en
los lugares apropiados en la pantalla. Proporciona los medios para la salida
de usuario presentando al usuario con mens u otros medios mediante
41
rdenes. El controlador recibe la salida de dicho usuario, lo traduce a los

mensajes apropiados y pasar estos mensajes a una o ms vistas.
Un controlador no debe complementar las vistas, nunca se debe, por
ejemplo, conectar las vistas dibujando flechas entre ellos. Por el contrario, la
vista nunca debe saber acerca de la entrada del usuario, tales como las
operaciones del ratn y las pulsaciones de teclado. Siempre debe ser posible
escribir un mtodo en un controlador que enva mensajes a las vistas que
precisamente reproducen cualquier secuencia de comandos de usuario.
B) CICLO DE VIDA DE LAS APLICACIONES BASADAS MVC
Durante la ejecucin de cualquier aplicacin basada en el patrn de
diseo MVC se produce una interaccin entre los componentes de la
aplicacin (Controlador Modelo Vista) y el usuario, tal y como se observa
en la figura 9:
Figura 9
Ciclo de Vida del MVC
Fuente: Rivera (2008, p. 12)
42
En este sentido, Rivera (2008, pp. 12 - 13) refiere que el ciclo de vida
de las aplicaciones basadas en el patrn de diseo MVC empieza cuando el
usuario hace una solicitud al controlador, entonces el controlador decide a
quin debe delegar la tarea y es aqu donde el modelo comienza su trabajo,
encargndose de realizar las operaciones sobre la informacin que maneja
para cumplir con lo que le solicita el controlador.
Una vez terminada su labor, el modelo le regresa al controlador la
informacin resultante de sus operaciones, el cual a su vez la redirige a la
vista, quien se encargar de transformar los datos en informacin entendible
para el usuario. Finalmente, la representacin grfica es transmitida de
regreso al controlador y ste se encarga de transmitrsela al usuario.
C) VENTAJAS Y DESVENTAJAS DEL PATRN DE DISEO MVC
De acuerdo a Rivera (2008, p. 13), se destacan como ventajas del
patrn de diseo Modelo - Vista - Controlador las siguientes:
a) La separacin de los datos de la representacin visual de los mismos
b) Es mucho ms sencillo agregar mltiples representaciones de los
mismos datos o informacin.
c) Facilita agregar nuevos tipos segn sea requerido por la aplicacin
ya que son independientes del funcionamiento de las otras capas
d) Crea independencia de funcionamiento.
e) Facilita el mantenimiento en caso de errores.
f) Ofrece maneras ms sencillas para probar el correcto funcionamiento
del sistema.
43
g) Permite el escalamiento de la aplicacin en caso de ser requerido

Por otra parte, el antes referido autor seala como desventajas:
a) La separacin de conceptos en capas agrega complejidad al sistema
b) La cantidad de archivos a mantener y desarrollar se incrementa
considerablemente
c) La curva de aprendizaje del patrn de diseo es ms alta que usando
otros modelos ms sencillos
Por ltimo, Rivera (2008, pp. 13 - 14), aclara que la comparacin de
ventajas y desventajas de MVC puede ser un tema muy subjetivo y se puede
prestar como tema de debate, sin embargo, en trminos generales, la
balanza se inclina a favor del patrn de diseo MVC en vez de en su contra.
2.1.6.2. LOS FRAMEWORKS
Un framework simplifica el desarrollo de una aplicacin mediante la
automatizacin de algunos de los patrones utilizados para resolver las tareas
comunes. Adems, un framework proporciona estructura al cdigo fuente,
forzando al desarrollador a crear cdigo ms legible y ms fcil de mantener.
Por ltimo, un framework facilita la programacin de aplicaciones, ya que
encapsula operaciones complejas en instrucciones sencillas (Potencier,
2008, p. 13).
Los frameworks ayudan en el desarrollo de software, proporcionan una
estructura definida la cual ayuda a crear aplicaciones con mayor rapidez.
Ayuda a la hora de realizar el mantenimiento del sitio gracias a la
44
organizacin durante el desarrollo de la aplicacin. Los Frameworks son

desarrollados con el objetivo de brindarles a los programadores y
diseadores una mejor organizacin y estructura a sus proyectos. Se utiliza
la Programacin Orientada a Objetos (POO), permitiendo la reutilizacin del
cdigo (Valdez, 2007, p. 1).
2.1.6.3. EL FRAMEWORK DE DESARROLLO SYMFONYPHP
Potencier (2008, p. 13) refiere que Symfony es un completo framework
diseado para optimizar, gracias a sus caractersticas, el desarrollo de las
aplicaciones web, separa la lgica de negocio, la lgica de servidor y la
presentacin de la aplicacin web. Proporciona varias herramientas y clases
encaminadas a reducir el tiempo de desarrollo de una aplicacin web
compleja, adems, automatiza las tareas ms comunes, permitiendo al
desarrollador dedicarse por completo a los aspectos especficos de cada
aplicacin. El resultado de todas estas ventajas es que no se debe reinventar
la rueda.
Asimismo, Potencier (2008, pp. 13 14), seala que Symfony est
desarrollado completamente con PHP 5. Ha sido probado en numerosos
proyectos reales y se utiliza en sitios web de comercio electrnico de primer
nivel. Symfony es compatible con la mayora de gestores de bases de datos,
como MySQL, PostgreSQL, Oracle y SQL Server de Microsoft. Se puede
ejecutar tanto en plataformas *nix (Unix, Linux, entre otros) como en
plataformas Windows.
45
A) CARACTERSTICAS
A continuacin se muestran algunas de sus caractersticas:
a) Fcil de instalar y configurar en la mayora de plataformas (con la
garanta de que funciona en los sistemas Windows y *nix estndares).
b) Independiente del sistema gestor de bases de datos.
c) Sencillo de usar en la mayora de casos, pero lo suficientemente
flexible como para adaptarse a los casos ms complejos.
d) Basado en la premisa de convenir en vez de configurar, en la que el
desarrollador solo debe configurar aquello que no es convencional.
e) Sigue la mayora de mejores prcticas y patrones de diseo para la
web.
f) Preparado para aplicaciones empresariales y adaptable a las polticas
y arquitecturas propias de cada empresa, adems de ser lo suficientemente
estable como para desarrollar aplicaciones a largo plazo.
g) Cdigo fcil de leer que incluye comentarios de phpDocumentor y
que permite un mantenimiento muy sencillo.
h) Fcil de extender, lo que permite su integracin con libreras
desarrolladas por terceros.
Potencier (2008, p. 14) tambin refiere que Symfony automatiza la
mayora de elementos comunes de los proyectos web, como por ejemplo:
a) La capa de internacionalizacin que incluye Symfony permite la
traduccin de los datos y de la interfaz, as como la adaptacin local de los
contenidos.
46
b) La capa de presentacin utiliza plantillas y layouts que pueden ser

creados por diseadores HTML sin ningn tipo de conocimiento del
framework. Los helpers incluidos permiten minimizar el cdigo utilizado en la
presentacin, ya que encapsulan grandes bloques de cdigo en llamadas
simples a funciones.
c)
Los formularios incluyen
validacin
automatizada
y relleno
automtico de datos (repopulation), lo que asegura la obtencin de datos

correctos y mejora la experiencia de usuario.
d) Los datos incluyen mecanismos de escape que permiten una mejor
proteccin contra los ataques producidos por datos corruptos.
e) La gestin de la cach reduce el ancho de banda utilizado y la carga
del servidor.
f) La autenticacin y la gestin de credenciales simplifican la creacin
de secciones restringidas y la gestin de la seguridad de usuario.
g) El sistema de enrutamiento y las URL limpias permiten considerar a
las direcciones de las pginas como parte de la interfaz, adems de estar
optimizadas para los buscadores.
Continuando con sus caractersticas, Potencier (2008, pp. 15 16)
refiere que Symfony puede ser personalizado para cumplir con los requisitos
de las empresas que disponen de polticas y reglas para la gestin de
proyectos y la programacin de aplicaciones. Por defecto incorpora varios
entornos de desarrollo diferentes e incluye varias herramientas que permiten
automatizar las tareas ms comunes de la ingeniera del software:
47
a) Las herramientas que generan automticamente cdigo han sido

diseadas para hacer prototipos de aplicaciones y para crear fcilmente la
parte de gestin de las aplicaciones.
b) El framework de desarrollo de pruebas unitarias y funcionales
proporciona las herramientas ideales para el desarrollo basado en pruebas
(test-driven development).
c) La barra de depuracin web simplifica la depuracin de las
aplicaciones, ya que muestra toda la informacin que los programadores
necesitan sobre la pgina en la que estn trabajando.
d) La interfaz de lnea de comandos automatiza la instalacin de las
aplicaciones entre servidores.
e) Es posible realizar cambios en caliente de la configuracin (sin
necesidad de reiniciar el servidor).
f) El completo sistema de log permite a los administradores acceder
hasta el ltimo detalle de las actividades que realiza la aplicacin.
B) IMPLEMENTACIN DE MVC EN SYMFONY
De acuerdo a Potencier (2008, pp. 32 - 33), para desarrollar una
aplicacin en Symfony, son necesarios los siguientes componentes
relacionados con el patrn de diseo Modelo Vista Controlador:
a) En la capa del Modelo: Abstraccin de la base de datos, Acceso a los
datos.
b) La capa de la Vista: Vista, Plantilla, Layout.
c) En la capa del Controlador: Controlador frontal, Accin.
48
En la figura 11 se presenta la implementacin que realiza Symfony con

el patrn de diseo MVC.
Figura 10
Implementacin de MVC en Symfony
Fuente: Potencier (2008, p. 33)
C) ESTRUCTURA DE LOS ARCHIVOS
Potencier (2008, p. 37) refiere que normalmente, todos los proyectos
web comparten el mismo tipo de contenidos, como por ejemplo:
a) Una base de datos, como MySQL, Oracle o PostgreSQL.
b) Archivo estticos (HTML, imgenes, archivos de JavaScript, hojas de
estilos, entre otros).
c) Archivos subidos al sitio web.
49
d) Clases y libreras PHP.

e) Libreras externas (scripts desarrollados por terceros).
f) Archivos que se ejecutan por lotes (batch files) que normalmente son
scripts que se ejecutan va lnea de comandos o mediante cron.
g) Archivos de log (las bitcoras generadas por las aplicaciones y/o el
servidor).
h) Archivos de configuracin.
Symfony proporciona una estructura en forma de rbol de archivos para
organizar de forma lgica todos esos contenidos, adems de ser consistente
con la arquitectura MVC utilizada y con la agrupacin proyecto / aplicacin /
mdulo. Cada vez que se crea un nuevo proyecto, aplicacin o mdulo, se
genera de forma automtica la parte correspondiente de esa estructura.
Adems, la estructura se puede personalizar completamente, para
reorganizar los archivos y directorios o para cumplir con las exigencias de
organizacin de un cliente.
La raz de los proyectos en Symfony contiene los siguientes directorios
(ver cuadro 1):
apps/
frontend/
backend/
batch/
cache/
config/
data/
sql/
doc/
lib/
model/
50
log/
plugins/
test/
unit/
functional/
web/
css/
images/
js/
uploads/
Cuadro 1
Estructura del Directorio Raz de los Proyectos en Symfony
Directorio Descripcin
apps/
Contiene un directorio por cada aplicacin del proyecto (normalmente,

frontend y backend para la parte pblica y la parte de administrativa
respectivamente)
batch/
Contiene los scripts de PHP que se ejecutan mediante la lnea de

comandos o mediante la programacin de tareas para realizar
procesos en lotes (batch processes)
cache/
Contiene la versin cacheada de la configuracin y (si est activada) la

versin cacheada de las acciones y plantillas del proyecto. El
mecanismo de cache utiliza los archivos de este directorio para
acelerar la respuesta a las peticiones web. Cada aplicacin contiene un
subdirectorio que guarda todos los archivos PHP y HTML
preprocesados
config/
Almacena la configuracin general del proyecto
data/
En este directorio se almacenan los archivos relacionados con los

datos, como por ejemplo el esquema de una base de datos, el archivo
que contiene las instrucciones SQL para crear las tablas
doc/
Contiene la documentacin del proyecto, formada por tus propios

documentos y por la documentacin generada por PHPdoc
lib/
Almacena las clases y libreras externas. Se suele guardar todo el

cdigo comn a todas las aplicaciones del proyecto. El subdirectorio
model/ guarda el modelo de objetos del proyecto
log/
Guarda todos los archivos de log generados por Symfony. Tambin se

puede utilizar para guardar los logs del servidor web, de la base de
datos o de cualquier otro componente del proyecto. Symfony crea un
archivo de log por cada aplicacin y por cada entorno
Fuente: Potencier (2008, pp. 37 38)
51
Todas las aplicaciones de Symfony tienen la misma estructura de

archivos y directorios (ver cuadro 2):
apps/
[nombre aplicacion]/
config/
i18n/
lib/
modules/
templates/
layout.php
error.php
error.txt
Cuadro 2
Estructura del Subdirectorio de las aplicaciones en Symfony
config/
Contiene un montn de archivos de configuracin creados con YAML.

Aqu se almacena la mayor parte de la configuracin de la aplicacin,
salvo los parmetros propios del framework. Tambin es posible
redefinir en este directorio los parmetros por defecto si es necesario.
i18n/
Contiene todos los archivos utilizados para la internacionalizacin de la

aplicacin, sobre todo los archivos que traducen la interfaz. La
internacionalizacin tambin se puede realizar con una base de datos,
en cuyo caso este directorio no se utilizara
lib/
Contiene las clases y libreras utilizadas exclusivamente por la

aplicacin
modules/
Almacena los mdulos que definen las caractersticas de la aplicacin
templates/
Contiene las plantillas globales de la aplicacin, es decir, las que

utilizan todos los mdulos. Por defecto contiene un archivo llamado
layout.php, que es el layout principal con el que se muestran las
plantillas de los mdulos

Cada aplicacin contiene uno o ms mdulos. Cada mdulo tiene su
propio subdirectorio dentro del directorio modules y el nombre del directorio
es el que se elige durante la creacin del mdulo.
52
A continuacin se muestra la estructura de directorios tpica de un

mdulo (ver cuadro 3):
apps/
[nombre aplicacion]/
modules/
[nombre modulo]/
actions/
actions.class.php
config/
lib/
templates/
indexSuccess.php
validate/
Cuadro 3
Estructura del Subdirectorio de los mdulos en Symfony
actions/
Normalmente contiene un nico archivo llamado actions.class.php y

que corresponde a la clase que almacena todas las acciones del
mdulo. Tambin es posible crear un archivo diferente para cada
accin del mdulo
config/
Puede contener archivos de configuracin adicionales con parmetros

exclusivos del mdulo
lib/
Almacena las clases y libreras utilizadas exclusivamente por el mdulo
templates/
Contiene las plantillas correspondientes a las acciones del mdulo.

Cuando se crea un nuevo mdulo, automticamente se crea la plantilla
llamada indexSuccess.php
validate/
Contiene archivos de configuracin relacionados con la validacin de

formularios

Finalizando la descripcin de los directorios, Potencier (2008, p. 40)
refiere que existen pocas restricciones sobre la estructura del directorio web,
que es el directorio que contiene los archivos que se pueden acceder de
forma pblica. Si se utilizan algunas convenciones bsicas en los nombres
53
de los subdirectorios, se pueden simplificar las plantillas.

La siguiente es una estructura tpica del directorio web (ver cuadro 4):
web/
css/
images/
js/
uploads/
Cuadro 4
Estructura del directorio web en Symfony
css/
Contiene los archivos de hojas de estilo creados con CSS (archivos

con extensin .css)
images/
Contiene las imgenes del sitio con formato .jpg, .png o .gif
js/
Contiene los archivos de JavaScript con extensin .js
uploads/
Se almacenan los archivos subidos por los usuarios. Aunque

normalmente este directorio contiene imgenes, no se debe confundir
con el directorio que almacena las imgenes del sitio (images/). Esta
distincin permite sincronizar los servidores de desarrollo y de
produccin sin afectar a las imgenes subidas por los usuarios

C) El ORM
Potencier (2008, pp. 150 - 151) refiere que las bases de datos son
relacionales, PHP 5 y Symfony estn orientados a objetos, para acceder de
forma efectiva a la base de datos desde un contexto orientado a objetos es
necesaria una interfaz que traduzca la lgica de los objetos a la lgica
relacional, esta interfaz se llama ORM (object-relational mapping) o "mapeo
de objetos a bases de datos", y est formada por objetos que permiten
acceder a los datos y que contienen en s mismos el cdigo para hacerlo.
54
Un ORM o (Object Relation Mapper) es una tcnica de programacin

que nos permite convertir datos entre el sistema de tipos utilizado en un
lenguaje de programacin orientado a objetos y el utilizado en una base de
datos relacional, es decir, las tablas de nuestra base de datos pasan a ser
clases y los registros objetos que podemos manejar con facilidad.
(http://www.tecnoretales.com)
Figura 11
Object Relation Mapper
Fuente: http://www.tecnoretales.com
En este orden de ideas, el autor refiere que la principal ventaja que
aporta el ORM es la reutilizacin, permitiendo llamar a los mtodos de un
objeto de datos desde varias partes de la aplicacin e incluso desde
diferentes aplicaciones. La capa ORM tambin encapsula la lgica de los
55
datos; como por ejemplo, el clculo de la puntuacin de un usuario de un foro

en funcin de las aportaciones que ha realizado al foro y en funcin del xito
de esas aportaciones. Cuando una pgina quiere mostrar esa puntuacin de
un usuario, simplemente invoca un mtodo del modelo de datos, sin
preocuparse de cmo se realiza el clculo. Si el mtodo de clculo sufre
alguna variacin, solo es necesario modificar el mtodo que calcula la
puntuacin en el modelo, sin necesidad de modificar el resto de la aplicacin.
Symfony puede trabajar con el formato nativo de los esquemas en
Propel que est basado en XML y Doctrine que est basado en YAML.
Propel es un Object-Relational Mapping (ORM) basada en cdigo
abierto (Open Source) para PHP5. Le permite acceder a la base de datos
utilizando un conjunto de objetos, proporcionando una API sencilla para
almacenar y recuperar datos, brindando al desarrollador de aplicaciones
web, las herramientas para trabajar con bases de datos de la misma manera
se trabaja con otras clases y objetos en PHP.(http://www.propelorm.org/)
Doctrine es un ORM para PHP 5.2.3 y posterior. Adems de todas las
ventajas que conlleva un ORM, uno de sus puntos fuertes es su lenguaje
DQL (Doctrine Query Language) inspirado en el HQL de Hibernate. Cuando
se trabaja con Doctrine, solo se necesita informar al motor interno de cual es
el modelo de nuestra aplicacin, para ello se hace una ingeniera inversa de
la base de datos existente, o si se empieza la aplicacin desde 0, crear el
modelo en la sintaxis especfica que propone Doctrine y luego generar toda
la base de datos. (http://www.doctrine-project.org/)
56
D) LOS OBJETOS EN SYMFONY

La utilizacin de objetos en vez de registros y de clases, en vez de
tablas, tiene otra ventaja: permite aadir mtodos accesores en los objetos
que no tienen relacin directa con una tabla. Si se dispone por ejemplo de
una tabla llamada cliente con dos campos llamados nombre y apellidos,
puede que se necesite un dato llamado NombreCompleto que incluya y
combine el nombre y los apellidos. En el mundo orientado a objetos, es tan
fcil como aadir un mtodo accesor a la clase Cliente, el siguiente cdigo
muestra como aplicar el mtodo accesor para obtener el nombre completo de
un cliente:
public function getNombreCompleto()
{
return $this->getNombre().' '.$this->getApellidos();
}
Desde el punto de vista de la aplicacin, no existen diferencias entre los

atributos Nombre, Apellidos, NombreCompleto de la clase Cliente. Solo la
propia clase es capaz de determinar si un atributo determinado se
corresponde con una columna de la base de datos.
Todo el cdigo repetitivo de acceso a los datos y toda la lgica de
negocio de los propios datos se puede almacenar en esos objetos. Imagina
que se ha definido la clase CarritoCompra en la que se almacenan Productos
(que son objetos). Para obtener el precio total del carrito de la compra antes
de realizar el pago, se puede crear un mtodo que encapsula el proceso de
clculo, tal y como se muestra en el siguiente cdigo:
57
public function getTotal()

{
$total = 0;
foreach ($this->getProductos() as $producto)
{
$total += $producto->getPrecio() * $producto->getCantidad();
}
return $total;
}
Existe otra consideracin importante que hay que tener en cuenta

cuando se crean elementos de acceso a los datos: las empresas que crean
las bases de datos utilizan variantes diferentes del lenguaje SQL. Si se
cambia a otro sistema gestor de bases de datos, es necesario reescribir parte
de las consultas SQL que se definieron para el sistema anterior. Si se crean
las consultas mediante una sintaxis independiente de la base de datos y un
componente externo se encarga de traducirlas al lenguaje SQL concreto de
la base de datos, se puede cambiar fcilmente de una base de datos a otra.
Este es precisamente el objetivo de las capas de abstraccin de bases de
datos. Esta capa obliga a utilizar una sintaxis especfica para las consultas y
a cambio realiza el trabajo sucio de optimizar y adaptar el lenguaje SQL a la
base de datos concreta que se est utilizando.
La principal ventaja de la capa de abstraccin es la portabilidad, porque
hace posible el cambiar la aplicacin a otra base de datos, incluso en mitad
del desarrollo de un proyecto. Si se debe desarrollar rpidamente un
prototipo de una aplicacin y el cliente no ha decidido todava la base de
datos que mejor se ajusta a sus necesidades, se puede construir la
58
aplicacin utilizando SQLite y cuando el cliente haya tomado la decisin,

cambiar fcilmente a MySQL, PostgreSQL u Oracle. Solamente es necesario
cambiar una lnea en un archivo de configuracin y todo funciona
correctamente.
E) LOS ENTORNOS DE LAS APLICACIONES EN SYMFONY
Potencier (2008, p. 51) refiere que en el directorio web/, se encuentran
dos archivos PHP: index.php y frontend_dev.php. Estos archivos son
llamados controladores frontales: las peticiones a la aplicacin se hacen a
travs de ellos. Ambos archivos apuntan a la misma aplicacin pero para
distintos entornos:
a) El entorno de desarrollo: Este es el ambiente utilizado por
desarrolladores web para aadir nuevas funciones, corregir los errores.
b) El entorno de prueba: Este entorno se utiliza para probar
automticamente la aplicacin.
c) El entorno staging: Este entorno es utilizado por el cliente para poner
a prueba la aplicacin e informar errores o caractersticas faltantes.
d) El entorno de produccin: Este es el entorno donde un usuario final
interacta.
En este orden de ideas, en el entorno de desarrollo, la aplicacin
necesita registrar todos los detalles de una peticin para facilitar la
depuracin, debe mostrar la excepcin en el navegador, pero la cache debe
ser deshabilitada para que todos los cambios realizados al cdigo se tengan
en cuenta de inmediato:
59
Figura 12
Una excepcin en el entorno de desarrollo
En el entorno de la produccin, la aplicacin deber mostrar mensajes
de error personalizados en lugar de excepciones, y por supuesto, la capa del
cache debe estar activada. El entorno de produccin debe ser optimizado
para el rendimiento y la experiencia del usuario final:
Figura 13
Una excepcin en el entorno de produccin
60
Al abrir los archivos de los controladores frontales, se puede observar

que la nica diferencia es el ajuste del entorno:
// web/index.php
<?php
require_once(dirname(__FILE__).'/../config/ProjectConfiguration.class.p
hp');
$configuration =
ProjectConfiguration::getApplicationConfiguration('frontend', 'prod',
false);
sfContext::createInstance($configuration)->dispatch();
Una vez creado el proyecto y sus aplicaciones se puede acceder a la

aplicacin en el entorno de desarrollo desde el navegador escribiendo la
URL: http://localhost/frontend_dev.php. La web debug toolbar o barra de
herramientas de depuracin web debera mostrarse en la esquina superior
derecha, incluidos los iconos, demostrando que la configuracin es correcta:
Figura 14
Aplicacin Symfony en entorno de desarrollo
61
2.1.7. POSTGRESQL
Segn WorsleyyDrake (2002, p. 3) PostgreSQL es un sistema de
gestin de bases de datos objeto-relacional, distribuido bajo licencia BSD y
con su cdigo fuente disponible libremente. Es el sistema de gestin de
bases de datos de cdigo abierto ms potente del mercado y en sus ltimas
versiones no tiene nada que envidiarle a otras bases de datos comerciales.
A continuacin el siguiente grfico ilustra de manera general los
componentes ms importantes en un sistema PostgreSQL.
Figura 15
Componentes del PostgreSQL
Fuente: http://www.postgresql.org.es
62
En la figura 15 se aprecian los siguientes elementos:

a) Aplicacin cliente: Esta es la aplicacin cliente que utiliza
PostgreSQL como administrador de bases de datos. La conexin puede
ocurrir via TCP/IP sockets locales.
b) Demonio postmaster: Este es el proceso principal de PostgreSQL. Es
el encargado de escuchar por un puerto/socket por conexiones entrantes de
clientes. Tambin es el encargado de crear los procesos hijos que se
encargaran de autentificar estas peticiones, gestionar las consultas y mandar
los resultados a las aplicaciones clientes
c)
Archivos
de
configuracin:
Los
archivos
principales
de
configuracin utilizados por PostgreSQL, postgresql.conf, pg_hba.conf y

pg_ident.conf
d) Procesos hijos postgres: Procesos hijos que se encargan de
autentificar a los clientes, de gestionar las consultas y mandar los resultados
a las aplicaciones clientes
e) PostgreSQL share buffer cache: Memoria compartida usada por
POstgreSQL para almacenar datos en cach.
f) Write-Ahead Log (WAL): Componente del sistema encargado de
asegurar la integridad de los datos (recuperacin de tipo REDO)
g) Kernel disk buffer cache: Cach de disco del sistema operativo
h) Disco: Disco fsico donde se almacenan los datos y toda la
informacin necesaria para que PostgreSQL funcione.
63
2.1.7.1. CARACTERSTICAS
PostgreSQL fue desarrollado hace ms de 15 aos, y durante este
tiempo, estabilidad, potencia, robustez, facilidad de administracin e
implementacin de estndares han sido las caractersticas que ms se han
tenido en cuenta. PostgreSQL funciona muy bien con grandes cantidades de
datos y una alta concurrencia de usuarios accediendo a la vez del sistema. A
continuacin se presentan algunas de sus caractersticas:
A) CARACTERSTICAS GENERALES
a) Es una base de datos 100% ACID
b) Integridad referencial
c) Tablespaces
d) Nested transactions (savepoints)
e) Replicacin asincrona / Streaming replication - Hot Standby
f) Two-phase commit
g) PITR - point in time recovery
h) Copias de seguridad en caliente (Online/hot backups)
i) Unicode
j) Juegos de caracteres internacionales
k) Multi-Version Concurrency Control (MVCC)
i) Mltiples mtodos de autentificacin
j) Acceso encriptado via SSL
k) Actualizacin in-situ integrada (pg_upgrade)
64
l) Disponible para Linux y UNIX en todas sus variantes (AIX, BSD, HPUX, SGI IRIX, Mac OS X, Solaris, Tru64) y Windows 32/64bit.
B) CARACTERSTICAS SOBRE PROGRAMACIN / DESARROLLO
a) Funciones/procedimientos almacenados (stored procedures) en
numerosos lenguajes de programacin, entre otros PL/pgSQL (similar al
PL/SQL de ORACLE), PL/Perl, PL/Python y PL/Tcl
b) Bloques annimos de cdigo de procedimientos (sentencias DO)
c) Numerosos tipos de datos y posibilidad de definir nuevos tipos.
Adems de los tipos estndares en cualquier base de datos, tenemos
disponibles, entre otros, tipos geomtricos, de direcciones de red, de
cadenas binarias, UUID, XML, matrices, entre otros.
d) Soporta el almacenamiento de objetos binarios grandes (grficos,
videos, sonido).
e) APIs para programar en C/C++, Java, .Net, Perl, Python, Ruby, Tcl,
ODBC, PHP, Lisp, Scheme, Qt y muchos otros.
C) STRUCTURE QUERY LANGUAJE (SQL)
a) Llaves primarias (primary keys) y ajenas (foreign keys)
b) Check, Unique y Not null constraints
c) Restricciones de unicidad postergables (deferrable constraints)
d) Columnas auto-incrementales
e) ndices compuestos, nicos, parciales y funcionales en cualquiera de
los metodos de almacenamiento disponibles, B-tree, R-tree, hash GiST
f) Sub-selects
65
g) Consultas recursivas
h) Funciones 'Windows'
i) Joins
j) Vistas (views)
k) Disparadores (triggers) comunes, por columna, condicionales.
l) Reglas (Rules)
m) Herencia de tablas (Inheritance)
n) Eventos LISTEN/NOTIFY
2.1.7.2. LIMITACIONES
Algunos de los lmites de PostgreSQL se presentan en el siguiente
cuadro:
Cuadro 5
Limitaciones de PostgreSQL
Lmite
Valor
Mximo tamao base de dato
Ilimitado (Depende del sistema de

almacenamiento)
Mximo tamao de tabla
32 TB
Mximo tamao de fila
1.6 TB
Mximo tamao de campo
1 GB
Mximo nmero de filas por tabla
Ilimitado
Mximo nmero de columnas por

tabla
250 - 1600 (dependiendo del tipo)
Mximo nmero de ndices por

tabla
Ilimitado
Fuente: http://www.postgresql.org.es
66
2.2. AMBIENTE WEB

En este apartado se hace referencia al estudio documental realizado
sobre la variable de investigacin Ambiente Web, en este sentido se
recolect toda la informacin necesaria para sobre los elementos de esta
variable
de
investigacin
para
finalmente
cristalizar
las
diferentes
metodologas sobre el tema.

2.2.1. DEFINICIONES
Segn Norton (2001, p. 291), es un sistema mundial de redes de
computadoras interconectadas que se acerca cada vez ms al mismo
proceso: aumentar la disponibilidad de la informacin y la facilidad y la
velocidad de comunicacin. Mediante la conexin de millones de
computadoras, hace posible que un usuario en cualquier parte del mundo
intercambie texto, imgenes, videos, programas de cmputo y cualquier cosa
que pueda almacenarse en forma digital con cualquier otra persona que
pertenezca al mundo conectado.
2.2.2. RESEA HISTRICA DE LA INTERNET
Vigden (2002, pp. 15 17) refiere que en la Guerra Fra de los aos 50
y 60, los EE.UU. invirtieron en la investigacin sobre radar, comunicaciones y
computadoras, haba preocupacin por los signos de superioridad de Rusia
en tecnologa, como se ilustra las misiones espaciales Sputnik.
67
Se crearon nuevas agencias para promover los avances en la ciencia y

la tecnologa, Uno de ellas fue la Advanced Research Projects Agency
(ARPA), que se form en 1958 adscrita al Departamento de Defensa (DoD).
ARPA distribuye fondos a los institutos de investigacin, uno de los
beneficiarios fue MIT (Massachusetts Institute of Technology). Los graduados
del MIT, trabajando para la empresa Bolt, Barenek y Newman (BBN),
ayudaron al desarrollo de ARPAnet a finales de los 60. ARPANET fue
diseada utilizando conmutacin de paquetes con el objetivo de ser capaz de
sobrevivir a la prdida de los nodos de red en el supuesto de una guerra
nuclear.
En 1969, fueron conectados cuatro ordenadores con ARPAnet. En 1972
haba 40 puntos de la red y la necesidad de normas comunes y protocolos
fue reconocido, dando lugar a un protocolo de transferencia de archivos
(FTP) en 1973 y el protocolo de control de transmisin (TCP) en 1974. En
1976 la reina Isabel II envi un correo electrnico, pero a finales de la dcada
de 1970 la ARPANET se sigue utilizando principalmente por instituciones
acadmicas de todo el mundo.
En 1982, el protocolo de control de transmisin (TCP) y el protocolo de
Internet (IP), conocidos colectivamente TCP/IP fueron adoptados por
ARPANET,
Internet haba
llegado.
El primer nombre
servidor fue
desarrollador por la Universidad de Winsconsin en 1983, lo que permiti

enviar mensajes sin tener que saber cual es la direccin exacta de la
mquina receptora. En 1985, el sistema de nombres de dominio (DNS) fue
68
introducida, el primer nombre de dominio fue symbolics.com, siguieron las

universidades (por ejemplo, purdue.edu) y organizaciones sin fines de lucro
(por ejemplo, mitre.org).
En 1986, la NSF (National Science Fundation) hizo de soporte en
Internet a disposicin de la comunidad de investigacin a travs del
backbone de NFSNET. En 1989 haba 100.000 nodos conectados a
NFSNET y en 1990, ARPAnet ces sus funciones dando paso a NFSNET. El
crecimiento en conexiones de red se vio impulsado por la adopcin
generalizada de la evolucin de los ordenadores personales en red (Apple e
IBM), servidores Sun y estaciones de trabajo, y la creacin de redes de Cisco
y la red de rea local Ethernet desarrollada por Bob Metcalfe.
En 1991 Tim Berners-Lee estaba trabajando anuncio del CERN (el
Laboratorio Europeo de Fsica de Partculas) imagin la posibilidad de
compartir documentos e informacin fcilmente a travs de Internet. BernersLee, nombr el projecto como el World Wide Web (WWW). CERN lanz un
navegador en lnea impulsando la WWW e hipermedia distribuidos.
El uso de un navegador, lnea por lnea no fue fcil, pero en 1992, Marc
Andreesen, estudiante de licenciatura en la Universidad de Illinois, vio el
potencial de la web en todo el mundo y, junto con colegas, desarroll el
primer navegador grafico: Mosaico. Jim Clark vio el valor del navegador
Mosaic y atrajo a los desarrolladores originales desde Illinois a California,
para trabajar en un nuevo navegador que ms tarde se convertira en
Netscape, el nuevo navegador de Clark fue nombrado Mozilla.
69
2.2.3. PROTOCOLOS DE INTERNET

Para Atelin (2007 p. 19) Los protocolos de Internet son un conjunto de
protocolos de red creados para enlazar va Internet y permitir la transferencia
de datos entre redes de computadoras, sin importar el sistema operativo ni el
tipo de computador que este usando. Entre los protocolos mas conocidos:
a) TCP/IP: Protocolo de Transmision (TCP) y Protocolo de Internet (IP).
b) HTTP: (HyperText Transfer Protocol) usado para
acceder a las
paginas.
c) ARP: (Address Resolution Protocol) para la resolucin de nombres.
d) FTP: (File Transfer Protocol) Protocolo para transferencia de
archivos.
e) SMTP: (Simple Mail Transfer Protocol) Protocolo para correos.
f) POP: (Post Office Protocol) Protocolo de Correos.
g) TELNET: Para acceder a equipos Remotos.
h) ICMP:(Internet Control Message Protocol) Usado para cuando
ocurren errores de Transmisin.
i) IGMP: (Internet Group Management Protocol)
Para realizar IP
Multicast.
j) DHCP: (Dynamic Host Configuration Protocol) Direccionamiento
dinamico de IP.
k) UDP: (User Datagram Protocol) Protocolo que permite cierta prdida
de paquetes cuando existen cambios de velocidad.
70
2.2.4. LA WORLD WIDE WEB

Es bsicamente un medio de comunicacin de texto, grficos y otros
objetos multimedia a travs de Internet es decir, la web es un sistema de
hipertexto que utiliza Internet como su mecanismo de transporte o desde otro
punto de vista, una forma grfica de explorar Internet. (Marco y otros, 2010,
p.76)
2.2.5. HYPERTEXT MARKUP LANGUAGE
Segn Marco y otros (2010, p.50) HTML es el "idioma" de la WWW. Los
documentos HTML utilizan etiquetas de marcado (tags), tales como la
etiqueta de encabezamiento de pgina:
<H1> Introduccion </h1>
Estas etiquetas de marcado son sensibles a maysculas, por lo que da
el mismo resultado <H1> como <h1>, aunque por la esttica y la facilidad de
lectura es mejor ser consistente con el uso de maysculas y minsculas que
mezclarlos.
Aunque las etiquetas de marcado no distinguen entre maysculas y
minsculas, otros atributos sensibles, otros, tales como nombres de archivo,
lo puede ser (por ejemplo, en los nombres de archivo del sistema operativo
UNIX, pero no tanto en los sistemas operativos de Microsoft). las etiquetas
de marcado suelen estar acompaados para indicar el inicio y el final de un
elemento, por ejemplo, <H1> se cierra la etiqueta </H1>.
71
Afortunadamente, los navegadores son bastante indulgentes cuando se

representa el contenido HTML. Supongamos que el archivo, hola.htm,
contiene slo el contenido del texto siguiente:
Hola
En el navegador se mostrar una ventana con la palabra "Hola". Este
archivo claramente no cumple con los estndares HTML, pero el navegador
del cliente har todo lo posible para que aparezca. Una versin mejor sera la
siguiente:
<html>
<head>
<title> Hola WWW </ title>
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8">
</head>
<body bgcolor="#ffffff" text="#000000">
Bienvenido a la web <i> en todo el mundo </i>.
Busca en <ahref=http://www.w3c.org"> W3C </a>
</body>
</html>
Slo el contenido entre las etiquetas <body> se muestra en el

navegador te. El resto de las marcas darn la informacin sobre el
navegador HTML estndar, que se utiliza, el ttulo del documento, y el color
del fondo. El contenido contiene texto sin formato, algunas de las cuales ha
subrayado <i>, y el <href> que mostrar un hipervnculo hacia otra pgina.
2.2.6. SITIOS WEB
2.1.6.1. DEFINICIONES
Segn Lujan (2002, p.62) un sitio Web es un conjunto de pginas web
72
relacionadas entre si. En todo sitio Web se suele distinguir dos pginas
especiales, la pagina inicial (o pgina de entrada) y la pgina principal (o
pgina men). En algunos sitios web se prescinde de la pgina inicial y
directamente se muestra al usuario la pgina principal. Por otro lado, la
pgina principal, conocida como home, front o main page, es la primera que
funciona como ndice o tabla de contenidos web. A travs de esta pgina, el
resto de documentos del sitio web es accesible de forma directa o indirecta.
Por su parte, Prat (2007, p. 8) define un sitio Web como un conjunto de
pginas web (archivos) enlazadas entre s por vnculos de hipertextos (o
hipervnculos), todo ellos instalado en un servidor web accesible las 24 horas
del da, los siete das de la semana, desde cualquier parte del mundo.
Ramos (2004, p.6) especifica que un sitio webcomo una coleccin de
pginas web relacionadas y comunes a un dominio de Internet o subdominio
en la World Wide Web en Internet. A las pginas de un sitio web se accede
frecuentemente a travs de un URL raz comn llamado portada, que
normalmente reside en el mismo servidor fsico. Los URL organizan las
pginas en una jerarqua, aunque los hiperenlaces entre ellas controlan ms
particularmente cmo el lector percibe la estructura general y cmo el trfico
web fluye entre las diferentes partes de los sitios.
2.1.6.2. TIPOS DE SITIOS WEB
Briz y Lazo (2001, p. 158) categorizan los sitios web como
Promocionales, Informativos y Transaccionales.
73
a) Sitios Promocionales: su objetivo es promocionar marcas, productos

y servicios de una organizacin o empresa. Son las mas abundantes y, con
mayor o menor derroche grfico. Se puede considerar como la unin entre la
red y el mundo fsico, siendo este en el que prestan sus servicios las
empresas.
b) Sitios Informativos: Proporcionan informacin, datos o contenido de
ocio. Se trata de un sitio temtico sobre un producto o servicio concreto o
grupo de ellos que ofrecen informacin centralizada sobre un determinado
sector. Entre este tipo de sitios se encuentran las revistas electrnicas, guas
electrnicas, pginas informativas entre otras.
c) Sitios
Transaccionales:
Son
aquellas capaces de
procesar
transacciones en la Web, como pagos en lnea, registros, clculos entre

otros.
2.1.6.3. PLANIFICACIN DE UN SITIO WEB
Segn Quero y otros (2007, p.31) antes de trabajar en el computador es
muy importante realizar con lpiz y papel una planificacin y preparacin del
sitio. Crear adecuadamente los contenidos y estructurarlos en forma de
pginas.
Lo primero hacer es planificar los contenidos. Aqu se deben anotar
todas las ideas que se desean para el sitio. Parte de esas ideas no sern
aplicables, pero de eso se trata, de ver qu interesa y qu no. Uno de los
primeros pasos es tomar como referencia otros sitios. Esto ayudara a tomar
74
ideas, ver la estructura de la navegacin, los colores que emplean y el

diseo. Lo siguiente es preparar una lista de las secciones que se desea
incluir y decidir la estructura de navegacin: lineal, jerrquica u otros.
En este orden de ideas, hay que determinar a qu pblico se dirige el
sitio web. Esto es muy importante ya que el diseo y los contenidos
dependern de ese punto. El contenido del sitio ser una combinacin de la
informacin que se tiene y de la que se tenga que crear. Por eso es
importante conocer a quien va dirigido.
El diseo grfico determina el tono de la pgina web. Crear algunos
grficos o repetir algunos elementos del diseo
pueden dar sentido de
continuidad al sitio. En este punto es donde se debe decidir el formato grafico

a utilizar, si se va a efectuar en formato jpeg o gif, si se usaran gif animados,
sonido u otros elementos multimedia.
Una vez que se ha evaluado los puntos anteriores se debe tomar cinco
aspectos importantes que resumirn la planificacin efectiva de un sitio web
y son los siguientes:
a) Determinar el aspecto que tendr el Sitio, tanto de diseo como de
estructura.
b) Seleccionar el proveedor de servicios en internet que proporcionara
el alojamiento del sitio Web
c) Ver disponibilidad y seleccionar un dominio (por ejemplo,
www.midominio.com)
d) Analizar los objetivos del sitio y el perfil del pblico que esta dirigido.
75
f) Tener un claro esquema de navegacin del sitio. Se planifican

cuidadosamente el sitio antes de empezar a desarrollarlo, se ahorrara mucho
tiempo.
2.1.6.4. CONSTRUCCIN DE UN SITIO WEB
Cuando se plantea la construccin de un sitio Web accesible desde
cero, existen una serie de fases principales, para conseguir el resultado
esperado y no llevarse sorpresas decepcionantes. Por supuesto, esto es slo
la teora, en la vida real no siempre se pueden seguir los pasos al completo
ya que el tiempo muchas veces es el que manda.
Segn Bracco (2001), la construccin de un sitio Web se divide en tres
fases principales: Contenido y Estructuracin, Presentacin y Maquetacin y
Revisin
a) Contenido y estructuracin. En primer lugar, se debe tener en cuenta
nicamente de qu queremos transmitir a los usuarios y que estructuras son
las ms adecuadas para esta informacin. Ahora, no se debe preocupar de
cmo sern presentados estos elementos en nuestra pgina. Por supuesto,
para conseguir el sitio Web accesible, todos estos elementos y estructuras
deben cumplir los estndares publicados.
b) Presentacin y maquetacin. Una vez que se tiene claras las
estructuras que formaran el sitio Web, es el momento de decidir cmo va a
ser la presentacin visual de dichos elementos. Como ya se ha dicho
muchas veces, es obligatorio separar el contenido de la presentacin, por lo
76
que todo el trabajo en esta fase se har definiendo estilos para los diferentes
elementos que se ha creado en la fase anterior. Aunque se ha dicho muchas
veces, no est de ms recordar que siempre hay que evitar la maquetacin
con tablas, que por suerte cada vez se ve menos.
c) Revisin. Una vez en esta ltima fase, ya se tiene construido el sitio
Web, pero es necesario una etapa de revisin de los diferentes requisitos de
accesibilidad, y si es posible que dicha revisin la lleve a cabo una persona
diferente a la que ha construido al sitio Web. Cuanto ms tiempo dediquemos
a la etapa de revisin de accesibilidad mejor ser el resultado obtenido
2.2.7. APLICACIONES WEBS
Como qued establecido anteriormente, las aplicaciones son parte
fundamental de las organizaciones y, por ende, son diseadas acorde a sus
necesidades. Los componentes de las mismas se interrelacionan para
alcanzar un fin, casi siempre, apoyar el proceso de toma de decisiones.
Tambin se estableci que el ambiente web es el contexto en el cual estn
inmersos millones de usuarios quienes participan en una red de redes.
En este sentido, coincidiendo con Surhone y otros (2010, p. 25), los
sistemas de informacin basados en ambiente web son complejos en su
estructura y organizacin de componentes y son complicados en su
desarrollo y mantenimiento. Por ello, puede decirse las aplicaciones basadas
en web conforman una nueva categorizacin y caracterizacin de sistemas.
77
2.2.7.1. CATEGORAS DE APLICACIONES WEB

De acuerdo a Capa (2008, p. 16) el desarrollo de aplicaciones web
puede iniciarse desde categoras bajas e irse expandiendo hasta incrementar
su grado de complejidad. Las nuevas categoras de aplicacin web
representan un grado mayor de dificultad pero ello no significa que
reemplacen en su totalidad a las antiguas generaciones. Cada una de estas
categoras tiene sus propios campos especficos. En consecuencia, la
complejidad de las aplicaciones web puede fcilmente ser atribuida a
algunas categoras de una vez (ver figura 16).
Figura 16
Categoras de las Aplicaciones Web
78
A continuacin se describen los campos que se representan en el

esquema anterior (Kappel, 2003, pp. 5 6):
a) Centrada en documentos (Document Centric): las pginas son
almacenadas en un servidor web, de donde son enviadas al cliente en
respuesta a las peticiones. Son usualmente actualizadas de forma manual
mediante el uso de herramientas. Riesgo de inconsistencias e informacin
desactualizada. Mayor simplicidad y estabilidad con tiempos de respuesta
muy cortos.
b) Interactiva (Interactive): ofrecen nuevas formas, aspectos de mejora
en la interfaz y selecciones. Las pginas y los enlaces a otras son generados
de forma dinmica.
c) Transaccional (Transactional): fueron creadas para brindar mayor
interactividad al usuario, permitindole acciones no slo de lectura sino de
actualizacin de los contenidos del sitio.
d) Basada en flujo de trabajo (Workflow-based): permite la gestin de
flujos de trabajo entre compaas, autoridades pblicas y usuarios privados.
La complejidad de los sistemas que se ofrecen, la autonoma de las
compaas participantes y la necesidad de flujos de trabajos flexibles y
robustos son los principales desafos.
e)
Colaborativa
(Collaborative):
son
utilizadas
especficamente
parafinescolaborativos.Soportanlainformacincompartidayworkspaces
para
editar, generar y gestionar la informacin que se tiene compartida.

f) Web Social (Social Web): son sitios donde los usuarios comparten su
79
identidad a un grupo reducido de personas con los mismos intereses.

g) Orientada a portales (Portal-Oriented): ofrecen un acceso a fuentes
de informacin y/o servicios heterogneos separados.
h) Ubicua (Ubiquitous): proveen servicios adaptados para cualquier
dispositivo en cualquier lugar y momento.
i) Web Semntica (Semantic Web): el objetivo de la web semntica es
brindar informacin no nicamente para el entendimiento humano sino para
los propios sistemas que la manipulan. Lo que facilitara la gestin del
conocimiento en la web y su reutilizacin.
2.2.7.2. CARACTERSTICAS DE LAS APLICACIONES WEB
De acuerdo a Kappel (2003, p. 8) las aplicaciones web difieren de las
tradicionales en algunos campos. Estas caractersticas no estn presentes
en las aplicaciones tradicionales y dependen mucho del tipo de aplicacin
web que se est desarrollando, por ejemplo una aplicacin web transaccional
demandar un mayor enfoque en sus detalles.
Por estas caractersticas tan particulares, muchos conceptos, mtodos,
tcnicas y herramientas de la ingeniera de software como las pruebas de
usuario, diagramas de navegabilidad entre otras, han tenido que ser
adaptados a las necesidades de la ingeniera web o han resultado totalmente
inadecuadas. La figura 17 ofrece una revisin de estas caractersticas
agrupadas en tres dimensiones: producto, uso y desarrollo con su respectiva
evolucin.
80
Figura 17
Dimensiones para la categorizacin de las Aplicaciones Web
Estas dimensiones estn basadas en el estndar ISO/IEC 9126-1 para
la evaluacin de las caractersticas de calidad del software.
A) CARACTERSTICAS RELACIONADAS AL PRODUCTO
Segn Kappel (2003, p. 8) constituyen la mayor parte en la construccin
de una nueva aplicacin web. Aqu se abarca el contenido, el modelo de
navegacin y el modelo de presentacin o interfaz de usuario:
a) Contenido: generar contenido, tenerlo disponible, integrarlo y
actualizarlo es igualmente importante como lo es el desarrollo de la
aplicacin en s. Los programadores no slo deben actuar como
constructores de la aplicacin sino tambin como autores de la informacin.
81
b) Modelo de navegacin: entre las caractersticas propias de las

aplicaciones web est la no linealidad de los documentos de hipertexto.
Existen muchos modelos de hipertexto y una web como tal, define un modelo
simple por su cuenta. Los elementos bsicos de un modelo de hipertexto o
navegacin son los nodos, enlaces y la fuente. Un nodo es una unidad de
informacin nica e identificable. Un enlace es la ruta desde un nodo hacia
otro. En la web, estas rutas son siempre unidireccionales y su significado no
est claramente definido. Finalmente, la fuente es el espacio dentro del
contenido de un nodo que es el origen o destino de un enlace.
c) Modelo de presentacin: dos caractersticas de las aplicaciones web
a nivel de presentacin son la esttica y el ser intuitivas para el usuario. La
esttica es importante porque captura la atencin del usuario y al ser de fcil
uso, tendr una utilizacin recurrente y cumplir los objetivos para la que
inicialmente fue diseada.
B) CARACTERSTICAS RELACIONADAS AL USO
De acuerdo a Kappel (2003, p. 9) comparada con aplicaciones
tradicionales, el uso de aplicaciones web es muy heterogneo. Los usuarios
varan en nmero, tiempos y lugares de acceso que no pueden ser
predichos, tienen diferentes componentes hardware y/o software. El uso de
las aplicaciones es caracterizado por la necesidad del continuo cambio en las
situaciones de uso de los usuarios, o tambin llamados contextos. Estos
contextos pueden ser divididos en tres grupos: contexto social, contexto
tcnico y contexto natural:
82
a) Contexto Social: (Usuarios). Se refiere a aspectos especficos de los

usuarios tales como espontaneidad y multiculturalidad. Un usuario puede
visitar una aplicacin web cuando l lo desee y regresar en cualquier
momento. Desde que la competencia en internet se ha visto incrementada,
un usuario nicamente utilizar una aplicacin web si sta representa una
ventaja inmediata sobre sus competidoras. La gran variedad de grupos de
posibles usuarios hace difcil la tarea de seleccionar un grupo representativo
para el anlisis de requerimientos.
b) Contexto Tcnico: (Red y Dispositivos). Comprende lo relacionado a
la conexin de red y su calidad en el servicio. Abarca los diferentes tipos de
hardware y software que los usuarios utilizan para acceder ala aplicacin
web. Un usuario puede personalizar a su manera el estilo de navegacin, sus
accesos, plugins adicionales. El gran nmero de navegadores disponibles en
el mercado tambin es un desafo que las aplicaciones web deben enfrentar,
cada uno tiene sus propias funcionalidades y restricciones.
c) Contexto Natural:(Lugar y Tiempo). Incluye aspectos de localizacin
y tiempos de acceso. Maneja trminos como globalidad y disponibilidad. La
globalidad de una aplicacin web demanda medidas de seguridad ms
elevadas que impidan el acceso deliberado o accidental de los usuarios a las
reas crticas del sistema. La disponibilidad involucra una estabilidad en las
aplicaciones web, las cuales se vuelven usables inmediatamente luego de su
liberacin obligando a que las exigencias de calidad en el producto
desarrollado sean seguras y ptimas.
83
C) CARACTERSTICAS RELACIONADAS AL DESARROLLO

Finalmente, Kappel (2003, p. 9) caracterizando las aplicaciones
basadas en web, refiere que por su desarrollo se caracterizan por el uso de
los recursos necesarios como un equipo de desarrollo, la infraestructura
tcnica necesaria, el proceso de desarrollo como tal y la integracin:
a) Equipo de desarrollo: se ve altamente influenciado por factores como
un equipo de trabajo multidisciplinario y generalmente ms joven que otro
equipo de desarrollo de software tradicional. Estos factores y los mtodos de
la llamada comunidad de desarrollo contribuyen a una forma completamente
nueva de colaboracin organizada de los diferentes grupos de desarrollo.
b) Infraestructura tcnica: la falta de homogeneidad e inmadurez delos
componentes usados son caractersticas importantes en la infraestructura
tcnica de las aplicaciones web. El desarrollo de aplicaciones web depende
de dos factores externos como lo son el servidor y el navegador. Mientras
que el servidor puede ser configurado para que tenga el comportamiento
deseado por el equipo de desarrollo, no sucede lo mismo con los
navegadores que poseen preferencias individuales y los conocidos plugins.
c) Proceso de desarrollo: se ve influenciado por la flexibilidad y el
paralelismo, flexibilidad para adaptarse a nuevas condiciones de cambio y
paralela dado que las aplicaciones web son desarrolladas ala par por
subgrupos que son estructurados de acuerdo a los componentes autnomos
de la aplicacin, y no de acuerdo a la experiencia laboral como ocurre en las
aplicaciones tradicionales.
84
d) Integracin: una caracterstica importante de muchas aplicaciones

web es la necesidad de integracin interna y externa no solamente en
aspectos tcnicos sino tambin de contenido. Tanto en integraciones
internas como externas con servicios o sin ellos, el nuevo sistema debe
recopilar las viejas prestaciones y mejorarlas.
2.2.8. INGENIERA DE REQUISITOS
En el proceso de desarrollo de un sistema, sea o no para la web, el
equipo de desarrollo se enfrenta al problema de la identificacin de
requisitos. La definicin de las necesidades del sistema es un proceso
complejo, identificando los requisitos que el sistema debe cumplir para
satisfacer las necesidades de los usuarios finales y de los clientes.
Para realizar este proceso, no existe una nica tcnica estandarizada y
estructurada que ofrezca un marco de desarrollo que garantice la calidad del
resultado. Existe en cambio un conjunto de tcnicas, cuyo uso proponen las
diferentes metodologas para el desarrollo de aplicaciones web. Se debe
tener en cuenta que la seleccin de las tcnicas y el xito de los resultados
que se obtengan, depende en gran medida tanto del equipo de anlisis y
desarrollo, como de los propios clientes o usuarios que en ella participen.
2.2.8.1. TIPOS DE REQUISITOS
De acuerdo a Escalona y Koch (2002, p. 11), para facilitar la
comprensin de las propuestas, antes de presentarlas, a continuacin se
85
hace una clasificacin de requisitos relevantes en sistemas web:

a) Requisitos de datos, tambin denominados requisitos de contenido,
requisitos conceptuales o requisitos de almacenamiento de informacin.
stos requisitos responden a la pregunta de qu informacin debe almacenar
y administrar el sistema.
b) Requisitos de interfaz (al usuario), tambin llamados en algunas
propuestas requisitos de interaccin o de usuario. Responden a la pregunta
de cmo va a interactuar el usuario con el sistema.
c) Requisitos navegacionales, recogen las necesidades de navegacin
del usuario.
d) Requisitos de personalizacin, describen cmo debe adaptarse el
sistema en funcin de qu usuario interacte con l y de la descripcin actual
de dicho usuario.
f) Requisitos transaccionales o funcionales internos, recogen qu debe
hacer el sistema de forma interna, sin incluir aspectos de interfaz o
interaccin. Tambin son conocidos en el ambiente web como requisitos de
servicios.
g) Requisitos no funcionales, son por ejemplo los requisitos de
portabilidad, de reutilizacin, de entorno de desarrollo, de usabilidad, de
disponibilidad, entre otros.
2.2.8.2. ESPECIFICACIN DE REQUISITOS
De acuerdo a Lowe y Hall (1999, p. 599), el proceso de especificacin
86
de requisitos se puede dividir en tres grandes actividades: captura de

requisitos, definicin de requisitos y validacin de requisitos
En la figura 18 se presenta el proceso de ingeniera de requisitos que
incluye estas tres actividades.
Figura 18
Proceso de Ingeniera de Requisitos.
Fuente: Escalona y Koch (2002, p. 5)
Se puede observar en la figura anterior, el proceso comienza con la
realizacin de la captura de requisitos, el grupo de tcnicos toma la
informacin suministrada por los usuarios y clientes. Esta informacin puede
provenir de fuentes muy diversas: documentos, aplicaciones existentes, a
travs de entrevistas, entre otros. En base a esta informacin, el equipo de
desarrollo elabora el catlogo de requisitos.
87
Sobre las anteriores aseveraciones, se infiere que en la validacin de

requisitos se realiza la valoracin de los mismos, comprobando si existen
inconsistencias, errores o si faltan requisitos por definir. El proceso de
definicin-validacin es iterativo y en algunos proyectos complejos resulta
necesario ejecutarlo varias veces.
2.2.8.3. TCNICAS PARA LA CAPTURA DE REQUISITOS
De acuerdo a Escalona y Koch (2002, p. 5), la captura de requisitos es
la actividad mediante la que el equipo de desarrollo de un sistema de
software extrae, de cualquier fuente de informacin disponible, las
necesidades que debe cubrir dicho sistema.
Las autoras tambin refieren que el proceso de captura de requisitos
puede resultar complejo, principalmente si el entorno de trabajo es
desconocido para el equipo de analistas, y depende mucho de las personas
que participen en l.
Por la complejidad que todo esto puede implicar, la ingeniera de
requisitos ha trabajado desde hace aos en desarrollar tcnicas que
permitan hacer este proceso de una forma ms eficiente y precisa para
alcanzar los objetivos propuestos.
A continuacin, Escalona y Koch (2002, p. 5), presentan un grupo de
tcnicas que de forma clsica han sido utilizadas para esta actividad en el
proceso de desarrollo de todo tipo de software y que tambin son usadas en
el proceso de captura de requisitos:
88
a) Entrevistas: resultan una tcnica muy aceptada dentro de la

ingeniera de requisitos y su uso est ampliamente extendido. Las entrevistas
le permiten al analista tomar conocimiento del problema y comprender los
objetivos de la solucin buscada. A travs de esta tcnica el equipo de
trabajo se acerca al problema de una forma natural.
b) JAD (Joint Application Development / Desarrollo conjunto de
aplicaciones): esta tcnica resulta una alternativa a las entrevistas. Es una
prctica de grupo que se desarrolla durante varios das y en la que participan
analistas, usuarios, administradores del sistema y clientes (IBM, 1997). Est
basada en cuatro principios fundamentales: dinmica de grupo, el uso de
ayudas visuales para mejorar la comunicacin, mantener un proceso
organizado y racional y una filosofa de documentacin WYSIWYG (What
You See Is What You Get, lo que ve es lo que obtiene), es decir, durante la
aplicacin de la tcnica se trabajar sobre lo que se generar.
Tras una fase de preparacin del JAD al caso concreto, el equipo de
trabajo se rene en varias sesiones. En cada una de ellas se establecen los
requisitos de alto nivel a trabajar, el mbito del problema y la documentacin.
Durante la sesin se discute en grupo sobre estos temas, llegndose a una
serie de conclusiones que se documentan. En cada sesin se van
concretando ms las necesidades del sistema.
Esta tcnica presenta una serie de ventajas frente a las entrevistas
tradicionales, ya que ahorra tiempo al evitar que las opiniones de los clientes
se tengan que contrastar por separado, pero requiere un grupo de
89
participantes bien integrados y organizados.

c) Brainstorming (Tormenta de ideas): es tambin una tcnica de
reuniones en grupo cuyo objetivo es que los participantes muestren sus
ideas de forma libre. Consiste en la mera acumulacin de ideas y/o
informacin sin evaluar las mismas. Para la ejecucin de esta tcnica el
grupo de personas que participa en estas reuniones no debe ser muy
numeroso (mximo 10 personas), una de ellas debe asumir el rol de
moderador de la sesin, pero sin carcter de controlador y al menos otra
debe estar capturando las ideas.
d) Concept Mapping: Los conceptos de mapas son grafos en los que
los vrtices representan conceptos y las aristas representan posibles
relaciones entre dichos conceptos. Estos grafos de relaciones se desarrollan
con el usuario y sirven para aclarar los conceptos relacionados con el
sistema a desarrollar.
Los Concept Mapping son muy usados dentro de la ingeniera de
requisitos, pues son fciles de entender por el usuario, ms an si el equipo
de desarrollo hace el esfuerzo de elaborarlo en el lenguaje de ste. Sin
embargo, deben ser usados con cautela porque en algunos casos pueden
ser muy subjetivos y pueden llegar a ser ambiguos en casos complejos, si no
se acompaa de una descripcin textual.
d) Sketches y Storyboards: Est tcnica es frecuentemente usada por
los diseadores grficos de aplicaciones en el entorno web. La misma
consiste en representar sobre papel en forma muy esquemtica las
90
diferentes interfaces al usuario (sketches). Pueden ser agrupados y unidos

por enlaces dando idea de la estructura de navegacin (storyboard).
e) Casos de Uso: muestran el contorno (actores) y el alcance (requisitos
funcionales expresados como casos de uso) de un sistema. Un caso de uso
describe la secuencia de interacciones que se producen entre el sistema y
los actores del mismo para realizar una determinada funcin. Los actores son
elementos externos (personas, otros sistemas, entre otros.) que interactan
con el sistema como si fuera una caja negra. Un actor puede participar en
varios casos de uso y un caso de uso puede interactuar con varios actores.
f) Cuestionarios y Checklists: Esta tcnica requiere que el analista
conozca el mbito del problema en el que est trabajando. Consiste en
redactar un documento con preguntas cuyas respuestas sean cortas y
concretas, o incluso cerradas por unas cuantas opciones en el propio
cuestionario (Checklist). Este cuestionario ser cumplimentado por el grupo
de personas entrevistadas o simplemente para recoger informacin en forma
independiente de una entrevista.
g) Comparacin de terminologa: Uno de los problemas que surge
durante la elicitacin de requisitos es que usuarios y expertos no llegan a
entenderse debido a problemas de terminologa. Esta tcnica es utilizada en
forma complementaria a otras tcnicas para obtener consenso respecto de la
terminologa a ser usada en el proyecto de desarrollo. Para ello es necesario
identificar el uso de trminos diferentes para los mismos conceptos
(correspondencia), misma terminologa para diferentes conceptos (conflictos)
91
o cuando no hay concordancia exacta ni en el vocabulario ni en los

conceptos (contraste).
2.2.8.4. DEFINICIN DE REQUISITOS
Segn Snchez y otros (2003, p. 34) la definicin de requisitos, es el
proceso mediante el cual los futuros usuarios del sistema informtico y los
ingenieros involucrados en su desarrollo investigan, descubren, revelan,
especifican y comprenden las capacidades y condiciones necesarias para
resolver un determinado problemas.
A continuacin Escalona y Koch (2002, pp. 8 9) describen
brevemente las diferentes tcnicas para la definicin de requisitos.
a) Lenguaje natural: Es una tcnica muy ambigua para la definicin de
los requisitos. Consiste en definir los requisitos en lenguaje natural sin usar
reglas para ello. Segn Sommerville (2005, p. 119) el lenguaje natural a
menudo es utilizado para redactar, para los requerimientos del usuario y las
especificaciones del requerimiento del sistema. Sin embargo debido a que
los requerimientos del sistema son ms detallados que los requerimientos del
usuario, las especificaciones en leguaje natural suelen ser ms confusas y
difciles de entender. A pesar de que son muchos los trabajos que critican su
uso, es cierto que a nivel prctico se sigue utilizando.
b) Glosario y ontologas: Segn Koch (2001, p. 217) La diversidad de
personas que forman parte de un proyecto software hace que sea necesario
establecer un marco de terminologa comn. Esta necesidad se vuelve ms
92
patente en los sistemas de informacin web puesto que el equipo de

desarrollo en ellas suele ser ms interdisciplinario. Por esta razn son
muchas las propuestas que abogan por desarrollar un glosario de trminos
en el que se recogen y definen los conceptos ms relevantes y crticos para
el sistema.
c) Plantillas o patrones: Esta tcnica, recomendada Escalona, Torres y
Mejias, (2002, p. 12), tiene por objetivo el describir los requisitos mediante el
lenguaje natural pero de una forma estructurada. Una plantilla es una tabla
con una serie de campos y una estructura predefinida que el equipo de
desarrollo va cumplimentando usando para ello el lenguaje del usuario. Las
plantillas eliminan parte de la ambigedad del lenguaje natural al estructurar
la informacin; cuanto ms estructurada sea sta, menos ambigedad
ofrece. Sin embargo, si el nivel de detalle elegido es demasiado estructurado,
el trabajo de rellenar las plantillas y mantenerlas, puede ser demasiado
tedioso.
d) Escenarios: La tcnica de los escenarios consiste en describir las
caractersticas del sistema a desarrollar mediante una secuencia de pasos.
La representacin del escenario puede variar dependiendo del autor. Esta
representacin puede ser casi textual o ir encaminada hacia una
representacin grfica en forma de diagramas de flujo. El anlisis de los
escenarios, hechos de una forma u otra, pueden ofrecer informacin
importante sobre las necesidades funcionales de sistema.
e) Casos de uso: Como tcnica de definicin de requisitos es como ms
93
ampliamente han sido aceptados los casos de uso. Actualmente se ha

propuesto como tcnica bsica del proceso RUP. Sin embargo, son varios
los autores que defienden que pueden resultar ambiguos a la hora de definir
los requisitos, por lo que hay propuestas que los acompaan de
descripciones basadas en plantillas o de diccionarios de datos que eliminen
su ambigedad.
f) Lenguajes Formales: Otro grupo de tcnicas que merece la pena
resaltar como extremo opuesto al lenguaje natural, es la utilizacin de
lenguajes formales para describir los requisitos de un sistema. Las
especificaciones algebraicas como ejemplo de tcnicas de descripcin
formal, han sido aplicadas en el mundo de la ingeniera de requisitos desde
hace aos (Pea, 1998). Sin embargo, resultan muy complejas en su
utilizacin y para ser entendidas por el cliente. El mayor inconveniente es
que no favorecen la comunicacin entre cliente y analista. Por el contrario, es
la representacin menos ambigua de los requisitos y la que ms se presta a
tcnicas de verificacin automatizadas.
2.2.8.5. VALIDACIN DE REQUISITOS
Los requisitos una vez definidos necesitan ser validados. La validacin
de requisitos tiene como misin demostrar que la definicin de los requisitos
define realmente el sistema que el usuario necesita o el cliente desea (Lowe
& Hall, 1999). Es necesario asegurar que el anlisis realizado y los
resultados obtenidos de la etapa de definicin de requisitos son correctos.
94
Pocas son las propuestas existentes que ofrecen tcnicas para la realizacin
de la validacin y muchas de ellas consisten en revisar los modelos
obtenidos en la definicin de requisitos con el usuario para detectar errores o
inconsistencias.
An as, existen algunas tcnicas que pueden aplicarse para ello:
a) Reviews o Walk-throughs: Est tcnica consiste en la lectura y
correccin de la completa documentacin o modelado de la definicin de
requisitos. Con ello solamente se puede validar la correcta interpretacin de
la informacin transmitida. Ms difcil es verificar consistencia de la
documentacin o informacin faltante.
b) Auditoras: La revisin de la documentacin con esta tcnica consiste
en un chequeo de los resultados contra una checklist predefinida o definida a
comienzos el proceso, es decir slo una muestra es revisada.
c) Matrices de trazabilidad: Esta tcnica consiste en marcar los
objetivos del sistema y chequearlos contra los requisitos del mismo. Es
necesario ir viendo qu objetivos cubre cada requisito, de esta forma se
podrn detectar inconsistencias u objetivos no cubiertos.
d) Prototipos: Algunas propuestas se basan en obtener de la definicin
de requisitos prototipos que, sin tener la totalidad de la funcionalidad del
sistema, permitan al usuario hacerse una idea de la estructura de la interfaz
del sistema con el usuario. Esta tcnica tiene el problema de que el usuario
debe entender que lo que est viendo es un prototipo y no el sistema final.
95
2.2.9. METODOLOGAS PARA EL DESARROLLO DE SISTEMAS DE

INFORMACIN BASADOS EN WEB
El avance de Internet y las comunicaciones ha provocado en los ltimos
aos el nacimiento de nuevas propuestas metodolgicas para la web. Sin
embargo, la mayora de ellas han centrado su trabajo principalmente en las
etapas de diseo e implementacin, en la mayora de estas propuestas el
tratamiento de requisitos ha sido tratado con una menor importancia y, en
cierta medida, de menor relevancia con relacin a las dems actividades.
En el presente proyecto se hace referencia a las metodologas para el
desarrollo de sistemas de informacin basados en web, en este caso, el
Desarrollo Rpido de Aplicaciones (RAD), Navigational Development
Techniques (NDT) y Design-Driven Requirements Elicitation (DDRE).
2.2.9.1. DESARROLLO RPIDO DE APLICACIONES (RAD)
Potencier y Zaninotto (2008, p. 20) refieren que durante mucho tiempo,
la programacin de aplicaciones web fue un tarea tediosa y muy lenta.
Siguiendo los ciclos habituales de la ingeniera del software (como los
propuestos por el Proceso Racional Unificado o Rational Unified Process) el
desarrollo de una aplicacin web no puede comenzar hasta que se han
establecido por escrito una serie de requisitos, se han creado los diagramas
UML
(Unified
Modeling
Language)
documentacin sobre el proyecto.
se
ha
producido
abundante
96
Potencier y Zaninotto (2008, p. 20) tambin refieren que este modelo se

vea favorecido por la baja velocidad de desarrollo, la falta de versatilidad de
los lenguajes de programacin (antes de ejecutar el programa se debe
construir, compilar y reiniciar) y sobre todo por el hecho de que los clientes
no estaban dispuestos a adaptarse a otras metodologas.
Siguiendo con los antes referidos autores, hoy en da, las empresas
reaccionan
ms
rpidamente
los
clientes
cambian
de
opinin
constantemente durante el desarrollo de los proyectos. De este modo, los

equipos de desarrollo deben adaptarse a esas necesidades y tienen que
poder
cambiar
la
estructura
de
una
aplicacin
de
forma
rpida.
Afortunadamente, el uso de lenguajes de script como Perl y PHP permiten

seguir otras estrategias de programacin, como RAD (desarrollo rpido de
aplicaciones) y el desarrollo gil de software.
Puede decirse entonces que una de las ideas centrales de esta
metodologa es que el desarrollo empieza lo antes posible para que el cliente
pueda revisar un prototipo que funciona y pueda indicar el camino a seguir. A
partir de ah, la aplicacin se desarrolla de forma iterativa, en la que cada
nueva versin incorpora nuevas funcionalidades y se desarrolla en un breve
espacio de tiempo, siendo este proceso continuo hasta que el usuario deje
de solicitar modificaciones o el sistema sea abandonado.
No obstante, Potencier y Zaninotto (2008, p. 21), aclaran que las
consecuencias de estas metodologas para el desarrollador pueden ser
numerosas:
97
a) El programador no debe pensar acerca de las versiones futuras al

incluir una nueva funcionalidad.
b) Los mtodos utilizados deben ser lo ms sencillos y directos
posibles.
Estas ideas se resumen en el principio denominado KISS: Haz las
cosas sencillas, idiota! (Keep It Simple, Stupid)
En este orden de ideas, los antes referidos autores sealan cuando se
modifican los requisitos o cuando se aade una nueva funcionalidad,
normalmente se debe reescribir parte del cdigo existente. Este proceso se
llama refactorizacin y sucede a menudo durante el desarrollo de una
aplicacin web. El cdigo suele moverse a otros lugares en funcin de su
naturaleza. Los bloques de cdigo repetidos se refactorizan en un nico
lugar, aplicando el principio DRY: No te repitas (Dont Repeat Yourself).
2.2.9.2. NAVIGATIONAL DEVELOPMENT TECHNIQUES (NDT)
NDT (Navigational Development Techniques) es una tcnica para
especificar, analizar y disear el aspecto de la navegacin en aplicaciones
web. Para la presente investigacin esta metodologa es relevante para la
definicin y captura de requisitos.
Escalona y otros (2004, p. 354), refieren que la a aportacin ms
importante de NDT es que ofrece una gua sistemtica para el tratamiento de
la navegacin y la interfaz. En este sentido, se podra indicar que NDT es
una propuesta orientada al proceso.
98
NDT describe de manera detallada todos los pasos que hay que realizar
para tratar los requisitos y a partir de ellos conseguir los modelos de anlisis.
Por otro lado, es una propuesta orientada a la tcnica. En todo el proceso
propuesto por NDT se indica qu tcnicas hay que usar, el modelo de
aplicacin y el resultado que hay que obtener. Y, por ltimo, es una
propuesta orientada al resultado. Tras la aplicacin de las tcnicas se
consiguen resultados y modelos cuya nomenclatura y estructura est
completamente detalladas en NDT.
En este orden de ideas, Escalona y otros (2004, pp. 354-355), sealan
que el ciclo de vida de NDT est compuesto por dos fases: la ingeniera de
requisitos y el anlisis. Aunque, en principio, ambas son secuenciales, el
proceso de NDT no lo es, puesto que en muchos momentos se puede
realizar la vuelta atrs para corregir errores o incongruencias:
a) La fase de ingeniera de requisitos de NDT es una ingeniera de
requisitos guiada por objetivos. En la primera etapa de la ingeniera de
requisitos se definen cules son los objetivos del sistema a desarrollar y en
base a ellos se capturan y definen los diferentes requisitos del sistema. Los
requisitos en NDT son agrupados segn su carcter en requisitos de
almacenamiento de informacin, requisitos de actores, requisitos funcionales,
requisitos de interaccin y requisitos no funcionales. Cada grupo de
requisitos es tratado de una manera particular, adecuada a su tipologa. Una
vez capturados y definidos los requisitos se pasa a la validacin de los
mismos.
99
Si durante la validacin se detectan errores, se vuelve a la captura y

definicin hasta llegar al resultado final adecuado. Este resultado final queda
plasmado en el documento de requisitos del sistema.
b) Con el documento de requisitos, se pasa a la fase de anlisis.
Durante la fase de anlisis se generan varios modelos. El primero de ellos es
el modelo conceptual. El modelo conceptual en NDT representa la estructura
esttica del sistema y viene representado por un diagrama de clases. La
generacin de este modelo consta dedos partes, la primera de ellas es
sistemtica y permite conseguir un modelo conceptual bsico desde los
requisitos.
El resultado de este proceso sistemtico suele coincidir bastante con el
modelo conceptual ms adecuado para el sistema, pero por si se pudieran
realizar mejoras que aumenten la calidad del resultado, NDT propone una
segunda etapa en el proceso de creacin del modelo conceptual.
En esta segunda etapa, NDT propone una serie de revisiones en las
que el analista debe ir aplicando su experiencia para revisar los resultados
del modelo bsico. La aplicacin de estas revisiones tiene dos ventajas. La
primera de ellas es que, a pesar de que NDT ofrezca el proceso sistemtico,
tambin deja libertad al analista para aplicar su experiencia. Pero por otro
lado, tambin permite detectar incongruencias y errores cometidos durante la
fase de ingeniera de requisitos. Por ello, puede ser posible que durante esta
actividad del anlisis haya que volver a la ingeniera de requisitos a modificar
los resultados.
100
El segundo modelo que se genera durante el anlisis es el modelo de

navegacin. En NDT el modelo de navegacin se compone de una serie de
diagramas, con una notacin estereotipada a partir del diagrama de clases
de UML. Los diferentes diagramas se corresponden a los sistemas de
navegacin para los diferentes roles de usuario que interactan con el
sistema.
Al igual que en el modelo conceptual, el proceso de generacin del
modelo de navegacin consta de dos partes. La primera de ellas es
sistemtica y permite conseguir un modelo de navegacin bsico desde los
requisitos. La segunda igualmente consiste en revisar el resultado del
proceso sistemtico para detectar incongruencias cometidas y para que el
analista aplique su experiencia. Tambin durante esta segunda etapa se
pueden detectar incongruencias en el resultado de ingeniera de requisitos
que puede obligar a volver a la fase anterior para realizar revisiones.
Todos estos cambios que se pueden producir durante la generacin del
modelo de navegacin o del modelo conceptual estn controlados y
detallados
en
NDT.
NDT
ofrece
una
gua
completa
de
posibles
modificaciones e indica cmo afectan a fases y resultados anteriores.

Cuando se tienen el modelo conceptual y de navegacin, se genera en NDT
la interfaz abstracta. sta no viene representada por un diagrama, sino por
un conjunto de prototipos evaluables por el usuario. Tambin durante la
evaluacin de estos prototipos se pueden detectar errores que obliguen a
volver a la etapa anterior.
101
Todo este proceso se representa en la figura 19 mediante un diagrama

de actividades.
Figura 19
Descripcin general de las actividades de NDT
Fuente: Escalona y otros (2004, p. 355)
2.2.9.3. DESIGN-DRIVEN REQUIREMENTS ELICITATION (DDRE)
Escalona y Koch (2002, pp. 16 17) refieren que Design-driven
Requirements Elicitation es parte del proceso design-driven que proponen
Lowe y Eklund para el desarrollo de aplicaciones Web. La propuesta consiste
en realizar la captura, definicin y validacin de requisitos durante el proceso
de diseo. Ello hace necesario que las actividades de diseo sean realizadas
de modo que los requerimientos pueden ser tratados y administrados.
102
En este orden de ideas, las anteriores autoras tambin refieren que el

proceso se basa en el uso de prototipos para ayudar al cliente en la
exploracin de las posibles soluciones y de los problemas que tienen que ser
resueltos. Los usuarios o clientes definen sus requerimientos basndose en
la observacin o trabajo con estos prototipos. Es un proceso iterativo que
consiste en reducir la incertidumbre del cliente. El ciclo tiene tres fases:
evaluacin, especificacin y construccin.
Finalmente, las anteriores autoras refieren que este proceso fue
definido sobre la base de un exhaustivo anlisis de best practices en el
desarrollo de aplicaciones comerciales para el entorno Web. Esta
metodologa trata a todos los requisitos de la misma manera; estos requisitos
son: de contenido, de protocolo de interfaces, de estructura navegacional, de
look and feel, de representacin interna de datos, de versionamiento, de
control de cambios, de seguridad, de gestin de contenido, de acceso de
control, de eficiencia, de monitoreo del usuario, de soporte de funcionalidad,
de adaptacin del sistema, de identificacin del usuario y sus derechos de
acceso, entre otros.
Los
investigadores
del
presente
trabajo,
verifican
que
como
continuacin de la metodologa Navigational Development Techniques, luego

del proceso de elicitacin, se generar el Documento de Requisitos del
Sistema (DRS), el cual contendr el diseo lgico de la aplicacin solicitada.
De acuerdo a Durn y Bernrdez (2000, p. 9) sealan que el
Documento de Requisitos del Sistema debe poseer el contenido tal como es
103
visualizado en la figura 20:
Figura 20
Estructura del Documento de Requisitos del Sistema
Fuente: Durn y Bernrdez (2000, p. 11)
A) LA PORTADA
La portada del DRS debe tener el formato que puede verse en la figura
21. Los elementos que deben aparecer son los siguientes:
a) Nombre del proyecto: al cual que pertenece el DRS.
b) Versin: la versin del DRS que se entrega al cliente. La versin se
compone de dos nmeros X e Y. El primero indica la versin, y se debe
incrementar cada vez que se hace una nueva entrega formal al cliente.
Cuando se incremente el primer nmero, el segundo debe volver a comenzar
104
en cero. El segundo nmero indica cambios dentro de la misma versin an

no entregada, y se debe incrementar cada vez que se publica una versin
con cambios respecto a la ltima que se public y que no se vaya a entregar
formalmente todava.
c) Fecha: fecha de la publicacin de la versin.
d) Equipo de desarrollo: nombre de la empresa o equipo de desarrollo.
e) Cliente: nombre del cliente, normalmente otra empresa.
Figura 21
Portada del Documento de Requisitos del Sistema
B) LA LISTA DE CAMBIOS
El documento debe incluir una lista de cambios en la que se
especifiquen, para cada versin del documento, los cambios producidos en el
mismo con un formato similar al que puede verse en la figura 22. Para cada
cambio realizado se debe incluir el nmero de orden, la fecha, una
descripcin y los autores.
105
Figura 22
Lista de Cambios del Documento de Requisitos del Sistema
C) NDICE
El ndice del DRS debe indicar la pgina en la que comienza cada
seccin, subseccin o apartado del documento. En la medida de lo posible,
se sangrarn las entradas del ndice para ayudar a comprender la estructura
del documento.
D) LISTAS DE FIGURAS Y TABLAS
El DRS deber incluir listas de las figuras y tablas que aparezcan en el
mismo. Dichas listas sern dos ndices que indicarn el nmero, la
descripcin y la pgina en que aparece cada figura o tabla del DRS.
E) INTRODUCCIN
Esta seccin debe contener una descripcin breve de las principales
caractersticas del sistema software que se va a desarrollar, la situacin
actual que genera la necesidad del nuevo desarrollo, la problemtica que se
acomete, tcnicas de elicitacin utilizadas y cualquier otra consideracin que
site al posible lector en el contexto oportuno para comprender el resto del
documento.
106
F) PARTICIPANTES EN EL PROYECTO
Esta seccin debe contener una lista con todos los participantes en el
proyecto, tanto desarrolladores como clientes y usuarios. Para cada
participante se deber indicar su nombre, el papel que desempea.
G) DESCRIPCIN DEL SISTEMA ACTUAL
Esta seccin debe contener una descripcin del sistema actual en el
caso de que se haya acometido su estudio.
H) OBJETIVOS DEL SISTEMA
Esta seccin debe contener una lista con los objetivos que se esperan
alcanzar cuando el sistema software a desarrollar est en explotacin, los
cuales pueden considerarse como requisitos de alto nivel, de forma que los
requisitos propiamente dichos seran la forma de alcanzar los objetivos. La
plantilla propuesta para los objetivos puede verse en la figura 23.
Figura 23
Plantilla de Objetivos del Sistema
107
I) CATLOGO DE REQUISITOS DEL SISTEMA

Esta seccin se divide en las siguientes subsecciones en las que se
describen los requisitos del sistema. Cada uno de los grandes grupos de
requisitos, de almacenamiento de informacin, funcionales y no funcionales,
podrn dividirse para ayudar a la legibilidad del documento, por ejemplo
dividiendo cada subseccin en requisitos asociados a un determinado
objetivo, requisitos con caractersticas comunes, entre otros.
J) REQUISITOS DE ALMACENAMIENTO DE INFORMACIN
Esta subseccin debe contener la lista de requisitos de almacenamiento
de informacin que se hayan identificado, en la figura 24 se observa la
plantilla para los requisitos de almacenamiento de informacin.
Figura 24
Plantilla para los Requisitos de Almacenamiento de Informacin
108
K) REQUISITOS FUNCIONALES
Esta subseccin debe contener la lista de requisitos funcionales que se
hayan identificado, la plantilla respectiva se observa en la figura 25.
Figura 25
Plantilla para los Requisitos Funcionales
Fuente: Durn y y Bernrdez (2000, p. 35)
109
L) DIAGRAMA DE CASOS DE USO

Este apartado debe contener los diagramas de casos de uso del
sistema que se hayan realizado.
M) DEFINICIN DE LOS ACTORES
Este apartado debe contener una lista con los actores que se hayan
identificado, especificados mediante la plantilla para actores de casos de uso
descrita figura 26.
Figura 26
Plantilla para los Actores del Sistema
N) CASOS DE USO DEL SISTEMA
Este apartado debe contener los casos de uso que se hayan
identificado,
especificados
mediante
la
plantilla
para
los
requisitos
funcionales, en este caso se pueden elaborar diagramas de procesos y

diagramas de relaciones de casos de uso.
O) REQUISITOS NO FUNCIONALES
Esta subseccin debe contener la lista los requisitos no funcionales del
sistema que se hayan identificado, especificados mediante la plantilla para
requisitos no funcionales descrita la figura 27.
110
Figura 27
Plantilla para los Requisitos No Funcionales
P) MATRIZ DE RASTREABILIDAD OBJETIVOS/REQUISITOS
Esta seccin debe contener una matriz objetivorequisito, de forma que
para cada objetivo se pueda conocer con qu requisitos est asociado. El
formato de la matriz de rastreabilidad puede verse en la figura 28.
Figura 28
Matriz de rastreabilidad del Documento de Requisitos del Sistema
111
2.3. PROCESOS DE INVESTIGACIN

En este apartado se presentar el estudio realizado sobre la variable
procesos de investigacin, el mismo constituye un aporte terico, en virtud a
la poca teora detectada sobre el tema. Para ello, se har referencia a todos
los aspectos tericos relativos a los procesos administrativos y acadmicos, y
as vislumbrar la concepcin sobre estos aspectos.
2.3.1. DEFINICIONES
2.3.1.1. PROCESOS
Segn Diccionario de la Real Acadmica Espaola, proceso es el
conjunto de las fases sucesivas de un fenmeno natural o de una operacin.
Por su parte, Heredia (2001, p. 41), lo define como un conjunto lgico
de actividades relacionadas que toma entradas de proveedores, les aade
valor y produce unas salidas para sus clientes.
En lneas generales, puede decirse que un proceso es el conjunto de
actividades que comprenden una serie de pasos divididos en etapas, los
cuales son coordinados y ejecutados persiguiendo un fin u objetivo.
2.3.1.2. GESTIN
Gestionar, segn el diccionario de la Real Academia Espaola de la
Lengua, es hacer diligencias conducentes al logro de un negocio o de un
deseo cualquiera.
112
Este enunciado evoca alto sentido de ejecucin o de actuacin, dirigida

en el cumplimiento de un encargo. Eso bien puede llevar a la idea de que
gestin no es simplemente resolver asuntos singulares sino que reclama
tambin el ejercicio de unas tareas genricas que la configuran.
2.3.2. ACTIVIDADES ADMINISTRATIVAS
Segn Stoner (1996, p. 7), la administracin consiste en darle forma,
de manera consistente y constante, a las organizaciones, las cuales cuentan
con personas que tienen el encargo de servirles para alcanzar sus metas.
Por su parte, Robbins y DeCenzo (2002 p. 5), sealan:
la administracin es el proceso para conseguir que se hagan las cosas
con eficiencia y eficacia, a travs de otras personas y junto con ellas;
eficiencia es hacer algo correctamente, se refiere a la relacin entre los
insumos y los productos buscando reducir al mnimo los costos de los
recursos; eficacia es hacer lo correcto, alcanzar las metas.
Estos conceptos hacen referencia al funcionamiento, la estructura y el
rendimiento de las organizaciones. La administracin puede ser entendida
como la disciplina que se encarga del manejo cientfico de los recursos y de
la direccin del trabajo humano, enfocada a la satisfaccin de un inters. Se
infiere que la Administracin es el proceso de lograr que las cosas se
realicen por medio de la planeacin, organizacin, delegacin de funciones,
integracin de personal, direccin y control de otras personas, creando y
manteniendo un ambiente en el cual la persona se pueda desempear
entusiastamente en conjunto con otras, sacando a relucir su potencial,
eficacia y eficiencia y lograr as fines determinados.
113
2.3.2.1. PLANIFICACIN
De acuerdo a Stoner (1996, p. 11), planificar implica que los
administradores piensan con antelacin en sus metas y acciones, y que
basan sus actos en algn mtodo, plan o lgica, y no en corazonadas.
Robbins y DeCenzo (2002, p. 80), sealan que planificar:
Abarca definir los objetivos o las metas de la organizacin, establecer
una estrategia general para alcanzar esas metas y preparar una amplia
jerarqua de planes para integrar y coordinar las actividades, tambin se
refiere a los fines (lo que se har) y a los medios (cmo se har).
Por su parte, Reyes (2004, p. 244) la planeacin consiste en fijar el
curso concreto de accin que ha de seguirse, estableciendo los principios
que habrn de orientarlo, la secuencia de operaciones para realizarlo y las
determinaciones de tiempos y de nmeros necesarias para su realizacin.
La planificacin (o planeacin) puede considerarse como el arte de
saber administrar las cosas, aun se diga esto en forma subjetiva se destaca
este hecho como una actividad intrnsecamente humana, a pesar de que
existen diversas metodologas que la apoyen siempre ser el factor humano
quien marque la diferencia, ya que un gerente conocedor de sus recursos
materiales y humanos sabr encontrar la mejor manera de combinarlos.
2.3.2.2. ORGANIZACIN
Segn Stoner (1996, p. 12), organizar es el proceso de ordenar y
distribuir el trabajo, la autoridad y los recursos entre los miembros de una
organizacin, de tal manera que stos puedan alcanzar las metas.
114
Por su parte, Chiavenato (2007, p. 76), refiere que organizacin es el
establecimiento de la estructura formal de autoridad, que integre, defina y
coordine las subdivisiones de trabajo, en pos del objetivo buscado.
Para Reyes (2004, p. 276), el concepto de organizacin implica:
a) Partes y funciones diversas. Ninguna organizacin tiene partes
idntica ni de igual funcionamiento.
b) Unidad funcional. Esas partes diversas tienen, con todo, un fin
comn e idntico.
c) Coordinacin y autoconstruccin. Precisamente para lograr ese fin
cada una de las partes pone una accin distinta, pero complementaria de las
dems; obran en vista del fin comn y ayudan a las dems a construirse y
ordenarse conforme a una teleologa especfica.
Los autores antes referidos coinciden al destacar la organizacin como
fuente de la autoridad, cuyas palabras claves son estructura, orden y
objetivo, es decir la organizacin es el proceso de ejercer el liderazgo y la
autoridad dentro de una estructura organizacional, coordinando las diferentes
entidades que conforman su estructura y cuyo resultado es alcanzar las
metas y objetivos.
2.3.2.3. CONTROL
Stoner (1996, p. 12), refiere que el gerente debe estar seguro de los
actos de los miembros de la organizacin que, de hecho, la conducen hacia
las metas establecidas.
115
Por su parte Reyes (2004, p. 440) al referirse sobre control seala: es
la recoleccin sistemtica de datos para conocer la realizacin de los planes,
todo control implica, necesariamente, la comparacin de lo obtenido con lo
esperado. Asimismo, Reyes (2004, p. 441) tambin hace referencia sobre la
importancia del control: (a) cierra el ciclo de la administracin, de hecho, los
controles son a la vez medios de previsin; y (b) se da en todas las dems
funciones administrativas, es por ello un medio para manejarlas o
administrarlas.
Por ltimo, Robbins y DeCenzo (2002, p. 412), refieren que el control
es el proceso de vigilar las actividades con el fin de asegurarnos que se
realicen conforme a los planes y de corregir las desviaciones importantes.
De acuerdo a estos sealamientos puede asumirse que el control
implica supervisin, lo cual no sera lo correcto puesto que los autores
coinciden en que es ms bien el establecimiento de mecanismos para el
seguimiento de las actividades las cuales deben ir ejecutando acorde a lo
planificado.
2.3.2.4. COMUNICACIN
Chiavenato (2007, p. 76) Es la actividad de mantener informados de lo
que pasa a aquellos ante quienes el jefe es responsable; esta actividad
presupone la existencia de registros, documentacin, investigacin e
inspecciones.
Rebeil y RuizSandoval (1998, p. 223), refieren:
116
La comunicacin da vida al sistema organizacional, pues constituye el

medio para obtener la accin de todos sus integrantes. El desarrollo de
la mayor parte de las actividades organizacionales incluye procesos de
comunicacin. Por lo tanto la organizacin constituye un sistema de
proceso de mensajes.
Puede decirse que la comunicacin en las organizaciones es el acto de
informar, transmitir mensajes de diverso contenido bajo el contexto
organizacional y que puede fluir dentro del entramado de su estructura as
como tambin hacia sus clientes y proveedores.
2.3.2.5. DIRECCIN
Segn Stoner (1996, p. 13), dirigir implica mandar, influir y motivar a los
empleados apara que realicen tareas esenciales.
Para, Robbins y DeCenzo (2002, p. 9) la direccin consiste en motivar a
los subordinados, influir en los individuos y los equipos mientras hacen su
trabajo, elegir el mejor canal de comunicacin y ocuparse de cualquiera otra
manera del comportamiento de los empleados.
Los referidos autores coindicen en sealar que la direccin implica
motivacin al personal, ejerciendo liderazgo con las debidas acciones
necesarias para el mantenimiento de un buen clima organizacional, usando
los diversos mecanismos de comunicacin diseados para tal fin.
2.3.2.6. COORDINACIN
De acuerdo a Chiavenato (2007, p. 76), la coordinacin es el deber de
establecer relaciones entre las diferentes partes del trabajo.
117
En www.managershelp.com se refiere:
Coordinar es establecer la armona entre todos los actos de una
empresa de manera de facilitar su funcionamiento y procurar el buen
xito. Es dar al organismo material y social de cada funcin las
proporciones convenientes para que sta pueda cumplir su misin en
forma segura y econmica.
La coordinacin es entonces la actividad de relacionar todos los
elementos que conforman la organizacin, la aplicacin de la misin y de la
visin as como la aplicacin de los objetivos son sus tareas claves.
2.3.3. PROCESOS ACADMICOS
2.3.2.1. DEFINICIONES
Los procesos acadmicos son todos aquellos trmites relacionados
con la vida acadmica del estudiante referido a los procesos de matrcula,
pagos,
evaluacin
de
docentes,
consulta
de
notas
horarios.
(http://www.ucentral.edu.co/)
Desde del punto de vista organizacional, Villavicencio y otros (2007),
refieren:
Los procesos acadmicos son los espacios de interaccin para el
desarrollo personal, disciplinar y profesional de profesores y
estudiantes. Permiten el trnsito desde la misin, el Proyecto
Institucional, hacia el logro de los ideales de formacin de la carrera o
programa y de las funciones sustantivas de la Universidad. Estos
procesos se vuelven fundamentales en el dinamismo del desarrollo
acadmico y posibilitan la transformacin de los estudiantes en
profesionales conscientes de su deber social y comprometido con las
necesidades del pas.
Por su parte Bustos y otros (2002) sealan:
118
Los procesos acadmicos son los factores que guan el desarrollo de

esta estrategia para con ello investigar las variables involucradas en el
proceso de tutela en lnea: la relacin tutores-tutelados, los resultados
obtenidos en el desempeo de los estudiantes al aplicar estrategias de
tutela y las facilidades u obstculos que el uso de la tecnologa presenta
para una estrategia de esta naturaleza.
A la luz de estas definiciones, una aproximacin al concepto de
procesos acadmicos depender desde el punto de vista de los actores que
participan en dichos procesos, evidentemente son procesos administrativos
que estn inmersos en el contexto de la administracin y las actividades
administrativas, desde el punto de vista de los estudiantes son los trmites
que deben realizar, para los profesores son servicios de apoyo en los cuales
ellos tambin participan de un modo u otro y para los funcionarios
administrativos son espacios en donde desempean sus funciones.
Es por ello que la relevancia de los procesos acadmicos estriba en que
son servicios que las instituciones ofrecen para que sus miembros soliciten
informacin, las instituciones estructuran y crean el espacio necesario para
que se desenvuelvan efectivamente dichos procesos.
2.3.2.2. LA ADMINISTRACIN EN LA EDUCACIN SUPERIOR
De acuerdo a Mazaira (2008, p. 1) la gestin acadmica es un proceso
complejo que involucra la entrada de recursos diversos (tangibles e
intangibles), un procesamiento de la complejidad ms elevada que pueda
existir (pues tiene que vrselas con el desarrollo de las capacidades
intelectuales
emotivas,
que
involucra
aspectos
aptitudinales
119
actitudinales), y genera salidas bajo la forma de productos de alta

complejidad como: nuevos conocimientos, profesionalidad, habilidades
cognoscitivas, investigativas, capacidades de solucin en el descubrimiento,
formulacin, planteamiento y resolucin de problemas profesionales,
pretendiendo que se minimicen los errores y se maximicen los aciertos en
aras de garantizar el continuado progreso de la sociedad humana en
equilibrada armona con la naturaleza a la que pertenece.
Lo anterior implica que el proceso de gestin acadmica realizado por
los departamentos docentes suelen presentar distinta complejidad segn las
tareas que le correspondan. Una de las distinciones ms significativas est
asociada al hecho de que tengan la responsabilidad de una carrera o
especialidad o el que no tengan como contenido el trabajo en esta direccin.
Esta complejidad puede simplificarse en trminos de factores histricos
y de las interrelaciones entre las unidades acadmicas administrativas,
dichos factores histricos estaran representados por la informacin registrada en diferentes perodos de tiempo, cambios curriculares, cambios en las
normativas, en fin, todos los factores que inciden en los registros almacenados y que deben ser tomados en cuenta a la hora de brindar informacin.
A la luz de estas ideas, se infiere que los procesos de investigacin son
la secuencia lgica relacional de actividades acadmicas y administrativas,
efectuadas por individuos o instituciones, quienes presentan sus productos
de investigacin ante un grupo evaluador sentenciando su aprobacin o no
en cumplimiento con lo exigido con las ctedras de investigacin.
120
3.
SISTEMA DE VARIABLES
3.1. VARIABLE NOMINAL

Para la presente investigacin se sealan como variables nominales las
siguientes: SISTEMA DE INFORMACION, AMBIENTE WEB y PROCESOS
DE INVESTIGACION
3.2. VARIABLE CONCEPTUAL
3.2.1. SISTEMA DE INFORMACIN
Se define los sistemas de informacin, como cualquier otro sistema
dentro de la organizacin, cuyas funciones son procesar entradas, mantener
archivos de datos relacionados con la organizacin y producir informacin,
reportes y otras salidas Senn (2003, p. 23).
3.2.2. AMBIENTE WEB
Se define ambiente web como el sistema mundial de redes de
computadoras interconectadas que se acerca cada vez ms al mismo
proceso: aumentar la disponibilidad de la informacin y la facilidad y la
velocidad de comunicacin. Mediante la conexin de millones de
computadoras, hace posible que un usuario en cualquier parte del mundo
intercambie texto, imgenes, videos, programas de computo y cualquier cosa
que pueda almacenarse en forma digital con cualquier otra persona que
121
pertenezca al mundo conectado (Norton, 2001, p. 291).

3.2.3. PROCESOS DE INVESTIGACIN
Los procesos de investigacin son la secuencia lgica relacional de
actividades acadmicas y administrativas, efectuadas por individuos o
instituciones, quienes presentan sus productos de investigacin ante un
grupo evaluador sentenciando su aprobacin o no en cumplimiento con lo
exigido con las ctedras de investigacin (Garca, Molina y Pirela, 2011).
3.3. VARIABLE OPERACIONAL
3.3.1. SISTEMA DE INFORMACIN
Es la herramienta utilizada con el fin de apoyar los procesos de
investigacin
del
Programa
Posgrado
de
la
Universidad
Nacional
Experimental Rafael Mara Baralt, facilitando la planificacin, evaluacin,

comunicacin y control del proceso de inscripcin de proyectos de tesis de
grados de los estudiantes - participantes de dicha institucin
3.3.2. AMBIENTE WEB
Es el medio a travs del cual los estudiantes - participantes de todas las
sedes del Programa Posgrado de la Universidad Nacional Experimental
Rafael Mara Baralt registran tanto los datos como los archivos del proyecto
de tesis de grado, realizando la inscripcin del mismo para su posterior
122
evaluacin por un profesor evaluador quien comunicar las observaciones al

estudiante participante.
3.3.3. PROCESOS DE INVESTIGACIN
Es el conjunto lgico de actividades acadmico - administrativas
relacionadas, las cuales son realizadas por los estudiantes - participantes en
el Programa Postgrado de la UNERMB, dirigidas por la Coordinacin de
Investigacin, las cuales producen como resultado la aprobacin o no de las
mismas en cumplimiento con lo exigido con las ctedras Trabajo de Grado.
4.
DEFINICIN DE TRMINOS BSICOS

Analista de Sistemas: es la persona clave en cualquier proyecto de
desarrollo de sistemas, interacta con los dems participantes del proyecto

con el fin de recabar informacin para crear un software especfico.
Desarrollo Rpido de Aplicaciones (Kendall y Kendall, 2005, p. 161): es
un enfoque orientado a objetos para el desarrollo de sistemas que incluye un
mtodo de desarrollo como as tambin herramientas software (Yourdon,
1993, p. 63).
Entrevista: Es una conversacin dirigida con propsito especfico que
utiliza un formato de preguntas y respuestas, se utiliza para obtener
opiniones de los entrevistados y su parecer acerca del estado actual del
sistema, metas organizacionales y personales y procedimientos informales
(Kendall y Kendall, 2005, p. 90).
123
Programacin Extrema (XP): es un enfoque de desarrollo de sistemas

que acepta lo que se conoce como buenas prcticas de desarrollo de
sistemas y las lleva al extremo (Kendall y Kendall, 2005, p. 68).
Prototipo: Versin funcional preliminar de un sistema de informacin
con prototipos de demostracin y evaluacin (Laudon y Laudon, 2005, p.
395).
Sistema: Es un conjunto de componentes que interaccionan entre s
para lograr un objetivo comn. (Senn, 1992, p. 19):
Usuarios: Es aqul (aqullos) para quien se construye el sistema. Es la
persona a la que tendr que entrevistar el analista de sistemas, a menudo
con gran detalle, a fin de conocer las caractersticas que deber tener el
nuevo sistema para tener xito (Yourdon, 1993, p. 46)
CAPITULO III
MARCO METODOLOGICO
CAPITULO III
MARCO METODOLOGICO
En este captulo se abarcan todos los elementos relativos a los
fundamentos metodolgicos que hicieron posible la realizacin de esta
investigacin. En primer lugar, se presentan los aspectos tericos y
metodolgicos en los cuales se basa la investigacin con el fin de
caracterizarla para facilitar el entendimiento, comprensin y consolidacin del
proyecto. Asimismo se expone el modelo de recoleccin de datos y por
ltimo se presentan las fases que guiaron el desarrollo de la investigacin.
1.
TIPO DE INVESTIGACIN
La presente investigacin es considerada de tipo No Experimental
Descriptiva, segn Hernndez y otros (2006, p. 189), en un estudio no

experimental no se construye ninguna situacin, sino que se observan
situaciones ya existentes, no provocadas por el investigador.
De igual manera, se dice que esta investigacin es No experimental ya
que no hay manipulacin de hiptesis as como lo explica Hernndez y otros
(2006, p. 267): En los estudios no experimentales no se manejan hiptesis,
sino
que
se
observan
situaciones
intencionalmente por el investigador.
125
ya
existentes,
no
provocadas
126
Asimismo, la presente investigacin es descriptiva, tal como lo seala

Sabino (2002, p. 36), este tipo de investigacin describe caractersticas
fundamentales de un conjunto homogneo, utilizando criterios sistemticos
para destacar los elementos esenciales de su naturaleza. De esta forma se
pueden obtener notas que caracterizan la realidad estudiada.
Ahora bien, en referencia a los criterios de clasificacin las
investigaciones descriptivas segn Sierra (2004, p. 32), a continuacin se
desprende la siguiente caracterizacin para la presente investigacin:
a) Por su finalidad, coincidiendo con Balestrini (2003, p. 8), es de tipo
factible ya que se elabor la propuesta de un modelo operativo viable para la
institucin donde se realiz la investigacin.
b) En cuanto al alcance temporal, es prospectiva, porque la
planificacin se cumpli en el tiempo establecido, partiendo del presente a
futuro.
c) Por la profundidad, es descriptiva, porque su objetivo fue medir una o
ms variables en una poblacin o muestra de poblacin.
d) Por la amplitud, es microsociolgica, porque las mediciones se
efectuarn sobre grupos pequeos y a los que se observaran para conocer la
variable de estudio.
e) Por el marco de estudio, es de campo, los datos sern recolectados
directamente dentro del entorno donde se suscitarn los hechos.
De acuerdo a la problemtica planteada, se aplic una investigacin no
experimental descriptiva con finalidad de proyecto factible en el sentido de
127
estudiar un fenmeno sin alterarlo bajo ningn tratamiento, solamente se

recogieron los datos que permitieron explicar la situacin objeto de estudio y
as crear un sistema de informacin bajo ambiente web para el Programa
Postgrado de la Universidad Nacional Experimental Rafael Mara Baralt.
2.
DISEO DE LA INVESTIGACIN
El diseo consiste en un plan que se desarrolla para obtener
informacin acerca de la investigacin. Segn Balestrini (2003, p. 147): el

diseo de la investigacin se define como el plan global de investigacin que
integra las tcnicas de recoleccin de datos, anlisis previstos y objetivos.
Una vez decidido el enfoque adoptado, el cual para la presente investigacin
es cualitativo, y definido el alcance inicial del estudio, el diseo a aplicar en
esta investigacin es el transversal descriptivo.
Con este tipo de diseo, los datos se obtendrn de manera directa, tal
como lo afirma Sabino, (2002, p. 64): En el diseo de campo los datos de
inters se obtienen de forma
directa de la realidad, mediante el trabajo
concreto del investigador y su equipo.

Asimismo, el diseo de este estudio tambin es transversal, puesto que
se obtendr informacin a travs de una tcnica para su recoleccin. Segn
Hernndez y otros (2003, p. 270): La investigacin transversal consiste en la
recoleccin de datos en un solo momento, en un tiempo nico con el
propsito de describir variables y analizar su incidencia e interpretacin en un
momento dado.
128
3.
TCNICAS PARA LA RECOLECCIN DE DATOS

De acuerdo al estudio terico, todos los aspectos metodolgicos de la
presente investigacin giraron en torno a la ingeniera de requisitos, como

qued establecido anteriormente, la misma comprende la definicin de los
requisitos y la elaboracin del modelo conceptual del sistema.
Tal y como lo refiere Zapata y otros (2010, p. 27) la definicin de
requisitos se consideran cuatro procesos fundamentales: educcin, anlisis,
especificacin y validacin de requisitos. La educcin de requisitos es el
proceso donde los interesados descubren, articulan y entienden sus
requisitos y es en este proceso donde se realiza la recoleccin de los
requisitos que formaran los modelos de anlisis utilizados en los siguientes
procesos.
En este sentido, para la realizacin de la presente investigacin se
escogi como tcnica para la recoleccin de datos el modelo del dilogo
enfocado a la captura de requisitos, de acuerdo a Zapata y Carmona (2008,
p. 210) incluye
transversales
la
a
definicin
cualquier
de
unos
proceso
de
temas generales
educcin
de
que
son
requisitos,
independientemente del dominio al cual se dirija, un conjunto de etiquetas

de dilogo que permiten establecer cules deben ser los actos de dilogo
que harn parte del proceso de educcin y una estructura general de las
preguntas, en la cual se combinan los elementos anteriormente descritos
para establecer la manera como se puede realizar la entrevista.
129
En la figura 29, mediante un esquema preconceptual, que es un

grfico que permite la representacin del conocimiento, se propone un
modelo de dilogo que permite hacer una educcin de requisitos entre un
sistema informtico y un interesado.
Figura 29
Modelo de Dilogo para la Educcin de Requisitos
Fuente: Zapata y Carmona (2010, p. 215)
Zapata y Carmona (2010, p. 216) refiriendo la figura anterior sealan
que los rectngulos en lnea continua representan los conceptos relativos a
la educcin de requisitos y al modelo del dilogo; los rectngulos en
130
lnea
discontinua
son posibles valores del concepto al que estn
ligados (por ejemplo, primero es un posible valor de nivel); los valos

se denominan relaciones y son verbos (cabe anotar que los verbos en
valos con lnea continua son nicamente es y tiene, que se conocen
como
relaciones
estructurales y los verbos
en valos con lnea
discontinua son verbos de accin, denominados relaciones dinmicas; la

flecha gruesa que une verbos como inicia y responde, expresa una
relacin causaefecto, que se lee si el analista inicia el acto de
dilogo, entonces el interesado responde el acto de dilogo; las
flechas delgadas son elementos de unin de conceptos a relaciones
viceversa; finalmente, las lneas discontinuas unen los conceptos con sus
posibles valores.
Con este modelo, se busca una forma de encontrar o extraer la
informacin precisa del interesado, para poder hacer un proceso eficiente
de educcin de requisitos. Se pretende, tambin, definir las bases para
implementar el modelo en un sistema informtico que asista el proceso
de educcin de requisitos.
La etiquetacin de las frases se realiza de la siguiente manera: al
final de cada frase, se coloca entre llaves el tipo de acto de dilogo,
discriminando primero las etiquetas de primer nivel y, separadas por
coma, se colocan luego las de segundo nivel y, as sucesivamente, a medida
que se profundice en el nivel de etiquetacin. Los siguientes, son ejemplos
de actos de dilogo etiquetados:
131
INTERESADO: De acuerdo. Comencemos. {Apertura}.

ANALISTA: En qu rea se ubica el problema? {Pregunta Declarativa}.
INTERESADO: intervienen en el proceso el profesor y el auxiliar de
docencia. {Respuesta Declarativa, Actor}.
INTERESADO: Para que un alumno reingrese a la carrera, debe
esperar al menos un semestre acadmico. {Respuesta Declarativa,
Problema, Restriccin}
Las entrevistas, se estructuran de la siguiente manera: una etapa
de
preparacin,
en
la
que
se definen las preguntas a realizar y se
establece un tiempo promedio para las preguntas y las respuestas, y una

etapa de desarrollo en donde se explica el objetivo y las metas de la
entrevista. Las
preguntas
se
deben
realizar
tratando
de
que la
conversacin no se salga de curso y teniendo en cuenta el siguiente

orden de temas:
Informacin sobre la entrevista.
Nombre de la Organizacin.
rea del problema.
Sntomas y Causas del problema.
Actores.
Funciones de los actores.
Restricciones del problema.
A medida que se vaya desarrollando la entrevista, se
realiza
la
etiquetacin de las preguntas y respuestas. En el anexo 1 se registran las
132
entrevistas efectuadas para el proceso de educcin de requisitos

desarrollado en el estudio de campo.
4.
METODOLOGA
Para el desarrollo del Sistema de Informacin basado en Ambiente Web
para los Procesos de Investigacin del Programa Posgrado de la Universidad

Nacional Experimental Rafael Mara Baralt, se utiliz una metodologa
hbrida compuesta por las metodologas de Escalona, Torres y Mejas (2004),
Lowe y Eklund (2002) y Potencier y otros (2008), en virtud a que se
adaptaban a los objetivos de investigacin, esto es porque la investigacin se
bas en requisitos de usuarios, por ser stos de carcter dinmico someta el
prototipo a constantes modificaciones hasta alcanzar la aplicacin definitiva.
La metodologa as propuesta qued construida de la siguiente forma:
FASE I: Descubrimiento de Requisitos. Siguiendo los lineamientos de la
metodologa Navigational Development Techniques (Escalona, Torres y
Mejas, 2004), en esta fase se llev a cabo el estudio mediante el cual los
clientes/usuarios y los desarrolladores identifican, revisan, articulan y
entienden los requisitos de aplicacin y su objetivo es capturar las
necesidades de los clientes, usuarios y otros interesados que tienen relacin
con la aplicacin.
El descubrimiento de requisitos implica entender el dominio de la
aplicacin organizando del conocimiento que conforma el sistema de
negocios que ser servido por la aplicacin, los problemas de informacin
133
que se quieren resolver y las necesidades de los usuarios de la aplicacin. Al

final de esta fase se llev a cabo la elaboracin del listado de requisitos
funcionales.
FASE II: Anlisis de Requisitos. Siguiendo los lineamientos de la
metodologa Navigational Development Techniques (Escalona, Torres y
Mejas, 2004) esta fase tiene por propsito conseguir una comprensin ms
precisa de los requisitos y una descripcin de los mismos que sea fcil de
mantener y que permita a los desarrolladores estructurar el sistema
completo, incluyendo la arquitectura.
Esta fase inicia con la clasificacin de los requisitos, sigue con la
negociacin de requisitos, modelado del problema, diseo inicial de la
arquitectura, elaboracin del listado tentativo de Requisitos Funcionales
Definitivos, el cual ser analizado, discutida, validado y firmado por los
usuarios expertos en el dominio de la aplicacin.
FASE III: Evaluacin de Requisitos de Prototipos. Siguiendo los
lineamientos de la metodologa Design-driven Requirements Elicitation (Lowe
y Eklund, 2002) se construy el prototipo del sistema sobre la base de los
requisitos recolectados en la fase anterior, a travs de un proceso recursivo
en el que se revisan los requisitos tomando de ellos las caractersticas
necesarias para disear el prototipo, de ser necesario, volver a la fase
anterior para efectuar los cambios necesarios y solicitados por los usuarios.
FASE IV: Construccin de la Aplicacin. Siguiendo la metodologa de
Potencier y otros (2010) en esta fase se llev a cabo la construccin de la
134
aplicacin generando las lneas de cdigo y de configuracin necesarias para

crear las vistas las cuales constituirn la capa interfaz con el usuario, los
controladores los cuales constituyen la capa de las reglas del negocio y el
modelo de datos el cual ser la estructura desde donde se comunicar la
aplicacin con el manejador de base de datos.
FASE V: Cierre de la aplicacin. Siguiendo la metodologa de Potencier
y otros (2010) en esta fase se realiz la publicacin del Sitio WEB, las
pruebas unitarias, pruebas funcionales y la aceptacin y culminacin del
Sistema.
Cuadro 6
Cuadro de Actividades
OBJETIVOS
ESPECIFICOS
FASES
METODOLOGICAS
ACTIVIDADES
RECURSOS Y
TECNICAS
Analizar la situacin
actual de los procesos
y procedimientos
acadmicos de la
Coordinacin de
Investigacin del
Programa Posgrado de
la Universidad
Experimental Rafael
Mara Baralt
FASE I
Descubrimiento de
Requisitos
(Escalona, Torres y
Mejas, 2002)
Estudio del entorno del

sistema
Establecimiento de los
objetivos
Entendimiento del
dominio
Organizacin del
conocimiento
Recoleccin de
requisitos
Elaboracin del listado
de requisitos funcionales
Entrevistas
Encuesta
Observacin
Directa
Recoleccin de
Documentacin
Diagramas y
Modelos
Determinar los
requerimientos del
Sistema de
Informacin para su
desarrollo en la
Coordinacin de
Investigacin del
Programa Posgrado de
la Universidad
Experimental Rafael
Mara Baralt.
FASE II
Anlisis de
Requisitos
(Escalona, Torres y
Mejas, 2002)
Clasificacin de los
requisitos
Negociacin de
Requisitos
Modelado del Problema
Diseo inicial de la
arquitectura
Elaboracin del listado
tentativo de Requisitos
Funcionales Definitivos
Entrevistas
Observacin
Directa
Patrones
Grafos
Modelos
135
CUADRO 6. CONTINUACIN
OBJETIVOS
ESPECIFICOS
Disear lgica y
fsicamente un sistema
de informacin bajo el
ambiente Web
tomando en cuenta los
requerimientos
encontrados en la
recopilacin de datos.
Evaluar la operatividad
del sistema de
informacin mediante
pruebas pertinentes.
FASES
METODOLOGICAS
ACTIVIDADES
RECURSOS Y
TECNICAS
FASE III
Evaluacin de
Requisitos de
Prototipos
(Lowe y Eklund,
2002)
Definicin de requisitos
de contenido
Definicin del protocolo
de interfaces
Diseo de la estructura
navegacional
Diseo de la
representacin interna
de datos
Establecimiento del
sistema versionamiento
Diseo del control de
cambios, seguridad, de
acceso y control, de
monitoreo del usuario,
de identificacin del
usuario y sus derechos
de acceso
Entrevistas
Observacin
Directa
Tormentas de
Ideas
Mockups
(maquetas de
interface de
usuario)
Pencil
Sketching Tool
FASE IV
Construccin de la
Aplicacin.
(Potencier y otros,
2010)
Configuracin del
Servidor Web
Creacin del proyecto,
las aplicaciones y los
mdulos
Construccin del Modelo
de datos
Establecimiento las
vistas
Establecimiento de los
controladores
Enrutamiento de los
mdulos
FASE V
Cierre de la
aplicacin
(Potencier y otros,
2010)
Publicacin del Sitio

Entrevista con
WEB
los usuarios
finales
Pruebas unitarias
Pruebas funcionales
Aceptacin y
Culminacin del Sistema
Fuente: Garca, Molina y Pirela (2011)
Gedit
Nano
pgDesigner
Apache2
PostgreSQL
SymfonyPHP
Netbeans
HTML
Javascript
CAPTULO IV
RESULTADOS DE LA INVESTIGACIN
CAPTULO IV
RESULTADOS DE LA INVESTIGACIN
En este captulo se presentan los resultados obtenidos en la
investigacin, comenzando por el anlisis de los datos recolectados en el
estudio de campo, siguiendo con la discusin de los resultados y finalmente
las conclusiones y recomendaciones.
1.
ANLISIS DE LOS DATOS

A continuacin se presentan los datos obtenidos en el estudio de
campo y sus respectivos anlisis en funcin a los objetivos de la

investigacin.
1.1. DESCUBRIMIENTO DE REQUISITOS
En esta fase los clientes/usuarios trabajando conjuntamente con los
desarrolladores identificaron, revisaron, articularon y entendieron los
requisitos de aplicacin, para capturar las necesidades de los clientes,
usuarios y otros interesados que tienen relacin con la aplicacin en
correspondencia con el primer objetivo de la presente investigacin el cual es
analizar la situacin actual de los procesos y procedimientos acadmicos de
la Coordinacin de Investigacin del Programa Posgrado de la UNERMB.
137
138
1.1.1. DOMINIO DE LA APLICACIN

El dominio de la aplicacin lo conforma el sistema de negocio (o de
inters) donde se ubicar la aplicacin y el supra sistema acadmico
administrativo compuesto por todos los dems sistemas: Sistema de Control
y Evaluacin, Sistema de Gestin de Bibliotecas, Sistema de Registro de
Lneas de Investigacin, el Portal Web, Sistema de Ingresos Propios y el
Sistema Integrado de Gestin Administrativa. La siguiente figura representa
el Modelo de Dominio de la aplicacin.
Figura 30
Modelo de Dominio de la aplicacin
139
El sistema de inters esta conformado por los subsistemas Inscripcin

de Proyectos de Investigacin (semi automtico), Evaluacin de Proyectos
de Investigacin (manual), Consulta de Proyectos de Investigacin (manual)
y la Validacin de Proyectos de Investigacin (manual), adicionalmente se
realizan actividades de apoyo administrativo las cuales permiten relacionar a
los subsistemas.
Con el subsistema Inscripcin de Proyectos de Investigacin se realizan
todas las actividades acadmico administrativas iniciando en el instante en
el que el participante de cualquiera de las maestras solicita informacin para
la inscripcin del proyecto de investigacin y finalizando cuando se le reporta
al participante la evaluacin de su proyecto, la cual, de ser aceptada le
permitir avanzar en su recorrido acadmico siendo el siguiente paso la
inscripcin de la tesis y su posterior defensa para la
aprobacin de la
maestra. Este subsistema solo se encuentra automatizado a nivel de

emisin de la planilla de inscripcin del proyecto (en formato pdf), la cual
debe ser llenada y presentada en la unidad de atencin a la investigacin
como recaudo obligatorio para inscribir el proyecto de investigacin.
En este orden de ideas, el subsistema de inscripcin de proyectos de
investigacin se interrelaciona con los subsistemas evaluacin y validacin
los cuales se activan en paralelo una vez iniciado el proceso, el subsistema
Validacin de Proyectos de Investigacin es llevado a cabo por la
Coordinacin de Maestra y cuyas actividades estn referidas a la validacin
de los proyectos registrados, dichas actividades son: verificacin de la
140
autenticidad del ttulo de los proyectos de investigacin (ttulo no repetido y/o

investigacin no realizada anteriormente), correspondencia de los objetivos
con el tema de investigacin, entre otras. El subsistema de evaluacin de
proyectos consiste en seleccionar un profesor de planta que labore en la
misma maestra del participante y que se especialice en el tema del proyecto,
a quien se le entrega un dossier (o expediente) consistente del proyecto mas
un instrumento de evaluacin.
El subsistema consulta de proyectos de investigacin tiene como
propsito ofrecer toda la informacin relativa a los proyectos de investigacin
y tesis de grado ya procesados con anterioridad, por un lado permite a la
Coordinacin de Investigacin y a las Coordinaciones de las Maestras
realizar sus procesos de validacin de proyectos de investigacin.
Los
subsistemas
antes
referidos
requieren
de
actividades
administrativas de apoyo secretarial para el archivado de los expedientes de

proyectos de investigacin, tomos anillados de los proyectos, registro
histrico, entre otros. Asimismo, los subsistemas tambin requieren de
actividades acadmicas referidas a planificacin de las actividades
coordinacin con las dems dependencias del Postgrado UNERMB.

El Suprasistema acadmico administrativo est conformado por el
Sistema de Control y Evaluacin (SICE), el Sistema de Gestin de Biblioteca
(SIREBI), el Portal Web www.unermb.edu.ve, el Sistema para el Registro de
Lneas de Investigacin (ARBOL ACAD), el Sistema de Ingresos Propios
(SIGREP) y el Sistema Integrado de Gestin Administrativa (SIGA).
141
A travs del Sistema de Control y Evaluacin (SICE) se realizan todas

las actividades acadmicas de la Unidad de Control de Estudios, Evaluacin,
Procesamiento e Informtica (CEEPI), siendo la encargada de administrar la
base de datos acadmica de las notas de los participantes, dicho sistema se
encuentra totalmente automatizado a nivel de intranet en la sede Cabimas y
en estaciones independientes en las sedes forneas.
Con el Sistema de Gestin de Bibliotecas (SIGEBI) se registran y
controlan los prstamo de libros, llevando el seguimiento de los mismos y
reportando en caso de los participantes que estn en situacin de morosidad
por no regresar los libros a tiempo o sancionados por prdida de libros.
El Portal Web www.unermb.edu.ve, es el portal institucional de la
UNERMB, a travs del mismo se ofrece a la comunidad universitaria y
pblico en general una gran variedad de informacin. Adems, tambin
residen en el portal varios sistemas en lneas, algunos ya implementados y
otros en fase de construccin.
El Sistema de Lneas de Investigacin es un sistema que reside en el
Portal Web y que tiene por objetivo el registro y mantenimiento de los grupos
de formacin de nuevos investigadores. A travs de este sistema los
profesores investigadores pueden conformar grupos desde donde los tesistas
pueden registrarse para formarse como futuros investigadores.
El Sistema de Ingresos Propios se encarga de todas las actividades
administrativas tales como el registro de los pagos por las diferentes
actividades acadmicas, este sistema es una aplicacin que reside en
142
equipos independientes, se maneja una base de datos en Microsoft Access

en donde se registran todas las transacciones administrativas de los
estudiantes.
Por ltimo, el Sistema Integrado de Gestin Administrativa (SIGA), el
cual es un sistema en lnea que reside en el Portal Web, dicho sistema tiene
los
diferentes
mdulos
para
el
control
administrativo:
contabilidad,
presupuesto, entre otros, los cuales son utilizados por todas las unidades
administrativas para la gestin administrativa centralizada de la institucin.
Los sistemas que conforman el suprasistema del Programa Posgrado
de la UNREMB actividades acadmicas y administrativas de apoyo
secretarial para el archivado, enlace con las otras dependencias y sistemas,
comunicacin interna, coordinacin, entre otras actividades.
1.1.2. OBJETIVOS DEL NEGOCIO
Misin: La Unidad de Atencin a la Investigacin tiene como misin el
Registro y control de los procesos administrativos y tcnicos relacionados
con la investigacin, tanto en su nivel de proyecto como de trabajo de grado
y tesis doctoral, permitiendo a los participantes, la socializacin del
conocimiento y satisfaciendo la necesidad de sistematizar los procesos de
formacin de un personal de cuarto nivel.
Visin: La Unidad de atencin a la investigacin se constituye como
una estructura tcnico administrativa del Programa Postgrado que permitir
sistematizar y consolidar la administracin de los procesos de registro y
143
seguimiento de los proyectos, trabajos de grado y tesis doctorales que se

ejecutan en el Programa de Postgrado con el propsito de socializar los
conocimientos generados y el intercambio de estos con la sociedad,
fomentando la transformacin del
talento humano y el modelo social
productivo de la regin.
Objetivo General: Coordinar los procesos administrativos y tcnicos
relacionados con la produccin de conocimientos cientficos, tecnolgicos y
humansticos, en el campo de las ciencias puras y aplicadas, en funcin a las
necesidades sociales y contextualizadas en el rea de conocimientos del
Programa Acadmico, que facilite el intercambio de saberes, cultural con la
sociedad.
Objetivos Especficos:
a) Registrar el proceso de inscripcin de proyectos, trabajos de grado y
tesis doctorales.
b) Administrar el proceso de defensas de trabajos de grado y tesis
doctorales.
c) Promover el intercambio cientfico, tecnolgico, humanstico, cultural
entre el programa acadmico y la sociedad.
En la figura 31 se detalla el modelo de los objetivos de negocio de la
Unidad de Atencin a la Investigacin UNERMB, en dicho modelo se explica
la relacin entre la misin, la visin (objetivos operacionales), el objetivo
general, los objetivos especficos (nivel operacional), el problema (nivel
estratgico) y los procesos fundamentales (procesos de negocio).
144
Figura 31
Modelo de los objetivos de negocio de la Unidad de Atencin a la
Investigacin UNERMB
Fuente: Castro (2011)
145
1.1.3. PROCESOS DE NEGOCIO (CADENA DE VALOR)

La cadena de valor de una empresa permite enlazar sus procesos
fundamentales con los proveedores y clientes de la misma. Una red de valor
mejora la competitividad promoviendo el uso de estndares y al dar a las
empresas la oportunidad de trabajar de manera ms eficiente.
Los procesos fundamentales identificados anteriormente se valen de
una serie de procesos de apoyo que le aportan valor (o peso organizacional)
los cuales se ven reflejados en la siguiente figura:
Figura 32
Modelo de procesos negocio de la Unidad de Atencin a la Investigacin
Los procesos de apoyo de soporte tcnico est conformado por las
actividades de mantenimiento de los sistemas y del hardware; asimismo los
procesos de apoyo de soporte secretarial y de servicios son las actividades
de atencin a los participantes, archivado, elaboracin de comunicaciones,
entre otras; por ltimo, los procesos de apoyo de soporte acadmico son
todas las actividades acadmicas sobre planificacin y coordinacin.
146
1.1.4. REGLAS DE NEGOCIO

En el siguiente cuadro se plasmaron las reglas de negocio de la Unidad
de Atencin a la Investigacin del Programa Posgrado de la UNERMB
describiendo en trminos generales las polticas, normas, operaciones,
definiciones y restricciones presentes en dicha dependencia y que son de
vital importancia para alcanzar los objetivos misionales.
Cuadro 7
Reglas de Negocio de la Unidad de Atencin a la Investigacin
CODIGO
NOMBRE
DESCRIPCION
FORMULA
FUENTE
RN-01
Calificacin
Se expresar por medio de

un nmero entero
comprendido entre cero
(00) a veinte (20)
Artculo 22
Reglamento de
Evaluacin
UNERMB
RN-02
Calificacin
Definitiva
Se expresar como la
acumulacin de las
calificaciones obtenidas en
cada una de las
actividades de evacuacin
Se considera aprobada la
cuando la calificacin definitiva
sea mayor o igual a 12 puntos,
de lo contrario es reprobada
RELACION: RN-01
Artculo 25
Reglamento de
Evaluacin
UNERMB
RN-03
ndice
Acadmico
Define la actuacin general

del estudiante en relacin a
todas las unidades
curriculares cursadas en la
maestra
Se obtiene multiplicando la
calificacin lograda en cada
asignatura por el numero de
crditos que le corresponden, se
suman los productos y este resultado se divide entre la suma
de los crditos computados.
RELACION: RN-02
Artculo 10
Reglamento de
Evaluacin
UNERMB
RN-04
Solvencia
Define si el participante
Administrati- est o no al da con la
va
cancelacin del pago de
los semestres
El participante est solvente si la

no tiene pendiente pagos por
concepto de cancelacin de
semestres anteriores
Departamento
Administracin
Posgrado
UNERMB
RN-05
Solvencia de Define si el participante

Biblioteca
est o no solvente con la
biblioteca
El participante est solvente si

no tiene libros en calidad de
prstamo, ha cancelado todas
las multas por concepto de libros
prestados y no devueltos o si fue
sancionado por extravo
Sistema de
Registro y
Control de
Biblioteca
RN-06
Eje de
Define las asignaturas que
Investigacin aprob el participante y
aprobado
que conforman el eje de
investigacin hasta el 3er
semestre
Metodologa de la Investigacin
I, Metodologa de la
Investigacin II y Tesis I
RELACION: RN-02
Pensum de
Estudios de las
Maestras del
Posgrado
UNERMB
147
CONTINUACION CUADRO 7
CODIGO
NOMBRE
DESCRIPCION
FORMULA
FUENTE
RN-07
Evaluadores
y Tutores de
Proyecto de
Investigacin
Define los requisitos para

que una persona sea
Evaluador de Proyectos de
Investigacin
1. Ser investigador en el rea de

conocimiento en la cual se
desarrolla el trabajo de
investigacin
2. Poseer un grado acadmico
igual o superior al de Magster
3. El evaluador debe ser
profesor de planta
Artculo 22 de
las Normas para
la inscripcin,
sustentacin y
evaluacin de
proyectos de
investigacin
RN-08
Proyecto de Define las caractersticas

Investigacin mnimas para que un
documento sea
considerado Proyecto de
Investigacin
Problema de investigacin,
objetivos, sustentacin terica y
metodolgica incluyendo
tcnicas e instrumento(s) de
recoleccin de datos, redactado
en trminos de una investigacin
completa faltando solo la
validacin, confiabilidad y
aplicacin del instrumento.
Artculo 9 de las
Normas para la
inscripcin,
sustentacin y
evaluacin de
proyectos de
investigacin
RN-09
Inscripcin
Define el inicio del proceso
del Proyecto de investigacin
de
Investigacin
Requisitos Acadmicos:
culminacin del eje de
investigacin
RELACIONES: RN-03 y RN-06
Requisitos administrativos:
planilla de registro del proyecto,
proyecto anillado, carta de designacin de la tutora, currculo
del tutor (en caso de no ser
profesor de planta), solvencia
acadmica, solvencia administrativa, solvencia de biblioteca,
constancia de pago de registro
RELACIONES: RN-04, RN-05
Artculo 15 de
las Normas para
la inscripcin,
sustentacin y
evaluacin de
proyectos de
investigacin
RN-10
Nombramien Define los requisitos para

to del tutor
que una persona sea
aceptada como tutor de
Proyectos de Investigacin
1. El aspirante dirigir una

solicitud a la Coordinacin
Acadmica respectiva en donde
propondr el tutor y lo
acompaar del respectivo
currculum vitae y carta de
aceptacin.
2. Ser designado por la
Coordinacin Acadmica
respectiva, considerando el rea
de conocimiento, previa revisin
de las credenciales.
RELACION: RN-07
Artculo 24 de
las Normas para
la inscripcin,
sustentacin y
evaluacin de
proyectos de
investigacin
RN-11
Proyecto en Define la revisin del

revisin
contenido del proyecto
RELACION: RN-08
Artculo 13 de
las Normas para
la inscripcin,
sustentacin y
evaluacin de
proyectos de
investigacin
148
CODIGO
NOMBRE
DESCRIPCION
FORMULA
RN-12
Tutor
rechazado
Define el lapso que el

participante debe cumplir
para proponer un nuevo
tutor
30 das continuos a la
inscripcin del proyecto de
investigacin.
RELACION: RN-09
RN-13
Proyecto
evaluado
Define la validacin del

Calificacin: Aprobado o
Evaluador a travs de la
Rechazado
gua de evaluacin para el RELACION: RN-08
registro de las
observaciones y
sugerencias
FUENTE
Artculo 24 de
las Normas para
la inscripcin,
sustentacin y
evaluacin de
proyectos de
investigacin
Artculo 23 de
las Normas para
la inscripcin,
sustentacin y
evaluacin de
proyectos de
investigacin

1.1.5. ACTORES DEL PROYECTO
A continuacin se especifican, los tipos de actores del proyecto
(stakeholders) que de alguna manera intervienen en las etapas del proyecto
para el desarrollo del software, agrupados de la siguiente manera:
Usuarios Directos: Son aquellos usuarios que de alguna manera
interactan en algunos de los procesos del sistema, estos son: los
Coordinadores y los encargados de las Unidades de Atencin.
Miembros del grupo de desarrollo: entre ellos se encuentran los
siguientes actores: el analista de sistema, el analista programador y el
diseador grfico.
Asesores del proyecto: son los actores que suministran informacin
tcnica al proyecto.
Clientes del Proyecto: estos los actores que usarn el sistema.
149
Cuadro 8
Actores del Proyecto
CODIGO
USUARIO
DESCRIPCIN
TIPO
ACT-01 Coordinador Este actor representa al personal

de
encargado de la coordinacin,
Investigacin planificacin y evaluacin de todas
las actividades acadmicas
Usuario
Directo
ACT-02 Coordinador Es el encargado la validacin de los

de Maestra proyectos de investigacin y la
asignacin de los docentes
evaluadores
Usuario
Directo
ACT-03 Encargados
de las
Unidades de
Atencin a la
Investigacin
Este actor representa al personal

responsable de tramitar todos los
procesos fundamentales y servir de
intermediarios entre los clientes y el
Programa Posgrado
Usuario
Directo
ACT-04 Analista de
Sistemas
Es la persona que traduce las necesidades de los usuarios directos y

clientes en los procesos de negocio
en funcin de los objetivos estratgicos que dan origen al proyecto
Miembro
del Grupo
de
Desarrollo
ACT-05 Analista
Es responsable en el uso de las
Programador herramientas y metodologas
computacionales adecuadas para la
elaboracin del sistema
Miembro
del Grupo
de
Desarrollo
ACT-06 Diseador
Grfico

responsable en el uso de las
herramientas y metodologas
computacionales adecuadas para la
creacin de la interface del sistema
con los usuarios
Miembro
del Grupo
de
Desarrollo
ACT-07 Director
Informtica
Este actor es la persona que asesora Asesor

al grupo de desarrollo en todo lo
del
relacionado a los servicios
Proyecto
informticos de la institucin
ACT-08 Docentes
Evaluadores seleccionado por el coordinador de
investigacin para evaluar a los
participantes que consignaron el
proyecto de investigacin al
Programa Posgrado de la UNERMB
Cliente
del
Proyecto
ACT-09 Participantes Estos actores son los estudiantes

participantes de las diferentes
maestras del Posgrado UNERMB
que usarn el nuevo sistema
Cliente
del
Proyecto
SMBOLO
150
1.1.6. DESCRIPCIN DEL PROBLEMA

De acuerdo a entrevistas realizadas a los usuarios directos y anlisis
efectuados sobre el modelo de negocio se evidenci lo siguiente:
1. Se genera mucho papeleo. Al momento del registro de los
proyectos de investigacin, los encargados de las Unidades de Atencin a la
Investigacin arman los expedientes, en el cual rene toda la documentacin
consignada por el participante, el tomo del proyecto y finalmente se archiva
en el expediente la gua de evaluacin suministrada por el evaluador.
Por expediente se contabilizan siente (7) folios entre los recaudos y
solvencias, la gua de evaluacin tiene cinco (5) folios, opcionalmente se
adiciona el currculum vitae del tutor en el caso de que no sea profesor de
planta. Se observa que el expediente del proyecto de investigacin puede
contener entre quince (15) y treinta (30) folios mas el tomo del proyecto el
cual puede variar entre cincuenta (50) y cien (100) pginas, todo esto
multiplicado por el nmero de participantes que inscriben el proyecto trae en
consecuencia un volumen considerable de papel que se debe almacenar
para efectuar el proceso de inscripcin de proyectos de investigacin.
2. El retardo en la evaluacin de los proyectos de investigacin. La
gua de evaluacin a pesar de estar correctamente estructurada no permite
agilizar el proceso debido a que son varios folios y el evaluador tiene la
necesidad de revisar de adelante hacia atrs todos los temes para que su
evaluacin sea pertinente con el proyecto de investigacin.
151
Por otro lado, tampoco hay facilidades para la entrega y recepcin de

dicho documento, el evaluador es notificado de que fue seleccionado para
evaluar un proyecto de investigacin y tiene que ir personalmente a retirar el
tomo y la gua de evaluacin. Posteriormente tiene que regresar la gua con
los resultados y el tomo con las observaciones. Tambin puede inferirse que
en el armado del expediente puede estar la raz de este problema, ya que los
encargados de las unidades de atencin a la evaluacin tienen que coordinar
con los coordinadores de investigacin en las sedes para la seleccin del
evaluador y el armado de las carpetas de evaluacin, las cuales contienen el
instrumento de evaluacin y el tomo.
3. No hay control en la validacin de los proyectos. Se pudo
observar que el Coordinador de Investigacin y los Coordinadores de las
diferentes maestras del Posgrado de la UNERMB deben acudir a su
experiencia y memoria para poder validar la autenticidad de los proyectos de
investigacin debido a que no puede revisar uno a uno los tomos de tesis de
investigacin aprobadas, hay un gran volumen de stos almacenados en la
biblioteca, tampoco hay un registro digital fidedigno y completo, solo existe
informacin dispersada en bases de datos, hojas de clculo y documentos de
texto.
Este problema puede propiciar el plagio entre los participantes lo cual
representa una falla en la visin de la unidad de atencin a la investigacin
en cuanto a que no hay efectividad al momento de realizar seguimientos a
los proyectos de investigacin.
152
4. Redundancia de tareas en los procesos. En cada paso del proceso

de inscripcin de proyectos de investigacin hay redundancia debido a que
se debe revisar continuamente uno a uno la aplicacin del reglamento,
puesto que es necesario verificar la aplicacin de las reglas de negocio.
Esto trae en consecuencia que se exija mucho esfuerzo a los
evaluadores, al coordinador de investigacin y a los encargados de las
unidades de atencin a la investigacin para velar por el fiel cumplimiento de
los reglamentos.
5. No existe un enlace con el suprasistema ni entre los procesos
del sistema. Entre los recaudos que consignan los participantes, se exige la
constancia de notas expedida por El Centro de Estudios, Evaluacin,
Procesamiento e Informtica (CEEPI) ubicada en la sede Cabimas,
igualmente tambin se solicitan la solvencia administrativa expedida por los
administradores de las sedes y la solvencia de biblioteca expedida por las
bibliotecas en las sedes. La ausencia de bases de datos centralizadas,
interconexin entre las sedes y conexiones internas entre las unidades,
propicia el problema de que el participante debe realizar muchos recorridos
para la obtencin de los recaudos.
Por otro lado, cabe destacar el peligro de las falsificaciones ya que
cualquier persona con malicia puede consignar recaudos falsificados de una
sede a otra ya que se usan formatos que fcilmente se pueden escanear o
reproducir. Para evitar estas situaciones los encargados de las diferentes
unidades deben estar en contacto permanente haciendo engorroso la
153
coordinacin y administracin de los procesos. Todo esto trae como

consecuencia mucho retardo en los procesos.
6. La dispersin geogrfica entre las sedes. Como se refiri en el
planteamiento del problema, el Programa Posgrado de la UNERMB posee
varias sedes en los Estados Zulia y Falcn, este hecho obliga a actualizar
peridicamente las bases de datos acadmicas de una sede a otra. En la
sede de Cabimas se concentra toda la informacin, adems de actualizar las
bases de datos propias tambin hay que actualizar en ella la informacin de
las bases de datos forneas ya que no hay mecanismos automticos para
llevarlo a cabo, ello se hace porque se desea garantizar la confianza de la
informacin. Una vez culminado el proceso de concentracin de notas se
copian de nuevo las bases de datos en las sedes forneas, observndose
que culmina mucho despus de la finalizacin del perodo acadmico en
curso dndose el caso de que las notas del perodo anterior nunca estn
actualizadas sino varios meses despus de iniciado el perodo nuevo.
1.1.7. RECOLECCIN DE REQUISITOS FUNCIONALES
El tratamiento de requisitos es el proceso mediante el cual se
especifican y validan los servicios que debe proporcionar el sistema. Los
requisitos funcionales, son los requisitos en el cual se describe lo que la
aplicacin deber hacer, esto es la funcionalidad del sistema es decir los
servicios que el sistema prestar a los usuarios directos, la interaccin entre
la aplicacin y su dominio de aplicacin.
154
Entre las fuentes de informacin que se utilizaron para capturar los

requisitos funcionales del Sistema de Informacin basado en Ambiente Web
para los Procesos de Investigacin del Programa Posgrado de la UNERMB
se encuentra las siguientes:
a) Modelado de Negocios y los procesos, procedimientos y las
diagramas de actividades.
b) Evaluacin de los procesos actuales con: Entrevistas con los
encargados de las unidades de atencin a la investigacin de las sedes
Maracaibo y Cabimas.
c) Observacin directa de los procesos acadmicos y administrativos.
d) Recoleccin de las solicitudes por escrito por parte de los usuarios
involucrados en el modelo de negocio.
En el siguiente cuadro se muestra la primera lista preliminar de los
requisitos funcionales del Sistema de Informacin bajo Ambiente Web para
los Procesos de Investigacin del Programa Posgrado de la UNERMB, que
se extrajo de las entrevistas con los usuarios expertos en el dominio de los
procesos acadmicos administrativos, y donde cada requisito contiene:
a) Cdigo: es el identificador del requisito.
b) Descripcin del Requisito: es la descripcin definicin del requisito.
c) Usuario: es quien realiza el requisito
d) Proceso: es el proceso donde se deriva el requisito
e) Documento de Soporte: documentacin que sustenta el requisito.
f) Reglas del Negocio: reglas de negocio asociadas al requisito.
155
Cuadro 9
Lista Preliminar de Requisitos Funcionales
CODIGO
DESCRIPCIN
USUARIO PROCESO
DOCUMENTO REGLAS DE
MEDIO
DE SOPORTE NEGOCIO
RF-01 El sistema debe controlar cuando el participante puede inscribir el proyecto de investigacin
ACT-03
PF-01
Planilla de
Inscripcin
RN-06
Impreso
RF-02 El sistema debe verificar

que el participante curs
el eje de investigacin.
ACT-03
PF-01
Notas
Certificadas
por CEEPI
RN-06
Impreso
RF-03 El sistema debe realizar

la inscripcin de los
proyectos de
investigacin
ACT-03
PF-01
Planilla de
Inscripcin de
Proyectos de
Investigacin
RN-09
Archivo
PDF en
lnea
RF-04 El sistema debe verificar ACT-03

que el estudiante no tenga alguna cuota vencida
por concepto de
cancelacin de
semestre anteriores
PF-01
Solvencia
Administrativa
expedida por
la
Administracin
en la sede
RN-04
Impreso
RF-05 El sistema debe verificar

que el estudiante est
solvente con la biblioteca, (libros prestados
osancin por extravo)
ACT-03
PF-01
Solvencia de
Biblioteca
expedida por
la Biblioteca en
la sede
RN-05
Impreso
RF-06 El sistema debe capturar los datos principales

de los proyectos de investigacin: datos del
participante, tutor
seleccionado, ttulo y
objetivos
ACT-09
PF-01
Planilla de
Inscripcin de
Proyectos de
Investigacin
RN-08
Impreso
RF-07 El sistema debe

capturar los proyectos
de investigacin
ACT-09
PF-01
Tomo del
Proyecto de
Investigacin
RN-09
Impreso
RF-08 El sistema debe asignar

los proyectos de
investigacin a los
profesores evaluadores
asignados por rea
ACT-02
PF-01
Programacin
Acadmica
RN-07
Impreso
RF-09 El sistema debe permitir

la captura del currculo
de los tutores cuando no
sean profesores de
planta
ACT-09
PF-01
Currculo del
tutor
RN-09
Impreso
156
CODIGO
DESCRIPCIN
USUARIO PROCESO
DOCUMENTO REGLAS DE
MEDIO
DE SOPORTE NEGOCIO
RF-10 El sistema debe capturar ACT-02

la validacin de los
proyectos de
investigacin
PF-03
Tomo del
Proyecto
RN-08
RN-12
Manual
RF-11 El sistema debe capturar ACT-08

la evaluacin de los
proyectos de
investigacin
PF-02
Gua de
Evaluacin de
Proyectos de
Investigacin
RN-11
Impreso
RF-12 El sistema debe indicar

la aceptacin del
proyecto de
investigacin
ACT-02
PF-03
PF-04
Notificacin
RN-13
Impreso
RF-13 El sistema debe emitir el

resultado de la evaluacin de los proyectos de
investigacin
ACT-08
PF-02
PF-03
PF-04
Gua de
Evaluacin de
Proyectos de
Investigacin
RN-13
Impreso
RF-14 El sistema debe generar

estadsticas de proyectos de investigacin
por maestras
ACT-01
ACT-08
PF-01
PF-02
PF-03
PF-04
Expedientes
de Proyectos
de
Investigacin
RN-09
Impreso
1.2. ANLISIS DE REQUISITOS

Siguiendo con el segundo objetivo de la presente investigacin,
determinar los requerimientos del Sistema de Informacin para su desarrollo
en la Coordinacin de Investigacin del Programa Posgrado de la
Universidad Experimental Rafael Mara Baralt, en esta etapa se determin
una comprensin ms precisa de los requisitos y una descripcin de los
mismos que sea fcil de mantener y que ayude a estructurar el sistema.
Despus del chequeo, anlisis y verificacin por parte de los
clientes/usuarios expertos en el dominio de la aplicacin, se eliminaron siete
157
(7) requisitos funcionales, los restantes siete (7) fueron el resultado de la

negociacin de requisitos con los usuarios, cambiando usuarios de un
requisito a otro y viceversa (ver cuadro 10).
Cuadro 10
Lista Preliminar de Requisitos Funcionales (negociados)
CODIGO
DESCRIPCIN
USUARIO PROCESO
DOCUMENTO REGLAS DE
MEDIO
DE SOPORTE NEGOCIO

realizar la inscripcin
de los proyectos de
investigacin
ACT-09
PF-01
Formulario
Inscripcin de
Proyectos de
Investigacin
RN-04
RN-05
RN-06
RN-09
En lnea

capturar los proyectos
de investigacin
ACT-09
PF-01
Tomo del
Proyecto de
Investigacin
RN-09
En lnea

asignar los proyectos
de investigacin a los
docentes evaluadores
asignados por rea
ACT-02
PF-01
Programacin
Acadmica
RN-07
En lnea

permitir la captura del
currculo de los tutores
cuando no sean
profesores de planta
ACT-09
PF-01
Currculo del
tutor
RN-09
En lnea

capturar la validacin
de los proyectos de
investigacin
ACT-02
PF-03
Tomo del
Proyecto
RN-08
RN-12
En lnea

capturar la evaluacin
y emitir los resultados
de los proyectos de
investigacin
ACT-08
ACT-09
PF-02
Formulario
Evaluacin de
Proyectos de
Investigacin
RN-11
RN-12
RN-13
En lnea

generar estadsticas
de proyectos de
investigacin por
maestras
ACT-01
ACT-08
PF-01
PF-02
PF-03
PF-04
Expedientes
de Proyectos
de
Investigacin
RN-09
En lnea
Fuente: Cuadro 9
158
1.3. EVALUACIN DE REQUISITOS DE PROTOTIPOS

Siguiendo con el tercer objetivo, disear lgica y fsicamente un sistema
de informacin bajo el ambiente Web tomando en cuenta los requerimientos
encontrados en la recopilacin de datos, el propsito principal de esta etapa
es alcanzar una comprensin ms precisa de los requisitos y una descripcin
de los mismos que sea fcil de mantener y que ayude a estructurar el
sistema completo, hasta crear el diseo lgico del sistema
1.3.1. OBJETIVOS DEL SISTEMA
Esta seccin se presenta los objetivos que se esperan alcanzar cuando
se implemente el sistema de informacin, especificados mediante la plantilla
para objetivos. A continuacin se presentan los objetivos del sistema.
Objetivo 1
Inscribir los Proyectos de Investigacin
Versin
1.0
Fuentes
Coordinacin de Investigacin
Unidad de Atencin a la Investigacin sedes Maracaibo y
Unidad de Atencin a la Investigacin Sede Cabimas
Descripcin
El sistema deber permitir el registro de los datos de los proyectos

de investigacin.
Sub Objetivos
1.1.
El sistema debe permitir a los participantes registrar los

datos del proyecto de investigacin si el participante cumpli
con todos los requisitos acadmicos y administrativos.
1.2.
El sistema debe permitir a los participantes enviar el archivo

del proyecto de investigacin en formato Word o PDF
1.3.
El sistema debe emitir las observaciones sobre las razones

por las cuales el estudiante que no cumpli con todos los
requisitos no puede registrar el proyecto.
1.4.
El sistema debe emitir las observaciones del Coordinador de

Maestra sobre la validacin efectuada al proyecto de
investigacin.
Fecha: 28/05/2011
159
1.5.
El sistema debe informar al participante que debe efectuar

las correcciones para poder validar nuevamente el proyecto
de investigacin.
1.6.
El sistema debe informar al participante que el proyecto de

investigacin fue validado por el Coordinador de la Pasanta
y que se encuentra en fase de evaluacin
1.7.
El sistema debe informar al participante que el proyecto fue

aprobado o rechazado
Importancia: Vital
Urgencia: Inmediata
Estado: Validado
Estabilidad: Alta
Objetivo 2
Validar los Proyectos de Investigacin registrados
Versin
1.0
Fuentes
Coordinacin Maestra Gerencia Financiera
Descripcin
El sistema debe apoyar la validacin los datos de los proyectos de

investigacin registrados por los participantes
Sub Objetivos
2.1.
El sistema debe informar al Coordinador de la Maestra los

proyectos de investigacin registrados.
2.2.
El sistema solo mostrar los participantes de la maestra a la

cual est adscrito el coordinador.
2.3.
El sistema debe permitir al Coordinador de Maestra registrar

las observaciones al proyecto de investigacin validando el
ttulo, el objetivo general y los objetivos especficos.
2.4.
El sistema debe permitir al Coordinador de Maestra aceptar

o rechazar el tutor seleccionado en el proyecto de
investigacin que est validando
2.5.
El sistema debe permitir al Coordinador de Maestra

seleccionar el docente evaluador, de acuerdo a su no tiene
mucha carga docente y menos de cuatro (4) proyectos de
investigacin en fase de evaluacin
Importancia: Vital
Fecha: 28/05/2011
Urgencia: Inmediata
Estado: Validado
Estabilidad: Alta
Objetivo 3
Evaluar los Proyectos de Investigacin validados
Versin
1.0
Fuentes
Coordinacin Maestra Gerencia Financiera
Descripcin
El sistema deber permitir la evaluacin de los proyectos de

investigacin registrados por los participantes
Sub Objetivos
3.1.
Fecha: 28/05/2011
El sistema debe informar al Docente Evaluador los proyectos

de investigacin que les asign el Coordinador de la
160
Maestra
3.2.
El sistema debe permitir al Docente Evaluador registrar las

observaciones al proyecto de investigacin de acuerdo al
formulario de evaluacin del Programa Posgrado.
3.3.
El sistema debe permitir al Docente Evaluador registrar las

observaciones del proyecto de investigacin por pgina,
prrafo y lnea donde est la observacin
3.4.
El sistema debe permitir al Docente Evaluador al proyecto de

investigacin que est evaluando la calificacin de aprobado
o reprobado
Importancia: Vital
Urgencia: Inmediata
Estado: Validado
Estabilidad: Alta
Objetivo 4
Consultar los Proyectos de Investigacin validados
Versin
1.0
Fuentes
Descripcin
El sistema deber permitir consultar la informacin de todos los

proyectos de investigacin aprobados anteriormente.
Sub Objetivos
4.1.
Importancia: Vital
Fecha: 28/05/2011
El sistema deber permitir al Coordinador de Investigacin y

al Coordinador de Maestra consultar todos los proyectos de
investigacin aprobados
Urgencia: Inmediata
Estado: Validado
Estabilidad: Alta
Objetivo 5
Mantener los datos principales del sistema
Versin
1.0
Fuentes
Encargados de las Unidades de Atencin a la Investigacin
Descripcin
El sistema deber permitir realizar el mantenimiento de los datos

principales del sistema
Sub Objetivos
5.1.
El sistema deber permitir al Coordinador de Investigacin

consultar, modificar y agregar fechas topes para cada
cohorte en el cronograma de entregas de proyectos de
investigacin
5.2.
El sistema deber permitir al Coordinador de Maestra

consultar, modificar y agregar observaciones generales para
los campos tipo combo del mdulo de validacin
5.3.
El sistema deber permitir a los Encargados de las Unidades

de Investigacin consultar, modificar, agregar o eliminar
(cambiar estatus) estudiantes y docentes
Importancia: Vital
Fecha: 28/05/2011
Urgencia: Inmediata
Estado: Validado
Estabilidad: Alta
161
1.3.2. CATALOGO DE REQUISITOS FUNCIONALES

En el presente documento, los requisitos funcionales se presentan
agrupados de acuerdo a los elementos principales relacionados a la actividad
que se va a ejecutar, definiendo los diferentes mdulos del sistema.
1.3.2.1. REQUISITOS TRANSACCIONALES
El sistema debe permitir al Coordinador de Investigacin (ACT-01)
registrar las fechas topes por cohorte para la consignacin de los Proyectos
de Investigacin y visualizar el nmero de proyectos de investigacin
registrados, validados, evaluados y el nmero de participantes (ACT-09) que
inscribieron el proyecto de investigacin y los que todava no lo han hecho.
Los encargados de las unidades de atencin a la investigacin (ACT03) podrn visualizar cuales son proyectos de investigacin registrados,
validados,
evaluados
todos
los
participantes
(ACT-09)
que
les
corresponden inscribir el proyecto de investigacin y que todava no lo han

hecho. Tambin podrn visualizar los datos personales y acadmicos de
todos los participantes que inscribieron el proyecto de investigacin y todos
aquellos que les corresponden inscribirlo pero que todava no lo han hecho.
El sistema debe permitir a los participantes (ACT-09) realizar la
inscripcin de los proyectos de investigacin y revisar los resultados de la
validacin del coordinador de la maestra en la que est actualmente ubicado
y los resultados de la evaluacin del profesor evaluador que le fue asignado.
162
El sistema debe permitir a los Coordinadores de Maestras (ACT-02)

validar los Proyectos de Investigacin registrados (filtrado para la maestra a
la cual est adscrito el coordinador), agregar las observaciones en el ttulo de
la
investigacin,
objetivo
general
objetivos
especficos.
Si
hay
observaciones, se debe permitir escoger las razones existentes o anotar una

observacin personalizada la cual se deber anexar en la base de datos.
El sistema debe permitir al Coordinadores de Maestra (ACT-02)
seleccionar el docente evaluador (ACT-08) por cada proyecto registrado
(hasta 4 proyectos), stos solo pueden ser profesores de planta de la
maestra en donde est adscrito el coordinador y/o en la lnea de
investigacin a la cual se puede asociar el proyecto de investigacin.
Los lapsos legales contemplados en la normativa para la inscripcin,
sustentacin y evaluacin de proyectos inician cuando los Coordinadores de
Maestra (ACT-02) validan los proyectos de investigacin registrados, de esa
forma pasaran a la fase de evaluacin, los docentes evaluadores (ACT-08)
tendrn asignados los trabajos de investigacin y los participantes (ACT-09)
observarn el aviso de que sus trabajo estn en fase de evaluacin hasta
que reciban las observaciones o la notificacin de que fueron aprobados.
El sistema debe permitir a los Coordinadores de Maestra (ACT-02)
aadir, editar y consultar razones para las observaciones (ttulo de
investigacin, objetivo general, objetivos especficos).
El sistema debe permitir a los docentes evaluadores (ACT-08) registrar
la evaluacin de los participantes que les fueron asignados.
163
1.3.2.2. REQUISITOS DE SALIDA

El sistema debe permitir ordenar por fecha de registro, por nombres, por
maestra y por ttulo de proyecto en todos los grids.
El sistema debe notificar automticamente a los participantes cuantos
das les faltan para la culminacin de los lapsos: veinticinco (25) das para
que los evaluadores registren la evaluacin de los proyectos asignados,
treinta (30) das para que los participantes propongan un nuevo tutor.
El sistema debe emitir el reporte de trabajos de investigacin
registrados, en fase de validacin, en fase de evaluacin, ya aprobados,
reprobados, o en observaciones.
1.3.2.3. REQUISITOS DE DATOS
El sistema debe registrar el nmero consecutivo numrico de los
proyectos registrados, dicho nmero ser usado como nmero de expediente
del proyecto de investigacin.
El sistema debe registrar cada movimiento (registro, validacin,
evaluacin, consulta) con el nombre del usuario asociado, ms la fecha y
hora de creacin del movimiento y de la ltima operacin del registro.
1.3.3. REQUISITOS NO FUNCIONALES
Este tipo de requisitos especifican todos los aspectos relacionados con
las restricciones que el sistema debe cumplir, de forma que alcance su
164
mximo desempeo, puede decirse que son aquellos aspectos del sistemas
que no cumplen una funcin especfica pero que contribuyen a mejorar la
interaccin con los actores y el sistema.
1.3.3.2. REQUISITOS DE INTERFAZ
a) La interfaz debe estar integrada al portal web de la universidad,
manteniendo el encabezamiento, logotipos, men principal (a la izquierda) y
men de opciones desplegables (debajo del encabezado).
b) La interfaz debe ser en idioma espaol.
c) Debe permitir la visualizacin de toda la informacin requerida.
d) Debe ser verstil en la presentacin de la informacin: textos, conos,
entre otros.
e) Debe permitir identificar a travs de los despliegues:
Nombre del sistema / mdulo en que se encuentra el usuario.
Ttulo del despliegue.
Fecha actual en formato DD/MM/AAAAA.
Hora actual en formato HH:MM:SS AM/PM.

f) La interfaz debe poseer la capacidad de capturar y ofrecer opciones
para enviar datos hacia impresoras, archivos, e-mail o dispositivos

conectados a la red.
g) Debe utilizar los dispositivos de entrada (teclado, ratn) y de salida
(monitor pantalla plana) ms apropiados para el uso del sistema.
h) Cuando existan muchos campos para seleccionar dentro del
165
formulario, se deben combinar en el diseo radio button y botones

desplegables para evitar el excesivo despliegue de pantallas y lentitud,
agrupando los campos en cuadros de paneles.
1.3.3.2. REQUISITOS NAVEGACIONALES
a) La interfaz debe estar basada en ventanas, permitiendo el despliegue
de mens seleccionables dentro de la misma ventana.
b) Debe permitir despliegues de resolucin mnima de 1024x768 pxeles
y con capacidad de escalabilidad a la resolucin de la pantalla que se
disponga.
c) Debe permitir la visualizacin de la ayuda del sistema desde un
navegador Web (Manual del usuario en lnea).
d) Debe satisfacer las medidas de seguridad definidas por el propietario
del sistema.
f) Debe poseer botones de navegacin estndar (Inicio, Atrs, Imprimir,
Salir, entre otros)
g) La conexin al sistema debe ser a travs de http://
1.3.3.3. REQUISITOS DE PERSONALIZACIN
a) El sistema debe permitir la administracin de usuarios y la
configuracin del sistema, respetando los niveles de permisologa, as como
tambin de los respaldos segn la frecuencia requerida e histricos.
b) El sistema debe identificar en la barra de estado el usuario que est
166
utilizando el sistema.
c) El sistema debe mostrar a cada usuario slo las opciones y datos
permitidos de acuerdo a su perfil.
d) El acceso al sistema siempre deber ser a travs de un usuario, y
una clave.
1.3.3.4. REQUISITOS GENERALES
a) El sistema debe ser desarrollado en software libre.
b) El sistema debe asegurar la integridad de la base de datos.
c) El sistema debe ser flexible a fin de asegurar el ingreso y
actualizacin de componentes.
d) El diseo del sistema deber ser definido a travs de un conjunto de
clases y/o componentes reutilizables.
e) El sistema debe permitir realizar respaldos diarios.
1.3.4. DEFINICIN DE ACTORES
La definicin de actores permite identificar los lmites del sistema en
desarrollo. Fueron identificados como actores los cuales se comunicarn en
forma directa con el sistema a los participantes, los coordinadores de
maestra, los docentes evaluadores, el coordinador de investigacin y los
encargados de las unidades de atencin a la investigacin.
En el siguiente cuadro se describe la definicin de los actores del
sistema.
167
Cuadro 11
Definicin de Actores
ID
ROL
Actividades
Dependencia
EP Estudiante del Posgrado Inscribir Proyecto de Investigacin

CI Coordinador de
Investigacin
Planificar y Coordinar las

Actividades en Investigacin
Coordinacin de
Investigacin
CM Coordinador de Maestra Validar los Proyectos de

Investigacin Inscritos
Seleccionar los Evaluadores
Coordinacin de
Maestras
DE Docente Evaluador
Coordinacin de
Maestras
Evaluar los Proyectos de

Investigacin de los Participantes
EU Encargado de Unidad de Consultar, Modificar y Agregar

Unidades de
Atencin a la
Profesores, Participantes, Valores Atencin a la
Investigacin
del Sistema
Investigacin
Fuente: Garca, Molina y Pirela
1.3.5. CASOS DE USO DEL SISTEMA

Los
casos
de
uso
se
agruparon
por
criterios
funcionales,
organizndolos en niveles para facilitar su comprensin. Los paquetes que

los agrupan se identificaron con el estereotipo <<subsistema>> y se
muestran en la siguiente figura.
Figura 33
Diagrama de Subsistemas
168
En la presente investigacin se contempla el caso de uso de para la

inscripcin de proyectos de investigacin:
a) Registrar del Proyecto de Investigacin
b) Presentar Resultados del Proyecto de Investigacin
c) Validar Proyectos de Investigacin
d) Evaluar Proyectos de Investigacin
e) Mantener Datos
f) Planificar
Figura 34
Caso de Uso de la Inscripcin de Proyectos de Investigacin
169
1.3.6. EL PROTOTIPO
A continuacin se presenta el prototipo desarrollado conjuntamente con
los usuarios entrevistados, sobre la base del consenso de los requerimientos
negociados en la fase anterior.
Figura 35
Modulo Registro de Proyecto de Investigacin
170
Figura 36
Modulo Presentacin de Resultados
171
Figura 37
Modulo Validacin de Proyectos de Investigacin
172
Figura 38
Modulo Evaluacin de Proyectos de Investigacin
1.4. CONSTRUCCIN DE LA APLICACIN
Siguiendo con el tercer objetivo, disear lgica y fsicamente un sistema
de informacin bajo el ambiente Web tomando en cuenta los requerimientos
encontrados en la recopilacin de datos, se procede en esta fase al diseo
fsico de la aplicacin concretando todo lo realizado en las fases previas.
Las actividades de configuracin, puesta a punto del servidor,
construccin del proyecto y pruebas de la aplicacin se llevan a cabo a
travs de comandos ejecutados remotamente usando ssh (Secure Shell), la
ventaja de realizarlo as es que el servidor se instala con lo mnimo necesario
para funcionar de tal manera que no se desperdicien recursos (memoria,
espacio en disco duro, ciclos de procesamiento del procesador).
173
Cabe destacar las actividades de configuracin e instalacin del

servidor, los cuales son el fruto de la investigacin exhaustiva efectuada en
distintas fuentes (www.apache.org, www.php.net, www.postgresql.org, howto, entre otras) dicha investigacin nace de las sugerencias de los
prerrequisitos necesarios para instalar symfony.
1.4.1. CONFIGURACIN DEL SERVIDOR WEB
Antes de crear el sistema, es necesario instalar el servidor y configurar
los distintos componentes lgicos que integrarn el sitio web, siendo esta
actividad realizada una sola vez puesto que el servicio que se ofrecer a los
usuarios ser fsicamente centralizado y distribuido a travs de internet.
Previamente, se solicit al Director de Informtica de la UNERMB,
instalar la aplicacin en el servidor de la institucin, el cual est bajo Ubuntu
Server versin 10.10, dicho servidor funciona en la Zona Desmilitarizada
(DMZ) de la red protegida por dos (2) servidores cortafuego (firewall) y tiene
asignado una IP pblica la cual servir para enlazar la aplicacin a travs de
un puerto virtual.
Los comandos utilizados durante esta actividad son los siguientes:
a) sudo: permite ejecutar programas con los privilegios de seguridad.
b) apt-get: con la opcin install sirve para instalar paquetes
c) ln: Con la opcin -s crea un acceso directo en lugar de una copia.
d) nano: es un potente editor de texto para lnea de comando.
e) cd: Cambiar de directorio (cd .. directorio anterior)
f) mkdir: Crear directorio
g) rmdir: Eliminar directorio
h) mv: mover o cambiar nombre a archivos y/o directorios
174
1.4.1.1. PRE-REQUISITOS PARA EL SERVIDOR WEB

A) Instalacin de Apache, PHP5 y mdulos necesarios:
sudo apt-get install apache2 php5 libapache2-mod-php5 php5-xsl
B) Desactivar la visualizacin de parmetros de las direcciones

especificadas en los navegadores
sudo a2enmod rewrite
C) Especificar el nmero de conexiones simultneas al servidor:

sudo nano /etc/apache2/apache2.conf
MaxClients = 1024
D) Verificar el cdigo de juego de caracteres internacionales:

sudo nano /etc/apache/conf.d/charset
AddDefaultCharset UTF-8
E) Instalacin del servicio de cach para PHP (APC):

1. Instalar paquetes requeridos:
sudo apt-get install php-pear php5-dev apache2-threaded-dev re2c
2. Crear el enlace simblico para ejecutar apxs (apache extension tool):

sudo ln -s /usr/bin/apxs2 /usr/bin/apxs
3. Instalar APC (Alternative PHP Cache) es un acelerador para PHP, instalar

preferiblemente la versin beta:
sudo pecl install apc-beta
4. Agregar en /etc/php5/apache2/php.ini y en /etc/php5/cli/php.ini:

sudo nano /etc/php5/apache2/php.ini
extension="apc.so"
apc.enabled=1
sudo nano /etc/php5/cli/php.ini
extension="apc.so"
apc.enabled=1
5. Reiniciar Apache para aplicar los cambios
175
sudo /etc/init.d/apache2 restart
F) Instalar XSL (Extensible Stylesheet Language) necesario para que PHP

pueda interpretar los archivos css y xml:
sudo apt-get install php5-xsl
G) Instalacin de PostgreSQL
1. Instalar paquetes requeridos:
sudo apt-get install postgresql postgresql-contrib postgresqlclient libpq-dev
2. Crear la contrasea para el usuario "postgres" (UNIX)

sudo passwd postgres
Introduzca la nueva contrasea de UNIX:
Vuelva a escribir la nueva contrasea de UNIX:
3. Crear la contrasea para el usuario "postgres"

sudo -u postgres psql template1
template1=# ALTER USER postgres WITH PASSWORD 'contrasea';
ALTER ROLE
template1=# \q
4. Ajustar la configuracin en el archivo postgresql.conf para configurar la IP

del servidor y el nmero mximo de conexiones concurrentes:
sudo nano /etc/postgresql/8.4/main/postgresql.conf
listen_addresses = 'La IP estatica del servidor'
max_connections = 1024
shared_buffers = 1024
5. Agregar al final del archivo sysctl.conf para aceptar las conexiones

sudo nano /etc/sysctl.conf
kernel.shmall=65536
kernel.shmmax=268435456
6. Reiniciar para aplicar los cambios

reboot
7. Agregar al final del archivo pg_hba.conf para aceptar cualquier conexion:
176
sudo nano /etc/postgresql/8.3/main/pg_hba.conf

host
all
all
0.0.0.0 0.0.0.0
md5
8. Instalar el driver de postgresql necesario para symfony:

sudo apt-get install php5-pgsql
9. Instalar el lenguaje plgsql necesario para realizar las consultas en

PostgreSQL:
sudo -u postgres psql template1
template1=# CREATE LANGUAGE plpgsql;
CREATE LANGUAGE
template1=# \q
8. Reiniciar el servidor de postgres para aplicar la nueva configuracin:

sudo /etc/init.d/postgresql restart
1.4.1.2. INSTALACIN DE SYMFONY

1. Descargar el paquete de symfony desde www.symfony-project.org
2. Desempaquetar el paquete en /lib/symfony
cd /lib
sudo tar xvfz /home/usuario/descargas/symfony-1.4.8.tgz
sudo rm /lib/symfony-1.4.8 /lib/symfony
3. Verificar que todos

satisfactoriamente
los
requisitos
tcnicos
fueron
cumplidos
php /lib/vendor/symfony/data/bin/check_configuration.php
********************************
*
*
* symfony requirements check *
*
*
********************************
php.ini used by PHP: /etc/php5/cli/php.ini
**
*
*
*
*
WARNING **
The PHP CLI can use a different php.ini file
than the one used with your web server.
If this is the case, please launch this
utility from your web server.
177
** WARNING **
** Mandatory requirements **
OK
PHP version is at least 5.2.4 (5.3.3-1ubuntu9.5)
** Optional checks **
OK
OK
OK
OK
OK
OK
OK
OK
OK
OK
OK
OK
OK
OK
OK
PDO is installed
PDO has some drivers installed: pgsql
PHP-XML module is installed
XSL module is installed
The token_get_all() function is available
The mb_strlen() function is available
The iconv() function is available
The utf8_decode() is available
The posix_isatty() is available
A PHP accelerator is installed: FAILED
php.ini has short_open_tag set to off
php.ini has magic_quotes_gpc set to off
php.ini has register_globals set to off
php.ini has session.auto_start set to off
PHP version is not 5.2.9
4. Si hay avisos ([[WARNING]]) editar el archivo php.ini o verificar los pasos

previamente descritos.
5. Instalacin de los plugins necesarios: sfPostgresDoctrinePluginpara
trabajar en el modo de esquemas de Postgres, sfDoctrineGuardPlugin
para seguridad y autenticacin, sfDoctrineApplyPlugin enviar correos para
verificacin de cuenta y cambio de contrasea, sfDependentSelectPlugin
para los combos dependientes.
symfony
symfony
symfony
symfony
plugin:install sfPostgresDoctrinePlugin
plugin:install sfDoctrineGuardPlugin
plugin:installsfDoctrineApplyPlugin
plugin:install sfDependentSelectPlugin
6. Publicar los plugins en el directorio /web

symfony plugin:publish-assets
1.4.1.3. INSTALACIN DEL SITIO WEB

1. Crear el servidor virtual, esto permitir que solo se vea la carpeta web del
proyecto (sice-unermb) y la carpeta sf de symfony.
178
sudo nano /etc/apache2/sites-available/NombreDelProyecto

Listen LaIPEstatica:ElPuerto
<VirtualHost sice-unermb>
ServerName LaIPEstatica
ServerName sice-unermb
DocumentRoot "/home/sfprojects/NombreProyecto/web"
Alias /sf /lib/vendor/symfony/data/web/sf
<Directory "/home/sfprojects/NombreProyecto/web">
AllowOverride All
Allow from All
</Directory>
</VirtualHost>
2. Habilitar y chequear el sitio

sudo a2ensite sice-unermb
Site sice-unermb created
sudo apache2ctl -t
Sintax OK
3. Activar el sitio en el archivo hosts

sudo nano /etc/hosts
127.0.0.1
localhost sice-unermb
LaIPEstatica
sice-unermb
4. Cargar la nueva configuracion y reiniciar apache

sudo /etc/init.d/apache2 reload
* Reloading web server config apache2
sudo /etc/init.d/apache2 restart
* Restarting web server apache2
waiting
[ OK ]
[ OK ]
1.4.2. CREACIN DEL PROYECTO Y SUS COMPONENTES

A partir de este punto se detallarn las caractersticas de los mdulos
agregados al sistema acadmico de la UNERMB (sice-unermb), en funcin a
los objetivos del presente proyecto de investigacin, sin embargo se
especificar todo como si se tratara de un proyecto nuevo.
179
1.4.2.1. CREACIN DEL PROYECTO

1. Crear la carpeta del proyecto dentro de la carpeta /home y cambiar al
directorio creado para aplicar los comandos de symfony:
mkdir sfprojects/sice-unermb -p
cd sfprojects/sice-unermb
2. Crear el proyecto bajo la ORM Doctrine:

symfony generate:project sice-unermb --orm=Doctrine
1.4.2.2. CREACIN DE LAS APLICACIONES

1. Crear las aplicaciones frontend (mdulos para los usuarios) y backend
(mdulos para la administracin de datos)
symfony generate:app frontend --escaping-strategy=on --csrf secret=UniqueSecret
symfony generate:app backend --escaping-strategy=on --csrf secret=UniqueSecret
2. Activar el entorno de desarrollo para que la aplicacin pueda ser accesada

desde un equipo remoto a travs de una IP (IPRemota):
sudo nano web/frontend_dev.php
if (!in_array(@$_SERVER['REMOTE_ADDR'], array('IPRemota', '::1')))
sudo nano web/backend_dev.php
if (!in_array(@$_SERVER['REMOTE_ADDR'], array('IPRemota', '::1')))
1.4.3. CONSTRUCCIN DEL MODELO DE DATOS Y LOS MODULOS

1.4.3.1. CONFIGURACIN DE LA CONEXIN CON POSTGRESQL
Configurar el acceso a la base de datos
symfony configure:database "pgsql:host=LaIpEstatica;dbname=sice"
postgres LaClave
180
1.4.3.2. EL ESQUEMA DE DATOS

Configurar el esquema de la base de datos. Symfony tiene la facilidad de
crear el esquema de la bases de datos a partir de un archivo (schema.yml)
y posteriormente generar las tablas en la base de datos. En este caso se
aplica primero la siguiente estructura:
nano config/doctrine/schema.yml
tabla:
columns:
campo_id:
type: ElTipo
primary: true
autoincrement: true
campoUnico:
type: tipo
unique: true
campoConValorInicial:
type: tipo
default: ElValor
campoSimple: tipo
tabla_relacionada:
columns:
campo_id_relacionada: typo
campo2: tipo
relations:
tabla:
local: campo_id_relacionada
foreign: campo_id
type: one | many
foreignType: one | many
3. Luego se procede a crear el modelo e insertar la estructura y datos en la

base de datos
symfony doctrine:build-model
symfony doctrine:build-sql
symfony doctrine:insert-sql
4. Por otro lado, si la base de datos ya existe se puede realizar el proceso

inverso, es decir, crear el modelo a partir de la base de datos
symfony doctrine:build-schema
5. Agregar usuario desde el terminal de comandos
181
symfony guard:create-user jpirela@unermb.edu.ve jpirela

LaContrasea Jorge Pirela
6. Promover el usuario a superadministrador

Symfony guard:promote jpirela
En el anexo 5 se presenta el esquema completo de la base de datos

1.4.3.3. CREACIN DE LOS MDULOS
1. Creacin de los mdulos vacos para los mens: el men al inicio de la
aplicacin (inicio):
symfonygenerate:module frontend inicio
2. Creacin de los mdulos del sistema: el modulo para la presentacin de

mensajes para los tesistas y el botn de registro de proyecto
(post_registro), el mdulo de mantenimiento de tutores externos (tut_ext),
el mdulo de administracin de proyectos de investigacin registrados
(admin_proyectoregistrado) y el modulo de validacin de proyectos de
investigacin (proy_obj)
symfony doctrine:generate-module --with-show --non-verbosetemplates frontend principal_proyectos_registro post_registro
symfony doctrine:generate-module --with-show --non-verbosetemplates frontend principal_mae_tutoresexternos tut_ext
symfony doctrine:generate-module --with-show --non-verbosetemplates frontend principal_proyectos_registro
admin_proyectoregistrado
symfony doctrine:generate-module --with-show --non-verbosetemplates frontend 'principal_proyectos_objetivos proy_obj
Los mdulos creados fueron ajustados suprimiendo las plantillas

(templates) que no se iban a usar dependiendo de cada caso:
tree apps/frontend/modules
.
admin_proyectoregistrado
actions
actions.class.php
config
security.yml
182
templates
editSuccess.php
_form.php
indexSuccess.php
listaobjSuccess.php
newSuccess.php
inicio
actions
actions.class.php
templates
indexSuccess.php
post_registro
actions
actions.class.php
config
security.yml
templates
editSuccess.php
_form.php
formRegistroSuccess.php
indexSuccess.php
newSuccess.php
proy_obj
actions
actions.class.php
templates
editSuccess.php
_form.php
indexSuccess.php
newSuccess.php
tut_ext
actions
actions.class.php
templates
editSuccess.php
_form.php
indexSuccess.php
newSuccess.php
1.4.3.4. CONFIGURACIN DE LOS MDULOS

En
la
carpeta
/home/sfprojects/sice-unermb/apps/frontend/config
fueron ajustados todo los parmetros necesarios para configurar la

aplicacin.
183
A) CONFIGURACION DE LA APLICACION
#/home/sfprojects/sice-unermb/apps/frontend/config/apps.yml
# default values
all:
max_per:
1000
sfApplyPlugin:
after: @homepage
afterLogin: @homepage
from:
email: "portalunermb@gmail.com"
fullname: "Portal Academico UNERMB"
sf_guard_plugin:
success_signin_url:
@homepage
# the plugin use the referer as default
success_signout_url:
@homepage
# the plugin use the referer as default
#/home/sfprojects/sice-unermb/apps/frontend/config/cache.yml
default:
enabled:
false
with_layout: false
lifetime:
86400
#/home/sfprojects/sice-unermb/apps/frontend/config/factories.yml
prod:
logger:
class:
sfNoLogger
param:
level:
err
loggers: ~
mailer:
param:
delivery_strategy: realtime
test:
storage:
class: sfSessionTestStorage
param:
session_path: %SF_TEST_CACHE_DIR%/sessions
184
response:
class: sfWebResponse
param:
send_http_headers: false
mailer:
param:
delivery_strategy: none
dev:
mailer:
param:
all:
user:
param:
culture: es
mailer:
class: sfMailer
param:
logging:
%SF_LOGGING_ENABLED%
charset:
%SF_CHARSET%
transport:
class: Swift_SmtpTransport
param:
host:
smtp.gmail.com
port:
465
encryption: ssl
username:
portalunermb@gmail.com
password:
p0rta1un3rm8
routing:
class: sfPatternRouting
param:
generate_shortest_url:
true
extra_parameters_as_query_string: true
view_cache_manager:
class: sfViewCacheManager
param:
cache_key_use_vary_headers: true
cache_key_use_host_name:
true
#/home/sfprojects/sice-unermb/apps/frontend/config/filters.yml
rendering: ~
security: ~
185
# insert your own filters here

cache:
~
execution: ~
#/home/sfprojects/siceunermb/apps/frontend/config/frontendConfiguration.class.php
<?php
class frontendConfiguration extends sfApplicationConfiguration
{
public function configure()
{
}
}
#/home/sfprojects/sice-unermb/apps/frontend/config/routing.yml
sf_guard_signin:
url:
/login
param: { module: sfGuardAuth, action: signin }
sf_guard_signout:
url:
/logout
param: { module: sfGuardAuth, action: signout }
sf_guard_password:
url:
/request_password
param: { module: sfGuardAuth, action: password }
##############################Lo que se cambia es en URL!!!
crearCuenta:
url: /crearCuenta
param: { module: sfApply, action: apply }
reset:
url: /camb10Cl4v3_unermbAdmin
param: { module: sfApply, action: reset }
resetRequest:
url: /reset-request
param: { module: sfApply, action: resetRequest }
186
validate:
url: /confirm/:validate
param: { module: sfApply, action: confirm }
settings:
url: /settings
param: { module: sfApply, action: settings }
# We implement the missing sf_guard_password feature from
sfGuardPlugin
sf_guard_password:
url: /reset-request
param: { module: sfApply, action: resetRequest }
##############################
# default rules
homepage:
url:
/
param: { module: inicio, action: index }
##############################
regacad:
url:
/regacad
param: { module: inicio_regacad, action: index }
inicregacad:
url:
/registro_acad
param: { module: inic_regacad, action: index }
inicregacadnew:
url:
/registro_acadnew
param: { module: inic_regacad, action: new }
inicregacaded:
url:
/registro_acaded
param: { module: inic_regacad, action: edit }
inicregacadcre:
url:
/registro_acadcre
param: { module: inic_regacad, action: create }
inicregacadup:
url:
/registro_acadup
param: { module: inic_regacad, action: update }
187
postregproy:
url:
/registro_proyecto
param: { module: post_registro, action: index }
postregproynew:
url:
/registro_proyectonew
param: { module: post_registro, action: new }
postregproyed:
url:
/registro_proyectoed
param: { module: post_registro, action: edit }
postregproycre:
url:
/registro_proyectocre
param: { module: post_registro, action: create }
postregproyup:
url:
/registro_proyectoup
param: { module: post_registro, action: update }
postregproyfr:
url:
/registro_proyectofr
param: { module: post_registro, action: formRegistro }
adminpostregproy:
url:
/admin_proyreg
param: { module: admin_proyectoregistrado, action: index }
adminpostregproydel:
url:
/admin_proyregdel
param: { module: admin_proyectoregistrado, action: delete }
adminpostregproynew:
url:
/admin_proyregnew
param: { module: admin_proyectoregistrado, action: new }
adminpostregproyed:
url:
/admin_proyreged
param: { module: admin_proyectoregistrado, action: edit }
adminpostregproycre:
url:
/admin_proyregcre
param: { module: admin_proyectoregistrado, action: create }
adminpostregproyup:
url:
/admin_proyregup
188
param: { module: admin_proyectoregistrado, action: update }

adminpostregproyfr:
url:
/admin_proyregfr
param: { module: admin_proyectoregistrado, action:
formRegistro }
adminpostregproylo:
url:
/admin_proyreglo
param: { module: admin_proyectoregistrado, action: listaobj
#/home/sfprojects/sice-unermb/apps/frontend/config/security.yml
default:
is_secure: false
#/home/sfprojects/sice-unermb/apps/frontend/config/settings.yml
# You can find more information about this file on the symfony
website:
# http://www.symfony-project.org/reference/1_4/en/04-Settings
prod:
.settings:
no_script_name:
logging_enabled:
dev:
.settings:
error_reporting:
?>
web_debug:
cache:
no_script_name:
etag:
test:
.settings:
error_reporting:
E_NOTICE)."\n" ?>
cache:
web_debug:
no_script_name:
etag:
all:
.settings:
true
false
<?php echo (E_ALL | E_STRICT)."\n"

true
false
false
false
<?php echo ((E_ALL | E_STRICT) ^

false
false
false
false
189
enabled_modules:
sfDependentSelectAuto]
[default, sfGuardAuth, sfApply,
login_module:
login_action:
sfGuardAuth
signin
secure_module:
secure_action:
sfGuardAuth
secure
i18n: on
default_culture:
es
# Form security secret (CSRF protection)

csrf_secret:
XXXXXXXXXXXXXX
# Output escaping settings
escaping_strategy:
true
escaping_method:
ESC_SPECIALCHARS
# Enable the database manager
use_database:
true
#/home/sfprojects/sice-unermb/apps/frontend/config/security.yml
default:
http_metas:
content-type: text/html
metas:
#title:
#description:
#keywords:
#language:
#robots:
symfony project
symfony project
symfony, project
es
index, follow
stylesheets:
[main.css, /sfDoctrineApplyPlugin/css/loginapply, style.css]
javascripts:
[]
has_layout:
layout:
true
layout
#/home/sfprojects/sice-unermb/apps/frontend/config/view.yml
190
default:
http_metas:
content-type: text/html
metas:
#title:
#description:
#keywords:
#language:
#robots:
symfony project
symfony project
symfony, project
es
index, follow
stylesheets:
[main.css, /sfDoctrineApplyPlugin/css/loginapply, style.css]
javascripts:
[]
has_layout:
layout:
true
layout
B) CONFIGURACION DE LOS MODULOS

En cuanto a seguridad a continuacin se especifica los parmetros
ajustados para cada mdulo (security.yml)
#/home/sfprojects/sice-unermb/apps/frontend/modules/
admin_proyectoregistrado/config/security.yml
default:
is_secure: true
credentials: [[ctrl, doc]]
#/home/sfprojects/sice-unermb/apps/frontend/modules/
post_registro/config/security.yml
default:
is_secure: true
1.4.4. ESTABLECIMIENTO LAS VISTAS

A continuacin se presentan las plantillas usadas para la construccin
del sistema.
191
A) PLANTILLA PARA EL ACCESO Y SELECCIN DE OPCIONES DE LOS

MENS
Esta plantilla fue resumida para mayor compresin la misma est

ubicada en /home/sfprojects/sice-unermb/templates/layout.php
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
# Titulo de la pagina y enlaces a las libreras y hojas de estilo
</head>
<body>
<?php if (!$sf_user->isAuthenticated()): ?>
# Iniciar valores para el usuario y la contrasea
<?php endif ?>
<?php if ($sf_user->isAuthenticated()): ?>
<?php if ($sf_user->hasCredential('est')):?>
<?php endif ?>
<?php if ($sf_user->hasCredential('doc')):?>
<?php endif ?>
<?php endif ?>
</body>
</html>
B) PLANTILLA PARA EL REGISTRO DE PROYECTOS DE INVESTIGACIN

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
<form method="post" action="" onsubmit="return:false" class="iform">

<div id="imessageOK">Proyecto recibido</div>
<div id="imessageERROR">ERROR: El proyecto no pudo ser enviado</div>
<legend>Info</legend>
<ul style="width:542px;">
<li class="iheader">Datos del Proyecto</li>
<li>
<label for="TtulodelProyecto">Ttulo del Proyecto:</label>
<textarea class="itextarea" name="TtulodelProyecto"
id="TtulodelProyecto"></textarea>
</li>
<li>
<label for="ObjetivoGeneral">Objetivo General:</label>
<textarea class="itextarea" name="ObjetivoGeneral"
id="ObjetivoGeneral"></textarea>
</li>
<li>
<label for="ObjetivoEspecfico">Objetivo Especfico:</label>
<textarea class="itextarea" name="ObjetivoEspecifico[]"
id="ObjetivoEspecifico"></textarea>
192
18.
19.
20.
21.
22.
</li>
<li class="iheader">Archivo del Proyecto</li>
<li>
<label for="Archivo">Subir Archivo: </label>
<input id="NombreArchivo" name="NombreArchivo" class="element
file" type="file"/>
23.
</li>
24.
25.
<li class="iheader">Tutor UNERMB</li>
26.
<li>
27.
<label for="EsprofesordelaUNERMB">Profesor de la
UNERMB?</label>
28.
<ul>
29.
<li>
30.
<input class="iradio" type="radio" checked="checked"
name="EsprofesordelaUNERMB" id="EsprofesordelaUNERMB2" value="Si">
31.
<label for="EsprofesordelaUNERMB2"
class="ilabel">Si</label>
32.
<input class="iradio" type="radio"
name="EsprofesordelaUNERMB" id="EsprofesordelaUNERMB3" value="No">
33.
<label for="EsprofesordelaUNERMB3"
class="ilabel">No</label>
34.
</li>
35.
</ul>
36.
</li>
37.
<li>
38.
<label for="Profesor">Profesor:</label>
39.
<select class="iselect" name="Profesor" id="Profesor">
40.
<option value="Fulanito">Fulanito</option>
41.
<option value="Zutanito">Zutanito</option>
42.
<option value="Menganito">Menganito</option>
43.
</select>
44.
</li>
45.
<li class="iheader">Tutor externo</li>
46.
<li>
47.
<label for="Cdula">Cdula</label>
48.
<ul>
49.
<li>
50.
<input class="iradio" type="radio" checked="checked"
name="Cdula" id="Cdula2" value="V">
51.
<label for="Cdula2" class="ilabel">V</label>
52.
<input class="iradio" type="radio" name="Cdula"
id="Cdula3" value="E">
53.
<label for="Cdula3" class="ilabel">E</label>
54.
<input class="icheckbox" type="checkbox" name="" id="2"
value="">
55.
<label for="2" class="ilabel">Pasaporte</label>
56.
</li>
57.
</ul>
58.
</li>
59.
<li>
60.
<label for="Nro">Nro.:</label><input class="itext" type="text"
name="Nro" id="Nro" />
193
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
</li>
<li>
<label for="Tratamiento">Tratamiento:</label>
<select class="iselect" name="Tratamiento" id="Tratamiento">
<option value="Sr">Sr</option>
<option value="Sra.">Sra.</option>
<option value="Srta.">Srta.</option>
</select>
</li>
<li>
<label for="GradoAcadmico">Grado Acadmico:</label>
<select class="iselect" name="GradoAcadmico"
id="GradoAcadmico">
73.
<option value="Licenciatura">Licenciatura</option>
74.
<option value="Ingenieria">Ingenieria</option>
75.
<option value="Medico">Medico</option>
76.
</select>
77.
</li>
78.
<li>
79.
<label for="Tratamiento">Tratamiento:</label>
80.
<select class="iselect" name="Tratamiento" id="Tratamiento">
81.
<option value="Sr">Sr</option>
82.
<option value="Sra.">Sra.</option>
83.
<option value="Srta.">Srta.</option>
84.
</select>
85.
</li>
86.
<li>
87.
<label for="OtroMSc">Otro:M.Sc.</label>
88.
<select class="iselect" name="OtroMSc" id="OtroMSc">
89.
<option value="Mgr">Mgr</option>
90.
<option value="Ph.D.">Ph.D.</option>
91.
<option value="Doctor(a)">Doctor(a)</option>
92.
</select>
93.
</li>
94.
<li>
95.
<label for="Apellidos">Apellidos:</label>
96.
<input class="itext" type="text" name="Apellidos"
id="Apellidos" />
97.
</li>
98.
<li>
99.
<label for="Nombres">Nombres:</label>
100.
<input class="itext" type="text" name="Nombres" id="Nombres"
/>
101.
</li>
102.
<li class="iseparator"> </li>
103.
<li>
104.
<label> </label>
105.
<input type="button" class="ibutton" onclick="sendForm()"
name="RegistrarProyecto" id="RegistrarProyecto" value="Inscribir
Proyecto de Investigacin" />
106.
</li>
107.
</ul>
108. </form>
194
1.5. ESTABLECIMIENTO DE LOS CONTROLADORES

A) Mdulo de Inicio
<?php
/**
* inicio actions.
*
* @package
portalacad
* @subpackage inicio
* @author
Your name here
* @version
SVN: $Id: actions.class.php 23810 2009-11-12
11:07:44Z Kris.Wallsmith $
*/
class inicioActions extends sfActions
{
/**
* Executes index action
*
* @param sfRequest $request A request object
*/
public function executeIndex(sfWebRequest $request)
{
//$this->forward('default', 'module');
}
}
B) Mdulo de Registro de Proyecto
<?php
/**
* post_registro actions.
*
* @package
sice
* @subpackage post_registro
* @author
Your name here
* @version
*/
class post_registroActions extends sfActions
{
{
195
$this->principal_proyectos_registro_items =
Doctrine_Core::getTable('Principal_ProyectosRegistro_Item')
->createQuery('a')
->execute();
//$this->cedula = $this->getUser()->getUsername();
$this->cedula = '10038242';
$this->getidest =
Doctrine_Core::getTable('Principal_MaeEstudiantes_Item')>getEstudiante($this->cedula);
foreach($this->getidest as $getid_est):
$this->id_est = $getid_est['id'];
$this->est_pensum = $getid_est['pensum'];
$this->est_proy = $getid_est['abrev_proy'];
endforeach;
//VARIABLES DE VERIFICACION
$this->est_existe = false; //Existe registro estudiante?
$this->mat_aprobadas = false; //Materias necesarias
aprobadas?
$this->val_existe = false; //Existe validacion?
$this->eval_existe = false; //Existe evaluacion?
$this->proy_aprobado = false; //Es aprobado?
//contar si existe registro del estudiante en la tabla
proyecto registro
$this->counter =
Doctrine_Core::getTable('Principal_ProyectosRegistro_Item')>countestreg($this->id_est);
foreach($this->counter as $idsc): $ids_count =
$idsc['a_contador']; endforeach;
if(intval($ids_count)>1){
$this->est_existe=true;
//Revisar si hay validacion y evaluacion en la tabla
proyecto registro
$this->countereval =
Doctrine_Core::getTable('Principal_ProyectosRegistro_Item')>counteval($this->id_est);
print_r($this->countereval);
foreach($this->countereval as $vals):
$valnum = $vals['a_id_validacion'];
$evalnum = $vals['a_id_evaluacion'];
$proyapr = $vals['a_proyecto_aprobado'];
endforeach;
if($valnum!=""){
$this->val_existe = true; //debe revisar si hay eval
if($evalnum!=""){
196
$this->eval_existe = true; //si hay evaluacion, debe

revisar si esta aprobado
if($proyapr==true){
$this->proy_aprobado = true; //el proyecto fue
aprobado
}
}
}//fin if val num
}
else{ //si el estudiante no existe verificar si aprobo las
materias necesarias para registrar el proyecto
$this->mat_aprob =
Doctrine_Core::getTable('Principal_AcademicoMaterias_Item')>mat_aprob($this->id_est, $this->est_pensum, $this->est_proy);
foreach($this->mat_aprob as $maprob): $cont_maprob =
$maprob['contador']; echo "<br/>...$cont_maprob"; endforeach;
if(intval($cont_maprob)>=3){ $this->mat_aprobadas=true; }
}
}
public function executeFormRegistro(sfWebRequest $request)
//Funcion que registra nuevos proyectos...
{
$this->esRegistrado=false;
$this->form2 = new Principal_ProyectosRegistro_ItemForm();
if(isset($_POST['TutorINTERNO'])&&$request>getPostParameter('TituloProyecto', "")!=""&&$request>getPostParameter('ObjetivoGeneral')!=""){
//echos de prueba
echo "hay tutor interno";
echo "<br/>titulo:
".$request>getPostParameter('TituloProyecto');
echo "<br/>ObjetivoGeneral: ".$request>getPostParameter('ObjetivoGeneral');
$i=1;
print_r($request->getPostParameter('Objetivo'));
echo "<br/>...<br/>";
foreach($request->getPostParameter('Objetivo') as $objs):
echo "<br/>Objetivo_$i: ".$objs;
$i++;
endforeach;
//FIN de echos de prueba
$this->cedula = '7961662';
197
$this->tituloproy = $request>getPostParameter('TituloProyecto');
$this->objgen = $request>getPostParameter('ObjetivoGeneral');
$this->objesp = $request->getPostParameter('Objetivo');
$this->archivo_p = $request>getPostParameter("principal_proyectos_registro_item");
$this->id_tutint = $request->getPostParameter('Profesor');
$this->id_tutint2 = '1';
$this->my_t=getdate();
$this->feccre = $this->my_t['year']."-".$this>my_t['mon']."-".$this->my_t['mday'];
foreach($this->archivo_p as $nomarc):
$this->archivo_proy = $nomarc;
endforeach;
//1. OBTENER ID_ESTUDIANTE
$this->getidest =
$this->est_sede = $getid_est['sede'];
endforeach;
echo "idest : $this->id_est<br/>archivo: $this>archivo_proy";
//get sede_unidad_atencion idestudiante+mae_estud
//unir sede unidad
//2. GUARDAR EXPEDIENTE
$this->guardaregnew =
Doctrine_Core::getTable('Principal_ProyectosRegistro_Item')>guardarRegistro($this->id_est, $this->tituloproy, $this>archivo_proy, $this->id_tutint2, '0', $this->feccre, $this>est_sede);
//3. OBTENER ID_EXPEDIENTE PARA GUARDAR LOS OBJETIVOS
CORRESPONDIENTES
foreach($this->guardaregnew as $id_exp):
$idexp = $id_exp['currval'];
//3.1. GUARDAR OBJ GENERAL CON ID 0
$this->guardaobjg =
Doctrine_Core::getTable('Principal_ProyectosObjetivos_Item')>guardarObjetivo($idexp, '0', $this->objgen);
//3.2. GUARDAR OBJS ESPECIFICOS CON IDS DEL 1 al N
$i=1;
foreach($this->objesp as $objs):
198
$this->guardaobje =
Doctrine_Core::getTable('Principal_ProyectosObjetivos_Item')>guardarObjetivo($idexp, $i, $objs);
$i++;
endforeach;
endforeach;
$this->esRegistrado=true;
}
else if(isset($_POST['TutorEXTERNO'])&&$request>getPostParameter('Nro', "")!=""&&$request>getPostParameter('Nombres', "")!=""){
$this->cedula = '7961662';
$this->tituloproy = $request>getPostParameter('TituloProyecto');
$this->objgen = $request>getPostParameter('ObjetivoGeneral');
$this->objesp = $request->getPostParameter('Objetivo');
$this->archivo_p = $request>getPostParameter("principal_proyectos_registro_item");
$this->nombres_te = $request->getPostParameter('Nombres');
$this->apellidos_te = $request>getPostParameter('Apellidos');
$this->nac_te = $request>getPostParameter('Identificacion');
$this->ident_te = $request->getPostParameter('Nro');
$this->sexo = '0';
$this->curriculo_te = $request>getPostParameter('Curriculo');
$espasap = false;
$this->my_t=getdate();
$this->feccre = $this->my_t['year']."-".$this>my_t['mon']."-".$this->my_t['mday'];
foreach($this->archivo_p as $nomarc):
$this->archivo_proy = $nomarc;
endforeach;
//1. OBTENER ID_ESTUDIANTE
$this->getidest =
endforeach;
199

//2. GUARDAR TUTOR EXTERNO
$this->guardartutext =
Doctrine_Core::getTable('Principal_MaeTutoresexternos_Item')>guardarTutext($this->ident_te, $this->apellidos_te, $this>nombres_te, $this->nac_te, $this->curriculo_te, $espasap);
//3. OBTENER ID TUTOR EXTERNO PARA GUARDARLO EN EL
EXPEDIENTE
foreach($this->guardartutext as $idtutext):
$this->id_tutext = $idtutext['currval'];
endforeach;
//4. GUARDAR EXPEDIENTE
$this->guardaregnew =
Doctrine_Core::getTable('Principal_ProyectosRegistro_Item')>guardarRegistro($this->id_est, $this->tituloproy, $this>archivo_proy, '1', $this->id_tutext, $this->feccre);
//5. OBTENER ID_EXPEDIENTE PARA GUARDAR LOS OBJETIVOS
CORRESPONDIENTES
foreach($this->guardaregnew as $id_exp):
$idexp = $id_exp['currval'];
//5.1. GUARDAR OBJ GENERAL CON ID 0
$this->guardaog =
Doctrine_Core::getTable('Principal_ProyectosObjetivos_Item')>guardarObjetivo($idexp, '0', $this->objgen);
//5.2. GUARDAR OBJS ESPECIFICOS CON IDS DEL 1 al N
$i=1;
foreach($this->objesp as $objs):
$this->guardaoe =
Doctrine_Core::getTable('Principal_ProyectosObjetivos_Item')>guardarObjetivo($idexp, $i, $objs);
$i++;
endforeach;
endforeach;
$this->esRegistrado=true;
//estudiantes:
//
//$this->guardartutext =
Doctrine_Core::getTable('Principal_MaeTutoresexternos_Item')>guardarTutext($identificacion, $apellidos, $nombres,
$nacionalidad, $sexo, $archcur, $espasap);
//guardar registros, con id tutor externo
//$this->guardareg =
Doctrine_Core::getTable('Principal_MaeTutoresexternos_Item')-
200
>guardarTutext($identificacion, $apellidos, $nombres,

$nacionalidad, $sexo, $archcurr, $espasap);
//guardar objetivos, con id registro
//$this->guardareg =
Doctrine_Core::getTable('Principal_ProyectosObjetivos_Item')>guardarObjetivo($id_exp['currval'], $id_obj, $objetivo);
}
}
public function executeNew(sfWebRequest $request)
{
$this->form = new Principal_ProyectosRegistro_ItemForm();
}
public function executeCreate(sfWebRequest $request)
{
$this->forward404Unless($request>isMethod(sfRequest::POST));
$this->processForm($request, $this->form);
$this->setTemplate('new');
}
public function executeEdit(sfWebRequest $request)
{
$this->forward404Unless($principal_proyectos_registro_item =
Doctrine_Core::getTable('Principal_ProyectosRegistro_Item')>find(array($request->getParameter('id_expediente'))),
sprintf('Object principal_proyectos_registro_item does not exist
(%s).', $request->getParameter('id_expediente')));
$this->form = new
Principal_ProyectosRegistro_ItemForm($principal_proyectos_regist
ro_item);
}
public function executeUpdate(sfWebRequest $request)
{
$this->forward404Unless($request->isMethod(sfRequest::POST)
|| $request->isMethod(sfRequest::PUT));
201

$this->form = new
ro_item);
$this->setTemplate('edit');
}
public function executeDelete(sfWebRequest $request)
{
$request->checkCSRFProtection();
$principal_proyectos_registro_item->delete();
$this->redirect('post_registro/index');
}
protected function processForm(sfWebRequest $request, sfForm
$form)
{
$form->bind($request->getParameter($form->getName()),
$request->getFiles($form->getName()));
if ($form->isValid())
{
$principal_proyectos_registro_item = $form->save();
$this>redirect('post_registro/edit?id_expediente='.$principal_proyect
os_registro_item->getIdExpediente());
}
}
}
C) Mdulo Validacin de Proyectos (listado de proyectos registrados)

<?php
/**
202
* admin_proyectoregistrado actions.
*
* @package
sice
* @subpackage admin_proyectoregistrado
* @author
Your name here
* @version
*/
class admin_proyectoregistradoActions extends sfActions
{
{
$this->principal_proyectos_registro_items =
Doctrine_Core::getTable('Principal_ProyectosRegistro_Item')
->createQuery('a')
->execute();
}
{
}
{
}
{
$this->form = new
ro_item);
}
public function executeListaobj(sfWebRequest $request)
203
{
$idexpediente = $request->getParameter('id_expediente');
$this->objGEN =
Doctrine_Core::getTable('Principal_ProyectosObjetivos_Item')>getObsgen($idexpediente);
$this->objESP =
Doctrine_Core::getTable('Principal_ProyectosObjetivos_Item')>getObsesp($idexpediente);
$this->getidestexp =
Doctrine_Core::getTable('Principal_MaeEstudiantes_Item')>getEstudianteexp($idexpediente);
//Informacion para llenar combos de observaciones, por
TItulo, ObjetivoGeneral y ObjetivoEspecifico
$this->obsTI =
Doctrine_Core::getTable('Principal_ValoresObservaciones_Item')>getObservaciones("TI");
$this->obsOG =
Doctrine_Core::getTable('Principal_ValoresObservaciones_Item')>getObservaciones("OG");
$this->obsOE =
Doctrine_Core::getTable('Principal_ValoresObservaciones_Item')>getObservaciones("OE");
print_r($request->getPostParameter('obj'));
//Array ( [0] => 4 [1] => 6 [2] => 7 [3] => 6 [4] => 7 )
/*
$this->est_pensum = $getid_est['pensum'];
$this->est_proy = $getid_est['abrev_proy'];
endforeach;
*/
}
{
204
$this->form = new
ro_item);
}
{
$principal_proyectos_registro_item->delete();
$this->redirect('admin_proyectoregistrado/index');
}
$form)
{
{
$principal_proyectos_registro_item = $form->save();
$this>redirect('admin_proyectoregistrado/edit?id_expediente='.$princi
pal_proyectos_registro_item->getIdExpediente());
}
}
}
D) Mdulo de Validacin de Proyectos (registro de observaciones)
<?php
/**
* proy_obj actions.
*
205
* @package
sice
* @subpackage proy_obj
* @author
Your name here
* @version
*/
class proy_objActions extends sfActions
{
{
$this->principal_proyectos_objetivos_items =
Doctrine_Core::getTable('Principal_ProyectosObjetivos_Item')
->createQuery('a')
->execute();
}
{
$this->form = new Principal_ProyectosObjetivos_ItemForm();
}
{
$this->form = new Principal_ProyectosObjetivos_ItemForm();
}
{
$this->forward404Unless($principal_proyectos_objetivos_item
= Doctrine_Core::getTable('Principal_ProyectosObjetivos_Item')>find(array($request->getParameter('id_expediente'),
$request->getParameter('id_objetivo'))), sprintf('Object
principal_proyectos_objetivos_item does not exist (%s).',
206
$request->getParameter('id_expediente'),
$request->getParameter('id_objetivo')));
$this->form = new
Principal_ProyectosObjetivos_ItemForm($principal_proyectos_objet
ivos_item);
}
{
$this->form = new
Principal_ProyectosObjetivos_ItemForm($principal_proyectos_objet
ivos_item);
}
{
207
$principal_proyectos_objetivos_item->delete();
$this->redirect('proy_obj/index');
}
$form)
{
{
$principal_proyectos_objetivos_item = $form->save();
$this>redirect('proy_obj/edit?id_expediente='.$principal_proyectos_ob
jetivos_item>getIdExpediente().'&id_objetivo='.$principal_proyectos_objetivo
s_item->getIdObjetivo());
}
}
}
E) Mdulo de Tutores externos
<?php
/**
* tut_ext actions.
*
* @package
sice
* @subpackage tut_ext
* @author
Your name here
* @version
*/
class tut_extActions extends sfActions
208
{
{
$this->principal_mae_tutoresexternos_items =
Doctrine_Core::getTable('Principal_MaeTutoresexternos_Item')
->createQuery('a')
->execute();
}
{
$this->form = new Principal_MaeTutoresexternos_ItemForm();
}
{
$this->form = new Principal_MaeTutoresexternos_ItemForm();
}
{
$this->forward404Unless($principal_mae_tutoresexternos_item
= Doctrine_Core::getTable('Principal_MaeTutoresexternos_Item')>find(array($request->getParameter('id'))), sprintf('Object
principal_mae_tutoresexternos_item does not exist (%s).',
$request->getParameter('id')));
$this->form = new
Principal_MaeTutoresexternos_ItemForm($principal_mae_tutoresexte
rnos_item);
}
{
209
$this->form = new
Principal_MaeTutoresexternos_ItemForm($principal_mae_tutoresexte
rnos_item);
}
{
$principal_mae_tutoresexternos_item->delete();
$this->redirect('tut_ext/index');
}
$form)
{
{
$principal_mae_tutoresexternos_item = $form->save();
$this>redirect('tut_ext/edit?id='.$principal_mae_tutoresexternos_item
->getId());
}
}
}
210
1.6. Cierre de la Aplicacin
Finalizando el proyecto con el cuarto objetivo, evaluar la operatividad

del sistema de informacin mediante pruebas pertinentes, en esta fase se
detallan las distintas pruebas realizadas sobre el sistema y su respectiva
entrega a los usuarios finales.
1.6.1. PRUEBAS UNITARIAS
Todas las pruebas unitarias son guardadas en el directorio test/unit/.
Por convencin, las pruebas son nombradas con el nombre de la clase que
ellas prueban ms el sufijo Test. Se puede organizar los archivos en el
directorio test/unit/ de la forma deseada, se recomienda replicar la estructura
de directorios del directorio lib/.
Crear un archivo test/unit/TestUnitario.php y copia en l, el siguiente
cdigo:
// test/unit/TestUnitario.php
require_once dirname(__FILE__).'/../bootstrap/unit.php';
$t = new lime_test(1);
$t->pass('This test always passes.');
Para lanzar las pruebas, se ejecuta el archivo directamente:

$ php test/unit/TestUnit.php
O usar la tarea test:unit:

$ php symfony test:unit RegistroProyectos
1..1
Ok 1 This test always passes.
Looks like everything went fine
211
1.6.2. PRUEBAS FUNCIONALES

As como para las pruebas unitarias, ejecutar las pruebas funcionales
se puede hacer directamente desde un archivo de pruebas:
$ php test/functional/frontend/categoryActionsTest.php
O usando la tarea test:functional:

$ php symfony test:functional frontend categoryActions
212
2.
DISCUSIN DE LOS RESULTADOS

En atencin a lo referido por Escalona, Koch, Lowe y Eklund se pudo
corroborar que los resultados obtenidos en la presente investigacin

estuvieron acorde a las metodologas aplicadas, en virtud a que el diseo de
la aplicacin estuvo centrado en el usuario. Los investigadores consideraron
pertinente esta combinacin de metodologas debido a que se ajust
perfectamente al contexto de los usuarios, aplicando el Modelo de Dilogo
para la Educcin de Requisitos como tcnica principal para recolectar la
informacin necesaria.
Por otro lado, acorde a lo expuesto por Potencier y Zaninotto, se verific
que el diseo rpido de aplicaciones sobre un modelo de prototipado
evolutivo se ajust a las necesidades para el desarrollo del sistema, ya que la
participacin activa de los usuarios, quienes aportaron constantemente
observaciones a la aplicacin, fue lo que permiti su perfeccionamiento y
crecimiento durante el desarrollo de la misma.
3.
CONCLUSIONES
Sobre la base de todas las actividades realizadas y desarrolladas en el
transcurso del desarrollo de la presente investigacin se concluy lo

siguiente:
Con relacin al primer objetivo de la investigacin, analizar la situacin
actual de los procesos y procedimientos acadmicos de la Coordinacin de
213
Investigacin del Programa Posgrado de la Universidad Experimental Rafael
Mara Baralt, se evidenci que la institucin antes referida existe un contexto
de alta complejidad de interrelaciones entre los diferentes actores y no hay
un sistema idneo para apoyar los procesos de inscripcin de proyectos de
investigacin.
Con relacin al segundo objetivo de la investigacin, determinar los
requerimientos del Sistema de Informacin para su desarrollo en la
Coordinacin de Investigacin del Programa Posgrado de la Universidad
Experimental Rafael Mara Baralt, se determin que existe la necesidad de
crear un sistema que permitiera satisfacer todos los requisitos solicitados,
especialmente para resolver el problema de dispersin geogrfica, el papeleo
excesivo y la complejidad de los procesos.
Disear lgica y fsicamente un sistema de informacin bajo el ambiente
Web tomando en cuenta los requerimientos encontrados en la recopilacin
de datos, en este sentido, se aplic la ingeniera de requisitos como una
alternativa para que los usuarios no solamente participaran en la fase de
anlisis sino que tambin se tomaran en cuenta sus ideas para el diseo de
la aplicacin.
Con relacin al cuarto objetivo de la investigacin, evaluar la
operatividad del sistema de informacin mediante pruebas pertinentes, se
verific mediante pruebas unitarias y funcionales aplicadas sobre datos de
prueba que el sistema funciona de acuerdo al diseo realizado.
214
4.
RECOMENDACIONES
Sobre la base de todo lo referido en esta investigacin se recomienda lo
siguiente:
Continuar con el mantenimiento del sistema actual, procurando
centralizar aun ms los recursos en un centro de hospedaje de servidores ya
que a medida que pase el tiempo las demandas sobre los recursos
tecnolgicos se vern incrementadas.
Los investigadores recomiendan para las futuras investigaciones tomar
en cuenta el desarrollo de un sistema que automatice el proceso de
elicitacin de requisitos de tal manera de crear una herramienta colaborativa
que podra ser bajo ambiente web para facilitar la fase de diseo de sistemas
bajo los criterios de la ingeniera de requisitos.
Asimismo, se propone la creacin de un sistema basado en ambiente
web para automatizar el proceso de inscripcin de tesis de grado, el cual
sera la continuacin del sistema propuesto en el presente estudio.
REFERENCIAS BIBLIOGRAFICAS
PROYECTOS DE INVESTIGACIN
Albarracn, Sonia (2009): Diseo de un Sistema de Informacin basado en la
Web para apoyar la actividad de Investigacin en la Escuela de
Economa. Trabajo de Ascenso para Docente con escalafn de
Agregado. Valencia, Venezuela: Universidad de Carabobo. Facultad de
Ciencias Econmicas y Sociales.
Capa Len, Luis Javier (2008): Modelado de Negocio de la Ingeniera Web.
Tesis de Pregrado. Loja, Ecuador. La Universidad Catlica de Loja.
Escuela de Sistemas Informticos y Computacin.
Chaparro, Gilberto y Forero, Luis (2005): Sistema de Informacin para
Administracin de Proyectos de Grado. Tesis de Pregrado. Bogot,
Colombia: Universidad Pontificia Javeriana. Facultad de Ingeniera.
Durn Toro, Amador; Bernrdez Jimnez, Beatriz (2000): Metodologa para
la Elicitacin de Requisitos de Software. Informe Tcnico. Sevilla,
Espaa: Universidad de Sevilla.
Escalona, Mara Jos (2004): Modelos y tcnicas para la especificacin y el
anlisis de la Navegacin en Sistemas Software. Tesis de Doctorado.
Sevilla, Espaa: Universidad de Sevilla.
Koch, N. (2001). Software Engineering for Adaptative Hypermedia
Applications. Phylosofus Doctor Thesis. Munich, Germany: Munich
University
Quintero, Jimi (2008): Sistema de Informacin Web para el trmite, control de
solicitudes y reservacin de salones para la Oficina de Registros de la
Facultad de Ingeniera. Tesis de Pregrado. Mrida, Venezuela:
Universidad de Los Andes. Facultad de Ingeniera.
Reao, Jos (2005): Propuesta de Diseo de Sistema de Informacin sobre
plataforma Web basado en Tecnologa base de Informacin como parte
del Sistema de Informacin para la Gestin del Postgrado de Ciencias y
Tecnologa. Tesis de Especialista. Barquisimeto, Venezuela:
Universidad Centroccidental Lisandro Alvarado.
Rivera Lpez, Alejandro (2008): Sistema asistente para la generacin de
horarios de cursos. Tesis de Pregrado. Puebla, Mxico: Universidad de
las Amricas Puebla. Escuela de Ingeniera y Ciencias Departamento
de Computacin, Electrnica, Fsica e Innovacin.
LIBROS
Alonso, Fernando; Martnez, Loc y Segovia, Javier (2005): Introduccin a la
215
216
Ingeniera de Software. Modelos de Desarrollo de Programas. Madrid,

Espaa: Delta Publicaciones Universitarias.
Atelin, Philippe; Dordoigne Jose (2007): TCP/IP y Protocolos de Internet.
Barcelona, Espaa: Ediciones ENI
Booch, Grady; Jacobson, Ivar; Rumbaugh, James (2000): El Proceso
Unificado de Desarrollo de Software. Madrid, Espaa: Addison Wesley.
Bracco, Felix (2001): 4000 Elementos para crear un Sitio Web. Buenos Aires,
Argentina: MP Ediciones S.A.
Briz, Julian; Lazo, Isidro (2001): Internet y Comercio Electrnico. Madrid,
Espaa: Mundi-Prensa Libros. 2da. Edicin.
Castro, Luis (2011): Revisin de la Estructura Organizacional de la Unidad de
Atencin a la Investigacin. Cabimas, Venezuela: Universidad Rafael
Mara Baralt. Programa Posgrado.
Chiavenato, Idalberto (2007): Teora General de la Administracin. Mxico:
Mc.Graw Hill Interamericana. Sptima Edicin.
Escalona, Mara Jos y Koch, Nora (2002): Ingeniera de Requisitos en
Aplicaciones para la Web Un estudio comparativo. Sevilla, Espaa:
Departamento de Lenguajes y Sistemas Informticos. Escuela Tcnica
Superior de Ingeniera Informtica. Universidad de Sevilla.
Fallas Pastor, Carlos Luis (2008): Historia Contempornea de Costa Rica.
San Jos de Costa Rica: Editorial Universidad Estatal a Distancia.
Gmez de Silva Garza, Andrs y Ania Briseo, Ignacio de Jess (2008);
Introduccin a la Computacin. Mxico: Cengage Learning Editores.
Heredia, Jos Antonio (2001): Sistema de indicadores para la mejora y el
control integrado de la calidad de los procesos. Madrid, Espaa:
Athenea.
Kappel, Gerti; Prll, Birgit; Reich, Siegfried; Retschitzegger. Wernet (2003):
Web Engineering: TheDiscipline of Systematic Development of Web
Applications. Heidelberg, Germany: John Wiley and Sons
Kendall, Kenneth E. y Kendall, Julie E. (2005): Anlisis y Diseo de Sistemas.
Mxico: Pearson Educacin.
Laudon, Kenneth y Laudon, Jane (2004): Sistemas de Informacin Gerencial.
Mxico: Prentice - Hall. 8va Edicin.
Lujan Mora, Sergio (2002): Programacin de aplicaciones web: historia,
principios bsicos y clientes web. Alicante, Espaa: Editorial Club
Universitario
Marco Galindo, Maria Jess; Marco Sim, Josep Maria; Prieto Blzquez,
Josep; Segret Sala, Ramon (2010): Escaneando la Informtica.
217
Barcelona, Espaa: Editorial UOC.

Mc.
Leod, Raymond (2000): Componentes de un Sistema

InformacionGerencial. Mxico: Prentice Hall Hispanoamerica.
de
Orozco, Luis; Cardoso, Rodrigo (2004): La evaluacin como estrategia de

autorregulacin y cambio institucional. UNESCO / IESALC RAP.
Potencier, Fabien y Zaninotto, Franois (2008): Symfony, La gua definitiva.
http://www.synfony-project.org/documentation.
Prat, Marie (2007): Cree su primer sitio web con Dreamweaver. Barcelona,
Espaa: Ediciones ENI.
Quero Catalinas, Enrique; Garca Romn, Agustn; Pea Rodrguez, Javier
(2007): Mantenimiento de portales de la Informacin. Madrid, Espaa:
Paraninfo, S.A.
Ramrez, Ramn (2005): Gestin del Desarrollo de Sistemas
Telecomunicacin e Informticos. Madrid, Espaa: Paraninfo.
de
Ramos Monso, Martin (2004): Software libre para Sitios Web. Buenos Aires,
Argentina: MP Ediciones S.A.
Rebeil Corella, Mara Antonieta y RuzSandoval Resndiz, Celia (1998): El
poder de la comunicacin en las organizaciones. Mxico: Asociacin
Mexicana de Comunicadores Organizacionales.
Reyes Ponce, Agustn (2004): Administracin Moderna. Mxico: Limusa.
Robbins, Stephen P. y DeCenzo, David. A. (2002): Fundamentos de
Administracin. Mxico: Pearson Educacin. 3ra. Edicin.
Snchez Garreta, Jos Salvador; Chalmeta Rosale, Ricardo; Monfort
Manero, Pilar; Campos Sancho; Cristina (2003): Ingeniera de
Proyectos Informticos. Barcelona, Espaa: Universitas.
Senn, James A. (1992): Anlisis y Diseo de Sistemas de Informacin.
Mxico: Mc.Graw Hill. Segunda Edicin.
Sommerville Ian, (2005): Lenguaje Natural Definicion de Requisitos Ingenieria
del Software. Madrid, Espaa: Pearson Education S.A. Sptima Edicion.
Stoner, James A.; Freeman, Edward; Gilbert, Daniel (1996): Administracin.
Mxico: Prentice Hall Hispanoamericana, S.A.
Surhone, Lambert; Tennoe, Mariam; Henssonow, Susan (2010): Web
Information System. VDM Verlag Dr. Mueller AG & Co.
Taboada Gonzlez, Jos y Cotos Yez Jos Manuel (2005): Sistemas de
Informacin medioambiental. Madrid, Espaa: Netbiblo, S. L.
Yourdon, Edward (1993): Anlisis Estructurado Moderno. Mxico: Prentice
Hall Hispanoamericana.
218
Vidgen, Richard; Wood, Bob (2002): Developing Web information systems:

from strategy to implementation. England, London: Elsevier Inc.
REVISTAS
Arribas Urrutia, Amaia (2000): Centralizar o descentralizar los sistemas de
informacin en la empresa? Revista mbitos. N 3-4 31/07/2000.
Espaa: Universidad de Sevilla.
Bascn Pantoja, Ernesto (2004): El patrn de diseo Modelo-VistaControlador (MVC) y su implementacin en Java Swing. Madrid,
Espaa: Acta Nova; Vol. 2, N 4, diciembre 2004.
Mazaira, Zahily (2008): La Administracin de la Labor Acadmica como
Actividad de Negocios en un Departamento Docente de la Educacin
Superior. El Proceso Acadmico y su Administracin en la Educacin
Superior. Habana: Universidad de Cienfuegos Carlos Rafael Rodrguez
Rodrguez.
Ortz Sosa, Lourdes Maritza (2004): Modelo de Clasificacin y Evolucin de
Metodologa de Desarrollo de Sistemas de Informacin. Tekne Revista
de la Facultad de Ingeniera N 7. Caracas, Venezuela: Universidad
Catlica Andrs Bello.
Zapata, Carlos M.; Carmona, Nicols (2008); Un modelo de dilogo para la
educcin de requisitos de software. Revista Dyna Nro. 164. Medelln,
Colombia: Universidad Nacional de Colombia. Escuela de Sistemas.
Zapata (2010): Una propuesta de metaontologa para la educcin de
requisitos: Arica, Chile: Universidad de Tarapac. Ingeniare. Revista de
Ingeniera Chilena. Vol. 18. Nro. 1. Abril de 2010.
ARTICULOS ELECTRONICOS
Bergamn Gladys (2008): Los costos de la universidad aumentan al ritmo de
la inflacin. http://www.collegeboard.com/about/prensa/noticias-prensa
/noticia102908.html
Bustos Snchez, Alfonso; Miranda Daz, Germn Alejandro y Tirado Segura;
Felipe (2002): PAEA en Lnea. Una propuesta para implementar un
modelo de tutela entre alumnos. Mxico: Universidad de Mxico.
Secretara General Acadmica. Primer Foro de Experiencias PAEA.
http://www.iztacala.unam.mx/temas/foropaea/10TP08IIc.htm
Contreras Guerrero, Daisy y Galea Bracho, Alfonso (2011): Definiciones y
Componentes de un Sistema de Informacin. Mimeografiado.
Maracaibo: Instituto Universitario de Maracaibo. http://www.alfonsogalea
.com.ve
FernndezMedina Patn, Eduardo (2006): Ciclo de Vida del Software.
219
Espaa: Universidad de Castilla La Mancha. Departamento de
Tecnologas y Sistemas de Informacin. Escuela Superior de
Informtica de Ciudad Real. Grupo Alarcos. http://alarcos.inf-cr.uclm.
es/doc/ISOFTWAREI/Tema03.pdf
IEEE 1074-1995. Standard for Developing Software Life Cycle Processes.
http://standards.ieee.org/findstds/standard/1074-1995.html
IEEE 1471-2000. Recommended Practice for Architectural Description for
Software-Intensive Systems. http://standards.ieee.org/findstds/standard
/1471-2000.html
ISO/IEC 12207:2008. Systems and software engineering -- Software life cycle
processes. http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue
_detail.htm?csnumber=43447
Klas, Mary Ellen (2008): Universidades suben las matriculas hasta un 15
porciento. http://www.elnuevoherald.com/noticias/sur-de-la-florida
Riley, Sandra (2005): Costos de estudios aumentan lentamente en centros
universitarios pblicos. http://www.hispanicprwire.com/news.php?l=es
&id=5255
Reenskaug, Trygve (1978): http://heim.ifi.uio.no/~trygver/
Romano, A. (2007): Bitcora-e Revista Electrnica Latinoamericana de
Estudios Sociales, Histricos y Culturales de la Ciencia y la Tecnologa
http://www.saber.ula.ve/bitstream/123456789/26492/3/servicio_academ.
pdf
Villavicencio, Julio; Arroyo, Carlos; Cuba, Juana; Gutirrez Ilave, Margot y
Meneses Tutaya, Norma (2007): Gua 2007 Autoevaluacin y
Acreditacin Pregrado y Postgrado. Lima: Universidad Nacional Mayor
de San Marcos. Facultad de Ingeniera de Sistemas e Informtica.
http://www.unmsm.edu.pe/occaa/publicaciones/guia2007.pdf
Prez Valdez, Daman (2007): Los Frameworks de PHP agilizan tu trabajo.
http://www.maestrosdelweb.com/editorial/los-frameworks-de-phpagilizan-tu-trabajo/
Universidad Nacional Experimental Rafael Mara Baralt. Resea Histrica
http://200.11.182.194/index.php?option=com_content&view=article&id=
49&Itemid=57
Universidad
Rafael
Belloso
Chacn.
Vida
Universitaria.
http://www.urbe.edu/vidauniversitaria/servicios/servicios.html
Qu es Doctrine ORM? http://www.tecnoretales.com/programacion/que-esdoctrine-orm/
CONFERENCIAS
220
Escalona, Mara Jos; Mejas, Manuel; Gutirrez, Javier Jess; Torres, Jess
(2004) Mtodos de Testing sobre la Ingeniera de Requisitos Web de
NDT. Conferencia IADIS Iberoamericana WWW/Internet.
Lowe D., Eklund J. (2002). Client Needs and the Design Process in Web
Projects (2002). WWW2002 ConferenceWeb Engineering Track.
REFERENCIAS LEGALES
Normas para la elaboracin de Tesis de Grado. Maracaibo, Venezuela:
Universidad Rafael Belloso Chacn
Normas para la Inscripcin, Sustentacin y Evaluacin de los Proyectos y
Trabajos de Grado de Maestra (2008). Cabimas, Venezuela:
Universidad Nacional Experimental Rafael Mara Baralt Programa
Posgrado.
Reglamento de Evaluacin (1997). Cabimas, Venezuela: Universidad
Nacional Experimental Rafael Mara Baralt Secretara
ANEXOS
ANEXO 1
MANUAL DE IDENTIDAD VISUAL PARA LOS PORTALES WEBS DE LA
UNIVERSIDAD NACIONAL EXPERIMENTAL RAFAEL MARA BARALT
El Logo
El logo de la Universidad Nacional Experimental Rafael Mara Baralt
UNERMB se compone de dos partes fundamentales:
El escudo. Representado el Estado Zulia en forma geomtrica, en color
celeste el golfo de Venezuela y el Lago de Maracaibo, en color negro la
Costa Oriental del Lago y el Petrleo. En su inicio compuesto por una (V) que
al estar repetidas forman una (W) y estas a su vez forman los rectngulos y
al mismo tiempo en los ngulos medio, izquierdo y derecho los dos
rectngulos que representan el petrleo, a su vez se van formando la imagen
de libros superpuestos.
El logotipo. La representacin escrita del nombre tiene dos partes
diferenciadas a) Repblica Bolivariana de Venezuela b) Universidad Nacional
Experimental c) Rafael Mara Baralt, compuesta en tipografas Perpetua
regular en maysculas y minsculas d) UNERMB en tipografa Perpetua
Titling MT, todas en maysculas, con una modificacin al ser trazada a curva
asignndole una lnea para hacerla ligeramente un poco mas gruesa y de
esta manera compensara a las lneas del Estado Zulia para formar su
identidad grfica completa.
El color. Tanto el escudo y el logotipo tienen como color principal el
Celeste (cyan), Rojo, Amarillo, Azul y Negro, todos cmputos por los cuatro
colores PANTONE PROCESO (C.M.Y.K.), y Los porcentajes de los mismos,
tambin se utilizarn los PANTONES: AMARILLO 108 C / AZUL 2728 C y
RED 032 C. / VERDE 376 C / VERDE 3405 C
Modalidades de Uso
a) El logo puede ser utilizado en 2 modalidades (ver ejemplos)
b) No podr usarse de manera lineal
c) El smbolo del logotipo no se deber reforzar con filetes, marcos o
planos de color.
d) El smbolo solo podr ser utilizado con texto en forma de bloque en la
parte inferior y al centro o a la derecha de la manera como se presentan los
ejemplos
e) Cualquier modificacin deber ser consultada a la Direccin General
de Extensin y Comunicaciones de la Universidad
Pginas Webs
Para
las
pginas
webs
que
se
enlazan
con
el
portal
www.unermb.edu.ve se destacan los siguientes elementos:

Encabezado: en el primer 2/3 del encabezado se escribe UNERMB en
la primera lnea y la ubicacin a la cual se refiere el contenido que puede ser
la denominacin del sitio (programa, proyecto) y la << ubicacin >> en
maysculas y en negritas. En el ultimo tercio se coloca el logo.
Separador: inmediatamente debajo del encabezado una lnea gruesa
amarilla del largo hasta por debajo de la letra u de UNERMB, el resto una
lnea gruesa de color rojo, mas gruesa por debajo del logo.
Mens: las opciones principales se agrupan en el men principal y las
opciones referidas al contenido de la pgina se agrupan en el men
<<ubicacin >>
Mens
Encabezado
Contenido
ANEXO 2
MANUAL DE USUARIO
1.
Elementos de la Pgina Web del Sistema Acadmico de la

UNERMB
El sistema acadmico de la Universidad Nacional Experimental Rafael
Mara Baralt es un portal web diseado como un proyecto nico desde el

cual se accesan a los diferentes mdulos que lo conforman, entre ellos el
sistema para el registro, validacin y evaluacin de los proyectos de
investigacin.
A continuacin se presenta la pgina web del Sistema Acadmico de la
UNERMB:
Seccin de
Validacin de
Usuario
rea Mens
rea de
Mensajes y
Formularios
a) Seccin de Validacin de Usuario: comprende dos casillas, la

primera donde el usuario coloca su cdula y la segunda corresponde a la
contrasea, asimismo hay un enlace para cuando el usuario olvide su
contrasea y el botn entrar para validar el usuario y la contrasea
introducidos.
b) rea de Mens: corresponde opciones agrupadas en diferentes

mens las cuales son sensibles al usuario, es decir, de acuerdo al tipo de
usuario se mostrarn diferentes grupos de opciones.
c) rea de Formularios y Mensajes: comprende la seccin principal
del sistema desde donde se presentan los formularios y diferentes mensajes
que se proporcionarn a los usuarios para interactuar con el sistema.
2.
Accesando al Sistema Acadmico

Para accesar al sistema el usuario debe proporcionar su cdula y
contrasea:
El usuario
proporciona
su cdula y
contrasea
Si alguno de los datos no son vlidos se mostrar el mensaje

respectivo, en el caso de que el usuario olvid su contrasea puede hacer
click en el enlace que le pedir al usuario que responsa a una pregunta
secreta previamente registrada y luego le pedir su direccin de correo para
enviarle un e-mail con una contrasea provisional.
3.
Registro del Proyecto de Investigacin

Si el usuario es un estudiante se le presentar las opciones en los
mens que le corresponden, entre estas opciones est la de realizar el

registro de su proyecto de investigacin haciendo click en el enlace
respectivo.
Si aprob todas las materias del eje de investigacin (Metodologa I,

Metodologa II y Tesis I) se mostrar el botn para iniciar el proceso del
registro del proyecto de investigacin:
Por el contrario, si no aprob dichas materias se mostrar el mensaje:
Si el estudiante desea corroborar la anterior informacin puede

consultar las notas aprobadas durante sus estudios haciendo click en el
enlace Registro Acadmico:
El registro del proyecto de investigacin se realiza en un formulario:

El estudiante transcribe
el ttulo y los objetivos
del proyecto
En caso de que lo
requiera el estudiante
puede agregar ms
objetivos especficos
Se debe subir el archivo del
proyecto en formato word
Se elige un profesor de planta
como tutor acadmico
Finaliza el registro haciendo
click en el botn para
inscribir el proyecto
Se puede alternar entre un

tutor interno o uno externo,
en este caso se deben
registrar los datos
personales y subir el
currculo vitae
Al subir el archivo del proyecto de investigacin o el currculo del tutor

externo se mostrar un cuadro de dilogo para seleccionar el archivo:
4.
Validacin de Proyectos de Investigacin

Si el usuario coordinador de maestra o asistente de la unidad de
atencin a la investigacin podr hacer click en el enlace para validacin de

proyectos, el mismo es un mdulo administrativo que ofrece el listado de
todos los proyectos de investigacin de la maestra en que se ubica el
usuario. En el listado se puede elegir el proyecto que se desea validar y/o
realizar observaciones.
Seccin de Datos del

Participante
Seccin de Datos del

Proyecto, el coordinador de
maestra podr realizar
observaciones sobre los
datos del proyecto, si hay
observaciones se
reportarn al participante
para que realice las
respectivas correcciones
Se puede volver (sin

validar) o validar el
proyecto
ANEXO 3
DICCIONARIO DE DATOS
LISTA DE LAS TABLAS DE LA BASE DE DATOS

Tabla
Esquema
academico_materias
principal
academico_materiasconvalidaciones
principal
academico_materiasequivalencias
principal
historico_estudiantesregistro
principal
historico_horarios
principal
historico_notas
principal
historico_notas_errores
principal
historico_secciones
principal
historico_secciones_errores
principal
mae_estudiantes
principal
mae_estudiantes_original
principal
mae_estudiantesubicacion
principal
mae_profesores
principal
* mae_tutoresexternos
principal
* proyectos_evaluacion
principal
* proyectos_guia_evaluacion
principal
* proyectos_objetivos
principal
* proyectos_registro
principal
* proyectos_resultadoevaluacion
principal
* proyectos_validacion
principal
valores_aulas
principal
valores_entorno
principal
valores_observaciones
principal
valores_pensums
principal
valores_periodos
principal
valores_programasproyectos
principal
valores_sedes
principal
* Tablas agregadas a la base de datos actual de la para integrar el Sistema de

Informacin basado en ambiente web para los proyectos de investigacin de la
UNERMB
LISTADO DE LAS CLAVES FORNEAS DE LAS TABLAS
Nombre
Tabla Padre
Tabla Hijo
Columnas
Tabla Padre
abrev_proy,
pensum
Columnas
Tabla Hijo
abrev_proy,
pensum
pensums_materias_fkey
principal.valores_pensums
principal.academico_materias
materias_convalidaciones_fkey
principal.academico_materiascon
id
validaciones
id_materia
materias_equivalencias_fkey
principal.academico_materiasequ
id
ivalencias
id_materia
estudiantes_registro_fkey
principal.mae_estudiantes
principal.historico_estudiantesregi
id
stro
id_estudiante
proy_sede_registro_fkey
principal.valores_entorno
principal.historico_estudiantesregi abrev_proy,
stro
abrev_sede
abrev_proy,
abrev_sede
registro_periodos_fkey
principal.valores_periodos
principal.historico_estudiantesregi
id
stro
id_periodo
aulas_secciones_fkey
principal.valores_aulas
principal.historico_horarios
id
id_aula
secciones_horarios_fkey
principal.historico_secciones
principal.historico_horarios
id
id_seccion
estudiantes_notas_fkey
principal.historico_notas
id
id_estudiante
secciones_notas_fkey
principal.historico_notas
id
id_seccion
periodos_secciones_fkey
principal.valores_periodos
id
id_periodo
entorno_estudiantesubicacion_fkey
principal.mae_estudiantesubicaci
on
abrev_proy,
abrev_sede
abrev_proy,
abrev_sede
estudiantes_estudiantesubicacion_f
key
on
id
id_estudiante
estudiantes_ubicacionperiodos_fkey principal.valores_periodos
on
id
per_ing
Nombre
Tabla Padre
Tabla Hijo
Columnas
Tabla Padre
Columnas
Tabla Hijo
registro_objetivos_fkey
principal.proyectos_registro
principal.proyectos_objetivos
id_expediente id_expediente
maeestudiantes_proyectos_registro
_fkey
id
proyectos_registro_evaluacion_fkey principal.proyectos_evaluacion
id_evaluacion id_evaluacion
proyectos_registro_validacion_fkey
principal.proyectos_validacion
id_validacion
id_validacion
proyectos_tutores_externos
principal.mae_tutoresexternos
id
id_tutor_extern
o
proyectos_tutores_internos
principal.mae_profesores
id
id_expediente
sedes_proyectos_registro_fkey
principal.valores_sedes
abrev
sede_unidad_at
encion
proyectos_guia_evaluacion_fkey
principal.proyectos_guia_evaluacion
id_version,
principal.proyectos_resultadoeval
id_grupo,
uacion
id_item
id_estudiante
id_version,
id_grupo,
id_item
proyectos_resultados_evaluacion_fk
principal.proyectos_evaluacion
ey
uacion
proyectos_resultados_fkey
principal.proyectos_evaluacion
uacion
sedes_aulas_fkey
principal.valores_aulas
abrev
abrev_sede
entorno_programasproyectos_fkey
principal.valores_programasproyectos
abrev
abrev_proy
entorno_sedes_fkey
abrev
abrev_sede
principal.valores_pensums
abrev
abrev_proy
programasproyectos_pensums_fkey principal.valores_programasproyectos
Diagrama Entidad Relacin completo de la base de datos institucional de la UNERMB (sice-unermb)
Listado de la estructura de las tablas de la base de datos institucional

de la UNERMB
--- PostgreSQL database dump
--- Dumped from database version 9.1.2
-- Dumped by pg_dump version 9.1.2
-- Started on 2011-12-10 10:56:18
SET
SET
SET
SET
SET
statement_timeout = 0;
client_encoding = 'UTF8';
standard_conforming_strings = on;
check_function_bodies = false;
client_min_messages = warning;
--- TOC entry 6 (class 2615 OID 16394)

-- Name: principal; Type: SCHEMA; Schema: -; Owner: postgres
-CREATE SCHEMA principal;
ALTER SCHEMA principal OWNER TO postgres;
-- Name: sfDoctrineGuardPlugin; Type: SCHEMA; Schema: -; Owner: postgres
-CREATE SCHEMA "sfDoctrineGuardPlugin";
ALTER SCHEMA "sfDoctrineGuardPlugin" OWNER TO postgres;

-- Name: plpgsql; Type: EXTENSION; Schema: -; Owner:
-CREATE EXTENSION IF NOT EXISTS plpgsql WITH SCHEMA pg_catalog;
-- Dependencies: 219
-- Name: EXTENSION plpgsql; Type: COMMENT; Schema: -; Owner:
-COMMENT ON EXTENSION plpgsql IS 'PL/pgSQL procedural language';
SET search_path = principal, pg_catalog;
-- Dependencies: 6
-- Name: academico_materias_id_seq; Type: SEQUENCE; Schema: principal; Owner: postgres
-CREATE SEQUENCE academico_materias_id_seq
START WITH 1
INCREMENT BY 1
NO MINVALUE
NO MAXVALUE
CACHE 1;
ALTER TABLE principal.academico_materias_id_seq OWNER TO postgres;
-- Name: academico_materias_id_seq; Type: SEQUENCE SET; Schema: principal; Owner:
postgres
-SELECT pg_catalog.setval('academico_materias_id_seq', 921, true);
SET default_tablespace = '';
SET default_with_oids = false;
-- Dependencies: 2033 6
-- Name: academico_materias; Type: TABLE; Schema: principal; Owner: postgres; Tablespace:
-CREATE TABLE academico_materias (
id bigint DEFAULT nextval('academico_materias_id_seq'::regclass) NOT NULL,
abrev_proy character varying(10) NOT NULL,
pensum character varying(10) NOT NULL,
codigo character varying(15) NOT NULL,
sem integer NOT NULL,
nro_mat integer NOT NULL,
asignatura character varying(200) NOT NULL,
uc integer NOT NULL,
hs integer NOT NULL,
req01 character varying(15),
ht integer,
hp integer
);
ALTER TABLE principal.academico_materias OWNER TO postgres;

-- Dependencies: 6
-- Name: academico_materiasconvalidaciones; Type: TABLE; Schema: principal; Owner:
postgres; Tablespace:
-CREATE TABLE academico_materiasconvalidaciones (
id_materia bigint NOT NULL,
convalidacion character varying(15) NOT NULL,
tipo character varying(10)
);
ALTER TABLE principal.academico_materiasconvalidaciones OWNER TO postgres;

-- Dependencies: 6
-- Name: academico_materiasequivalencias; Type: TABLE; Schema: principal; Owner:
-CREATE TABLE academico_materiasequivalencias (
equivalencia character varying(15) NOT NULL
);
ALTER TABLE principal.academico_materiasequivalencias OWNER TO postgres;

-- Dependencies: 6
-- Name: historico_estudiantesregistro; Type: TABLE; Schema: principal; Owner: postgres;
Tablespace:
-CREATE TABLE historico_estudiantesregistro (
id_estudiante bigint NOT NULL,
id_periodo bigint NOT NULL,
abrev_sede character varying(10) NOT NULL,
condicion integer NOT NULL,
posicion integer,
hora_inscripcion time without time zone,
semestre integer,
num_aprob integer,
num_aplaz integer,
num_sinf integer,
es_preinscrito boolean,
estaba_retirado boolean,
estaba_suspendido boolean,
uc_aprob integer,
uc_cursadas integer,
es_becado boolean
);
ALTER TABLE principal.historico_estudiantesregistro OWNER TO postgres;
-- Dependencies: 6
-- Name: historico_horarios; Type: TABLE; Schema: principal; Owner: postgres; Tablespace:
-CREATE TABLE historico_horarios (
id_seccion bigint NOT NULL,
id_aula bigint NOT NULL,
ligaseccion character varying(25) NOT NULL,
n_dia_sem integer NOT NULL,
n_hora_ini integer NOT NULL,
n_hora_fin integer NOT NULL
);
ALTER TABLE principal.historico_horarios OWNER TO postgres;
-- Dependencies: 6
-- Name: historico_notas; Type: TABLE; Schema: principal; Owner: postgres; Tablespace:

-CREATE TABLE historico_notas (
id_seccion bigint NOT NULL,
n01 double precision,
adicional integer,
def double precision
);
ALTER TABLE principal.historico_notas OWNER TO postgres;
-- TOC entry 171 (class 1259 OID 16420)
-- Dependencies: 6
-- Name: historico_secciones_id_seq; Type: SEQUENCE; Schema: principal; Owner: postgres
-CREATE SEQUENCE historico_secciones_id_seq
START WITH 1
INCREMENT BY 1
NO MINVALUE
NO MAXVALUE
CACHE 1;
ALTER TABLE principal.historico_secciones_id_seq OWNER TO postgres;
-- Name: historico_secciones_id_seq; Type: SEQUENCE SET; Schema: principal; Owner:
postgres
-SELECT pg_catalog.setval('historico_secciones_id_seq', 12651, true);
-- Name: historico_secciones; Type: TABLE; Schema: principal; Owner: postgres;
Tablespace:
-CREATE TABLE historico_secciones (
id bigint DEFAULT nextval('historico_secciones_id_seq'::regclass) NOT NULL,
id_periodo bigint NOT NULL,

seccion character varying(15) NOT NULL,
id_profesor bigint NOT NULL,
max_cupo integer,
p01 double precision,
verificada boolean NOT NULL,
num_reg integer
);
ALTER TABLE principal.historico_secciones OWNER TO postgres;
-- Dependencies: 6
-- Name: mae_estudiantes_id_seq; Type: SEQUENCE; Schema: principal; Owner: postgres
-CREATE SEQUENCE mae_estudiantes_id_seq
START WITH 1
INCREMENT BY 1
NO MINVALUE
NO MAXVALUE
CACHE 1;
ALTER TABLE principal.mae_estudiantes_id_seq OWNER TO postgres;
-- Name: mae_estudiantes_id_seq; Type: SEQUENCE SET; Schema: principal; Owner: postgres
-SELECT pg_catalog.setval('mae_estudiantes_id_seq', 9730, true);
-- Name: mae_estudiantes; Type: TABLE; Schema: principal; Owner: postgres; Tablespace:
-CREATE TABLE mae_estudiantes (
id bigint DEFAULT nextval('mae_estudiantes_id_seq'::regclass) NOT NULL,
cedula bigint NOT NULL,
pasaporte character varying(15),
apellidos character varying(50),
nombres character varying(50),
nacionalidad character varying(1),
sexo character varying(1),

fec_nac date
);
ALTER TABLE principal.mae_estudiantes OWNER TO postgres;
-- Dependencies: 6
-- Name: mae_estudiantes_original; Type: TABLE; Schema: principal; Owner: postgres;
Tablespace:
-CREATE TABLE mae_estudiantes_original (
id bigint NOT NULL,
fec_nac date,
sexo character varying(1)
);
ALTER TABLE principal.mae_estudiantes_original OWNER TO postgres;
-- Name: mae_estudiantes_original_id_seq; Type: SEQUENCE; Schema: principal; Owner:
postgres
-CREATE SEQUENCE mae_estudiantes_original_id_seq
START WITH 1
INCREMENT BY 1
NO MINVALUE
NO MAXVALUE
CACHE 1;
ALTER TABLE principal.mae_estudiantes_original_id_seq OWNER TO postgres;
-- Name: mae_estudiantes_original_id_seq; Type: SEQUENCE OWNED BY; Schema: principal;
Owner: postgres
-ALTER SEQUENCE mae_estudiantes_original_id_seq OWNED BY mae_estudiantes_original.id;
-- Name: mae_estudiantes_original_id_seq; Type: SEQUENCE SET; Schema: principal; Owner:
postgres
-SELECT pg_catalog.setval('mae_estudiantes_original_id_seq', 1, false);
--
-- TOC entry 179 (class 1259 OID 16442)

-- Dependencies: 6
-- Name: mae_estudiantesubicacion; Type: TABLE; Schema: principal; Owner: postgres;
Tablespace:
-CREATE TABLE mae_estudiantesubicacion (
per_ing bigint NOT NULL,
pensum character varying(10),
modo_ing bit varying(10),
mencion character varying(10)
);
ALTER TABLE principal.mae_estudiantesubicacion OWNER TO postgres;
-- Dependencies: 6
-- Name: mae_profesores_id_seq; Type: SEQUENCE; Schema: principal; Owner: postgres
-CREATE SEQUENCE mae_profesores_id_seq
START WITH 1
INCREMENT BY 1
NO MINVALUE
NO MAXVALUE
CACHE 1;
ALTER TABLE principal.mae_profesores_id_seq OWNER TO postgres;
-- Name: mae_profesores_id_seq; Type: SEQUENCE SET; Schema: principal; Owner: postgres
-SELECT pg_catalog.setval('mae_profesores_id_seq', 1, true);
-- Name: mae_profesores; Type: TABLE; Schema: principal; Owner: postgres; Tablespace:
-CREATE TABLE mae_profesores (
id bigint DEFAULT nextval('mae_profesores_id_seq'::regclass) NOT NULL,
sexo character varying(1),
fec_nac date
);
ALTER TABLE principal.mae_profesores OWNER TO postgres;
-- Dependencies: 6
-- Name: mae_tutoresexternos; Type: TABLE; Schema: principal; Owner: postgres;
Tablespace:
-CREATE TABLE mae_tutoresexternos (
id bigint NOT NULL,
identificacion character varying(50) NOT NULL,
apellidos character varying(50) NOT NULL,
nombres character varying(50) NOT NULL,
fec_nac date,
sexo integer,
archivo_curriculo character varying(255),
es_pasaporte boolean
);
ALTER TABLE principal.mae_tutoresexternos OWNER TO postgres;
-- Name: mae_tutoresexternos_id_seq; Type: SEQUENCE; Schema: principal; Owner: postgres
-CREATE SEQUENCE mae_tutoresexternos_id_seq
START WITH 1
INCREMENT BY 1
NO MINVALUE
NO MAXVALUE
CACHE 1;
ALTER TABLE principal.mae_tutoresexternos_id_seq OWNER TO postgres;
-- Name: mae_tutoresexternos_id_seq; Type: SEQUENCE OWNED BY; Schema: principal; Owner:
postgres
-ALTER SEQUENCE mae_tutoresexternos_id_seq OWNED BY mae_tutoresexternos.id;

-- Name: mae_tutoresexternos_id_seq; Type: SEQUENCE SET; Schema: principal; Owner:
postgres
-SELECT pg_catalog.setval('mae_tutoresexternos_id_seq', 5, true);
-- Dependencies: 6
-- Name: proyectos_evaluacion; Type: TABLE; Schema: principal; Owner: postgres;
Tablespace:
-CREATE TABLE proyectos_evaluacion (
id_evaluacion bigint NOT NULL,
evaluacion_general character varying(255),
cumplimiento boolean
);
ALTER TABLE principal.proyectos_evaluacion OWNER TO postgres;
-- Name: proyectos_evaluacion_id_evaluacion_seq; Type: SEQUENCE; Schema: principal;
Owner: postgres
-CREATE SEQUENCE proyectos_evaluacion_id_evaluacion_seq
START WITH 1
INCREMENT BY 1
NO MINVALUE
NO MAXVALUE
CACHE 1;
ALTER TABLE principal.proyectos_evaluacion_id_evaluacion_seq OWNER TO postgres;
-- Name: proyectos_evaluacion_id_evaluacion_seq; Type: SEQUENCE OWNED BY; Schema:
principal; Owner: postgres
-ALTER SEQUENCE proyectos_evaluacion_id_evaluacion_seq OWNED BY
proyectos_evaluacion.id_evaluacion;
-- Name: proyectos_evaluacion_id_evaluacion_seq; Type: SEQUENCE SET; Schema: principal;
Owner: postgres
-SELECT pg_catalog.setval('proyectos_evaluacion_id_evaluacion_seq', 1, false);
-- Dependencies: 2041 2042 2043 2044 6
-- Name: proyectos_guia_evaluacion; Type: TABLE; Schema: principal; Owner: postgres;
Tablespace:
-CREATE TABLE proyectos_guia_evaluacion (
id_version bigint DEFAULT 0 NOT NULL,
id_grupo integer DEFAULT 0 NOT NULL,
id_item integer DEFAULT 0 NOT NULL,
nro_item integer DEFAULT 0 NOT NULL,
descripcion character varying(255) NOT NULL
);
ALTER TABLE principal.proyectos_guia_evaluacion OWNER TO postgres;
-- Dependencies: 6
-- Name: proyectos_objetivos; Type: TABLE; Schema: principal; Owner: postgres;

Tablespace:
-CREATE TABLE proyectos_objetivos (
id_expediente bigint NOT NULL,
id_objetivo bigint NOT NULL,
objetivo character varying(255) NOT NULL,
objetivo_modificado character varying(255),
obs_validacion bigint,
f_ultimo_acceso timestamp without time zone,
f_modificacion timestamp without time zone
);
ALTER TABLE principal.proyectos_objetivos OWNER TO postgres;

-- Name: proyectos_objetivos_id_expediente_seq; Type: SEQUENCE; Schema: principal; Owner:
postgres
-CREATE SEQUENCE proyectos_objetivos_id_expediente_seq
START WITH 1
INCREMENT BY 1
NO MINVALUE
NO MAXVALUE
CACHE 1;
ALTER TABLE principal.proyectos_objetivos_id_expediente_seq OWNER TO postgres;

-- Name: proyectos_objetivos_id_expediente_seq; Type: SEQUENCE OWNED BY; Schema:
-ALTER SEQUENCE proyectos_objetivos_id_expediente_seq OWNED BY
proyectos_objetivos.id_expediente;
-- Name: proyectos_objetivos_id_expediente_seq; Type: SEQUENCE SET; Schema: principal;
Owner: postgres
-SELECT pg_catalog.setval('proyectos_objetivos_id_expediente_seq', 1, false);
-- Dependencies: 2045 2046 6
-- Name: proyectos_registro; Type: TABLE; Schema: principal; Owner: postgres; Tablespace:
-CREATE TABLE proyectos_registro (
id_expediente bigint NOT NULL,
id_validacion bigint,
id_evaluacion bigint,
id_tutor_interno bigint DEFAULT 1,

id_tutor_externo bigint DEFAULT 1,
f_creacion timestamp without time zone,
f_ultimo_acceso timestamp without time zone,
f_modificacion timestamp without time zone,
sede_unidad_atencion character varying(10),
obs character varying(255),
titulo_proyecto character varying(255) NOT NULL,
archivo_proyecto character varying(255) NOT NULL,
proyecto_aprobado boolean
);
ALTER TABLE principal.proyectos_registro OWNER TO postgres;

-- Name: proyectos_registro_id_expediente_seq; Type: SEQUENCE; Schema: principal; Owner:
postgres
-CREATE SEQUENCE proyectos_registro_id_expediente_seq
START WITH 1
INCREMENT BY 1
NO MINVALUE
NO MAXVALUE
CACHE 1;
ALTER TABLE principal.proyectos_registro_id_expediente_seq OWNER TO postgres;

-- Name: proyectos_registro_id_expediente_seq; Type: SEQUENCE OWNED BY; Schema:
-ALTER SEQUENCE proyectos_registro_id_expediente_seq OWNED BY
proyectos_registro.id_expediente;
-- Name: proyectos_registro_id_expediente_seq; Type: SEQUENCE SET; Schema: principal;
Owner: postgres
-SELECT pg_catalog.setval('proyectos_registro_id_expediente_seq', 23, true);
-- Dependencies: 6
-- Name: proyectos_resultadoevaluacion; Type: TABLE; Schema: principal; Owner: postgres;
Tablespace:
-CREATE TABLE proyectos_resultadoevaluacion (
id_evaluacion bigint NOT NULL,
id_version bigint NOT NULL,
id_grupo integer NOT NULL,
id_item integer NOT NULL,
resultado integer,
observacion_item character varying(255)

);
ALTER TABLE principal.proyectos_resultadoevaluacion OWNER TO postgres;
-- Dependencies: 6
-- Name: proyectos_validacion; Type: TABLE; Schema: principal; Owner: postgres;
Tablespace:
-CREATE TABLE proyectos_validacion (
id_validacion bigint NOT NULL,
f_creacion timestamp without time zone,
f_ultimo_acceso timestamp without time zone
);
ALTER TABLE principal.proyectos_validacion OWNER TO postgres;
-- Name: proyectos_validacion_id_validacion_seq; Type: SEQUENCE; Schema: principal;
Owner: postgres
-CREATE SEQUENCE proyectos_validacion_id_validacion_seq
START WITH 1
INCREMENT BY 1
NO MINVALUE
NO MAXVALUE
CACHE 1;
ALTER TABLE principal.proyectos_validacion_id_validacion_seq OWNER TO postgres;
-- Name: proyectos_validacion_id_validacion_seq; Type: SEQUENCE OWNED BY; Schema:
-ALTER SEQUENCE proyectos_validacion_id_validacion_seq OWNED BY
proyectos_validacion.id_validacion;
-- Name: proyectos_validacion_id_validacion_seq; Type: SEQUENCE SET; Schema: principal;
Owner: postgres
-SELECT pg_catalog.setval('proyectos_validacion_id_validacion_seq', 1, false);
-- Dependencies: 6
-- Name: valores_aulas_id_seq; Type: SEQUENCE; Schema: principal; Owner: postgres
--
CREATE SEQUENCE valores_aulas_id_seq

START WITH 1
INCREMENT BY 1
NO MINVALUE
NO MAXVALUE
CACHE 1;
ALTER TABLE principal.valores_aulas_id_seq OWNER TO postgres;
-- Name: valores_aulas_id_seq; Type: SEQUENCE SET; Schema: principal; Owner: postgres
-SELECT pg_catalog.setval('valores_aulas_id_seq', 1, false);
-- Name: valores_aulas; Type: TABLE; Schema: principal; Owner: postgres; Tablespace:
-CREATE TABLE valores_aulas (
id bigint DEFAULT nextval('valores_aulas_id_seq'::regclass) NOT NULL,
nom_aula character varying(15) NOT NULL
);
ALTER TABLE principal.valores_aulas OWNER TO postgres;

-- Dependencies: 6
-- Name: valores_entorno; Type: TABLE; Schema: principal; Owner: postgres; Tablespace:
-CREATE TABLE valores_entorno (
cod_prog character varying(2) NOT NULL,
cod_proy character varying(2) NOT NULL,
cod_sede character varying(2) NOT NULL,
autoridad character varying(50),
ced_autoridad bigint,
titulo_autoridad character varying(25)
);
ALTER TABLE principal.valores_entorno OWNER TO postgres;
-- Dependencies: 6
-- Name: valores_observaciones; Type: TABLE; Schema: principal; Owner: postgres;
Tablespace:
-CREATE TABLE valores_observaciones (
id_observacion bigint NOT NULL,
descripcion character varying(255) NOT NULL,
nivel character varying(2)
);
ALTER TABLE principal.valores_observaciones OWNER TO postgres;

-- Name: valores_observaciones_id_observacion_seq; Type: SEQUENCE; Schema: principal;
Owner: postgres
-CREATE SEQUENCE valores_observaciones_id_observacion_seq
START WITH 1
INCREMENT BY 1
NO MINVALUE
NO MAXVALUE
CACHE 1;
ALTER TABLE principal.valores_observaciones_id_observacion_seq OWNER TO postgres;
-- Name: valores_observaciones_id_observacion_seq; Type: SEQUENCE OWNED BY; Schema:
-ALTER SEQUENCE valores_observaciones_id_observacion_seq OWNED BY
valores_observaciones.id_observacion;

-- Name: valores_observaciones_id_observacion_seq; Type: SEQUENCE SET; Schema: principal;
Owner: postgres
-SELECT pg_catalog.setval('valores_observaciones_id_observacion_seq', 7, true);
-- Dependencies: 6
-- Name: valores_pensums; Type: TABLE; Schema: principal; Owner: postgres; Tablespace:
-CREATE TABLE valores_pensums (
pensum character varying(10) NOT NULL
);
ALTER TABLE principal.valores_pensums OWNER TO postgres;
-- Dependencies: 6
-- Name: valores_periodos_id_seq; Type: SEQUENCE; Schema: principal; Owner: postgres
-CREATE SEQUENCE valores_periodos_id_seq
START WITH 1
INCREMENT BY 1
NO MINVALUE
NO MAXVALUE
CACHE 1;
ALTER TABLE principal.valores_periodos_id_seq OWNER TO postgres;
-- Name: valores_periodos_id_seq; Type: SEQUENCE SET; Schema: principal; Owner: postgres
-SELECT pg_catalog.setval('valores_periodos_id_seq', 1, false);

-- Name: valores_periodos; Type: TABLE; Schema: principal; Owner: postgres; Tablespace:
-CREATE TABLE valores_periodos (
id bigint DEFAULT nextval('valores_periodos_id_seq'::regclass) NOT NULL,
nom_periodo character varying(8) NOT NULL,
fec_inicio date,
fec_finalizacion date
);
ALTER TABLE principal.valores_periodos OWNER TO postgres;
-- Dependencies: 6
-- Name: valores_programasproyectos; Type: TABLE; Schema: principal; Owner: postgres;
Tablespace:
-CREATE TABLE valores_programasproyectos (
cod_prog character varying(2) NOT NULL,
cod_proy character varying(2) NOT NULL,
denominacion character varying(100) NOT NULL,
abrev character varying(10) NOT NULL,
autoridad character varying(50),
ced_autoridad bigint,
titulo_autoridad character varying(25),
esquema character varying(100)
);
ALTER TABLE principal.valores_programasproyectos OWNER TO postgres;
-- Dependencies: 6
-- Name: valores_sedes; Type: TABLE; Schema: principal; Owner: postgres; Tablespace:
-CREATE TABLE valores_sedes (
cod_sede character varying(2) NOT NULL,
denominacion character varying(50) NOT NULL,
abrev character varying(10) NOT NULL
);
ALTER TABLE principal.valores_sedes OWNER TO postgres;
SET search_path = "sfDoctrineGuardPlugin", pg_catalog;

-- Dependencies: 7
-- Name: sf_guard_forgot_password_id_seq; Type: SEQUENCE; Schema: sfDoctrineGuardPlugin;
Owner: postgres
-CREATE SEQUENCE sf_guard_forgot_password_id_seq
START WITH 1
INCREMENT BY 1
NO MINVALUE
NO MAXVALUE
CACHE 1;
ALTER TABLE "sfDoctrineGuardPlugin".sf_guard_forgot_password_id_seq OWNER TO postgres;
-- Name: sf_guard_forgot_password_id_seq; Type: SEQUENCE SET; Schema:
sfDoctrineGuardPlugin; Owner: postgres
-SELECT pg_catalog.setval('sf_guard_forgot_password_id_seq', 1, false);

-- Name: sf_guard_forgot_password; Type: TABLE; Schema: sfDoctrineGuardPlugin; Owner:
-CREATE TABLE sf_guard_forgot_password (
id bigint DEFAULT nextval('sf_guard_forgot_password_id_seq'::regclass) NOT NULL,
user_id bigint NOT NULL,
unique_key character varying(255),
expires_at timestamp without time zone NOT NULL,
created_at timestamp without time zone NOT NULL,
updated_at timestamp without time zone NOT NULL
);
ALTER TABLE "sfDoctrineGuardPlugin".sf_guard_forgot_password OWNER TO postgres;

-- Dependencies: 7
-- Name: sf_guard_group_id_seq; Type: SEQUENCE; Schema: sfDoctrineGuardPlugin; Owner:
postgres
-CREATE SEQUENCE sf_guard_group_id_seq
START WITH 1
INCREMENT BY 1
NO MINVALUE
NO MAXVALUE
CACHE 1;
ALTER TABLE "sfDoctrineGuardPlugin".sf_guard_group_id_seq OWNER TO postgres;

-- Name: sf_guard_group_id_seq; Type: SEQUENCE SET; Schema: sfDoctrineGuardPlugin; Owner:
postgres
-SELECT pg_catalog.setval('sf_guard_group_id_seq', 1, false);
-- Name: sf_guard_group; Type: TABLE; Schema: sfDoctrineGuardPlugin; Owner: postgres;
Tablespace:
-CREATE TABLE sf_guard_group (
id bigint DEFAULT nextval('sf_guard_group_id_seq'::regclass) NOT NULL,
name character varying(255),
description character varying(1000),
);
ALTER TABLE "sfDoctrineGuardPlugin".sf_guard_group OWNER TO postgres;
-- Dependencies: 7
-- Name: sf_guard_group_permission; Type: TABLE; Schema: sfDoctrineGuardPlugin; Owner:
-CREATE TABLE sf_guard_group_permission (
group_id bigint NOT NULL,
permission_id bigint NOT NULL,
);
ALTER TABLE "sfDoctrineGuardPlugin".sf_guard_group_permission OWNER TO postgres;
-- Dependencies: 7
-- Name: sf_guard_permission_id_seq; Type: SEQUENCE; Schema: sfDoctrineGuardPlugin;
Owner: postgres
-CREATE SEQUENCE sf_guard_permission_id_seq
START WITH 1
INCREMENT BY 1
NO MINVALUE
NO MAXVALUE
CACHE 1;
ALTER TABLE "sfDoctrineGuardPlugin".sf_guard_permission_id_seq OWNER TO postgres;
-- Name: sf_guard_permission_id_seq; Type: SEQUENCE SET; Schema: sfDoctrineGuardPlugin;

Owner: postgres
-SELECT pg_catalog.setval('sf_guard_permission_id_seq', 5, true);
-- Name: sf_guard_permission; Type: TABLE; Schema: sfDoctrineGuardPlugin; Owner:
-CREATE TABLE sf_guard_permission (
id bigint DEFAULT nextval('sf_guard_permission_id_seq'::regclass) NOT NULL,
name character varying(255),
description character varying(1000),
);
ALTER TABLE "sfDoctrineGuardPlugin".sf_guard_permission OWNER TO postgres;
-- Dependencies: 7
-- Name: sf_guard_remember_key_id_seq; Type: SEQUENCE; Schema: sfDoctrineGuardPlugin;
Owner: postgres
-CREATE SEQUENCE sf_guard_remember_key_id_seq
START WITH 1
INCREMENT BY 1
NO MINVALUE
NO MAXVALUE
CACHE 1;
ALTER TABLE "sfDoctrineGuardPlugin".sf_guard_remember_key_id_seq OWNER TO postgres;
-- Name: sf_guard_remember_key_id_seq; Type: SEQUENCE SET; Schema: sfDoctrineGuardPlugin;
Owner: postgres
-SELECT pg_catalog.setval('sf_guard_remember_key_id_seq', 1, false);
-- Name: sf_guard_remember_key; Type: TABLE; Schema: sfDoctrineGuardPlugin; Owner:
-CREATE TABLE sf_guard_remember_key (
id bigint DEFAULT nextval('sf_guard_remember_key_id_seq'::regclass) NOT NULL,
user_id bigint,
remember_key character varying(32),
ip_address character varying(50),
);
ALTER TABLE "sfDoctrineGuardPlugin".sf_guard_remember_key OWNER TO postgres;
-- Dependencies: 7
-- Name: sf_guard_user_id_seq; Type: SEQUENCE; Schema: sfDoctrineGuardPlugin; Owner:
postgres
-CREATE SEQUENCE sf_guard_user_id_seq
START WITH 1
INCREMENT BY 1
NO MINVALUE
NO MAXVALUE
CACHE 1;
ALTER TABLE "sfDoctrineGuardPlugin".sf_guard_user_id_seq OWNER TO postgres;
-- Name: sf_guard_user_id_seq; Type: SEQUENCE SET; Schema: sfDoctrineGuardPlugin; Owner:
postgres
-SELECT pg_catalog.setval('sf_guard_user_id_seq', 21, true);

-- Dependencies: 2056 2057 2058 2059 7
-- Name: sf_guard_user; Type: TABLE; Schema: sfDoctrineGuardPlugin; Owner: postgres;
Tablespace:
-CREATE TABLE sf_guard_user (
id bigint DEFAULT nextval('sf_guard_user_id_seq'::regclass) NOT NULL,
first_name character varying(255),
last_name character varying(255),
email_address character varying(255) NOT NULL,
username character varying(128) NOT NULL,
algorithm character varying(128) DEFAULT 'sha1'::character varying NOT NULL,
salt character varying(128),
password character varying(128),
is_active boolean DEFAULT true,
is_super_admin boolean DEFAULT false,
last_login timestamp without time zone,
);
ALTER TABLE "sfDoctrineGuardPlugin".sf_guard_user OWNER TO postgres;
-- Dependencies: 7
-- Name: sf_guard_user_group; Type: TABLE; Schema: sfDoctrineGuardPlugin; Owner:
-CREATE TABLE sf_guard_user_group (

group_id bigint NOT NULL,
);
ALTER TABLE "sfDoctrineGuardPlugin".sf_guard_user_group OWNER TO postgres;
-- Dependencies: 7
-- Name: sf_guard_user_permission; Type: TABLE; Schema: sfDoctrineGuardPlugin; Owner:
-CREATE TABLE sf_guard_user_permission (
permission_id bigint NOT NULL,
);
ALTER TABLE "sfDoctrineGuardPlugin".sf_guard_user_permission OWNER TO postgres;
-- Dependencies: 7
-- Name: sf_guard_user_profile_id_seq; Type: SEQUENCE; Schema: sfDoctrineGuardPlugin;
Owner: postgres
-CREATE SEQUENCE sf_guard_user_profile_id_seq
START WITH 1
INCREMENT BY 1
NO MINVALUE
NO MAXVALUE
CACHE 1;
ALTER TABLE "sfDoctrineGuardPlugin".sf_guard_user_profile_id_seq OWNER TO postgres;
-- Name: sf_guard_user_profile_id_seq; Type: SEQUENCE SET; Schema: sfDoctrineGuardPlugin;
Owner: postgres
-SELECT pg_catalog.setval('sf_guard_user_profile_id_seq', 22, true);
-- Name: sf_guard_user_profile; Type: TABLE; Schema: sfDoctrineGuardPlugin; Owner:
-CREATE TABLE sf_guard_user_profile (
id bigint DEFAULT nextval('sf_guard_user_profile_id_seq'::regclass) NOT NULL,
email character varying(255) NOT NULL,
first_name character varying(80),
last_name character varying(80),
validate character varying(17)

);
ALTER TABLE "sfDoctrineGuardPlugin".sf_guard_user_profile OWNER TO postgres;
SET search_path = principal, pg_catalog;
-- Name: id; Type: DEFAULT; Schema: principal; Owner: postgres
-ALTER TABLE mae_estudiantes_original ALTER COLUMN id SET DEFAULT
nextval('mae_estudiantes_original_id_seq'::regclass);
-- Name: id; Type: DEFAULT; Schema: principal; Owner: postgres
-ALTER TABLE mae_tutoresexternos ALTER COLUMN id SET DEFAULT
nextval('mae_tutoresexternos_id_seq'::regclass);
-- Name: id_evaluacion; Type: DEFAULT; Schema: principal; Owner: postgres
-ALTER TABLE proyectos_evaluacion ALTER COLUMN id_evaluacion SET DEFAULT
nextval('proyectos_evaluacion_id_evaluacion_seq'::regclass);
-- Name: id_expediente; Type: DEFAULT; Schema: principal; Owner: postgres
-ALTER TABLE proyectos_registro ALTER COLUMN id_expediente SET DEFAULT
nextval('proyectos_registro_id_expediente_seq'::regclass);

-- Name: id_validacion; Type: DEFAULT; Schema: principal; Owner: postgres
-ALTER TABLE proyectos_validacion ALTER COLUMN id_validacion SET DEFAULT
nextval('proyectos_validacion_id_validacion_seq'::regclass);
-- Name: id_observacion; Type: DEFAULT; Schema: principal; Owner: postgres
-ALTER TABLE valores_observaciones ALTER COLUMN id_observacion SET DEFAULT
nextval('valores_observaciones_id_observacion_seq'::regclass)
ANEXO 4
LOS PLUGINS PARA EL CONTROL DE ACCESO Y AUTENTICACIN
SFGUARDDOCTRINEPLUGIN Y SFAUTHPLUGIN
1.
INSTALACION DEL SFDOCTRINEGUARDPLUGIN

Como siempre la instalacin ms sencilla es desde ejecutando el
siguiente comando:
symfony plugin:install sfDoctrineGuardPlugin
Alternativamente se puede hacer va SVN, ubicndonos en la raz de

nuestro proyecto:
svn co http://svn.symfonyproject.com/plugins/sfDoctrineGuardPlugin/trunk
plugins/sfDoctrineGuardPlugin
Luego hay que agregar el plugin a la configuracin del proyecto, en el

archivo /config/ProjectConfiguration.class.php:
class ProjectConfiguration extends sfProjectConfiguration
{
public function setup()
{
$this->enablePlugins(array(
'sfDoctrinePlugin',
'sfDoctrineGuardPlugin',
//'...'
));
}
}
Ahora hay que construir el modelo:

symfony doctrine:build --all --and-load --no-confirmation
En la carpeta del plugin hay un fixture con un super administrador, para

copiarlo se puede hacerlo a mano o bien ejecutar los siguientes comandos:
mkdir data/fixtures/
cp
plugins/sfDoctrineGuardPlugin/data/fixtures/fixtures.yml.sample
data/fixtures/sfGuard.yml
symfony doctrine:data-load
2.
CONFIGURACIN
Las siguientes modificaciones se realizan en los archivos de
configuracin de la aplicacin, tuApp/config

Para habilitar el mdulo para autentificar o de inicio sesin de los
usuarios es necesario agregar la siguiente lnea dentro de .settings en el
archivo setting.yml:
all:
.settings:
enabled_modules:
[default, sfGuardAuth]
Las siguientes modificaciones se realizan en los archivos de

configuracin de la aplicacin, tuApp/config
Opcionalmente se pueden habilitar los siguientes modulos para
administrar usuarios, grupos y permisos. (Est claro que estos mdulos son
para aplicacin de administrador)
all:
.settings:
enabled_modules:
sfGuardPermission]
[default, sfGuardGroup, sfGuardUser,
Para habilitar la opcin de recordar los datos del usuario en una

Cookie hay que agregar el item remember_me sobre el tem security en el
archivo filters.yml:
remember_me:
class: sfGuardRememberMeFilter
security: ~
Limpiar el cach:
symfony cc
Para modificar los mdulos y la accin a utilizar para autentificar a los

usuarios, hay que agregar las siguientes lneas dentro de .settings en el
archivo setting.yml.
.all:
.settings:
#...
login_module:
login_action:
secure_module:
secure_action:
sfGuardAuth
signin
sfGuardAuth
secure
Luego en la carpeta /lib de la aplicacin, hay que modificar la clase

myUser.class.php
class myUser extends sfGuardSecurityUser
{
}
Luego, opcionalmente, se pueden cambiar los nombres a las URLs para

que se vean de alguna otra forma, agregar las siguientes lineas en el archivo
de routing.yml, ojo que tienen que estar antes que las reglas genricas
creadas por defecto y debes tener una @homepage (que se usa cuando se
hace un logout de un usuario):
#sfGuardAuth
sf_guard_signin:
url:
/ingresar
param: { module: sfGuardAuth, action: signin }
sf_guard_signout:
url:
/salir
param: { module: sfGuardAuth, action: signout }
sf_guard_password:
url:
/recuperar-password
param: { module: sfGuardAuth, action: password }
# generic rules
# please, remove them by adding more specific rules
default_index:
url:
/:module
param: { action: index }
default:
url:
/:module/:action/*
Luego hay que eliminar los enrutamientos por defecto agregando lo

siguiente en el archivo app.yml
all:
sf_guard_plugin:
routes_register: false
Ahora, aseguramos toda la aplicacin

default:
is_secure: true
Cuando un usuario est autenticado, el acceso a algunas acciones

pueden ser an ms restringida por la definicin de credenciales. Un usuario
debe tener las credenciales para acceder a la pgina:
default:
is_secure:
false
credentials: admin
El sistema de credenciales de Symfony es bastante simple y poderoso.

Una credencial puede representar todo lo que sea necesario para describir la
seguridad al modelo de la aplicacin (como grupos o permisos).
3.
CREDENCIALES COMPLEJAS
El item credentials de security.yml soporta operadores Booleanos para
describir las necesidades complejas en credenciales.
Si un usuario debe tener credenciales A y B, hay que envolver las

credenciales con corchetes:
index:
credentials: [A, B]
Si un usuario debe tener credenciales A o B, hay que envolver las

credenciales con dos pares de corchetes:
index:
credentials: [[A, B]]
Incluso puedes mezclar y combinar entre parntesis para describir

cualquier tipo de Expresin booleana con cualquier nmero de credenciales.
Para gestionar las credenciales de usuario, sfBasicSecurityUser da
varios mtodos:
// Add one or more credentials
$user->addCredential('foo');
$user->addCredentials('foo', 'bar');
// Check if the user has a credential
echo $user->hasCredential('foo');
true
=>
// Check if the user has both credentials

echo $user->hasCredential(array('foo', 'bar'));
true
=>
// Check if the user has one of the credentials

echo $user->hasCredential(array('foo', 'bar'), false); =>
true
// Remove a credential
$user->removeCredential('foo');
echo $user->hasCredential('foo');
false
=>
// Remove all credentials (useful in the logout process)

$user->clearCredentials();
echo $user->hasCredential('bar');
false
4.
=>
PERSONALIZAR LOS TEMPLATES DE SFGUARDAUTH

Si se desea modificar como luce el Login de este plugin debes modificar
los archivos signinSuccess.php y secureSuccess.php

Para ello se debe crear un nuevo mdulo en la aplicacin con el nombre
sfGuardAuth, luego en la carpeta de templates debes crear los archivos
recin mencionados. Adems para que el mdulo tenga sentido hay que
modificar el archivo de acciones tal como sigue a continuacin:
require_once(sfConfig::get('sf_plugins_dir').'/sfDoctrineGuard
Plugin/modules/sfGuardAuth/lib/BasesfGuardAuthActions.class.php
');
class sfGuardAuthActions extends BasesfGuardAuthActions
{
}
Con esto estamos listos para modificar la plantilla del login

(signinSuccess.php). Aqu ya queda a criterio de cada uno el diseo que
puede tomar, por ejemplo:
<?php if ($form->hasErrors()): ?>
<div class="flash_error">
<strong>Error</strong>: El nombre de usuario o
contrasea no son vlidos.
</div>
<?php endif; ?>
<div class="login">
<form action="<?php echo url_for('@sf_guard_signin')
?>" method="post">
<label class="unico" for="signin_username">
Nombre de usuario
</label>
<?php echo $form['username'] ?>
<label class="unico" for="signin_password">

Contrasea
</label>
<?php echo $form['password'] ?>
<label for="signin_remember">
Recordarme
</label>
<?php echo $form['remember']->render() ?>
<button type="submit">Iniciar Sesin</button>
<?php echo $form['_csrf_token'] ?>
</form>
<a href="<?php echo url_for('@sf_guard_password');
?>"><?php echo ('Problemas para acceder a su cuenta?') ?></a>
</div>
Con esto ya est funcionando el login para nuestra aplicacin.
ANEXO 5
ESQUEMA DE LA BASE DE DATOS (SCHEMA.YML)
Principal_AcademicoMaterias_Item:
connection: doctrine
tableName: principal.academico_materias
columns:
id:
type: integer(8)
fixed: false
unsigned: false
primary: true
sequence: principal.academico_materias_id
abrev_proy:
type: string(10)
fixed: false
unsigned: false
notnull: true
primary: false
pensum:
type: string(10)
fixed: false
unsigned: false
notnull: true
primary: false
codigo:
type: string(15)
fixed: false
unsigned: false
notnull: true
primary: false
sem:
type: integer(4)
fixed: false
unsigned: false
notnull: true
primary: false
nro_mat:
type: integer(4)
fixed: false
unsigned: false
notnull: true
primary: false
asignatura:
type: string(200)
fixed: false
unsigned: false
notnull: true
primary: false
uc:
type: integer(4)
fixed: false
unsigned: false
notnull: true
primary: false
hs:
type: integer(4)
fixed: false
unsigned: false
notnull: true
primary: false
req01:
type: string(15)
fixed: false
unsigned: false
notnull: false
primary: false
req02:
type: string(15)
fixed: false
unsigned: false
notnull: false
primary: false
req03:
type: string(15)
fixed: false
unsigned: false
notnull: false
primary: false
req04:
type: string(15)
fixed: false
unsigned: false
notnull: false
primary: false
ht:
type: integer(4)
fixed: false
unsigned: false
notnull: false
primary: false
hp:
type: integer(4)
fixed: false
unsigned: false
notnull: false
primary: false
package: Principal.Entities
relations:
Principal_AcademicoMateriasconvalidaciones_Items:
class: Principal_AcademicoMateriasconvalidaciones_Item
local: id
foreign: id_materia
type: many
Principal_AcademicoMateriasequivalencias_Items:
class: Principal_AcademicoMateriasequivalencias_Item
local: id
foreign: id_materia
type: many
Principal_AcademicoMateriasconvalidaciones_Item:
tableName: principal.academico_materiasconvalidaciones
columns:
id_materia:
type: integer(8)
fixed: false
unsigned: false
primary: true
convalidacion:
type: string(15)
fixed: false
unsigned: false
notnull: true
primary: false
tipo:
type: string(10)
fixed: false
unsigned: false
notnull: false
primary: false
relations:
local: id_materia
foreign: id
type: one
Principal_AcademicoMateriasequivalencias_Item:
tableName: principal.academico_materiasequivalencias
columns:
id_materia:
type: integer(8)
fixed: false
unsigned: false
primary: true
equivalencia:
type: string(15)
fixed: false
unsigned: false
notnull: true
primary: false
relations:
local: id_materia
foreign: id
type: one
Principal_HistoricoEstudiantesregistro_Item:
tableName: principal.historico_estudiantesregistro
columns:
id_estudiante:
type: integer(8)
fixed: false
unsigned: false
primary: true
id_periodo:
type: integer(8)
fixed: false
unsigned: false
primary: true
abrev_proy:
type: string(10)
fixed: false
unsigned: false
notnull: true
primary: false
abrev_sede:
type: string(10)
fixed: false
unsigned: false
notnull: true
primary: false
condicion:
type: integer(4)
fixed: false
unsigned: false
notnull: true
primary: false
posicion:
type: integer(4)
fixed: false
unsigned: false
notnull: false
primary: false
hora_inscripcion:
type: time(25)
fixed: false
unsigned: false
notnull: false
primary: false
semestre:
type: integer(4)
fixed: false
unsigned: false
notnull: false
primary: false
num_aprob:
type: integer(4)
fixed: false
unsigned: false
notnull: false
primary: false
num_aplaz:
type: integer(4)
fixed: false
unsigned: false
notnull: false
primary: false
num_sinf:
type: integer(4)
fixed: false
unsigned: false
notnull: false
primary: false
es_preinscrito:
type: boolean(1)
fixed: false
unsigned: false
notnull: false
primary: false
estaba_retirado:
type: boolean(1)
fixed: false
unsigned: false
notnull: false
primary: false
estaba_suspendido:
type: boolean(1)
fixed: false
unsigned: false
notnull: false
primary: false
uc_aprob:
type: integer(4)
fixed: false
unsigned: false
notnull: false
primary: false
uc_cursadas:
type: integer(4)
fixed: false
unsigned: false
notnull: false
primary: false
es_becado:
type: boolean(1)
fixed: false
unsigned: false
notnull: false
primary: false
relations:
Principal_MaeEstudiantes_Item:
local: id_estudiante
foreign: id
type: one
Principal_ValoresPeriodos_Item:
local: id_periodo
foreign: id
type: one
Principal_HistoricoHorarios_Item:
tableName: principal.historico_horarios
columns:
id_seccion:
type: integer(8)
fixed: false
unsigned: false
primary: true
id_aula:
type: integer(8)
fixed: false
unsigned: false
primary: true
ligaseccion:
type: string(25)
fixed: false
unsigned: false
notnull: true
primary: false
n_dia_sem:
type: integer(4)
fixed: false
unsigned: false
notnull: true
primary: false
n_hora_ini:
type: integer(4)
fixed: false
unsigned: false
notnull: true
primary: false
n_hora_fin:
type: integer(4)
fixed: false
unsigned: false
notnull: true
primary: false
relations:
Principal_ValoresAulas_Item:
local: id_aula
foreign: id
type: one
Principal_HistoricoSecciones_Item:
local: id_seccion
foreign: id
type: one
Principal_HistoricoNotasErrores_Item:
tableName: principal.historico_notas_errores
columns:
id_estudiante:
type: integer(8)
fixed: false
unsigned: false
primary: true
id_seccion:
type: integer(8)
fixed: false
unsigned: false
primary: true
ligaseccion:
type: string(50)
fixed: false
unsigned: false
primary: true
n01:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
n02:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
n03:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
n04:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
n05:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
n06:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
n07:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
n08:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
n09:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
n10:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
n11:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
n12:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
n13:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
n14:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
n15:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
adicional:
type: integer(4)
fixed: false
unsigned: false
notnull: false
primary: false
def:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
Principal_HistoricoNotas_Item:
tableName: principal.historico_notas
columns:
id_estudiante:
type: integer(8)
fixed: false
unsigned: false
primary: true
id_seccion:
type: integer(8)
fixed: false
unsigned: false
primary: true
ligaseccion:
type: string(50)
fixed: false
unsigned: false
primary: true
n01:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
n02:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
n03:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
n04:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
n05:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
n06:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
n07:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
n08:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
n09:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
n10:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
n11:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
n12:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
n13:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
n14:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
n15:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
adicional:
type: integer(4)
fixed: false
unsigned: false
notnull: false
primary: false
def:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
relations:
foreign: id
type: one
local: id_seccion
foreign: id
type: one
Principal_HistoricoSeccionesErrores_Item:
tableName: principal.historico_secciones_errores
columns:
id:
type: integer(8)
fixed: false
unsigned: false
primary: true
sequence: principal.historico_secciones_errores_id
id_periodo:
type: integer(8)
fixed: false
unsigned: false
notnull: true
primary: false
ligaseccion:
type: string(50)
fixed: false
unsigned: false
notnull: true
primary: false
abrev_proy:
type: string(10)
fixed: false
unsigned: false
notnull: true
primary: false
abrev_sede:
type: string(10)
fixed: false
unsigned: false
notnull: true
primary: false
id_materia:
type: integer(8)
fixed: false
unsigned: false
notnull: true
primary: false
seccion:
type: string(15)
fixed: false
unsigned: false
notnull: true
primary: false
id_profesor:
type: integer(8)
fixed: false
unsigned: false
notnull: true
primary: false
max_cupo:
type: integer(4)
fixed: false
unsigned: false
notnull: false
primary: false
p01:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
p02:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
p03:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
p04:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
p05:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
p06:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
p07:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
p08:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
p09:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
p10:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
p11:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
p12:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
p13:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
p14:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
p15:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
verificada:
type: boolean(1)
fixed: false
unsigned: false
notnull: true
primary: false
num_reg:
type: integer(4)
fixed: false
unsigned: false
notnull: false
primary: false
tableName: principal.historico_secciones
columns:
id:
type: integer(8)
fixed: false
unsigned: false
primary: true
sequence: principal.historico_secciones_id
id_periodo:
type: integer(8)
fixed: false
unsigned: false
notnull: true
primary: false
ligaseccion:
type: string(50)
fixed: false
unsigned: false
notnull: true
primary: false
abrev_proy:
type: string(10)
fixed: false
unsigned: false
notnull: true
primary: false
abrev_sede:
type: string(10)
fixed: false
unsigned: false
notnull: true
primary: false
id_materia:
type: integer(8)
fixed: false
unsigned: false
notnull: true
primary: false
seccion:
type: string(15)
fixed: false
unsigned: false
notnull: true
primary: false
id_profesor:
type: integer(8)
fixed: false
unsigned: false
notnull: true
primary: false
max_cupo:
type: integer(4)
fixed: false
unsigned: false
notnull: false
primary: false
p01:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
p02:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
p03:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
p04:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
p05:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
p06:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
p07:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
p08:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
p09:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
p10:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
p11:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
p12:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
p13:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
p14:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
p15:
type: float()
fixed: false
unsigned: false
notnull: false
primary: false
verificada:
type: boolean(1)
fixed: false
unsigned: false
notnull: true
primary: false
num_reg:
type: integer(4)
fixed: false
unsigned: false
notnull: false
primary: false
relations:
local: id_periodo
foreign: id
type: one
Principal_HistoricoHorarios_Items:
class: Principal_HistoricoHorarios_Item
local: id
foreign: id_seccion
type: many
Principal_HistoricoNotas_Items:
class: Principal_HistoricoNotas_Item
local: id
foreign: id_seccion
type: many
Principal_MaeEstudiantesOriginal_Item:
tableName: principal.mae_estudiantes_original
columns:
id:
type: integer(8)
fixed: false
unsigned: false
primary: true
sequence: principal.mae_estudiantes_original_id
cedula:
type: integer(8)
fixed: false
unsigned: false
notnull: true
primary: false
pasaporte:
type: string(15)
fixed: false
unsigned: false
notnull: false
primary: false
apellidos:
type: string(50)
fixed: false
unsigned: false
notnull: false
primary: false
nombres:
type: string(50)
fixed: false
unsigned: false
notnull: false
primary: false
nacionalidad:
type: string(1)
fixed: false
unsigned: false
notnull: false
primary: false
fec_nac:
type: date(25)
fixed: false
unsigned: false
notnull: false
primary: false
sexo:
type: string(1)
fixed: false
unsigned: false
notnull: false
primary: false
tableName: principal.mae_estudiantes
columns:
id:
type: integer(8)
fixed: false
unsigned: false
primary: true
sequence: principal.mae_estudiantes_id
cedula:
type: integer(8)
fixed: false
unsigned: false
notnull: true
primary: false
pasaporte:
type: string(15)
fixed: false
unsigned: false
notnull: false
primary: false
apellidos:
type: string(50)
fixed: false
unsigned: false
notnull: false
primary: false
nombres:
type: string(50)
fixed: false
unsigned: false
notnull: false
primary: false
nacionalidad:
type: string(1)
fixed: false
unsigned: false
notnull: false
primary: false
sexo:
type: string(1)
fixed: false
unsigned: false
notnull: false
primary: false
fec_nac:
type: date(25)
fixed: false
unsigned: false
notnull: false
primary: false
relations:
Principal_MaeEstudiantesubicacion_Items:
class: Principal_MaeEstudiantesubicacion_Item
local: id
foreign: id_estudiante
type: many
Principal_HistoricoNotas_Items:
class: Principal_HistoricoNotas_Item
local: id
type: many
Principal_ProyectosRegistro_Items:
class: Principal_ProyectosRegistro_Item
local: id
type: many
Principal_HistoricoEstudiantesregistro_Items:
class: Principal_HistoricoEstudiantesregistro_Item
local: id
type: many
Principal_MaeEstudiantesubicacion_Item:
tableName: principal.mae_estudiantesubicacion
columns:
id_estudiante:
type: integer(8)
fixed: false
unsigned: false
primary: true
abrev_proy:
type: string(10)
fixed: false
unsigned: false
notnull: true
primary: false
abrev_sede:
type: string(10)
fixed: false
unsigned: false
notnull: true
primary: false
per_ing:
type: integer(8)
fixed: false
unsigned: false
notnull: true
primary: false
relations:
foreign: id
type: one
local: per_ing
foreign: id
type: one
Principal_MaeProfesores_Item:
tableName: principal.mae_profesores
columns:
id:
type: integer(8)
fixed: false
unsigned: false
primary: true
sequence: principal.mae_profesores_id
cedula:
type: integer(8)
fixed: false
unsigned: false
notnull: true
primary: false
pasaporte:
type: string(15)
fixed: false
unsigned: false
notnull: false
primary: false
apellidos:
type: string(50)
fixed: false
unsigned: false
notnull: false
primary: false
nombres:
type: string(50)
fixed: false
unsigned: false
notnull: false
primary: false
nacionalidad:
type: string(1)
fixed: false
unsigned: false
notnull: false
primary: false
sexo:
type: string(1)
fixed: false
unsigned: false
notnull: false
primary: false
fec_nac:
type: date(25)
fixed: false
unsigned: false
notnull: false
primary: false
relations:
local: id
foreign: id_expediente
type: many
Principal_MaeTutoresexternos_Item:
tableName: principal.mae_tutoresexternos
columns:
id:
type: integer(8)
fixed: false
unsigned: false
primary: true
sequence: principal.mae_tutoresexternos_id
identificacion:
type: string(50)
fixed: false
unsigned: false
notnull: true
primary: false
apellidos:
type: string(50)
fixed: false
unsigned: false
notnull: true
primary: false
nombres:
type: string(50)
fixed: false
unsigned: false
notnull: true
primary: false
nacionalidad:
type: string(1)
fixed: false
unsigned: false
notnull: false
primary: false
fec_nac:
type: date(25)
fixed: false
unsigned: false
notnull: false
primary: false
sexo:
type: integer(4)
fixed: false
unsigned: false
notnull: false
primary: false
archivo_curriculo:
type: string(255)
fixed: false
unsigned: false
notnull: false
primary: false
es_pasaporte:
type: boolean(1)
fixed: false
unsigned: false
notnull: false
primary: false
relations:
local: id
foreign: id_tutor_externo
type: many
Principal_ProyectosEvaluacion_Item:
tableName: principal.proyectos_evaluacion
columns:
id_evaluacion:
type: integer(8)
fixed: false
unsigned: false
primary: true
sequence: principal.proyectos_evaluacion_id_evaluacion
evaluacion_general:
type: string(255)
fixed: false
unsigned: false
notnull: false
primary: false
cumplimiento:
type: boolean(1)
fixed: false
unsigned: false
notnull: false
primary: false
relations:
Principal_ProyectosResultadoevaluacion_Items:
class: Principal_ProyectosResultadoevaluacion_Item
local: id_evaluacion
foreign: id_evaluacion
type: many
type: many
Principal_ProyectosGuiaEvaluacion_Item:
tableName: principal.proyectos_guia_evaluacion
columns:
id_version:
type: integer(8)
fixed: false
unsigned: false
primary: true
id_grupo:
type: integer(4)
fixed: false
unsigned: false
primary: true
id_item:
type: integer(4)
fixed: false
unsigned: false
primary: true
nro_item:
type: integer(4)
fixed: false
unsigned: false
notnull: true
default: '0'
primary: false
descripcion:
type: string(255)
fixed: false
unsigned: false
notnull: true
primary: false
Principal_ProyectosObjetivos_Item:
tableName: principal.proyectos_objetivos
columns:
id_expediente:
type: integer(8)
fixed: false
unsigned: false
primary: true
sequence: principal.proyectos_objetivos_id_expediente
id_objetivo:
type: integer(8)
fixed: false
unsigned: false
primary: true
objetivo:
type: string(255)
fixed: false
unsigned: false
notnull: true
primary: false
objetivo_modificado:
type: string(255)
fixed: false
unsigned: false
notnull: false
primary: false
obs_validacion:
type: integer(8)
fixed: false
unsigned: false
notnull: false
primary: false
f_ultimo_acceso:
type: timestamp(25)
fixed: false
unsigned: false
notnull: false
primary: false
f_modificacion:
type: timestamp(25)
fixed: false
unsigned: false
notnull: false
primary: false
relations:
Principal_ProyectosRegistro_Item:
local: id_expediente
type: one
Principal_ProyectosRegistro_Item:
tableName: principal.proyectos_registro
columns:
id_expediente:
type: integer(8)
fixed: false
unsigned: false
primary: true
sequence: principal.proyectos_registro_id_expediente
id_estudiante:
type: integer(8)
fixed: false
unsigned: false
notnull: true
primary: false
id_validacion:
type: integer(8)
fixed: false
unsigned: false
notnull: false
primary: false
id_evaluacion:
type: integer(8)
fixed: false
unsigned: false
notnull: false
primary: false
id_tutor_interno:
type: integer(8)
fixed: false
unsigned: false
notnull: false
default: '1'
primary: false
id_tutor_externo:
type: integer(8)
fixed: false
unsigned: false
notnull: false
default: '1'
primary: false
f_creacion:
type: timestamp(25)
fixed: false
unsigned: false
notnull: false
primary: false
f_ultimo_acceso:
type: timestamp(25)
fixed: false
unsigned: false
notnull: false
primary: false
f_modificacion:
type: timestamp(25)
fixed: false
unsigned: false
notnull: false
primary: false
sede_unidad_atencion:
type: string(10)
fixed: false
unsigned: false
notnull: false
primary: false
obs:
type: string(255)
fixed: false
unsigned: false
notnull: false
primary: false
titulo_proyecto:
type: string(255)
fixed: false
unsigned: false
notnull: true
primary: false
archivo_proyecto:
type: string(255)
fixed: false
unsigned: false
notnull: true
primary: false
relations:
foreign: id
type: one
Principal_ProyectosEvaluacion_Item:
type: one
Principal_ProyectosValidacion_Item:
local: id_validacion
foreign: id_validacion
type: one
Principal_MaeTutoresexternos_Item:
local: id_tutor_externo
foreign: id
type: one
Principal_MaeProfesores_Item:
foreign: id
type: one
Principal_ValoresSedes_Item:
local: sede_unidad_atencion
foreign: abrev
type: one
Principal_ProyectosObjetivos_Items:
class: Principal_ProyectosObjetivos_Item
type: many
Principal_ProyectosResultadoevaluacion_Item:
tableName: principal.proyectos_resultadoevaluacion
columns:
id_evaluacion:
type: integer(8)
fixed: false
unsigned: false
primary: true
id_version:
type: integer(8)
fixed: false
unsigned: false
primary: true
id_grupo:
type: integer(4)
fixed: false
unsigned: false
primary: true
id_item:
type: integer(4)
fixed: false
unsigned: false
primary: true
resultado:
type: integer(4)
fixed: false
unsigned: false
notnull: false
primary: false
observacion_item:
type: string(255)
fixed: false
unsigned: false
notnull: false
primary: false
relations:
Principal_ProyectosEvaluacion_Item_ForIdEvaluacion:
class: Principal_ProyectosEvaluacion_Item
type: one
Principal_ProyectosValidacion_Item:
tableName: principal.proyectos_validacion
columns:
id_validacion:
type: integer(8)
fixed: false
unsigned: false
primary: true
sequence: principal.proyectos_validacion_id_validacion
f_creacion:
type: timestamp(25)
fixed: false
unsigned: false
notnull: false
primary: false
f_ultimo_acceso:
type: timestamp(25)
fixed: false
unsigned: false
notnull: false
primary: false
relations:
local: id_validacion
foreign: id_validacion
type: many
Principal_ValoresAulas_Item:
tableName: principal.valores_aulas
columns:
id:
type: integer(8)
fixed: false
unsigned: false
primary: true
sequence: principal.valores_aulas_id
abrev_sede:
type: string(10)
fixed: false
unsigned: false
primary: true
nom_aula:
type: string(15)
fixed: false
unsigned: false
primary: true
relations:
local: abrev_sede
foreign: abrev
type: one
Principal_HistoricoHorarios_Items:
class: Principal_HistoricoHorarios_Item
local: id
foreign: id_aula
type: many
Principal_ValoresEntorno_Item:
tableName: principal.valores_entorno
columns:
cod_prog:
type: string(2)
fixed: false
unsigned: false
notnull: true
primary: false
cod_proy:
type: string(2)
fixed: false
unsigned: false
notnull: true
primary: false
cod_sede:
type: string(2)
fixed: false
unsigned: false
notnull: true
primary: false
abrev_proy:
type: string(10)
fixed: false
unsigned: false
primary: true
abrev_sede:
type: string(10)
fixed: false
unsigned: false
primary: true
autoridad:
type: string(50)
fixed: false
unsigned: false
notnull: false
primary: false
ced_autoridad:
type: integer(8)
fixed: false
unsigned: false
notnull: false
primary: false
titulo_autoridad:
type: string(25)
fixed: false
unsigned: false
notnull: false
primary: false
relations:
Principal_ValoresProgramasproyectos_Item:
local: abrev_proy
foreign: abrev
type: one
local: abrev_sede
foreign: abrev
type: one
Principal_ValoresObservaciones_Item:
tableName: principal.valores_observaciones
columns:
id_observacion:
type: integer(8)
fixed: false
unsigned: false
primary: true
sequence: principal.valores_observaciones_id_observacion
descripcion:
type: string(255)
fixed: false
unsigned: false
notnull: true
primary: false
nivel:
type: string(2)
fixed: false
unsigned: false
notnull: false
primary: false
Principal_ValoresPensums_Item:
tableName: principal.valores_pensums
columns:
abrev_proy:
type: string(10)
fixed: false
unsigned: false
primary: true
pensum:
type: string(10)
fixed: false
unsigned: false
primary: true
relations:
local: abrev_proy
foreign: abrev
type: one
tableName: principal.valores_periodos
columns:
id:
type: integer(8)
fixed: false
unsigned: false
primary: true
sequence: principal.valores_periodos_id
nom_periodo:
type: string(8)
fixed: false
unsigned: false
notnull: true
primary: false
fec_inicio:
type: date(25)
fixed: false
unsigned: false
notnull: false
primary: false
fec_finalizacion:
type: date(25)
fixed: false
unsigned: false
notnull: false
primary: false
relations:
Principal_MaeEstudiantesubicacion_Items:
class: Principal_MaeEstudiantesubicacion_Item
local: id
foreign: per_ing
type: many
Principal_HistoricoSecciones_Items:
class: Principal_HistoricoSecciones_Item
local: id
foreign: id_periodo
type: many
Principal_HistoricoEstudiantesregistro_Items:
class: Principal_HistoricoEstudiantesregistro_Item
local: id
foreign: id_periodo
type: many
tableName: principal.valores_programasproyectos
columns:
cod_prog:
type: string(2)
fixed: false
unsigned: false
notnull: true
primary: false
cod_proy:
type: string(2)
fixed: false
unsigned: false
notnull: true
primary: false
denominacion:
type: string(100)
fixed: false
unsigned: false
notnull: true
primary: false
abrev:
type: string(10)
fixed: false
unsigned: false
primary: true
autoridad:
type: string(50)
fixed: false
unsigned: false
notnull: false
primary: false
ced_autoridad:
type: integer(8)
fixed: false
unsigned: false
notnull: false
primary: false
titulo_autoridad:
type: string(25)
fixed: false
unsigned: false
notnull: false
primary: false
esquema:
type: string(100)
fixed: false
unsigned: false
notnull: false
primary: false
relations:
Principal_ValoresEntorno_Items:
class: Principal_ValoresEntorno_Item
local: abrev
foreign: abrev_proy
type: many
Principal_ValoresPensums_Items:
class: Principal_ValoresPensums_Item
local: abrev
foreign: abrev_proy
type: many
tableName: principal.valores_sedes
columns:
cod_sede:
type: string(2)
fixed: false
unsigned: false
notnull: true
primary: false
denominacion:
type: string(50)
fixed: false
unsigned: false
notnull: true
primary: false
abrev:
type: string(10)
fixed: false
unsigned: false
primary: true
relations:
Principal_ValoresEntorno_Items:
class: Principal_ValoresEntorno_Item
local: abrev
foreign: abrev_sede
type: many
local: abrev
foreign: sede_unidad_atencion
type: many
Principal_ValoresAulas_Items:
class: Principal_ValoresAulas_Item
local: abrev
foreign: abrev_sede
type: many

Sistema de información web para procesos de investigación

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sistema de información web para procesos de investigación

Uploaded by

Copyright:

Available Formats

REPBLICA BOLIVARIANA DE VENEZUELA

UNIVERSIDAD RAFAEL BELLOSO CHACN

SISTEMA DE INFORMACIN BAJO AMBIENTE WEB PARA LOS

MARACAIBO, JULIO DE 2011

SISTEMA DE INFORMACIN BAJO AMBIENTE WEB PARA LOS

Por darme la fuerza y voluntad que

Jos y Berta, por acompaarme a lo

Marco Antonio, Enmanuel y Freddy

Creador del Cielo y la Tierra.

Freddy y Norma, sin ustedes no

Marco Antonio, Enmanuel y Freddy,

Por ser fuente de luz y sabidura.

Zadid y Adelfa, por todo el apoyo

Mi Julieta, sin tu impulso no hubiese

Mara Jos, mi muchacha, mi nia

Garca, Yeimaira; Molina, Freddy; Pirela, Jorge (Autores); Dra. Ordez,

Garca, Yeimaira; Molina, Freddy; Pirela, Jorge (Authors), Dr. Ordoez,

MARCO TERICO .......................................................................... 14

2.1.5.4. MODELO DE DESARROLLO INCREMENTAL ....... 32

2.2.9.3. DESIGN-DRIVEN REQUIREMENTS

MARCO METODOLOGICO ........................................................... 124

TIPO DE INVESTIGACIN ................................................................ 125

RESULTADOS DE LA INVESTIGACIN ...................................... 136

1.1.4. REGLAS DE NEGOCIO ..................................................... 146

3. CONCLUSIONES ............................................................................... 212

REFERENCIAS BIBLIOGRAFICAS .......................................................... 215

MANUAL DE IDENTIDAD VISUAL PARA LOS PORTALES

MANUAL DE USUARIO ................................................................. 227

DICCIONARIO DE DATOS ............................................................ 234

LOS PLUGINS PARA EL CONTROL DE ACCESO Y

ESQUEMA DE LA BASE DE DATOS (SCHEMA.YML) ................. 268

ESTRUCTURA DEL DIRECTORIO RAZ DE LOS

ESTRUCTURA DEL SUBDIRECTORIO DE LAS

ESTRUCTURA DEL SUBDIRECTORIO DE LOS MDULOS

ESTRUCTURA DEL DIRECTORIO WEB EN SYMFONY ............. 53

LIMITACIONES DE POSTGRESQL .............................................. 65

CUADRO DE ACTIVIDADES ....................................................... 134

REGLAS DE NEGOCIO DE LA UNIDAD DE ATENCIN A LA

ACTORES DEL PROYECTO ....................................................... 149

LISTA PRELIMINAR DE REQUISITOS FUNCIONALES ............. 155

LISTA PRELIMINAR DE REQUISITOS FUNCIONALES

DEFINICIN DE ACTORES ........................................................ 167

COMPONENTES GENRICOS DE UNA ARQUITECTURA

MODELO CLSICO O CASCADA .................................................. 27

EJEMPLO DEL MODELO DE ANLISIS ESTRUCTURADO ......... 30

MODELO DE DESARROLLO EN ESPIRAL ................................... 31

MODELO DE DESARROLLO INCREMENTAL............................... 33

MODELO DE PROTOTIPADO RPIDO ......................................... 34

MODELO DE PROTOTIPADO EVOLUTIVO .................................. 36

EL PATRN DE DISEO MODELO VISTA CONTROLADOR ...... 39

CICLO DE VIDA DEL MVC ............................................................. 41

IMPLEMENTACIN DE MVC EN SYMFONY ................................ 48

OBJECT RELATION MAPER ......................................................... 54

UNA EXCEPCIN EN EL ENTORNO DE DESARROLLO ............. 59

UNA EXCEPCIN EN EL ENTORNO DE PRODUCCIN ............. 59

APLICACIN SYMFONY EN ENTORNO DE DESARROLLO........ 60

COMPONENTES DEL POSTGRESQL .......................................... 61

CATEGORAS DE LAS APLICACIONES WEB .............................. 77

DIMENSIONES PARA LA CATEGORIZACIN DE LAS

PROCESO DE INGENIERA DE REQUISITOS.............................. 86

DESCRIPCIN GENERAL DE LAS ACTIVIDADES DE NDT ...... 101

ESTRUCTURA DEL DOCUMENTO DE REQUISITOS DEL