Desarrollo de Software Con Ingeniería Web - LIBRO

                                                                                                                                                                                                           

                      

   

                                                                    



         

        

         

   

         

     

                                                                                            

                                                                                                                                                                                                         

           

               

Docente del Tecnológico Nacional de México campus Tecnológico de Ciudad Valles

La ingeniería web es la aplicación de metodologías sistemáticas, disciplinadas y cuantificables al desarrollo eficiente, operación y evolución de aplicaciones de alta calidad en la World Wide Web. La ingeniería web se debe al crecimiento desenfrenado que está teniendo la Web está ocasionando un impacto en la sociedad y el nuevo manejo que se le está dando a la información en las diferentes áreas en que se presenta ha hecho que las personas tiendan a realizar todas sus actividades por esta vía. Desde que esto empezó a suceder el Internet se volvió más que una diversión y empezó a ser tomado más 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áticos y metodologías donde tuvieron en cuenta aspectos específicos de este nuevo medio.

     





1

INTRODUCCIÓN............................................................................................. 1

2

Fases de desarrollo de la Ingeniería Web ...................................................... 4 2.1 Fase 1: Introducción a la Ingeniería Web (IWeb) ...................................... 4 2.2 Fase 2: Formulación y Planeación de la Ingeniería Web ......................... 4 2.3 Fase 3: Modelado del Análisis de Ingeniería Web .................................... 4 2.4 Fase 4: Modelado del Diseño de aplicaciones Web ................................. 5 2.5 Fase 5: Pruebas para IWeb ....................................................................... 6

3

Objetivo(s) General(es) de la Ingeniería de Software Web ........................... 7 3.1 Competencias Previas para desarrollar software con ingeniería web...... 7 3.2 Competencias específicas a desarrollar por fase de Ingeniería web ....... 8

GUÍA TÉCNICA DE LA FASE 1 .......................................................................... 10 4

Fase 1. Introducción a la Ingeniería Web ..................................................... 11 4.1 Ingeniería Web ......................................................................................... 11 4.2 Atributos de los sistemas y aplicaciones Web ........................................ 13 4.3 Estratos de la ingeniería Web .................................................................. 16 4.4 El proceso de ingeniería Web .................................................................. 18 4.5 Mejores prácticas en la Ingeniería Web. ................................................. 21

5

Práctica No. 1 ................................................................................................ 23 5.1 Nombre de la práctica: Fase 1 Plan de Negocios para Proyecto IWeb 23


Fase 2. Formulación y Planeación de la Ingeniería Web ............................. 26

ING. ROSA IMELDA GARCIA CHI, MTI

i

     



6.1 Formulación de sistemas basados en Web ............................................ 26 6.2 Planeación de proyectos de Ingeniería Web........................................... 28 6.3 El Equipo de ingeniería Web ................................................................... 28 6.4 Conflictos de gestión de proyecto para ingeniería Web ......................... 29 6.5 Mediación para ingeniería Web y WebApps ........................................... 31 7

Práctica No. 2 ................................................................................................ 32 7.1 Nombre de la práctica: Fase 2 Formulación y Planificación IWeb ....... 32


Fase 3. Modelado del Análisis de Ingeniería Web. ...................................... 37 8.1 Requisitos para el análisis de las WebApp ............................................. 37 8.2 El modelado de análisis para WebApps .................................................. 39 8.3 El modelo de contenido............................................................................ 40 8.4 El modelo de interacción .......................................................................... 40 8.5 El modelo funcional .................................................................................. 42 8.6 El modelo de configuración ...................................................................... 43 8.7 Análisis relación  navegación (ARN) ..................................................... 43

9

Práctica No. 3 ................................................................................................ 45 9.1 Nombre de la práctica: Fase 3 Modelado del Análisis de IWeb ........... 45


Fase 4. Modelado del Diseño de Aplicaciones Web.................................. 51

10.1

Temas de diseño para ingeniería Web ................................................. 51

10.2

Pirámide del diseño IWEB .................................................................... 52


ii

     



10.3

Diseño de la interfaz de la WebApp .  53

10.4

Diseño estético .  60

10.5

Diseño de contenido.  60

10.6

Diseño arquitectónico .  60

10.7

Diseño de navegación .  61

10.8

Método de diseño hipermedia orientado a objetos (MDHOO) .  63

11

Práctica No. 4 .  68

11.1

Nombre de la práctica: Fase 4: Modelado del Diseño de IWeb .  68

GUÍA TÉCNICA DE LA FASE 5 .  72 12

Fase 5. Pruebas para IWeb .  73

12.1

Pruebas de conceptos para WebApp .  73

12.2

Las pruebas que se aplican a una aplicación web .  75

13

Práctica No. 5 .  79

13.1

Nombre de la práctica: Fase 5 Aplicación de Pruebas IWeb .  79

FORMATO FASES DE PROYECTO IWEB .  82 14

Anexo No. 1. Formato Fase 1 Proyecto IWeb. .  83

15


16


17


18


19

Bibliografía.  98


iii

     



1 INTRODUCCIÓN La Guía Técnica de Ingeniería de Software Web (IWeb) integra un conjunto de prácticas que van guiando el desarrollo y la creación de una aplicación web. En el primer apartado, se inicia con prácticas relacionadas con los estratos: procesos, métodos, herramientas/tecnología.

El Proceso IWeb adopta el

            

riguroso, que conduce a la entrega incremental del sistema que será construido. En este punto se desarrolla la primera fase del proyecto IWeb, que corresponde a la propuesta. En el segundo apartado, denominada Formulación y Planeación de IWeb, integra la actividad de comunicación con el cliente, define las necesidades del negocio, las metas y objetivos del proyecto, las categorías de usuario final, las funciones y características principales y el grado de interoperabilidad con otras aplicaciones. Se desarrolla la segunda fase del proyecto IWeb. En el tercer apartado, se integran prácticas que describen el Modelado de Análisis de la IWeb, cuyo propósito es describir la motivación básica (metas) y objetivos de una WebApps, definir las categorías de usuarios y señalar los requisitos de contenido y de función de la WebApps para establecer una comprensión básica de porqué se construirá la WebApps, quién la usará y qué problemas les resolverá a los usuarios, generando la fase tres del proyecto, denominado Modelado del Análisis IWeb.

ING. ROSA IMELDA GARCIA CHI,MTI

1

     



En el apartado cuarto, se aborda el Modelado del diseño de la IWeb, que define la calidad en términos de facilidad de uso, funcionalidad, confiabilidad, eficiencia, facilidad de mantenimiento, seguridad, escalabilidad y tiempo en el mercado. El diseño de la interfaz describe la estructura y organización de la interfaz del usuario. Incluye una representación de la plantilla de pantalla, una definición de los modos de interacción y una descripción de los mecanismos de navegación. Aquí también se incluye el diseño gráfico, referente a la apariencia y la percepción de la Web Apps e incluye esquemas de color, plantilla geométrica, tamaño de texto, fuente y ubicación, el uso de gráficos y decisiones estéticas relacionadas. En esta unidad se describen las métricas de diseño para la ingeniería Web. En este punto, se solicita la generación de la fase cuatro del proyecto, el Modelado de Diseño de IWeb. Y por último apartado, se revisan los temas referentes a las Pruebas de IWeb. La meta de probar las Web Apps es ejercitar cada una de las muchas dimensiones de la calidad con la finalidad de encontrar errores o descubrir conflictos que pudieran conducir a fallas en la calidad. Las pruebas se centran en contenido, función, estructura, facilidad de uso, navegabilidad, desempeño, compatibilidad, interoperabilidad, capacidad y seguridad. Las pruebas también incorporan revisiones que ocurren conforme se diseña la Web App. Se propone en esta unidad probar el producto obtenido de aplicar el modelado de Ingeniería Web en cada una de sus fases. Se solicita evidencia de la aplicación de las pruebas.


2

     



La presente Guía Técnica, tiene como objetivo la integración de los diferentes elementos, criterios y métodos, e incluye la información básica para resolver un conjunto de prácticas de la Ingeniería de Software W eb de la Carrera de Ingeniería en Sistemas Computacionales, que proporcione al alumno la habilidad y destreza para conocer, comprender y aplicar con profundidad las tecnologías y metodologías presentes en el entorno profesional para el desarrollo de aplicaciones Web, diseñar y dirigir soluciones de calidad basadas en aplicaciones Web, así como analizar y evaluar aplicaciones Web vigentes en el marco legal, social y económico. La Guía presenta una serie de prácticas o fases de proyecto que cubre cada una de las competencias que debe integrar un ingeniero de desarrollo de software web. Las prácticas son sólo una sugerencia didáctica para que el docente guie al alumno a aplicar los conocimientos adquiridos en cada una de las unidades. Se incorporan formatos para elaborar las fases del proyecto IWeb, para que el practicante o desarrollador integre al final un documento integrador, donde muestre la aplicación y resultado de cada una de las prácticas o f ases.


3

     

2 Fases de desarrollo de la Ingeniería Web 2.1 Fase 1: Introducción a la Ingeniería Web (IWeb) Temas

1.1 1.2 1.3 1.3.1 1.3.2

Atributos de los sistemas y aplicaciones basados en Web Estratos de la ingeniería de WebApps El proceso de ingeniería Web Definición del marco de trabajo Refinamiento del marco de trabajo

2.2 Fase 2: Formulación y Planeación de la Ingeniería Web Temas

