UNIVERSIDAD RAFAEL URDANETA

REPÚBLICA BOLIVARIANA DE VENEZUELA
UNIVERSIDAD RAFAEL URDANETA
FACULTAD DE INGENIERÍA
ESCUELA DE INGENIERÍA DE COMPUTACIÓN
DESARROLLO DE UNA EXTRANET PARA LA AUTOMATIZACIÓN DE LOS
PROCESOS DE GESTIÓN DE LOS CONSULTORES DE LA EMPRESA
CONSULTING & INFORMATION FOR BUSINESS S.A.
S
O
D
VA
R
E
S
E
R
S
HO
EC
R
E
D
TRABAJO ESPECIAL DE GRADO
Para Optar al Título de
Ingeniero de Computación
REALIZADO POR EL BACHILLER:
Ramos O. Daniel V.
C.I: 16.846.108
TUTOR ACADÉMICO:
Lcda. Rosa Zamora. Msc.
C.I: 13.737.474
MARACAIBO, ABRIL DE 2008
UNIVERSIDAD RAFAEL URDANETA
DESARROLLO DE UNA EXTRANET PARA LA AUTOMATIZACIÓN DE LOS
PROCESOS DE GESTIÓN DE LOS CONSULTORES DE LA EMPRESA
CONSULTING & INFORMATION FOR BUSINESS S.A.
S
O
D
VA
R
E
S
E
R
S
HO
EC
R
E
D
Ramos Daniel
CI:16846108
San Francisco, Sector
El Manzanillo Calle 22
con Av. 25 No. Casa 25ª-44
Teléfono:0416-2268251
[email protected]
_______________________
Lcda. Rosa Esperanza Zamora
ii
UNIVERSIDAD RAFAEL URDANETA
VEREDICTO
Este jurado aprueba el Trabajo Especial de Grado titulado “DESARROLLO DE UNA
EXTRANET PARA LA AUTOMATIZACION DE LOS PROCESOS DE GESTION DE
LOS CONSULTORES DE LA EMPRESA CONSULTING & INFORMATION FOR
BUSINNESS S.A. ”, que el bachiller RAMOS ORTEGA DANIEL VALENTIN C.I. V16.846.108 presenta para optar al título de INGENIERO DE COMPUTACION.
Maracaibo, Mayo de 2008.
S
O
D
VA
Jurado Examinador
R
E
S
E
R
OS
CH
E
R
DE ______________________________
Lcda. Rosa Zamora.
Tutor- Jurado
C.I. V - 13.737.474
______________________________
______________________________
______________________________
Ing. Carlos Urdaneta
Director de la Escuela de Computación
C.I. V - 8.985.945
______________________________
Ing. José Bohórquez
Decano de la Facultad de Ingeniería
C.I. V- 3.379.454
iii
UNIVERSIDAD RAFAEL URDANETA
Ramos Ortega Daniel Valentin. “Desarrollo de una Extranet para la Automatización de
los Procesos de Gestión de los Consultores de la Empresa Consulting & Information for
Business S.A.”. Trabajo Especial de Grado para optar al titulo de Ingeniero de
Computación. Universidad Rafael Urdaneta, Facultad de Ingeniería, Escuela de
Computación. Maracaibo, Venezuela 2005. 144 p.
RESUMEN
La presente investigación desarrolló una extranet para la automatización de los
procesos de gestión de los consultores de la empresa Consulting & Infomatión for
Business S.A., el estudio fue descriptivo, con un diseño no-experimental transaccional
descriptivo. Se utilizaron para el desarrollo de la investigación una adaptación de la
metodología Watch Extendida desarrollada por Montilva y Barrios (2002) para el
desarrollo con PHP, más específicamente se instanciaron los modelos del producto,
equipo y procesos; en el modelo del proceso se llevaron a cabo los procesos
gerenciales de gestión del proyecto, gestión de calidad del software, gestión de
configuración del software, verificación y validación del sistema, y gestión de riesgo; por
otra parte, los procesos de desarrollo que se llevaron a cabo ó se adaptaron fueron la
definición de requerimientos, el diseño arquitectónico, la elaboración e integración del
código y las pruebas de la aplicación. Las fases mencionadas anteriormente dieron la
guía a seguir para la solución del problema. La información fue recopilada de textos
que sustentaron las teorías referentes a las extranets y a la programación Web. Con el
cumplimiento de los aspectos antes mencionados se logró desarrollar la extranet para
la automatización de los procesos de gestión de los consultores de la empresa Cibiz
S.A.; por último se recomienda que Consulting & Información for Business implante la
extranet desarrollada para solucionar sus problemas de una manera eficiente, eficaz y
efectiva.
S
O
D
VA
R
E
S
E
R
S
HO
EC
R
E
D
Palabras Clave: extranet, automatización de procesos de gestión, programación Web,
PHP.
Correo del Autor: [email protected]
xii
UNIVERSIDAD RAFAEL URDANETA
Ramos Ortega, Daniel Valentín. “Development of an Extranet for the Automation of
Consultants’ Managerial Processes of the company Consulting & Information for
Business S.A.”. Degree Special Work. Universidad Rafael Urdaneta, Engineer Faculty,
Computing School, Maracaibo, Venezuela 2007. 144 p.
ABSTRACT
The present investigation developed an extranet for the automation of consultants’
managerial processes of the company Consulting & Infomation for Business S.A., this
was a descriptive study, with a non-experimental descriptive transactional design.
For the development of the investigation was used an adaptation of the Extended
Watch methodology developed by Montilva and Barrios (2002) for the development with
PHP, more specifically were instanced the product model, equipment and processes; in
the process model were represented the management process of the project, software
quality management, software configuration management, system verification and
validation, and the risk management; in other side, the developments or adaptations
were the requirements definitions, the architectural design, the programming code, and
the application tests. These activities were the guide to be followed for the theories
about extranets and web programming. With the compliance of all the mentioned
aspects was completed the development of the extranet for the automation of
consultants’ managerial processes of the company Consulting & Infomation for
Business S.A.; finally is recommended that Consulting & Infomation for Business S.A.
deploy the extranet in order to solve the operative issues in a efficient and effective
manner.
S
O
D
VA
R
E
S
E
R
S
HO
EC
R
E
D
Keywords: extranet, process automation, Web programming, PHP.
Author’s eMail: [email protected]
xiii
UNIVERSIDAD RAFAEL URDANETA
INDICE GENERAL
Pág.
VEREDICTO
iii
ÍNDICE GENERAL
iv
S
O
D
VA
R
E
S
ÍNDICE DE FIGURAS
ÍNDICE DE TABLAS
RESUMEN
ABSTRACT
E
R
S
HO
EC
R
E
D
vii
xi
xii
xiii
CAPÍTULO I
EL PROBLEMA
1. PLANTEAMIENTO DEL PROBLEMA
15
2. FORMULACIÓN DEL PROBLEMA
19
3. OBJETIVOS DE LA INVESTIGACIÓN
19
3.1. OBJETIVO GENERAL
19
3.2. OBJETIVOS ESPECIFÍCOS
19
4. JUSTIFICACIÓN E IMPORTANCIA DE LA INVESTIGACIÓN
20
5. DELIMITACIÓN ESPACIAL Y TEMPORAL
21
iv
UNIVERSIDAD RAFAEL URDANETA
CAPÍTULO II
MARCO TEÓRICO
1. ANTECEDENTES DE LA INVESTIGACIÓN
23
2. BASES TEÓRICAS
25
3. METODOLOGÍA
47
4. DEFINICIÓN DE TÉRMINOS BÀSICOS
53
S
O
D
VA
R
E
S
5. SISTEMA DE VARIABLES E INDICADORES
E
R
S
HO
EC
R
E
D
CAPITULO III
57
MARCO METODOLÓGICO
1. TIPO DE INVESTIGACIÓN
60
2. DISEÑO DE LA INVESTIGACIÓN
61
3. POBLACIÓN Y MUESTRA
61
4. METODOLOGÍA UTILIZADA PARA EL DESARROLLO DE LA EXTRANET
62
5. TÉCNICAS PARA LA RECOLECCIÓN DE DATOS
65
CAPÍTULO IV
ANÁLISIS E INTERPRETACIÓN DE LOS RESULTADOS
1. MODELO DEL PRODUCTO
67
1.1. CAPA DE PRESENTACIÓN
68
v
UNIVERSIDAD RAFAEL URDANETA
1.2. CAPA DE LÓGICA DE NEGOCIOS
69
1.3. CAPA DE DATOS
69
2. MODELO DEL EQUIPO
69
3. MODELO DEL PROCESO
70
3.1. PROCESOS DE GESTIÓN
71
3.1.1. GESTIÓN DE CALIDAD DEL SOFTWARE
71
3.1.2. GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARE
71
3.1.3. PLAN DE VERIFICACIÓN Y VALIDACIÓN DEL SOFTWARE
74
S
O
D
VA
R
E
S
E
R
S
HO
3.1.4. GESTIÓN DE RIESGOS
EC
R
E
D
75
3.2. PROCESOS DE DESARROLLO
78
3.2.1. DEFINICIÓN Y ESPECIFICACIÓN DE REQUERIMIENTOS
78
3.2.2. DISEÑO DE LA APLICACIÓN
120
3.2.3. IMPLEMENTACIÓN DE CÓDIGO
135
3.2.4. INTEGRACIÓN DE CÓDIGO
140
3.2.5. PRUEBA DE LA APLICACIÓN WEB
141
CONCLUSIONES
142
RECOMENDACIÓNES
144
vi
UNIVERSIDAD RAFAEL URDANETA
INDICE DE TABLAS
TABLAS
Pág.
1. ESTRUCTURA DEL MODELO DEL PROCESO DE LA WATCH EXTENDIDA.
51
2. DECLARACIÓN DE LOS RIESGOS IDENTIFICADOS.
75
3. VALORES DE LAS VARIABLES ASOCIADAS A LOS RIESGOS.
76
S
O
D
VA
R
E
S
E
R
S
HO
4. PLANES DE MITIGACIÓN Y CONTINGENCIA DE LOS RIESGOS.
76
5. ESCALAS CUALITATIVA Y CUANTITATIVA USADAS PARA ESTIMAR LA
PROBABILIDAD DE LOS RIESGOS.
77
6. ESCALAS CUALITATIVA Y CUANTITATIVA USADAS PARA ESTIMAR EL
IMPACTO DE LOS RIESGOS.
77
7. SIGNIFICADO DE LAS ABREVIATURAS USADAS PARA CLASIFICAR LOS
RIESGOS.
78
EC
R
E
D
xi
UNIVERSIDAD RAFAEL URDANETA
INDICE DE FIGURAS
FIGURA
1. ARQUITECTURA CLIENTE/SERVIDOR WEB CON BASE DE DATOS
Pág.
44
2. ESTRUCTURA GENERAL DEL MODELO DEL PRODUCTO DE LA WATCH
EXTENDIDA.
49
S
O
VAD
3. EL MODELO DEL PROCESO DE LA WATCH E
EXTENDIDA.
52
R
S
E
REXTRANET PARA LA AUTOMATIZACIÓN DE
S
4. EL MODELO DE PRODUCTO
DE
LA
O
CH DE LOS CONSULTORES DE LA EMPRESA CIBIZ
LOS PROCESOS DE
GESTIÓN
E
R
DE
S.A.
68
5. EL MODELO DE EQUIPO DE LA EXTRANET PARA LA AUTOMATIZACIÓN DE
LOS PROCESOS DE GESTIÓN DE LOS CONSULTORES DE LA EMPRESA CIBIZ
S.A.
70
6. DIAGRAMA DE CASO DE USO GENERAL DE LA EXTRANET.
116
7. DIAGRAMA DE CASO DE USO DE ACCESO A LA EXTRANET.
116
8. DIAGRAMA DE CASO DE USO DE INGRESO A UN MÓDULO DE LA EXTRANET.
116
9. DIAGRAMA DE CASO DE USO DE LOS MÓDULOS DE GESTIÓN DE DATOS DE
LOS CONSULTORES.
117
10. DIAGRAMA DE CASO DE USO DE LOS MÓDULOS DE GESTIÓN DE CUANTAS
DE USUARIO DE LA EXTRANET.
117
11. DIAGRAMA DE CASO DE USO DE LOS MÓDULOS DE GESTIÓN DE DATOS DE
LAS EMPRESAS CLIENTES.
118
12. DIAGRAMA DE CASO DE USO DE LOS MÓDULOS DE GESTIÓN DE DATOS DE
LOS TIPOS DE ACTIVIDAD.
118
vii
UNIVERSIDAD RAFAEL URDANETA
13. DIAGRAMA DE CASO DE USO DE LOS MÓDULOS DE GESTIÓN DE
PROYECTOS.
119
14. DIAGRAMA DE CASO DE USO DE LOS MÓDULOS RELACIONADOS AL
REGISTRO DE ACTIVIDADES.
119
15. ESTRUCTURA DE DIRECTORIOS DE LA EXTRANET PARA LA
AUTOMATIZACIÓN DE LOS PROCESOS DE GESTIÓN DE LOS CONSULTORES DE
LA EMPRESA CIBIZ S.A.
121
16. MENÚ PARA USUARIOS ESTÁNDAR DE LA EXTRANET.
124
DOS
124
19. FORMULARIO PARA LA AUTENTICACIÓN DE LOS USUARIOS.
125
17. MENÚ PARA SUPERUSUARIOS DE LA EXTRANET.
VA
R
E
ES
18. FOOTER DE LAS PÁGINAS DE LA EXTRANET.
R
S
O
CH
E
DER
124
20. FORMULARIO PARA LA AUTENTICACIÓN DE LOS USUARIOS MOSTRANDO EL
ÚNICO MENSAJE DE ERROR.
125
21. CABECERA DE LAS PÁGINAS DEL MÓDULO DE ACTUALIZACIÓN DE DATOS
DE CONSULTORES.
126
22. FORMULARIO PARA EL INGRESO DE LOS PARÁMETROS DE SELECCIÓN DEL
CONSULTOR AL QUE SE LE ACTUALIZARÁN LOS DATOS DEL MÓDULO PARA LA
ACTUALIZACIÓN DE DATOS DE CONSULTORES.
126
23. MENSAJES DE ERROR DEL FORMULARIO PARA EL INGRESO DE LOS
PARÁMETROS DE SELECCIÓN DEL CONSULTOR AL QUE SE LE ACTUALIZARÁN
LOS DATOS DEL MÓDULO PARA LA ACTUALIZACIÓN DE DATOS DE
CONSULTORES.
127
24. TABLA PARA LA SELECCIÓN DEL CONSULTOR AL QUE SE LE ACTUALIZARÁN
LOS DATOS DEL MÓDULO PARA LA ACTUALIZACIÓN DE DATOS DE
CONSULTORES.
127
25. MENSAJES DE ERROR DEL FORMULARIO PARA LA ACTUALIZACIÓN DE LOS
DATOS DE UN CONSULTOR DEL MÓDULO PARA LA ACTUALIZACIÓN DE DATOS
DE CONSULTORES.
128
26. MENSAJE DE CONFIRMACIÓN DE ACTUALIZACIÓN DE DATOS DEL MÓDULO
PARA LA ACTUALIZACIÓN DE LOS DATOS DE UN CONSULTOR.
129
viii
UNIVERSIDAD RAFAEL URDANETA
27. COLUMNAS QUE CONFORMAN LA TABLA CONSULTOR. LA TABLA GUARDA
LO DATOS DE LOS CONSULTORES, INCLUYENDO LOS DATOS DE LA CUENTA
DE ACCESO A LA EXTRANET. EN LA FIGURA SE PUEDE APRECIAR EL TIPO DE
CADA COLUMNA ASÍ COMO LA CLAVE PRIMARIA DE LA TABLA.
131
28. COLUMNAS QUE CONFORMAN LA TABLA CONSULTOR_PROYECTO. LA
TABLA INDICA QUE CONSULTORES FUERON O ESTÁN ASIGNADOS A CUALES
PROYECTOS. EN LA FIGURA SE PUEDE APRECIAR EL TIPO DE CADA COLUMNA
ASÍ COMO LA CLAVE PRIMARIA DE LA TABLA.
131
29. COLUMNAS QUE CONFORMAN LA TABLA DIVISA. LA TABLA INDICA EN QUE
DIVISAS PUEDEN ESTAR EXPRESADOS LOS DISTINTOS NIVELES SALARIALES.
EN LA FIGURA SE PUEDE APRECIAR EL TIPO DE CADA COLUMNA ASÍ COMO LA
CLAVE PRIMARIA DE LA TABLA.
132
S
O
D
VA
R
E
S EMPRESA. LA TABLA GUARDA LOS
30. COLUMNAS QUE CONFORMAN LA TABLA
E
R
DATOS DE LAS EMPRESAS CLIENTES
S.A. EN LA FIGURA SE PUEDE
OS DEASÍCIBIZ
H
C
APRECIAR EL TIPO DE
CADA
COLUMNA
COMO
LA CLAVE PRIMARIA DE LA
E
R
E
TABLA.
132
D
31. COLUMNAS QUE CONFORMAN LA TABLA ESTATUS_LABORAL. LA TABLA
GUARDA LOS POSIBLES ESTATUS LABORALES DE LOS CONSULTORES DE
CIBIZ S.A. EN LA FIGURA SE PUEDE APRECIAR EL TIPO DE CADA COLUMNA ASÍ
COMO LA CLAVE PRIMARIA DE LA TABLA.
132
32. COLUMNAS QUE CONFORMAN LA TABLA NIV_SALARIAL. LA TABLA GUARDA
LOS DATOS DE LA ESCALA DE SALARIOS DE LOS CONSULTORES DE CIBIZ S.A.
EN LA FIGURA SE PUEDE APRECIAR EL TIPO DE CADA COLUMNA ASÍ COMO LA
CLAVE PRIMARIA DE LA TABLA.
133
33. COLUMNA QUE CONFORMA LA TABLA PAÍS. LA TABLA GUARDA LOS
NOMBRES DE 202 PAÍSES, 38 TERRITORIOS DEPENDIENTES Y 1 ENTIDAD
ESPECIAL. SE USARÁ COMO RANGO DE VALORES PARA LOS DATOS PAIS_C DE
LA TABLA CONSULTOR Y PAIS_E DE LA TABLA EMPRESA. EN LA FIGURA SE
PUEDE APRECIAR EL TIPO DE CADA COLUMNA ASÍ COMO LA CLAVE PRIMARIA
DE LA TABLA.
133
34. COLUMNAS QUE CONFORMAN LA TABLA PROYECTO. LA TABLA GUARDA
LOS DATOS DE LOS PROYECTOS EMPRENDIDOS POR CIBIZ S.A. EN LA FIGURA
SE PUEDE APRECIAR EL TIPO DE CADA COLUMNA ASÍ COMO LA CLAVE
PRIMARIA DE LA TABLA.
134
35. COLUMNAS QUE CONFORMAN LA TABLA REG_DE_ACT. LA TABLA GUARDA
LOS DATOS DE LAS ACTIVIDADES REGISTRADAS POR LOS CONSULTORES. EN
ix
UNIVERSIDAD RAFAEL URDANETA
LA FIGURA SE PUEDE APRECIAR EL TIPO DE CADA COLUMNA ASÍ COMO LA
CLAVE PRIMARIA DE LA TABLA.
134
36. COLUMNAS QUE CONFORMAN LA TABLA TIPO_ACTIVIDAD. LA TABLA
GUARDA LOS DATOS DE LOS TIPOS DE ACTIVIDAD QUE PUEDEN REGISTRAR
LOS CONSULTORES. EN LA FIGURA SE PUEDE APRECIAR EL TIPO DE CADA
COLUMNA ASÍ COMO LA CLAVE PRIMARIA DE LA TABLA.
135
37. DIAGRAMA DE ENTIDAD-RELACIÓN (E-R) DE LA BD DEL SISTEMA.
S
O
D
VA
R
E
S
E
R
S
HO
EC
R
E
D
x
135
OS
D
A
RV
E
S
E
SR
O
H
C
E
R
DE
CAPÍTULO I
EL PROBLEMA
Capítulo I: El Problema
UNIVERSIDAD RAFAEL URDANETA
CAPÍTULO I
EL PROBLEMA
1..PLANTEAMIENTO DEL PROBLEMA
S
O
D
VA
R
E
S
E
R
S
HO
La automatización de procesos, es una práctica que le permite al ser humano
EC
R
E
D
realizar ciertas actividades de una manera más rápida, precisa y económica, por ello,
ha sido uno de los pilares de la humanidad desde su propagación en la época de la
revolución industrial (Rosario 2004). No es posible concebir al mundo de hoy sin las
maquinarias industriales y los computadores encargados de producir alimentos, ropa,
electrodomésticos, automóviles, combustibles, entre otros bienes, y de proporcionar al
planeta la conectividad para poder realizar operaciones de tipo comercial, empresarial y
financiero.
En este orden de ideas, el procesamiento electrónico de datos (PED) es la rama de
la automatización relacionada con los sistemas de información y los centros de
computo, también se considera PED a la obtención, análisis y registro de datos a través
de interfaces y computadores. El PED tiene sus orígenes a finales del siglo XVIII
cuando el inventor norteamericano Herman Hollerith patentó una máquina calculadora
que contaba, comparaba y ordenaba la información guardada en tarjetas perforadas.
Para Hazas (2008), el PED es el principal avance tecnológico logrado en el mundo de
15
16
Capítulo I: El Problema
UNIVERSIDAD RAFAEL URDANETA
los negocios, debido a que permite realizar un gran número de tareas; desde procesar
una nómina, hasta simular los efectos de las decisiones de mercado en una empresa.
Como se puede ver, el procesamiento electrónico de datos ha sido y sigue siendo un
elemento imprescindible en cualquier campo de la actividad humana en donde se
necesite procesar grandes cantidades de información y junto con las tecnologías de la
comunicación e información (TIC) constituyen las bases sobre las cuales se fundamenta
S
O
D
VAimportantes de toda empresa
Hoy en día, se considera que uno de los activos
más
R
E
S
E
R
es la información, por ello, toma
vitalS
importancia para dichas organizaciones contar con
O
H
C
E
R
mecanismos por
medio de los cuales se procese y haga un uso efectivo de la misma.
DE
la economía simbólico-electrónica de la actualidad.
En Venezuela, los grandes proveedores de sistemas de planificación de recursos
empresariales (ERP por sus siglas en inglés) contaban con soluciones dirigidas a las
PYMES desde el comienzo de la década (Ramírez 2001). Actualmente, hay una gran
demanda de sistemas integrados de información de diversos tipos a nivel nacional,
entre los que están CRM (Gestión de Relaciones con los Clientes), SCM (Gestión de la
Cadena de Proveedores), y los anteriormente mencionados ERP.
Dichos sistemas, deben permitirle tanto a gerentes como a subordinados hacer un
uso efectivo de la información relacionada con proyectos y otras actividades de la
empresa, para generar una mayor productividad del empleado, optimizar los procesos y
reducir costos. Según Ramírez (2001), los sistemas ERP de mayor demanda en el país
“han ido extendiendo su funcionalidad a Internet” para ofrecer un rango más amplio de
soluciones a los clientes.
17
Capítulo I: El Problema
UNIVERSIDAD RAFAEL URDANETA
En este orden de ideas, Consulting & Information for Business S.A. (Cibiz S.A.) es
una firma dedicada a brindar servicios en consultoría de negocios y para tal fin provee
soluciones informáticas en sistemas ERP de clase mundial, especialmente en el
sistema SAP R/3 ®. Cibiz actualmente se encuentra en un período de crecimiento y ha
empezado a ofrecer sus servicios a nivel nacional e intencional.
Como Cibiz aún es una empresa pequeña (35 empleados aproximadamente),
S
O
D
VA y por este motivo, viajan
vicepresidente, ellos a su vez son consultores de
laR
empresa,
E
S
E
R
al interior y exterior del país H
constantemente
para reunirse con los clientes, es por ello
OS
C
E
DERdirectivos necesitan una plataforma por medio de la cual puedan
que los mencionados
quienes se encargan de la gestión de los consultores son el presidente y el
planear y dirigir así como organizar y supervisar, proyectos y consultores
respectivamente, desde cualquier lugar del mundo de manera fácil y centralizada. De
igual manera, el resto de los consultores necesita un medio por el cual reportar las
actividades realizadas diariamente de una manera fácil y rápida sin importar en que
lugar del mundo estén. Además, esta solución debe ser lo más económica posible,
porque actualmente todos los recursos de la empresa están destinados a el crecimiento
de la misma.
En el presente, las herramientas utilizadas para la organización y control de los
consultores, son aplicaciones ofimáticas como Microsoft Word ® y Microsoft Excel ®, en
las cuales los consultores realizan el reporte de las actividades llevadas a cabo cada
semana para luego enviárselo a los gerentes por correo electrónico. El mecanismo
descrito anteriormente, funcionó bien durante los primeros años de la empresa, pero
18
Capítulo I: El Problema
UNIVERSIDAD RAFAEL URDANETA
actualmente, debido al aumento en el número de consultores contratados, genera
problemas porque el procesamiento de la información contenida en dichos documentos
es muy lento, y resulta muy difícil llevar un histórico de las actividades reportadas por
los consultores, ya que las mismas se encuentran distribuidas entre los archivos
enviados semanalmente por los mismos, lo cual a su vez dificulta la verificación del
cumplimiento del calendario, presupuestos y horas/hombre calculadas para un
S
O
D
VAes que hay dificultad para
Otra deficiencia que sufre Cibiz S.A. en elE
presente,
R
S
E
R
organizar la información referente
OSa consultores, clientes y proyectos, de manera
H
C
ERunaEbase de datos para tal fin), lo cual dificulta la planeación y
organizada (no
Dhay
proyecto.
dirección de los proyectos de la empresa.
De continuar Cibiz con las fallas mencionadas, podría quedar incapacitada para
contratar a más consultores ya que no estaría preparada para supervisarlos, trayendo
como consecuencia que la empresa interrumpa su crecimiento. También se volvería
muy difícil verificar la marcha de los proyectos. Finalmente, se podrían generar pérdidas
debido a un uso ineficiente de los pasivos destinados a los consultores y proyectos.
Para solventar las fallas descritas, es necesario desarrollar una extranet para la
automatización de los procesos de gestión de los consultores de Consulting &
Information for Business S.A., por medio de la cual los directivos de la empresa puedan
supervisar a los consultores, así como también planear y dirigir los proyectos desde
cualquier lugar del mundo, de manera fácil, organizada y centralizada.
19
Capítulo I: El Problema
UNIVERSIDAD RAFAEL URDANETA
2. FORMULACIÓN DEL PROBLEMA
¿ Cómo debe estar compuesta una extranet para la automatización de los procesos
de gestión de los consultores de la empresa Consulting & Information for Business
S.A.?
S
O
D
VA
R
E
S
3. OBJETIVOS DE LA INVESTIGACIÓN
E
R
S
HO
EC
R
E
D
3.1. OBJETIVO GENERAL
Desarrollar una extranet para la automatización de los procesos de gestión de los
consultores de la empresa Consulting & Information for Business S.A.
3.2. OBJETIVOS ESPECÍFICOS
•
Identificar los requerimientos para el desarrollo de una extranet para la
automatización de los procesos de gestión de los consultores de la empresa
Consulting & Information for Business S.A.
•
Analizar los requerimientos identificados para realizar el diseño de la extranet
para la automatización de los procesos de gestión de los consultores de la
empresa Consulting & Information for Business S.A.
20
Capítulo I: El Problema
UNIVERSIDAD RAFAEL URDANETA
•
Elaborar la extranet para la automatización de los procesos de gestión de los
consultores de la empresa Consulting & Information for Business S.A.
•
Ejecutar pruebas de funcionamiento a la extranet para la automatización de los
procesos de gestión de los consultores de la empresa Consulting & Information
for Business S.A.
S
O
D
VA
R
E
S
4. JUSTIFICACIÓN E IMPORTANCIA DE LA INVESTIGACIÓN
E
R
S
El desarrollo de una extranet
HOpara la automatización de los procesos de gestión de
C
E
R
DE
los consultores
de Consulting & Information for Business S.A., le brindará a la
mencionada empresa una plataforma mediante la cual organizar y supervisar de una
manera centralizada, organizada, rápida, eficiente y efectiva a sus consultores, sin
importar la parte del mundo donde se encuentren, porque la plataforma sobre la cual
funcionará la extranet será Internet. Así mismo, la extranet le permitirá a Cibiz
almacenar toda la información referente a los consultores y sus actividades de una
manera más organizada, ya que la misma contará con una base de datos para tal fin,
con lo cual desaparecerán todos los inconvenientes vinculados a dicha causa.
Por otra parte, la presente obra, muestra como se debe adaptar la metodología
Watch Extendida al desarrollo de sistemas Web no codificados con lenguajes
orientados a objetos, como es el caso de PHP. De la misma manera, en la elaboración
de la extranet se implementó el desarrollo de aplicaciones Web por capas,
21
Capítulo I: El Problema
UNIVERSIDAD RAFAEL URDANETA
específicamente se dividió el trabajo en las capas de presentación o interfaz de usuario,
la capa de lógica de negocios y la capa de datos.
Igualmente, los resultados arrojados por esta investigación podrían ser considerados
en diversas organizaciones de la región a la hora de desarrollar ó rediseñar extranets
para la gestión de personal. Finalmente, este trabajo especial de grado también puede
servir de apoyo a otras investigaciones de características similares, como por ejemplo la
elaboración de sistemas de información Web.
S
O
D
VA
R
E
S
E
R
S
5. DELIMITACIÓN ESPACIAL
HYOTEMPORAL
C
E
DER
Esta investigación esta referida al desarrollo de una extranet para la automatización
de los procesos de gestión de la empresa Consulting & Information for Business S.A.,
cuyo contenido trata de la automatización de procesos a través de sistemas de
información integrados basados en Web. De la misma manera, este trabajo especial de
grado se desarrolló geográficamente en las instalaciones de la empresa Consulting &
Information for Business S.A., ubicada en el Estado Zulia, en el período comprendido
entre Enero de 2007 y Abril de 2008.
OS
D
A
RV
E
S
E
SR
O
H
C
E
R
DE
CAPÍTULO II
MARCO TEÓRICO
Capítulo II: Marco Teórico
UNIVERSIDAD RAFAEL URDANETA
CAPÍTULO II
MARCO TEÓRICO
1. ANTECEDENTES DE LA INVESTIGACIÓN
S
O
D
VA
R
E
S
E
R
S
HO
García (2002), en su trabajo de grado titulado: Extranet para la consulta de tareas
EC
R
E
D
académicas entre el personal docente y administrativo con los representantes caso:
Colegio Bellas Artes, tuvo como propósito fundamental desarrollar una extranet para la
consulta de las tareas académicas, las observaciones sobre conducta y otras
informaciones de interés, mejorando la comunicación entre los representantes, personal
docentes y administrativo del Colegio Bellas Artes de Maracaibo.
En cuanto a la metodología utilizada para dicha investigación, la misma fue según el
objeto de estudio, de tipo aplicada, y según el nivel de medición y análisis de la
información, de tipo descriptiva, con el diseño tecnológico del conocimiento, se empleó
la metodología adaptada a los métodos de Jonás Montilva, la cual está constituida por
seis fases: Descripción del Proyecto, Definición de Requerimientos, Diseño Preliminar,
Diseño Detallado, Construcción del Sistema y Prueba del Sistema. Para la obtención de
los datos se utilizaron la observación directa, entrevistas informales y la aplicación de
una encuesta cerrada.
23
24
Capítulo II: Marco Teórico
UNIVERSIDAD RAFAEL URDANETA
Los resultados obtenidos por esta investigación, indican que los objetivos
propuestos al inicio de la misma se cumplieron, ya que se comprobó la factibilidad del
sistema propuesto, la aplicación del mismo por parte del personal docente y
administrativo así como de los representantes, facilitando el control de las actividades
académicas de los alumnos a los representantes y docentes.
Esta investigación sirvió de sustento al presente estudio, pues aportó información
S
O
D
VAtitulado: Desarrollo de una
Por otra parte, González (2002), realizó un
estudio
R
E
S
E
R
S la optimización de la comunicación entre los
extranet corporativa orientada
hacia
O
H
C
ERECocsa Corrosión Control S.A., cuyo propósito fundamental fue
usuarios de laD
empresa
relacionada con la metodología a seguir para desarrollar la extranet.
desarrollar una extranet corporativa orientada hacia la optimización de la comunicación
entre los usuarios de dicha empresa.
Este estudio, según su propósito y conforme a la metodología empleada fue de tipo
aplicada y descriptiva respectivamente. La metodología utilizada para el desarrollo de la
extranet, está basada en una adaptación de los lineamientos de Alin F., Lafont D. y
Macary J., y está constituida por tres fases: “Análisis del Entorno”, “Desarrollo” y
“Despliegue y Seguridad”. La técnica de recolección de datos utilizada fue la
observación directa y el instrumento fue la entrevista informal no estructurada.
En torno a los resultados obtenidos por esta investigación, el sistema logra cumplir
con los objetivos planteados al proporcionar un medio efectivo de comunicación,
utilizando tecnología de Internet para satisfacer las necesidades de transporte y
tratamiento de los flujos de información, facilitando el control administrativo entre la
25
Capítulo II: Marco Teórico
UNIVERSIDAD RAFAEL URDANETA
oficina matriz y sus sucursales, estableciendo así una base para la efectiva toma de
decisiones.
Este estudio suministró a la presente investigación ideas sobre los tipos de prueba
de verificación a aplicarle a la extranet de Cibiz S.A.
2. BASES TEÓRICAS
S
O
D
VAteóricos en los que se basó el
A continuación se presentan los diversos fundamentos
R
E
S
E
R
S
desarrollo de la extranet para
la automatización
de los procesos de gestión de los
O
H
C
E
R
consultores deD
laE
empresa Consulting & information for Businness S.A.
2.1. EXTRANETS
Una extranet, (extended intranet o intranet extendida), es la parte de una intranet ó
un conjunto de servicios informáticos disponibles para usuarios que se conectan fuera
de la red interna de una organización. Para Musciano y Kennedy (1998), las extranets
son de acceso restringido, pero usan Internet para proveer servicios a sus usuarios. Las
extranets a menudo se implementan como un portal Web desde la cual los usuarios se
autentican escribiendo su login y
contraseña, y así poder acceder a los servicios
disponibles en la extranet para su tipo de usuario, es decir, dependiendo del tipo de
usuario, estos últimos podrán acceder ó no a cada uno de los servicios de la extranet.
26
Capítulo II: Marco Teórico
UNIVERSIDAD RAFAEL URDANETA
En cuanto a las aplicaciones de las extranets, estas pueden utilizarse entre grupos
de empresas que comparten la misma información, para mostrar los catálogos de
productos a los clientes; para la gestión, control y desarrollo de proyectos, programas
de formación de empleados, intercambio de información entre clientes y empleados,
entre otras.
2.1.1. TIPOS DE EXTRANETS
S
O
D
VA
R
E
S
E
R
S
Existen dos tipos básicos H
deO
extranet: La Interactiva y la Integrada. Así mismo, una
C
E
ER de ambas.
mixta incluiríaD
elementos
2.1.1.1. EXTRANET INTERACTIVA
Es aquella que delega funciones o procesos de la propia empresa a los usuarios del
sistema. Una aplicación de este tipo de extranet es la recepción de facturas, asi se
ahorra en gastos administrativos, de envío e impresión, porque los gastos también son
delegados en los usuarios de la extranet. Así mismo, otro uso típico de las extranets
interactivas es servir de nodo de información. Un nodo de información efectivo
reemplazara gran parte de las cartas, faxes, llamadas telefónicas y demás medios
tradicionales hasta ahora necesarios para la relación entre empresas. Por lo tanto,
informar en "tiempo real" agiliza procesos y también redunda en ahorros.
27
Capítulo II: Marco Teórico
UNIVERSIDAD RAFAEL URDANETA
2.1.1.2. EXTRANET INTEGRADA
Este tipo de Extranet precisamente integra el intercambio de información entre
sistemas. Las barreras de entrada son superiores debido al impacto tecnológico y la
necesidad de integración con sistemas externos a la empresa, pero es el sistema con
mayor potencial debido a la automatización de procesos. Un uso típico de esta clase de
S
O
D
VA
R
E
S
Extranet es como parte de un sistema de aprovisionamiento "Just In Time".
En
empresas
con
E
empleados
R
S
HO
numerosos
EC
R
E
D
y
complejos
sistemas
de
aprovisionamiento, es cada vez más común el permitir (o exigir) a proveedores de
suministros no-competitivos el integrarse en este tipo de Extranet para delegarles la
gestión de estas compras. Un ejemplo es la adquisición de Tarjetas de Negocio.
Siempre y cuando el usuario del sistema tenga el perfil y los privilegios de compras
apropiados, podrá realizar el pedido que será gestionado directamente por el proveedor
acordado, eliminando así errores e intermediarios innecesarios dentro de la propia
empresa.
2.2. AUTOMATIZACIÓN DE PROCESOS
La automatización es un proceso donde se trasfieren tareas industriales,
administrativas o científicas, realizadas habitualmente por operadores humanos a un
conjunto de elementos tecnológicos, haciendo más ágil y efectivo el trabajo y ayudando
al hombre. El alcance va más allá de la simple mecanización de los procesos ya que
28
Capítulo II: Marco Teórico
UNIVERSIDAD RAFAEL URDANETA
ésta provee a operadores humanos mecanismos para asistirlos en los esfuerzos físicos
del trabajo.
2.2.1. TIPOS DE AUTOMATIZACIÓN
Entre los tipos de automatización más conocidos se encuentran el control automático
de procesos, el procesamiento electrónico de datos, la automatización fija, el control
S
O
D
VAcaracterizados de diversos
Procesos, se refiere usualmente al manejo deE
procesos
R
S
E
R
S y físicos); un ejemplo de esto lo podría ser el
tipos de cambios (generalmente
químicos
O
H
C
E
R
E
D
proceso de refinación de petróleo.
numérico computarizado y la automatización flexible. El Control Automático de
El Procesamiento Electrónico de Datos, frecuentemente es relacionado con los
sistemas de información, centros de cómputo, entre otros. Sin embargo, en la
actualidad también se considera dentro de esto la obtención, análisis y registros de
datos a través de interfases y computadores.
La Automatización Fija, es aquella asociada al empleo de sistemas lógicos tales
como: los sistemas de relevadores y compuertas lógicas; sin embargo estos sistemas
se han ido flexibilizando al introducir algunos elementos de programación como en el
caso de los (PLC'S) O Controladores Lógicos Programables. La automatización fija se
caracteriza por la secuencia única de operaciones de procesamiento y ensamble. Sus
operaciones son simples pero su integración en las diferentes estaciones de trabajos
dan lugar a sistemas complejos y costos aplicados a la producción masiva pero cuando
29
Capítulo II: Marco Teórico
UNIVERSIDAD RAFAEL URDANETA
se cambia de un producto a otro, es necesario la puesta a punto manual de todo el
equipo implicando otras tareas, en cambio de herramientas y utilage.
El término “control numérico" se debe a que las órdenes dadas a la máquina son
indicadas mediante códigos numéricos. En una máquina CNC, a diferencia de una
máquina convencional o manual, una computadora controla la posición y velocidad de
los motores que accionan los ejes de la máquina. Gracias a esto, puede hacer
S
O
D
VA
R
E
S
movimientos que no se pueden lograr manualmente como círculos, líneas diagonales y
E
R
S
HO
figuras complejas tridimensionales. Una vez programada la máquina, ésta ejecuta todas
EC
R
E
D
las operaciones por sí sola, sin necesidad de que el operador esté manejándola. Esto
permite aprovechar mejor el tiempo del personal para que sea más productivo.
En cambio la automatización flexible es una extensión de la programable que se ha
desarrollado durante las ultimas décadas a la par de los computadores y de la
tecnología de la automatización, Además de la capacidad para trabajar diferentes
secuencias de operaciones en forma automática permitiendo la fabricación continua de
mezclas variables de productos con tiempos de preparación y cambio de herramientas
virtualmente nulos, al pasar de un producto a otro. Esta requiere alta inversión en
equipo adaptado a las necesites del cliente y esta orientada a la manufactura de partes
afines en lotes de tamaño bajo y medio bajo a una velocidad media de producción La
automatización flexible ha hecho factible los sistemas de manufactura flexible y la
manufactura integrada por computador.
30
Capítulo II: Marco Teórico
UNIVERSIDAD RAFAEL URDANETA
2.3. REDES DE COMPUTADORAS
Para Tanenbaum (2003), el viejo modelo de una solo computadora para satisfacer
todas las necesidades computacionales de una organización ha sido reemplazado por
otro en el cual un gran número de computadoras separadas pero interconectadas hacen
el mismo trabajo, estos sistemas son llamados redes de computadoras.
S
O
D
VA
R
E
S
Sin embargo, las redes de computadoras no existen solo en el mundo de las
E
R
S
HO
organizaciones y empresas, en la actualidad hay un gran número de personas con
EC
R
E
D
pequeñas LAN´s en sus hogares para brindarle conexión a Internet a todos los
ordenadores de la casa y compartir documentos e impresoras, pero en un sentido más
amplio, las funciones de las redes de computadoras, no solo caseras sino en general,
son hacer posible el intercambio de información, compartir recursos y brindar servicios
entre ó a los ordenadores de la red.
2.3.1. CLASIFICACIÓN DE LAS REDES DE COMPUTADORAS
Para Tanenbaum (2003), “no hay una sola clasificación aceptada en la que se
ajusten todas las redes de computadoras, pero hay dos que destacan de manera
importante: la tecnología de transmisión y la escala”,la clasificación hecha en la
presente investigación se basa en la escala ó extensión del área que abarca cada red,
según este enfoque las redes de computadoras se pueden clasificar en redes de área
metropolitana, redes de área local y redes de área extensa. Sin embargo, en este
31
Capítulo II: Marco Teórico
UNIVERSIDAD RAFAEL URDANETA
trabajo sólo se trataran las últimas dos por ser las utilizadas en el proceso de
investigación.
2.3.1.1. REDES DE ÁREA LOCAL
Para Tanenbaum (2003), “las redes de área local (generalmente conocidas como
LANs) son redes de propiedad privada que se encuentran en un solo edificio o en un
S
O
D
A
computadoras personales y estaciones de trabajo
enVoficinas de una empresa y de
R
E
S
E
R
fabricas para compartir recursos
O(porSejemplo, impresoras) e intercambiar información”.
H
C
E
R
E
D
Las LANs están restringidas por tamaño, es decir, el tiempo de transmisión en el peor
campus de pocos kilómetros de longitud. Se utilizan ampliamente para conectar
de los casos es limitado y conocido de antemano. El hecho de conocer este límite
permite utilizar ciertos tipos de diseño, lo cual no sería posible de otra manera. Esto
también simplifica la administración de la red.
2.3.1.2. REDES DE ÁREA AMPLIA
Para Stallins (2004), “se considera como redes de área amplia a todas aquellas que
cubren una extensa área geográfica, requieren atravesar rutas de acceso público y
utilizan, al menos parcialmente, circuitos proporcionados por una entidad proveedora de
servicios de telecomunicación”. Generalmente una red de área amplia (WAN), consiste
de una serie de dispositivos de conmutación interconectados.
Igualmente, continua Stallins, la transmisión generada por cualquier dispositivo se
encaminará a través de estos nodos internos hasta alcanzar el destino. A estos nodos
32
Capítulo II: Marco Teórico
UNIVERSIDAD RAFAEL URDANETA
(incluyendo los situados en los contornos) no les concierne el contenido de los datos, al
contrario, su función es proporcionar el servicio de conmutación, necesario para
transmitir los datos de nodo en nodo hasta alcanzar se destino final. Tradicionalmente,
las WAN se han implementado usando una de las dos tecnologías siguientes:
conmutación de circuitos y conmutación de paquetes. Últimamente, se está empleando
como solución la tecnica de retransmisión de tramas (frame relay), así como las redes
S
O
D
VA
R
E
S
ATM.
2.3.2. INTERREDES
E
R
S
HO
EC
R
E
D redes en el mundo, a veces con hardware y software diferentes.
Existen muchas
Con frecuencia, las personas conectadas a una red desean comunicarse con personas
conectadas a otra red diferente. Para Tanenbaum (2003), “La satisfacción de este
deseo requiere que se conecten diferentes redes, con frecuencia incompatibles, a veces
mediante máquinas llamadas puertas de enlace (gateways) para hacer la conexión y
proporcionar la traducción necesaria, tanto en términos de hardware como de software.
Un conjunto de redes interconectadas se llama interred”. Una forma común de interred
es un conjunto de LANs conectadas por una WAN. Un sinónimo de interred es internet
(con “i” minúscula).
2.3.3. INTERNET
Internet, es un conjunto de redes de computadoras interconectadas a nivel mundial
sobre la cual funciona la World Wide Web (WWW). Según Tanenbaum (2003), “Internet
33
Capítulo II: Marco Teórico
UNIVERSIDAD RAFAEL URDANETA
no es del todo una red, sino un inmenso conjunto de redes diferentes que usan ciertos
protocolos comunes y proporcionan ciertos servicios comunes. Es un sistema poco
común porque nadie lo planeó y nadie lo controla”. Internet es la WAN más grande y
extensa del planeta, ha tenido un éxito tan rotundo que su tamaño se ha duplicado cada
año desde 1988.
2.3.3.1. ANTECEDENTES DE INTERNET
S
O
D
VdeAProyectos de Investigación
Según GS Comunicaciones (1998), la Agencia
R
E
S
E
R
Avanzada (ARPA por sus siglas
OenSinglés) del departamento de defensa de Estados
H
C
E
R
E
D
Unidos creó el proyecto ARPANET en 1969, que daría como resultado el desarrollo de
Internet, la cual en su origen no fue diseñado para uso comercial. Luego entre 1973 y
1974 se creó el protocolo estándar de comunicación, el TCP/IP, dicho protocolo permite
la comunicación entre computadoras sin importar su sistema operativo o hardware. Un
año después empezaron a aparecer los servicios básicos de Internet: correo
electrónico, transferencia de archivos y la conectividad remota.
De igual manera, un poco más tarde en 1982, surgieron servicios como el sistema
de noticias Usenet y el Internet Gopher, un precursor de lo que siete años más tarde se
daría a conocer como el World Wide Web (WWW ó Web). Efectivamente en 1989 se
crea la Web, una infraestructura de información gráfica y textual colocada en servidores
y fácil de navegar, la cual implicó un gran salto hacia el uso comercial de Internet.
34
Capítulo II: Marco Teórico
UNIVERSIDAD RAFAEL URDANETA
2.3.4. LA WORLD WIDE WEB
Según Tanenbaum (2003), “Hasta principios de la década de 1990, Internet era
muy visitada por investigadores académicos, del gobierno e industriales. Una nueva
aplicación, WWW (World Wide Web) cambió todo eso y trajo millones de usuarios
nuevos no académicos a la red. Esta aplicación –inventada por Tim Berners-Lee, físico
del CERN—no cambió ninguna de las características subyacentes pero las hizo más
S
O
D
VA
R
E
S
fáciles de usar… WWW hizo posible que un sitio estableciera páginas de información
E
R
S
HO
que contienen texto, imágenes, sonido e incluso video, y vínculos integrados a otras
páginas”.
EC
R
E
D
Para Gralla y Troller (2006), “Cuando mucha gente utiliza la palabra Internet,
realmente están hablando de la World Wide Web. La Web es la parte de Internet de
más rápido crecimiento, más interesante, innovadora y visible”. Si bien el concepto de
hipertexto había sido implementado anteriormente, en el WWW toma un sentido mucho
más amplio. Un enlace de una página Web puede apuntar a otra página que se
encuentre en cualquier servidor del mundo. El objetivo de la World Wide Web es servir
como base de información amigable, fácil de utilizar, rica en contenido y con la
posibilidad de poder actualizarse en forma distribuida. Actualmente en la WWW
podemos encotrar páginas de empresas, gobierno, universidades, ONG´s, y hasta
páginas personales.
35
Capítulo II: Marco Teórico
UNIVERSIDAD RAFAEL URDANETA
2.4. BASES DE DATOS
Para Silberschatz y otros (2002), un sistema gestor de bases de datos (SGBD),
consiste en una colección de datos interrelacionados y un conjunto de programas para
acceder a dichos datos. La colección de datos es normalmente denominada base de
datos. El objetivo principal de un SGBD es proporcionar una forma de almacenar y
recuperar la información de una base de datos de manera que sea tanto práctica como
S
O
D
VA
R
E
S
eficiente.
E
R
S
HO
Así mismo, los sistemas de bases de datos se diseñan para gestionar grandes
EC
R
E
D
cantidades de información. La gestión de los datos implica tanto la definición de
estructuras para almacenar la información como la provisión de mecanismos para la
manipulación de la información. Además, los sistemas de bases de datos deben
proporcionar la fiabilidad de la información almacenada, a pesar de las caídas del
sistema o los intentos de acceso sin autorización. Si los datos van a ser compartidos
entre diversos usuarios, el sistema debe evitar posibles resultados anómalos.
2.4.1. SQL
El SQL (Structured Query Language ó lenguaje estructurado de consultas), es un
lenguaje de consultas de bases de datos, cuya versión original fue desarrollada por IBM
en el laboratorio de investigación de San José, actualmente centro de investigación de
Almadén. Según Lane y Williams (2004), SQL es usado por casi todos los servidores de
bases de datos y consiste en un conjunto de sentencias para definir y manipular datos.
36
Capítulo II: Marco Teórico
UNIVERSIDAD RAFAEL URDANETA
Para Silberschatz y otros (2002), el lenguaje SQL usa una combinación de álgebra
relacional y construcciones del cálculo relacional. Aunque SQL se considere un
lenguaje de consultas, tiene muchas otras capacidades, como por ejemplo,
características para definir la estructura y modificación de los datos y para la
especificación de restricciones de seguridad.
2.4.1.1. COMPONENTES DE SQL
S
O
D
VA
R
E
S
E
R
S
Según Silberschatz y otrosH
(2002),
O el lenguaje SQL tiene varios componentes:
C
E
DER
•
Lenguaje de definición de datos (LDD): El LDD proporciona órdenes para la
definición de esquemas y borrado de relaciones, creación de índices y
modificación de esquemas de relación.
•
Lenguaje interactivo de manipulación de datos (LMD): Incluye un lenguaje de
consultas, basado tanto en álgebra relacional como en el cálculo relacional de
tuplas, además de órdenes para insertar, borrar y modificar tuplas de la base de
datos.
•
Definición de vistas: El LDD incluye órdenes para la creación de vistas.
•
Control de transacciones: SQL incluye órdenes para la especificación del
comienzo y final de transacciones.
37
Capítulo II: Marco Teórico
UNIVERSIDAD RAFAEL URDANETA
•
SQL incorporado y SQL dinámico: Ambos definen cómo se pueden incorporar
las instrucciones SQL en lenguajes de programación de propósito general, tales
como C, C++, Java, PL/I, Cobol, Pascal y Fortran.
•
Integridad: El LDD incluye órdenes para la especificación de las restricciones de
integridad que deben satisfacer los datos almacenados en la base de datos. Las
actualizaciones que violen las restricciones de integridad se rechazan.
S
O
D
VAse ejecuta como un proceso
R
Finalmente, para Lane y Williams (2004),E
MySQL
S
E
R
OSservidor, como Apache o ISS, y soporta una gran
(daemon ó demonio) ó servicio
H
C
E
R
E
D
cantidad de clientes incluyendo un interpretador de comandos (shell) y una librería
de funciones PHP; un servidor MySQL puede administrar múltiples bases de datos
pertenecientes a múltiples aplicaciones y cada una de dichas BD´s pueden
almacenar diferentes datos organizados de diferentes maneras.
2.5. PÁGINAS ESTÁTICAS
Son páginas Web creadas usando solamente el estándar HTML. Según Musciano y
Kennedy (1998), el flujo de datos entre el servidor y el cliente en las páginas estáticas,
la inicia el navegador del cliente contactando al servidor con el documento solicitado,
luego el servidor responde a la petición enviándole el documento y el contenido
referenciado por el mismo (imágenes, sonido, video, entre otros),
navegador del cliente despliega el contenido del documento al usuario.
finalmente, el
38
Capítulo II: Marco Teórico
UNIVERSIDAD RAFAEL URDANETA
Una vez desplegado al usuario contenido del documento, este no cambia, por ello no
son necesarias descargas de datos adicionales desde el servidor que respondan a las
acciones de los usuarios, de hecho, las únicas acciones capaces de iniciar una
descarga desde el servidor al cliente en este tipo de páginas, son teclear una URL en la
barra de direcciones del navegador ó hacer click en un enlace, en otras palabras, la
solicitud de otro documento Web, es por ello que a este tipo de páginas se les llama
S
O
D
VA
R
E
S
estáticas.
2.5.1. HTML
EC
R
E
D
E
R
S
HO
El lenguaje de marcas de hipertexto (HTML por sus siglas en inglés), es un
subconjunto del estándar internacional para el intercambio electrónico de documentos
(SGML por sus siglas en inglés). Para Niederst (1999, 2001), es el lenguaje usado para
crear documentos Web, define la sintaxis y colocación de instrucciones especiales
(etiquetas o tags), no mostradas, pero cuya función es decirle al navegador como y
donde desplegar los elementos que forman dichos documentos. Así mismo, como lo
indica su nombre, provee etiquetas para crear enlaces de hipertexto, es decir, enlaces
que permiten acceder y mostrar en pantalla el contenido de otros documentos Web,
alojados en la misma computadora, en otro ordenador de la misma LAN, ó en otras
redes, como Internet.
De igual manera, existen etiquetas para editar y manipular el aspecto del texto en el
documento Web, desplegar imágenes, colocar formularios, entre otras funciones. Los
39
Capítulo II: Marco Teórico
UNIVERSIDAD RAFAEL URDANETA
documentos HTML son simplemente archivos de texto ASCII, según Tittel y Burmeister
(2005) “es por eso que la Web trabaja tan bien como lo hace”, porque, continúa Tittel,
“el texto es el lenguaje universal de las computadoras”. Las etiquetas hacen referencia
a la ubicación física del contenido multimedia, y el navegador los busca y muestra como
contenido de las páginas Web. El HTML y todos los demás estándares relacionados
con el Web son desarrollados bajo la autoridad del World Wide Web Consortium (W3C).
S
O
D
VA
R
E
S
E
R
S
HO
2.5.2. MACROMEDIA DREAMWEAVER
EC
R
E
Macromedia
DDreamweaver ®, es un editor HTML profesional para diseñar, codificar
y desarrollar sitios, páginas y aplicaciones Web. Se puede utilizar para generar
manualmente el código HTML, es decir, escribiendo; así como para generar el código
en un entorno de edición visual del tipo WYSIWYG, en el cual se diseña la estructura de
las páginas arrastrando elementos visuales o a través de los menús y opciones de una
Interfaz gráfica de usuario, sin la necesidad de escribir una solo etiqueta de código
HTML, porque Dreamweaver ®, se encarga de generar en segundo plano el documento
HTML con el código necesario para que la página Web luzca igual a como se ve en el
entorno de edición visual.
Así mismo, Dreamweaver ® también ofrece numerosas herramientas y funciones de
gestión de código, como la vista de código, terminación automática de etiquetas,
material de referencia sobre HTML, CSS, Javascript, CFML, ASP, JSP y un depurador
Javascript. Además, Dreamweaver ® también incorpora Macromedia UltraDev, con
40
Capítulo II: Marco Teórico
UNIVERSIDAD RAFAEL URDANETA
funciones mejoradas, lo que facilita la creación de aplicaciones Web con bases de datos
dinámicas mediante lenguajes de servidor como ASP, ASP.NET, ColdFusión Markup
Lenguaje (CFML), JSP y PHP.
2.6. PÁGINAS DINÁMICAS
S
O
D
VaAlas acciones que los usuarios
funcionalidad programática, la cual le permite responder
R
E
S
E
R
hacen en la página. Por otraH
parte,
OSpara Musciano y Kennedy (1998), son el resultado
C
E
de múltiples transacciones
DER iniciadas desde ambos lados, es decir, desde el lado del
Para Tittel y Burmeister (2005), las páginas Web son dinámicas cuando se les añade
cliente y el lado del servidor, un documento client – pull es el que inicia las
transacciones desde el lado del cliente, cuando el servidor Web es el instigador, el
documento dinámico es conocido como “documento server - push“.
2.6.1. PHP
PHP es un acrónimo recursivo cuyo significado es “PHP: Hypertext Preprocessor”.
Para Williams (2004), PHP es un lenguaje de scripting usualmente embebido o
combinado con el código HTML de una pagina Web, y funciona de la siguiente manera:
cuando una página es solicitada, el servidor Web ejecuta el script PHP y genera e
introduce el código HTML indicado por el código PHP en el documento Web que es
enviado al navegador como respuesta de la solicitud de página. PHP es compatible con
41
Capítulo II: Marco Teórico
UNIVERSIDAD RAFAEL URDANETA
una gran cantidad de las bases de datos comerciales y de libre distribución usadas
actualmente, a lo cual le debe gran parte de su popularidad También es importante
señalar que PHP es un lenguaje interpretado.
En otras palabras, PHP es un leguaje de programación de alto nivel, mediante el
cual se pueden realizar páginas Web dinámicas, al programar la ejecución de scripts
con comportamiento condicional cuando ocurran ciertos eventos de importancia para el
S
O
D
VA
R
E
S
diseñador del sitio Web. Estos scripts determinarán el código HTML que será enviado
E
R
S
HO
de vuelta al navegador de la computadora cliente.
EC
R
E
D
2.6.2. JAVASCRIPT
Para Niederst (2001), Javascript es un lenguaje de scripting del lado del servidor que
añade interactividad a las páginas Web y le permite al diseñador tener el control de
varios aspectos del navegador. Javascript no se puede conectar a las bases de datos,
por esta razón señala Williams (2004), “sólo ofrece una limitada interacción con ciertos
recursos del sistema, y no puede realizar la mayoría de las tareas que una aplicación de
bases de datos Web requiere…Como sea, Javascript es bueno para interactuar con
formularios y para controlar el despliegue de datos al usuario”.
Por otra parte, como los scripts de Javascript están embebidos en el código HTML,
estos son interpretados en el cliente cuando la página es cargada. En cuanto a las
aplicaciones de Javascript, Niederst (2001), señala que se pueden hacer muchas cosas
como desplegar información adicional acerca de los enlaces, crear efectos rollover en el
42
Capítulo II: Marco Teórico
UNIVERSIDAD RAFAEL URDANETA
puntero del ratón, cambiar los contenidos de una página de acuerdo a ciertas
condiciones, mostrar contenido aleatoriamente, cargar contenido en una nueva ventana
o frame del navegador y con algo de ayuda de las Cascading Style Shets (CSS) mover
elementos alrededor de la página.
Sin embargo, Javascript es mayormente utilizado para hacer validaciones de
formularios en el lado del cliente, para Williams (2004) esto trae como beneficios una
S
O
D
VA de la validación del lado
trabajo del servidor y de tráfico en la red. Además,
a diferencia
R
E
S
E
R
del servidor, puede ser implementado
OS como un tipo de validación interactiva donde los
H
C
E
errores son detectados
DER en el momento de su ocurrencia y realizar reportes donde los
validación más rápida que la validación del lado del servidor, reducción de la carga de
mensajes de error son mostrados individualmente campo por campo del formulario.
2.7. ARQUITECTURA CLIENTE/SERVIDOR
Para Elizalde (2000), la arquitectura cliente-servidor permite al usuario en una
máquina, llamada el cliente, requerir algún servicio de una máquina a la que está unida,
llamada el servidor, mediante una red como una LAN o una WAN. Estos servicios
pueden ser peticiones de datos a una base de datos, de información contenida en
archivos, los archivos en sí mismos, peticiones de imprimir datos en una impresora
asociada, entre otros. Aunque clientes y servidores suelen verse como máquinas
separadas, pueden, de hecho, ser dos áreas separadas de una misma máquina.
43
Capítulo II: Marco Teórico
UNIVERSIDAD RAFAEL URDANETA
Además una estación cliente unida a un servidor puede ser a su vez ser servidor de otro
cliente y el servidor puede ser un cliente de otro servidor en la red.
Igualmente, es posible tener el cliente corriendo en un sistema operativo y el servidor
en otro distinto, además un servidor puede atender a múltiples clientes en forma
concurrente. Para IBM la arquitectura cliente-servidor es “La tecnología que proporciona
S
O
D
VdeAla organización, en múltiples
cualquier otro recurso del grupo de trabajo y/o, aE
través
R
S
E
R
plataformas. El modelo soporta
OSun medio ambiente distribuido en el cual los
H
C
RE hechos por estaciones de trabajo inteligentes o "clientes'',
Eservicio
requerimientosDde
al usuario final el acceso transparente a las aplicaciones, datos, servicios de cómputo o
resultan en un trabajo realizado por otros computadores llamados servidores”.
Sin embargo, para Lane y Williams (2004), si las aplicaciones cliente-servidor
trabajan con una base de datos, se esta en presencia de una cadena con tres
eslabones, en el cual, en un extremo se encuentra la parte del cliente, en el medio esta
la mayoría de la lógica de la aplicación, y en el otro extremo se presenta la parte de la
base de datos y su correspondiente DBMS. Los autores advierten que aunque este es
un modelo conceptual en la práctica hay diferentes implementaciones de sistemas de
bases de datos Web que encajan en él.
44
Capítulo II: Marco Teórico
UNIVERSIDAD RAFAEL URDANETA
S
O
D
VA
R
E
S
E
R
S
HO
EC
R
E
D
FIGURA 1. ARQUITECTURA CLIENTE/SERVIDOR WEB CON BASE DE DATOS.
Fuente: Greenspan y Bulger (2001).
Por su parte, la presente investigación se enfocará en la implementación de la
arquitectura cliente-servidor en aplicaciones Web que utilicen Apache Friends y
Javascript, en dichas aplicaciones sólo hay un cliente y un servidor, los cuales son el
navegador Web del usuario y el Apache Friends respectivamente.
2.7.1. EJECUCIÓN DEL PROCESO CLIENTE/SERVIDOR
Según Musciano y Kennedy (1998), toda actividad Web comienza en el lado del
cliente, cuando un usuario inicia su browser, este comienza a cargar la pagina de inicio
desde cualquier almacenamiento local ó desde un servidor en otra red, como Internet,
45
Capítulo II: Marco Teórico
UNIVERSIDAD RAFAEL URDANETA
una intranet corporativa ó una extranet citadina. En los últimos 4 casos, el navegador
Web consulta primero un servidor DNS para traducir el nombre del servidor en el
documento de la pagina de inicio, como www.oreilly.com, en una dirección IP antes de
enviar una petición a ese servidor en Internet. Esta petición (y la respuesta del servidor)
esta formateada de acuerdo a los dictámenes del estándar de transferencia de
hipertexto (HTTP por sus siglas en inglés).
S
O
D
A
Vestampada
esperando por una petición de documento que E
tenga
la dirección IP única
R
S
E
Rpetición, el servidor verifica que al browser
S
de él mismo. Cuando se recibe
una
O
CH
E
R
demandante se
DleEpermita recibir documentos del servidor Web, y de ser así, busca el
Así mismo, un servidor consume la mayor parte del tiempo “escuchado” a la red,
documento solicitado, si lo encuentra, lo envía al browser. Los servidores usualmente
registran la petición, el nombre de la computadora cliente, el documento pedido y la
hora.
No obstante, de vuelta al servidor, el documento llega al navegador. Los browsers
también archivos binarios del servidor, los cuales con la ayuda de un programa
ayudante ó plug-in que despliegan imágenes, video y sonido en el browser. Finalmente
el navegador termina de estructurar todo el texto y los recursos multimedia en el
ordenador del usuario, y si este, por ejemplo, selecciona un enlace, todo el proceso se
repite desde el comienzo.
46
Capítulo II: Marco Teórico
UNIVERSIDAD RAFAEL URDANETA
2.7.2. NAVEGADOR WEB
Estos programas de aplicación, también conocidos como browsers, son utilizados
para recuperar y visualizar documentos Web escritos en HTML y otros lenguajes Web,
como por ejemplo Javascript. Para Tittel y Burmeister (2005), la pieza del usuario en el
rompecabezas Web es el navegador, estos leen instrucciones escritas en HTML y usan
S
O
D
VA
R
E
S
esas instrucciones para desplegar el contenido de las páginas Web en el monitor y
E
R
S
HO
sistema de audio de las computadoras.
EC
R
E
D APACHE
2.7.3. SERVIDOR
Apache es el servidor HTTP más popular en el mundo, para 2004 era utilizado por
más del 65% de los servidores WWW de Internet, fue desarrollado por el “Apache
Group” en 1995 y según Kabir (1999), Apache procede del código fuente del servidor
NCSA y de una gran colección de parches. Este servidor Web es compatible con las
recientes versiones del sistema operativo Windows ®, todas las versiones de Unix ®,
Linux, Amiga ® y OS/2 ®, además es de libre distribución y código abierto.
Igualmente, Apache soporta los lenguajes PHP y Perl e implementa los protocolos
HTTP 1.0 y HTTP 1.1. Otras características importantes de este servidor Web para
Rosebrock y Wilson (2004) son, hosting virtual basado en nombre y en IP, autenticación
de usuarios, reescritura de URL, Server Side
47
Capítulo II: Marco Teórico
UNIVERSIDAD RAFAEL URDANETA
Include (SSI), logging avanzado, manejadores de variables de entorno, negociación
de contenido, manejadores de CGI y Secure Sockets Layer (SSL). Además Apache
cuenta con un servidor Proxy, registros personalizables y capacidad para registrar las
acciones de los usuarios a través de las cookies HTTP.
3. METODOLOGÍA
3.1. WATCH EXTENDIDA
S
O
D
VA
R
E
S
E
R
S
HO
EC
R
E
La metodología
D Watch Extendida (WE), fue publicada en 2002 por Jonás A. Montilva
y Judith Barrios Albornoz, ambos profesores de la Universidad de los Andes (ULA),
como una extensión del método Watch original creado por Montilva, pero orientada al
desarrollo de aplicaciones Web basadas en componentes de software.
La WE es descrita por medio de tres modelos; el primero de ellos es el modelo del
producto, este se ocupa del diseño de la arquitectura de la aplicación Web; el modelo
del equipo es el segundo de ellos, este se ocupa de organizar a las personas del
proyecto en los equipos de gerencia del proyecto y desarrollo de la aplicación,
indicando los diferentes roles que deben tener las personas en cada equipo; y por
último está el modelo del proceso, el cual integra las actividades de administración y
desarrollo requeridas para producir aplicaciones Web basadas en componentes de alta
calidad. A continuación se explica en detalle cada modelo y como se combinan para
producir una aplicación Web.
48
Capítulo II: Marco Teórico
UNIVERSIDAD RAFAEL URDANETA
3.1.1. EL MODELO DEL PRODUCTO
Un modelo de producto, es una descripción genérica de los elementos que se
encontrarán en la versión final de los productos hechos usando un método. En el caso
de la WE, el modelo de producto esta conformado por tres capas, cada una de las
cuales puede incluir uno ó más niveles. A continuación se describen cada una de estas
S
O
D
VA
R
E
S
capas:
•
E
R
S
Capa de Presentación:
Ola responsable de la interacción con los usuarios, se
HEs
C
E
R y mostrar información o datos desde y hacia el usuario. Esta
Erecibir
encargaD
de
capa tiene dos niveles, uno en el que van los componentes del lado del cliente
(Javascript, Java Applets, controles Active X entre otros) y el otro para los
componentes del lado del servidor (PHP, ASP, JSP, ISAPI, CGI, ect.).
•
Capa de Lógica de Negocios: Está compuesta por los componentes de
procesos de negocio y los componentes de entidades de negocio, los primeros
se encargan de manejar los servicios ó transacciones pedidas por los usuarios a
través de la interfaz de usuario, los últimos representan la información que debe
ser guardada por la aplicación en la Base de Datos o en los sistemas de
almacenamiento de datos en XML.
•
Capa de Datos: Se encarga de administrar el almacenamiento de los datos de
las entidades de negocio en la base de datos y/o en los sistemas de
almacenamiento de datos en XML.
49
Capítulo II: Marco Teórico
UNIVERSIDAD RAFAEL URDANETA
FIGURA 2. ESTRUCTURA GENERAL DEL MODELO DEL PRODUCTO DE LA
WATCH EXTENDIDA.
Fuente: Barrios y Montilva (2002).
S
O
D
VA
R
E
S
E
R
S
3.1.2. EL MODELO DEL EQUIPO
HO
C
E
DER
El modelo del equipo en la WE ayuda a repartir las responsabilidades entre las
personas del proyecto de aplicación Web. La WE define seis roles que se describen a
continuación:
•
Gerente del Proyecto/ Líder del Equipo: Este rol tiene asociada la
responsabilidad de planear, organizar, dirigir, supervisar y controlar el proceso de
desarrollo de la aplicación.
•
Representante de los usuarios / Usuario Embajador: Le da al proyecto el
conocimiento acerca del negocio o dominio de la aplicación. Provee los
requerimientos de la aplicación y actúa como un puente entre el equipo de
desarrollo y la comunidad de usuarios.
50
Capítulo II: Marco Teórico
UNIVERSIDAD RAFAEL URDANETA
•
Desarrollador de la Aplicación / Desarrollador Principal: Interpreta y modela
los requerimientos de los usuarios y usa destrezas técnicas para diseñar y
evaluar arquitecturas de aplicación y sus componentes.
•
Desarrollador Web: Su responsabilidad es especificar, diseñar y desarrollar
interfaces Web para los usuarios de la aplicación.
•
Desarrollador de Componentes de Negocio: Modela e Interpreta los
S
O
D
VA
integrar, probar y desarrollar componentesE
deR
negocio.
S
E
R
OS de Datos: Se encarga de modelar e interpretar
Desarrollador de Componentes
H
C
E
R
E
D
los requerimientos de data y usa destrezas técnicas para diseñar, crear, integrar
requerimientos de negocio y usa destrezas técnicas para diseñar, codificar,
•
y evaluar bases de datos.
En el caso particular de la presente investigación, el mismo investigador jugó todos
los roles, a excepción del de representante de los usuarios, el cual estuvo a cargo del
gerente de consultoría de la empresa cliente (Cibiz S.A.).
3.1.3. EL MODELO DEL PROCESO.
Lo primero que se advierte en este modelo, es que el mismo agrupa los procesos
que se llevan a cabo en el proyecto de creación de software en dos grandes grupos, los
procesos de gestión y de desarrollo. En la siguiente tabla se muestran los procesos que
conforman cada grupo.
51
Capítulo II: Marco Teórico
UNIVERSIDAD RAFAEL URDANETA
Procesos de Gestión
Procesos de Desarrollo
- Gestión del proyecto
- Modelado de negocios
- Calidad del software
- Definición de requerimientos
-Gestión de la configuración del -Diseño de la arquitectura de la
software
aplicación
- Verificación y validación
- Especificación de componentes
- Control de riesgos
- Aprovisionamiento de componentes
- Entrenamiento de personal
- Ensamblaje de componentes
S
O
D
A
V
- Entrega
de la aplicación
R
E
S
E
R
S
- Pruebas
HO
C
E
TABLA 1. ESTRUCTURA
DER DEL MODELO DEL PROCESO DE LA WATCH EXTENDIDA.
Fuente: Barrios y Montilva (2002).
Los creadores de la WE, Barrios y Montilva, usaron la metáfora de un reloj (Watch
en inglés significa reloj de pulsera), para diseñar la estructura y dinámica de la
metodología. Aplicando esta metáfora, el desarrollo de una aplicación Web puede ser
visto como un reloj cuyas agujas son movidas por el gerente del proyecto, el cual
haciendo uso de los procesos de gestión, más que todo de los de verificación y
validación de cada versión nueva del software o los informes de progreso del mismo,
decide si se necesita volver a una fase anterior para corregir errores o añadir elementos
a un producto de dicha fase, ó si por el contrario se avanza a la siguiente etapa de
desarrollo; por ello se dice que esta metodología puede llegar a ser muy iterativa. Es
importante señalar, que los procesos de desarrollo están representados por el dial de
52
Capítulo II: Marco Teórico
UNIVERSIDAD RAFAEL URDANETA
las horas del reloj. A continuación se muestra un grafico que ilustra el modelo del
proceso de la metodología Watch Extendida.
S
O
D
VA
R
E
S
E
R
S
HO
EC
R
E
D
FIGURA 3. EL MODELO DEL PROCESO DE LA WATCH EXTENDIDA.
Fuente: Barrios y Montilva (2002).
El desarrollo de una aplicación Web comienza con los procesos de iniciación y
planeamiento del proyecto, además de la organización de las personas involucradas en
53
Capítulo II: Marco Teórico
UNIVERSIDAD RAFAEL URDANETA
el mismo; estos claramente son los primeros procesos de gestión que se ejecutan.
Luego comienzan los procesos de desarrollo, y el primero que se realiza es el modelado
de negocios; las demás actividades de este tipo son realizadas después en orden
secuencial bajo el control de los procesos de verificación y validación.
4. DEFINICIÓN DE TÉRMINOS BÁSICOS
S
O
D
VA
R
E
S
Algebra Relacional: Lenguaje formal con una serie de operadores que trabajan sobre
E
R
S
HO
una o varias relaciones para obtener otra relación resultado, sin que cambien las
EC
R
E
D
relaciones originales. Tanto los operandos como los resultados son relaciones, por lo
que la salida de una operación puede ser la entrada de otra operación (Marqués 2001).
API: Una API (del inglés Application Programming Interface - Interfaz de Programación
de Aplicaciones) es un conjunto de especificaciones de comunicación entre
componentes software. Se trata del conjunto de llamadas al sistema que ofrecen
acceso a los servicios del sistema desde los procesos y representa un método para
conseguir abstracción en la programación, generalmente (aunque no necesariamente)
entre los niveles o capas inferiores y los superiores del software.
Cálculo Relacional: En contraste con el álgebra relacional, el cálculo es un lenguaje de
consulta no procedural, esto es, describe la información deseada sin indicar el proceso
de su obtención.
54
Capítulo II: Marco Teórico
UNIVERSIDAD RAFAEL URDANETA
CGI: Common Gateway Interface (en castellano Interfaz Común de Pasarela) es una
importante tecnología de la World Wide Web que permite a un cliente (explorador Web)
solicitar datos de un programa ejecutado en un servidor Web. CGI especifica un
estándar para transferir datos entre el cliente y el programa.
Cookies: Fragmento de información que se almacena en el disco duro del visitante de
S
O
D
VenAposteriores visitas.
información puede ser luego recuperada por el servidor
R
E
S
E
R
OS
H
C
E
ERen
CSS: Hojas de
cascada (Cascading Style Sheets o CSS) son un lenguaje
Destilo
una página Web a través de su navegador, a petición del servidor de la página. Esta
formal usado para definir la presentación de un documento estructurado escrito en
HTML o XML, y por extensión en XHTML.
DBMS: Database Management System ó sistema de gestión de base de datos, es
sinónimo de sistema gestor de base de datos (Silberschatz y otros 2006).
DNS: Es una base de datos distribuida y jerárquica que almacena información asociada
a nombres de dominio en redes como Internet.
Formulario ó Formulario Web: Conjunto de campos (espacios) para introducir datos
en una página Web. Un formulario permite a los usuarios escribir información que se
envía al servidor Web después de pulsar un botón.
55
Capítulo II: Marco Teórico
UNIVERSIDAD RAFAEL URDANETA
Formulario Web Congelado: Es un formulario en el cual no es posible modificar los
datos de los campos, es decir, sólo se muestran los valores de los campos y se usan
para reportar el procesamiento exitoso de una operación de un formulario.
Frame: En diseño de páginas Web, opción que ofrece el lenguaje HTML de dividir una
S
O
D
A un frame
Vasimismo
independiente de las demás de forma que cada zona
es
R
E
S
E
R
OS
H
C
GNU: Acrónimo recursivo
E que significa “GNU is not Unix”, el cual se usa para indicar
DER
página Web en varias zonas. Cada una de las cuales puede tener un contenido
que el software desarrollado por la General Public license no tiene que ver con el
sistema operativo Unix.
GNU GPL: La GNU GPL (General Public License o licencia pública general) es una
licencia creada por la Free Software Foundation a mediados de los 80, y está orientada
principalmente a proteger la libre distribución, modificación y uso de software. Su
propósito es declarar que el software cubierto por esta licencia es software libre y
protegerlo de intentos de apropiación que restrinjan esas libertades a los usuarios.
Hosting: Servicio de alojamiento de las páginas Web que gestionan empresas
especializadas.
HTTP: HyperText Transfer Protocol o protocolo de transferencia de hipertexto, es el
protocolo usado en cada transacción de la Web (WWW). El hipertexto es el contenido
56
Capítulo II: Marco Teórico
UNIVERSIDAD RAFAEL URDANETA
de las páginas Web, y el protocolo de transferencia es el sistema mediante el cual se
envían las peticiones de acceso a una página y la respuesta con el contenido. También
sirve el protocolo para enviar información adicional en ambos sentidos, como
formularios con campos de texto (Fidalgo 2007).
Just in Time: Término inglés que significa Justo a tiempo. Es un sistema originado en
Japón para la organización de la producción en las fábricas.
S
O
D
VA es un movimiento en el
Opensource: Termino inglés que significa código
abierto,
R
E
S
E
R
mundo del software cuyo objetivo
OesS poner a libre disposición el código fuente de los
H
C
E
R
E
D
programas, esta palabra suele confundirse con freeware y no significan lo mismo
(González 2007).
Parche ó Plug-in: Modificación llevada a cabo en un programa informático con el
propósito de sustituir una parte del código y así eliminar un error en su programación o
añadir mas funcionalidad (Montenegro 2004).
Script: Serie de instrucciones que permite realizar tareas sencillas y repetitivas,
generalmente son interpretados en tiempo de ejecución, aunque hay sistemas que
permiten compilarlos. Algunos de los sistemas de scripts son verdaderos lenguajes de
programación (Pfaffenberger 2000).
Scripting: En general, subconjunto de los lenguajes de programación que forman los
lenguajes interpretados (Van Der Vlist 2006).
57
Capítulo II: Marco Teórico
UNIVERSIDAD RAFAEL URDANETA
SSI: Server Side Includes, son comentarios especiales dentro de paginas HTML que,
cuando son leídas por el servidor realizan acciones especiales.
URL: Acrónimo de Universal Resource Locator (Localizador Universal de Recursos).
Sistema unificado de identificación de recursos en la red. Es el modo estándar de
proporcionar la dirección de cualquier recurso o página en Internet.
S
O
D
VAeditores de texto con formato
este término se aplica a los procesadores de texto
yR
otros
E
S
E
R
S escribir un documento viendo directamente
(como los editores de HTML)H
que
Opermiten
C
E
R
E
D
el resultado final ó real. (González 2007).
WYSIWYG: Acrónimo de What You See Is What You Get (lo que ve es lo que obtiene),
5. SISTEMA DE VARIABLES E INDICACDORES
5.1. CUADRO DE OPERACIONALIZACIÓN DE VARIABLES
Objetivo General: Desarrollar una extranet para la automatización de los
procesos de gestión de los consultores de la empresa Consulting & Information
for Business S.A.
Objetivos Específicos
Variable
Sub-Variable
Indicadores
Identificar
los
requerimientos para el
desarrollo
de
una
extranet
para
la
-Funcionalidades
automatización de los
Extranet
Requerimientos
-Interfaz con el
procesos de gestión de
usuario
los consultores de la
empresa Consulting &
Information for Business
S.A.
58
Capítulo II: Marco Teórico
UNIVERSIDAD RAFAEL URDANETA
Objetivos Específicos
Analizar
los
requerimientos
identificados
para
realizar el diseño de la
extranet
para
la
automatización de los
procesos de gestión de
los consultores de la
empresa Consulting &
Information for Business
S.A.
Variable
Ejecutar pruebas de
funcionamiento a la
extranet
para
la
automatización de los
procesos de gestión de
los consultores de la
empresa Consulting &
Information for Business
S.A.
Indicadores
Diseño
-Modelo Relacional
de la BD
-Interfaz grafica de
usuario
-Módulos de la
aplicación
-Permisos de usuario
-Implementación de
la aplicación
S
O
D
VA
R
E
S
E
R
S
HO
EC
R
E
D
Elaborar la extranet
para la automatización
de los procesos de
gestión
de
los
consultores
de
la
empresa Consulting &
Information for Business
S.A.
Sub-Variable
Extranet
Extranet
Operativa
Pruebas de
funcionamiento
-Esquema de la BD
-Código de la
aplicación
-Ensamblaje de los
módulos
-Operacionalización
de la aplicación
-Pruebas unitarias
OS
D
A
RV
E
S
E
SR
O
H
C
E
R
DE
CAPÍTULO III
MARCO METODOLÓGICO
Capítulo III: Marco Metodológico
UNIVERSIDAD RAFAEL URDANETA
CAPITULO III
MARCO METODOLÓGICO
En este capitulo se explica el tipo, diseño, población, muestra, metodología y técnica
S
O
D
VA
R
E
S
utilizada en la obtención de datos e información durante la realización del presente
estudio.
E
R
S
HO
EC
R
E
D
1. TIPO DE INVESTIGACION
Para determinar a que tipo de investigación correspondía el presente trabajo, se
consultaron diversos autores, los cuales tenían diferentes criterios de clasificación para
las investigaciones. A continuación se explica cada uno de estos enfoques.
Para Zorrilla (1993), la presente obra es de tipo aplicada según el grado de
abstracción ó propósito de la investigación, ya que el desarrollo de una extranet para la
automatización de los procesos de gestión de los consultores de la empresa Consulting
& Information for Business S.A. (Cibiz), trajo como consecuencia la aplicación y
utilización práctica de conocimientos, lo cual para el mencionado autor, constituye una
característica de los estudios aplicados.
Por otra parte, según Fernández, Hernández y Baptista
(2006), la presente
investigación es de tipo descriptiva desde el punto de vista del alcance del estudio,
60
61
Capítulo III: Marco Metodológico
UNIVERSIDAD RAFAEL URDANETA
porque al recolectar y analizar los datos necesarios para desarrollar una extranet para
automatizar los procesos de gestión de los consultores de Cibiz, se buscó “especificar
las propiedades, las características, y los perfiles de personas, grupos, comunidades,
procesos, objetos ó cualquier otro fenómeno”. En un estudio descriptivo se selecciona
una serie de entidades y se mide o recolecta información sobre cada una de ellas, para
así (valga la redundancia) describir el objeto de estudio.
S
O
D
VA
R
E
S
E
R
S
HO
2. DISEÑO DE LA INVESTIGACIÓN
EC
R
E
Según Fernández
D et all (2006), el diseño utilizado en la realización de la presente
investigación es de tipo no-experimental transaccional descriptivo. No-experimental,
porque a lo largo del estudio no se hizo variar intencionalmente ninguna variable
independiente para ver su efecto sobre otras variables; y transaccional descriptivo,
debido a que la recolección de datos se ejecuto en un periodo de tiempo muy corto, con
el objetivo de medir las modalidades ó niveles de una ó más variables en la población,
tal como se hizo con la recolección de información acerca de los procesos de gestión de
los consultores de Cibiz para luego poder automatizarlos a través de una extranet.
3. POBLACIÓN Y MUESTRA
Chávez (1998), define población como el conjunto total de los entes a observar, en
otras palabras, es el universo de la investigación, sobre el cual se pretende aplicar los
62
Capítulo III: Marco Metodológico
UNIVERSIDAD RAFAEL URDANETA
resultados. Por otra parte, Fernández et all (2006), definen muestra como un
subconjunto representativo de la población del cual se recolectan los datos. En lo
referente al presente estudio, tanto la población como la muestra estuvieron
conformadas por el gerente de consultoría de Cibiz S.A., debido a que él encarnó el rol
de de representante de los usuarios, el cual en la metodología usada, una adaptación
de la Watch Extendida al proceso de desarrollo con el lenguaje PHP, es la única
S
O
D
VA
R
E
S
persona responsable de indicarle al equipo de desarrollo los requerimientos de la
aplicación.
E
R
S
HO
EC
R
E
D UTILIZADA PARA EL DESARROLLO DE LA EXTRANET
4. METODOLOGIA
La metodología empleada en el desarrollo de la extranet para la automatización de
los procesos de gestión de los consultores de la empresa Consulting & Información for
Business S.A. (Cibiz), fue una adaptación de la metodología para el desarrollo de
aplicaciones Web Watch Extendida (WE), al proceso de desarrollo con el lenguaje PHP.
Fue necesario adaptar la WE al proceso de desarrollo con PHP, porque este último
no es un lenguaje en el que se facilita el desarrollo basado en componentes (DBC),
principal característica de la WE. Para implementar dicha filosofía de desarrollo con
PHP, se requería un 50% más de tiempo para culminar el proyecto, tiempo que el
cliente no podía esperar. Otros lenguajes para la elaboración de aplicaciones Web
como ASP de Microsoft, ofrecen más comodidades para el DBC, pero no se usó porque
la compra de la licencia no podía ser cubierta por el presupuesto destinado al proyecto.
63
Capítulo III: Marco Metodológico
UNIVERSIDAD RAFAEL URDANETA
En consecuencia, la extranet tuvo que elaborarse con PHP y mediante una adaptación
de la WE no basada en componentes previa aprobación del cliente.
Los motivos por los cuales se eligió adaptar la metodología WE al proceso de
desarrollo con PHP, fue por la integridad que la WE original ofrecía (no sólo explica los
pasos a seguir para desarrollar la aplicación, también muestra como deben repartirse
las responsabilidades entre el personal del proyecto y ayuda en el diseño de la
S
O
D
VA tipo, como la de Pressman
elaboración de la extranet que otras metodologías
del
mismo
R
E
S
E
R
S las modificaciones hechas a la WE original y
o la HMMOD. A continuaciónH
seO
nombran
C
ERE
el porque de las
Dmismas.
arquitectura del sistema) y porque dicha adaptación resultó ser más apropiada para la
•
El proceso de gestión llamado entrenamiento del personal de desarrollo, no se
llevó a cabo porque el desarrollador del sistema dominaba con anterioridad al
comienzo de la investigación las tecnologías necesarias para el desarrollo de la
extranet.
•
La finalidad del modelado de negocio es elaborar un documento con el dominio
del negocio del cliente, para que además de los responsables de modelar los
requerimientos, los miembros del equipo de desarrollo también entiendan el
entorno del sistema que se desarrollará. Pero como en el caso de la presente
investigación una misma persona se encargó de modelar los requerimientos y de
desarrollar la extranet, no hizo falta llevar a cabo la mencionada fase.
•
En la fase de especificación de requerimientos, no se elaboraron los diagramas
de clase ni los de secuencia, porque tales construcciones del UML, aplican sólo a
64
Capítulo III: Marco Metodológico
UNIVERSIDAD RAFAEL URDANETA
sistemas elaborados con programación orientada a objetos (POO), y como PHP
aún no soporta completamente la POO, la misma no fue utilizada para codificar
la aplicación, en lugar de ello se utilizó la programación estructurada.
•
No se llevó a cabo la fase de especificación de componentes, porque como se
dijo anteriormente, el desarrollo de la extranet de Cibiz S.A. no estuvo basado en
dicho paradigma de desarrollo.
•
S
O
D
A
R
de código, y abarcó las mismas actividades
de
laV
primera, pero en el ámbito de la
E
S
E
R
OS
programación estructurada.
Lo mismo sucedió con la fase de ensamblado de
H
C
E
DERcuyo nuevo nombre fue fase de integración de código, y fue
componentes,
La fase de implementación de componentes pasó a llamarse fase de elaboración
ejecutada paralelamente a la fase de elaboración de código. Las pruebas de
integración realizadas al sistema se explicaron en el plan de verificación y
validación.
•
La fase de entrega de la aplicación Web fue ejecutada hasta la actividad de
instalación y prueba de la aplicación en su entorno operacional, porque al subir el
código realizado al Web hosting durante la integración de código, de hecho se
estaba instalando la aplicación (más específicamente se trató de una instalación
paralela a la codificación), y al ejecutar las pruebas de integración, se estaba
probando el sistema en su entorno operacional.
65
Capítulo III: Marco Metodológico
UNIVERSIDAD RAFAEL URDANETA
5. TÉCNICAS PARA LA RECOLECCIÓN DE DATOS
Durante la captura de requerimientos y las pruebas de validación llevadas a cabo en
el desarrollo de la extranet de Cibiz S.A., se utilizó la entrevista no estructurada
semidirigida como técnica de recolección de datos. Para Campenhoudt (1998), esta
variante de la entrevista no es ni enteramente abierta, ni se canaliza mediante un gran
S
O
D
VA imperativo que reciba una
guía, relativamente abiertas a propósito de las cuales
resulta
R
E
S
E
R
información por parte del entrevistador.
OS Pero no planteará forzosamente todas las
H
C
ERenEel que las ha anotado y con el plan previsto.
preguntas en el
Dorden
número de preguntas precisas, el investigador dispone de una serie de preguntas -
En el presente estudio fue posible llevar a cabo un censo poblacional, porque la
población y al mismo tiempo muestra de la investigación estuvo conformada por una
sola persona, el gerente de consultoría de Cibiz S.A., a quien se le asignó el rol de
representante de los usuarios en la metodología usada, una adaptación de la Watch
Extendida al proceso de desarrollo con PHP.
OS
D
A
RV
E
S
E
SR
O
H
C
E
R
DE
CAPÍTULO IV
ANÀLISIS E INTERPRETACIÓN DE LOS RESULTADOS
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
CAPÍTULO IV
ANÀLISIS E INTERPRETACIÓN DE LOS RESULTADOS
En el presente capítulo se muestran y explican los resultados obtenidos de la
S
O
D
VA
R
E
S
aplicación de la metodología usada para la solución del problema.
E
R
S
HO
EC
R
E
D
1. MODELO DEL PRODUCTO
Como se mencionó en el marco metodológico, un modelo de producto en la
adaptación de la Watch Extendida al proceso de Desarrollo con PHP (WEPHP), esta
compuesto por la capa de presentación, la capa de lógica de negocios y la capa de
datos. A continuación, se describe en detalle cada una de las tecnologías usadas en
dichas capas.
67
68
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
S
O
D
VA
R
E
S
E
R
S
HO
EC
R
E
D
FIGURA 4. EL MODELO DE PRODUCTO DE LA EXTRANET PARA LA
AUTOMATIZACIÓN DE LOS PROCESOS DE GESTIÓN DE LOS CONSULTORES DE
LA EMPRESA CIBIZ S.A.
Fuente: Ramos (2008).
1.1. CAPA DE PRESENTACIÓN
Esta capa está compuesta por dos partes, la de los componentes del lado del cliente
y la de los componentes del lado del servidor. En la primera de ellas se usaron páginas
HTML con imágenes en formato bmp, jpeg y gif, así como hojas de estilo en cascada y
código Javascript (tanto embebido en los documentos HTML como en archivos externos
a los mismos). Por otra parte, los componentes de la capa de presentación utilizados
del lado del servidor fueron las plantillas Smarty
TM
y la biblioteca PEAR. Cabe señalar
que todo el código desarrollado con las tecnologías mencionadas funciona
69
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
perfectamente en los navegadores Mozilla Firefox 2.x e Internet Explorer 6 y 7, lo cual
representa más del 85% de los navegadores usados a nivel mundial para finales de
Marzo de 2008.
1.2. CAPA DE LÓGICA DE NEGOCIOS
S
O
D
componentes de entidades de negocio, para ambos tipos
de componente se usó
VA
R
E
ES DB, HTML y PhpDocumentor de la
el lenguaje PHP versión 5.2.4 y S
los R
paquetes
HO
C
E
biblioteca PEAR versión
DER 1.4.
Esta capa está formada por los componentes de procesos de negocio y los
1.3. CAPA DE DATOS
Para la capa de datos se usó el sistema de gestión de bases de datos MySQL
versión 5.0.45, con el motor de almacenamiento MyISAM para las tablas.
2. MODELO DEL EQUIPO
En el desarrollo de la extranet para la automatización de los procesos de gestión de
los consultores de la empresa Cibiz S.A., fue necesario distribuir el trabajo entre los
roles de líder del proyecto, representante de los usuarios, desarrollador de la aplicación,
desarrollador Web, desarrollador de componentes de negocio y desarrollador de
componentes de datos, es decir, todos los roles básicos de la WEPHP, esto debido a
70
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
que el tamaño y los requerimientos del proyecto no precisaron la definición de más
roles. El único rol que no fue desempeñado por el investigador fue el de representante
de los usuarios, el cual estuvo a cargo del gerente de consultoría de Cibiz S.A. La
jerarquía entre los distintos roles del modelo se puede apreciar en la figura 4.2.
S
O
D
VA
R
E
S
E
R
S
HO
EC
R
E
D
FIGURA 5. EL MODELO DE EQUIPO DE LA EXTRANET PARA LA
AUTOMATIZACIÓN DE LOS PROCESOS DE GESTIÓN DE LOS CONSULTORES DE
LA EMPRESA CIBIZ S.A.
Fuente: Ramos (2008).
3. MODELO DEL PROCESO
El modelo del proceso de la WEPHP está conformado por dos grandes grupos de,
precisamente procesos, como lo son los procesos de gestión y los de desarrollo. A
continuación se describirá en detalle los resultados obtenidos en cada una de las
actividades relacionadas con dichos procesos.
71
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
3.1. PROCESOS DE GESTIÓN
La metodología WEPHP tiene 5 procesos de gestión, cada uno de los cuales se
ejecuta paralelamente a las fases de desarrollo. Tales procesos se encargan de la
gestión del proyecto (el cual corresponde a la suma de todos los demás procesos de
gestión), gestión de la configuración del software, calidad del software, verificación y
S
O
D
detalladamente los lineamientos seguidos en la ejecución
VAde cada uno de los procesos
R
E
S
E
R
antes mencionados.
OS
H
C
E
DER
validación del software y gestión de riesgos del proyecto. A continuación, se explicaran
3.1.1. GESTIÓN DE CALIDAD DEL SOFTWARE
Debido a la simplicidad de los requerimientos de la extranet, las tareas implicadas en
la gestión de calidad del software se limitaron a aquellas que propone la metodología
WEPHP para tal fin, a saber, el perfecto desempeño del sistema en las pruebas de
implementación de los requisitos funcionales y no funcionales, y en las pruebas de
aceptación.
3.1.2. GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARE
La gestión de configuración del software (SCM por sus siglas en inglés), son todas
aquellas actividades involucradas en el control de versiones de los archivos y
documentos no sólo del sistema en sí, sino también a otros aspectos del mismo como
72
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
los requerimientos, diseño, pruebas y documentación. La SCM también se encarga del
control de versiones de los documentos de planificación y gestión del proyecto de
elaboración del sistema. A continuación se explica el plan para el control de la
configuración del software, así como los procedimientos de cambio de versión
ejecutados.
S
O
D
VA
R
E
S
3.1.2.1. PLAN PARA EL CONTROL DE LA CONFIGURACIÓN DEL SOFTWARE
E
R
S
HO
A causa de que todos los roles en los que se organizó el equipo de desarrollo de la
EC
R
E
D
extranet fueron encarnados por el investigador, él fue el responsable de la gestión de
configuración del software. Por otra parte, los elementos a los cuales se les aplicó la
SCM fueron los siguientes:
•
Documento de definición de requerimientos.
•
Documento de especificación de requerimientos.
•
Documento de diseño de la aplicación.
•
Los archivos de código fuente de PHP, SMARTY y Javascript.
•
El archivo de configuración “php.ini”.
•
Los archivos de hojas de estilo en cascada.
•
Las imágenes empleadas en la interfaz de usuario.
•
Los nombres de los directorios donde se guardan los archivos de código fuente.
•
El plan de verificación y validación del sistema.
73
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
•
Los documentos de diseño y resultados de las pruebas de funcionalidades,
desempeño y aceptación.
El seguimiento de los cambios hechos a cualquiera de estos ítems, se llevó a cabo
registrando dichos cambios en un documento. Por otra parte, no fue necesario llevar un
control de archivos compilados porque la única tecnología usada que genera este tipo
S
O
D
VA
R
E
S
de archivos (las plantillas SMARTY) los actualiza con cada solicitud de página.
E
R
S
HO
Para nombrar todos aquellos documentos que no formaban parte del sistema en sí
EC
R
E
D
(archivos de Microsoft Word para la planificación, requerimientos y diseño del sistema),
se escribía primero el nombre del documento, seguido de la fecha y hora de creación ó
actualización del mismo. Para expresar la fecha, se utilizaba una cadena de seis dígitos
decimales en donde los dos primeros dígitos correspondían al día del mes, los dos
dígitos del medio correspondían al mes del año, y los últimos dos dígitos indicaban el
año, luego se agregaba un espacio en blanco y se indicaba la hora con otra cadena,
pero de 4 dígitos decimales, en la cual los dos primeros dígitos indicaban la hora en
formato de 24 horas, y los últimos dos indicaban los minutos. Este procedimiento no se
aplicó a los archivos que componen la extranet, porque el servidor donde están alojados
guarda y muestra la fecha y hora de creación, actualización y último acceso de todos
los archivos automáticamente.
74
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
3.1.2.2. PROCEDIMIENTO DE CAMBIO DE VERSIÓN.
Cuando se hacía una modificación en cualquiera de los elementos sujetos a la SCM,
se verificaba que otros elementos se relacionaban con él y se procedía a la
actualización de los mismos. Si la actualización de un elemento no podía llevarse a
cabo inmediatamente, se anotaba dicha tarea como pendiente en la agenda del
proyecto. Finalmente, cada vez que se completaba la actualización de un elemento, se
S
O
D
VA
R
E
S
procedía a registrarla en el historial de cambios.
E
R
S
HO
EC
R
E
D
3.1.3. PLAN DE VERIFICACIÓN Y VALIDACIÓN DEL SOFTWARE.
En el desarrollo de la extranet de Cibiz S.A., se realizaron pruebas de verificación de
software de varios tipos (funcionamiento e integración), usando múltiples técnicas (caja
blanca, caja negra e inspecciones), y en diferentes entornos (distintos navegadores,
computadoras, sistemas operativos y redes). También se hicieron pruebas de
verificación de los casos de uso mediante la inspección de los mismos. Por otra parte,
las pruebas de validación de la funcionalidad e interfaces de usuario se llevaron a cabo
cuando se terminaban todos los módulos pertenecientes a una misma área (por
ejemplo, los módulos de registro, actualización y visualización de los datos de las
empresas clientes). Además, cada vez que un caso de uso era modificado por un error
encontrado ó para mejorar la usabilidad del sistema, igualmente era sometido a
validación por parte del representante de los usuarios.
75
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
3.1.4. GESTIÓN DE RIESGOS.
Todos los riesgos fueron identificados en el planeamiento del proyecto. Es
importante señalar que durante el desarrollo del sistema la probabilidad e impacto (y por
ende prioridad) de cada riesgo no varió. A continuación se ilustran tres tablas, en la
primera se declaran los riesgos, la segunda muestra los valores de probabilidad,
impacto, exposición y otros datos de importancia correspondientes a cada uno de los
S
O
D
VA
R
E
S
riesgos; finalmente la tercera de las tablas presenta los planes de mitigación y
E
R
S
HO
contingencia planeados para cada riesgo.
EC
R
E
D
ID Causa Raíz
Estado
Consecuencia
1 Planificación El proyecto es más Posiblemente no se
grande de lo que se pueda terminar el
estimó.
proyecto antes de la
fecha de entrega.
2 Planificación La fecha acordada Posiblemente no se
de
entrega
del pueda terminar el
sistema
es
muy proyecto antes de la
temprana.
fecha de entrega.
3 Planificación El cliente ha hecho La
planificación
más cambios en los temporal del proyecto
requerimientos de lo puede sufrir retrasos.
previsto.
4 Tecnología
La biblioteca PEAR El
equipo
de
tiene bugs.
desarrollo
invertirá
tiempo
en
crear
parches
para
los
bugs.
Efecto de la Causa
Insatisfacción
del
cliente.
Insatisfacción
cliente.
del
Aumento
en
la
cantidad de recursos
necesarios
para
culminar el sistema.
Atrasos
en
el
desarrollo
del
sistema.
TABLA 2. DECLARACIÓN DE LOS RIESGOS IDENTIFICADOS.
Fuente: Ramos (2008).
76
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
ID Prioridad Probabilidad Impacto Exposición Clasificación
1
1
6
4
24
TP
2
2
3
4
12
TP
3
3
3
4
12
CL
4
4
3
3
9
TE
TABLA 3. VALORES DE LAS VARIABLES ASOCIADAS A LOS RIESGOS.
Fuente: Ramos (2008).
ID
Plan de Mitigación
1 1.Identificar los requerimientos lo
mejor posible.
2.Planear el desarrollo de cada
módulo del sistema hasta el nivel
de las tareas que se deben llevar a
cabo para completarlo.
2 1.Hacer un cálculo realista del
tiempo necesario para llevar a cabo
el proyecto, tomando en cuenta
todos los factores que puedan
retrasar su culminación.
3 1.Identificar los requerimientos los
mejor posible.
2.Implementar los requerimientos
del cliente a cabalidad.
3.Diseñar pruebas de validación
completas.
4.Elaborar
constancias
de
aprobación del cliente para cada
prueba
de
validación
completamente superada.
4 1.Leer semanalmente la lista de
bugs en el sitio Web de PEAR, para
no usar las librerías defectuosas ó
implementar soluciones para dichos
defectos a tiempo.
Plan de Contingencia
1.Trabajar 10 horas al día,
incluyendo los Domingos,
hasta ir a la par con la
planificación temporal del
proyecto.
Responsable
Gerente del
proyecto.
1.Trabajar 10 horas al día,
incluyendo los Domingos,
hasta ir a la par con la
planificación temporal del
proyecto.
1.Trabajar 10 horas al día,
incluyendo los Domingos,
hasta ir a la par con la
planificación temporal del
proyecto.
Gerente del
proyecto.
S
O
D
VA
R
E
S
E
R
S
HO
EC
R
E
D
Gerente del
proyecto.
1.Trabajar 10 horas al día, Desarrollador
incluyendo los Domingos, Principal.
hasta ir a la par con la
planificación temporal del
proyecto.
TABLA 4. PLANES DE MITIGACIÓN Y CONTINGENCIA DE LOS RIESGOS.
Fuente: Ramos (2008).
77
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
Los riesgos que llegaron a manifestarse fueron “El proyecto es más grande de lo
que se estimó” y ” La fecha acordada de entrega del sistema es muy temprana”, que
tienen asignado los identificadores 1 y 2 respectivamente. Los planes de contingencia
elaborados para cada uno de estos riesgos demostraron ser efectivos, por lo cual no fue
necesario modificarlos. A continuación se presentan dos tablas más con las escalas de
valor cualitativa y cuantitativa utilizadas para estimar los valores de probabilidad e
S
O
D
el significado de las abreviaturas usadas en el campoV
deAclasificación del riesgo de la
R
E
S
E
R
misma tabla.
OS
H
C
Escala Cualitativa
Escala Cuantitativa
ERE
Rango de
DProbabilidad
impacto de los riesgos que se muestran en la tabla 4.2, también se ilustra otra tabla con
De 1% a 14%
De 15% a 28%
De 28% a 42%
De 43% a 57%
De 58% a 72%
De 73% a 86%
De 87% a 99%
(Lenguaje Natural)
Muy poco probable
Baja
Probablemente no
50-50
Probable
Altamente probable
Casi seguro
(Valor Numérico)
1
2
3
4
5
6
7
TABLA 5. ESCALAS CUALITATIVA Y CUANTITATIVA USADAS PARA ESTIMAR LA
PROBABILIDAD DE LOS RIESGOS.
Fuente: Ramos (2008).
Escala Cualitativa
(Lenguaje Natural)
Bajo
Medio
Alto
Critico
Atraso en la
planificación
temporal
Una semana
Dos semanas
Un mes
Más de un mes
Escala Cuantitativa
(Valor Numérico)
1
2
3
4
TABLA 6. ESCALAS CUALITATIVA Y CUANTITATIVA USADAS PARA ESTIMAR EL
IMPACTO DE LOS RIESGOS.
Fuente: Ramos (2008).
78
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
Abreviatura
Significado
CL
Riesgo relativo al cliente
TE
Riesgo relativo a la tecnología
TP
Riesgo relativo al tamaño del proyecto
TABLA 7. SIGNIFICADO DE LAS ABREVIATURAS USADAS PARA CLASIFICAR LOS
RIESGOS.
Fuente: Ramos (2008).
3.2. PROCESOS DE DESARROLLO
S
O
D
A
V
R
E
La metodología WEPHP consta de 6E
fases
S de desarrollo, de las cuales fueron
R
OS
ejecutadas 5, la fase queC
noH
se llevó a cabo fue la de modelado de negocios, porque
E
DER
como el mismo investigador se encargó de reunirse con el representante de los
usuarios para identificar los requerimientos, y a la vez de desarrollar la aplicación, no
fue necesario elaborar un documento de modelado de negocios para que el equipo de
desarrollo entendiera mejor los requerimientos. A continuación se muestran los
resultados de las fases que se implementaron.
3.2.1. DEFINICIÓN Y ESPECIFICACIÓN DE REQUERIMIENTOS
Como se puede deducir a partir del título, esta fase a su vez se subdivide en otras
dos, la de definición de requerimientos y la de especificación de requerimientos. En la
primera de las fases se producen los casos de uso del sistema, luego de que el
encargado de la toma de requerimientos (aquel en el grupo de desarrollo que el gerente
haya elegido para ese fin) se reúna varias veces con el representante de los usuarios.
79
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
En la segunda subfase, el encargado de la toma de requerimientos realiza los
diagramas de caso de uso correspondientes a los casos de uso tomados en la
definición de requerimientos. A continuación se presentan los resultados obtenidos en
cada una de las mencionadas subfases.
3.2.1.1. DEFINICIÓN DE REQUERIMIENTOS.
S
O
D
Luego de varias entrevistas con el representante de
A usuarios, los casos de uso
Vlos
R
E
S
E
R
de la extranet arrojaron los siguientes
requerimientos.
OS
H
C
E
DER
Caso de Uso: Tipos de usuario (ID:00)
• Usuarios Estándar: Pueden ver los datos con los que están registrados en la
extranet, asi como cambiar sus propios login y contraseña. También pueden
registrar, modificar, anular y visualizar actividades realizadas sólo por ellos
mismos.
• Superusuarios: Pueden acceder y llevar a cabo las funciones de todos los
casos de uso de la extranet, excepto ver la contraseña de acceso de otro
consultor y registrar, modificar o anular una actividad realizada o registrada por
otro consultor.
80
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
Caso de Uso: Ingresar a la extranet (ID:01)
Se requiere una interfaz con un formulario en donde el usuario pueda ingresar su
login y contraseña en unas cajas de texto para luego proceder a autenticarse
presionando un botón, en esta interfaz también debe aparecer el logo de la empresa.
S
O
D
login y contraseña, en caso de equivocación se podrá
repetir el proceso hasta siete
VA
R
E
S ya que a la octava se bloqueará el
E
R
veces más (en total son ocho las oportunidades),
OS
H
C
E de ese login a la extranet (esto en caso de que se este
acceso al consultor
poseedor
DER
Obviamente, sólo se podrá ingresar a la extranet si el usuario ingresa correctamente su
llevando a cabo un intento de acceso no autorizado a la extranet), y sólo podrá ser
desbloqueado por un superusuario (si en efecto se trata de un intento de hacking y no
que en realidad el usuario se equivocó todas esas veces), se le recomienda al consultor
afectado cambiar su contraseña. Finalmente, cada vez que se produzca un intento
fallido de acceso a la extranet se le debe advertir al usuario que si continua fallando se
le bloqueará la cuenta.
Caso de Uso: Ingresar a un módulo de la extranet (ID:02)
Después de que el usuario se autentique exitosamente en el sistema, dependiendo
del tipo de usuario que sea se le llevará a diferentes módulos. Si se trata de un usuario
estándar, se le enviará al módulo de registro de actividades, si es un superusuario se le
llevará al módulo de registro de consultores; en ambos módulos, así como en el resto
81
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
de los módulos de la extranet, habrá un menú desde el que se puede elegir cualquier
módulo que pueda ser accedido por ambos tipos de usuario.
Caso de Uso: Registrar un consultor (ID:03)
Sólo los superusuarios podrán llevar a cabo esta acción. El ingreso de los datos se
S
O
D
VA
R
E
S
hará a través de un formulario, el cual debe permitir al usuario ingresar los siguientes
datos del consultor:
•
E
R
S
HO
EC
R
E
D
Primer nombre: Este dato se ingresará en una textbox, y es de carácter
obligatorio. Será una cadena con una longitud máxima de 20 caracteres y no
contará con ninguna validación de formato, es decir, para él serán válidas todas
las cadenas con una longitud de 20 caracteres o menos.
•
Segundo nombre: También se ingresará en una textbox. No es de carácter
obligatorio, pero en caso de ser ingresado debe ser una cadena de 20 caracteres
o menos, siendo esta su única validación.
•
Primer apellido del consultor: Contará con los mismos requerimientos del dato
“primer nombre”.
•
Segundo Apellido: Contará con los mismos requerimientos del dato “segundo
nombre”.
•
Código del documento de identidad: Contará con los mismos requerimientos
del dato “primer nombre”, con la única diferencia de que la longitud máxima del
dato será 30 caracteres.
82
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
•
Fecha de nacimiento: Al igual que los otros datos, este también se ingresará a
través de una textbox, será de carácter obligatorio escribirlo y obviamente será
una fecha. Contará con validaciones de formato (el cual es AÑO-MES-DIA), de
que sea una fecha gregoriana y de que este dentro del rango de fechas que
soporta el DBMS (de 1000-01-01 a 9999-12-31).
•
País de Origen: Este dato será una cadena con el nombre del país de origen del
S
O
D
A esta su única validación.
selección en una drop-down list y no es opcional,
Vsiendo
R
E
S dependientes y 1 entidad especial.
E
R
La lista comprende 202 países,
38
territorios
OS
H
C
E
DER
consultor y tendrá una longitud máxima de 30 caracteres, se ingresará mediante
•
Teléfono: Este dato será una cadena que contiene ó el teléfono personal u otro
teléfono de contacto del consultor, no es de necesario ingreso y su longitud
máxima será de 30 caracteres. No contará con ninguna validación de formato y
será ingresado desde una textbox.
•
Correo Electrónico: Este dato será una cadena con el e-mail del consultor. No
es obligatorio su ingreso, pero si se hace, se debe verificar que ningún otro
consultor tenga el mismo mail, para poder guardarse en la base de datos (esta
es su única validación). Tendrá una longitud máxima de 45 caracteres y se
ingresará desde una textbox.
•
Estatus Laboral: Este dato será una cadena que indique el estatus laboral del
consultor, y cuenta con las mismas características del dato “país de origen”, sólo
que su longitud máxima es de 15 caracteres. Los posibles valores de este dato
son:
83
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
•
ƒ
Potencial
ƒ
Contratado
ƒ
Empleado
ƒ
Ex – Empleado
ƒ
Despedido
ƒ
Jubilado
S
O
D
el consultor, su longitud máxima será de 45 caracteres.
VA No contará con ninguna
R
E
ESdesde una textbox. Si el estatus laboral
R
validación de formato y seráS
ingresado
HO
C
E
es potencial
no se puede ingresar este dato, si el estatus es contratado ó
DER
Cargo: Este dato será una cadena con el cargo desempeñado en la empresa por
empleado es obligatorio, y si es ex-empleado, jubilado ó despedido entonces es
opcional.
•
Nivel Salarial: Este dato será una cadena contentiva del nivel salarial del
consultor y no es de carácter obligatorio. Se seleccionará de una drop-down list y
su longitud máxima será de 30 caracteres, y no contará con validaciones de
formato. Si el estatus laboral es potencial no se puede ingresar este dato, si el
estatus es contratado ó empleado es obligatorio, y si es ex-empleado, jubilado ó
despedido entonces es opcional.
En el momento en el que el usuario termine de ingresar los datos del consultor, este
presionará un botón para proceder al registro en la BD. A continuación el sistema
comprobará si se ha cumplido con todas las restricciones y validaciones, si todas se
han cumplido correctamente, se procederá a guardar los datos ingresados en la BD, si
84
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
no, se procede a mostrar los mensajes de error que le indicaran al usuario la manera
correcta de ingresar los datos para luego corregir los errores e intentar nuevamente el
registro, y así sucesivamente hasta que el usuario ingrese correctamente los datos
(luego de lo cual se le muestran los datos ingresados como un formulario congelado) ó
abandone el caso de uso. Cabe destacar que un consultor recién registrado en la base
de datos no tiene acceso a la extranet, ni login o contraseña y es un tipo de usuario
S
O
D
VA
R
E
S
estándar.
E
R
S
HO
EC
R
E
D
Caso de Uso: Actualizar los datos de un consultor (ID:04)
Este caso comienza al proporcionar al usuario una interfaz para buscar al consultor
al que se la quieren modificar los datos. La interfaz debe tener un formulario donde se
puedan introducir los datos para la búsqueda en los siguientes textbox:
•
Primer nombre del consultor
•
Segundo nombre del consultor
•
Primer apellido del consultor
•
Segundo apellido del consultor
•
Fecha de Nacimiento del consultor
•
Código del documento de identidad del consultor
•
Correo Electrónico del consultor
85
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
•
ID en la BD del consultor
Si no se ingresa ninguno de los datos el sistema mostrará todos los consultores
registrados en la BD .Luego de que el usuario introduzca los parámetros de búsqueda
anteriores (si es que decidió ingresar alguno), debe presionar el botón de búsqueda,
con lo cual (si no hay errores en los parámetros de búsqueda, ya que si los hay
aparecerán mensajes advirtiéndolo hasta que el usuario ingrese todos los parámetros
S
O
D
igual a al menos uno de los datos introducidos y los mostrará
VA en una tabla (si no hay
R
E
Susuario que su búsqueda no produjo
E
R
consultores con esos datos, se le
indica
al
OS
H
C
E
resultados), pidiendo
DERque seleccione a alguno de los consultores mostrados para
correctamente) se seleccionarán de la BD todos los consultores que tengan un valor
proceder a actualizarle los datos, esta selección se hará escribiendo el ID del consultor
en cuestión en una textbox y presionando un botón.
A continuación, se le mostrará al usuario un formulario casi igual al usado para
registrar a un nuevo consultor en la BD, con la única diferencia de que este tiene otro
botón para devolverse a la pagina anterior (la de selección del consultor de la tabla de
resultados). El formulario aparecerá con los datos actuales del consultor cargados, para
que el usuario tenga una idea clara de cuales son los datos que debe modificar. Luego
de actualizar los datos, el usuario presionará un botón para guardar los cambios en la
BD.
Sólo los superusuarios podrán acceder a este caso de uso. Una regla muy
importante a tener en cuenta, es que si se cambia el estatus laboral de un consultor de
“Contratado” o “Empleado” a cualquiera de los otros valores, el sistema le bloquea
automáticamente el acceso a la extranet a ese consultor (si es que lo tiene). Para los
86
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
demás datos que se modifiquen, aplican las mismas validaciones que sus contrapartes
en el caso de uso de registro de nuevos consultores en la BD. En caso de producirse
errores en la actualización de los datos, el sistema mostrará los mensajes de error
correspondientes para indicarle al usuario la manera correcta de ingresar los datos, y lo
seguirá haciendo hasta que el usuario cumpla con todas las restricciones de ingreso,
solo en ese momento se guardarán las modificaciones hechas en la BD, las cuales se
S
O
D
VA
R
E
S
mostrarán al usuario en forma de un formulario congelado.
E
R
S
HO
EC
R
E
D
Caso de Uso: Visualizar los datos de un consultor registrado menos los datos
relacionados a la cuenta en la extranet (ID:05)
Sólo los superusuarios podrán acceder a este caso de uso. Para indicar el consultor
al que se le quieren ver los datos, se emplearán la interfaz y el mecanismo de búsqueda
utilizados para seleccionar al consultor al que se le iban a modificar los datos en el caso
de uso de actualización de datos de los consultores registrados en la BD. Luego de
ingresar los parámetros sin errores y presionar el botón de búsqueda, si se produjeron
resultados aparecerá una tabla con todos los datos de los consultores seleccionados,
de esta manera se tiene la posibilidad de hacer comparaciones entre consultores, ó si el
usuario así lo desea, puede ver los datos de un solo consultor ingresando su ID en una
textbox que estará ubicada debajo de la tabla de resultados, para luego presionar un
botón de confirmación; con esto los datos del consultor poseedor del ID ingresado
podrán ser vistos en otra página de forma individual.
87
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
Caso de Uso: Visualizar los datos de registro en la extranet propios (ID:06)
Este caso de uso es para que un consultor pueda ver los datos con los que está
registrado en la empresa. El caso comienza cuando el consultor selecciona la opción de
“Visualizar datos de registro propios” en el menú de la extranet, a partir de ese
S
O
D
base de datos y los mostrará en la interfaz grafica deVusuario
A mediante un formulario
R
E
S
E
R
congelado.
OS
H
C
E
Caso de Uso: Crearle
DER una cuenta en la extranet a un consultor (ID:07)
momento el sistema seleccionará automáticamente los datos de dicho consultor de la
Sólo los superusuarios tienen acceso a este caso de uso. Para elegir al consultor al
que se le creará la cuenta en la extranet se usará el mismo método utilizado en el
módulo de actualización de datos de consultor para elegir al consultor al que se le iban
a actualizar los datos. Luego de que se haya elegido al consultor, se requiere una
interfaz con un formulario en el cual se puedan ingresar los siguientes datos de la
cuenta en la extranet del consultor:
•
Login: Será una cadena con el nombre de usuario del consultor en la extranet y
su longitud debe estar entre los 10 y 15 caracteres. Se ingresará desde una
textbox y es de carácter obligatorio. No tendrá validaciones de formato. El valor
de este dato tiene que ser único para cada consultor.
•
Contraseña: Este dato presenta los mismos requerimientos del campo “login”.
Excepto que en vez de usarse una textbox para su ingreso, se usará un
88
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
elemento “password”, que es una textbox a la que no se le pueden ver el valor
de los caracteres ingresados en ella; otra excepción es que no es necesario que
el valor de la contraseña sea único para cada consultor. Por último el valor de
este dato y el de ‘Confirmar Contraseña’ tienen que ser iguales.
•
Confirmar Contraseña: El valor de este campo se comparará con el de la
contraseña para ver si el usuario no se equivoco ingresando la contraseña. Por
S
O
D
Tipo de Usuario: Este dato representa el tipo de
usuario que es el consultor en
VA
R
E
S
E
R
la BD. Es de carácter obligatorio
y
se
ingresará desde una drop – down list con
S
O
H
EC
R
las siguientes
opciones:
E
D
lo demás este dato tiene las mismas especificaciones del dato ‘contraseña.
•
ƒ
Estándar
ƒ
Superusuario
Que corresponden a los tipos de usuario que tendrá la extranet, y que fueron
descritos al principio de este apartado.
•
Bloqueado: Este campo indica si un consultor tiene acceso a la extranet o no y
es de carácter obligatorio. Para elegir su valor se usará una drop – down list con
2 opciones “SI“ y “NO”, si se elige “SI” quiere decir que se le esta habilitando el
acceso a la extranet al consultor, lo contrario sucede si se elige “NO”.
Obviamente, para crearle una cuenta a un consultor en la extranet este debe
estar registrado en la BD y su estatus laboral debe ser “Contratado” ó “Empleado”.
Por otra parte, el sistema debe asegurarse de que el consultor efectivamente no
tenga una cuenta de acceso a la extranet. Así mismo, Cuando se crea una cuenta
89
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
de acceso, el superusuario encargado de hacerlo le da al consultor un login y
contraseña provisionales, los cuales el consultor debe cambiar lo más pronto posible
accediendo al caso de uso de cambio de login y/o contraseña; este es el único
momento, es decir, durante la creación de la cuenta, en el que un usuario que no
sea la persona poseedora de la cuenta puede acceder para ver y cambiar el login y
contraseña de otro usuario.
S
O
D
En caso de producirse errores en el ingreso de los
A el sistema mostrará los
Vdatos,
R
E
S al usuario la manera correcta de
E
R
mensajes de error correspondientes
para
indicarle
OS
H
C
ingresar los datos,
y loEseguirá haciendo hasta que el usuario cumpla con todas las
DER
restricciones de ingreso, solo en ese momento se guardarán los datos en la BD, los
cuales se mostrarán al usuario como un formulario congelado.
Caso de Uso: Actualizar los datos de acceso a la extranet de un consultor (ID:08)
Sólo los superusuarios tienen acceso a este caso de uso. Para elegir el consultor al
que le van a modificar los datos, se utilizará el mismo método utilizado en él caso de
uso de modificación de los datos de un consultor registrado en la BD. Una vez
seleccionado el consultor, se necesita una interfaz con un formulario que permita
ingresar los siguientes datos:
•
Login: Es el nombre de usuario del consultor en la extranet y su longitud debe
estar entre los 10 y 15 caracteres. Se ingresará desde una textbox y es de
90
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
carácter obligatorio. No tendrá validaciones de formato. El valor de este dato
tiene que ser único para cada consultor.
•
Contraseña: Este dato presenta los mismos requerimientos del campo “login”.
Excepto que en vez de usarse una textbox para su ingreso, se usará un
elemento “password”, que es una textbox a la que no se le pueden ver el valor
de los caracteres ingresados en ella; otra excepción es que no es necesario que
S
O
D
este dato y el de ‘Confirmar Contraseña’ tienen V
que
Aser iguales.
R
E
S
E
R
OS
H
C
E
ConfirmarEContraseña:
El valor de este campo se comparará con el de la
D R
el valor de la contraseña sea único para cada consultor. Por último el valor de
•
contraseña para ver si el usuario no se equivoco ingresando la contraseña. Por
lo demás este dato tiene las mismas especificaciones del dato ‘contraseña.
•
Bloqueado: Como se mencionó antes, este dato indica si un consultor tiene
habilitado el acceso a la extranet ó no. Su ingreso se hará por medio de una
drop-down list cuyas opciones naturalmente serán “SI” ó “NO” (con el valor actual
preseleccionado). Cuando se cambia este dato de “SI” a “NO” no hay novedad
puesto que a un consultor se le puede bloquear la cuenta por diversos motivos,
pero para cambiarlo de NO a SI el consultor tiene que tener un estatus laboral de
“Contratado” ó “Empleado”.
•
Tipo de Usuario: Al igual que se dijo anteriormente, este dato señala el tipo de
usuario que es el consultor en la extranet. Su ingreso se hará a través de una
drop-down list con las opciones de “Estándar” y “Superusuario” (con el valor
actual preseleccionado).
91
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
Estos datos, en este caso de uso, son de ingreso opcional y el cambio de valor en
uno de ellos no implica que el otro tenga que cambiar a un determinado valor también.
Cuando el usuario presione el botón para guardar las modificaciones en la BD se le
mostrarán los datos recién ingresados en forma de formulario congelado.
S
O
D
VA
R
E
S
E
R
S
HO
Caso de Uso: Cambiar el login o contraseña propios (ID:09)
EC
R
E
D
Sólo el usuario propietario de la cuenta a la que se le van a modificar los valores
puede acceder a este caso de uso, es por ello que no se necesita ningún proceso para
seleccionar al consultor al que se le van a modificar los datos. Por otra parte, se
requiere una interfaz con un formulario para ingresar los siguientes datos:
•
Login: Como se mencionó anteriormente, este dato tiene el nombre de usuario
del consultor en la extranet. Se modificará desde una textbox (la cual estará llena
con el login actual del consultor). Las validaciones que tendrá es que no se
puede ingresar el mismo valor de login que otro consultor y que su longitud esté
en un rango de 10 a 15 caracteres.
•
Contraseña: Para modificar su contraseña de acceso, el consultor usará dos
textbox de tipo “password”, porque la segunda se utilizará para confirmar la
nueva contraseña ingresada, es decir, para que la modificación de la contraseña
se lleve a cabo con éxito, ambas textbox deben tener ingresado el mismo valor.
92
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
La única validación de este dato es que su longitud este en un rango de 10 a 15
caracteres.
Estos datos, en este caso de uso, son de ingreso opcional. En caso de producirse
errores en la modificación de los datos, el sistema mostrará los mensajes de error
correspondientes para indicarle al usuario la manera correcta de ingresar los datos, y lo
S
O
D
solo en ese momento se guardarán las modificacionesV
hechas
A en la BD, las cuales se
R
E
EScongelado.
R
mostrarán al usuario en forma de unS
formulario
HO
C
E
DER
seguirá haciendo hasta que el usuario cumpla con todas las restricciones de ingreso,
Caso de Uso: Visualizar los datos de acceso a la extranet propios (ID:10)
Sólo el consultor poseedor de la cuenta en la extranet puede acceder a este caso de
uso. No hace falta un mecanismo de selección de consultor puesto que los datos que se
mostrarán son los del mismo consultor que usa la extranet en ese momento. Se
requiere una interfaz que muestre al consultor el login, tipo de usuario y si tiene
habilitado el acceso a la extranet. Por razones de seguridad no se mostrará la
constraseña.
Caso de Uso: Registrar una empresa (ID:11)
93
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
Sólo los superusuarios tienen acceso a este caso de uso. Se requiere una interfaz
con un formulario que permita al usuario el ingreso de los siguientes datos de la
empresa:
•
Nombre: Es una cadena que representa el nombre de la empresa, su ingreso es
de carácter obligatorio y se llevará a cabo desde una textbox. La única validación
de este dato es que su longitud máxima será de 45 caracteres.
•
•
S
O
D
empresa. Es una cadena cuya longitud máximaV
esA
de 20 caracteres, su ingreso
R
E
S
E
R
es obligatorio y se hará desde
una
textbox.
OS
H
C
RE
CódigoD
deE
Identificación:
Es el código de identificación de la empresa ante las
Nombre corto: Como su nombre lo indica, representa el nombre corto de la
entidades fiscales de su país. Como se puede inferir, en el caso de Venezuela
dicho código corresponde es el registro de información fiscal (RIF). La longitud
máxima de este dato será de 30 caracteres.
•
Teléfono: Es una cadena cuyo valor representa el número ó números de
teléfono de la empresa (separados por comas), y su longitud máxima es de 255
caracteres. Su ingreso se llevará a cabo desde una textbox.
•
País de operación: Es una cadena que indica el país de operación de la
empresa, en caso de tratarse de una transnacional, el valor de este dato indicará
el país donde esta la sede a la que se le están brindando los servicios. Este dato
será seleccionado desde una drop-down list con 202 países, 38 territorios
dependientes y 1 entidad especial. El ingreso de este dato es obligatorio y no
necesita ninguna validación.
94
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
•
Dirección: Es una cadena con la dirección de la empresa. Su ingreso se hará
desde una textbox y es opcional. La única validación que tendrá este dato será
que su longitud no supere los 255 caracteres.
•
Fax: Es una cadena con el número ó números de fax de la empresa (separados
por coma). Su ingreso se hará desde una textbox y es opcional. Su longitud no
puede ser mayor de 255 caracteres.
S
O
D
Como se puede ver, las restricciones de este caso
de uso son bastante simples,
VA
R
E
S forma correcta. En caso de producirse
E
R
consisten en ingresar los datos obligatorios
en
OS
H
C
E
errores durante E
ingreso de los datos, el sistema mostrará los mensajes de error
Del R
correspondientes para indicarle al usuario la manera correcta de ingresar los datos, y lo
seguirá haciendo hasta que el usuario cumpla con todas las restricciones de ingreso,
solo en ese momento se guardarán los datos en la BD, los cuales se mostrarán al
usuario como un formulario congelado.
Caso de Uso: Actualizar los datos de una empresa (ID:12)
Para seleccionar la empresa a la que se la van a modificar los datos, se usará una
interfaz con un formulario que permita al usuario ingresar el ID de la empresa, una
cadena para buscar en el comienzo ó en cualquier parte del nombre largo y otra con las
mismas características pero para buscar en el nombre corto (el usuario elegirá donde
buscar por medio de dos radio buttons). También se podrá indicar el país de operación
95
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
de la empresa por medio de una drop-down list. El ingreso de todos estos datos para la
búsqueda es opcional, pero al menos se tiene que introducir uno de ellos.
Luego de que el usuario introduzca alguno los parámetros de búsqueda anteriores,
debe presionar el botón de búsqueda, con lo cual se seleccionará de la BD (si no hay
errores en los parámetros de búsqueda, ya que si los hay aparecerán mensajes
advirtiéndolo hasta que el usuario ingrese todos los parámetros correctamente) todas
S
O
D
mostrará en una tabla (si no hay empresas con esos datos,
VA se le indica al usuario que
R
E
Sque seleccione a alguna de las empresas
E
R
su búsqueda no produjo resultados),
pidiendo
OS
H
C
E
mostradas para proceder
DER a actualizarle los datos, esta selección se hará escribiendo el
las empresas que tengan un valor igual a al menos uno de los datos introducidos y las
ID de la empresa en cuestión en una textbox y presionando un botón.
A continuación, se le mostrará al usuario un formulario casi igual al usado para
registrar una empresa en la BD, con la única diferencia de que este tiene otro botón
para devolverse a la pagina anterior (la de selección de la empresa de los resultados de
búsqueda). El formulario aparecerá con los datos actuales de la empresa cargados,
para que el usuario tenga una idea clara de cuales son los datos que debe modificar.
Luego de actualizar los datos, el usuario presionará un botón para guardar los cambios
en la BD.
Sólo los superusuarios tienen acceso a este caso de uso. Para los datos que se
modifiquen, aplican las mismas validaciones que sus contrapartes en el caso de uso de
registro de empresas en la BD. En caso de producirse errores en la actualización de los
datos, el sistema mostrará los mensajes de error correspondientes para indicarle al
usuario la manera correcta de ingresar los datos, y lo seguirá haciendo hasta que el
96
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
usuario cumpla con todas las restricciones de ingreso, solo en ese momento se
guardarán las modificaciones hechas en la BD, las cuales se mostrarán al usuario en
forma de un formulario congelado.
Caso de Uso: Visualizar los datos de una empresa (ID:13)
S
O
D
la que se le quieren ver los datos, se emplearánV
laA
interfaz y el mecanismo de
R
E
S a la que se le modificarían los datos
E
R
búsqueda utilizados para seleccionar
a
la
empresa
OS
H
C
E
en el caso de uso
DEdeRactualización de datos de empresas registradas en la BD, con la
Sólo los superusuarios tienen acceso a este caso de uso. Para indicar la empresa a
única diferencia que si se presiona el botón de búsqueda sin ingresar ningún parámetro
se mostrarán los datos de todas las empresas clientes registradas en el sistema
Luego de ingresar los parámetros sin errores (en caso de haberse ingresado alguno)
y presionar el botón de búsqueda, si se produjeron resultados, aparecerá una tabla con
todos los datos de las empresas seleccionadas, de esta manera se tiene la posibilidad
de hacer comparaciones entre empresas, ó si el usuario así lo desea, puede ver los
datos de una sola empresa ingresando su ID en una textbox que estará ubicada debajo
de la tabla de resultados, para luego presionar un botón de confirmación; con esto los
datos de la empresa poseedora del ID ingresado podrán ser vistos en otra página de
forma individual.
Caso de Uso: Registrar un tipo de actividad (ID:14)
97
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
Sólo los superusuarios tienen acceso a este caso de uso. Se requiere una interfaz
con un formulario que permita al usuario ingresar los siguientes datos del tipo de
actividad:
•
Nombre: Este dato tipo cadena, representa el nombre del tipo de actividad. Su
ingreso se hará desde una textbox y es obligatorio; su longitud máxima será de
45 caracteres.
•
Cargable: Este dato indica si el tipo de actividad es cargable (es decir, si se le
•
Vigente: Este dato expresa si el tipo de actividad está vigente para ser usado en
S
O
D
A desde una drop-down list
debe pagar) al consultor. Su ingreso se llevara V
a cabo
R
E
Sque es cargable y “NO” para el caso
E
R
con las opciones de “SI”, para
indicar
OS
H
C
E
contrario. Finalmente,
DER el ingreso de este dato es obligatorio.
el registro de actividades y otros casos de uso de la extranet. Su ingreso se
llevará a cabo desde una drop-down list con las opciones de “SI” para indicar que
estará vigente y “NO” para indicar lo contrario. Introducir este dato es de carácter
obligatorio para poder registrar un nuevo tipo de actividad.
•
Descripción: Este dato es una cadena con la descripción del tipo de actividad.
Su ingreso se llevara a cabo desde una textarea (un rectángulo para ingresar
texto) y es de carácter obligatorio. Finalmente, este campo no puede tener más
de 255 caracteres.
Luego de llenar los campos del formulario, el usuario debe presionar un botón para
que se guarden los datos en la BD. En caso de producirse errores en el ingreso de la
información, el sistema mostrará los mensajes de error correspondientes para indicarle
98
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
al usuario la manera correcta de introducir los datos, y lo seguirá haciendo hasta que el
usuario cumpla con todas las validaciones de ingreso de los datos, sólo en ese
momento se guardarán los datos en la BD, los cuales se mostrarán al usuario como un
formulario congelado.
Caso de Uso: Poner en vigencia ó dejar sin vigencia un tipo de actividad (ID:15)
S
O
D
Sólo los superusuarios tienen acceso a este caso de
A Para seleccionar el tipo de
Vuso.
R
E
S se necesita un formulario que le
E
R
actividad que se va a colocar ó dejar
sin
vigencia,
OS
H
C
RE el ID del tipo de actividad, una cadena que aparezca en el
permita al usuario
DEingresar
nombre del tipo de actividad (y que se pueda buscar al comienzo ó en cualquier parte
de la misma, lo cual se indicará por medio de radio buttons), y sendas drop-down lists
para indicar si el tipo de actividad es cargable y vigente respectivamente. Es obligatorio
introducir al menos uno de los datos anteriores.
Luego de que el usuario introduzca alguno ó todos los parámetros de búsqueda
anteriores, debe presionar el botón de búsqueda, con lo cual se seleccionarán de la BD
(si no hay errores en los parámetros de búsqueda, ya que si los hay aparecerán
mensajes
advirtiéndolo
hasta
que
el
usuario
ingrese
todos
los
parámetros
correctamente) todos los tipos de actividad que tengan un valor igual a al menos uno de
los datos introducidos y las mostrará en una tabla (si no hay tipos de actividad con esos
datos, se le indica al usuario que su búsqueda no produjo resultados), pidiendo que
seleccione a alguno de los tipos de actividad mostrados para proceder a actualizarle los
99
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
datos, esta selección se hará escribiendo el nombre del tipo de actividad en cuestión en
una textbox y presionando un botón.
A continuación, se le mostrará al usuario un formulario casi igual al usado para
registrar un tipo de actividad en la BD, con la única diferencia de que este tiene otro
botón para devolverse a la pagina anterior (la de selección del tipo de actividad de los
resultados de búsqueda). El formulario aparecerá con los datos actuales del tipo de
S
O
D
que debe modificar. Luego de actualizar los datos, el usuario
VA presionará un botón para
R
E
S
E
R
guardar los cambios en la BD.
OS
H
C
E
DER
actividad cargados, para que el usuario tenga una idea clara de cuales son los datos
Para permitirle al usuario guardar los cambios de los datos en la BD, se tiene que
cumplir con las mismas restricciones que tienen los datos del caso de uso de registro de
un tipo de actividad en la BD. En caso de producirse errores en la actualización de los
datos, el sistema mostrará los mensajes de error correspondientes para indicarle al
usuario la manera correcta de ingresar los datos, y lo seguirá haciendo hasta que el
usuario cumpla con todas las restricciones de ingreso, solo en ese momento se
guardarán las modificaciones hechas en la BD, las cuales se mostrarán al usuario en
forma de un formulario congelado.
Caso de Uso: Visualizar los datos de un tipo de actividad (ID:16)
Sólo los superusuarios tienen acceso a este caso de uso. Para seleccionar el tipo
de actividad a la que se le quieren visualizar los datos, se emplearán la misma interfaz y
100
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
método de selección utilizado en el caso de uso de actualización de datos de un tipo de
actividad para seleccionar la actividad que iba a ser actualizada, con la única diferencia
de que si no se ingresa ningún parámetro de búsqueda se seleccionaran de la BD todas
los tipos de actividad registrados.
Luego de ingresar los parámetros sin errores (si es que ingresó alguno) y presionar
el botón de búsqueda, si se produjeron resultados, aparecerá una tabla con todos los
S
O
D
hacer comparaciones entre tipos de actividad, ó si el usuario
VA así lo desea, puede ver los
R
E
Ssu ID en una textbox que estará ubicada
E
R
datos de un solo tipo de actividad ingresando
OS
H
C
E
debajo de la tabla
DEdeRresultados, para luego presionar un botón de confirmación; con
datos de los tipos de actividad seleccionados, de esta manera se tiene la posibilidad de
esto los datos del tipo de actividad con ese ID podrán ser vistos en otra página de forma
individual. Es importante señalar que si no se producen resultados en la búsqueda, el
sistema mostrará un mensaje indicándolo y ofrecerá un botón para devolverse a la
página de ingreso de los parámetros de búsqueda.
Caso de Uso: Registrar un proyecto (ID:17)
Sólo los superusuarios tienen acceso a este caso de uso. Se requiere una interfaz
con un formulario que permita al usuario ingresar los siguientes datos:
•
Nombre del proyecto: Este dato representa el nombre del proyecto y será una
cadena con una longitud máxima de 255 caracteres, su ingreso se hará a través
101
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
de una textbox y es de carácter obligatorio. Finalmente, este dato no tendrá
validaciones de formato.
•
Fecha de inicio del proyecto: Este dato indica la fecha de inicio del proyecto.
Su ingreso es obligatorio y se hará a través de una textbox. La fecha de inicio del
proyecto debe tener el siguiente formato AÑO-MES-DÍA, con 4 dígitos para el
año y dos para el mes y día. La fecha también debe ser una fecha gregoriana y
S
O
D
fecha debe ser la misma fecha o posterior a la fecha
VAde inicio.
R
E
ES
R
Fecha de fin del proyecto:S
Este
dato indica la fecha de fin del proyecto. Su
HO
C
E
R y se llevará a cabo desde una textbox. La fecha de fin del
ingreso esE
D opcional
el año debe estar dentro del rango que soporta el DBMS (de 1000 a 9999). Esta
•
proyecto debe tener el siguiente formato AÑO-MES-DÍA, con 4 dígitos para el
año y dos para el mes y día. La fecha también debe ser una fecha gregoriana y
el año debe estar dentro del rango que soporta el DBMS (de 1000 a 9999). En
caso de ser ingresado, este dato debe ser ó la misma fecha ó posterior a la fecha
de inicio.
•
Nombre de la empresa cliente: Este dato es de ingreso obligatorio. Contiene el
nombre corto de la empresa donde se va ó se está realizando el proyecto y se
introducirá desde una drop – down list, la cual contiene todos los nombres cortos
de las empresas registradas en la BD, lo que quiere decir que si la empresa
cliente no se encuentra en el repositorio de empresas de la BD, primero hay que
registrarla antes de poder inscribir el proyecto.
•
Descripción del proyecto: Este dato contiene detalles acerca del proyecto y
será una cadena con una longitud máxima de 255 caracteres. Su ingreso se
102
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
llevará a cabo desde un elemento de formulario de tipo textarea (un recuadro
donde se puede escribir texto), y es de carácter obligatorio. Este dato no contará
con validaciones de formato.
•
Activo: Este dato indica si el proyecto está activo ó no en un momento
determinado. Su ingreso es de carácter obligatorio y se llevará a cabo desde una
drop-down list con las opciones de “SI” (para indicar que se desea que el
S
O
D
inactivo los consultores no podrán registrar actividades
VA en él.
R
E
S
E
R
OS
H
C
EREprecargado en la BD llamado "actividad independiente", el cual
Existirá unD
proyecto
proyecto este activo) y “NO” para indicar lo contrario. Mientras un proyecto este
permitirá registrar actividades realizadas fuera de cualquier proyecto, es decir,
actividades independientes.
En el momento en el que el usuario termine de ingresar los datos del proyecto, este
presionará un botón para proceder a su registro en la BD. A continuación el sistema
comprobará si se ha cumplido con todas las restricciones y validaciones, si todas se
han cumplido correctamente, se procederá a guardar los datos ingresados en la BD, si
no, se procede a mostrar los mensajes de error que le indicaran al usuario la manera
correcta de ingresar los datos para luego corregir los errores e intentar nuevamente el
registro, y así sucesivamente hasta que el usuario ingrese correctamente los datos
(luego de lo cual se le muestran los datos ingresados como un formulario congelado) ó
abandone el caso de uso.
103
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
Caso de Uso: Actualizar los datos de un proyecto (ID:18)
Se requiere una interfaz donde se puedan ingresar los siguientes parámetros para la
búsqueda del proyecto.
•
El ID del proyecto
•
S
O
D
El límite inferior del rango de fechas de inicio
queAdeben tener los proyectos a
V
R
E
S
E
R
buscar.
OS
H
C
EREdel rango de fechas de inicio que deben tener los proyectos a
El límite
Dsuperior
•
•
Una cadena que aparezca en el nombre del proyecto
buscar.
•
El límite inferior del rango de fechas de fin que deben tener los proyectos a
buscar.
•
El límite superior del rango de fechas de fin que deben tener los proyectos a
buscar.
•
El estatus del proyecto (activo ó inactivo)
•
Indicación de si el proyecto tiene asignada una fecha de fin.
•
La empresa cliente.
Se debe introducir al menos uno de los datos anteriores. Luego de que el usuario
introduzca alguno los parámetros de búsqueda, debe presionar el botón de búsqueda,
con lo cual (si no hay errores en los parámetros, ya que si los hay aparecerán mensajes
advirtiéndolo hasta que el usuario ingrese todos los parámetros correctamente) se
104
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
seleccionarán de la BD todos los proyectos que tengan un valor igual a al menos uno de
los datos introducidos y se mostrarán en una tabla (si no hay proyectos con esos datos,
se le indica al usuario que su búsqueda no produjo resultados), pidiendo que seleccione
a alguno de los proyectos mostrados para proceder a actualizarle los datos, esta
selección se hará escribiendo el ID del proyecto en cuestión en una textbox y
presionando un botón.
S
O
D
registrar un nuevo proyecto en la BD, con la única diferencia
VA de que este tiene otro
R
E
E(laSde selección del proyecto de la tabla de
R
botón para devolverse a la pagina S
anterior
HO
C
E
resultados). El formulario
DER aparecerá con los datos actuales del proyecto cargados, para
A continuación, se le mostrará al usuario un formulario casi igual al usado para
que el usuario tenga una idea clara de cuales son los datos que debe modificar. Luego
de actualizar los datos, el usuario presionará un botón para guardar los cambios en la
BD.
Sólo los superusuarios tienen acceso a este caso de uso. El usuario sólo podrá
modificar las fechas de inicio y de fin de un proyecto si con las nuevas fechas no
quedan actividades registradas en una fecha anterior ó posterior a las fechas de inicio y
fin del proyecto respectivamente. Para los demás datos que se modifiquen, aplican las
mismas validaciones que sus contrapartes en el caso de uso de registro de nuevos
proyectos en la BD. En caso de producirse errores en la actualización de los datos, el
sistema mostrará los mensajes de error correspondientes para indicarle al usuario la
manera correcta de ingresar los datos, y lo seguirá haciendo hasta que el usuario
cumpla con todas las restricciones de ingreso, solo en ese momento se guardarán las
105
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
modificaciones hechas en la BD, las cuales se mostrarán al usuario en forma de un
formulario congelado.
Caso de Uso: Inscribir a un consultor en un proyecto (ID:19)
Sólo los superusuarios tienen acceso a este caso de uso. Se requiere una interfaz
S
O
D
VseAnecesita una drop-down list
R
proyecto donde se quiere inscribir al consultor. También
E
S
E
R
S
donde se indique el estatus H
conO
el que se quiere inscribir al consultor en el proyecto.
C
E
DER
en la que el usuario pueda ingresar los identificadores tanto del consultor como del
Luego de ingresar todos los datos anteriores (todos son de ingreso obligatorio), el
usuario debe presionar un botón para proceder a la inscripción, con lo cual se le
presentará al mismo usa interfaz en la cual se le preguntará si esta seguro de querer
inscribir al consultor elegido en el proyecto indicado con el estatus señalado.
Si el usuario confirma la inscripción, se le mostrará una página con un mensaje
indicando que el consultor ha sido inscrito en el proyecto elegido con el estatus indicado
exitosamente; en esa misma página se mostrará un botón para volver al comienzo del
módulo e inscribir a otro consultor en otro proyecto.
Otra restricción que presentará este caso de uso, es que los consultores que se
inscriban en un proyecto deben tener un estatus laboral de “Contratado” ó “Empleado” y
en caso de que el consultor haya sido inscrito con un estatus de activo, el mismo debe
tener una cuenta de acceso a la extranet. Por otra parte, la fecha en la que se agregue
el consultor al proyecto no debe ser posterior a la fecha de fin del mismo, esto en caso
106
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
de estar definida la fecha de fin Por otra parte, se puede inscribir un consultor en un
proyecto así este último este inactivo. Finalmente, se debe verificar que el consultor no
esté actualmente inscrito en ese mismo proyecto.
Caso de Uso: Activar/desactivar a un consultor en un proyecto (ID:20)
S
O
D
VA
R
activar ó desactivar en un proyecto mientras la fecha
en la que se lleve a cabo tal acto
E
S
E
R
S del proyecto. Al igual que en el caso de uso de
Ofin
sea igual ó anterior a la fecha
de
H
C
E
DER
Sólo los superusuarios tienen acceso a este caso de uso. Un consultor se puede
inscripción de un consultor en un proyecto, en este caso de uso también se indicará el
consultor que se quiere activar ó desactivar y el proyecto donde se quiere hacerlo a
través de sendas textbox, también se indicará el nuevo estatus del consultor mediante
la selección de la opción deseada en una drop-down list. Si el cambio de estado de un
consultor es de inactivo a activo, el mismo debe estar contratado ó empleado y debe
tener una cuenta en la extranet.
Todos los datos anteriores son de obligatorio ingreso y luego de que el usuario los
ingrese se le mostrará una página en la que deberá confirmar si quiere
activar/desactivar al consultor en cuestión en el proyecto elegido; si el usuario confirma
la acción, se le mostrará una página donde se indica que el cambio de estatus ha
llevado a cabo exitosamente, si el usuario no confirma la acción, puede abandonar el
caso de uso. Vale la pena destacar que en todas las páginas de este caso de uso se
mostrará un botón para regresar a la página inmediatamente anterior del caso de uso.
107
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
Finalmente, se puede activar un consultor en un proyecto incluso si este último esta
inactivo.
Al momento de inscribir un consultor en un proyecto, a este se le puede dar un
estatus de activo ó inactivo. Pero se debe tener en cuenta que aunque un consultor este
activo en un proyecto, si dicho proyecto no está activo, él por consiguiente, en realidad
no estará activo en ese proyecto. Este estado se puede cambiar más de una vez.
S
O
D
VA
R
E
S
Lógicamente, mientras un consultor no esté activo en un proyecto, no podrá registrar
actividades en ese proyecto.
E
R
S
HO
EC
R
E
D
Caso de Uso: Visualizar los datos de un proyecto (ID:21)
Sólo los superusuarios tienen acceso a este caso de uso. Para seleccionar el
proyecto al que se le quieren ver los datos, se usará la misma interfaz y método
utilizado para seleccionar el proyecto al que se le modificarían los datos en el caso de
uso de actualización de datos de un proyecto; una vez seleccionado el proyecto, se
requiere una interfaz que le muestre al usuario los siguientes datos del mismo:
•
ID del proyecto.
•
Nombre.
•
Fecha de Inicio.
•
Fecha de fin (si está definida).
•
Descripción.
108
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
•
Activo
•
Empresa en la que se está llevando a cabo.
En fin, este caso de uso despliega toda la información relacionada con un proyecto
al usuario.
S
O
D
VA
R
E
S
Caso de Uso: Registrar actividades realizadas (ID:22)
E
R
S
HO
Ambos tipos de usuario tienen acceso a este caso de uso ya que los dos comparten
EC
R
E
D
el rol de consultor de la empresa. Cada consultor debe registrar sus actividades el
mismo, esto se traduce en que cuando un consultor registre una actividad, esta quedará
registrada a su nombre en el sistema. Se requiere una interfaz con un formulario que le
permita al usuario ingresar los siguientes datos:
•
Proyecto donde se realizó la actividad: Es el nombre de uno de los proyectos
que aún no ha finalizado, registrados en el caso de uso de registro de proyectos,
en los que a su vez el consultor se encuentre inscrito y activo. Su ingreso se
hará desde una drop-down list y es de carácter obligatorio. En caso ir a registrar
actividades no relacionadas con un proyecto se elige el proyecto de nombre
“Actividad Independiente”.
•
Fecha de realización de la actividad: Es la fecha en la que se llevó a cabo la
actividad, debe estar ente la fecha de inicio y fin del proyecto. Su ingreso se
llevará a cabo desde una textbox y es obligatorio. Esta fecha debe tener el
109
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
formato AÑO-MES-DÍA, con 4 dígitos para el año y dos para el mes y día, debe
ser una fecha gregoriana y estar en el rango soportado por el DBMS (de 100001-01 a 9999-12-31).
•
Tipo de actividad: Corresponde a uno de los tipos de actividad vigentes
registrados en el caso de uso de registros de actividades. El ingreso de este
dato se hará desde una drop-down list y es obligatorio.
•
S
O
D
cantidad de horas que duró la actividad. Su ingreso
VAse llevará a cabo desde una
R
E
S
E
R
textbox y es obligatorio.
OS
H
C
E
DER
•
Comentario: Servirá para especificar detalles de la actividad realizada ó que
Duración: Este dato es un número entero entre 1 y 24, que representa la
está por realizarse. Será una cadena con una longitud máxima de 255
caracteres, su ingreso es obligatorio y se hará a través de una textarea. Este
dato no cantará con validaciones de formato.
Cuando el usuario termine de ingresar los datos de la actividad debe presionar un
botón para guardarlos en la BD. A continuación, el sistema comprobará si se han
respetado todas las restricciones y validaciones; si todas se han cumplido
correctamente, se procede a guardar los datos, si no, se muestran los mensajes de
error que le indicaran al usuario la manera correcta de ingresar los datos para luego
corregir los errores e intentar nuevamente el registro, y así sucesivamente hasta que el
usuario ingrese correctamente los datos ó abandone el caso de uso. Cada vez que el
usuario ingrese los datos de una actividad correctamente, irán apareciendo (a manera
de confirmación del registro de la información en la BD) debajo del formulario de ingreso
110
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
de la data de las actividades, los datos recién ingresados en la BD (excepto el de
comentario de la actividad). Este proceso se repetirá para cada actividad que necesite
registrar el consultor.
Los posibles estatus de una actividad registrada serán:
•
En Revisión: El sistema asigna este estatus automáticamente cuando un
S
O
D
modificada, anulada y visualizada por el mismo consultor
VA que la registró.
R
E
S
E
R
OS
H
C
RE
Anulada:
Este
estatus se asigna a una actividad cuando el consultor que la
DE
consultor registra una actividad. Una actividad en este estado puede ser
•
registró la anula en el módulo de anulación de actividades. Este estatus es
irreversible y una vez alcanzado no se pueden modificar los datos de la actividad
pero si pueden ser visualizados.
Otros datos no introducidos por el usuario pero que se necesitan registrar son la
persona que está registrando la actividad (explicado al comienzo del apartado), el
estatus de la misma (que en este caso de uso siempre será “En Revisión”) y, la fecha y
hora a la que se llevó a cabo el registro. Otras restricciones de este caso de uso son:
•
Un consultor no puede registrar más de 24 horas de actividades en un mismo
día, sin importar si lo hace en proyectos diferentes.
111
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
•
Para poder registrar actividades, un consultor debe tener un estatus laboral de
empleado ó contratado.
Caso de Uso: Modificar actividades registradas (ID:23)
Este caso comienza al proporcionar al usuario una interfaz para buscar la actividad a
S
O
D
puedan introducir los siguientes datos para la búsqueda:
VA
R
E
S
E
R
OS
H
C
REdel cual se llevo a cabo la actividad: Al igual que en el caso
• Proyecto E
D dentro
la que se le quieren modificar los datos. La interfaz debe tener un formulario donde se
de uso de registro de actividades, es el nombre de uno de los proyectos que aún
no ha finalizado, registrados en el caso de uso de registro de proyectos, en los
que a su vez el consultor se encuentre inscrito y activo. Su ingreso se hará desde
una drop-down list y es de carácter obligatorio.
•
Tipo de actividad realizada: Al igual que en el caso de uso de registro de
actividades, corresponde a uno de los tipos de actividad vigentes registrados en
el caso de uso de registros de actividades. El ingreso de este dato se hará desde
una drop-down list y es obligatorio.
•
Límite inferior del rango de fechas de realización: Que como su nombre lo
indica es el límite inferior del rango de fechas dentro del cual debe estar la fecha
de realización de las actividades registradas que se buscan. Este dato se
ingresará desde una textbox y contará con validaciones de formato, de si la fecha
es gregoriana y de si está en el rango de fechas soportado por el DBMS.
112
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
También se verificará que esta fecha este dentro de la fecha de inicio y fin del
proyecto. Si este parámetro no se ingresa quiere decir que el rango va desde el
limite superior hasta la primera fecha registrada por el consultor que cumpla con
todos los demás parámetros.
•
Límite superior del rango de fechas de realización: Que como su nombre lo
indica es el límite superior del rango de fechas dentro del cual debe estar la
S
O
D
ingresará desde una textbox y contará con validaciones
VA de formato, de si la fecha
R
E
ES
es gregoriana y de si estáS
en R
el rango de fechas soportado por el DBMS.
HO
C
E
R que esta fecha este dentro de la fecha de inicio y fin del
También se
DEverificará
fecha de realización de las actividades registradas que se buscan. Este dato se
proyecto. Si este parámetro no se ingresa quiere decir que el rango va desde el
límite inferior hasta la última fecha registrada por el consultor que cumpla con
todos los demás parámetros.
•
Limite inferior del rango de duración de la actividad: Que como su nombre lo
indica, es el límite inferior del rango de duración dentro del cual debe estar la
duración de las actividades registradas que se buscan. Este dato se ingresará
desde una textbox. Si este parámetro no se ingresa quiere decir que el rango va
desde el límite superior hasta 1.
•
Limite superior del rango de duración de la actividad: Que como su nombre
lo indica, es el límite superior del rango de duración dentro del cual debe estar la
duración de las actividades registradas que se buscan. Este dato se ingresará
desde una textbox. Si este parámetro no se ingresa quiere decir que el rango va
desde el límite inferior hasta 24 horas.
113
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
Si no se ingresa ninguno de los límites para el rango de fechas, el sistema
seleccionara las actividades sin tomar en cuenta la fecha de realización de las mismas,
es decir no discriminará actividades registradas basándose en su fecha de realización,
lo mismo aplica para el rango de duración de la actividad.
Luego de que el usuario introduzca los parámetros de búsqueda anteriores, debe
presionar el botón de búsqueda, con lo cual (si no hay errores en los parámetros de
S
O
D
ingrese todos los parámetros correctamente) se seleccionarán
de la BD todas las
VA
R
E
S igual a al menos uno de los datos
E
R
actividades registradas que tengan
un
valor
OS
H
C
RE en una tabla con las columnas de número de fila, proyecto al
introducidos y losE
D mostrará
búsqueda, ya que si los hay aparecerán mensajes advirtiéndolo hasta que el usuario
que pertenece la actividad, fecha de realización, tipo de actividad y duración (si no hay
actividades con esos datos, se le indica al usuario que su búsqueda no produjo
resultados), pidiendo que seleccione a alguna de las actividades mostradas para
proceder a actualizarle los datos, esta selección se hará escribiendo el número de fila
de la tabla de resultados donde se encuentra la actividad en cuestión en una textbox y
presionando el botón de selección.
A continuación, se le mostrará al usuario un formulario casi igual al usado para
registrar una actividad en la BD, con la única diferencia de que este tiene un botón para
devolverse a la pagina anterior (la de selección de la actividad de la tabla de
resultados). El formulario aparecerá con los datos actuales de la actividad cargados
para que el usuario tenga una idea clara de cuales son los datos que debe modificar.
Luego de actualizar los datos, el usuario presionará un botón para guardar los cambios
en la BD.
114
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
Sólo el usuario que registró la actividad tendrá acceso a este módulo (sea usuario
estándar ó superusuario). El usuario sólo modificará los datos que desee modificar.
Para los datos que se modifiquen, aplican las mismas validaciones que sus
contrapartes en el caso de uso de registro de actividades. En caso de producirse
errores en la actualización de los datos, el sistema mostrará los mensajes de error
correspondientes para indicarle al usuario la manera correcta de ingresar los datos, y lo
S
O
D
solo en ese momento se guardarán las modificacionesV
hechas
A en la BD, las cuales se
R
E
EScongelado.
R
mostrarán al usuario en forma de unS
formulario
HO
C
E
DER
seguirá haciendo hasta que el usuario cumpla con todas las restricciones de ingreso,
Caso de Uso: Anular actividades (ID:24)
Este caso de uso sólo puede ser accedido por el mismo consultor que registró la
actividad. Para seleccionar la actividad que se desea anular, se utilizará la misma
interfaz y proceso utilizado en el caso de uso de modificación de datos de actividad para
seleccionar la actividad a la que se le iban a modificar los datos. Una vez seleccionada
la actividad, se le presentará al usuario un mensaje advirtiéndole si está seguro de
querer anular la actividad, si el usuario confirma la acción, se procede a anular la
actividad y se le muestra un mensaje indicándole que la actividad ha sido anulada
exitosamente. Si por el contrario el usuario no confirma la acción, está en libertad de
abandonar el caso de uso.
115
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
Caso de Uso: Visualizar los datos de las actividades registradas (ID:25)
Este caso de uso sólo puede ser accedido por el mismo consultor que registró la
actividad. Para seleccionar la actividad que se desea anular, se utilizará la misma
interfaz y proceso utilizado en el caso de uso de modificación de datos de actividad para
seleccionar la actividad a la que se le iban a modificar los datos, con la única diferencia
S
O
D
selecciona una opción, no se tomará en cuenta el estatus
VApara buscar las actividades)
R
E
S Revisión” ó “Anuladas”. Al mostrarse la
E
R
para indicar si se desean buscar actividades
“En
OS
H
C
E
tabla con los resultados
DER de la búsqueda, el usuario puede observar todas estas
de que este formulario tiene una drop-down list de uso opcional (es decir si no se
actividades juntas para hacer comparaciones, o si así lo desea, seleccionar una para
verle los datos en otra página.
3.2.1.2. ESPECIFICACIÓN DE REQUERIMIENTOS.
Tal como se explicó en el capítulo anterior, en esta fase sólo se elaboraron los
diagramas de caso de uso, porque los diagramas de clases y secuencia aplican a
sistemas hechos con el paradigma de la programación orientada a objetos, el cual no es
el caso de la extranet de Cibiz S.A. A continuación se muestran los diagramas de caso
de uso producidos durante la fase de especificación de requerimientos.
116
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
FIGURA 6. DIAGRAMA DE CASO DE USO GENERAL DE LA EXTRANET.
Fuente: Ramos (2008).
S
O
D
VA
R
E
S
E
R
S
HO
EC
R
E
D
FIGURA 7. DIAGRAMA DE CASO DE USO DE ACCESO A LA EXTRANET.
Fuente: Ramos (2008).
FIGURA 8. DIAGRAMA DE CASO DE USO DE INGRESO A UN MÓDULO DE LA
EXTRANET.
Fuente: Ramos (2008).
117
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
S
O
D
VA
R
E
S
E
R
S
HO
EC
R
E
D
FIGURA 9. DIAGRAMA DE CASO DE USO DE LOS MÓDULOS DE GESTIÓN DE
DATOS DE LOS CONSULTORES.
Fuente: Ramos (2008).
FIGURA 10. DIAGRAMA DE CASO DE USO DE LOS MÓDULOS DE GESTIÓN DE
CUANTAS DE USUARIO DE LA EXTRANET.
Fuente: Ramos (2008).
118
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
S
O
D
VA
R
E
S
FIGURA 11. DIAGRAMA DE CASO DE USO DE LOS MÓDULOS DE GESTIÓN DE
DATOS DE LAS EMPRESAS CLIENTES.
Fuente: Ramos (2008).
E
R
S
HO
EC
R
E
D
Extranet
Registrar un tipo
de actividad
*
*
*
*
Poner/Dejar sin
vigencia un tipo de actividad
*
Superusuario
*
Visualizar los datos
de un tipo de actividad
FIGURA 12. DIAGRAMA DE CASO DE USO DE LOS MÓDULOS DE GESTIÓN DE
DATOS DE LOS TIPOS DE ACTIVIDAD.
Fuente: Ramos (2008).
119
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
S
O
D
VA
R
E
S
E
R
S
HO
EC
R
E
D
FIGURA 13. DIAGRAMA DE CASO DE USO DE LOS MÓDULOS DE GESTIÓN DE
PROYECTOS.
Fuente: Ramos (2008).
FIGURA 14. DIAGRAMA DE CASO DE USO DE LOS MÓDULOS RELACIONADOS AL
REGISTRO DE ACTIVIDADES.
Fuente: Ramos (2008).
120
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
Como se puede ver, se organizaron los diagramas de caso de uso de acuerdo a la
función que desempeñaban, por ejemplo, aquellos relacionados a la gestión de datos
de las empresas clientes se colocaron juntos, lo mismo sucedió con aquellos relativos a
la gestión de los datos de los consultores. Para la realización de los diagramas se usó
la notación del UML 1.1.
3.2.2. DISEÑO DE LA APLICACIÓN.
S
O
D
VA
R
E
S
E
R
S
HO
EC
R
E
D
En este apartado se profundizará en los tópicos relacionados a la interfaz gráfica de
usuario, así como el diseño arquitectónico del sistema, y finalmente se detallará la
estructura de la base de dato de la extranet.
3.2.2.1. DISEÑO DE LA INTERFAZ DE USUARIO
La interfaz de usuario es la responsable de la interacción con los usuarios de la
extranet. En este apartado, se mostrará la estructura de todo el subsistema de interfaz
grafica de usuario. Se comenzará ilustrando la parte del árbol de directorios en donde
se guardan los archivos de los módulos de la extranet, lo cual a primera vista no parece
tener relación con la interfaz de usuario del sistema, pero en realidad esta íntimamente
ligado a el funcionamiento del menú de navegación de la aplicación.
121
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
S
O
D
VA
R
E
S
E
R
S
HO
EC
R
E
D
FIGURA 15. ESTRUCTURA DE DIRECTORIOS DE LA EXTRANET PARA LA
AUTOMATIZACIÓN DE LOS PROCESOS DE GESTIÓN DE LOS CONSULTORES DE
LA EMPRESA CIBIZ S.A.
Fuente: Ramos (2008).
Por otra parte, el dominio de la extranet, es http://www.ci4biz.com/extranet, que
como se puede observar es un subdominio de http://www.ci4biz.com, el cual
corresponde al dominio de la pagina Web de la empresa Cibiz S.A. En el mismo orden
de ideas, se puede advertir que el directorio “extranet” corresponde al directorio raíz del
árbol de directorios de la aplicación.
A continuación, se nombrarán los directorios en los que se alojan los módulos de la
extranet, así como cuales módulos se alojan en cada directorio. También se indicará los
tipos de usuario que pueden acceder a cada módulo.
122
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
Directorio “extranet/”
•
Módulo de acceso al sistema: Usuario Estándar, Superusuario.
Directorio “/extranet/Datos Maestros/Consultores/”
•
•
•
•
S
O
D
A Superusuario.
Módulo para la actualización de los datos de un V
consultor:
R
E
ES
R
Módulo para la visualización S
de los
datos de un consultor: Superusuario.
HO
C
E
ERla visualización de los datos propios: Usuario Estándar,
MóduloDpara
Módulo para el registro de consultores: Superusuario.
Superusuario.
Directorio “/extranet/Datos Maestros/Consultores/Datos de Acceso/”
•
Módulo para la creación de cuentas de acceso a la extranet: Superusuario.
•
Módulo para la actualización de los datos de las cuentas de acceso a la extranet:
Superusuario.
•
Módulo para la visualización de los datos de las cuentas de acceso a la extranet,
menos la contraseña del usuario: Superusuario.
•
Módulo para el cambio del login y/o contraseña propios: Usuario Estándar,
Superusuario.
123
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
Directorio “/extranet/Datos Maestros/Empresas/”
•
Módulo para el registro de empresas: Superusuario.
•
Módulo para la actualización de los datos de una empresa: Superusuario.
•
Módulo para la visualización de los datos de una empresa: Superusuario.
S
O
D
VA
R
E
S
Directorio “/extranet/Datos Maestros/Tipos de Actividad/”
E
R
S
HO
•
Módulo para el registro de tipos de actividad: Superusuario.
•
Módulo para colocarle ó quitarle la vigencia a un tipo de actividad: Superusuario.
•
Módulo para la visualización de los datos de un tipo de actividad: Superusuario.
EC
R
E
D
Directorio “/extranet/Proyectos/”
•
Módulo para el registro de proyectos: Superusuario.
•
Módulo para la actualización de los datos de un proyecto: Superusuario.
•
Módulo para la inscripción de un consultor en un proyecto: Superusuario.
•
Módulo para la activación/desactivación de un consultor en un proyecto:
Superusuario.
•
Módulo para la visualización de los datos de un proyecto: Superusuario.
124
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
Directorio “/extranet/Registro de Actividades/”
•
Módulo para el registro de actividades: Usuario Estándar, Superusuario.
•
Módulo para modificar los datos de las actividades registradas: Usuario Estándar,
Superusuario.
•
Módulo para anular las actividades registradas: Usuario Estándar, Superusuario.
•
Módulo para visualizar los datos de una actividad registrada: Usuario Estándar,
Superusuario.
S
O
D
VA
R
E
S
EC
R
E
D
E
R
S
HO
Seguidamente, se presentarán los diseños de los menús para los usuarios estándar
y los superusuarios, así como los dos estilos de interfaz que se utilizaron en la extranet,
a saber, el estilo del módulo de acceso a la extranet y el del resto de los módulos, del
cual sólo se mostrará el módulo de actualización de datos de consultor.
FIGURA 16. MENÚ PARA USUARIOS ESTÁNDAR DE LA EXTRANET.
Fuente: Ramos (2008).
FIGURA 17. MENÚ PARA SUPERUSUARIOS DE LA EXTRANET.
Fuente: Ramos (2008).
125
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
FIGURA 18. FOOTER DE LAS PÁGINAS DE LA EXTRANET.
Fuente: Ramos (2008).
S
O
D
VA
R
E
S
E
R
S
HO
EC
R
E
D
FIGURA 19. FORMULARIO PARA LA AUTENTICACIÓN DE LOS USUARIOS.
Fuente: Ramos (2008).
FIGURA 20. FORMULARIO PARA LA AUTENTICACIÓN DE LOS USUARIOS
MOSTRANDO EL ÚNICO MENSAJE DE ERROR.
Fuente: Ramos (2008).
126
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
Módulo para la actualización de los datos de los consultores.
FIGURA 21. CABECERA DE LAS PÁGINAS DEL MÓDULO DE ACTUALIZACIÓN DE
DATOS DE CONSULTORES.
Fuente: Ramos (2008).
S
O
D
VA
R
E
S
E
R
S
HO
EC
R
E
D
FIGURA 22. FORMULARIO PARA EL INGRESO DE LOS PARÁMETROS DE
SELECCIÓN DEL CONSULTOR AL QUE SE LE ACTUALIZARÁN LOS DATOS DEL
MÓDULO PARA LA ACTUALIZACIÓN DE DATOS DE CONSULTORES.
Fuente: Ramos (2008).
127
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
S
O
D
VA
R
E
S
E
R
S
HO
EC
R
E
D
FIGURA 23. MENSAJES DE ERROR DEL FORMULARIO PARA EL INGRESO DE LOS
PARÁMETROS DE SELECCIÓN DEL CONSULTOR AL QUE SE LE ACTUALIZARÁN
LOS DATOS DEL MÓDULO PARA LA ACTUALIZACIÓN DE DATOS DE
CONSULTORES.
Fuente: Ramos (2008).
FIGURA 24. TABLA PARA LA SELECCIÓN DEL CONSULTOR AL QUE SE LE
ACTUALIZARÁN LOS DATOS DEL MÓDULO PARA LA ACTUALIZACIÓN DE DATOS
DE CONSULTORES.
Fuente: Ramos (2008).
128
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
EC
R
E
D
E
R
S
HO
S
O
D
VA
R
E
S
FIGURA 25. MENSAJES DE ERROR DEL FORMULARIO PARA LA ACTUALIZACIÓN
DE LOS DATOS DE UN CONSULTOR DEL MÓDULO PARA LA ACTUALIZACIÓN DE
DATOS DE CONSULTORES.
Fuente: Ramos (2008).
129
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
S
O
D
VA
R
E
S
E
R
S
HO
EC
R
E
D
FIGURA 26. MENSAJE DE CONFIRMACIÓN DE ACTUALIZACIÓN DE DATOS DEL
MÓDULO PARA LA ACTUALIZACIÓN DE LOS DATOS DE UN CONSULTOR.
Fuente: Ramos (2008).
3.2.2.2. DISEÑO ARQUITECTÓNICO
El diseño arquitectónico de la aplicación, corresponde al modelo del producto
mostrado en este mismo capitulo en la figura 4.1.
130
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
3.2.2.3. DISEÑO DE LA BASE DE DATOS
En la base de datos (BD), se guardará la información relevante de las entidades
involucradas en los procesos de gestión de los consultores de la empresa Cibiz, la cual
después podrá ser modificada o visualizada por los usuarios de la extranet. Como se
mencionó en el comienzo de este capítulo, el sistema de gestión de base de datos
(DBMS por sus siglas en inglés) utilizado para la BD del sistema fue MySql 5.0.45, con
S
O
D
VA
R
E
S
el motor de almacenamiento de tablas MyISAM.
E
R
S
HO
A continuación se ilustra el diseño de la BD de la extranet, mostrando primero las
EC
R
E
D
tablas de manera individual, para mostrar las columnas que conforman cada una, y
luego se presentará el diagrama entidad-relación (diseño conceptual) de la base de
datos, el cual es una forma de indicar las diferentes relaciones de las tablas entre si.
131
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
S
O
D
VA
R
E
S
E
R
S
HO
EC
R
E
D
FIGURA 27. COLUMNAS QUE CONFORMAN LA TABLA CONSULTOR. LA TABLA
GUARDA LO DATOS DE LOS CONSULTORES, INCLUYENDO LOS DATOS DE LA
CUENTA DE ACCESO A LA EXTRANET. EN LA FIGURA SE PUEDE APRECIAR EL
TIPO DE CADA COLUMNA ASÍ COMO LA CLAVE PRIMARIA DE LA TABLA.
Fuente: Ramos (2008).
FIGURA 28. COLUMNAS QUE CONFORMAN LA TABLA CONSULTOR_PROYECTO.
LA TABLA INDICA QUE CONSULTORES FUERON O ESTÁN ASIGNADOS A
CUALES PROYECTOS. EN LA FIGURA SE PUEDE APRECIAR EL TIPO DE CADA
COLUMNA ASÍ COMO LA CLAVE PRIMARIA DE LA TABLA.
Fuente: Ramos (2008).
132
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
FIGURA 29. COLUMNAS QUE CONFORMAN LA TABLA DIVISA. LA TABLA INDICA
EN QUE DIVISAS PUEDEN ESTAR EXPRESADOS LOS DISTINTOS NIVELES
SALARIALES. EN LA FIGURA SE PUEDE APRECIAR EL TIPO DE CADA COLUMNA
ASÍ COMO LA CLAVE PRIMARIA DE LA TABLA.
Fuente: Ramos (2008).
S
O
D
VA
R
E
S
E
R
S
HO
EC
R
E
D
FIGURA 30. COLUMNAS QUE CONFORMAN LA TABLA EMPRESA. LA TABLA
GUARDA LOS DATOS DE LAS EMPRESAS CLIENTES DE CIBIZ S.A. EN LA FIGURA
SE PUEDE APRECIAR EL TIPO DE CADA COLUMNA ASÍ COMO LA CLAVE
PRIMARIA DE LA TABLA.
Fuente: Ramos (2008).
FIGURA 31. COLUMNAS QUE CONFORMAN LA TABLA ESTATUS_LABORAL. LA
TABLA GUARDA LOS POSIBLES ESTATUS LABORALES DE LOS CONSULTORES
DE CIBIZ S.A. EN LA FIGURA SE PUEDE APRECIAR EL TIPO DE CADA COLUMNA
ASÍ COMO LA CLAVE PRIMARIA DE LA TABLA.
Fuente: Ramos (2008).
133
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
FIGURA 32. COLUMNAS QUE CONFORMAN LA TABLA NIV_SALARIAL. LA TABLA
GUARDA LOS DATOS DE LA ESCALA DE SALARIOS DE LOS CONSULTORES DE
CIBIZ S.A. EN LA FIGURA SE PUEDE APRECIAR EL TIPO DE CADA COLUMNA ASÍ
COMO LA CLAVE PRIMARIA DE LA TABLA.
Fuente: Ramos (2008).
S
O
D
VA
R
E
S
E
R
S
HO
EC
R
E
D
FIGURA 33. COLUMNA QUE CONFORMA LA TABLA PAÍS. LA TABLA GUARDA LOS
NOMBRES DE 202 PAÍSES, 38 TERRITORIOS DEPENDIENTES Y 1 ENTIDAD
ESPECIAL. SE USARÁ COMO RANGO DE VALORES PARA LOS DATOS PAIS_C DE
LA TABLA CONSULTOR Y PAIS_E DE LA TABLA EMPRESA. EN LA FIGURA SE
PUEDE APRECIAR EL TIPO DE CADA COLUMNA ASÍ COMO LA CLAVE PRIMARIA
DE LA TABLA.
Fuente: Ramos (2008).
FIGURA 34. COLUMNAS QUE CONFORMAN LA TABLA PROYECTO. LA TABLA
GUARDA LOS DATOS DE LOS PROYECTOS EMPRENDIDOS POR CIBIZ S.A. EN LA
FIGURA SE PUEDE APRECIAR EL TIPO DE CADA COLUMNA ASÍ COMO LA CLAVE
PRIMARIA DE LA TABLA.
Fuente: Ramos (2008).
134
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
S
O
D
VAREG_DE_ACT. LA TABLA
R
E
FIGURA 35. COLUMNAS QUE CONFORMAN
LA
TABLA
S REGISTRADAS POR LOS
E
R
GUARDA LOS DATOS DE LAS
ACTIVIDADES
OS SE PUEDE APRECIAR EL TIPO DE CADA
CONSULTORES. ENC
LAH
FIGURA
E
COLUMNA
LA CLAVE PRIMARIA DE LA TABLA.
DER ASÍ COMO
Fuente: Ramos (2008).
FIGURA 36. COLUMNAS QUE CONFORMAN LA TABLA TIPO_ACTIVIDAD. LA
TABLA GUARDA LOS DATOS DE LOS TIPOS DE ACTIVIDAD QUE PUEDEN
REGISTRAR LOS CONSULTORES. EN LA FIGURA SE PUEDE APRECIAR EL TIPO
DE CADA COLUMNA ASÍ COMO LA CLAVE PRIMARIA DE LA TABLA.
Fuente: Ramos (2008).
135
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
S
O
D
VA
R
E
S
E
R
S
HO
FIGURA 37. DIAGRAMA DE ENTIDAD-RELACIÓN (E-R) DE LA BD DEL SISTEMA.
Fuente: Ramos (2008).
EC
R
E
D
3.2.3. IMPLEMENTACIÓN DE CÓDIGO.
Como se mencionó en el capítulo anterior, aunque el desarrollo de la extranet de
Cibiz S.A. no estuvo basado en componentes, en este apartado se explicará que
elementos fueron desarrollados ó adaptados para el sistema, así como los servicios que
fueron suscritos para su funcionamiento.
3.2.3.1. ELEMENTOS DESARROLLADOS Y ADAPTADOS.
Los archivos del sistema que no se desarrollaron, fueron adaptados de otros con
una función igual ó similar. Por ejemplo, los documentos PHP y TPL para el registro de
consultores se codificaron desde cero y luego se adaptaron para usarse en la parte final
(luego de haber seleccionado el consultor al que se le actualizarían los datos) del
136
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
módulo de actualización de datos de consultor. A continuación, se listan todos los
documentos hechos desde cero, indicando para cada uno de ellos (si aplica), los
documentos resultantes de su adaptación. Los nombres de archivo del lado izquierdo
en negrita, corresponden a los nombres los archivos que fueron elaborados desde el
principio, mientras que los nombres de archivo de la derecha en letra normal, son los
archivos producto de la adaptación de los primeros.
S
O
D
Módulos de Datos Maestros / Consultores
VA
R
E
S
E
R
OS
H
C
E
• reg_con.php:
DERact_con3.php
•
reg_con.tpl: act_con3.tpl
•
act_con.php: vis_con.php, cre_cuen.php, act_cuen.php. vis_cuen.php.
•
act_con.tpl: vis_con.tpl, cre_cuen.tpl, act_cuen.tpl. vis_cuen.tpl.
•
act_con2.php: vis_con2.php, cre_cuen2.php, act_cuen2.php, vis_cuen2.php.
•
act_con2.tpl: vis_con2.tpl, cre_cuen2.tpl, act_cuen2.tpl. vis_cuen2.tpl.
•
vis_con3.php
•
vis_con3.tpl
•
cre_cuen3.php: act_cuen3.php
•
cre_cuen3.tpl: act_cuen3.tpl
•
vis_cuen3.php
•
vis_cuen3.tpl
•
actpro_lc.php
137
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
•
actpro_lc.tpl
Módulos de Datos Maestros / Empresas
•
reg_emp.php: act_emp3.php
•
reg_emp.tpl: act_emp3.tpl
•
act_emp.php: vis_emp.php
•
act_emp.tpl: vis_emp.tpl
•
act_emp2.php: vis_emp2.php
•
S
O
D
VA
R
E
S
E
R
S
HO
C
E
R
E
act_emp2.tpl:
D vis_emp2.tpl
•
vis_emp3.php
•
vis_emp3.tpl
Módulos de Datos Maestros / Tipos de Actividad
•
reg_tact.php
•
reg_tact.tpl
•
vig_tact.php: vis_tact.php
•
vig_tact.tpl: vis_tact.tpl
•
vig_tact2.php: vis_tact2.php
•
vig_tact2.tpl: vis_tact2.tpl
138
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
•
vig_tact3.php
•
vig_tact3.tpl
•
vis_tact3.php
•
vis_tact3.tpl
Módulos de Proyectos
•
reg_pro.php: act_pro3.php
•
reg_pro.tpl: act_pro3.tpl
•
E
R
S
HO
S
O
D
VA
R
E
S
C
E
R
E
act_pro.php:
D vis_pro.php
•
act_pro.tpl: vis_pro.tpl
•
act_pro2.php: vis_pro2.php
•
act_pro2.tpl: vis_pro2.tpl
•
vis_pro3.php
•
vis_pro3.tpl
•
inscon_pro.php
•
inscon_pro.tpl
•
inscon_pro2.php
•
inscon_pro2.tpl
•
actdescon_pro.php
•
actdescon_pro.tpl
•
actdescon_pro2.php
139
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
•
actdescon_pro2.tpl
•
viscon_pro.php
•
viscon_pro.tpl
•
viscon_pro2.php
•
viscon_pro2.tpl
S
O
D
VA
R
E
S
Módulos de Registro de Actividades
•
•
E
R
S
HO
C
E
R
E
reg_act.tpl
D
reg_act.php: mod_act3.php
•
mod_act.php: anul_act.php, vis_act.php
•
mod_act.tpl: anul_act.tpl, vis_act.tpl
•
mod_act2.php: anul_act2.php. vis_act2.php
•
mod_act2.tpl: anul_act2.tpl, vis_act2.tpl
•
mod_act3.tpl: vis_act3.tpl
•
anul_act3.php
•
anul_act3.tpl
•
vis_act3.php
140
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
3.2.3.2. SERVICIOS SUSCRITOS
La extranet de Cibiz S.A. funciona con varios servicios, como por ejemplo, el
servicio de hospedaje Web con servidor http APACHE 2.1 y SSL3 provisto por
NETFIRMS ®. El contrato con dicha empresa también estipula el derecho a 10 bases
de datos MySQL 5 para el sistema Web y un servidor PHP5. Es oportuno señalar que
S
O
D
versión 1.0, el cual fue usado para elaborar el menú principal
VA de la extranet.
R
E
S
E
R
OS
H
C
E
3.2.4. INTEGRACIÓN
DERDE CÓDIGO.
se compró la licencia de un programa creador de menús para Web llamado Ultramenu
En la elaboración de la extranet de Cibiz S.A. no hubo una fase dedicada a la
integración del código de la aplicación, en lugar de ello, cuando se terminaba de
desarrollar un módulo, el mismo se subía al hosting para verificar su funcionamiento y
correcta interacción con el resto de sus contrapartes, es decir, los procesos de
desarrollo e integración del código de la aplicación se ejecutaron paralelamente,
práctica que algunos autores denominan integración continua.
3.2.5. PRUEBA DE LA APLICACIÓN WEB.
Al igual que en la fase de integración de código, en el desarrollo de la extranet no
hubo una fase dedicada a la prueba de la aplicación Web, en su lugar, cada vez que se
terminaba de desarrollar un módulo, se verificaba que todas las validaciones de datos
141
Capítulo IV: Análisis e Interpretación de los Resultados
UNIVERSIDAD RAFAEL URDANETA
funcionaran correctamente, y que el sistema en general funcionara como se diseño. Por
otra parte, las pruebas de validación se llevaron a cabo caga vez que se terminaba de
elaborar un grupo de módulos relacionados, como por ejemplo, los módulos de gestión
de cuentas de usuario de la extranet. Vale la pena destacar que para aprobar una
prueba de validación el cliente tenía que estar completamente de acuerdo con el
producto desarrollado.
EC
R
E
D
E
R
S
HO
S
O
D
VA
R
E
S
UNIVERSIDAD RAFAEL URDANETA
aplicación, otro elemento que ayudó a la completación del tercer objetivo, fue la
traducción del diagrama E-R en el esquema de la BD.
El cuarto objetivo “Ejecutar pruebas de funcionamiento a la extranet para la
automatización de los procesos de gestión de los consultores de la empresa Consulting
& Information for Business S.A.”, fue completado al realizarle pruebas de caja blanca y
negra a los módulos de la extranet en su entorno operacional, es decir, en el servidor
S
O
D
VA cuando así lo requería el
subidos a la extranet y los ya presentes. Todas estas
pruebas,
R
E
S
E
R
caso, fueron realizadas desde
OSdistintos navegadores, computadoras, sistemas
H
C
E
operativos y redes,
DERcon el fin de garantizar su correcto funcionamiento en todos los
Web del Hosting. También se hicieron pruebas de integración entre los módulos recién
ambientes. También se le realizaron inspecciones al código y a los documentos de
diseño del sistema.
UNIVERSIDAD RAFAEL URDANETA
CONCLUSIONES
Luego de culminar la investigación, el análisis de los resultados indicó que todos los
objetivos de la misma habían sido alcanzados. A continuación se explican los
indicadores que permiten afirmar que los objetivos fueron completados.
S
O
D
VlosA consultores de la empresa
para la automatización de los procesos de gestión
de
R
E
S
E
R
S S.A.”, fue alcanzado al recolectar los
Consulting & Information H
for O
Business
C
E
R
E
D
requerimientos funcionales de la aplicación en los casos de uso y el diseño de la
El primer objetivo “Identificar los requerimientos para el desarrollo de una extranet
interfaz grafica aprobada por el usuario.
El segundo objetivo “Analizar los requerimientos identificados para realizar el diseño
de la extranet para la automatización de los procesos de gestión de los consultores de
la empresa Consulting & Information for Business S.A.”, también se completó, al diseñar
la estructura del árbol de directorios que contendría los archivos de la interfaz y la lógica
de negocios del sistema, también ayudó al cumplimiento de este objetivo la elaboración
de la arquitectura general del sistema y del modelo entidad-relación de la base de datos
(BD).
El tercer objetivo “Elaborar la extranet para la automatización de los procesos de
gestión de los consultores de la empresa Consulting & Information for Business S.A.”,
fue alcanzado al realizar la versión definitiva de los archivos “.tpl” y “.php” (archivos de
las plantillas SMARTY y PHP) de cada una de las páginas de los módulos de la
UNIVERSIDAD RAFAEL URDANETA
RECOMENDACIONES
A la Universidad Rafael Urdaneta, definir de manera estratégica líneas de
investigación, que permitan el desarrollo de proyectos donde se apliquen las
herramientas vistas en clases, y al mismo tiempo impulsen el desarrollo de nuestra casa
S
O
D
VAS.A., que diseñe un plan de
A la empresa Consulting & Information for Business
R
E
S
E
R
S sus empleados, a partir de la documentación
implementación de la extranet
entre
O
H
C
E
R
E
D
elaborada para la misma, ya que entre más pronto implemente el sistema, más pronto
de estudio.
se acabará el problema con la gestión de los procesos de los consultores.