UNIVERSIDAD NACIONAL EXPERIMENTAL DE GUAYANA

VICERRECTORADO ACADÉMICO
COORDINACIÓN GENERAL DE PREGRADO
COORDINACIÓN DE INGENIERÍA EN INFORMÁTICA
DESARROLLO WEB

ASIGNACIÓN III

PROFESOR INTEGRANTES
Oscar Rodríguez Any Muñoz
Julio Cardozo
Johan Martin

PUERTO ORDAZ, NOVIEMBRE 2017

 INTRODUCCIÓN

Antes de desarrollar la teoría sobre los sistemas es necesario conocer como

surge, por quien y para que.

La teoría de general de sistemas surgió con los trabajos del biólogo alemán
Ludwing von Bertalanffy, publicados entre 1950 y 1968. La TGS no busca
solucionar problemas ni proponer soluciones prácticas, pero si producir teorías
y formulaciones conceptuales que puedan crear condiciones de aplicación en
la realidad empírica. Los supuestos básicos de la teoría general de sistemas
son:

 Existe una nítida tendencia hacia la integración en las diversas ciencias

naturales y sociales. Esta integración parece orientarse hacia una teoría
de los sistemas.
 Dicha teoría de los sistemas puede ser una manera más amplia de
estudiar los campos no físicos del conocimiento científico, en especial
las ciencias sociales.
 Esa teoría de sistemas, al desarrollar principios unificadores que
atraviesan verticalmente los universos particulares de las diversas
ciencias involucradas, nos aproximan al objeto de la unidad de la
ciencia. Esto pude llevarnos a una integración en la administración
científica.
La teoría general de los sistemas afirma que las propiedades de los sistemas
no pueden describirse significativamente en términos de sus elementos
separados. La comprensión de los sistemas solo ocurre cuando se estudian
globalmente, involucrando todas las interdependencias de sus partes.

El concepto sistema pasó a dominar las ciencias y, en especial, la

administración. Si se habla de astronomía, se piensa en el sistema solar. La
sociología habla de sistema social, y así sucesivamente. En la actualidad el
enfoque sistemático es tan común en administración que no se nos ocurre
pensar que estamos utilizándolo en todo momento.

La teoría de sistemas penetro rápidamente en la teoría administrativa por dos

razones básicas:

Por una parte, debido a la necesidad de sintetizar e integrar mas las teorías
que la precedieron, lo cual se llevo a cabo con bastante éxito cuando los
behavioristas aplicaron las ciencias del comportamiento al estudio de la
organización.

Por otra parte, la cibernética y la tecnología informática trajeron inmensas

posibilidades de desarrollo y operación de las ideas que convergían hacia
una teoría de sistemas aplicada a la administración.

ELEMENTO
Se entiende por elemento de un sistema las partes o componentes que lo
constituyen. Estas pueden referirse a objetos o procesos. Una vez
identificados los elementos pueden ser organizados en un modelo.

ATRIBUTO
Se entiende por atributo las características y propiedades estructurales o
funcionales que caracterizan las partes o componentes de un sistema
(elementos)
 MODELO
Los modelos son constructos diseñados por un observador que persigue
identificar y mensurar relaciones sistémicas complejas. Todo sistema real
tiene la posibilidad de ser representado en más de un modelo. La decisión,
en este punto, depende tanto de los objetivos del modelador como de su
capacidad para distinguir las relaciones relevantes con relación a tales
objetivos. La esencia de la novelística sistémica es la simplificación.

AMBIENTE
Se refiere al área de sucesos y condiciones que influyen sobre el
comportamiento de un sistema. En lo que a complejidad se refiere, nunca un
sistema puede igualarse con el ambiente y seguir conservando su identidad
como sistema. La única posibilidad de relación entre un sistema y su
ambiente implica que el primero debe absorber selectivamente aspectos de
éste. Sin embargo, esta estrategia tiene la desventaja de especializar la
selectividad del sistema respecto a su ambiente, lo que disminuye su
capacidad de reacción frente a los cambios externos. Esto último incide
directamente en la aparición o desaparición de sistemas abiertos.