2.1 Formulación de sistemas basados en Web 2.1.1. Preguntas de formulario 2.1.2. Recopilación de requisitos para WebApps 2.1.3. El puente hacia el modelado de análisis 2.2 .Planeación de proyectos de ingeniería Web 2.3. El equipo de ingeniería Web 2.3.1. Los actores 2.3.2. Construcción del equipo 2.4. Conflictos de gestión de proyecto para ingeniería Web 2.4.1 Planeación de WebApps: subcontratación 2.4.2 Planeación de WebApps: ingeniería Web en casa 2.5 Medición para ingeniería Web y WebApps 2.5.1 Mediciones para esfuerzo de ingeniería Web 2.5.2 Medición del valor de negocios

2.3 Fase 3: Modelado del Análisis de Ingeniería Web Temas

3.1 Requisitos para el análisis de las WebApps 3.1.1 La jerarquía del usuario 3.1.2 Desarrollo de casos de uso 3.1.3 Afinación del modelo de caso de uso 3.2 El modelado de análisis para WebApps 3.3 El modelado de contenido 3.3.1 Definición de objetos de contenido 3.3.2 Relaciones y jerarquía de contenido 3.3.3 Clases de análisis para WebApps 3.4 El modelo de interacción 3.5 El modelo funcional 3.6 El modelo de configuración 3.7 Análisis relación-navegación 3.7.1 Análisis de relaciones 3.7.2 Análisis de navegación


4



      2.4 Fase 4: Modelado del Diseño de aplicaciones Web Temas

4.1 Temas del diseño para ingeniería web 4.1.1 Diseño y calidad de una WebApps 4.1.2 Metas de diseño 4.2 Pirámide del diseño IWeb 4.3 Diseño de la interfaz de la WebApps 4.3.1 Principios y directrices del diseño de interfaz 4.3.2 Mecanismos del control de la interfaz 4.3.3 Flujo de trabajo en el diseño de la interfaz 4.4 Diseño estético 4.4.1 Cuestiones de plantilla 4.4.2 Cuestiones de diseño gráfico 4..5 Diseño de contenido 4.5.1 Objetos de contenido 4.5.2 Cuestiones de diseño de contenido 4.6 Diseño arquitectónico 4.6.1 Arquitectura de contenido 4.6.2 Arquitectura WebApps 4.7 Diseño de navegación 4.7.1 Semántica de navegación 4.7.2 Sintaxis de navegación 4.8 Diseño al nivel de componentes 4.9 Patrones de diseño hipermedia 4.10 Método de diseño hipermedia orientado a objetos(MDHOO) 4.10.1 Diseño conceptual MDHOO 4.10.2 Diseño de navegación mediante el MDHOO 4.10.3 Diseño abstracto de la interfaz e implementación 4.11 Métricas de diseño para WebApps


5



      2.5 Fase 5: Pruebas para IWeb Temas

5.1 Prueba de conceptos para WebApps 5.1.1. Dimensiones de calidad 5.1.2. Errores dentro de un ambiente WebApps 5.1.3. Estrategias de pruebas 5.1.4. Planeación de las pruebas 5.2. El Proceso de prueba 5.3. Prueba de contenido 5.3.1. Objetivos de la prueba de contenido 5.3.2. Prueba de la base de datos 5.4. Prueba de la interfaz del usuario 5.4.1. Estrategia de pruebas de la interfaz 5.4.2. Prueba de mecanismos de la interfaz 5.4.3. Prueba de la semántica de la interfaz 5.4.4. Prueba de la Facilidad de uso 5.4.5. Pruebas de compatibilidad 5.5. Prueba al nivel de componentes 5.6. Pruebas de navegación 5.6.1. Prueba de la sintaxis de navegación 5.6.2. Prueba de la semántica de la navegación 5.7. Prueba de la configuración 5.7.1. Conflictos en el lado del servidor 5.7.2. Conflictos en el lado del cliente 5.8. Pruebas de seguridad 5.9. Pruebas del desempeño 5.9.1. Objetivos de las pruebas de desempeño 5.9.2. Pruebas de carga 5.9.3. Pruebas de tensión


6



     



3 Objetivo(s) General(es) de la Ingeniería de Software Web Proporcionar al alumno una visión global y actualizada de los principales



campos relacionados con la Ingeniería Web, así como las principales líneas de investigación relacionadas con dicha disciplina. 

Conocer, comprender y aplicar con profundidad las tecnologías y metodologías presentes en el entorno profesional para el desarrollo de aplicaciones Web. Diseñar y dirigir soluciones de calidad basadas en aplicaciones Web en el



entorno profesional. Analizar y evaluar aplicaciones Web vigentes en el entorno profesional bajo



el marco legal, social y económico 3.1 Competencias Previas para desarrollar software con ingeniería web

Aplica modelos, técnicas y herramientas para cada una de las etapas del



ciclo de vida de desarrollo de software tradicional y orientado a objetos 

Conoce Sistemas Avanzados de Bases de Datos



Utiliza algún lenguaje de modelado (UML)



Conoce de programación web avanzada



Identifica diferentes Arquitecturas Tecnológicas



Programación.



Sistemas Operativos.



Sistemas Distribuidos.



Ingeniería del Software.



Ingeniería de Computadores.



Sistemas de Información.



Tecnologías de la Información.


7

      

Gestión de Tecnologías de la Información



Administración y Gestión de Empresa.



Sistemas orientados a Servicios.



3.2 Competencias específicas a desarrollar por fase de Ingeniería web 3.2.1.1 Competencia Específica de la fase 1 

Desarrollar la habilidad para identificar los atributos que existen en la mayoría de las WebApps; Así como los estratos de la ingeniería de WebApps y el proceso de la Ingeniería Web.

3.2.1.2 Competencia Específica de la fase 2 

Desarrollar la habilidad para la formulación de sistemas y aplicaciones basados en Web; Así mismo visualizar la planeación de proyectos de ingeniería Web contemplando el equipo de ingeniería Web, los conflictos de gestión de proyectos y la medición para ingeniería Web y WebApps.


Desarrollar la habilidad para la formulación, recopilación de requisitos y el modelado de análisis describiendo la motivación básica (metas) y objetivos para la WebApps, definir la categoría de usuarios, señalar los requisitos de contenido y de función para la WebApps, establecer una comprensión básica de por qué se construirá la WebApps quien la usará y que problema(s) les resolverá a los usuarios.


8

     




Desarrollar la habilidad para aplicar la calidad de una WebApps en términos de facilidad de uso, funcionalidad, confiabilidad, eficiencia, facilidad de mantenimiento, seguridad y escalabilidad y tiempo en el mercado logrando un buen diseño con simplicidad, consistencia, identidad, robustez, navegabilidad y apariencia visual.


Desarrollar la habilidad de descubrir errores en el contenido, la función, la facilidad de uso, la navegabilidad, el desempeño, la capacidad y la seguridad de la WebApps mediante la aplicación de una estrategia de prueba que abarca tanto revisiones como pruebas ejecutables en todo el proceso de ingeniería Web.


9

     

    

Introducción a la Ingeniería web


10

 



     



4 Fase 1. Introducción a la Ingeniería Web 4.1 Ingeniería Web

La World Wide Web y la Internet que la alimentan son, posiblemente los desarrollos más importantes en la historia de la computación. Estas tecnologías han llevado a todos a la era de la informática; además se han convertido en parte integral de la vida diaria en los últimos días.

Figura 1 Modelo de Ingeniería Web. Fuente: (PRESSMAN, 2006)


11

     



4.1.1 ¿Qué es? Los sistemas y aplicaciones basadas en Web ofrecen un completo arreglo de contenido y funcionan a una amplia población de usuarios finales. La ingeniería Web es el proceso con el que se crean las WebApps de alta calidad. La Ingeniería Web no es un clon perfecto de la ingeniería de software, pero utiliza muchos conceptos y principios fundamentales de ella. 4.1.2 ¿Quién lo hace? Los ingenieros Web y los desarrolladores de los contenidos que no son técnicos crean las WebApps. 4.1.3 ¿Por qué es importante? Conforme las WebApps se integran cada vez más en las estrategias de negocios para pequeños y grandes empresas (ejemplo el comercio electrónico), crese en importancia la necesidad de construir sistemas confiables, prácticos y adaptables. 4.1.4 ¿Cuáles son los pasos? Como cualquier otra disciplina de ingeniería, la Ingeniería Web aplica un enfoque genérico que se suaviza mediante estrategias, técnicas y métodos especializados. El proceso IWeb comienza con una formulación del problema que se resolverá con la WebApps. El sistema se construye con tecnologías y herramientas especializadas asociadas con la Web. 4.1.5 ¿Cuál es el producto obtenido? Se producen muchos productos de trabajo IWeb. El resultado final es l a WebApps operativa.


12

     



4.2 Atributos de los sistemas y aplicaciones Web

