“N´
estor C´
aceres Vel´
asquez”
Facultad de Ingenier´ıa de Sistemas
Carrera Acad´
emico Profesional de Ingenier´ıa de
Sistemas
TESIS:
DESARROLLO DE UN PORTAL WEB PARA EL I.S.E.P. ACOMAYO (CUSCO) UTILIZANDO LA METODOLOG´IA OOHDM
TESIS
PRESENTADO POR EL BACHILLER:
Jos´e luis Vilca Condori
PARA OPTAR EL T´ITULO PROFESIONAL DE:
SISTEMAS
CARRERA ACAD´EMICO PROFESIONAL DE INGENIER´IA DE
SISTEMAS
—————————————————————————–
“
DESARROLLO DE UN PORTAL WEB PARA EL
I.S.E.P. ACOMAYO (CUSCO) UTILIZANDO LA
METODOLOG´
IA OOHDM
”
TESIS PRESENTADO POR EL BACHILLER
Jos´e luis Vilca Condori
PARA OPTAR EL T´ITULO PROFESIONAL DE:
INGENIERO DE SISTEMAS
APROBADO POR:
FECHA: Marzo 2015
PRESIDENTE:
PRIMER MIEMBRO:
SEGUNDO MIEMBRO:
Tabla de Contenido III
Lista de Tablas VI
Lista de Figuras VII
1. El problema, objetivos e hip´otesis 1
1.1. T´ıtulo . . . 1
1.2. Problema de Investigaci´on . . . 1
1.2.1. An´alisis de la Situaci´on Problem´atica . . . 1
1.3. Definici´on del Problema . . . 2
1.4. Planteamiento del Problema . . . 3
1.5. Formulaci´on del Problema . . . 3
1.5.1. Problema General . . . 3
1.5.2. Problemas Espec´ıficos . . . 3
1.6. Objetivos . . . 4
1.6.1. Objetivo General . . . 4
1.6.2. Objetivos Espec´ıficos . . . 4
1.7. Justificaci´on . . . 4
1.8. Hip´otesis y Variables . . . 5
1.8.1. Hip´otesis General . . . 5
1.8.2. Hip´otesis Espec´ıficas . . . 5
1.8.3. Variables . . . 5
1.8.4. Operacionalizaci´on de Variables . . . 6
1.9. Planteamiento Operacional . . . 6
1.9.1. T´ecnicas e Instrumentos de Verificaci´on . . . 6
2. Marco te´orico 7 2.1. Antecedentes . . . 7
2.2. Aplicaciones WEB . . . 11
2.3.2. Tipos de Requerimientos . . . 13
2.3.3. Actividades de la Ingenier´ıa de Requerimientos . . . . 17
2.3.4. An´alisis y Negociaci´on de Requisitos . . . 20
2.3.5. Especificaci´on de Requisitos . . . 22
2.3.6. Modelado del Sistema . . . 23
2.3.7. Validaci´on de Requisitos . . . 24
2.4. Hipermedia . . . 24
2.5. Ingenier´ıa web . . . 29
2.6. Categor´ıas web . . . 32
2.7. Metodolog´ıas web . . . 35
2.8. HDM- A Model-Based Approach to Hypertext Aplication Design 41 2.8.1. HDM . . . 42
2.9. RMM- Relationship Management Methogology . . . 47
2.9.1. Fases de RMM . . . 49
2.10. EORM- Enhanced Object Relationship Methodology . . . 53
2.10.1. Fases de EORM . . . 53
2.11. The MacWeb Hypermedia Development Enviroment . . . 58
2.11.1. Fases de Macweb . . . 58
2.12. OOHDM (Object Oriented Hypermedia Design Method) . . . 60
2.12.1. OOHDM . . . 63
2.12.2. Fases de OOHDM . . . 64
2.13. Marco Conceptual . . . 79
3. Metodolog´ıa de la Investigaci´on 83 3.1. M´etodo de Investigaci´on . . . 83
3.2. Dise˜no de la Investigaci´on . . . 83
3.2.1. Dise˜no de la Investigaci´on . . . 83
3.2.2. Tipo de Investigaci´on . . . 83
3.2.3. Nivel de Investigaci´on . . . 83
3.3. Poblaci´on y Muestra . . . 84
3.3.1. Poblaci´on . . . 84
3.3.2. Muestra . . . 84
3.4. T´ecnicas e instrumentos de investigaci´on . . . 84
3.5. Ubicaci´on Espacial . . . 84
3.6. Ubicaci´on Temporal . . . 84
4.2. M´odulo . . . 86
4.2.1. Ventana principal . . . 86
4.2.2. Requisitos Funcionales . . . 87
4.2.3. Requisitos no funcionales . . . 88
4.3. Modelamiento de la aplicaci´on usando el m´etodo OOHDM . . 89
Conclusiones 95
Recomendaciones 96
Referencias Bibliogr´aficas 98
Referencias Internet 101
2.1. Relaciones de los elementos de HDM . . . 44
2.2. Ejemplo de modelo HDM . . . 46
2.3. Primitivas del modelo RMDM . . . 49
2.4. Diagrama de slices para el ejemplo . . . 51
2.5. Ejemplo de modelo de an´alisis de EORM . . . 54
2.6. Ejemplo de modelo de dise˜no de EORM . . . 56
2.7. Definici´on de la clase enlace . . . 67
2.8. Ejemplo de diagrama de clases navegacionales . . . 69
2.9. Ejemplo de descripci´on de clases navegacionales . . . 70
2.10. Ejemplo de contexto navegacional . . . 71
2.11. Ejemplo de adv . . . 74
2.12. Ejemplo de diagrama de configuraci´on . . . 75
4.1. Dise˜no ADV principal de la aplicaci´on . . . 90
4.2. Interfaz Aplicaci´on . . . 90
4.3. Interfaz Aplicaci´on . . . 91
4.4. Interfaz Aplicaci´on . . . 92
4.5. Interfaz Aplicaci´on . . . 93
4.6. Interfaz Aplicaci´on . . . 93
4.7. Ingreso al Sistema . . . 94
El problema, objetivos e
hip´
otesis
1.1.
T´ıtulo
DESARROLLO DE UN PORTAL WEB PARA EL I.S.E.P.
ACOMA-YO (CUSCO) UTILIZANDO LA METODOLOG´IA OOHDM (M´etodo de
Dise˜no Hipermedia Orientado a Objetos).
1.2.
Problema de Investigaci´
on
1.2.1.
An´
alisis de la Situaci´
on Problem´
atica
En la red Internet se destaca la telara˜na de cobertura mundial, conocida
como WWW o web. Aqu´ı encajan todas las nuevas tecnolog´ıas como Java,
JavaScript y otros lenguajes, que ampl´ıan las posibilidades del web para la
interactividad, la distribuci´on de informaci´on y las comunicaciones. Es as´ı,
que en la red existen distintos mecanismos de acceso y distribuci´on de la
enorme cantidad de informaci´on disponible, siendo esta una principal fuente
de informaci´on.
Existe, por lo tanto, un inter´es creciente por parte de los estudiantes y
docentes en utilizar este recurso de WWW para as´ı poder compartir, difundir
y captar informaci´on haciendo que las instituciones brinden mejores servicios
a sus usuarios.
Ahora en el Instituto Superior Acomayo que est´a ubicado en el Cusco
existe el problema de que no utiliza el WWW o web, por lo que falta difusi´on
del mismo, y al ser esta una tecnolog´ıa ya muy difundida hace necesario el
desarrollo de un portal web que nos muestre la informaci´on necesaria del
instituto.
Es por esto que nos planteamos la siguiente interrogante: Mediante el
desarrollo de un portal web para el instituto Acomayo mejoraremos la calidad
educativa que presta a los estudiantes y docentes.
1.3.
Definici´
on del Problema
La realizaci´on de este trabajo es importante ya que con esto
introducire-mos al Instituto Superior Acomayo en el uso de las tecnolog´ıas de Internet
muy de moda en nuestra actualidad.
Con lo cual ser´a posible la mejora la calidad educativa que presta esta
instituci´on a sus estudiantes y docentes.
Por lo que es importante el desarrollo de este portal que utilice los recursos
OOHDM (M´etodo de Dise˜no Hipermedia Objeto Orientado) es un m´etodo
para el desarrollo de aplicaciones Web. Es uno de los primeros m´etodos para
separar de las dificultades que defin´ıan diferentes modelos que se separaban
en las siguientes fases del dise˜no: Requisitos, conceptual, navegaci´on, interfaz
abstracta y ejecuci´on. OOHDM, y su sucesor, SHDM (M´etodo de dise˜no
Sem´antica Hipermedia, utilizado por modelos de web Sem´antica) se apoyan
en c´odigo abierto, disponible libremente, ejecutado en diferentes ambientes.
Con el uso de este m´etodo podemos desarrollar una aplicaci´on necesaria
en esta instituci´on.
1.4.
Planteamiento del Problema
1.5.
Formulaci´
on del Problema
1.5.1.
Problema General
¿Como se analiza un portal WEB empleando OOHDM (M´etodo de Dise˜no
Hipermedia Orientado a Objetos) en el I.S.E.P. ACOMAYO (CUSCO)?
1.5.2.
Problemas Espec´ıficos
- ¿Analizar el portal WEB con otras aplicaciones para el I.S.E.P.
ACO-MAYO (CUSCO) ?
- ¿Que dise˜no es m´as accesible a la plataforma desde cualquier tipo de
terminal de usuario (ordenadores personales, dispositivos port´atiles, tel´efonos
1.6.
Objetivos
1.6.1.
Objetivo General
¿ Desarrollar la metodolog´ıa OOHDM, en el desarrollo del Portal WEB
de la I.S.E.P. ACOMAYO (CUSCO) ?
1.6.2.
Objetivos Espec´ıficos
Analizar el portal web con la metodologia OOHDM y otras aplicaci´ones
web.
Dise˜nar accesos a la plataforma para cualquier tipo de terminal de
usuario (ordenadores personales, dispositivos port´atiles, tel´efonos
inte-ligentes).
1.7.
Justificaci´
on
El uso de las nuevas tecnolog´ıas de comunicaci´on permite una
interac-ci´on m´as asertiva entre las instituciones y sus integrantes, en este caso se
beneficiar´ıa la Instituto superior ACOMAYO (CUSCO) de poseer un
v´ıncu-lo electr´onico, como lo es el portal web, dando una mayor accesibilidad de
datos actuales, y en algunos casos en tiempo real, referentes a las actividades
inherentes al instituto, fortaleci´endose e innovando la imagen del mismo en
la llamada era de la informaci´on, permitiendo un mayor alcance y presencia
La realizaci´on de este trabajo es importante ya que con esto
introducire-mos al Instituto Superior Acomayo en el uso de las tecnolog´ıas de internet
muy de moda en nuestra actualidad.
Con la cual es posible la mejorar el servicio que presta la instituci´on a
sus usuarios.
Por lo que es importante el desarrollo de este portal que utilice los recursos
que ofrece la web en el internet.
1.8.
Hip´
otesis y Variables
1.8.1.
Hip´
otesis General
- Con el Desarrollo de la metodolog´ıa OOHDM mejora el portal web.
1.8.2.
Hip´
otesis Espec´ıficas
- Edificar el analisis porque facilita el acceso al portal web .
- El uso de la metodolog´ıa OOHDM garantiza el acceso a la plataforma
desde cualquier tipo de terminal de usuario (ordenadores personales,
dispo-sitivos port´atiles, tel´efonos inteligentes).
1.8.3.
Variables
Variable Independiente
Desarrollo de un Portal WEB.
Metodolog´ıa OOHDM.
1.8.4.
Operacionalizaci´
on de Variables
Variable Dependiente
Metodologia OOHDM Indicadores
Fase conceptual Fase Navegacional Fase de Interfaz Abstracta
Fase de Implementaci´on
Variable Independiente
Portal WEB Indicadores
An´alisis Dise˜no Implementaci´on
Prueba
1.9.
Planteamiento Operacional
1.9.1.
T´
ecnicas e Instrumentos de Verificaci´
on
Para el estudio de la variable antes mencionada as´ı como sus indicadores
Marco te´
orico
2.1.
Antecedentes
Dentro de los antecedentes del problema de la investigaci´on podemos citar
los siguientes, art´ıculos, tesis: Damos a conocer diferentes tesis de
investiga-ci´on que han sido realizados en diferentes universidades del mundo as´ı como:
Tesis para optar el grado de Ingeniero:
Tesis Locales
-IMPLEMENTACI ´ON DE APLICACIONES WEB PARA EL COLEGIO SAN ROM ´AN USANDO LA METODOLOG´IA(HDM)[A]
-UNIVERSIDAD ALAS PERUANAS JULIACA -ANDRES MAMANI QUISPE
-OCTUBRE 2011 Conclusi´on
- El desarrollo de la aplicaci´on que se presenta en este proyecto surge de la
necesidad de organizaci´on de los recursos de colegio san roman. Para ello, se
propuso el dise˜no de un repositorio de recursos de investigaci´on, centralizado
y coordinado donde los pudieran brindar en una base de datos del colegio de
ciudad de juliaca as´ı como realizar consultas, b´usquedas y descargas de los
mismos.
- Se opta por el desarrollo de una aplicaci´on que en un futuro pr´
oxi-mo se instalar´a en un ordenador del ´area que realiza las tareas de
servi-dor, concretamente en el servidor donde se aloja la p´agina web del ´area
(http://sanroman.edu.pe). Por tanto, esta aplicaci´on estar´a orientada a dar
mayor servicio y utilidad a la p´agina principal .
- Para abordar el dise˜no de la aplicaci´on propuesta, se han estudiado las
posibles soluciones software, enumerando y destacando en el segundo cap´ıtulo
de este documento aquellas que, por sus ventajas desde el punto de vista de la
arquitectura, se han elegido para realizar la aplicaci´on. En el mismo cap´ıtulo
tambi´en se aborda, desde el punto de vista del dise˜no de la aplicaci´on, los
motivos que han llevado al autor a elaborar una aplicaci´on desde el principio.
Entre los motivos enumerados destaca la necesidad de obtener el m´aximo
aprovechamiento de los recursos y servicios que ofrece el ordenador servidor
del ´area, as´ı como optimizar las funcionalidades requeridas en este proyecto.
Tesis Nacionales
-APLICACIONES WEB PARA LA EMPRESA TAURUS SAC USANDO LA METODOLOG´IA OOHDM)[B]
-UNIVERSIDAD ALAS PERUANAS SEDE TRUJILLO -NESTOR AQUISE LOPEZ
Conclusi´on
- Contar con una metodolog´ıa adecuada a la hora de desarrollar una
aplicaci´on Web, ayudar´ıa a disminuir los problemas de dise˜no que han venido
presentando este tipo de aplicaciones, reduciendo sus costos de desarrollo e
implementaci´on, haciendo que los objetivos planteados para el proyecto se
cumplan de manera r´apida y efectiva.
- El desarrollo de aplicaciones efectivas permite disminuir el rechazo que,
normalmente, tienen los usuarios a la hora de aceptar una nueva aplicaci´on.
En el caso de aplicaciones Web, este rechazo puede ser m´as evidente, ya
que es una tecnolog´ıa relativamente nueva y con caracter´ısticas de uso y
navegaci´on totalmente diferentes a las aplicaciones tradicionales, lo que hace
que la utilizaci´on de una metodolog´ıa de desarrollo adecuada para llevar a
cabo una aplicaci´on Web sea mucho m´as relevante.
- Hay que destacar que cada vez son m´as comunes las aplicaciones Web
dentro de las organizaciones, inclusive muchas aplicaciones tradicionales han
sido migradas a la tecnolog´ıa Web, por las bondades que esta ofrece. Se
prev´e que a mediano plazo las aplicaciones Web desplacen a las aplicaciones
tradicionales, una muestra de esto son compa˜n´ıas como Microsoft y Google,
que se encuentran trabajando en el primer sistema operativo Web, lo que
producir´a una nueva era en el desarrollo de software, en donde la ingenier´ıa
- Por lo expuesto, es fundamental que se realicen investigaciones
relacio-nadas con el ´area de la ingenier´ıa Web, que aporten conocimientos y
expe-riencias, con la finalidad de contar, cada vez m´as, con una s´olida base te´orica
que ayude a dise˜nar y desarrollar aplicaciones Web, y que faciliten la tarea de
los equipos de trabajo en la transici´on de la migraci´on de software tradicional
al ambiente Web.
Tesis Internacionales
-METODOLOG´IA DIRIGIDA POR MODELOS PARA EL DI-SE ˜NO DE FUNCIONALIDAD VOL ´ATIL EN APLICACIONES WEB)[C]
-UNIVERSIDAD NACIONAL DE LA PLATA. ARGENTINA -NESTOR AQUISE LOPEZ
-AGOSTO 2012 Conclusi´on
- Para dar una soluci´on a este problema de funcionalidad vol´atil en
apli-caciones Web se ha propuesto un enfoque modular dirigido por modelos que
puede ser aplicado a casi cualquier metodolog´ıa de ingenier´ıa Web; en este
caso se utiliz´o OOHDM. El eje de la tesis es el dise˜no sim´etrico de
cual-quier funcionalidad vol´atil por m´as simple que sea. Este concepto se propaga
a las diferentes modelos de una aplicaci´on Web (conceptual, navegacional
e interfaz) y para ello se definieron herramientas conceptuales que
permi-ten el adecuado modelado de los requerimientos vol´atiles de forma sim´etrica,
- Siguiendo el enfoque, las funcionalidades vol´atiles son detectadas en
las etapas tempranas del desarrollo de Software para identificar conflictos
con otros requerimientos corre y proponer soluciones de forma autom´atica o
semi-autom´atica. Es un novedoso aporte que mediante la formalizaci´on de
re-querimientos de interacci´on utilizando WebSpec se pueden detectar conflictos
(de estructura y de navegaci´on) a nivel sint´actico y sem´antico. Para detectar
conflictos e inconsistencias los requerimientos de en aplicaciones, cada nuevo
requerimiento vol´atil es validado contra los requerimientos consolidados (que
ya demostraron mantener la consistencia).
2.2.
Aplicaciones WEB
Las aplicaciones hipermedia han evolucionado en los ´ultimos a˜nos y se
han concentrado mayormente en la web. Las antiguas aplicaciones
distribui-das en cd s dieron lugar a aplicaciones din´amicas, de constante actualizaci´on
e incluso personalizables, capaces de adaptarse a los tipos de usuarios y en
ca-sos avanzados, a cada usuario en particular. Estas caracter´ısticas encuentran
el medio ideal en la web, ya que de otra forma ser´ıa costoso su
manteni-miento y evoluci´on. La complejidad del desarrollo ocurre a diferentes niveles:
dominios de aplicaci´on sofisticados (financieros, m´edicos, geogr´aficos, etc.);
la necesidad de proveer acceso de navegaci´on simple a grandes cantidades de
datos multimedia les, y por ´ultimo la aparici´on de nuevos dispositivos para
los cuales se deben construir interfaces web f´aciles de usar. Esta complejidad
de los asuntos de modelizaci´on en forma clara y modular. [1] La metodolog´ıa
OOHDM, presentada en la pr´oxima secci´on, ha sido utilizada para dise˜nar
diferentes tipos de aplicaciones hipermedia como galer´ıas interactivas,
pre-sentaciones multimedia y como veremos en este trabajo, aplicaciones web.
El ´exito de esta metodolog´ıa es la clara identificaci´on de los tres diferentes
niveles de dise˜no en forma.
2.3.
Ingenier´ıa de Requerimientos
Uno de los puntos importantes de la Ingenier´ıa del Software es la
especi-ficaci´on de Requisitos o Ingenier´ıa de requerimientos el cu´al es el proceso de
descubrir, analizar, documentar y verificar servicios y restricciones. La
Inge-nier´ıa de Requerimientos es base para el proceso de desarrollo de software,
por ello se defini´o lo que es un requerimiento. La meta de la ingenier´ıa de
requerimientos (IR) es entregar una especificaci´on de requisitos de software
correcta y completa. Otros conceptos de ingenier´ıa de requerimientos que
se encontraron son: Ingenier´ıa de Requerimientos ayuda a los ingenieros de
software a entender mejor el problema en cuya soluci´on trabajar´an. Incluye
el conjunto de tareas que conducen a comprender cu´al ser´a el impacto del
software sobre el negocio, qu´e es lo que el cliente quiere y c´omo interactuar´an
los usuarios finales con el software. La ingenier´ıa de requerimientos es el
pro-ceso de desarrollar una especificaci´on de software. [6] Las especificaciones
pretenden comunicar las necesidades del sistema del cliente a los
se utiliz´o para definir todas las actividades involucradas en el
descubrimien-to, documentaci´on y mantenimiento de los requerimientos para el sistema
de Control Presupuestal, donde es muy importante tomar en cuenta que el
aporte de la IR viene a ayudar a determinar la viabilidad de llevar a cabo
el software (si es factible llevarlo a cabo o no),pasando posteriormente por
un sub proceso de obtenci´on y an´alisis de requerimientos, su especificaci´on
formal, para finalizar con el sub proceso de validaci´on donde se verifica que
los requerimientos definen el sistema que el cliente requiere. Independiente
de la implementaci´on.
2.3.1.
Requerimientos
El t´ermino requerimiento no se utiliza de una forma constante en la
pro-ducci´on de software. En algunos casos, un requerimiento es simplemente una
declaraci´on abstracta de alto nivel de un servicio que debe proporcionar el
sistema o una restricci´on de ´este. En este caso se utiliz´o el t´ermino
reque-rimiento para determinar cu´ales ser´ıan las funciones que el sistema debe
realizar y satisfacer las necesidades del cliente.
2.3.2.
Tipos de Requerimientos
Algunos de los problemas que surgen durante el proceso de ingenier´ıa de
requerimientos son resultado de no haber hecho una clara separaci´on entre los
diferentes niveles de descripci´on de los requisitos. Aqu´ı se distinguieron con
abstractos de alto nivel, del sistema para designar la descripci´on detallada de
lo que el sistema debe hacer. Los requerimientos se dividen en dos categor´ıas:
requerimientos de usuario y requerimientos del sistema.
Requerimientos de Usuario
Para la declaraci´on de las necesidades del cliente dentro del documento
de requerimientos se utilizaron los requerimientos del usuario, ya que estos
permitieron al cliente comprender y visualizar el alcance del sistema en un
lenguaje com´un.
Requerimientos del Sistema
Los requerimientos del sistema son versiones extendidas de los
requeri-mientos que son utilizados por los ingenieros de software como punto de
par-tida para el dise˜no del sistema. Agregan detalle y explican como el sistema
debe proporcionar los requerimientos del usuario. Pueden ser utilizados como
parte del contrato para la implementaci´on del sistema y por lo tanto, deben
ser una especificaci´on completa y consistente del sistema entero. A menudo
se utiliza el lenguaje natural para redactar, adem´as de los requerimientos
del usuario, las especificaciones de requerimientos del sistema. Sin embargo,
debido a que los requerimientos del sistema son m´as detallados que los
re-querimientos del usuario, las especificaciones en lenguaje natural pueden ser
confusas y dif´ıciles de entender. Los requerimientos de sistema de software
se clasificaron en funcionales y no funcionales, o como requerimientos del
1. Requerimientos Funcionales.- Son declaraciones de los servicios que debe proporcionar el sistema, de la manera en que este debe reaccionar a
entradas particulares y de c´omo se debe comportar en situaciones
particula-res. En algunos casos, los requerimientos funcionales de los sistemas tambi´en
pueden declarar expl´ıcitamente lo que el sistema debe hacer.
2. Requerimientos no Funcionales.-Son restricciones de los servicios o funciones ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el
proceso desarrollo y est´andares. Normalmente los requerimientos funcionales
apenas se aplican a caracter´ısticas o servicios individuales del sistema.
3. Requerimientos del Dominio.- Son requerimientos que provienen del dominio de aplicaci´on del sistema y que reflejan las caracter´ısticas y
restricciones de ese dominio. Pueden ser funcionales o no funcionales.
Caracter´ısticas de un Requerimiento
Los requerimientos formulados deb´ıan satisfacer varias caracter´ısticas. Si
no lo hac´ıan, ten´ıan que ser reformulados hasta hacerlo. Para ello un
reque-rimiento debe ser:
- Necesario: Lo que pida un requerimiento debe ser necesario para el producto.
- No ambiguo:El texto debe ser claro, preciso y tener una ´unica inter-pretaci´on posible.
referenciar los aspectos importantes
- Consistente: Ning´un requerimiento debe entrar en conflicto con otro requerimiento diferente, ni con parte de otro. Asimismo, el lenguaje empleado
entre los distintos requerimientos debe ser consistente tambi´en.
- Completo: Los requerimientos deben contener en s´ı mismos toda la informaci´on necesaria, y no remitir a otras fuentes externas que los expliquen
con m´as detalle.
- Alcanzable:Un requerimiento debe ser un objetivo realista, posible de ser alcanzado con el dinero, el tiempo y los recursos disponibles.
- Verificable:Se debe poder verificar con absoluta certeza, si el requeri-miento fue satisfecho o no. Esta verificaci´on puede lograrse mediante
inspec-ci´on, an´alisis,demostraci´on o testeo.[4]
Dificultades para Definir los Requerimientos
- Durante la etapa de especificaci´on de requerimientos (IR) se presentaron
inconvenientes los cuales fueron importantes de identificar, a continuaci´on se
presenta un listado de los problemas m´as comunes que se dieron durante este
proceso:
- Los requerimientos no eran obvios y proven´ıan de varias fuentes, ya que
se trataba de un ´area financiera.
- Fueron dif´ıciles de expresar en palabras (el lenguaje es confuso).
- La cantidad de requerimientos del proyecto fueron un poco dif´ıcil de
- El usuario no pod´ıa explicar lo que hace durante el proceso de control
de presupuesto. Tend´ıa a recordar lo excepcional y olvidar lo rutinario
Los usuarios ten´ıan distinto vocabulario que los analistas.Para resolver
estos inconvenientes, se utiliz´o la Ingenier´ıa de Requerimientos, ya que aqu´ı se
incluyen algunas t´ecnicas de obtenci´on de requisitos que ayudaron en la etapa
de Especificaci´on de Requerimientos
2.3.3.
Actividades de la Ingenier´ıa de Requerimientos
Se identific´o que existen cinco actividades b´asicas que se tienen que llevar
a cabo para completar el proceso de software. Estas actividades ayudaron
a reconocer la importancia que tiene, para el desarrollo de un proyecto de
software, realizar una especificaci´on y administraci´on adecuada de los
reque-rimientos de los clientes o usuarios. Las cinco actividades identificadas son:
Extracci´on de Requisitos, An´alisis y Negociaci´on de Requisitos,
Especifica-ci´on de Requisitos, Modelado del Sistema, Validaci´on y Gesti´on de
Requisi-tos, ser´an explicadas a continuaci´on cada una de ellas. O no funcionales.
Extracci´on de Requisitos
En principio, parece bastante simple -preguntar al cliente, a los usuarios
y a los que est´an involucrados en los objetivos del sistema o producto y sean
expertos, investigar c´omo el sistema o producto se ajusta a las necesidades
del negocio, y finalmente, c´omo el sistema o producto va a ser utilizado en
el d´ıa a d´ıa
problemas que ayudan a comprender por qu´e la obtenci´on de requisitos es
costosa.
Problemas de alcance. El l´ımite del sistema est´a mal definido o los
deta-lles t´ecnicos innecesarios, que han sido aportados por los clientes/usuarios,
pueden confundir m´as que clarificar los objetivos del sistema.
- Problemas de comprensi´on. Los clientes/usuarios no est´an
completa-mente seguros de lo que necesitan, tienen una pobre compresi´on de las
capa-cidades y limitaciones
de su entorno de computaci´on, no existe un total entendimiento del
do-minio del problema, existen dificultades para comunicar las necesidades al
ingeniero del sistema, la omisi´on de informaci´on o por considerar que es
ob-via, especificaci´on de requisitos que est´an en conflicto con las necesidades de
otros clientes/usuarios, o especificar requisitos ambiguos o poco estables.
- Problemas de volatilidad. Los requisitos cambian con el tiempo.Para
ayudar a solucionar estos problemas, los analistas del sistema se pueden
apro-ximar de manera organizada a trav´es de reuniones con el cliente para definir
los requisitos. Un conjunto de actuaciones para la obtenci´on de requisitos,
que est´an descritos en las tareas siguientes:
- Valorar el impacto en el negocio y la viabilidad t´ecnica del sistema
propuesto.
- Identificar las personas que ayudar´an a especificar requisitos y contrastar
- Definir el entorno t´ecnico (arquitectura de computaci´on, sistema
opera-tivo,necesidades de telecomunicaciones) en el sistema o producto a desarrollar
e integrar.
Identificar restricciones de dominio (caracter´ısticas espec´ıficas del entorno
de negocio en el dominio de la aplicaci´on) que limiten la funcionalidad y
rendimiento del sistema o producto a construir.
Definir uno o m´as m´etodos de obtenci´on de requisitos (entrevistas, grupos
de trabajo,equipos de discusi´on).
- Solicitar la participaci´on de muchas personas para que los requisitos se
definan desde diferentes puntos de vista, asegurarse de identificar lo
funda-mental de cada requisito registrado.
- Identificar requisitos ambiguos como candidatos para el prototipado, y
crear escenarios de uso
para ayudar a los clientes/usuarios a identificar mejor los
requisitosfun-damentales.El resultado alcanzado como consecuencia de la identificaci´on de
requisitos puede variar dependiendo del tama˜no del sistema o producto a
construir. Para grandes sistemas, el producto obtenido debe incluir:
- Una relaci´on de necesidades y caracter´ısticas.
Un informe conciso del alcance del sistema o producto.
- Una lista de clientes, usuarios y otros intervinientes que deben participar
en la actividad de obtenci´on de requisitos.
- Una descripci´on del entorno t´ecnico del sistema.
y las restricciones del dominio aplicables a cada uno.
Un conjunto de escenarios que permiten profundizar en el uso del sistema
o producto bajo diferentes condiciones operativas, y cualquier prototipo
desa-rrollado para definir mejor los requisitos.Cada uno de los productos obtenidos
debe ser revisado por las personas que hayan participado en la obtenci´on de
los requisitos. Es importante, que la extracci´on de los requisitos sea efectiva,
ya que la aceptaci´on del sistema depender´a de cu´an bien ´este satisfaga las
necesidades del cliente.
2.3.4.
An´
alisis y Negociaci´
on de Requisitos
Sobre la base de la extracci´on realizada anteriormente, comienza esta fase
la cual se enfoc´o en descubrir los problemas con los requerimientos del
siste-ma identificados.Usualmente se hace un an´alisis luego de haber producido un
bosquejo inicial del documento de requerimientos; en esta etapa se leyeron
los requerimientos, se conceptuaron,se investigaron, se intercambiaron ideas
con el resto del equipo, se resaltaron los problemas,se buscaron alternativas
y soluciones, y luego se fijaron reuniones con el cliente para discutir los
re-querimientos.Una vez recopilados los requisitos, se agruparon por categor´ıas
y se organizaron en subconjuntos, se estudi´o cada requisito en relaci´on con
el resto, se examinaron los requisitos en su consistencia, completitud y
am-big¨uedad (Caracter´ısticas de un requerimiento), y se clasificaron en base a
Al iniciarse la actividad del an´alisis de requisitos se plantearon las
si-guientes cuestiones:
¿Cada requisito es consistente con los objetivos generales del sistema/producto?
¿Tienen todos los requisitos especificados el nivel adecuado de
abstrac-ci´on? Es decir, ¿algunos requisitos tienen un nivel de detalle t´ecnico
inapro-piado en esta etapa?
¿El requisito es necesario o representa una caracter´ıstica a˜nadida que
puede no ser esencial a la finalidad del sistema?
¿Cada requisito est´a delimitado y sin ambig¨uedad?
Cada requisito tiene procedencia. Es decir, ¿existe un origen (general o
espec´ıfico)conocido para cada requisito?
¿Existen requisitos incompatibles con otros requisitos?
¿Es posible lograr cada requisito en el entorno t´ecnico donde se
inte-grar´a el sistema o producto?
¿Se puede probar el requisito una vez implementado?
Es corriente en clientes y usuarios solicitar m´as de lo que puede
realizar-se,asumiendo recursos de negocio limitados. Tambi´en es relativamente com´un
en clientes y usuarios el proponer requisitos contradictorios, argumentando
que su versi´on es esencial por necesidades especiales. Si los clientes no
pue-den facilitar los requisitos, el riesgo de errar es muy alto. Los analistas del
sistema pueden resolver estos conflictos a trav´es de un proceso de
negocia-ci´on. Los clientes, usuarios y el resto de los involucrados discuten los posibles
requisito son identificados y analizados. Se efect´uan estimaciones del
esfuer-zo de desarrollo que se utilizan para valorar el impacto de cada requisito en
el coste del proyecto y en el plazo de entrega. Utilizando un procedimiento
iterativo, se ir´an eliminando requisitos, se ir´an combinando y/o modificando
para conseguir satisfacer los objetivos planteados
2.3.5.
Especificaci´
on de Requisitos
En esta fase se documentaron los requerimientos acordados con el
clien-te. En el contexto de un sistema basado en computadoras (y software), el
t´ermino especificaci´on significa distintas cosas para diferentes personas. Una
especificaci´on puede ser un documento escrito, un modelo gr´afico, un modelo
matem´atico formal, una colecci´on de escenarios de uso, un prototipo o una
combinaci´on de lo anteriormente citado.Algunos sugieren que debe
desarro-llarse una plantilla y usarse en la especificaci´on del sistema, argumentando
que as´ı se consiguen los requisitos para que sean presentados de una forma
m´as consistente y m´as comprensible.Para este caso se considero como mejor
alternativa un documento escrito(Documento de Especificaci´on de
Requisi-tos), combinado con descripciones en lenguaje natural y modelos gr´aficos.La
Especificaci´on del Sistema es el producto final sobre los requisitos del
siste-ma obtenido por el ingeniero. Sirve como fundamento para la ingenier´ıa del
hardware, ingenier´ıa del software, la ingenier´ıa de bases de datos y la
inge-nier´ıa humana.La Especificaci´on de Requisitos ayud´o a describir la funci´on
desarrollo. En s´ı, la especificaci´on del sistema describe la informaci´on (datos
y control) que entra y sale del sistema.
2.3.6.
Modelado del Sistema
Al terminar de especificar el sistema, se model´o cada uno de los
requi-sitos, para un mejor entendimiento del proceso de Control de Presupuesto.
Considere por un momento que a usted se le ha requerido para especificar
los requisitos para la construcci´on de una cocina. Se conocen las
dimensio-nes del lugar, la localizaci´on de las puertas y ventanas y el espacio de pared
disponible. Debe especificar todos los armarios y electrodom´esticos e
indi-car d´onde colocarlos.¿Ser´a una especificaci´on v´alida? La respuesta es obvia.
Para especificar completamente lo que se va a desarrollar, se necesita un
modelo de la cocina con toda la informaci´on necesaria, esto es, un
antepro-yecto o una representaci´on en tres dimensiones que muestre las posiciones
de los armarios y electrodom´esticos, y sus relaciones.Con el modelo ser´a
re-lativamente f´acil asegurar la eficiencia del trabajo (un requisito de todas las
cocinas), la est´etica visual de la sala (es un requisito personal, aunque muy
importante).Se construyeron modelos del sistema por la misma raz´on que se
desarrollo para una cocina un anteproyecto o una representaci´on en 3D. Fue
importante evaluar los componentes que integrar´ıan el sistema y sus
relacio-nes entre s´ı; determinar c´omo est´an reflejados los requisitos, y valorar como
2.3.7.
Validaci´
on de Requisitos
La validaci´on se considera por muchos autores como la actividad final de
la IR. Su objetivo es, ratificar los requerimientos, es decir, se verifican todos
los requerimientos que aparecen en el documento especificado (Documento
de Requerimientos) para asegurarse que se represent´o una descripci´on, por
lo menos, aceptable del sistema que se desea implementar. Esto implica que
se verifique que los requerimientos fueran consistentes y estuvieran
comple-tos.Es necesario recalcar que no existe un proceso ´unico que sea v´alido de
aplicar en todas las organizaciones. Cada organizaci´on desarrolla su propio
proceso de acuerdo al tipo de producto que se est´a desarrollando, a la
cul-tura organizacional, y al nivel de experiencia y habilidad de las personas
involucradas en la ingenier´ıa de requerimientos.
2.4.
Hipermedia
El t´ermino HIPERMEDIA, combinaci´on de los conceptos HIPERtexto
y multiMEDIA, hace referencia a una tecnolog´ıa de construcci´on de
(hi-per)documentos que permite a los lectores encontrar facilmente la
informa-ci´on que realmente necesitan, de la manera que ellos decidan, a trav´es de
en-laces establecidos por el autor entre los diferentes elementos de informaci´on
multimedia (texto, sonido, imagen, v´ıdeo, etc.) que conforman el documento.
Aunque en la literatura se suelen utilizar indistintamente ambos, el t´ermino
de informaci´on contienen ´unicamente texto. Tambi´en suele confundirse con el
t´ermino Multimedia, cuando ´este, en realidad, hace referencia a sistemas que
contienen y presentan texto, im´agenes, sonido, video, etc. pero sin enlaces
entre estos elementos de informaci´on.
Para ilustrar las posibilidades de esta tecnolog´ıa, se podr´ıa imaginar
co-mo ejemplo de documento hipermedia o hiperdocumento, un posible informe
policial sobre un accidente de tr´afico que, adem´as del texto describiendo el
si-niestro, incorpore fotograf´ıas digitalizadas tomadas por los agentes, la versi´on
grabada de la propia voz o en v´ıdeo de los testigos, im´agenes .escaneadas”de
los informes m´edicos, datos geoespaciales del lugar donde se produjo el
si-niestro, etc. El documento deber´ıa, por tanto, incluir enlaces entre estos
elementos que establezcan las posibles v´ıas de acceso o de navegaci´on por
la informaci´on. En este ejemplo de tr´afico podr´ıa existir un enlace a una
se-cuencia de v´ıdeo donde un testigo da explicaciones, desde el lugar del texto
del informe en el que aparece el nombre de esa persona.
Un hiperdocumento se compone, en principio, de dos tipos de elementos:
por un lado estar´ıan los nodos, o ¸contenedores”de la informaci´on
multime-dia; y por otro los enlaces, que interconectan los nodos permitiendo otras
alternativas de navegaci´on por la informaci´on diferentes del cl´asico acceso
secuencial ”desde la primera a la ´ultima l´ınea”. Existe, no obstante, un
ter-cer componente fundamental denominado ancla. Se trata de un mecanismo
para se˜nalar puntos incluidos en el interior de los nodos que sirven de origen
con contenido textual puede haber palabras o frases marcadas que al ser
se-leccionadas por el usuario (p. ej. con el rat´on) activen un enlace originando el
acceso al contenido de otro nodo (o a otra parte del mismo nodo). Este nodo
destino podr´ıa contener informaci´on multimedia de tipo secuencia de v´ıdeo,
con lo que el ancla deber´ıa marcar el fotograma o el instante de la secuencia
de v´ıdeo que deber´ıa comenzar a visualizarse al activarse el enlace.
Los Sistemas Hipermediales son los entornos que ofrecen a los usuarios
todos los mecanismos para la creaci´on, manipulaci´on y consulta de
hiperdo-cumentos. As´ı, respecto a su interface con los usuarios, proporcionan browsers
o visualizadores para la navegaci´on y, opcionalmente, visiones de mapas
ge-nerales del hiperespacio del documento para que los usuarios conozcan su
situaci´on en cada momento. Tambi´en incluyen herramientas de autor para el
mantenimiento de los contenidos de los nodos y de la estructura de enlaces.
En este caso se deber´an tener en cuenta todas las posibilidades multimedia,
por lo que har´an falta editores, no solo de texto, sino tambi´en de sonido, de
im´agenes, etc. y mecanismos de conexi´on entre todos estos tipos de
informa-ci´on. Adem´as de las facilidades anteriores que son percibidas por los usuarios
del sistema y, teniendo en cuenta que la informaci´on de un documento
hiper-media (tanto la de los nodos como la relativa a los enlaces) ser´a registrada
f´ısicamente en un sistema de ficheros o en una base de datos, deber´an existir
tambi´en mecanismos que adapten dicha informaci´on a las caracter´ısiticas del
sistema de almacenamiento utilizado, as´ı como los correspondientes
Debido a la complejidad evidente de los documentos hipermedia, desde
los or´ıgenes de esta tecnolog´ıa se ha intentado establecer un modelo
univer-sal de hiperdocumento que permita su percepci´on desde diferentes niveles de
abstracci´on para facilitar el desarrollo de est´andares de interface entre niveles
que garanticen la portabilidad de los documentos generados. Uno de los
mo-delos m´as conocidos es el denominado Dexter Hypertext Reference Model,
presentado en 1990 para Hipertextos y mejorado en 1993 por el Amsterdam
Hypermedia Model para recoger aspectos espec´ıficos de la informaci´on
mul-timedia. El modelo Dexter considera tres niveles para un hiperdocumento:
1.- Nivel de ejecuci´on (Run-time Layer): Se trata del nivel de mayor
abs-tracci´on, que se superpone a los restantes niveles. En ´el se describe el
hi-perdocumento tal y como lo perciben los usuarios, como una serie de nodos
con contenido que aparecen en pantalla y desde los que se puede acceder a
otros nodos a trav´es de enlaces. Este nivel tambi´en incluye las
caracter´ısti-cas de la Interface Gr´afica de Usuario (IGU) utilizada en la visualizaci´on del
hiperdocumento.
2.- Nivel de almacenamiento (Storage Layer): En este nivel intermedio se
ver´ıa el documento como una base de datos en la que se almacena toda la
informaci´on en entidades o ¸componentes”(normalmente coincidiendo con los
nodos) relacionados entre s´ı.
3.- Nivel de contenido (Within-Component Layer): Este nivel se concentra
en la estructura de la informaci´on en el interior de los componentes de la
estructuraci´on de documentos como ODA o SGML.
De todo lo anterior se evidencian algunas consideraciones importantes a
tener en cuenta respecto a la tecnolog´ıa hipermedia que pueden aconsejar
la incorporaci´on del paradigma de la orientaci´on a objetos en los diferentes
aspectos de dicha tecnolog´ıa:
- La informaci´on que se maneja en los sistemas hipermediales es muy
he-terogenea, lo cual es evidente debido al componente multimedia en la
tecno-log´ıa. - Los hiperdocumentos se estructuran en bloques documentales (nodos)
aut´onomos a los que se accede a trav´es de enlaces. - Se va a requerir un gran
espacio de almacenamiento para la informaci´on. - Se pueden crear
hiperespa-cios de navegaci´on muy complejos debido a las posibilidades de interconexi´on
de nodos - El usuario es el elemento m´as importante de un sistema
hiper-medial. De tal forma que si se le ignora durante el proceso de dise˜no del
hiperdocumento es muy probable nunca lo utilice si no satisface plenamente
sus necesidades de informaci´on. Tambi´en hay que cuidar especialmente la
interface del sistema con el usuario para hacerlo atractivo.
- Las metodolog´ıas tradicionales de ingenier´ıade software, o las
metodo-log´ıas para sistemas de desarrollo deinformaci´on, no contienen una buena
abstracci´on capaz de facilitar la tarea de especificar aplicaciones hipermedia.
El tama˜no, la complejidad y el n´umero de aplicaciones crecen en forma
ace-lerada en la actualidad, por lo cual una metodolog´ıa de dise˜no sistem´atica es
necesaria para disminuir la complejidad y admitir evoluci´on y reusabilidad.
del paradigma de la navegaci´on de sitios web, mientras ejecuta transacciones
sobre bases de informaci´on, es una tarea muy dif´ıcil de lograr. En primer
lugar, la navegaci´on posee algunos problemas. Una estructura de navegaci´on
robusta es unade las claves del ´exito en las aplicaciones hipermedia. Si el
usuario entiende d´onde puede ir y c´omo llegar al lugar deseado, es una buena
se˜nal de que la aplicaci´on ha sido bien dise˜nada. Construir la interfaz de una
aplicaci´on web es tambi´en una tarea compleja; no s´olo se necesita especificar
cu´ales son los objetos de la interfaz que deber´ıan ser implementados, sino
tambi´en la manera en la cual estos objetos interactuar´an con el resto de la
aplicaci´on. En hipermedia existen requerimientos que deben ser satisfechos
en un entorno de desarrollo unificado . Por un lado, la navegaci´on y el
com-portamiento funcional de la aplicaci´on deber´ıan ser integrados. Por otro lado,
durante el proceso de dise˜no se deber´ıa poder desacoplar las decisiones de
dise˜no relacionadas con la estructura navegacional de la aplicaci´on, de
aque-llas relacionadas con el modelo del dominio. OOHDM propone el desarrollo
de aplicaciones hipermedia a trav´es de un proceso compuesto por cuatro
eta-pas: dise˜no conceptual, dise˜no navegacional, dise˜no de interfaces abstractas
e implementaci´on.
2.5.
Ingenier´ıa web
La ingenier´ıa web es la aplicaci´on de metodolog´ıas sistem´aticas,
discipli-nadas y cuantificables al desarrollo eficiente, operaci´on y evoluci´on de
crecimiento desenfrenado que est´a teniendo la Web est´a ocasionando un
im-pacto en la sociedad y el nuevo manejo que se le est´a dando a la informaci´on
en las diferentes ´areas en que se presenta ha hecho que las personas tiendan
a realizar todas sus actividades por esta v´ıa. Desde que esto empez´o a
suce-der el Internet se volvi´o m´as que una diversi´on y empez´o a ser tomado m´as
en serio, ya que el aumento de publicaciones y de informaciones hizo que la
Web se volviera como un desaf´ıo para los (Ingenier´ıa del software) ingenieros
del software, a ra´ız de esto se crearon enfoques disciplinados, sistem´aticos
y metodolog´ıas donde tuvieron en cuenta aspectos espec´ıficos de este nuevo
medio.
Uno de los aspectos m´as tenidos en cuenta, en el desarrollo de sitios web es
sin duda alguna el dise˜no gr´afico y la organizaci´on estructural del contenido.
En la actualidad la web est´a sufriendo grandes cambios, que han obligado a
expertos en el tema a utilizar herramientas y t´ecnicas basadas en la ingenier´ıa
del software, para poder garantizar el buen funcionamiento y administraci´on
de los sitios web. ´ Para garantizar el buen funcionamiento y mantenimiento
de los sitios web, este debe contar con ciertos atributos y caracter´ısticas que
en conjunto forman un concepto muy importante, para alcanzar el ´exito en
cualquier organizaci´on, herramienta, y todo aquello que se pueda considerar
como servicio. Dicho concepto es la calidad, que con atributos como,
usabili-dad, navegabiliusabili-dad, seguriusabili-dad, mantenibiliusabili-dad, entre otros, hace posible por
un lado la eficiencia del artefacto web y por ende la satisfacci´on del usuario
programar y controlar, es decir la calidad no podr´a ser agregada a un
arte-facto web o a cualquier otro producto, al final del proceso de desarrollo, si no
que se deber´a implementar durante todo el ciclo de vida del desarrollo. Para
finalizar el resultado de un proceso de calidad, podr´ıa arrojar
recomenda-ciones para introducir mejoras, y la decisi´on final podr´ıa consistir en lanzar
una nueva versi´on del sitio web o en modificar algunos atributos ausentes o
pobremente dise˜nados. Cabe destacar que la ingenier´ıa de la web hace una
diferencia entre un webSite y un aplicativo, ya que la ingenier´ıa de la web
no se dedica a la construcci´on de sitios web si no a la construcci´on de
aplica-tivos web, la principal caracter´ıstica que los distingue (aplicaaplica-tivos de sitios
web) es que los sitios web son sitios en la web en donde se publica contenido
generalmente est´atico o un muy bajo nivel de interactividad con el usuario,
mientras que los aplicativos son lugares con alto contenido de interactividad
y funcionalidades que bien podr´ıan ser de un software convencional, el
apli-cativo web m´as sencillo seria uno que contenga formularios y subiendo de
nivel encontramos los que realizas conexi´on con bases de datos remotas, y
administradores de contenidos entre otras. Entonces la ingenier´ıa de la Web
es la aplicaci´on de metodolog´ıas sistem´aticas, disciplinadas y cuantificables
al desarrollo eficiente, operaci´on y evoluci´on de aplicaciones de alta calidad
en la World Wide Web. En este sentido, la ingenier´ıa de la Web hace
re-ferencia a las metodolog´ıas, t´ecnicas y herramientas que se utilizan en el
desarrollo de aplicaciones Web complejas y de gran dimensi´on en las que se
aplicaciones.
2.6.
Categor´ıas web
Los sitios web pueden ser categorizados de la siguiente forma:
- S´olo est´atico que se enfoca en la organizaci´on de la estructura y el
contenido, en la forma como se va a presentar la informaci´on y que sea f´acil
de manejar para cualquier usuario, pero debe tener en cuenta la eficiencia y
la confiabilidad.
- Sitio est´atico con formularios de entrada este sitio tiene las mismas
caracter´ısticas que el anterior, adicion´andole que el le permite a los usuarios
la interacci´on por medio de cuestionarios, comentario y sugerencias.
- Sitio con acceso de datos din´amicos aqu´ı, adem´as de las caracter´ısticas
antes mencionadas, cuenta con bases de datos en las cuales el usuario puede
realizar consultas y b´usquedas.
- Sitio creado din´amicamente en este sitio los requerimientos son
pare-cidos pero deben suplir con las necesidades de cada usuario; creando sitios
din´amicos que sean compatibles con el entorno de navegaci´on de cada
usua-rio.
- Aplicaci´on de software basada en la Web este sitio puede tener todas
las caracter´ısticas antes mencionadas, pero logrando un parecido con una
implementaci´on cliente/servidor com´unmente conocido que a un sitio web
est´atico.
nuestro mundo circundante hemos podido observar la necesidad y la utilidad
de la red de redes; Internet para mejorar de cierta manera nuestras
condi-ciones de vida y as´ı fortalecer m´as nuestro proceso de formaci´on educativa y
contribuir con un mejoramiento del global de las necesidades de cada quien
observemos que un proyecto que comenz´o meramente con fines militares para
no centralizar los datos, ha tenido un crecimiento significable hoy en d´ıa el
mundo se mueve con la web, ayudando a peque˜nas, medianas y grandes
em-presas a si como todo entidad educativa. Tengamos en cuenta que emem-presas
mueven sus negocios por medio de la internet y que hasta pol´ıticas como
el CRM para el manejo de clientes, son muy importantes para las empresas
como por ejemplo, Dell, surgen pol´ıticas para el mantener los clientes y
te-nerlos en contactos v´ıa Web, mediante Internet se cuidada de cierta manera
la imagen de una empresa, por ejemplo mediante el marketing a trav´es de
Internet permite reforzar el servicio, haciendo m´as fuerte la relaci´on entre la
marca y el cliente.
Esto implica un uso creativo del medio, involucrando verdaderamente a
las personas con la compa˜n´ıa. Utilizando la inmediatez, que brinda esta v´ıa
de comunicaci´on. Con la herramienta comunicacional, se permite una
rela-ci´on constante e inmediata con los clientes, as´ı como mantener a los clientes
contentos, conquistar nuevos nichos de mercado y, por ende, incrementar las
ventas.
Debemos tener en cuenta que para la efectiva comunicaci´on en la web
el intercambio de comunicaci´on, vale la pena preguntarse, as´ı para poder
acceder a toda la informaci´on que nos puede suministrar Internet s´olo debes
poseer un servicio de alg´un proveedor de Internet un navegador como Mozilla
o Netscape.
Por medio de un sitio web podremos tener nuestro sitio accesible o
dis-ponible 24 horas al d´ıa, 365 d´ıas del a˜no en absolutamente todo el mundo
para quienes tienen acceso; es decir, cerca de 600 millones de personas
aproxi-madamente, es por esto que nuestros datos en internet publicados en el sitio
web podr´ıan ser accesibles a toda persona en cualquier momento en cualquier
parte del mundo.
Todas estas consideraciones nos llevan a la conclusi´on de que un sitio
web bien logrado no es ´unicamente un espacio en la red para ver el mismo
comercial que en televisi´on; es en realidad una extensi´on de las empresas o
instituciones, as´ı mismo teniendo en cuenta la importancia y aplicabilidad
que tiene la ingenier´ıa Web en nuestro desarrollo cognitivo, social y vivencial
es f´acil visionar que cada una de las funciones que ella emana estar´an
siem-pre ligadas a la vanguardia del desarrollo progresivo de la tecnolog´ıa y del
hombre.
La ingenier´ıa del software, incluye nuevas metodolog´ıas de desarrollo
esen-ciales para la administraci´on de proyectos. Actualmente la ingenier´ıa web ha
adoptado tambi´en metodolog´ıas de la ingenier´ıa del software y ha creado
muchas nuevas. Debido a que la informaci´on es p´ublicada para conocimiento
y ´eticos que pueden influir a la hora de la publicaci´on. De acuerdo con esto,
la ingenier´ıa Web puede utilizar una parte de cada una de estas disciplinas
y no ser dominada por puntos de vista muy particulares, es una
respues-ta de car´acter multidisciplinario para las aplicaciones Web. Usualmente, las
aplicaciones web son multidisciplinares, ya que son construidas en un medio
constantemente cambiante, donde los requerimientos son inestables, los
equi-pos de desarrollo generalmente son peque˜nos, las comunidades de usuarios
son m´as amplias que antes y la competici´on ahora es a nivel mundial. En
ge-neral, las aplicaciones web, necesitan ser funcionales, mantenibles, escalables
y seguras. Como podemos ver, la actual demanda de las aplicaciones web
es totalmente diferente de las aplicaciones convencionales y por lo tanto hay
una gran necesidad de la ingenier´ıa web.
2.7.
Metodolog´ıas web
Hoy en d´ıa las aplicaciones que se desarrollan son muy diferentes a las
que se desarrollaban hace unos a˜nos. El desarrollo de las comunicaciones y
la gran difusi´on de Internet han creado nuevas necesidades dentro de los
sis-temas software. En este sentido, muchas definiciones de sissis-temas se est´an
dando dentro del mundo de la ingenier´ıa del software: sistemas multimedia,
sistemas hipermedia, aplicaciones web, sistemas de informaci´on global, etc.
Este trabajo es el resultado de la investigaci´on que se ha llevado a cabo para
estudiar una posible metodolog´ıa para el desarrollo de sistemas de
aplicando en este ´ambito y se presenta los primeros inicios de una nueva
pro-puesta que actualmente se est´a elaborando. Sin embargo, antes de comenzar
a plantear el problema que nos va a ocupar el contenido de este trabajo,
es necesario enmarcar el entorno de trabajo en el que nos vamos a mover.
Para ello, es necesario hacer una serie de definiciones previas. Desde que el
desarrollo de aplicaciones inform´aticas se empez´o a considerar un proceso de
ingenier´ıa, muchas metodolog´ıas de desarrollo han ido naciendo con el fin de
dar soporte al ciclo de desarrollo del proyecto. Entre estas, podemos
desta-car algunas como M´ETRICA, MERISE, SSADM y ya m´as recientes como
OMT o el actual UML. Todos estas metodolog´ıas estaban orientadas
des-de sus comienzos al des-desarrollo sistemas para gestionar una informaci´on que
se encuentra almacenada en una o varias bases de datos, distribuidas o no.
Entre los aspectos que se tratan como m´as cr´ıticos en estas metodolog´ıas,
los m´as importante son el almacenamiento y la recuperaci´on adecuada de
la informaci´on, as´ı como que las posibilidades funcionales que ofrezcan sean
las necesarias. Otro t´ermino que comienza a nacer es el de las aplicaciones
multimedia. Mientras que las metodolog´ıas anteriores tratan con especial
in-ter´es los aspectos de almacenamiento y funcionalidad, en las aplicaciones
multimedia el objetivo esencial va a ser difundir informaci´on almacenada en
diferentes medios (im´agenes, v´ıdeos, m´usica, etc.) de manera que llegue al
p´ublico no experto en inform´atica de una forma sencilla, f´acil e intuitiva. Son
aplicaciones que nos preocupan tanto por las necesidades de
funcionalidad, como por la apariencia y el interfaz del sistema. El desarrollo
de estos sistemas comienzan a realizarse sin que haya ninguna norma que se
pueda tomar como marco de referencia para su desarrollo. Sin embargo, a
principios de los 90, se comienza a estudiar la necesidad de una metodolog´ıa
que gu´ıe a los desarrolladores y que asegure la calidad de los productos
mul-timedia generados. Por esta raz´on, desde el a˜no 93 comienzan a publicarse
propuestas metodol´ogicas y nuevos modelos para representar la problem´atica
de estas aplicaciones: RMM , EORM, OOHDM [14], etc. Junto con todo esto,
Internet va tomando cada vez m´as popularidad. Hoy en d´ıa Internet supone
un excelente medio para obtener informaci´on de los m´as variados temas sin
necesidad de movernos de casa. Internet nos permite, a trav´es de interfaces
sencillas, intuitivas y amigables, hacer desde una consulta a la cartelera de
cine hasta comprar acciones en nuestra entidad bancaria. Sin embargo, esto
no siempre ha sido as´ı. En sus comienzos la Web naci´o como una red que
co-nectaba a varias redes privadas, p´ublicas y de centros de investigaci´on, con el
objetivo de compartir informaci´on entre grupos de investigaci´on localizados
en diversos lugares. Cuando la red de redes comenz´o a tomar popularidad, las
p´aginas que se mostraban en los servidores de las organizaciones eran p´
agi-nas est´aticas que podr´ıamos describir como documentos mostrados a trav´es
de Internet. Sin embargo, poco a poco y, a medida que va aumentando la
popularidad de la red, las empresas y organizaciones comienzan a requerir
que sus p´aginas tengan un cierto dinamismo que las haga m´as atractivas
cada vez m´as interactivas, permitiendo que el usuario no solo sea un sujeto
pasivo en la p´agina, sino que, comienza a interactuar mandando datos al
ser-vidor remoto y recibiendo respuestas de este. Poco a poco Internet adquiere
popularidad y las organizaciones ven en ella una posibilidad de publicidad
efectiva y de facilitar la comunicaci´on con sus clientes. Comienza as´ı la
ne-cesidad de incluir bases de datos y grandes vol´umenes de informaci´on en la
red. A finales de los 90, las p´aginas Web han dejado de ser p´aginas
documen-tales puramente est´aticas para dejar paso a p´aginas interactivas, en las que
se incluye informaci´on en m´ultiples medios y con las que el usuario puede
in-teractuar. En estas p´aginas se han unido los conceptos de hipertexto con los
m´ultiples medios, dando origen a lo que se conoce como hipermedia. Adem´as,
la nueva generaci´on de p´aginas Web est´a dotada de una gran funcionalidad.
Ya no tenemos p´aginas que muestran y recogen datos, lo que
actualmen-te se tiende a mostrar por Inactualmen-ternet son complejas aplicaciones con grandes
requisitos de almacenamiento y funcionalidad, acompa˜nado de un complejo
y llamativo interfaz, que engloba informaci´on en m´ultiple medios y enlaces
no solo entre datos textuales, sino que, permite tambi´en enlaces entre datos
multimedia. Son los llamados sistemas de informaci´on web, que est´an
dan-do origen a complejos portales que se est´an ganando la atenci´on del p´ublico
actual. Debido a este gran avance y promovidos por las mismas inquietudes
de otros entornos, desde el a˜no 98 est´an empezando a nacer metodolog´ıas
Las metodolog´ıas para la web nacen en la mayor´ıa de los casos de otra
meto-dolog´ıa anterior, bien de una metometo-dolog´ıa cl´asica, como el caso de Conallen
basada en el Proceso Unificado y UML; o bien de una metodolog´ıa para
apli-caciones multimedia, como el caso de los nuevos desarrollos de OOHDM .
Otro t´ermino importante que aparece tambi´en hoy en d´ıa es el concepto de
biblioteca digital. Una biblioteca digital (BiDi) es una biblioteca que ha sido
extendida y mejorada mediante la aplicaci´on de la tecnolog´ıa digital. Es la
uni´on de ordenadores, sistemas de almacenamiento y redes de comunicaciones
con el contenido y el software necesario para reproducir, emular y extender
los servicios proporcionados por las bibliotecas conve ncionales. Una
biblio-teca digital debe cumplir todas las tareas de una bibliobiblio-teca convencional y
explotar las ventajas de la tecnolog´ıa digital en el almacenamiento, la b´
usque-da y las comunicaciones, adem´as de la integraci´on de nuevos tipos de medios
(textos, im´agenes, sonidos, v´ıdeos, animaciones). La biblioteca digital
pro-porciona a una comunidad de usuarios un acceso coherente a repositorios de
informaci´on grandes y organizados. Las bibliotecas digitales son construidas
(recogiendo y organizando la informaci´on) por una comunidad de usuarios
y sus funcionalidades son acordes a las necesidades de informaci´on de dicha
comunidad. Las posibilidades de los usuarios para acceder, reorganizar y
uti-lizar este repositorio est´an enriquecidas con las capacidades de la tecnolog´ıa
digital. Tambi´en han aparecido propuestas para el desarrollo de aplicaciones
basadas en BiDi [8]. Como resumen a esto, podr´ıamos decir que durante los
´
entornos concretos dando m´as importancia a los aspectos m´as importantes
de los sistemas que tratan. En la multimedia, el tratamiento de los m´
ulti-ples medios y el entorno visual es esencial, de ah´ı que las metodolog´ıas de
la multimedia se centren en estos aspectos. Las metodolog´ıas de la web, van
a estar m´as orientadas a aspectos de navegaci´on y arquitecturas. Mientras
que el resto de las metodolog´ıas m´as generales, el Proceso Unificado, OMT,
etc. van a centrarse m´as en aspectos como el almacenamiento de la
infor-maci´on y la funcionalidad. En la actualidad, las aplicaciones se desarrollan
normalmente en entornos distribuidos, es muy com´un el que se distribuyan
por internet y normalmente tienen asociados elementos multimedia e
hyper-media en grandes bases de datos. Se caracterizan por tener grandes requisitos
funcionales y de seguridad, m´ultiples usuarios y en muchos casos indefinidos
y con diferentes grados de conocimiento. Estas aplicaciones se conocen como
sistemas de informaci´on global, y son, por decirlo de alguna manera, un
con-cepto mucho m´as gen´erico que engloba a las aplicaciones que se encuentran
en los otros grupos. El sistema de informaci´on global puede verse como si
fuera una aplicaci´on multimedia, puesto que normalmente maneja
informa-ci´on almacenado en m´ultiples medios. Pero cuando se distribuye a trav´es de
internet, se podr´ıa ver como un sistema de informaci´on web. Sin embargo,
ninguna de las metodolog´ıas de estos ´ambitos ser´ıa adecuada, puesto que no
tratan los aspectos de almacenamiento y funciona lidad de manera
adecua-da, que en los sistemas de informaci´on web suelen ser bastante cr´ıticos. Los
y requieren sistemas de seguridad muy potentes, as´ı como una funcionalidad
muy elaborada que asegure que los usuarios van a poder trabajar con esta
informaci´on de manera adecuada. Para tratar estos aspectos, metodolog´ıas
como el Proceso Unificado podr´ıan ser un buen marco de referencia para su
desarrollo. Por otro lado, y cuando su medio de transmisi´on es la web, cosa
que suele ser muy com´un, el sistema de informaci´on global adquiere todas las
caracter´ısticas de un sistema de informaci´on en la web. Normalmente, estos
sistemas deben tener una interfaz intuitiva y amigable que hacen uso de la
multimedia para llegar m´as f´acilmente al usuario. As´ı un sistema de
infor-maci´on global podr´ıa verse como una aplicaci´on multimedia. Pero adem´as
si analizamos la definici´on de biblioteca digital, ¿no podr´ıamos decir que un
sistema basado en bibliotecas digitales es un sistema de informaci´on global?.
Por ser el sistema de informaci´on global el m´as gen´erico, este trabajo se
mueve en este entorno. Aqu´ı vamos a estudiar las propuestas metodol´ogicas
definidas para sistemas multimedia, sistemas de informaci´on web, etc. Con el
fin de encontrar modelos e ideas consensuadas que nos permitan desarrollar
una metodolog´ıa para el desarrollo de los sistemas de informaci´on global.
2.8.
HDM- A Model-Based Approach to
Hy-pertext Aplication Design
HDM (Hypermedia Design Model) [6] es uno de los primeros m´etodos
desarrollado para definir la estructura y la navegaci´on propia de las
ampl´ıa el concepto de entidad e introduce nuevos elementos, como las
uni-dades o los enlaces. En HDM se pretende especificar la aplicaci´on mediante
un modelo Entidad-Relaci´on extendido. Este modelo va a representar la
es-tructura global de la aplicaci´on sin entrar en detalles de desarrollo de los
elementos unitarios (nodos de la aplicaci´on). A pesar de que en la
actuali-dad HDM no se usa, ha servido como base a otras importantes metodolog´ıas
como son RMM [5] y OOHDM [8], las cuales veremos m´as adelante.
2.8.1.
HDM
HDM propone un conjunto de elementos que permiten al dise˜nador
es-pecificar una aplicaci´on. Estos elementos son las entidades, los componentes,
las perspectivas, las unidades y los enlaces. Todos estos elementos pueden
incorporarse en la sem´antica del cl´asico modelo Entidad-Relaci´on. Sin
em-bargo, y a pesar de que t´erminos como las entidades hayan sido heredados
de los ERD veremos a continuaci´on que han sido extendidos para poder
re-presentar una estructura compleja que contenga enlaces y una sem´antica de
navegaci´on interna.
En definitiva una aplicaci´on especificada mediante un modelo HDM
con-siste en una estructura general compuesta por unas unidades b´asicas
deno-minadas entidades. Una entidad denota un objeto f´ısico o conceptual del
universo de discurso de la aplicaci´on. En HDM las entidades son agrupadas
por un conjunto de perspectivas bajo las que se pueden presentar su
conte-nido y un conjunto de enlaces de aplicaci´on por los que se puede navegar
(estos conceptos se ver´an m´as adelante). Una entidad es la unidad m´ınima
aut´onoma de cualquier modelo HDM, pero existen otros conceptos a˜nadidos
que veremos a continuaci´on. Cada entidad est´a compuesta por una jerarqu´ıa
de componentes que heredan las propiedades de dicha entidad. Los
compo-nentes no tienen raz´on de ser sin que exista la entidad de la que dependen.
Los componentes son, por su parte, abstracciones para dise˜nar un conjunto
de unidades o nodos que representan un mismo conjunto de informaci´on de
la entidad. Una unidad, es pues un dep´osito de la informaci´on contenida en
una aplicaci´on. Una unidad representa un fragmento del contenido de una
entidad presentada bajo una perspectiva particular. De esta forma, la
pers-pectiva permite representar la multiplicidad de presentaciones de un mismo
contenido de informaci´on (por ejemplo, la presentaci´on de un documento en
m´ultiples lenguas). Para entender mejor la relaci´on entre estos elementos,
usaremos la potencia representativa de UML. Vemos as´ı en la figura
siguien-te un modelo de clases que representa las relaciones entre los elementos de
HDM.
En un modelo HDM las estructuras de informaci´on pueden ser conectadas
mediante enlaces. Un enlace entre dos elementos indica que en la aplicaci´on
hipermedia resultante existe la posibilidad de navegar entre esos dos
elemen-tos. HDM distingue tres tipos de enlaces: - Enlaces estructurales, conectan