ORGANIZACIÓN
N. Wiener planteó que la organización debía concebirse como "una
interdependencia de las distintas partes organizadas, pero una
interdependencia que tiene grados. Ciertas interdependencias internas
deben ser más importantes que otras, lo cual equivale a decir que la
interdependencia interna no es completa" (Buckley. 1970:127). Por lo cual la
organización sistémica se refiere al patrón de relaciones que definen los
estados posibles (variabilidad) para un sistema determinado.
 ESTRUCTURA
Las interrelaciones más o menos estables entre las partes o componentes
de un sistema, que pueden ser verificadas (identificadas) en un momento
dado, constituyen la estructura del sistema. Según Buckley (1970) las clases
particulares de interrelaciones más o menos estables de los componentes
que se verifican en un momento dado constituyen la estructura particular del
sistema en ese momento, alcanzando de tal modo una suerte de "totalidad"
dotada de cierto grado de continuidad y de limitación. En algunos casos es
preferible distinguir entre una estructura primaria (referida a las relaciones
internas) y una hiperestructura (referida a las relaciones externas).

COMPLEJIDAD
Por un lado, indica la cantidad de elementos de un sistema (complejidad
cuantitativa) y, por el otro, sus potenciales interacciones (conectividad) y el
número de estados posibles que se producen a través de éstos (variedad,
variabilidad). La complejidad sistémica está en directa proporción con su
variedad y variabilidad, por lo tanto, es siempre una medida comparativa.
Una versión más sofisticada de la TGS se funda en las nociones de
diferencia de complejidad y variedad. Estos fenómenos han sido trabajados
por la cibernética y están asociados a los postulados de R.Ashby (1984), en
donde se sugiere que el número de estados posibles que puede alcanzar el
ambiente es prácticamente infinito. Según esto, no habría sistema capaz de
igualar tal variedad, puesto que si así fuera la identidad de ese sistema se
diluiría en el ambiente.

RELACION
Las relaciones internas y externas de los sistemas han tomado diversas
denominaciones. Entre otras: efectos recíprocos, interrelaciones,
organización, comunicaciones, flujos, prestaciones, asociaciones,
intercambios, interdependencias, coherencias, etcétera. Las relaciones entre
los elementos de un sistema y su ambiente son de vital importancia para la
comprensión del comportamiento de sistemas vivos. Las relaciones pueden
ser recíprocas (circularidad) o unidireccionales. Presentadas en un momento
del sistema, las relaciones pueden ser observadas como una red
estructurada bajo el esquema input/output.

METODOLOGIA DE CONSTRUCCIÓN DE SISTEMAS

La metodología de construcción de sistemas implementa para:
a) observación del comportamiento de un sistema real,
b) identificación de los componentes y procesos fundamentales del
mismo,
c) identificación de las estructuras de retroalimentación que permiten
explicar su comportamiento,
d) construcción de un modelo formalizado sobre la base de la
cuantificación de los atributos y sus relaciones
e) trabajo del modelo como modelo de simulación (Forrester).
VIABILIDAD
Indica una medida de la capacidad de sobrevivencia y adaptación
(morfostásis, morfogénesis) de un sistema a un medio en cambio.

METODOLOGÍA DE DESARROLLO DE SISTEMAS DE INFORMACIÓN:

CLÁSICO Y PROTOTIPO

Una Metodología para el Desarrollo de Sistemas de Información es un

conjunto de actividades llevadas a cabo para desarrollar y poner en marcha
un Sistema de Información.
Objetivos de una Metodología para el Desarrollo de Sistemas de
Información

 Definir actividades a llevarse a cabo en un Proyecto de S.I.

 Unificar criterios en la organización para el desarrollo de S.I.
 Proporcionar puntos de control y revisión
 Asegurar la uniformidad y calidad tanto del desarrollo como del