4.2.1 ¿Qué es la usabilidad? Técnicas que ayudan a los seres humanos a realizar tareas en entornos gráficos de ordenador. Tres conceptos muy importantes. Se trabaja para seres humanos, que quieren realizar una tarea de una forma sencilla y eficaz y en este caso particular, la deben realizar frente a un ordenador en un entorno gráfico, la Web. La usabilidad ayuda a que esta tarea se realice de una forma sencilla analizando el comportamiento humano, y los pasos necesarios para ejecutar la tarea de una forma eficaz. Quizás suene un poco a trabajo industrial, pero al hacer referencia al término   hace referencia a buscar un programa que se quiere ver en la tele, a ver información sobre un equipo de fútbol favorito, a comprar un libro sobre artes marciales. 4.2.2 ¿Realmente hace falta la usabilidad para hacer una Web? Sea tu Web un portal o una página personal, no olvides que la gente que entra en tu Web es porque básicamente busca algo. Hacerlo sencillo es decisión tuya, pero seguro que entre todos podemos hacer de Internet un sitio mejor donde la gente no se sienta perdida o extraviada o sencillamente defraudada. 4.2.3 ¿Cuáles son las 8 reglas de Oro sobre la usabilidad? Quizás mañana sean 10 reglas. 1. En Internet el usuario es el que manda. Esto quiere decir que sin usuarios tu página muere, así que más vale que los cuides y les des lo que te piden, de lo contrario te quedaras solo. ING. ROSA IMELDA GARCIA CHI,MTI

13

     



2. En Internet la calidad se basa en la rapidez y la fiabilidad. En Internet cuenta que tu página sea más rápida que bonita, fiable que moderna, sencilla que compleja, directa. 3. Seguridad. Si en el mundo real a veces nos cuesta fiarnos del banco de la esquina, imagínate cómo se siente la gente en Internet cuando llega a tu site. Procura que todo funcione como un reloj para que la gente pueda fiarse de tu site. 4. La confianza es algo que cuesta mucho ganar y se pierde con un mal enlace. Esto quiere decir que tal y como está la competencia en Internet, no puedes perder ni un solo visitante por tener un enlace mal hecho. Es mejor salir con algo               qué es lo que              

y genere confianza. Poco a poco y con el feedback de los usuarios, podrás ir complicando la página. Pero asegura antes de arriesgar. 5. Si quieres hacer una página decente, simplifica, reduce, optimiza. La gente no se va a aprender tu site por mucho que insistas, así que por lo menos hazlo sencillo, reutiliza todos los elementos que puedas, para que de este modo los usuarios se sientan cómodos y no se pierdan cada vez que necesiten encontrar algo en tu site.


14

     



6. Pon las conclusiones al principio. El usuario se sentirá más cómodo si ve las metas al principio. De esta forma no tendrá que buscar lo que necesita y perderá menos tiempo en completar su tarea. Si completa su tarea en menos tiempo se sentirá cómodo y quizás se dedique a explorar tú site o quizás se lo recomiende a un amigo. 7. No hagas perder el tiempo a la gente con cosas que no necesitan. Cuidado con cruzar promociones, si lo haces por lo menos hazlo con cuidado. Procurar que la selección de productos a cruzar sea consecuente y no lo quieras     

páginas. Según avance el usuario en su navegación

procura dejarle más espacio libre. Puede ocurrir que cuando este punto de comprar algo vea una oferta que le distraiga y pierdas esa venta. 8. Buenos contenidos. Escribir bien para Internet es todo un arte. Pero siguiendo las reglas básicas de (1) poner las conclusiones al principio, (2) escribir como un 25% de lo que pondrías en un papel, se puede llegar muy lejos. (3) Leer en pantalla cuesta mucho, por lo que, en el caso de textos para Internet, reduce y simplifica todo lo que puedas. 9. Evaluación del contenido. A diferencia del software de aplicación que evoluciona continuamente, las aplicaciones Web involucran una de manera continua. Un seguimiento continuo y detallado de la información implícita en la aplicación Web. Todo esto hace que la aplicación Web sirva al usuario fina. ING. ROSA IMELDA GARCIA CHI,MTI

15

     



4.3 Estratos de la ingeniería Web

El desarrollo de aplicaciones Web incorpora métodos de proceso especializados, métodos de ingeniería de software adaptados a características de desarrollo de las aplicaciones Web y un conjunto de importantes tecnologías que permitan un correcto desarrollo de las mismas. Los procesos, métodos y tecnologías (herramientas) proporcionan un enfoque en estratos de la IWeb que es conceptualmente idéntico a los estratos de la ingeniería de software. 4.3.1 Proceso Los modelos de procesos Web adoptan la filosofía de desarrollo ágil. El desarrollo ágil enfatiza un enfoque de desarrollo riguroso que incorpora rápidos ciclos de desarrollo. Es importante reconocer que el problema todavía debe analizarse, debe desarrollarse un diseño, la implementación debe preceder en una forma incremental y se debe iniciar un enfoque organizado de prueba. Dichas actividades de marco de trabajo se deben definir dentro de un proceso que: 

Adopte el cambio: Aliente la creatividad y la independencia del equipo de desarrollo y fortalezca la interacción con el usuario.





Construya sistemas que utilicen pequeños equipos de desarrollo. Subraye el desarrollo evolutivo o incremental mediante el uso de cortos ciclos de desarrollo.


16

     



4.3.2 Métodos Los métodos de la IWeb abarcan un conjunto de labores técnicas que permiten al ingeniero Web comprender, caracterizar y luego construir una aplicación Web de alta calidad. Los métodos de la IWeb se puedes categorizar de la siguiente manera: 4.3.2.1 Métodos de comunicación:

Métodos de comunicación: Definen el enfoque con que se facilita la comunicación entre: cliente y desarrollador. Las técnicas de comunicación son importantes durante la recolección de requisitos. 4.3.2.2 Métodos de análisis de requisitos:

Proporcionan una base para comprender el contenido que se entregará a las WebApps, la función que proporcionará al usuario final y los modos de interacción de cada clase de usuario requerirá mientras ocurra la navegación por medio de las WebApps 4.3.2.3 Métodos de diseño:

Abarcan una serie de técnicas de diseño que abordan el contenido, la aplicación y la arquitectura de información, así como el diseño de interface y la estructura de navegación de las WebApps. 4.3.2.4 Método de prueba:

Incorporan revisiones técnicas formales tanto de contenido y el modelo de diseño como de una amplia variedad de técnicas de pruebas que abordan conflictos al nivel de componentes. ING. ROSA IMELDA GARCIA CHI,MTI

17

     



Pruebas de la navegación, pruebas de facilidad de uso, pruebas de seguridad y pruebas de configuración. 4.3.3 Herramientas y tecnologías Las tecnologías abarcan un amplio conjunto de descripción de contenido y lenguaje de modelación por ejemplo: HTML, VRML, XML, etc. lenguajes de programación por ejemplo java, php, jsp, etc. recursos de desarrollo basados en componentes por ejemplo corba, com, activeX, .net, etc. navegadores, herramientas multimedia, herramientas de auditoria de sitio, herramientas de conectividad de base de datos, herramientas de seguridad, servidores y utilidades de servidor, y herramientas de administración y análisis de sitio. 4.4 El proceso de ingeniería Web

En un proceso tan rápido como es el proceso de Ingeniería Web, donde los tiempos de desarrollo y los ciclos de vida de los productos son tan cortos, ¿merece la pena el esfuerzo requerido por la gestión? La respuesta es que dada su complejidad es imprescindible. Entre los aspectos que añaden dificultad a la gestión destacamos: - alto porcentaje de contratación a terceros, - el desarrollo incluye una gran variedad de personal técnico y no técnico trabajando en paralelo, - el equipo de desarrollo debe dominar aspectos tan variopintos como, software basado en componentes, redes, diseño de arquitectura y navegación, diseño gráfico y de interfaces, lenguajes y estándares en Internet, test de aplicaciones Web, etc., lo que hace que el proceso de búsqueda y contratación de personal sea arduo.


18

     



4.4.1 Definir el marco de trabajo La efectividad de cualquier proceso de ingeniería depende de su adaptabilidad. Esto es, la organización del equipo de trabajo del proyecto, los modos de comunicación entre miembros del equipo, las actividades de ingeniería y las tareas que deben realizarse, la información que se recolecte y se cree, y los métodos empleados para producir un producto de alta calidad deben estar adaptados a la gente que realiza el trabajo, el plazo y las restricciones del proyecto, y al problema que se quiere resolver. Antes de definir un marco de trabajo de proceso para la IWeb se debe reconocer que: 

Las WebApps con frecuencia se entregan de manera incremental.



Los cambios ocurrirán frecuentemente.



Los plazos son cortos.

4.4.2 Comunicación con el cliente: La comunicación con el cliente se caracteriza por medio de dos grandes tareas: el análisis del negocio y la formulación. El análisis del negocio define el contexto empresarial-organizativo para las WebApps y otras aplicaciones de negocio. La formulación es una actividad de recopilación de requisitos que involucran a todos los participantes. 4.4.3 Planeación: Se crea el plan del proyecto para el incremento de la WebApp. El plan consiste de una definición de tareas y un calendario de plazos respecto al período establecido para el desarrollo del proyecto.


19

     



4.4.4 Modelado: Las labores convencionales de análisis diseño de la ingeniería del software se adaptan al desarrollo de las WebApp, se mezclan y luego se funden en una actividad de modelado de la IWeb. El intento es desarrollar análisis rápido y modelos de diseño que definan requisitos y al mismo tiempo representen una WebApp que los satisfará. 4.4.5 Construcción: Las herramientas y la tecnología IWeb se aplican para construir la WebApp que se ha modelado. Una vez que se construye el incremento de WebApp se dirige a una serie de pruebas rápidas para asegurar que se descubran los errores en el diseño. 4.4.6 Despliegue: Las WebApp se configura para su ambiente operativo, se entrega a los usuarios finales y luego comienza un período de evaluación. La retroalimentación acerca de la evaluación para realizar los procesos respectivos.


20

     



Figura 2 Fase de construcción de una aplicación Web. Fuente: (PRESSM AN, 2006)

