Embed Size (px)
Citation preview
CAPITULO II
MARCO TEÓRICO En este segmento de la investigación se dispone del problema dentro
de un contexto teórico apropiado, donde se revisan diversas teorías
existentes y cuyos parámetros permiten orientar el proceso de investigación
hacia fines concretos y con una plataforma teórica. Las variables en estudio
han sido analizadas en diversas investigaciones, que sirven de punto de
referencia y comparación para el presente trabajo.
A continuación se exponen antecedentes que describen las variables,
una vez revisada la literatura correspondiente:
1. ANTECEDENTES Esta investigación toma como referencia otros estudios, afines a las
variables que se utilizaran en esta investigación; Portillo y Toris en el año
2007 presentaron la tesis que llevo por nombre “Sistema de Información
bajo plataforma web para los procesos administrativos de la empresa
de importaciones y distribuciones JBL” en la Universidad Rafael Belloso
Chacín.
El propósito de la investigación fue desarrollar un sistema de
investigación bajo plataforma web para los procesos administrativos de la
13
14
empresa importaciones y distribuciones JBL, con el fin de mejorar los
procesos como el tiempo de respuestas a solicitudes y almacenamiento de
información, así como alcanzar mayor productividad, tomando como
referencia la teoría de los sistemas de información propuesta por Kendall y
Kendall (1997), Vassos (1996), Rispuez, Fuenmayor y Perecra (1999).
Esta investigación es de tipo descriptiva para la cual se realizo un
surco de operaciones entre gerentes y administradores de la empresa,
consultando investigaciones previas, y autores del área, para determinar los
requerimientos de automatización de información, procesos y estructuras de
la pagina web. Las herramientas utilizadas fueron PHP 5.0, para la
programación del sistema de información y la pagina web, se obtiene como
resultado un incremento en la productividad en los procesos de facturación,
pedidos, búsqueda avanzada de cliente, a través del manejo de sistemas
automatizados así como una importante proyección y mayor competitividad
en el mercado. Cumpliendo con las expectativas de los clientes, gerente y
administradores.
En esta investigación se toma como referencia la plataforma web en la
cual se realizo el diseño, la diferencia de la actual es la presentación de una
base de datos para el inventario y la realización de secciones para la
administración de la página web.
De igual manera, se tomaron como referencia otros estudios de
investigación, se presentan los siguientes antecedentes: Corrales, en el año
15
2008 presentaron la tesis que llevaba por nombre “Sistema de información
en ambiente web para la gestión operativa de un centro de manejos de
desechos. Caso Terraven, C.A” en la Universidad Rafael Belloso Chacín.
El Objetivo de la investigación fue desarrollar una sistema de
información en ambiente web para la gestión operativa de un centro de
manejo de desechos. Caso Terraven C.A. El estudio fue sustentado por los
aportes de los autores Montilva (1999), Garcia Perez (2002) y Molina (2000)
entre otros, considerando la ejecución del mismo en un periodo de ocho
meses, comprendiendo entre mayo 2008 hasta diciembre 2008.
Dicho estudio es de tipo proyectivo, descriptivo, y de campo,
considerando los criterios de finalidad, método y forma de obtener los datos.
La muestra estuvo conformada directamente por la empresa TERRAVEN,
C.A. La investigación se baso en la aplicación de la metodología ofrecida por
Senn (1999) y Powell (2001) quedando definidas las fases de: Investigación
Preliminar, Identificación de los Requerimientos, Diseño del Software,
Desarrollo del Software, Pruebas y Evaluación.
Además se utilizaron como técnica de recolección de datos la visita, la
observación directa y la entrevista no estructurada, las cuales permitieron
determinar que la empresa lleva sus procesos de forma manual, dificultando
el control de sus actividades, de la misma manera se obtuvieron los
requerimientos.
16
Los resultados reflejaron que la metodología aplicada en la empresa
logro la creación del sistema de información como software de diseño del
sitio web Dreamweaver 8.0, ya que es un sistema fácil y atractivo para la
aplicación de las operaciones requeridas por TERRAVEN, C.A, en la cual las
pruebas parciales, de sistema, de ejecución de tiempo y, de aceptación;
validaron que el mismo funcionara de acuerdo a los requerimientos
planteados. Así mismo se logro la aceptación e involucramiento del personal
que manejara el sistema, asegurándose del funcionamiento satisfactorio del
software desarrollado.
Esta investigación maneja la gestión de procesos y las tareas de la
empresa la cual aportara una valiosa información al momento de realizar la
investigación. Por otra parte trabaja bajo ambiente web y fue creado con el
programa Dreamweaver el cual se utilizara pare crear el sistema Web a
proponer.
Por otra parte, también se toma como referencia otros estudios de
investigación que se presenta a continuación: Diez, Gutiérrez y Rincón en el
año 2007 Presentaron la tesis que lleva por nombre “Sistema de
información en Ambiente web para la Gestión Operativa de un
departamento de tecnología de la información en Procedatos” En la
Universidad Dr. Rafael Belloso Chacín.
El objetivo de la investigación fue desarrollar un sistema de
información en ambiente web para la gestión operativa, para facilitar el
17
control de los procesos a las personas que laboran en el departamento de
tecnología de la información en la empresa procedatos. Este sistema se
encarga de llevar de forma automatizada todos los procesos, actividades y
tareas realizadas en diferentes áreas que conforman dicho departamento.
Dicho estudio fue descriptivo, y su diseño fue de campo, transaccional
y no experimental. Se utilizó la metodología de Montilva (1999) en solo 6
fases. Así mismo, la técnica de recolección de datos fue la entrevista no
estructurada lo que permitió conocer a profundidad la problemática que se
presentaba en la empresa y las necesidades y requerimientos del nuevo
sistema.
Los resultados obtenidos fue de un sistema de información capaz de
visualizar y actualizar todas las tareas que se realizan en cada área,
brindándoles a los usuarios mayor organización, seguridad y comodidad de
los procesos, actividades y tareas de cada área. El diseño de la interfaz se
desarrollo en Dreamweaver 8.0,y para el desarrollo se utilizo JBuilder 8.0 y
para el manejo de base de datos se utilizo PostgrasSQL 1.2.1
Esta investigación refleja como aporte la visita y la entrevista no
estructurada para hacer la recolección de datos dentro de una empresa. Por
otra parte dicha investigación se baso en la creación de base de datos con el
programa MySqlManager el cual se usara para la administración de la base
de datos del proyecto a desarrollar.
18
2. BASES TEÓRICAS Los sistemas de información, ambiente web y gestión operativa; han
sido investigadas en las literaturas correspondientes, hallándose en ellas,
diversos elementos doctrinarios y científicos, así como opiniones,
afirmaciones y teorías expuestas por los más respetados autores.
Se abordara las variables mencionadas y diferentes puntos
importantes de las mismas, relacionadas con el objetivo de la investigación.
2.1.- SISTEMA DE INFORMACIÓN Según, Fernández Alarcón (2006, p. 11) es un conjunto de
componentes que interaccionan entre sí para lograr un objetivo común.
Aunque existe una gran variedad de sistemas, la mayoría de ellos pueden
representarse a través de un modelo formado por cinco bloques básicos;
elementos de entrada, elementos de salida, sección de transformación,
mecanismos de control y objetivos.
Afirma Laudon y Laudon (2004, p. 8) los sistemas de información
como conjunto de componentes interrelacionados que recolectan (o
recuperan), procesan, almacenan y distribuye información para apoyar la
toma de decisiones y el control de una organización. También puede ayudar
a los gerentes y trabajadores a analizar problemas, a visualizar asuntos
complejos y a crear productos nuevos.
19
Los sistemas formales de información son aquellos que se apoyan en
definiciones fijas y aceptadas de datos y procedimientos que operan en
conformidad con reglas predefinidas. Por otra parte, los sistemas informales
de información se basan en reglas de comportamiento no establecidas. Las
conversaciones de trabajo en la máquina de café, o una reunión durante la
comida pueden considerarse sistemas informales.
2.2.- MÉTODOS ÁGILES DE DESARROLLO DE SISTEMA Según, Davenport (2005, p. 84), durante un tiempo, se conocían como
metodologías ligeras, pero ahora el aceptado es metodologías agiles.
Para muchas personas, el atractivo de estas metodologías
monumentales agiles es su reacción a la burocracia de las metodologías
monumentales. Estos métodos nuevos intentan un compromiso útil entre no
tener proceso y tener demasiado proceso, es decir, proporcionar el proceso
justo para conseguir una recompensa razonable. Dos diferencias clave entre
los métodos de adaptación y de ingeniería son:
Los métodos ágiles son adaptativos en lugar de previsibles, los
métodos de ingeniería tienden a intentar planificar una gran parte del proceso
de software en gran detalle para un espacio de tiempo largo, lo que funciona
hasta que las cosas cambian. Así, su naturaleza es resistir al cambio. En
cambio, los métodos ágiles aceptan sin problemas el cambio, se procura que
20
sean procesos que se adapten y que crezcan con fuerza a partir del cambio,
incluso hasta llegar al punto de cambiar ellos mismos.
Los métodos ágiles se orientan a las personas en lugar de hacerlo a
los procesos. El objetivo de los métodos de ingeniería es definir un proceso
que funcione bien independientemente de la persona que lo esté utilizando,
los métodos ágiles afirman que ningún proceso compensara la habilidad del
equipo de desarrollo, por lo que el papel del proceso es dar apoyo al equipo
de desarrollo en su trabajo. Además, afirman Galindo, Simón, Blázquez y
Sala (2010, p. 194), los métodos ágiles se basan en los valores expresados
en el Agile Manifestó.
Según, Torres y López (2003, p. 10), al individuo y las interacciones
del equipo de desarrollo sobre el proceso y las herramientas. La gente es el
principal factor de éxito de un proyecto software. Es más importante construir
un buen equipo que construir el entorno. Es mejor crear el equipo y que éste
configure su propio entorno de desarrollo en base a sus necesidades.
Desarrollar software que funciona más que conseguir una buena
documentación. La regla a seguir es “no producir documentos a menos que
sean necesarios de forma inmediata para tomar un decisión importante”,
estos documentos deben ser cortos y centrarse en lo fundamental. La
colaboración con el cliente más que la negociación de un contrato. Se
propone que exista una interacción constante entre el cliente y el equipo de
21
desarrollo. Esta colaboración entre ambos será la que marque la marcha del
proyecto y asegure su éxito.
Responder a los cambios más que seguir estrictamente un plan. La
habilidad de responder a los cambios que puedan surgir a los largo del
proyecto (cambios en los requisitos, en la tecnología, en el equipo, entre
otros.) determina también el éxito o fracaso del mismo. Por lo tanto, la
planificación no debe ser estricta sino flexible y abierta.
Los valores anteriores inspiran los doce principios del manifiesto. Son
características que diferencian un proceso ágil de uno tradicional. Los dos
primeros principios son generales y resumen gran parte del espíritu ágil. El
resto tienen que ver con el proceso a seguir y con el equipo de desarrollo.
2.3.- METODOLOGÍA DE MODELADO AGIL Según, Ambler (2002, p. 25), define que es una metodología basada
en la práctica para modelado efectivo de sistemas de software. La
metodología de modelado ágil es una colección de prácticas, guiadas por
principios y valores que pueden ser aplicados por profesionales de software
en el día a día. El modelado ágil no es un proceso prescriptivo, ni define
procedimientos detallados de cómo crear un tipo de modelo dado.
22
2.4.-MODELADO AGIL DE TRES OBJETIVOS Según, Ambler (2002, p. 25), definir y mostrar cómo poner en práctica
una colección de valores, principios y prácticas que conlleven a un modelado
ligero efectivo. Explorar la aplicación de técnicas de modelado en proyectos
de software a través de un enfoque ágil, tal como XP, DSDM o SCRUM. Y
explorar el cómo mejorar el modelado bajo procesos prescriptivos, tales
como el Proceso Rational Unificado (RUP), Proceso Unificado Empresarial
(EUP).
2.5.- METODOLOGIA AGIL: PROCESO UNIFICADO DE RATIONAL O (RUP) Según, Carvajal Riola, (2008, p. 74) es un framework de procesos de
desarrollo de software, ampliamente utilizado en miles de proyectos, con
equipos que van de dos a cientos de miembros y utilizado en una amplia
variedad de compañías a lo largo del mundo.
Fue creado por la Rational Software Corporation. RUP es una
metodología basada en Objectory, metodología orientada a objetos creada
por Ivar Jacobson5 en 1988. Rational compró Objectory en 1995 y siete años
más tarde IBM se hizo con el control de Rational Corporation.
RUP no es proceso prescriptivo, sino que es un framework de
procesos adaptable y con la intención de ser personalizado por los diferentes
equipos de desarrolladores, seleccionando los elementos del proceso que
23
son mas apropiados para sus necesidades. Rational Unified Process es
también un producto que distribuye IBM y que incluye una gran base
documental con artefactos de ejemplo y detalladas descripciones de las
diferentes actividades.
2.5.1.- PROCESOS. El ciclo de vida de RUP es UP o proceso unificado y describe la
dimensión temporal del proyecto, esto es como un proyecto es dividido en
fases e iteraciones. UP divide el proyecto en cuatro fases: Inicio,
Elaboración, Construcción y Transición, junto con las disciplinas que se
desarrollan en cada una. Se muestra con mayor detalle estas fases:
INICIO: En esta fase se establece el objetivo principal del sistema y
también se trata de entender que sistema se va a construir, a través de los
requisitos de los usuarios. Otras tareas que se realizan en esta fase es la
identificación y mitigación de los riesgos de negocio típicos, generación de
los casos de negocio para construir el sistema y el documento Visión, con tal
de obtener la aceptación de todos los stakeholders.
ELABORACIÓN: En la fase de elaboración se busca reducir al
máximo los posibles riesgos y de este modo cumplir la planificación y los
costes estimados. Los riesgos técnicos son tratados con especial interés,
prestando una mayor atención a las tareas técnicamente más difíciles. Aquí
se desarrollan las disciplinas de diseñar, implementar, probar y como punto
24
de partida se genera una arquitectura ejecutable que incluye subsistemas,
sus interfaces, componentes claves, y detalles de cómo se comunican los
procesos internos o como se realiza la persistencia.
CONSTRUCCIÓN: Se lleva a cabo la mayor parte de la
implementación del sistema, partiendo de una arquitectura ya ejecutable
construida en la etapa anterior hasta una primera versión funcional del
sistema. A continuación se desplegarán diferentes versiones, internas y
alpha6, con tal de asegurar la usabilidad del sistema y que cumple las
necesidades de los usuarios A final de la fase se libera una versión beta
completamente funcional, que incluye la documentación necesaria para su
instalación, soporte y aprendizaje.
TRANSICIÓN: En esta fase se asegura que el software cumple las
necesidades de los usuarios y esto se hace a través de la realización de
pruebas y la realización de pequeños ajustes basados en el feedback con el
cliente. En esta fase no se deberían encontrar problemas estructurales
mayores, ya que deberían haber sido identificados y corregidos en etapas
anteriores.
2.5.2.- ROLES Y RESPONSABILIDADES.
En la siguiente tabla se observan los roles según su grado de detalle,
tal y como se trabaja con RUP, en primera instancia se obtiene un visión
general de la solución y después, en cada nueva iteración se concretan los
25
detalles. De esta forma, se especifican los roles según pertenezcan a una de
las primeras iteraciones (roles generales) o a iteraciones más avanzadas
(roles específicos).
Cuadro 1 Roles Según RUP
Fuente: Carvajal Riola (2008, p.76)
26
2.5.3.- PRÁCTICAS.
RUP presenta un gran número de prácticas, Best software practices
development”, a continuación se muestran, las prácticas que se han
considerado más relevantes.
Cuadro 2 Practicas de RUP
Fuente: Carvajal Riola (2008, p.77) 2.5.4.- ADOPCIÓN Y EXPERIENCIAS. RUP es una de los modelos de proceso más utilizados hoy en día y
prácticamente se ha convertido en un estándar para procesos prescriptivos
de desarrollo de software. Si lo que se quiere es ver la cantidad de empresas
27
que han utilizado o que están utilizando RUP, siempre se podrá dirigir a la
página oficial de IBM y observar los casos de estudio que se muestran.
2.5.5.- ENTORNOS DE USO. IBM provee de una herramienta llamada RMC o IBM Rational Method
Composer que propone los siguientes procesos en los cuales se pueden
ejecutar RUP:
RUP para proyectos pequeños.
RUP para proyectos de mediana envergadura.
RUP para proyectos grandes. Y especifica que es el RUP clásico.
RUP para COTS o desarrollo de aplicaciones empaquetadas.
RUP para ingeniería de sistemas.
RUP para arquitecturas orientadas a servicios (SOA).
RUP para mantenimiento.
Se puede observar que desde IBM prácticamente recomiendan el uso
de RUP para cualquier tipo de proyecto, grande o pequeño, proyectos para
COTS o de mantenimiento, entre otros. Obviamente esta es la sugerencia de
IBM e indica que RUP considera su utilización en todos estos ámbitos, otro
tema es que sea la metodología más idónea en cada caso. RUP puede ser
28
muy útil para grandes y medianos proyectos, pero cuando se habla de
proyectos pequeños, añade un trabajo excesivo que podría ser fácilmente
obviado.
2.6.- DSDM (Método de Desarrollo de Sistema Dinámico) Según, AG, Oracle, Ingres, el DSDM empezó en Gran Bretaña en
1994 como un consorcio de compañías del Reino Unido que querían
construir sobre (RAD) Desarrollo Rápido de Aplicaciones y desarrollo
iterativo.
El método empieza con un estudio de viabilidad y negocio. El estudio
de viabilidad considera si DSDM es apropiado para el proyecto. El estudio de
negocio es una serie corta de talleres para entender el área de negocio
dónde tiene lugar el desarrollo. También propone arquitecturas de esbozos
del sistema y un plan del proyecto. El resto del proceso forma tres ciclos
entretejidos: el ciclo del modelo funcional produce documentación de análisis
y prototipos, el ciclo de diseño del modelo diseña el sistema para uso
operacional, y el ciclo de implantación se ocupa del despliegue al uso
operacional.
DSDM tiene principios subyacentes que incluyen una interacción
activa del usuario, entregas frecuentes, equipos autorizados, pruebas a lo
largo del ciclo. Como otros métodos ágiles usan ciclos de plazos cortos de
entre dos y seis semanas. Hay un énfasis en la alta calidad y adaptabilidad
29
hacia requisitos cambiantes. DSDM es notable por tener mucha de la
infraestructura de las metodologías tradicionales más maduras, al mismo
tiempo que sigue los principios de los métodos ágiles.
En enero de 1994, se reúne en Reino Unido un grupo de profesionales
para discutir sobre la creación de un proceso iterativo normalizado para el
desarrollo RAD. Un método de desarrollo creado por James Martinque se
caracteriza por usar un ciclo de vida iterativo, prototipos y herramientas
CASE (Computer Aided Software Engineering). El proceso que el grupo
definió se llamó DSDM, Dynamic Systems Development Method, el que se
considera primer método ágil. DSDM contempla el ciclo de vida iterativo e
incremental, involucrar continuamente al usuario y la adaptación al cambio.
2.7.- BASE DE DATOS Según, Ramos y Martin (2007, p. 2) una base de datos es un
conjunto de datos relacionados entre sí, organizados y estructurados, con
información referente a algo. Se puede utilizar una base de datos para cosas
tan sencillas como mantener un registro de nuestra agenda personal de
teléfonos, o tan complicados como llevar toda la gestión de una gran
empresa u organización.
30
2.7.1.- LOS SISTEMAS GESTORES DE BASE DE DATOS
Según, Ramos y Martin (2007, p. 3), es una aplicación que permite a
los usuarios definir, crear y mantener la base de datos y proporciona un
acceso controlado a la misma. Debe prestar los siguientes servicios:
Creación y definición de la base de datos: especificación de la
estructura, el tipo de los datos, las restricciones y relaciones entre ellos
mediante lenguajes de definición de datos. Toda esta información se
almacena en el diccionario de datos.
Manipulación de los datos realizando consultas, inserciones y
actualizaciones de aquellos utilizando lenguajes de manipulación de datos.
Acceso controlado a los datos de la BD mediante mecanismos de seguridad
de acceso a los usuarios. Mantener la integridad y consistencia de los datos
utilizando mecanismos para evitar que los datos sean perjudicados por
cambios no autorizados. Acceso compartido a la base de datos, controlando
la interacción entre usuarios concurrentes. Mecanismos de copias de
respaldo y recuperación para restablecer la información en caso de fallos en
el sistema.
Afirma, Silberschatz (2002, p. 1 y 7); consiste en una colección de
datos interrelacionados y un conjunto de programas para acceder a dichos
datos. La colección de datos, normalmente denominada base de datos,
contiene información relevante para una empresa. El objetivo principal de
una Base de Datos es proporcionar una forma de almacenar y recuperar la
31
información de una base de datos de manera que sea tanto práctica como
eficiente. Los sistemas de bases de datos se diseñan para gestionar grandes
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. De igual manera, las siguientes son algunas
de sus aplicaciones más representativas ya que las bases de datos son
ampliamente usadas: banca, universidades, telecomunicaciones, finanzas,
recursos humanos y otras cantidades de empresa donde ha crecido la base
de datos.
Un sistema de bases de datos proporciona un lenguaje de definición
de datos para especificar el esquema de la base de datos y un lenguaje de
manipulación de datos para expresar las consultas a la base de datos y las
modificaciones. En la práctica, los lenguajes de definición y manipulación de
datos no son dos lenguajes separados; en su lugar simplemente forman
partes de un único lenguaje de bases de datos, tal como SQL, ampliamente
usado.
2.7.2.- LENGUAJE DE MANIPULACIÓN DE DATOS Según, Silberschatz (2002, p. 1 y 7) se trata de la recuperación de
información almacenada en la base de datos, la inserción de información
32
nueva en la base de datos, además, el borrado de información de la base de
datos y la modificación de información almacenada en la base de datos.
2.8.- AMBIENTE WEB Powell (2001, p. 21) define el ambiente web como el diseño
multidisciplinar muy centrado en el usuario que incluye influencias de las
artes visuales, la tecnología, el contenido y la finalidad, La finalidad puede
recoger hasta consideraciones económicas, tales como el coste del sitio en
relación con sus beneficios. La Web es una idea que se construyo sobre la
Internet. Las conexiones físicas son sobre la Internet, pero introduce una
serie de ideas nuevas, heredando las ya existentes.
Así mismo, O'Brien (2001, p. 24) señala que en la actualidad, la web
se ha convertido en una plataforma o ambiente para aplicaciones
empresariales estratégicas, dado que se utilizan tecnología de la misma para
marketing, ventas, servicios al cliente, además permiten investigar, solicitar y
compartir información empresarial interna y externa.
Permitiendo esto que diferentes usuarios empresariales de distintas
partes del mundo se comuniquen entre sí para trabajar en conjunto por
medio de internet a través de equipos virtuales, además de permitir el acceso
rápido y fácil a medios o datos compartidos de la misma manera que a otros
recursos de la red.
33
2.8.1.- SITIO WEB Según, Mora (2002, p. 62), Es un conjunto de páginas web
relacionadas entre sí. Se entiendo por página web tanto el fichero que
contiene el código HTML como todos los recursos que se emplean en la
página (imágenes, sonidos, código, JavaScript, entre otros). En todo sitio
web se suelen distinguir dos páginas especiales: la página inicial, conocida
como splash: es la primera página que un usuario ve al visitar un sitio web.
Normalmente, la página inicial se emplea para promocionar la
compañía u organización a la que pertenece el sitio web, o para dar a
conocer un producto o servicio particular. También se suele emplear para
informar al usuario de los requisitos necesarios para visualizar correctamente
el resto de páginas del sitio web.
Por otro lado, la página principal, conocida como (home) en inglés, es
la página que funciona como índice o tabla de contenidos del sitio web. A
través de esta página, el resto de documentos del sitio web es accesible de
una forma directa o indirecta. Por tanto, la página principal tiene la función de
guiar y dirigir al usuario a otras páginas de opciones.
2.9.-METODOLOGIAS DE DESARROLLO DE AMBIENTE WEB
2.9.1.- (OOHDM) Método de Diseño de Desarrollo en Hipermedia
Orientado a Objetos; Según, Angordans, Esteve y Gea-Valor (2003, p. 390),
una de las metodologías utilizadas en el desarrollo de software más
34
adecuadas para la construcción de aplicaciones hipermedia está basada en
el modelo en espiral de Pressman, esta metodología utiliza la creación de
prototipos como un mecanismo para ir reduciendo los riesgos de error.
Figura 1. Modelo en Espiral
Fuente: Angordans, Esteve y Gea-Valor (2003, p. 390)
El diagrama que se presenta muestra los ciclos progresivos de
desarrollo de una aplicación; cada ciclo consta de cuatro fases
representadas en cada uno de los ejes: Análisis de requisitos, diseño,
construcción y prueba y evaluación. Estas etapas se repiten de forma cíclica
para ir refinando los resultados obtenidos hasta obtener una aplicación final
que supere de forma satisfactoria la evaluación y pruebas.
El resultado de la fase de análisis es el esquema docente y un
conjunto de requisitos de tipo técnico, documentos que serán revisados
cíclicamente después de evaluar los prototipos sucesivos. En la fase de
35
diseño se propone utilizar modelos hipermedia que separan las estructuras
de datos, navegación e interfaz. Los siguientes ciclos de diseño pueden
suponer solamente la modificación de una o dos sub-fases del diseño,
conforme crece la espiral las modificaciones de diseño se centran solo en el
diseño de las interfaces. Se mostrara cada una de estas fases y los modelos
utilizados en la aplicación concreta que se está desarrollando, estos autores
definen los elementos de la metodología de la siguiente manera.
2.9.1.1.- EL MODELO DIDACTICO La tecnología informativa puede dar soporte a los modelos
tradicionales de aprendizaje y enseñanza, pero su aplicación es mucho
más interesante en el caso de los nuevos modelos activos, donde el alumno
es el que dirige su aprendizaje.
El modelo de aprendizaje se plantea en tres etapas: establecimiento
del objetivo, generación de preguntas y elaboración de respuestas. En cada
etapa se pueden utilizar distintas estrategias de enseñanza, esta aplicación
se basa en una enseñanza basada en casos. Los fundamentos teóricos y la
descripción de los procesos aprendizaje constituyen el marco conceptual de
la aplicación; servirán no solo para diseñar el esquema docente, sino
también para guiar el diseño de los esquemas de navegación y de
percepción de la aplicación hipermedia.
36
2.9.1.2.- DISEÑO CONCEPTUAL
El diseño comienza a partir del esquema conceptual contenido en la
fase de análisis, este esquema constituye la base sobre la que se diseñara la
aplicación didáctica. En la primera fase el diseño conceptual, el conocimiento
se organiza como un conjunto de objetos interrelacionados, estos se
generalizan o agregan en clases.
La definición de todas las clases constituye el esquema de datos
conceptual de la base de datos. En el OOHDM estas clases de denominan
clases conceptuales.
2.9.1.3.- DISEÑO DE NAVEGACION Los mecanismos de acceso a la información se diseñan e la fase del
diseño de la navegación, el esquema de navegación especifica cómo va a
explorar la información el alumno, fase muy delicada.
El objetivo es reproducir las estrategias de comprensión de textos
según el nivel de conocimiento del usuario y evitar los problemas propios de
las aplicaciones hipermedia. El nivel de conocimiento del usuario determina
como va a acceder la información, hemos considerado dos tipos de usuarios:
el usuario con muy pocos conocimientos de la lengua objeto y el usuario más
experto. Teniendo en cuenta esta tipología definimos dos tipos de
navegación: navegación tutorizada y navegación focalizada.
37
En la tutorizada el usuario puede seguir una secuencia de seis
bloques de actividades que ha sido diseñada para lograr una comprensión
incremental del texto. En la focalizada el usuario busca completar las
estructuras de significado no construidas en una primera lectura del texto.
2.9.1.4.- EL DISEÑO ABSTRACTO DE VISTAS El diseño de las interfaces se denomina diseño abstracto de vistas
(ADV) en el modelo OOHDM. El resultado es un conjunto de diagramas de
eventos y constituye la definición abstracta de la interfaz. En imagen
siguiente muestra uno de los diagramas, el correspondiente a la interfaz del
correo electrónico. La iconografía, distribución en pantalla y resto de la
presentación se elegirá en la fase de implementación. Definición de eventos
en el ADV email.
Figura 2.
Definición de eventos en el ADV email
Fuente: Angordans, Esteve y Gea-Valor (2003. p. 397)
38
2.9.2.- LAS TÉCNICAS DE NAVEGACIÓN DE DESARROLLO (NDT) Según Escalona (2004, p. 151), es una propuesta orientada en el
paradigma de la ingeniería guiada por modelos. Inicialmente NDT estaba
focalizada en las fases de ingeniería de requisitos y análisis, sin embargo, a
medida que se ha ido evolucionando en la propuesta, las fases se han ido
extendiendo hacia otras fases del ciclo de vida.
En la actualidad, NDT cubre seis grupos de procesos que se
encuentran detallados en el entorno NDTQ-Framework: procesos de
desarrollo, mantenimiento, calidad del software, gestión de proyectos,
pruebas y seguridad. NDT evolucionó, sin embargo a los nuevos estándares
y sus metas modelos se definieron como meta-modelos.
Sus transformaciones, inicialmente definidas mediante OCL, están
ahora expresadas bajo el estándar QVT.
En la actualidad, NDT está siendo usado en varios proyectos y
evoluciona creciendo en otros aspectos como su enriquecimiento en temas
de testing temprano o aspectos de calidad del software. .
2.9.3.- INGENIERIA WEB BASADA EN UML (UWE) Según Koch, (2000, p. 18), La propuesta de Ingeniería Web basada en
UML (UWE (Koch, 2000)) es una metodología detallada para el proceso de
autoría de aplicaciones con una definición exhaustiva del proceso de diseño
que debe ser utilizado. Este proceso, iterativo e incremental, incluye flujos de
39
trabajo y puntos de control, y sus fases coinciden con las propuestas en el
Proceso Unificado de Modelado.
UWE está especializada en la especificación de aplicaciones
adaptativas, y por tanto hace especial hincapié en características de
personalización, como es la definición de un modelo de usuario o una etapa
de definición de características adaptativas de la navegación en función de
las preferencias, conocimiento o tareas de usuario.
Otras características relevantes del proceso y método de autoría de
UWE son el uso del paradigma orientado a objetos, su orientación al usuario,
la definición de un meta-modelo (modelo de referencia) que da soporte al
método y el grado de formalismo que alcanza debido al soporte que
proporciona para la definición de restricciones sobre los modelos.
Los principales de aspectos en los que se fundamenta UWE son los
siguientes:
Uso de una notación estándar, para todos los modelos (UML:
Lenguaje de modelado unificado).
Definición de métodos: Definición de los pasos para la construcción
de los diferentes modelos.
Especificación de Restricciones: Se recomienda el uso de
restricciones escritas (OCL: Lenguaje de restricciones de objetos) para
aumentar la exactitud de los modelos.
40
2.9.3.1.- Fases del Desarrollo Web. Por lo que respecta al proceso de autoría de la aplicación, UWE hace
un uso exclusivo de estándares reconocidos como UML y el lenguaje de
especificación de restricciones asociado OCL. Para simplificar la captura de
las necesidades de las aplicaciones web, UWE propone una extensión que
se utiliza a lo largo del proceso de autoría. Este proceso de autoría está
dividido en cuatro pasos o actividades:
El análisis de Requisitos: el cual fija los requisitos funcionales de la
aplicación Web para reflejarlos en un modelo de casos de uso.
El diseño Conceptual: el cual esta materializado en un modelo de
dominio, considerando los requisitos reflejados en los casos de uso.
El diseño Navegacional este lo podemos subdividir en: Modelo
del Espacio de Navegacional, Modelo de la Estructura de navegación el cual
muestra la forma de navegar ante el espacio de navegación;
El diseño de presentación: el cual representa las vistas del interfaz
del usuario mediante modelos estándares de interacción UML.
2.9.4.- METODOLOGIA DE DESARROLLO DE AMBIENTE WEB
PARADIGMA ESPIRAL ORIENTADO A LA WEB (MODELO DEL
PROCESO IWEB)
41
Figura 3. El modelo del proceso IWeb
Fuente: Santos y Mantilla (2007, p. 19)
Según Santos y Mantilla (2007, p. 19) se encuentra desarrollada la
metodología por las siguientes fases:
FASE I - Formulación
Para hacer una correcta formulación, las primeras interrogantes deben
ser, entre otras cosas:
Porque y para qué hacer la WebApp?
Porque es necesaria?
Quién la va a usar?
Las respuestas serán muy generales, y no entraran en detalles. Se
puede clasificar las metas específicas en:
Metas Informativas: Definen los objetivos sobre el contenido e
información que se dará al usuario.
42
Metas Aplicables: Son los servicios o tareas que puede realizar la
WebApp.
Después de las metas, se hará el Perfil del Usuario, determinando las
principales características de los potenciales navegadores y clientes. Más
adelante, se hace la Afirmación del Ámbito, con la que vemos la posible
integración con sistemas ya existentes, como pueden ser bases de datos.
FASE II - Análisis Identifica los datos y requisitos funcionales y de comportamiento para
la WebApp.
Durante la IWeb, se realizan 4 tipos de análisis:
Análisis del contenido: Se puede utilizar el modelado de datos, y en
esta etapa se identifica todo el contenido que se va a proporcionar. (Texto,
gráficos, imágenes, video y sonido)
Análisis de la interacción: Se realizan casos prácticos y sus casos
de uso para la descripción detallada de la interacción usuario-WebApp.
Análisis funcional: Se detallan las funciones y operaciones de
procesamiento adicionales que se aplicaran en el contenido de la WebApp
Análisis de la configuración: Se detalla y describe el lugar donde va
a residir la App. (Intranet, Internet o Extranet). También se tiene que
identificar la infraestructura de los componentes y el grado de utilización de la
base de datos para generar el contenido.
43
En todo caso es recomendable hacer un documento que recoja la
información de todo el proceso de análisis y que será revisado y modificado
para hacer otro documento que pasarle a los diseñadores de la WebApp. En
el caso de una App grande no es recomendable hacer un documento muy
extenso, porque los requisitos estarán cambiando continuamente, y quedaría
obsoleto antes de terminarlo.
FASE III - Diseño
La característica de inmediatez obliga a que los diseños se hagan
rápidamente ya que sean evolucionables. Muchas veces la rapidez o
precipitación en el diseño nos cierra puertas a la evolución de la aplicación.
Los ingenieros Web, trabajan bajo los siguientes elementos técnicos:
Principios y métodos de diseño: Facilitaran la adaptación, pruebas,
mejoras y uso.
Modularidad eficaz (cohesión alta y acoplamiento bajo)
Elaboración pasó a paso
Diseño orientado a objetos y diagramas UML
Reglas de oro: que se han ido construyendo desde los inicios de
Internet
Configuraciones de diseño: Aplicables a los elementos funcionales y
a los documentos, gráficos y estética general.
44
Plantillas: Dotan de una estructura similar cada elemento,
configuración de diseño, o documento a utilizar dentro de la WebApp. Se
hace posible pasando como parámetros a esa plantilla, los datos
relevantes, que darán cuerpo al esquema.
Diseño Arquitectónico Se encarga de la definición de la estructura global hipermedia y en la
aplicación de las configuraciones de diseño y plantillas. Dicha estructura
depende de las metas establecidas, del contenido y de la filosofía de
navegación. Típicamente hay:
Estructuras lineales: cuando es predecible la sucesión de
interacciones. Por ejemplo en la entrada, y validación de datos, hay una
estructura lineal. También existen lineales con flujo opcional, y lineal con
desviaciones.
Estructuras reticulares: Solo si el contenido de la Web puede ser
organizado en dos o más dimensiones. Para ellos el contenido debe ser muy
regular. Por ejemplo, marcas de electrodomésticos y tipos de
electrodomésticos.
Estructuras jerárquicas: Son las más comunes. En las jerarquías de
software tradicionales se fomentan el flujo de control solo a lo largo de las
ramas verticales. En una WebApp se pueden enlazar por hipertexto ramas
verticales de la misma estructura. Es el “Acoplamiento”.
45
Estructura en red (o de Web pura): Es como la arquitectura “en
evolución” de los sistemas OO. Se enlaza todo con todo. Da mucha
flexibilidad de navegación, aunque a veces es confusa para el usuario. Es
común combinar varias de las estructuras, dando lugar a estructuras
híbridas. Los patrones de diseño pueden aplicarse en el nivel de componente
(cuando se requiere la funcionalidad del proceso de datos), jerárquico, y de
navegación (que tratan sobre como el usuario podrá moverse por el
contenido de la aplicación)
Entre estos últimos, están:
Ciclo: Se devuelve al usuario al nodo de contenido visitado
anteriormente.
Anillo de Web: Se enlazan páginas de un mismo tema.
Contorno: Cuando varios ciclos inciden en otro
Contrapunto: durante la narración se añaden comentarios de
hipertexto.
Mundo de espejo: Varias narraciones desde puntos de vista distintos
Tamiz: Se presentan opciones que el usuario va eligiendo, hasta
llegar a un punto que el mismo habrá provocado con sus decisiones.
Vecindario: Marco de navegación uniforme por todas las páginas
web.
46
Diseño de navegación
Una vez establecida la arquitectura se define la ruta que permitirá
acceder al contenido y a los servicios. Se deberá identificar una semántica
para según qué usuarios y definir una sintaxis (mecánica) para la
navegación. Se tendrá, habitualmente, varios papeles: visitante, cliente,
cliente registrado, cliente privilegiado, administrador, etc. La semántica para
cada rol será distinta. El diseñador crea una USN (Unidad Semántica de
Navegación) para cada meta asociada a cada rol de usuario. Cada USN
tiene unas “formas de navegación” (WoN) para que cada usuario llegue a
cada meta que se proponga. Entre las opciones de enlaces (texto, iconos,
botones, interruptores, metáforas gráficas, entre otros) deberemos elegir la
que más se adecuen al interfaz de nuestra web.
Desde el punto de vista de los buscadores hoy por hoy es mejor un
enlace texto con la palabra con la que nos gustaría dotar de importancia a la
página web enlazada que cualquier otra cosa.
Sin embargo, desde nuestra visión de diseño, los botones, imágenes e
iconos que usemos deberán tener un aspecto clickable. Los enlaces de texto
deberán tener un color característico, diferenciador del resto del documento.
También se harán necesarias ayudas a la navegación por el sitio: una vista
de esquema, un mapa web, tabla de contenidos, mecanismos de búsqueda y
servicios dinámicos de ayuda.
47
Diseño de la interfaz
Además de las consideraciones de diseño de interfaces de cualquier
otro software, en WebApps es necesario considerar nuevos factores, todos
ellos, bastante subjetivos.
Algunas sugerencias y generalizadas son: Los errores de servidor deben ser mínimos. El usuario tiene poca
paciencia, y generalmente muchos otros recursos en la Web.
No se debe obligar a hacer leer grandes cantidades de texto, sobre
todo si estamos en alguna de las secciones de Ayuda de nuestra App.
Evitar poner “En construcción”. Crea expectativas decepcionantes.
Evitar el scroll. Un usuario poco experto “no sabe que existe el scroll”.
Todo lo que se le pueda dar en un “pantallazo” será mejor entendido por la
mayoría.
Los menús de navegación estarán disponibles en todas las páginas
las funciones de navegación no deberán depender del navegador que se
esté usando.
La estética nunca deberá sustituir la funcionalidad.
Las opciones de navegación y el resto de funcionalidades deberán ser
obvios.
48
FASE IV – Pruebas Son el proceso de ejercitar el software con el fin de encontrar y
corregir los errores. En las WebApps, es un reto, debido a la variedad de
navegadores, sistemas operativos, plataformas hardware y protocolos de
comunicación.
Las estrategias y tácticas a seguir son:
1. El modelo de contenido es revisado para descubrir errores: similar
a un corrector ortográfico.
2. El modelo de diseño es revisado para descubrir errores de
navegación: Se revisan los posibles errores 404 de navegación, y vemos si
cada enlace lleva a la correspondiente USN de la meta del rol de usuario a la
que pertenece.
3. Se aplican pruebas de unidad a los componentes de proceso
seleccionado y las páginas Web: en muchos casos la unidad comprobable
más pequeña es la propia página web. Muchas veces no es posible o
practico comprobar elementos más pequeños como formularios, objetos,
mapas de imágenes, entre otros.
4. Se construye la arquitectura y se realizan las pruebas de
integración: La estrategia para la prueba de integración depende de la
arquitectura que se haya elegido. En estructuras jerárquicas lineales,
reticulares o sencillas, es muy similar a como se integran los módulos del
49
software convencional. En jerarquías mezcladas o arquitecturas de red, es
similar a los sistemas OO.
5. La WebApp ensamblada se prueba para conseguir una
funcionalidad global y un contenido: Se hace una prueba de acciones visibles
y de salidas reconocibles para el usuario.
6. Se implementa la WebApp en una variedad de configuraciones
diferentes de entornos y comprobar así la compatibilidad con cada
configuración: Se lleva hace una matriz de referencias cruzadas con
sistemas operativos, plataformas de hardware, navegadores y protocolos de
comunicación. Se hacen pruebas para cubrir los errores asociados con todas
y cada una de las configuraciones posibles.
7. La WebApp se comprueba con una población de usuarios finales
controlada y monitorizada: Se hacen grupos de usuarios según los posibles
roles, se hace un uso intensivo y se evalúan los resultados, para ver errores
de contenido y navegación, usabilidad, compatibilidad, fiabilidad y
rendimiento.
2.10.- GESTIÓN OPERATIVA Afirma, Gimbert (2010, p. 22), es un enfoque a corto plazo, por ello se
dice que es “gestionar el día a día”. Los problemas operativos surgen hoy y
necesitan una solución inmediata para que no afecten a la organización.
50
Según Díaz (2009, p. 57), se entiende por gestión operativa la que
realiza el Directivo público hacia el interior de su organización para aumentar
su capacidad de conseguir los propósitos de sus políticas.
Abarca los cambios en la estructura de la organización y en el sistema
de roles y funciones, la elección de personal directivo y asesor de mediano
nivel, los procesos de capacitación del personal de planta permanente, la
mejora continua del funcionamiento de la Organización con su actual
tecnología y la introducción de innovaciones técnicas y estratégicas acordes
con los proyectos en curso.
La tarea esencial de la gestión operativa es el despliegue de recursos
y capacidades para obtener resultados concretos. Requiere objetivos
acertados (acordes con los requerimientos sociales), capacidad de conseguir
recursos y lograr implantar sistemas, procedimientos y personal en forma
acorde con lo que se quiere conseguir. Según una visión estratégica de la
gestión operativa, los directores son responsables del uso que hacen del
poder y del dinero público, en una actuación que debe ser imparcial, creando
organizaciones adaptables, flexibles, controlables y eficientes.
La visión convencional del funcionamiento del sector público lo
considera un caso especial de creación de valor en condiciones de pocos
cambios y conflictos, con innovaciones mínimas, manteniendo a la capacidad
operativa contenida dentro del sistema de la organización misma. La nueva
visión estratégica aparece como realmente necesaria cuando hay muchos
51
cambios y conflictos y, por ende, necesidad de innovar para asumir los
nuevos desafíos con posibilidades de éxito.
3.- SISTEMAS DE VARIABLES El presente estudio se realizó en torno a las variables antes mencionadas
donde se identifican independientemente, además se define de manera
conceptual y operacional las mismas, de esta manera se amoldaran estos
estudios a la investigación.
3.1.-DEFINICION NOMINAL
Sistemas de Información
Ambiente Web
Gestión Operativa
3.2.- DEFINICION CONCEPTUAL
Conceptualmente los sistemas de información son un conjunto de
componentes interrelacionados que recolectan (o recuperan), procesan,
almacenan y distribuye información para apoyar la toma de decisiones y el
control de una organización. También puede ayudar a los gerentes y
trabajadores a analizar problemas, a visualizar asuntos complejos y a crear
productos nuevos. (Laudon y Laudon 2004, p.8)
52
Además de manera conceptual se define el ambiente web como el
diseño multidisciplinar muy centrado en el usuario que incluye influencias de
las artes visuales, la tecnología, el contenido y la finalidad, La finalidad puede
recoger hasta consideraciones económicas, tales como el coste del sitio en
relación con sus beneficios. (Powell 2001, p.21)
Por otra parte, la gestión operativa de manera conceptual se define
como aquello en que se tiene un enfoque a corto plazo, por ello se dice que
es “gestionar el día a día”. Los problemas operativos surgen hoy y necesitan
una solución inmediata para que no afecten a la organización. (Gimbert
2010, p.22).
3.3.- DEFINICION OPERACIONAL
En el ámbito operativo el sistema de información a implementar
tendrá como principales funciones el almacenaje, distribución, procesamiento
y seguridad de los datos, manteniendo los mismos organizados a través de
una base de datos. Logrando que la gestión operativa de la empresa
Importadora SURCA1 C.A sea más efectiva produciendo mayores ingresos a
la misma y mejorando los procesos que se llevan a cabo en esta de acuerdo
a las ventas, pedidos, compras e inventario.
Así mismo, se implantara bajo un ambiente web para que los
empleados de la empresa Importadora SURCA1 C.A puedan tener acceso a
esta desde cualquier otro sitio y de forma remota, ya que esta empresa
53
cuenta con más de una sucursal, de igual manera para agilizar los procesos
así como también prestar mejor servicio a los clientes, los cuales puedan
disponer de un sistema de apartado para los repuestos que se encuentren
ofertados en la empresa Importadora SURCA1 C.A.