sistema en sí
 Satisfacer las necesidades de los usuarios del sistema
 Conseguir un mayor nivel de rendimiento y eficiencia del personal
asignado al desarrollo
 Ajustarse a los plazos y costos previstos en la planificación
 Generar de forma adecuada la documentación asociada a los
sistemas
 Facilitar el mantenimiento posterior de los sistemas

Independientemente de la Metodología de Desarrollo de Sistemas de

Información que se siga, varios autores sugieren distribuir el tiempo de
desarrollo de acuerdo a los siguientes porcentajes:
Distribución del tiempo en proyectos de Sistemas de Información:
Metodologías clásicas:
 Cascada: El modelo de cascada original se desarrolló entre las
décadas de los años 60 y 706 y se define como una secuencia de
actividades, donde la estrategia principal es seguir el progreso del
desarrollo de software hacia puntos de revisión bien definidos (en
inglés, milestones o checkpoints) mediante entregas programadas con
fechas precisas (en inglés, schedule). El modelo original planteaba
que cada actividad debía completarse antes de poder continuar con la
siguiente actividad. Sin embargo, en una revisión posterior se extendió
el modelo, permitiendo regresar a actividades anteriores.
 Algunas de las creencias del modelo de cascada son que las metas se
logran mejor cuando se tienen puntos de revisión bien preestablecidos y
documentados (dividiendo el desarrollo del software en actividades
secuenciales bien definidas), los documentos técnicos son comprensibles
para usuarios y administradores no técnicos, cada detalle de los requisitos se
conoce de antemano antes de desarrollar el software (dichos detalles son
estables durante el desarrollo) y las pruebas y evaluaciones se realizan de
manera eficiente al final del desarrollo.

El modelo de cascada llamado también lineal secuencial. Proporciona una

simple visión del desarrollo del software. A los procesos los representa como
fases separadas y secuenciales en tiempo. Antes de codificar debemos
diseñar el software, además probarlo antes de construirlo y ponerlo en
operación.

 Incremental:
El modelo incremental consiste de un desarrollo inicial de la arquitectura
completa del sistema, seguida de incrementos y versiones parciales de
éste. Cada incremento tiene su propio ciclo de vida, típicamente
siguiendo el modelo de cascada. Los incrementos pueden construirse de
manera serial o paralela dependiendo de la naturaleza de la dependencia
entre versiones y recursos. Cada incremento agrega funcionalidad
adicional o mejorada sobre el sistema.
Conforme se completa cada etapa, se verifica e integra la última versión
con las demás versiones ya completadas del sistema.Durante cada
incremento, el sistema se evalúa con respecto al desarrollo de versiones
futuras.

Las actividades se dividen en procesos y subprocesos, dando lugar al

término fábrica de software (en inglés, software factory). Para que la
secuencia de desarrollo sea exitosa, es esencial definir etapas que no
requieran cambiar los resultados anteriores al agregar nuevas. Por lo tanto,
es importante comprender al inicio los requisitos completos del sistema, algo
que normalmente es muy difícil de lograr. El desarrollo incremental evita la
teoría del “big bang” para el desarrollo de software, donde una gran
explosión de desarrollo se transforma repentinamente en el sistema final.

Algunas de las creencias del modelo de cascada son que la

administración de proyectos es más fácil de lograr en incrementos más
pequeños, es más fácil comprender y probar incrementos de funcionalidad
más pequeños, la funcionalidad inicial se desarrolla más temprano (logrando
resultados de inversión en menor tiempo) y hay más probabilidad de
satisfacer el cambio en los requisitos de usuario mediante incrementos del
software en el tiempo que si fueran planeados todos a la vez en un mismo
periodo.

 Evolutivo