4.4.7 Refinamiento del marco de trabajo La definición de tareas de ingeniería requerida para refinar cada actividad del marco de trabajo se dejan a discrecional del juicio del equipo de ingeniería Web. Es importante destacar que las tareas asociadas con la actividad del marco de trabajo IWeb pueden modificarse, eliminarse o extenderse con base en las características del problema, el producto, el proyecto y la gente en el equipo de ingeniería Web. 4.5 Mejores prácticas en la Ingeniería Web. 

Tomar tiempo para entender las necesidades del negocio y los objetivos del producto, incluso si los detalles de la WebApp son vagos.



Describir cómo interactuarán los usuarios con la WebApp aplicando un enfoque basado en escenarios.



Desarrollar un plan del proyecto, incluso si es muy breve


21

     





Utilizar algún tiempo para modelar lo que se construirá.



Revisar la consistencia y calidad de los modelos.



Utilizar herramientas y tecnología que permitan construir el sistema con tantos componentes reutilizables.



No apoyarse en usuarios anteriores para depurar la WebApp


22

     

5 Práctica No. 1 5.1 Nombre de la práctica: Fase 1 Plan de Negocios para Proyecto IWeb

Definir el Plan de Negocios como propuesta

5.1.1 Objetivo

de desarrollo de un Proyecto de Ingeniería Web. Los puntos a considerar en un Plan de

5.1.2 Introducción

Negocios son: 1. Resumen ejecutivo 2. Descripción del producto y valor distintivo 3. Mercado potencial 4. Competencia 5. Modelo de negocio y plan financiero 6. Equipo directivo y organización 7. Estado de desarrollo y plan de implantación 8. Alianzas estratégicas 9. Estrategia de marketing y ventas 10.Principales riesgos y estrategias de salida

5.1.3 Material Equipo

y



Computadora con Acceso a Internet



Dispositivo de almacenamiento



Plataforma Moodle del IT Valles



Procesador de Textos p.e. Word


23



      5.1.4 Metodología

1. Conformar equipo de trabajo con diversos roles 2. Descargar el formato para elaborar la fase 1 (Anexo No. 1). Se encuentra disponible en las plataformas como www.slideshare.net ,

www.issuu.com,

www.googledocs.com , www.scribd.com. 3. Resolver cada uno de los puntos propuestos en la fase del proyecto 4. Elaborarlo en formato digital 5. Subirlo a la Plataforma Virtual de Aprendizaje 5.1.5 Sugerencias

Puedes revisar diversos materiales referentes a la elaboración de Planes de Negocios. En Ingeniería de Software se aprendió sobre el Modelado de Negocios, el cuál puede ser aplicado en esta fase del proyecto. De la misma manera la materia de Administración

de

Proyectos

aporta

elementos para generar un Plan de Negocios bajo el esquema del PMBook, que se puede aplicar a la fase inicial del proyecto.


24



     

    



 

Formulación y Planeación de la Ingeniería Web


25

     



6 Fase 2. Formulación y Planeación de la Ingeniería Web 6.1 Formulación de sistemas basados en Web

La formulación se enfoca sobre el gran cuadro en las necesidades y objetivos del negocio y el la información relacionada. Los clientes y los ingenieros Web quieren definir el contenido requerido, discutir la funcionalidad específica, características específicas e identificar la forma en que los usuarios finales interactuarán con las WebApp, todo esto es formulación y recopilación de requisitos. 6.1.1 Preguntas de formulación: En esta etapa es bueno preguntarse y responderse lo siguiente: 

¿Cuál es la principal motivación para las WebApp?



¿Cuáles son los objetivos que deben satisfacer las WebApp?



¿Quién usará la WebApp?


26

     



Si tenemos una respuesta correcta a estas preguntas implican metas específicas para el sitio Web. En general se identificas dos categorías de metas: Metas informativas: indican una intención de proporcionar contenido información específicos al usuario final. Metas aplicables: indican la habilidad para realizar alguna tarea dentro de la WebApp. 6.1.2 Recopilación de requisitos para WebApps Los objetivos globales de la recopilación de requisitos propuestos para la ingeniería de software permanecen inalterados. Adaptados para las WebApp, dichos objetivos se convierten en: 

Identificar requisitos de contenido.



Identificar requisitos funcionales.



Definir escenarios de interacción para diferentes clases de usuarios.

Los siguientes pasos de la recopilación de requisitos se dirigen para lograr estos objetivos 1. Pedir a los clientes que definan una categoría de usuario y describan cada categoría. 2. Comunicarse con los clientes para definir los requisitos básicos para las WebApp. 3. Analizar la información recopilada y utilizar la información para realizar un seguimiento a los clientes. ING. ROSA IMELDA GARCIA CHI,MTI

27

     



4. Definir casos de uso que describan escenarios de interacción para cada clase de usuario. 6.1.3 El puente hacia el modelado de análisis Toda la información recolectada y tratada se modela con la utilización de casos de uso y notación UML. 6.2 Planeación de proyectos de Ingeniería Web

Dada la inmediatez de las WebApps es razonable preguntar: ¿en realidad se necesita gastar tiempo en la planeación y administración de un esfuerzo WebApp? ¿No solo se debería dejar involucrar naturalmente a las WebApp, con poco o ninguna gestión explicativa? 6.3 El Equipo de ingeniería Web

Un equipo de ingeniería Web exitoso mezcla una amplia variedad de talentos que deben trabajar como equipo en un ambiente de proyecto con alta presión. Los plazos son cortos, los cambios son inexorables y la tecnología continúa cambiando. La creación de un equipo que se consolide no es asunto sencillo. 

Los Actores



Desarrolladores/proveedores de contenido



Editores de Web



Ingeniero Web



Expertos en dominios empresariales



Especialista en Soporte



Administrador


28

     



6.3.1 Construcción del equipo Para la construcción del equipo tiene particular relevancia cuando una organización se forma un equipo de IWeb 

Se debe establecer un conjunto de directrices del equipo.



El liderazgo fuerte es una obligación



El respeto hacia los talentos individuales es crucial



Cada miembro del equipo se debe comprender



Es fácil comenzar, lo difícil es mantener el espíritu.

6.4 Conflictos de gestión de proyecto para ingeniería Web

Una vez realizada la formulación y que se han identificado los requisitos básicos de la WebApp, la empresa debe elegir una de dos opciones de ingeniería Web: 

La WebApp es subcontratada: la ingeniería Web la realiza un tercer proveedor con experiencia, talento y recursos con los cuales no cuenta la empresa.



Las WebApp la desarrollan en casa ingenieros Web que sean empleados de la empresa.

6.4.1 Planeación de WebApp: subcontratación En este caso un negocio (el cliente) pide un precio fijo para desarrollar la WebApp de uno o más proveedores, evalúa los precios competitivos y luego elige un proveedor para efectuar el trabajo. Pero ¿Qué busca la organización contratante? ¿Cómo se determina la competencia de un proveedor de WebApp? ¿Cómo se sabe si una cotización es razonable?


29

     



¿Qué grado de planeación, programa de trabajo y valoración de riesgos se pueden esperar conforme una organización se embarca en un esfuerzo por desarrollar una gran WebApp? Estas preguntas no siempre son fáciles de contestar, pero vale la pena considerar algunos lineamientos. 6.4.1.1 Selección de los subcontratistas candidatos:

Con la finalidad de elegir desarrolladores Web candidatos, el contratante debe realizar algunas tareas obligadas: 

Entrevistar a los clientes antiguos para determinar el profesionalismo del vendedor Web, así como su habilidad para cumplir con compromiso de plazos y costos y su destreza para comunicarse efectivamente.



Determinar el nombre de ingeniero(s) Web jefe de la empresa subcontratista para buscar proyectos anteriores exitosos.



Examinar cuidadosamente ejemplos de trabajo del subcontratista que sean similares en apariencia y sentido a la WebApp que será contratada.

6.4.2 Planeación de WebApp: Ingeniería Web en casa Los pasos siguientes se recomiendan para proyectos IWeb pequeños y de tamaño moderado. 

Entender el ámbito, las dimensiones del cambio y las restricciones del proyecto.



Definir una estrategia del proyecto incremental



Realizar análisis de riesgo



Desarrollar una estimación rápida


30

      

Elegir un conjunto de tareas



Establecer un programa



Definir mecanismos de rastreo del proyect proyecto o



Establecer un enfoque de gestión de cambios



6.5 Mediación para ingeniería Web y WebApps

La mediación del software ofrece una base para mejorar el proceso de software, lo que aumenta la precisión de las estimaciones del proyecto, incrementa el rastreo del proyecto y mejora la calidad del software. Las mediciones tienen tres metas principales: 

Proporcionar un indicador indicador de calidad de las WebApp desde el punto de vista técnico.



Proporcionar una base para la estimación del esfuerzo esfuerzo



Proporcionar una indicación indicación del éxito de la WebApp desde desde el punto de vista empresarial.


31

     

7 Práctica No. 2 7.1 Nombre de la práctica: Fase 2 Formulación y Planificación IWeb

7.1.1 Objetivo

Elaborar la Formulación y Planificación de un Proyecto de Ingeniería Web


32



      7.1.2 Introducción

La ingeniería web formula procesos bajo la necesidad subyacente de la aplicación web, las características y las funciones deseadas por los usuarios, y el alcance del esfuerzo de desarrollo. IWeb planifica las directrices de las cosas que deben ser definidos para establecer un plan de trabajo, considerar los riesgos, definir un programa, y establecer mecanismos para el seguimiento del trabajo de cómo avanza la investigación. Desde IWeb hay un proceso ágil de los productos de trabajo, para la formulación y la planificación deben cohesionarse, pero los documentos deben ser escritos. La