El modelo evolutivo es una extensión al modelo incremental en la que los
incrementos se hacen de manera secuencial, en lugar de en paralelo.10
Desde el punto de vista del cliente, el sistema evoluciona según vayan
siendo entregados los incrementos. Desde el punto de vista del
desarrollador, los requerimientos que son claros al principio del proyecto
dictan el incremento inicial, mientras que los incrementos para cada uno de
los siguientes ciclos de desarrollo se clarifican a través de la experiencia de
los incrementos anteriores.

Este modelo considera que el desarrollo de sistemas es un proceso de

cambios progresivos mediante deltas (cambios) de especificación de
requerimientos. El modelo evolutivo es también conocido como desarrollo
rápido de aplicaciones (en inglés,RAD—rapid application development), que
se basa tradicionalmente en el uso de prototipos (en inglés,rapid
prototyping).
  Prototipo:
Un prototipo de software se considera como un medio para especificar los
requisitos y un enlace de comunicación entre el usuario final y el diseñador,
ayudando a reducir el riesgo de carecer de requerimientos iniciales
completos y estables. Algunas de las creencias del modelo de cascada son
la entrega temprana de parte del sistema, aunque no estén completos todos
los requerimientos, ya que esto permite utilizarlo como herramienta para la
generación de requerimientos faltantes, obteniendo beneficios para el
sistema mediante entregas iniciales mientras las entregas posteriores se
encuentran en desarrollo.

 Espiral:
El modelo espiral, desarrollado durante la década de los años 80, es una
extensión del modelo de cascada. A diferencia del modelo de cascada, que
es dirigido por documentos, el modelo espiral se basa en una estrategia
para reducir el riesgo del proyecto en áreas de incertidumbre, como tener
requerimientos iniciales incompletos e inestables.

El modelo enfatiza ciclos de trabajo, cada uno de los cuales estudia el

riesgo antes de proceder al siguiente ciclo. Cada ciclo comienza con la
identificación de los objetivos, soluciones alternas y restricciones asociadas
con cada alternativa, y finalmente se procede a su evaluación. Cuando se
encuentra que existe cierta incertidumbre, se utilizan diversas técnicas para
reducir el riesgo de las distintas alternativas. Cada ciclo del modelo espiral
termina con una revisión que discute los logros actuales y los planes para el
siguiente ciclo.

Al igual que el modelo evolutivo, el modelo espiral incorpora una estrategia

de uso de prototipos como parte del manejo del riesgo. Las creencias del
modelo de espiral son que una actividad comienza cuando se entienden los
objetivos y riesgos involucrados, se usan las herramientas que mejor
reduzcan los riesgos basándose en la evaluación de soluciones alternas,
todo el personal relacionado debe involucrarse en una revisión que
determine cada actividad (planeando y comprometiéndose con las siguientes
actividades) y el desarrollo se incrementa en cada etapa, permitiendo
prototipos sucesivos del producto. Con algunas variantes, éste es el modelo
de proceso más importante en la actualidad.

 Prototipos
Un prototipo es una versión preliminar, intencionalmente incompleta o
reducida de un sistema. El uso de prototipos es una estrategia que puede
aplicarse en casi todas las actividades del proceso de software. El propósito
de los prototipos es obtener de manera rápida la información necesaria como
ayuda en la toma de decisiones.

Los siguientes son algunos tipos de prototipo: Los prototipos de requisitos

permiten que los usuarios perciban la funcionalidad del producto final a
través del diseño de interfaces o pantallas del sistema. El objetivo es ayudar
a aclarar los requisitos y solicitar nuevas ideas. Los prototipos de análisis
permiten generar rápidamente una arquitectura general que considere las
características principales del sistema de acuerdo con la especificación de
requisitos.

Los prototipos de diseño permiten explorar y comprender la arquitectura

particular de un sistema para poder evaluar aspectos como cuellos de botella
(rendimiento y uso de memoria) o incoherencias en el diseño. Los prototipos
verticales permiten comprender parte de un problema y desarrollar su
solución completa.

Esto se hace generalmente cuando los conceptos básicos no están bien

comprendidos (por ejemplo, el seguimiento de cierta metodología). Los
prototipos de factibilidad permiten demostrar si es posible lograr ciertos
objetivos del proyecto (por ejemplo, aplicar una arquitectura particular,
conectarse a una base de datos bajo ciertas restricciones de rendimiento,
aprender a programar en cierto lenguaje en un tiempo determinado o
predecir los costos de desarrollo de un proyecto).

Un prototipo no es necesariamente un producto de calidad, que deba

mantenerse a largo plazo. Por el contrario, los prototipos a menudo son
creados y probados rápidamente, para luego ser descartados. Sin embargo,
es común que, por presiones de tiempo, se trate de enviar un prototipo al
mercado (venderlo) como si éste fuera el producto final. En general, siempre
existirá un conflicto entre un desarrollo rápido y un producto de calidad.

Las siguientes dos listas muestran algunas consideraciones para el éxito o

fracaso de los prototipos.

 Los prototipos tienen éxito cuando se comprende su propósito y se

usan de manera adecuada, se comprende la tecnología que va a
utilizarse y su relación con el proceso de prototipos, se integra un
grupo técnico apropiado para hacer el prototipo (líder de proyecto,
documentador, elaborador de prototipos de requisitos y análisis, y
elaborador de prototipos de diseño), se evalúa al grupo y las entregas
finales, se involucra temprano en el proceso de software a los usuarios
finales, se está dispuesto a repetir el proceso de prototipos para
comprender mejor la arquitectura básica, se establecen criterios de
evaluación apropiados al comienzo de cada etapa de prototipos y se
basa uno firmemente en estos criterios para su terminación y/o se
construyen prototipos basados en una biblioteca de código reutilizable,
controlada por el bibliotecario asignado.
 Los prototipos fallan cuando no se comprende qué es un prototipo y
cómo debe usarse, no se comprende el proceso lo suficientemente
bien como para organizar al grupo de manera adecuada, no se sabe
hasta cuándo dejar de evolucionar el prototipo y comenzar de cero
(así extendiendo demasiado el proceso), no se sabe hasta cuándo
continuar para tratar de lograr los criterios de evaluación deseados
 (así terminando prematuramente el proceso), no se utilizan ambientes
o herramientas de apoyo adecuados para el desarrollo particular, se
cree que un prototipo razonable es un producto aceptable y/o los
prototipos nunca terminan.
El paradigma de construcción de prototipos tiene tres pasos:

 Escuchar al cliente. Recolección de requisitos. Se encuentran y

definen los objetivos globales, se identifican los requisitos conocidos y
las áreas donde es obligatorio más definición.
 Construir y revisar la maqueta (prototipo).
 El cliente prueba la maqueta (prototipo) y lo utiliza para refinar los
requisitos del software.
Este modelo es útil cuando:

 El cliente no identifica los requisitos detallados.

 El responsable del desarrollo no está seguro de la eficiencia de un
algoritmo, sistema operativo o de la interface hombre -máquina.
Ciclo de Vida de un Sistema basado en Prototipo.

Una maqueta o prototipo de pantallas muestra la interfaz de la aplicación,

su cara externa, pero dicha interfaz está fija, estática, no procesa datos. El
prototipo no tiene desarrollada una lógica interna, sólo muestra las pantallas
por las que irá pasando la futura aplicación. Por su parte, el prototipo
funcional evolutivo desarrolla un comportamiento que satisface los requisitos
y necesidades que se han entendido claramente. Realiza, por tanto, un un
proceso real de datos, para contrastarlo con el usuario. Se va modificando y
desarrollando sobre la marcha, según las apreciaciones del cliente.

Esto ralentiza el proceso de desarrollo y disminuye la fiabilidad, puesto