Formulación

y

planificación

de

la

información debe ser revisada con las partes interesadas para asegurarse de que las inconsistencias y omisiones se identifiquen a tiempo.


33



      7.1.3 Material Equipo

7.1.4 Metodología

y












Microsoft Visio o Concept Draw o DIA

1. Conformar equipo de trabajo con diversos roles 2. Descargar el formato para elaborar la fase 2 (Anexo No. 2). Se encuentra disponible en las plataformas como www.slideshare.net ,

www.issuu.com,

www.googledocs.com , www.scribd.com. 3. Resolver cada uno de los puntos propuestos en la fase del proyecto 4. Elaborarlo en formato digital 5. Subirlo a la Plataforma Virtual de Aprendizaje


34



      7.1.5 Sugerencias

Para

elaborar

la

Formulación

y

la

Planificación de un proyecto de Ingeniería Web es necesario conocer y dominar aspectos del Lenguaje Unificado de Modelado (UML) específicamente los diagramas de casos de uso, los diagramas de clase. Se sugiere el uso de herramientas de desarrollo de software como diagramadores o herramientas CASE. Algunas de estas herramientas son: Microsoft Visio, Concept Draw o DIA.


35



     

    



 

Modelado del Análisis de Ingeniería Web


36

     

8 Fase 3. Modelado del Análisis de Ingeniería Web. 8.1 Requisitos para el análisis de las WebApp

El análisis de requisitos para las WebApp abarca tres grandes tareas: 

Formulación



Recopilación de requisitos



Modelado de análisis


37



     



8.1.1 La jerarquía de usuario Las categorías de los usuarios finales se identifican como parte de las tareas de formulación y de recopilación de requisitos. Las categorías de usuarios son relativamente limitados y no necesitan una representación UML. Sin embargo, cuando crece el número de categorías de usuario, a veces es aconsejable desarrollar una jerarquía de usuarios. 8.1.2 Desarrollo de casos de uso Los casos de uso se desarrollan para cada categoría de usuario descrita en la jerarquía de usuario. En el contexto de la ingeniería Web, el caso de uso en sí mismo es relativamente informal: un párrafo narrativo que describe una interacción especifica entre el usuario y la W ebApp. 8.1.3 Afinación del modelo de caso de uso A la par que se crean los diagramas de casos de uso para cada categoría de usuario, se desarrolla una vista superior de los requisitos de la WebApp observables de manera externa. Cada paquete se valora para garantizar que es: 

Comprensible.



Cohesivo



Libremente acoplados



Jerárquicamente superficial.


38

     



Puesto que el análisis y modelado de actividades son actividades iterativas. 8.2 El modelado de análisis para WebApps

Se basa en la información que contienen los casos de uso desarrollados para l aplicación. Se identifican el contenido que presentará la WebApp y se extraen las funciones que se desarrollarán a partir de las descripciones de caso de uso. Finalmente los requisitos específicos de la implementación se deben desarrollar de modo que el ambiente y la infraestructura que apoyan la WebApps puedan construirse.

Cuatro actividades de análisis, cada una con su aporte a la creación de un modelo de análisis completo son: 

Análisis de contenido



Análisis de interacción



Análisis de funciones



Análisis de configuración

El modelo es si mismo contiene elementos estructurales y dinámicos. Los elementos estructurales identifican las clases de análisis y los objetivos de contenido que se requieren para crear una WebApp que satisfaga las necesidades del cliente. Los elementos dinámicos del modelo de análisis describen como interactúan los elementos estructurales, entre ellos y con los usuarios finales.


39

     



8.3 El modelo de contenido

El modelo de contenido contiene elementos estructurales que proporcionan una importante visión de los requisitos de contenido para una WebApp. Además incluye todas las clases de análisis: entidades visibles para el usuario que se crean o manipulan conforme éste interactúa con la W ebApp. Al igual que otros elementos del modelo de análisis, el modelo de contenido se deriva a partir de un examen cuidadoso de los casos de uso desarrollados para la WebApp. 8.3.1 Definición de objetos de contenido Un objeto de contenido puede ser una descripción textual de un producto, un artículo que describa un evento noticioso. Los objetos de contenido se extraen en los casos de uso al examinar la descripción del escenario para referencias directas e indirectas al contenido. 8.3.2 Relaciones de jerarquía de contenido El modelo de contenido puede contener diagramas de relación de entidades o árboles de datos que bosquejan las relaciones entre los objetos de contenido o la jerarquía de éste que mantiene una WebApp. 8.4 El modelo de interacción

Este modelo de interacción lo comprenden cuatro elementos: 

Casos de uso



Diagramas de secuencia



Diagramas de estado



Prototipo de interfaz de usuario


40

     



8.4.1 Casos de Uso Un caso de uso se modela para todos los procesos que la WebApp debe llevar a cabo. Los procesos se describen dentro del caso de uso por una descripción textual o una secuencia de pasos ejecutados. Los Diagramas de Actividad se pueden usar también para modelar escenarios gráficamente. Una vez que el comportamiento de la aplicación está captado de esta manera, los casos de uso se examinan y amplían para mostrar qué objetos se interrelacionan para que ocurra este comportamiento. 8.4.2 Diagrama de Secuencia Un diagrama de Secuencia muestra una interacción ordenada según la secuencia temporal de eventos. En particular, muestra los objetos participantes en la interacción y los mensajes que intercambian ordenados según su secuencia en el tiempo. El eje vertical representa el tiempo, y en el eje horizontal se colocan los objetos y actores participantes en la interacción, sin un orden prefijado. Cada objeto o actor tiene una línea vertical, y los mensajes se representan mediante flechas entre los distintos objetos. El tiempo fluye de arriba abajo. Se pueden colocar etiquetas (como restricciones de tiempo, descripciones de acciones, etc.) bien en el margen izquierdo o bien junto a las transiciones o activaciones a las que se refieren.


41

     



8.4.3 Diagramas de Estado El comportamiento en tiempo real de cada clase que tiene comportamiento dinámico y significativo, se modela usando un Diagrama de Estado. El diagrama de actividad puede ser usado también aquí, esta vez como una extensión del diagrama de estado, para mostrar los detalles de las acciones llevadas a cabo por los objetos en respuesta a eventos internos. El diagrama de actividad se puede usar también para representar gráficamente las acciones de métodos de clases. 8.4.4 Prototipo de interfaz de usuario Algunas propuestas se basan en obtener de la definición de requisitos prototipos que, sin tener la totalidad de la funcionalidad del sistema, permitan al usuario hacerse una idea de la estructura de la interfaz del sistema con el usuario. Esta técnica tiene el problema de que el usuario debe entender que lo que está viendo es un prototipo y no el sistema final. Puesto que las herramientas de desarrollo de la WebApp son abundantes y funcionalmente poderosas, es mejor crear prototipos de la interfaz mediante tales herramientas. 8.5 El modelo funcional

Este modelo funcional aborda dos elementos de procesamiento de la WebApp y cada uno representa un gráfico diferente de la abstracción de procedimiento: 

Funcionalidad observable respecto al usuario y que entrega al usuario final de WebApp.



Las operaciones dentro de las clases de análisis que implementan comportamientos asociados con la clase.


42

     



La funcionalidad observable para el usuario comprende cualesquiera funciones de procesamiento que éste indicia directamente. Por ejemplo, un sitio Web financiero puede implementar una variedad de funciones financieras. 8.6 El modelo de configuración

Las WebApps se deben diseñar e implementar de forma que se acomoden a una diversidad de ambientes, tanto del lado del servidor como del cliente. Se deben especificar el hardware del servidor y el ambiente del sistema operativo. Si las WebApp deben tener acceso a una gran base de datos o ínter operar con las aplicaciones corporativas existentes en el lado del servidor, se deben especificar las interfaces apropiadas, los protocolos de comunicación y la información. Las WebApp deben someterse a una amplia prueba de cada configuración de navegador que se especifique como parte del modelo de configuración. 8.7 Análisis relación  navegación (ARN)

El análisis relación-navegación proporciona una serie de pasos de análisis que luchan por identificar relaciones entre los elementos descubiertos como parte de la creación del modelo de análisis. El enfoque de ARN se organiza en cinco pasos: 

Análisis de los participantes



Análisis de los elementos



Análisis de relaciones



Análisis de navegación



Análisis de evaluación.


43

     



8.7.1 Análisis de relaciones: preguntas claves En este análisis se formulan una serie de preguntas que nos ayudará a comprender más la relación. 8.7.2 Análisis de navegación Uno de los aspectos más importantes en los sistemas de información en las WebApp es el de la navegación. La gran mayoría de las propuestas metodológicas para sistemas WebApp resaltan este aspecto ofreciendo modelos que permitan diseñarlo e implementarlo asegurando la calidad del resultado. Sin embargo, analizando dichos modelos y técnicas y viendo los resultados de diferentes estudios comparativos, se puede observar que este aspecto, en la mayoría de las propuestas, se trata solamente en las últimas fases del ciclo de vida, principalmente en diseño e implementación. Los mecanismos de navegación se definen como parte del diseño. En esta etapa, los desarrolladores deben considerar requisitos de navegación globales.


44

     

9 Práctica No. 3 9.1 Nombre de la práctica: Fase 3 Modelado del Análisis de IWeb

9.1.1 Objetivo