que el software está constantemente variando, pero, a la larga, genera un
producto más seguro, en cuanto a la satisfacción de las necesidades del
cliente. Cuando un prototipo se desarrolla con el sólo propósito de precisar
mejor las necesidades del cliente y después no se va a aprovechar ni total ni
parcialmente en la implementación del sistema final se habla de un prototipo
desechable. Para que la construcción de prototipos sea posible se debe
contar con la participación activa del cliente.

Ventajas del Modelo de Prototipo.

Este modelo es útil cuando el cliente conoce los objetivos generales para
el software, pero no identifica los requisitos detallados de entrada,
procesamiento o salida. También ofrece un mejor enfoque cuando el
responsable del desarrollo del software está inseguro de la eficacia de un
algoritmo, de la adaptabilidad de un sistema operativo o de la forma que
debería tomar la interacción humano-máquina.

Desventajas del Modelo de Prototipo.

Su principal desventaja es que una vez que el cliente ha dado su

aprobación final al prototipo y cree que está a punto de recibir el proyecto
final, se encuentra con que es necesario reescribir buena parte del prototipo
para hacerlo funcional, porque lo más seguro es que el desarrollador haya
hecho compromisos de implementación para hacer que el prototipo funcione
rápidamente. Es posible que el prototipo sea muy lento, muy grande, no muy
amigable en su uso, o incluso, que esté escrito en un lenguaje de
programación inadecuado.

El cliente ve funcionando lo que para él es la primera versión del prototipo

que ha sido construido con "plastilina y alambres", y puede desilusionarse al
decirle que el sistema aún no ha sido construido. El desarrollador puede
ampliar el prototipo para construir el sistema final sin tener en cuenta los
compromisos de calidad y de mantenimiento que tiene con el cliente.
 BASES TEÓRICAS PARA METODOLOGÍA DE DESARROLLO WEB.

En la actual era informática, el desarrollo de aplicaciones web implica

decisiones no convencionales de diseño e implementación que
ineludiblemente influyen en todo el proceso de desarrollo, afectando la
división de tareas como lo son los problemas como el diseño del modelo del
dominio y la construcción de la interfaz de usuario, las cuales tienen
requerimientos disjuntos que deben ser tratados por separado.
Una aplicación web es:
”Un SI donde una gran cantidad de datos volátiles, altamente
estructurados, van a ser consultados, procesados y analizados
mediante navegadores. Una de las principales características va a ser
su alto grado de interacción con el usuario, y el diseño de su interfaz
debe ser claro, simple y debe estar estructurado de tal manera que sea
orientativo para cada tipo de usuarios.” Kappel, (2003)

Tanto el enfoque del tipo de usuarios a los que estará dirigida la

aplicación, como el alcance de la misma son consideraciones tan importantes
como las tecnologías elegidas para realizar la implementación. Precisamente
como las tecnologías pueden limitar la funcionalidad de la aplicación,
decisiones de diseño equivocadas también pueden reducir su capacidad de
extensión y reusabilidad. Es por ello que el empleo de una metodología de
diseño y de tecnologías que se adecúen naturalmente a ésta, representa una
alta importancia para el desarrollo de aplicaciones complejas.
Por lo anteriormente dicho, pasada la última década, se han planteado
diferentes metodologías de desarrollo Web, dichas metodologías cuentan
con las herramientas demandadas para el diseño de este tipo de aplicación,
ayudando así a los desarrolladores a diseñar aplicaciones efectivas que
cumplan los objetivos para las cuales fueron desarrolladas.
 Para describir las metodologías es necesario explicar el marco de
referencia que recopilan las potencialidades y características de tales
propuestas.
Niveles: Los niveles representan la composición de una aplicación Web,
Cachero (2003) define este término como: “los distintos puntos de vista
desde los cuales se puede estudiar el sistema: contenido, navegación
(hipertexto) y presentación”.
Es decir, el contenido es la estructura lógica de la aplicación, el hipertexto
es como está estructurado el contenido dentro de una página y sus enlaces,
y por último la presentación que es la interfaz del usuario, es decir, el diseño
de la página. Para el caso de software tradicional, sólo aplicarían los niveles
de: contenido y la presentación, ésta es la principal diferencia con las
aplicaciones Web.
Aspectos: “Añaden la perspectiva acerca del carácter estático
(estructural) / dinámico (comportamiento) de cada uno de los niveles.”
(Cachero, 2002). La relevancia que pueden tener los modelos de estructura y
comportamiento dependen en gran medida del tipo de aplicación que se va a
realizar, ya que si se desea desarrollar una aplicación estática, el modelado
del comportamiento es irrelevante, en cambio, una aplicación que maneje
diversos tipos de usuarios los cuales interactúan con el sistema, el modelado
del comportamiento se hace necesario.
Fases: Son las secuencias de los pasos para modelar los niveles, por
ejemplo: la aplicación del análisis en modelar los niveles y los aspectos,
luego aplicar el diseño en el modelado de los niveles, entre otros.
En este mismo orden de ideas, por las características propias de las
aplicaciones Web y tomando en consideración el marco de referencia
anterior, es necesario que las propuestas metodológicas sean capaces de
describir modelos específicos.
Algunos modelos que se deben llevar a cabo en una propuesta en su
etapa madura son:
 Modelado de Requerimientos: En esta etapa es donde se recogen, se
evalúan y se analizan todas las características que se deben desarrollar para
cumplir los objetivos que persigue la aplicación Web.
Kappel, Pröll,Reich, & Retschitzegger, (2003) puntualizan esta etapa como:
“Varias técnicas pueden ser usadas para identificar, analizar, describir,
evaluar y gestionar los requerimientos de una aplicación Web. Los
casos de usos son la técnica de modelado más empleada en el
levantamiento de los requerimientos, ya que puede ser representada
gráficamente.”

Modelado del Contenido: Se puede definir como la estructuración de

cómo será almacenada la data de la aplicación, es decir detallar la Base de
Datos y cómo será su conducta según la tarea que se ejecute en la
aplicación. Dicho modelado es esencial a la hora de diseñar aplicaciones
Webs, debido a que un buen diseño del contenido facilitaría el proceso de
desarrollo.
Modelado del Hipertexto: El modelado del hipertexto es prácticamente el
mapa navegacional de la aplicación, así como la estructura del contenido
dentro de los nodos. Un buen diseño del hipertexto permite que la aplicación
sea más fácil de usar y evita la redundancia de la información, generando
una aplicación más amigable.

Modelado de Presentación:
“El modelo de presentación detalla cómo será la interfaz del usuario y
el ‘look and feel’ de la aplicación Web. El modelado de la presentación
está destinado a diseñar la estructura y el comportamiento de la interfaz
del usuario para asegurar que la interacción con la aplicación Web sea
sencilla y se auto-explique.” KAPPEL(2003).
Este modelado meramente específico y detalla la interfaz gráfica que
interactuará con los usuarios. Este modelado genera 2 resultados, el primero
es el de producir el modelado recurrente de la página (Ejemplo: el
encabezado y el pie de página). El segundo es referente a la estructura de
cada página de la aplicación, es decir, en donde irán colocados los botones,
los cuadros de texto, la información, entre otros.
Modelado de Personalización: Este modelo describe cómo será la
estructura y el comportamiento de la aplicación según el usuario que
interactúe en un momento específico con la aplicación.

METODOLOGIA UWE

“Es una metodología con un modelado de proceso espiral / interactivo –