Elaborar la Fase 3 del Modelado de Análisis de la Ingeniería Web utilizando el Lenguaje de Modelado

Unificado

Herramientas de Software.


45

con

ayuda

de



      9.1.2 Introducción



El Análisis de aplicaciones web se centra en tres áreas: la información o contenido que se



presenta 

las funciones del usuario final a ejecutar



los comportamientos de aplicación web que se presenta en respuesta a acciones del usuario.

Los ingenieros de red, especialistas en contenido, y las partes interesadas desarrollan el modelo de análisis. Los análisis de modelos permiten que el equipo de ingeniería Web para crear una representación concreta de los requisitos de aplicación web. El Modelado de Análisis de una aplicación web se centra en cuatro aspectos fundamentales del problema: contenidos



interacción



función



configuración




46

     



El producto del trabajo de análisis de modelos IWeb es un conjunto de diagramas UML y un texto descriptivo que describe los resultados de los cuatro análisis realizados. Los Productos de trabajo de análisis son revisados para la corrección, integridad y consistencia. Condiciones que favorecen el análisis de modelos Grandes o complejos WebApp ser



construidos 

Gran número de interesados



Un gran número de ingenieros Web y otros colaboradores



Las metas y los objetivos de aplicación web afectará a la línea de negocios inferior



Éxito

aplicación

web

tendrá

gran

influencia en el éxito de la empresa Requisitos de tareas de análisis de aplicación web Formulación 

Identificar las metas y objetivos para la aplicación web


47

      



Definir las categorías de usuarios y crear la jerarquía de usuario

La recopilación de requisitos 

La comunicación entre el equipo Web y las partes interesadas intensifica

Contenido y requisitos funcionales se



enumeran Los escenarios de interacción (casos de uso) son desarrollados 9.1.3 Material Equipo

y














48

      9.1.4 Metodología

1. Conformar

equipo

de

trabajo



con

diversos roles 2. Descargar el formato para elaborar la fase 3 (Anexo No. 3). Se encuentra disponible en las plataformas como www.slideshare.net,

www.issuu.com,

www.googledocs.com , www.scribd.com. 3. Resolver cada uno de los puntos propuestos en la fase del proyecto 4. Elaborarlo en formato digital 5. Subirlo a la Plataforma Virtual de Aprendizaje 9.1.5 Sugerencias

Para esta fase de proyecto es importante haber cumplido y acreditado la fase 1 y fase 2 del proyecto. Para Modelar el Análisis se requiere de los diagramas de caso de uso y los diagramas de clase del UML generados en la fase 1 del proyecto. En esta fase también se requiere el uso de herramientas de elaboración de diagramas UML.


49

     

    



 

Modela del Diseño de Aplicaciones Web


50

     



10 Fase 4. Modelado del Diseño de Aplicaciones Web. 10.1 Temas de diseño para ingeniería Web

Cuando se aplica el diseño dentro del contexto de la ingeniería Web, se deben considerar cuestiones tanto genéricas como específicas. El diseño debe ser muy específico. 10.1.1

Diseño de calidad de una WebApp

En la práct                           

estudio de la calidad de productos y procesos de desarrollo para la Web es muy reciente y todavía no se dispone de métodos de evaluación ampliamente difundidos para este tipo de entorno. Por lo tanto, existe la gran necesidad de metodologías efectivas para la obtención de aplicaciones Web de calidad. Actualmente, hay dos vertientes de metodologías de desarrollo para la Web: la comunidad de Ingeniería de Software y la comunidad de Hipermedia. Estas metodologías carecen sin embargo de métricas que puedan ser aplicadas a los modelos intermedios (Ej. Modelo de Objetos, Modelo Navegacional) utilizados en el proceso de desarrollo orientado a la Web. Otras características de diseño de calidad Web son: 

Seguridad



Disponibilidad



Escalabilidad



Tiempo en el mercado


51

      10.1.2



Metas de diseño

Una de las metas de diseño de una WebApp es abarcar lo siguiente: 

Simplicidad



Consistencia



Identidad



Robustez



Navegabilidad





Apariencia visual Compatibilidad

10.2 Pirámide del diseño IWEB

El diseño conduce a un modelo que contiene una mezcla adecuada de estética, contenido y tecnología. En la figura 3 se muestra la pirámide de diseño de ingeniería Web.


52

     

Figura 3 Modelado del Diseño IWeb. Fuente: (PRESSMAN, 2006)

10.3 Diseño de la interfaz de la WebApp

Toda interfaz de usuario debe presentar las siguientes características: 

Fácil de usar



Fácil de aprender



Fácil de navegar



Intuitiva



Consistente



Eficiente





Libre de errores Funcional

Debe ofrecer al usuario final una experiencia satisfactoria y gratificante.


53



     



Los principios y directrices esenciales del diseño de una WebApp se pueden mencionar: 

Uso equitativo



Flexibilidad en el uso



Uso sencillo e intuitivo



Información perceptible



Tolerancia al error



Esfuerzo físico reducido



Tamaño y espacio para acercarse y usar

En un momento de nuestra vida, cualquiera de nosotros puede llegar a experimentar una transición física. Ya sea una minusvalía temporal, como un hueso roto, o una discapacidad permanente, nos veremos enfrentados al cambio. El simple proceso de envejecimiento nos lleva a ser dependientes de otros. El diseño universal nos permite transitar por esos cambios y seguir disfrutando de igualdad de oportunidades, autodeterminación y calidad de vida. 10.3.1

Pauta 3.4 de las W3C WCAG 1.0

Utilice unidades relativas en lugar de absolutas al especificar los valores en los atributos de los marcadores de lenguaje y en los valores de las propiedades de las hojas de estilo.


54

      10.3.2



Qué significa:

La maquetación, la presentación y los contenidos de texto de una página deben tener la posibilidad de adaptación a la interfaz utilizada por el usuario, sin superposiciones o perdida de informaciones en caso de redimensionamiento (ampliación o reducción de visualización y/o de los caracteres). em, %, ex, px Las unidades relativas em   -    

H1 { margin: 0.5em } % valor relativo al valor del elemento padre P { line-height: 140% } ex         

H1 { margin: 1ex } px pixeles, relacionados con los dispositivos visuales P { font-size: 14px }

10.3.3

Técnicas de diseño


55

      10.3.3.1



Diseño fijo

Diseño que utiliza dimensiones de tamaño absoluto: inches (in), centimetros (cm), milímetros (mm), puntos (pt), picas (pc). Su efecto es bloquear el tamaño de un elemento a un tamaño fijo. 10.3.3.2

Diseño líquido (o fluido)

Diseño que utiliza cómo unidad de medida el porcentaje (%). Su efecto es la adaptación de los elementos y su disposición aprovechando todo el ancho de pantalla que será calculada en base a la resolución del dispositivo utilizado. 10.3.3.3

Diseño elástico (o flexible)

Diseño que utiliza cómo unidad de medida em. Su efecto es adaptar el ancho de los elementos y su disposición en base al tamaño de texto configurado por el usuario. 10.3.3.4

Diseño hibrido

Diseño que utiliza unidades de medida absolutas, porcentaje y em. 10.3.4

¿El diseño (más) accesible?

10.3.4.1

Diseño fijo

A favor Los diseñadores disfrutan de un control absoluto en determinar tamaño y posicionamiento de los elementos. Favorece la legibilidad. En contra No adapto en pantalla: no se conoce a priori las características del monitor             ING. ROSA IMELDA GARCIA CHI,MTI

56

      10.3.4.2



Diseño liquido

A favor Presentación de más informaciones en pantalla y reducción del efecto scroll. Adaptación al medio. En contra Causa líneas de texto muy largas en caso de resoluciones de pantalla muy altas: dificultad en la lectura. 10.3.4.3

Diseño elástico

A favor           

sobre posición de elementos. En contra Al aumentar el tamaño del texto, en determinados diseños puede causar la comparsa de la barra de scroll horizontal: dificultad en la legibilidad. 10.3.4.4

Diseño hibrido

A favor Todo lo bueno de aporta el diseño fijo, fluido y elástico. En contra ¿Hacemos una investigación? 10.3.5

En fin, ¿cuál es diseño (más) accesible?*


57

      

No hay un diseño más accesible que otro.



Se elige el tipo de diseño en base a las necesidades (proyecto).


58



     



*La W3C WAI no establece cual sea el diseño más accesible sino que sea transformable de una manera agradable y que el contenido sea comprensible y navegable. 10.3.6

Flujo de trabajo en el diseño de la interfaz

Las siguientes tareas representan un flujo de trabajo rudimentario para el diseño de la interfaz WebApp. 1. Revisar la información contenida en el modelo de análisis y refinarla conforme se requiera. 2. Desarrollar un bosquejo aproximado de la plantilla de la interfaz de la WebApp. 3. Correlacionar los objetivos del usuario con acciones específicas de la interfaz. 4. Definir un conjunto de tareas de usuario que estén asociadas con cada acción. 5. Elaborar bosquejos con imágenes de la pantalla para cada acción de la interfaz. 6. Refinar la plantilla de la interfaz y los bosquejos con el uso de entradas desde el diseño estético. 7. Identificar los objetos de la interfaz del usuario que se requieren para implementarla. 8. Desarrollar una representación de procedimiento de la interacción del usuario con la interfaz. 9. Desarrollar una representación del comportamiento de la interfaz. 10. Describir la plantilla de la interfaz par a cada estado. ING. ROSA IMELDA GARCIA CHI,MTI

59

     