incremental y tomando como lenguaje de notación UML, ésta metodología
está enfocada en el diseño sistemático, la personalización y la generación
semiautomática de escenarios.” Como vemos, esta metodología soporta el
desarrollo de aplicaciones Web con un especial interés en la sistematización,
personalización y generación semi-automática de código. Koch & Kraus,
(2002).
UWE se centra en actividades de modelado tales como el análisis de
requerimientos y el diseño conceptual, de navegación y de presentación
complementado con modelado de tareas y visualización de escenarios Web.
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.
Consecuentemente UWE propone los siguientes pasos a la hora del
desarrollo de una aplicación Web:
Especificación de requerimientos: es donde se describen los requisitos
funcionales de la aplicación a desarrollar. UWE propone el modelo de casos
de uso de UML para el levantamiento de los requerimientos, ya que a través
de esta herramienta se puede describir una parte del comportamiento de la
aplicación sin revelar la estructura interna, así como la identificación de los
distintos usuarios que interactuarán con la aplicación.
Modelo Lógico-Conceptual: aquí se especifican los elementos del
dominio de la aplicación. UWE propone para este paso la utilización de un
diagrama de clases de UML
Modelo de Navegación: en este paso se genera la especificación de los
objetos que pueden ser visitados mediante la navegación dentro de la
aplicación Web y las asociaciones entre ellos. En UWE los modelos de la
navegación son representados por los diagramas de clases estereotipadas
de UML.
Modelo de presentación: se define como los usuarios visualizarán los
objetos de navegación y las primitivas de acceso. Para este modelo UWE
propone una forma particular de un diagrama de clase, el cual representa de
forma gráfica, las clases definidas anteriormente.
 CONCLUSIÓN

Después de realizar la investigación podemos concluir que cada uno de los

temas planteados lo hemos desarrollado a lo largo de nuestra carrera en
diferentes materias ya sea de forma teórica o de forma práctica, uno de los
puntos de importancia es la metodología básica para el desarrollo web
debido a que es esencial en la toma de decisiones para determinar los
requerimientos.
REFERENCIAS BIBLIOGRÁFICAS.

Koch, N., & Kraus, A. (2002). The expressive Power of UML-based Web
Engineering. Second International Workshop on Web-oriented Software
Technology.

Ludwig Von Bertalanffy. (1968). General Systema Theory; Foundations,

Development, Applications.

López, M (2010). Ingeniería Web Capitulo III.

MONTILVA, Jonás: Método Watch. 2008.

PRESSMAN, Roger: Ingeniería del Software. Un enfoque práctico. Ed

McGraw Hill. México, 2010. 7a Edición.

SENN, James: Analysis & Design of Information Systems. Ed McGraw Hill.

2008.

Arnold, M & D. Rodríguez. "El Perspectivismo en la Teoría Sociológica".

Revista Estudios Sociales (CPU). Santiago. Chile. Nº64. 1990ª.

Ashby, W.R. "Sistemas y sus Medidas de Información". En: von Bertalanffy,

et. al. Tendencias en la Teoría General de los Sistemas. Alianza
Editorial. Madrid. 3ºEdición. 1984.

Buckley, W. La Sociología y la Teoría Moderna de los Sistemas. Editorial

Amorrortu. Buenos Aires. 1973.

CASTELLANOS, Luis: Desarrollo de Sistemas de Información. Editorial

Académica Española. Alemania, 2012. 1ra edición.
Cachero, C. (2003). OO-H: Una extensión a los métodos OO para el
modelado y generación automática de interfaces hipermediales. Tesis
Doctoral, Universidad de Alicante, España.
Kappel, Pröll, Reich, & Retschitzegger, (2003). Web Engineering. Munich:
John Wiley & Sons Ltd.

IEEE: SWEBOK v3. 2014.

KENDALL, Kenneth & KENDALL, Julie: Análisis y Diseño de Sistemas. Ed

Pearson. México, 2011. 8va Edición.

Wiener, N. Cibernética y Sociedad. Editorial Sudamericana.Buenos Aires.

1979.
Chiavenato Idalberto. (1999). Introducción a la Teoría General de la
Administración. (5ta. ed). Editorial Mc. Graw Hill .