11. Refinar y revisar el modelo de diseño de la interfaz. 10.4 Diseño estético

El diseño estético, también llamado diseño gráfico, es un esfuerzo artístico que complementa los aspectos técnicos de la ingeniería Web. Sin él una WebApp puede ser funcional, pero sin atractivo. 10.5 Diseño de contenido

El diseño de contenido se enfoca en dos asuntos de diseño diferentes, cada uno lo abordan individuos con distintos conjuntos de habilidades. El diseño de contenido desarrolla una representación de diseño para los objetos de contenido y representa los mecanismos que se requieren para que establezcan sus relaciones uno con otro. 10.5.1

Objetos de contenido

La relación entre objetos de contenido, defina como parte del modelo de análisis WebApp y los objetos de diseño que representan contenido es análoga a la relación entre las clases de análisis y los componentes de diseño. Un objeto de contenido tiene atributos que incluyen información específica de contenido y atributos específicos de implementación que se especifican como parte del diseño. 10.6 Diseño arquitectónico

El diseño arquitectónico está enlazado con las metas establecidas para la WebApp, el contenido que se presentará, los usuarios que la vistan y la filosofía de navegación que se establezca.


60

     



La arquitectura de contenido se basa en la forma en que los objetos de contenido se estructuran para su presentación y navegación. 10.6.1

Arquitectura de contenido

Se centra en la definición de la estructura hipermedia global de la WebApp. El diseño se puede elegir de cuatro diferentes estructuras de contenido: 

Estructuras lineales



Estructuras en retícula



Las estructuras jerárquicas



La estructura en red.

10.7 Diseño de navegación

El diseñador debe definir las rutas de navegación que habiliten para la ruta de los usuarios el acceso al contenido y las funciones de las WebApp. Para ello se debe: 

Identificar la semántica de navegación para diferentes usuarios del sitio



Definir la mecánica que logra la navegación.


61

      10.7.1



Semántica de navegación

Durante las etapas iniciales del diseño, de navegación se valora la arquitectura de contenido de la WebApp para determinar una o más FdN para cada caso de uso. Como se anotó anteriormente, una FdN identifica los nodos de navegación y los vínculos que permiten la navegación entre ellos. 10.7.2

Sintaxis de navegación

Conforme el diseño se lleva a cabo se define la mecánica de navegación, entre sus posibilidades tenemos: 

Vinculo de navegación individual



Barra de navegación horizontal



Columna de navegación vertical





Pestañas Mapas del sitio


62

     



10.8 Método de diseño hipermedia orientado a objetos (MDHOO)

Las metodologías tradicionales de ingeniería de software, o las metodologías para sistemas de desarrollo de información, no contienen una buena abstracción capaz de facilitar la tarea de especificar aplicaciones hipermedia. El tamaño, la complejidad y el número de aplicaciones crecen en forma acelerada en la actualidad, por lo cual una metodología de diseño sistemática es necesaria para disminuir la complejidad y admitir evolución y reusabilidad. Producir aplicaciones en las cuales el usuario pueda aprovechar el potencial del paradigma de la navegación de sitios web, mientras ejecuta transacciones sobre bases de información, es una tarea muy difícil de lograr. En primer lugar, la navegación posee algunos problemas. Una estructura de navegación robusta es una de las claves del éxito en las aplicaciones hipermedia. Si el usuario entiende dónde puede ir y cómo llegar al lugar deseado, es una buena señal de que la aplicación ha sido bien diseñada. Construir la interfaz de una aplicación web es también una tarea compleja; no sólo se necesita especificar cuáles son los objetos de la interfaz que deberían ser implementados, sino también la manera en la cual estos objetos interactuarán con el resto de la aplicación. En hipermedia existen requerimientos que deben ser satisfechos en un entorno de desarrollo unificado. Por un lado, la navegación y el comportamiento funcional de la aplicación deberían ser integrados. Por otro lado, durante el proceso de diseño se debería poder desacoplar las decisiones de diseño relacionadas con la estructura navegacional de la aplicación, de aquellas relacionadas con el modelo del dominio. ING. ROSA IMELDA GARCIA CHI,MTI

63

     



OOHDM propone el desarrollo de aplicaciones hipermedia a través de un proceso compuesto por cuatro etapas: diseño conceptual, diseño navegacional, diseño de interfaces abstractas e implementación. 10.8.1

Diseño Conceptual

Durante esta actividad se construye un esquema conceptual representado por los objetos del dominio, las relaciones y colaboraciones existentes establecidas entre ellos. En las aplicaciones hipermedia convencionales, cuyos componentes de hipermedia no son modificados durante la ejecución, se podría usar un modelo de datos semántico estructural (como el modelo de entidades y relaciones). De este modo, en los casos en que la información base pueda cambiar dinámicamente o se intenten ejecutar cálculos complejos, se necesitará enriquecer el comportamiento del modelo de objetos. En OOHDM, el esquema conceptual está construido por clases, relaciones y subsistemas. Las clases son descritas como en los modelos orientados a objetos tradicionales. Sin embargo, los atributos pueden ser de múltiples tipos para representar perspectivas diferentes de las mismas entidades del mundo real. Se usa notación similar a UML (Lenguaje de Modelado Unificado) y tarjetas de clases y relaciones similares a las tarjetas CRC (Clase Responsabilidad Colaboración). El esquema de las clases consiste en un conjunto de clases conectadas por relaciones. Los objetos son instancias de las clases. Las clases son usadas durante el diseño navegacional para derivar nodos, y las relaciones que son usadas para construir enlaces.


64

      10.8.2



Diseño Navegacional

La primera generación de aplicaciones Web fue pensada para realizar navegación a través del espacio de información, utilizando un simple modelo de datos de hipermedia. En OOHDM, la navegación es considerada un paso crítico en el diseño aplicaciones. Un modelo navegacional es construido como una vista sobre un diseño conceptual, admitiendo la construcción de modelos diferentes de acuerdo con los diferentes perfiles de usuarios. Cada modelo navegacional provee una vista subjetiva del diseño conceptual. El diseño de navegación es expresado en dos esquemas: el esquema de clases navegacionales y el esquema de contextos navegacionales. En OOHDM existe un conjunto de tipos predefinidos de clases navegacionales: Nodos, enlaces y estructuras de acceso. La semántica de los nodos y los enlaces son las tradicionales de las aplicaciones hipermedia, y las estructuras de acceso, tales como índices o recorridos guiados, representan los posibles caminos de acceso a los nodos. La principal estructura primitiva del espacio navegacional es la noción de contexto navegacional. Un contexto navegacional es un conjunto de nodos, enlaces, clases de contextos, y otros contextos navegacionales (contextos anidados). Pueden ser definidos por comprensión o extensión, o por enumeración de sus miembros.


65

     



Los contextos navegacionales juegan un rol similar a las colecciones y fueron inspirados sobre el concepto de contextos anidados. Organizan el espacio navegacional en conjuntos convenientes que pueden ser recorridos en un orden particular y que deberían ser definidos como caminos para ayudar al usuario a lograr la tarea deseada. Los nodos son enriquecidos con un conjunto de clases especiales que permiten de un nodo observar y presentar atributos (incluidos las anclas), así como métodos (comportamiento) cuando se navega en un particular contexto. 10.8.3

Diseño de Interfaz Abstracta

Una vez que las estructuras navegacionales son definidas, se deben especificar los aspectos de interfaz. Esto significa definir la forma en la cual los objetos navegacionales pueden aparecer, cómo los objetos de interfaz activarán la navegación y el resto de la funcionalidad de la aplicación, qué transformaciones de la interfaz son pertinentes y cuándo es necesario realizarlas. Una clara separación entre diseño navegacional y diseño de interfaz abstracta permite construir diferentes interfaces para el mismo modelo navegacional, dejando un alto grado de independencia de la tecnología de interfaz de usuario. El aspecto de la interfaz de usuario de aplicaciones interactivas (en particular las aplicaciones Web) es un punto crítico en el desarrollo que las modernas metodologías tienden a descuidar. En OOHDM se utiliza el diseño de interfaz abstracta para describir la interfaz del usuario de la aplicación de hipermedia.


66

     



El modelo de interfaz ADVs (Vista de Datos Abstracta) especifica la organización y comportamiento de la interfaz, pero la apariencia física real o de los atributos, y la disposición de las propiedades de las ADVs en la pantalla real son hechas en la fase de implementación. 10.8.4

Implementación

En esta fase, el diseñador debe implementar el diseño. Hasta ahora, todos los modelos fueron construidos en forma independiente de la plataforma de implementación; en esta fase es tenido en cuenta el entorno particular en el cual se va a correr la aplicación. Al llegar a esta fase, el primer paso que debe realizar el diseñador es definir los ítems de información que son parte del dominio del problema. Debe identificar también, cómo son organizados los ítems de acuerdo con el perfil del usuario y su tarea; decidir qué interfaz debería ver y cómo debería comportarse. A fin de implementar todo en un entorno Web, el diseñador debe decidir además qué información debe ser almacenada.


67

     



11 Práctica No. 4 11.1 Nombre de la práctica: Fase 4: Modelado del Diseño de IWeb

11.1.1

Objetivo

Desarrollar el Modelado del Diseño de la aplicación Web que ha estado resolviendo desde la Fase 1.


68

      11.1.2

Introducción



Cuando se aplica el diseño dentro del contexto de la ingeniería Web, se deben considerar cuestiones tanto genéricas como específicas. El diseño debe ser muy específico. Diseño de calidad de una WebApp En la práctica, la calidad de los sitios web se ha          

común y en la experiencia de los desarrolladores. El estudio de la calidad de productos y procesos de desarrollo para la Web es muy reciente y todavía no se dispone de métodos de evaluación ampliamente difundidos para este tipo de entorno. Por lo tanto, existe la gran necesidad de metodologías efectivas para la obtención de aplicaciones Web de calidad.

Actualmente,

hay

dos

vertientes

de

metodologías de desarrollo para la Web: la comunidad de Ingeniería de Software y la comunidad de Hipermedia. Estas metodologías carecen sin embargo de métricas que puedan ser aplicadas a los modelos intermedios (Ej. Modelo de Objetos, Modelo Navegacional) utilizados en el proceso de desarrollo orientado a la Web.


69

      11.1.3

Material

y

Equipo

















www.mex.tl

,

www.1&1.mx

,

www.mipaginawebgratis.es , www.wix.com, entre otras páginas que permitan el diseño de la página web. 

11.1.4

Metodología

Herramientas de diseño de páginas web

1. Conformar

equipo

de

trabajo

con

diversos roles 2. Descargar el formato para elaborar la fase 4 (Anexo No. 4). Se encuentra disponible en las plataformas como www.slideshare.net,

www.issuu.com,

www.googledocs.com , www.scribd.com. 3. Resolver cada uno de los puntos propuestos en la fase del proyecto 4. Elaborarlo en formato digital 5. Generar la página Web en algunas de las herramientas de la web o herramientas de desarrollo de páginas web 6. Subirlo a la Plataforma Virtual de Aprendizaje


70

      11.1.5

Sugerencias



Es recomendable que utilices las herramientas de desarrollo de páginas web que están disponibles en la Web de manera gratuita, ya que podrás ver tu creación en internet.


71

     

    

 

Pruebas para Ingeniería Web


72



     



12 Fase 5. Pruebas para IWeb 12.1 Pruebas de conceptos para WebApp

Se consideran las dimensiones de calidad que son particularmente relevantes en cualquier debate de las pruebas para el trabajo de ingeniería Web. Se considera también la naturaleza de los errores que se encuentran como consecuencia de las pruebas y la estrategia de poner a prueba aplicable para descubrir dichos errores. 12.1.1

Dimensiones de calidad

La calidad se incorpora en una aplicación Web como consecuencia de un buen diseño. Se evalúa al aplicar una serie de revisiones técnicas que valoran varios elementos del modelo de diseño y al aplicar una serie de revisiones técnicas que valoran varios elementos del modelo de diseño y al aplicar un proceso de pruebas. Tanto las revisiones como las pruebas examinan una o más de las siguientes dimensiones de calidad: El contenido se evalúa tanto en el ámbito sintáctico y semántica La función de prueba para descubrir errores que indiquen que no hay concordancia con los requisitos del cliente. La estructura se valora para asegurarse de que entrega adecuadamente contenido y función de la WebApp. La facilidad de uso se prueba para garantizar que a cada categoría de usuario la soporta la interfaz. ING. ROSA IMELDA GARCIA CHI,MTI

73

     



*La navegabilidad se pone a prueba para garantizar que toda la sintaxis y semántica de navegación se ejercen para descubrir cualquier error de navegación.

*El desempeño se prueba en una diversidad de condiciones operativas, configuraciones y cargas para asegurar que el sistema responde a la interacción del usuario. La compatibilidad se prueba al ejecutar las WebApp en varias configuraciones huésped. La interoperabilidad se prueba para asegurar que la WebApp realiza interfaces adecuadas. La seguridad se prueba al valorar las vulnerabilidades potenciales e intentar explotar cada una de ellas. 12.1.2

Estratégicas de prueba

Las estrategias para probar una WebApp adoptan los principios básicos para todas las pruebas de software. 1. Se revisa el modelado de contenido de la WebApp para descubrir errores. 2. Se revisa el modelo de la interfaz para asegurarse que todos los casos


74

     



12.2 Las pruebas que se aplican a una aplicación web

El proceso de someter a prueba la WebApp es una suma de actividades relacionadas con una sola meta: descubrir errores en el contenido, la función, la facilidad de uso, la navegabilidad, el desempeño, la capacidad y la seguridad de la WebApp. Esto se logra a lo largo de todo el proceso de ingeniería Web, mediante la aplicación de una estrategia de prueba que abarca tanto revisiones como pruebas ejecutables. Los ingenieros Web y otros participantes del proyecto (gerentes, clientes, usuarios finales) toman parte en el proceso de probar WebApp. Si los usuarios finales encuentran errores

que afecten su confianza en la

WebApp, se irán a cualquier otra parte por el contenido y la función que necesitan, y la WebApp fracasará. Por esta razón, los ingenieros de la Web deben trabajar para eliminar tantos errores como sea posible antes que la WebApp esté en línea. El proceso de prueba comienza en enfocarse sobre aquellos aspectos de ésta que son visibles para el usuario y procede a probar dicha tecnología e infraestructura. La prueba consta de siete etapas: contenido, interfaz, navegación, componente, configuración, desempeño y prueba de seguridad. En algunos casos se produce un plan de prueba de la WebApp.


75

     



El proceso de Pruebas que se debe aplicar a la página Web que se ha construido tiene su base en el Diseño de la Página:

Figura 5 Proceso de Prueba

En la figura 6 se aprecian todas las pruebas a aplicarse en la Página que se ha desarrollado:


77

     



13 Práctica No. 5 Nombre de la práctica: Fase 5 Aplicación de Pruebas IWeb 

13.1.1

Objetivo

Aplicar todo el proceso de pruebas a la Página Web desarrollada mostrando evidencia de la aplicación en un documento digital.


79

      13.1.2

Introducción



La estrategia para probar una WebApp, adopta los principios básicos para todas las pruebas de software y aplica una estrategia y las tácticas que se recomendaron respecto de los sistemas orientados a objetos como se indica a continuación: 

Revisión del modelo de contenido de la WebApp en busca de errores



Revisión

del

modelo

de

la

interfaz

asegurándose que todos los casos de uso pueden acomodarse 

Revisión del modelo de diseño de la WebApp en busca de errores de navegación



Se prueba la interfaz de usuario para descubrir errores en la presentación o los mecanismos de navegación.



Componentes funcionales seleccionados se prueban en forma individual.



Se llevan a cabo pruebas de desempeño.



Se prueba la WebApp en una población controlada y monitoreada de usuarios finales buscando errores relacionados con la facilidad de uso, con la compatibilidad, confiabilidad y desempeño de la WebApp.


80

      13.1.3

Material

y

Equipo






Navegadores





Diversos dispositivos para accesar a la página

13.1.4

Metodología







1. Conformar equipo de trabajo 2. Tener diversos dispositivos con acceso a internet 3. Cargar la página Web que desarrollaron 4. Aplicar cada una de las pruebas de IWeb 5. Documentar y agregar evidencia de las pruebas aplicadas 6. Entregar en la plataforma virtual el documento de pruebas.

13.1.5

Sugerencias

Es necesario que todo el equipo participe en la prueba de la página web. Las pruebas no se pueden aplicar si no está terminada la página Web.


81

            

Documento Integrador


82



     



19 Bibliografía 1.

Cuevas, I., Ingeniería de la Web y Patrones de Diseño. 2005.

2.

Arlow, J. and I. Neustad, UML 2. Programación. Anaya Multimedia-Anaya Interactiva, 2006.

3.

Booch, G., et al., El lenguaje unificado de modelado. 1999: Addison Wesley Madrid.

4.

Cuevas Agustín, G., Gestión del proceso software . 2002.

5.

Fowler, M., R. SCOTT, and K. Scott, UML gota a gota. 1999: Pearson Educación.

6.

Fuente, A.A.J., et al., El libro Azul de la Ingeniería en Informática: una alternativa al Libro Blanco. I Jornadas de Innovación Docente de la EUITIO,

2005: p. 67. 7.

García Molina, J.J., G. Rossi, and A. Moreira, UML: el lenguaje estándar para el modelado de software. Novática: Revista de la Asociación de

Técnicos de Informática, 2004(168): p. 4-5. 8.

Génova, G., J.M. Fuentes, and J. Llorens, Evaluación de herramientas CASE para UML.

9.

Grady, R.B., Successful software process improvement . 1997: Prentice Hall PTR.

10.

Guevera, A., Ingeniería Web: E-learning. Cultura Científica, 2011(5): p. 1620.


98

      11.



Hernández González, A., Identificación de Procesos de Negocio. Ingeniería Industrial, 2010. 25(3): p. 6 pág.

12.

Humphrey, W.S., Introducción al Proceso Software Personal (PSP) . 2001: Addison Wesley.

13.

Pastor, O. OOWS: Una aproximación para el Modelado Conceptual de Aplicaciones Web. 2002.

14.

Pressman, R.S. and J.M. Troya, Ingeniería del software: Un enfoque práctico. 6ta edicion. 2006: McGraw Hill.

15.

Rumbaugh, J. and I. Jacobson, Grady Booch. The Unified Modeling Language Reference Manual (The Addison-Wesley Object Technology Series), 2001.

16.

Senn, J.A. and D. Mercer, Análisis y diseño de sistemas. 1992: México: McGraw Hill.

17.

Sommerville, I., Ingeniería del software. 2005: Pearson Educación.

18.

Thomas, D., et al., Agile web development with rails. 2005: Pragmatic bookshelf New York.


99

Desarrollo de Software Con Ingeniería Web - LIBRO

Recommend Documents