Ingenieria Web Resumen 39221e
This document was ed by and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this report form. Report 3i3n4
Overview 26281t
& View Ingenieria Web Resumen as PDF for free.
More details 6y5l6z
- Words: 6,351
- Pages: 10
Ingeniería de Software II – Ingeniería Web – Pablo Pintado MBA
Ingeniería Web antes de comenzar a construir es mejor que se entienda el problema, analice y diseñe una solución factible, se la implemente en una forma sólida y con pruebas amplias. Para este objetivo se debe: - Formular el problema - Planificar - Modelar los requisitos - Diseñar la solución - Construir con tecnología y herramientas especializadas - Evaluación por parte de los s (técnicos, como empresariales). Atributos de las aplicaciones basados en Web (WebApp) Los sistemas basados en Web involucran una mezcla entre publicación impresa y desarrollo de software, entre marketing e informática, entre comunicaciones internas y relaciones externas y entre arte y tecnología. Características: - Intensidad de red (Internet, intranet, extranet) - Concurrencia (gran numero de s tienen al mismo tiempo) - Carga impredecible (el numero de s puede variar de un día a otro) - Desempeño (tiempo en ingreso y navegación) - Disponibilidad (24x7x365) - Gobernada por los datos (proveen gran cantidad de información) - Evolución continua / Inmediatez (la agilidad para poner productos/servicios) - Seguridad (para el manejo transaccional) - Sensibilidad al contenido / Estética / Temporalizable: calidad y naturaleza estética de su contenido - Personalizable (ya sea la propia WebApp o el personaliza su navegación, contenido de acuerdo a sus necesidades específicas) - Soporte (ayuda en línea, grupos de discusión y vínculos relacionados). Proceso de Ingeniería Web Debido a que la Internet cambio la prioridad principal de desarrollo de que a cuando; el proceso debe ser realizado bajo una filosofía de desarrollo ágil, en el cual se incorpora rápidos ciclos de desarrollo. El Marco de trabajo de IWeb debe considerar: adoptar el cambio, aliente la creatividad, construyendo sistemas con pequeños equipos de desarrollo, con un desarrollo evolutivo/incremental, istrar el riesgo y usar cortos ciclos de desarrollo. Se pueden utilizar varios tipos de procesos como XP (programación extrema, MSF (Microsoft solution Framework) o una personalizada ágil IWeb. Comunicación con el cliente - Análisis del negocio (análisis del contexto empresarial-organizativo para la WebApp) o Identifican a los participantes o Predicen potenciales cambios en el ambiente y requisitos o Se definen integración entre la WebApp y otras aplicaciones del negocio, bases de datos - Formulación o Recopilación de requisitos Planeación Se definen tareas y un calendario de plazos, asignando responsables y/o ejecutores. Se define la línea base para efectos de control de cambios Modelado Se mezclan las funciones de análisis y diseño para crear el modelado IWeb. - Análisis de requisitos o Definir el contenido que tendrá la WebApp o Funcionalidad que se presentara al o Modos de interacción de cada clase de al momento de navegar - Diseño o Diseño de contenido/aplicación o Diseño de arquitectura de la información o Diseño de interfase o Diseño de la navegación
1
Ingeniería de Software II – Ingeniería Web – Pablo Pintado MBA
Construcción - Programación de acuerdo al modelado - Pruebas rápidas (contenido, arquitectura, interfase, navegación) Despliegue (entrega y retroalimentación) - configuración para su ambiente operativo - evaluación por parte del - retroalimentación y ajustes. Unido a estos cinco pasos para un proceso incremental debe ir acompañado de los puntos básicos de istración de cambios y riesgos. FORMULACION Y PLANEACION PARA INGENIERIA WEB Dentro del Marco de trabajo de Ingeniería Web se inicia con la formulación y planificación. La Formulación Inicia con la identificación de las necesidades del negocio, exponiendo los objetivos de la WebApp, definiendo grandes características y funciones, recopilando los requisitos que conducen al desarrollo del modelo de análisis. También identifica el ámbito de esfuerzo de desarrollo así como la forma de cómo determinar un resultado exitoso. Si bien en la formulación se deben exponer las grandes necesidades, pero por lo general también se exponen detalles o especificaciones que el cliente y el Ingeniero Web desean hacerlo. Preguntas para la formulación ¿Cuál es la principal motivación (necesidades del negocio) para la WebApp? ¿Cuáles son los objetivos que debe satisfacer la WebApps? ¿Quién usará la WebApp? De esto se podrá ahora especificar metas informativas y aplicativas como: Informativa: “el sitio proporcionara a los s especificaciones de producto detalladas que incluyan descripciones técnicas, instrucciones de instalación y precios.” Aplicativa: “el sitio consultara al acerca de la instalación (casa, oficina) que será protegida y realizara recomendaciones personalizadas acerca del producto y la configuración que se utilizara”. De estas especificaciones se podrán definir perfiles de . Con esto se definirá el ámbito para la WebApp. Recopilación de requisitos para Web Se puede recopilar por medio de una Ingeniería de requisitos común, y si adaptamos a WebApp los objetivos serán: - identificar requisitos de contenido - identificar requisitos funcionales - definir escenarios de interacción para diferentes clases de s. Los pasos para esta recopilación de requisitos: 1. Pedir a los clientes que definan las categorías de y describan cada categoría - Cual es objetivo global del cuando usa la WebApp? - Cuales son los antecedentes y la pericia del en relación al contenido y la funcionalidad de la WebApp? - Que características genéricas de la WebApp le gustan y/o disgustan al ? 2. comunicarse con los clientes para definir los requisitos básicos de la WebApp. Para esta comunicación se usan varios mecanismos como: - grupo muestral tradicional (presencial con un grupo de personas) - entrevistas interactivas (electrónicos, exploración) (desde sitio web o correo electrónico) - construcción de escenarios, a s seleccionados se les pide que describan interacciones específicas con la WebApp. 3. Analizar la información recopilada y utilizar la información para realizar un seguimiento con los clientes - Se debe categorizar en clase de y tipos de transacción - Se debe desarrollar lista de objetos de contenido y las operaciones que se aplican a estos contenidos dentro de una transacción de especifico - Se pide a los s que ordenen como gustaría que se les organizara el contenido y su funcionalidad - Así como también listar las etiquetas que utilizaremos para enlazar a estos contenidos y funciones 4. Definir casos de uso que describan escenarios de interacción para cada clase de (de la jerarquía de s). Se describe como interactúa cada categoría de (actor) con la WebApp para lograr una acción específica. Esto servirá para el análisis y pruebas.
2
Ingeniería de Software II – Ingeniería Web – Pablo Pintado MBA
Planeación En un proyecto IWeb, el equipo de trabajo es multidisciplinario. Dos alternativas al momento de construir una WebApp, un camino es la subcontratación y otro es el desarrollo en casa (in-house). Planeación de WebApp con subcontratación: - Inicio de proyecto Identificar el publico para la WebApp, metas globales, información y servicios que proporcionara la WebApp, se destacan Web competidores, y formas de medir cualitativa y cuantitativa si la web es exitosa Desarrollar internamente un diseño aproximado de la WebApp, identificando el tipo y volumen de contenido, tipos de procesamiento interactivo Elaborar un plan aproximado que incluya las fecha finales y claves Crear una lista de responsabilidades para la organización interna y la subcontratista Identificar el grado de supervisión e interacción de la organización con el subcontratista (definir claramente los os de cada parte) - Selección entre subcontratistas candidatos Comprobar con clientes anteriores sobre el profesionalismo del subcontratista Determinar los nombres de los Ingenieros Web que realizaron con éxito los proyectos Examinar trabajos similares - Coordinar la gestión del proyecto con el subcontratista, aquí deben acordarse tareas, puntos de comprobación e hitos, aseguramiento de calidad, valorar riesgos, control de cambios y métodos de comunicación efectiva - Evaluación del programa del proyecto, debe tener una dosificación de acuerdo al tamaño del proyecto, cuando son cortos los controles llegan a ser hasta diarios - Es importante mencionar que el ámbito podrá cambiar constantemente, por lo que se suele “congelar” o versionar para poder tener entregables. Planeación de WebApp en modalidad in-house: - Entender el ámbito, las dimensiones de cambio y las restricciones del proyecto - Definir la estrategia del proyecto incremental - Desarrollar una estimación rápida, con esto se podrá saber a nivel macro si podrá desarrollarse con recursos disponibles - Establecer un conjunto de tareas (descripción del proceso) - Establecer el plan, incluyendo las tareas antes descritas y estableciendo fechas de entregables - Definir mecanismos de rastreo del proyecto, es poder saber como valorar los entregables (si se completaron). -
-
-
MODELADO DE ANALISIS PARA APLICACIONES WEB que información o contenido se presentará o manipulara? Que funciones realizará el final? Que comportamientos exhibirá la WebApp conforme presente contenido y realice funciones? Requisitos para el análisis de las WebApps Formulación, se identifica la motivación (metas) y objetivos básicos para la WebApp, así como la definición de categoría de s. Recopilación de requisitos, aquí se intensifica la comunicación entre el Ingeniero de Software y los expertos del negocio. Se listan los requisitos de contenido y funcionales; se desarrollan escenarios de iteración (casos de uso). La intención es el resolver el por qué se construirá la WebApp, quien la usará, y que problema resolverá a sus s. Modelado de análisis, luego de la formulación y recopilación de requisitos, se procede con el modelado de contenido, interacción, funcional, configuración y navegación. Modelo de Análisis para las WebApps modelado de Contenido modelado de Interacción (como interactúa el con la WebApp) modelado funcional (operaciones de contenido y de procesamiento) modelado de Configuración (ambiente e infraestructura) análisis relación-navegación
El Modelo de Contenido Este modelo contiene los elementos estructurales que son necesarios para satisfacer los requisitos de contenido de la WebApp, como son las clases de contenido por ejemplo texto, imágenes graficas, fotografías, imágenes video, audio, etc. 3
Ingeniería de Software II – Ingeniería Web – Pablo Pintado MBA
Así como todas las clases de análisis visibles para el que se crean para la interacción con la WebApp. Estas se derivan del análisis gramatical de los casos de uso. El Modelo de Interacción Las WebApp que proveen “conversación” con el final deben ser modelado su interacción por medio de cuatro elementos: - casos de uso (proporcionan una visión unidimensional de la interacción) - diagramas de secuencia: (maneja dos dimensiones) representación abreviada de la forma como interactúa las acciones del con las clases de contenido y análisis - diagramas de estado (tres dimensiones), muestra a más del comportamiento una información acerca de los patrones de navegación potenciales que no proporciona los casos de uso y diagramas de secuencia. - prototipo de interfaz de . Si bien la creación del prototipo de interfaz de es una actividad de diseño, se recomienda hacerlo ya en el análisis (mientras más pronto mejor) porque se pueden obtener requerimientos adicionales al momento que el vea el prototipo El Modelo de Configuración Las WebApps deben ser construidas para que funcionen en una diversidad de ambientes (clientes y servidores), por lo que se deben especificar las características de hardware y software soportados, así como también especificar las interfaces bien definidas y seguras para la interacción con las bases de datos y el resto de aplicaciones de la empresa y asociadas. Análisis relación-navegación Se deben establecer los vínculos apropiados entre los objetos de contenido y las funciones. El ARN (análisis relación navegación) sirve para determinar la estructura de relación de la aplicación (relaciones potenciales en los dominios que pueden implementarse como vínculos más adelante), así como las estructuras de navegación apropiadas sobre estos vínculos, meta-información y navegaciones adicionales. El ARN se organiza en cinco pasos: - análisis de los participantes: identifica las diversas categorías de . - análisis de elementos: se identifica los objetos de contenido y los elementos funcionales. - análisis de relaciones: se describe las relaciones entre elementos WebApp - análisis de navegación: examina como los s pueden acceder a elementos individuales o grupos de elementos - análisis de evaluación: considera temas pragmáticos como por ejemplo: costo/beneficio asociados con la implementación de las relaciones definidas en los dos pasos anteriores. Análisis de navegación. Para definir los requisitos de navegación siempre el debe saber dónde está y a donde va. Se debe considerar los requisitos que dictan como navegara cada categoría de de un elemento a otro. Esto se lo hace al detalle a nivel del diseño, sin embargo, en esta etapa se consideran los requisitos de navegación globales mediante las siguientes preguntas: MODELADO DE DISEÑO PARA APLICACIONES WEB Introducción de diseño En pequeños WebApp deben invertirse poco tiempo en el diseño porque se asume que los WebApp tienen la característica de inmediatez y volatilidad. Sin embargo en WebApp más grandes (más de 100 objetos) deben invertirse más tiempo porque debe aplicarse la calidad al software. Esta calidad de software WebApp cuenta con varios requisitos que deben cumplirse como son: facilidad de uso, funcionalidad, confiabilidad, eficiencia, facilidad de mantenimiento. A estos requisitos les podemos adicionar otros como: seguridad, disponibilidad, escalabilidad. Pirámide del Diseño IWeb. El diseño para Ingeniería Web es una mezcla adecuada de estética, contenido y tecnología que descansa en una pirámide de 6 niveles que son los pasos a seguir en el Diseño.
4
Ingeniería de Software II – Ingeniería Web – Pablo Pintado MBA
Diseño de la interfaz de la WebApp Toda interfaz de debe tener las características: fácil de usar, fácil de aprender (en Web no debería haber capacitación), fácil navegar, intuitiva, consistente, eficiente, libre de errores y funcional; ofreciendo al final una experiencia satisfactoria y gratificante. Los objetivos de una interfaz WebApp son: - establecer una ventana consistente con el contenido y funcionalidad que proporciona - guiar al a través de una serie de interacciones con la WebApp - organizar las opciones de navegación y el contenido disponible para el . El diseño de la interfaz inicia con el desarrollo de las jerarquías de El Ingeniero Web debe diseñar la interfaz de modo que conteste a las siguientes preguntas (conforme navegue el en la Web): - Dónde estoy? o A que se ha tenido o Informar la ubicación en la jerarquía de contenido - Que puedo hacer ahora? o Indicar sus opciones actuales (funciones disponibles, vínculos vivos, contenido relevante) - Donde he estado, a donde voy? o Facilitar la navegación o Facilitar un mapa (implementado de forma fácil de entender). Principios del diseño de la interfaz. Las interfaces efectivas son comprensibles y ofrecen al una sensación de control. No preocupa al final de trabajos internos (le es transparente), así como realizan el máximo trabajo mientras demandan un mínimo de información a los s. Con la finalidad de cumplir con esto se plantean los siguientes principios: - Anticipación, Comunicación , Consistencia , Autonomía, Eficiencia, Flexibilidad, Ley de Fitt, Objetos de interfaz humana, Reducción de latencia, Facilidad de aprendizaje, Metáforas, Mantener la integridad del producto de trabajo, Legibilidad, Estado de rastro, Navegación visible, Rapidez de lectura, Evitar signos de construcción, Los s prefieren no desplazarse, Menús de navegación y los encabezados deben estar diseñados de manera consistente, La estética no debe sustituir la funcionalidad, Opciones de navegación deben ser obvias Flujo de trabajo para el diseño de la interfaz: 1. revisar la información contenida en el modelo de análisis y refinarla conforme se requiera 2. desarrollar el bosquejo de la plantilla de la interfaz de la WebApp 3. correlacionar los objetivos del con acciones especificas de la interfaz 4. Definir un conjunto de tareas de que estén asociadas con cada acción. (cada acción del por ejemplo comprar un producto está relacionado con un conjunto de tareas que fueron identificadas en el análisis y ahora en el diseño se las correlaciona su interacción para identificar asuntos de navegación, objetos de contenido y funciones) 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 diseño estético (con la ayuda del diseñador grafico) 7. Identificar los objetos de la interfaz del que se requieran para implementarla 8. Desarrollar una representación de procedimiento (comportamiento) de la interacción del con la interfaz (es opcional, se puede representar con UML: diagramas de secuencia, actividad y de estado)
5
Ingeniería de Software II – Ingeniería Web – Pablo Pintado MBA
9.
Describir la plantilla de la interfaz para cada estado (es opcional, si realizo el paso 8, en función del paso 2 y 5 se debe especificar las plantillas para cada estado) 10. Refinar y revisar el modelo de diseño de la interfaz (revisar toda la interfaz para confirmar que exista consistencia y por sobre todo facilidad de uso). Diseño Estético (gráfico) También conocido como diseño grafico, debe ser hecho por un “artista” o especialista en diseño grafico. Para realizar esta fase se debe regresar a la jerarquía de s desarrollado en el análisis, preguntando quienes son los s de la WebApp y que “apariencia” desean. No existen reglas absolutas para el diseño de plantillas, sin embargo se enumeran los siguientes lineamientos generales: - no temerle al espacio vació - resaltar el contenido, (el 80% debe ser contenido y el resto para la navegación y otras características) - Organizar los elementos de plantilla de arriba a la izquierda hacia abajo a la derecha (la mayor prioridad se la coloca a arriba a la izquierda) - Agrupar navegación, contenido y función geográficamente dentro la pagina (los humanos buscamos patrones virtualmente en todas las cosas, por lo que se debe conservarse un orden, porque caso contrario el tendrá una frustración en la búsqueda de información) - Preferible no permitir el uso de la barra de desplazamiento (la de arriba hacia abajo, y mucho menos la de izquierda a derecha) - Considerar la resolución y el tamaño de la ventana de navegador cuando se diseñe la plantilla (1280x800) - Los medios audiovisuales (imágenes, video, sonido) utilizados deben ser de lo más liviano posible para evitar paginas lentas (considerar la realidad del servicio de Internet de la región del ). Diseño de Contenido Se enfoca desde dos puntos de vista: - del Ingeniero Web que diseña los objetos de contenido y sus relaciones - del diseñador grafico o publicista que se ocupa de la representación de la información del objeto de contenido. Luego del modelo de contenido en el análisis que se especificaron ciertos atributos de las clases de contenido, se procede con la inserción de atributos específicos de implementación propios del diseño. Una vez que se detallan todos los objetos de contenido se deben diseñar la parte estética (apariencia y percepción adecuada), así como se debe estructurar el numero de objetos que se insertaran en una página web conforme las necesidades del y las restricciones impuestas por rapidez en descarga y conexiones de Internet. Diseño Arquitectónico El diseñador arquitectónico debe identificar la arquitectura de contenido (como se estructura los objetos de contenido para su presentación y navegación) y arquitectura de WebApp (la estructuración de la aplicación para gestionar la interacción con el , manejo de tareas internas, efectuar navegación y presentar el contenido). Arquitectura de Contenido Se centra en la definición de la estructura hipermedia global de la WebApp. - Estructura lineal. Cuando existe una secuencia predecible de interacciones (con alguna variación o desviación). - Estructura en retícula. Cuando el contenido está organizado categóricamente en dos o más dimensiones. - Estructura jerárquica. Son las más comunes, en donde su flujo de control es vertical por medio de las ramificaciones verticales, pero adicionalmente pueden tener control (flujo) horizontal por medio de ramificaciones de hipertexto pudiendo pasarse de una rama a otra directamente, sin embargo hay que tener cuidado con esta funcional adicional porque pueden causar confusión al . - Estructura en red. Denominada “Web pura”, está diseñado para poder navegar por medio de vínculos de hipertexto virtualmente a cualquier pagina del sistema, este enfoque es el más flexible pero al mismo tiempo puede ser el más confuso. Arquitectura de WebApp Aquí se describe la infraestructura que va a tener la solución WebApp. Existe una variedad de formas de diseñar esta arquitectura/infraestructura, sin embargo todas llevan el concepto de “multicapa”, que separan el manejo de la interfaz , navegación, comportamiento de la aplicación y de los datos. La arquitectura MVC Modelo-Vista-Controlador es usada por varias soluciones WebApp, que desacopla la interfaz del de la funcionalidad WebApp y del contenido de la información. - Modelo: el contenido de la aplicación y la lógica de procesamiento, desde aquí se acceden a los datos - Vista: contiene las funciones especificas de la interfaz - Controlador: gestiona el al modelo y vista y coordina el flujo entre ellos.
6
Ingeniería de Software II – Ingeniería Web – Pablo Pintado MBA
Otra de las alternativas de arquitectura es basada en el concepto de “multicanal” llamada Arquitectura Middleware, en donde igualmente está separado la interfaz , de las reglas del negocio y datos, pero aquí ya no solo se diseña pensando en un único front-end Web sino mas bien en varios canales que pueda proveer el servicio (Web, ATM, Celular, Kiosco, PDA, etc.). La capa Middleware contiene manejo de interfaces, las reglas de negocio, el control de flujo, a datos y otros sistemas; bajo el concepto de reutilización por todos los canales. Diseño Navegación Una vez establecido la arquitectura de la WebApp, se diseña las rutas de navegación que utilizaran los s al acceder al contenido y las funciones WebApp. Para esto se debe tomar en cuenta la semántica y sintaxis de la navegación. Semántica de Navegación: identificar la semántica “sentido” de navegación para los diferentes tipos de s, esto se lo toma de las categorías de y se desarrolla un USN (Unidades Semánticas de Navegación) para cada caso de uso, en estos USN se describen los requisitos de navegación, aquí se muestra como el actor se mueve entre los objetos de contenido y la funcionalidad WebApp. Sintaxis de Navegación: se define la “mecánica” de navegación, teniendo varias opciones como: - vinculo de navegación individual: que son vínculos basados en texto, iconos, botones y metáforas graficas - Barra de navegación horizontal: la lista de principales categorías de contenido o funcionales en una barra (de cuatro a siete categorías) - Columna de navegación vertical: similar a la horizontal con la particularidad que al momento de seleccionar una puede expandir a subcontenidos en forma de árbol - Pestañas: es una variación de la de barra o columna pero que dan la sensación de marca - Mapas de sitio: proporciona una tabla de contenido incluyente para la navegación hacia todos los contenidos y funcionalidad de la WebApp. En la mayoría de casos se elige navegaciones horizontales o verticales pero no ambas a la vez. Diseño a nivel de Componentes El diseño de componentes para WebApp se los hace de manera similar que para los sistemas convencionales orientados a objetos (sensibles al cambio y reducen la propagación de efectos secundarios cuando ocurren cambios), pues estos varían más bien por su ambiente de implementación y marcos de trabajo. Estos componentes deben ser diseñados bajo los principios: - Principio de Abierto Cerrado (PAC). Debe estar abierto para extensión pero cerrado para modificación. - Principio de Sustitución de Liskov (PSL). Permita al componente seguir funcionando si se cambia el uso de clase principal a una clase derivada, esto exige que toda subclase se apegue al contrato de la superclase. - Principio de Segregación de la Interfaz (PSI). Es mejor tener muchas interfaces específicas del cliente que una interfaz de propósito general. Es decir, no se debe tener una sola interfaz que tengan una variedad de funcionalidad que los diferentes tipo de cliente ocupan solo una parte de ella. - Principio de Equivalencia entre Reutilización y Versión (PER). Agrupar las clases reutilizables en paquetes que pueden manejarse y controlarse a medida que evolucionan nuevas versiones. Este principio va relacionado también con el principio que las clases que no se reutilizan juntas no deben agruparse juntas. - Principio del Cierre Común (PCC): las clases que cambien juntas deben permanecer juntas. Para esto deben juntarse clases que atiendan la misma área de función o comportamiento. Métricas de diseño para WebApp Las métricas de diseño deben ser creadas para facilitar al Ingeniero Web para medir la calidad de una forma cuantitativa/cualitativa, debiendo responder a las siguientes preguntas: - La interfaz del promueve la facilidad de uso? - La estética de la WebApp es apropiada para el dominio de la aplicación y confortable para el ? - El contenido está diseñado en una forma que proporciona la mayor información con el menor esfuerzo? - La navegación es eficiente y directa? - La arquitectura de la WebApp se ha diseñado para acomodar las metas y objetivos de los s, la estructura de contenido y funcionalidad y flujo de navegación requerido para usar el sistema de manera efectiva? - Los componentes están diseñados en una forma que reduce la complejidad de procedimientos y aumenta la confiabilidad y el desempeño?. PRUEBAS EN APLICACIONES WEB Como en todo software desarrollado, debe aplicarse un plan de pruebas desde el inicio y no esperar al final del proyecto para detectar errores. Es así que metodologías de proyectos como MSF tienen dentro de su planificación general del
7
Ingeniería de Software II – Ingeniería Web – Pablo Pintado MBA
proyecto un punto dedicado a la planeación de pruebas para poder preparar los ambientes y personal adecuado para las pruebas que por cierto son de diferentes tipos. - el contenido: evaluación sintáctica (ortografía y gramática de contenido) y semántica (exactitud de la información presentada y consistencia entre objetos de contenido y objetos relacionados) - la función: comprobar la concordancia con los requisitos del cliente - estructura: se comprueba que se entregue adecuadamente el contenido y la funcionalidad de la WebApp. - facilidad de uso: para cada categoría de , que va relacionado con la sintaxis y semántica de la navegación - navegabilidad: comprobar la sintaxis y semántica de navegación así como comprobar que esté controlado todo flujo, por ejemplo: vínculos rotos, vínculos inadecuados, etc.) - desempeño: se prueba en una diversidad de condiciones operativas, configuraciones, y cargas para saber que el software responde adecuadamente a cargas extremas - compatibilidad: se comprueba que la WebApp funciona en varias configuraciones huésped tanto del lado del cliente como del servidor e infraestructura de seguridad - interoperabilidad: se prueba para asegurar que la WebApp realiza interfaces adecuadas con otras aplicaciones y/o bases de datos, y que estas sean con un buen desempeño - seguridad: se prueba la vulnerabilidad potencial. Estrategias de Pruebas 1. revisar el modelo de contenido (sintáctica y semántica) 2. revisar el modelo de interfaz para confirmar que todos los casos de uso se pueden acomodar 3. revisar el modelo de diseño para descubrir errores de navegación 4. revisar la interfaz del para descubrir errores en la presentación o en los mecanismos de navegación 5. se prueban los componentes funcionales de forma individual (se cambia el concepto de unidad que en orientado a objetos era la clase ahora es la pagina Web que tiene encapsulado contenido, vínculos, procesamiento, etc. Así como también la unidad pueda ser un componente funcional. Es importante de igual manera se debe hacer pruebas de integración entre componentes). 6. se prueba la navegación a través de toda la arquitectura, para esto se aplica los casos de uso que se prueban contra el diseño de la navegación (USN) y luego con la aplicación en si 7. se prueba en diversas configuraciones ambientales para comprobar su compatibilidad. Se crea una matriz de referencia cruzada que define todos los probables sistemas operativos, navegador, plataformas de hardware y protocolos de comunicación. 8. se realizan pruebas de seguridad con el objetivo de encontrar vulnerabilidades 9. se hacen pruebas de desempeño para valorar como afecta el aumento del tráfico, que características de uso provocan degradación, cuales son los componentes responsables de la degradación y como esta degradación afecta a los objetivos y requisitos globales de la WebApp 10. se prueba la WebApp en una porción de población controlada y monitoreada de s finales. Los resultados de esta prueba servirán para mejorar la interacción, errores de contenido, navegación, facilidad de uso, compatibilidad, confiabilidad y desempeño de la WebApp. Se debe hacer un plan de pruebas que por lo general se definen en el planeamiento general del proyecto, en este plan se identifican: - tipo y objetivo de pruebas aplicar, - tareas que se aplicaran en la prueba, - la forma en la que se evaluara los resultados de las pruebas (métricas, valoración, niveles o puntuación). -
Prueba de Contenido sintáctica (ortografía y gramática de contenido) semántica (exactitud de la información presentada y consistencia entre objetos de contenido y objetos relacionados). Esta evaluación que se hace para cada objeto de contenido debe el examinador responder a las siguiente preguntas: o la información realmente es precisa (concisa y exacta)? o la plantilla del objeto de contenido es fácil de entender para el ? o La información anidada en un objeto de contenido se encuentra con facilidad? o La información presentada internamente es consistente con la información de otros objetos de contenido? o El contenido es ofensivo, engañoso o abre la puerta a pleitos? o El contenido infringe derechos de autor o marcas registradas? o El estilo estético del contenido entra en conflicto con el estilo estético de la interfaz global?
8
Ingeniería de Software II – Ingeniería Web – Pablo Pintado MBA
-
Un grupo de pruebas adicionales en cuanto a la semántica es para los WebApp que construyen objetos de contenido dinámicos que se crean en tiempo real en base a una base de datos. Para esto se deben observar varios factores: o Pruebas que descubran errores cometidos al traducir la solicitud del en una forma que pueda procesar la DBMS o Pruebas para comprobar errores en la comunicación con la base de datos o Validar que los datos brutos provenientes de la DBMS hacia el servidor y este hacia el cliente estén correctamente formateados para crear los objetos de contenido o Probar el formato y compatibilidad de presentación de los objetos de contenido dinámico al con diferentes configuraciones de ambiente del cliente Estructurales/arquitectura (que se entregue adecuadamente el contenido y la función de la WebApp. Que pueda ser extensible en contenido y funcionalidad) CMS.
Prueba de Interfaz del La verificación y validación de la interfaz del se lo hace en tres puntos del proceso, en el análisis (formulación y análisis de requisitos), en el diseño (al diseñar la interfaz que garantice la calidad) y durante las pruebas donde básicamente se prueban ejecutando la aplicación. Los objetivos que se obtienen con las pruebas de interfaz son: - las características de la interfaz se prueban para asegurar que las reglas del diseño, la estética y el contenido visual relacionado están a disposición del sin error alguno - los mecanismos individuales de la interfaz se prueban en forma unitaria (por ejemplo se prueba html dinámico, cgi, carrito de compras, etc.) - la interfaz se prueba frente cada caso de uso (USN) para descubrir errores de semántica, y facilidad de uso - la interfaz se prueba dentro de una diversidad de ambientes para asegurar su compatibilidad. Pruebas de semántica de la interfaz. Una vez que se ha probado de forma unitaria cada mecanismo de interfaz, se procede con la prueba semántica que evalúa cuan bien el diseño se ocupa de los s, ofreciendo una dirección clara, manteniendo consistencia de lenguaje y enfoque. Para esto se sugiere probar cada caso de uso (categorías de ) versus el diseño de la interfaz para confirmar que no hay errores y si los hubiere como los maneja y su recuperación. Pruebas de compatibilidad. Como sabemos, el puede tener diferentes ambientes (sistemas operativos, navegador, plataformas de hardware), por lo que se debe hacer pruebas de compatibilidad para descubrir errores asociados con un ambiente específico. Para esto se debe definir un conjunto de configuraciones de computadoras cliente más comunes y en función de estas armar las pruebas. Prueba al nivel de Componentes Conocidas como pruebas de función, que intentan descubrir errores en la funcionalidad de la WebApp. Para esto existen algunos métodos de prueba: - Partición de equivalencia. Cuyo dominio de entrada se divide en categorías o clases de entrada y a partir de estos se derivan los casos de prueba. Se hacen pruebas con cada categoría mientras las otras permanecen constantes, por ejemplo en una página que importe el código postal, aquí se hace pruebas posibles con el código postal mientras los otros valores permanecen constantes - Análisis de valores límite. Probar los valores máximos o mínimos de campos o atributos que maneja el componente o la función - Pruebas de ruta. Para comprobar y garantizar que se ha ejercitado toda ruta posible en su funcionamiento. Para cada caso se debe especificar la entrada y salida esperada. Existen circunstancias en las que la funcionalidad es tan extensa que complica probar todas las posibles situaciones, por lo que una sugerencia seria acudir a un análisis de riesgo para obtener los casos de prueba de mayor riesgo, como por ejemplo: - Cual funcionalidad es la mas importante para el propósito - Cuales áreas del sitio amerita más dura interacción con la DB? - Cuales mecanismos específicos (cgi, applets, activex) son los más complejos? - Que tipos de problemas causara la mayoría de las quejas o la peor publicidad? - Que áreas del sitio serán las más populares? - Que partes del sitio tendrán mayores riesgos de seguridad?. Pruebas de Navegación Las pruebas de navegación garantizan que todos los mecanismos que permiten al de la WebApp viajar a través de ella sean funcionales y validar que cada USN pueda ser alcanzado por la categoría de adecuada. La primera prueba de navegación inicia con la prueba de interfaz. Estas pruebas inicialmente son probadas por los Ingenieros Web para luego pasar que prueben los s. Prueba de sintaxis de navegación. Con cada mecanismo de navegación se prueba: vínculos navegación, redirigir (destinos removidos), mapas de sitio, motores de búsqueda. 9
Ingeniería de Software II – Ingeniería Web – Pablo Pintado MBA
Prueba de semántica de navegación. Se deben probar los USN (unidad semántica de navegación). Si no se han hecho los USN en el análisis, se puede tomar los casos de uso para armar casos de prueba de navegación respondiendo a las siguientes preguntas: Pruebas de Configuración En las pruebas de compatibilidad en pruebas de interfaz se probaron solo del lado del cliente, mientras que en estas pruebas de configuración se prueban un conjunto de probables configuraciones de cliente y servidores. Del lado del servidor: - la WebApp es totalmente compatible con el sistema operativo del servidor? - Los archivos de sistema, directorios y datos de sistema relacionados se crean correctamente cuando la WebApp esta operativa? - Las medidas de seguridad del sistema permiten a la WebApp ejecutarse y dar el servicio a los s sin interferencia y a un buen desempeño? - La WebApp se ha probado con la configuración de servidor distribuido (cluster o balanceo de carga)? - La WebApp está integrada adecuadamente con la base de datos (incluyendo diferentes versiones de DB)? - Si se usan proxys, las diferencias en configuraciones se han abordado?. Del lado del cliente: - hardware: u, memoria, dispositivos de impresión, monitor - sistemas operativos: normales y especiales para equipos móviles - software de navegación - componentes de interfaz del : activex, applets java, otros - Plug in: quicktime, realplayer, adobe, otros - Conectividad: cable, dsl, Modem, proxys, otros - Aplicaciones que corren al mismo tiempo. Pruebas de Desempeño Se aplican para descubrir problemas de desempeño que se presentan debido a la falta de recursos en el lado del servidor, ancho de banda de red inapropiada, capacidades inadecuadas de bases de datos, capacidades/defectuosos de sistemas operativos, funcionalidad mal diseñada, u otros conflictos de hardware o software (seguridad) que impidan un buen desempeño. Esto conducirá a comprender como el sistema responde a cierta carga (numero de s activos, numero de transacciones, volumen de datos, etc.) y a poder recolectar métricas para poder modificar el diseño o acoplar soluciones (hardware/software apropiadas) para mejorar el rendimiento. Las pruebas deben responder a las siguientes preguntas: - en qué punto (s, transacciones, carga de datos) el desempeño se vuelve inaceptable? - Que componentes del sistema son responsables de la reducción del desempeño? - Cuál es el tiempo de respuesta promedio para los s en una variedad de condiciones de carga? - Que ocurre cuando se aplican cargas que rebasan la capacidad máxima del servidor?. Para contestar a estas preguntas se hacen las pruebas de desempeño comunes (carga y tensión). Pruebas de carga. Para esta prueba se consideran variables: - N: número de s concurrentes - T: numero de transacciones en línea por por unidad de tiempo - D: la carga de datos procesada por el servidor por transacción. De estas variables el Ingeniero Web obtiene valores promedios aceptables y si en el momento de la prueba encuentra una disminución precipitada de desempeño se debe revisar el porqué. Pruebas de tensión. Es una continuación de la prueba de carga, en donde las variables N, T y D se fuerzan para poder superar los límites operativos. Con esta prueba se responden a las siguientes preguntas: - el sistema se degrada o el servidor se desconecta cuando se rebasa su capacidad? - El software emite mensajes al cliente y al soporte técnico del sitio que se no puede alcanzar el servidor? - El servidor pone en cola las peticiones que no alcanza a resolverlas para ir atendiendo poco a poco como su capacidad lo permita? - Las transacciones se pierden conforme se rebasa los límites? - La integridad de datos se pierde cuando se rebasa los límites? - Si el sistema falla, cuánto tarda en estar en línea de nuevo? - Ciertas funciones del WebApp se descontinúan cuando el servidor llega a sus umbrales (memoria, procesador, disco)?. Una variación de pruebas de tensión son las llamadas pruebas pico, que son las mismas pruebas de tensión pero se lo hace muy repentino llegar o sobrepasar el límite volviendo a la normalidad y luego nuevamente sobrepasando el límite para efectos de poder comprobar cuan bien que el sistema/servidor se recupera regresando a su normalidad.
10
Ingeniería Web antes de comenzar a construir es mejor que se entienda el problema, analice y diseñe una solución factible, se la implemente en una forma sólida y con pruebas amplias. Para este objetivo se debe: - Formular el problema - Planificar - Modelar los requisitos - Diseñar la solución - Construir con tecnología y herramientas especializadas - Evaluación por parte de los s (técnicos, como empresariales). Atributos de las aplicaciones basados en Web (WebApp) Los sistemas basados en Web involucran una mezcla entre publicación impresa y desarrollo de software, entre marketing e informática, entre comunicaciones internas y relaciones externas y entre arte y tecnología. Características: - Intensidad de red (Internet, intranet, extranet) - Concurrencia (gran numero de s tienen al mismo tiempo) - Carga impredecible (el numero de s puede variar de un día a otro) - Desempeño (tiempo en ingreso y navegación) - Disponibilidad (24x7x365) - Gobernada por los datos (proveen gran cantidad de información) - Evolución continua / Inmediatez (la agilidad para poner productos/servicios) - Seguridad (para el manejo transaccional) - Sensibilidad al contenido / Estética / Temporalizable: calidad y naturaleza estética de su contenido - Personalizable (ya sea la propia WebApp o el personaliza su navegación, contenido de acuerdo a sus necesidades específicas) - Soporte (ayuda en línea, grupos de discusión y vínculos relacionados). Proceso de Ingeniería Web Debido a que la Internet cambio la prioridad principal de desarrollo de que a cuando; el proceso debe ser realizado bajo una filosofía de desarrollo ágil, en el cual se incorpora rápidos ciclos de desarrollo. El Marco de trabajo de IWeb debe considerar: adoptar el cambio, aliente la creatividad, construyendo sistemas con pequeños equipos de desarrollo, con un desarrollo evolutivo/incremental, istrar el riesgo y usar cortos ciclos de desarrollo. Se pueden utilizar varios tipos de procesos como XP (programación extrema, MSF (Microsoft solution Framework) o una personalizada ágil IWeb. Comunicación con el cliente - Análisis del negocio (análisis del contexto empresarial-organizativo para la WebApp) o Identifican a los participantes o Predicen potenciales cambios en el ambiente y requisitos o Se definen integración entre la WebApp y otras aplicaciones del negocio, bases de datos - Formulación o Recopilación de requisitos Planeación Se definen tareas y un calendario de plazos, asignando responsables y/o ejecutores. Se define la línea base para efectos de control de cambios Modelado Se mezclan las funciones de análisis y diseño para crear el modelado IWeb. - Análisis de requisitos o Definir el contenido que tendrá la WebApp o Funcionalidad que se presentara al o Modos de interacción de cada clase de al momento de navegar - Diseño o Diseño de contenido/aplicación o Diseño de arquitectura de la información o Diseño de interfase o Diseño de la navegación
1
Ingeniería de Software II – Ingeniería Web – Pablo Pintado MBA
Construcción - Programación de acuerdo al modelado - Pruebas rápidas (contenido, arquitectura, interfase, navegación) Despliegue (entrega y retroalimentación) - configuración para su ambiente operativo - evaluación por parte del - retroalimentación y ajustes. Unido a estos cinco pasos para un proceso incremental debe ir acompañado de los puntos básicos de istración de cambios y riesgos. FORMULACION Y PLANEACION PARA INGENIERIA WEB Dentro del Marco de trabajo de Ingeniería Web se inicia con la formulación y planificación. La Formulación Inicia con la identificación de las necesidades del negocio, exponiendo los objetivos de la WebApp, definiendo grandes características y funciones, recopilando los requisitos que conducen al desarrollo del modelo de análisis. También identifica el ámbito de esfuerzo de desarrollo así como la forma de cómo determinar un resultado exitoso. Si bien en la formulación se deben exponer las grandes necesidades, pero por lo general también se exponen detalles o especificaciones que el cliente y el Ingeniero Web desean hacerlo. Preguntas para la formulación ¿Cuál es la principal motivación (necesidades del negocio) para la WebApp? ¿Cuáles son los objetivos que debe satisfacer la WebApps? ¿Quién usará la WebApp? De esto se podrá ahora especificar metas informativas y aplicativas como: Informativa: “el sitio proporcionara a los s especificaciones de producto detalladas que incluyan descripciones técnicas, instrucciones de instalación y precios.” Aplicativa: “el sitio consultara al acerca de la instalación (casa, oficina) que será protegida y realizara recomendaciones personalizadas acerca del producto y la configuración que se utilizara”. De estas especificaciones se podrán definir perfiles de . Con esto se definirá el ámbito para la WebApp. Recopilación de requisitos para Web Se puede recopilar por medio de una Ingeniería de requisitos común, y si adaptamos a WebApp los objetivos serán: - identificar requisitos de contenido - identificar requisitos funcionales - definir escenarios de interacción para diferentes clases de s. Los pasos para esta recopilación de requisitos: 1. Pedir a los clientes que definan las categorías de y describan cada categoría - Cual es objetivo global del cuando usa la WebApp? - Cuales son los antecedentes y la pericia del en relación al contenido y la funcionalidad de la WebApp? - Que características genéricas de la WebApp le gustan y/o disgustan al ? 2. comunicarse con los clientes para definir los requisitos básicos de la WebApp. Para esta comunicación se usan varios mecanismos como: - grupo muestral tradicional (presencial con un grupo de personas) - entrevistas interactivas (electrónicos, exploración) (desde sitio web o correo electrónico) - construcción de escenarios, a s seleccionados se les pide que describan interacciones específicas con la WebApp. 3. Analizar la información recopilada y utilizar la información para realizar un seguimiento con los clientes - Se debe categorizar en clase de y tipos de transacción - Se debe desarrollar lista de objetos de contenido y las operaciones que se aplican a estos contenidos dentro de una transacción de especifico - Se pide a los s que ordenen como gustaría que se les organizara el contenido y su funcionalidad - Así como también listar las etiquetas que utilizaremos para enlazar a estos contenidos y funciones 4. Definir casos de uso que describan escenarios de interacción para cada clase de (de la jerarquía de s). Se describe como interactúa cada categoría de (actor) con la WebApp para lograr una acción específica. Esto servirá para el análisis y pruebas.
2
Ingeniería de Software II – Ingeniería Web – Pablo Pintado MBA
Planeación En un proyecto IWeb, el equipo de trabajo es multidisciplinario. Dos alternativas al momento de construir una WebApp, un camino es la subcontratación y otro es el desarrollo en casa (in-house). Planeación de WebApp con subcontratación: - Inicio de proyecto Identificar el publico para la WebApp, metas globales, información y servicios que proporcionara la WebApp, se destacan Web competidores, y formas de medir cualitativa y cuantitativa si la web es exitosa Desarrollar internamente un diseño aproximado de la WebApp, identificando el tipo y volumen de contenido, tipos de procesamiento interactivo Elaborar un plan aproximado que incluya las fecha finales y claves Crear una lista de responsabilidades para la organización interna y la subcontratista Identificar el grado de supervisión e interacción de la organización con el subcontratista (definir claramente los os de cada parte) - Selección entre subcontratistas candidatos Comprobar con clientes anteriores sobre el profesionalismo del subcontratista Determinar los nombres de los Ingenieros Web que realizaron con éxito los proyectos Examinar trabajos similares - Coordinar la gestión del proyecto con el subcontratista, aquí deben acordarse tareas, puntos de comprobación e hitos, aseguramiento de calidad, valorar riesgos, control de cambios y métodos de comunicación efectiva - Evaluación del programa del proyecto, debe tener una dosificación de acuerdo al tamaño del proyecto, cuando son cortos los controles llegan a ser hasta diarios - Es importante mencionar que el ámbito podrá cambiar constantemente, por lo que se suele “congelar” o versionar para poder tener entregables. Planeación de WebApp en modalidad in-house: - Entender el ámbito, las dimensiones de cambio y las restricciones del proyecto - Definir la estrategia del proyecto incremental - Desarrollar una estimación rápida, con esto se podrá saber a nivel macro si podrá desarrollarse con recursos disponibles - Establecer un conjunto de tareas (descripción del proceso) - Establecer el plan, incluyendo las tareas antes descritas y estableciendo fechas de entregables - Definir mecanismos de rastreo del proyecto, es poder saber como valorar los entregables (si se completaron). -
-
-
MODELADO DE ANALISIS PARA APLICACIONES WEB que información o contenido se presentará o manipulara? Que funciones realizará el final? Que comportamientos exhibirá la WebApp conforme presente contenido y realice funciones? Requisitos para el análisis de las WebApps Formulación, se identifica la motivación (metas) y objetivos básicos para la WebApp, así como la definición de categoría de s. Recopilación de requisitos, aquí se intensifica la comunicación entre el Ingeniero de Software y los expertos del negocio. Se listan los requisitos de contenido y funcionales; se desarrollan escenarios de iteración (casos de uso). La intención es el resolver el por qué se construirá la WebApp, quien la usará, y que problema resolverá a sus s. Modelado de análisis, luego de la formulación y recopilación de requisitos, se procede con el modelado de contenido, interacción, funcional, configuración y navegación. Modelo de Análisis para las WebApps modelado de Contenido modelado de Interacción (como interactúa el con la WebApp) modelado funcional (operaciones de contenido y de procesamiento) modelado de Configuración (ambiente e infraestructura) análisis relación-navegación
El Modelo de Contenido Este modelo contiene los elementos estructurales que son necesarios para satisfacer los requisitos de contenido de la WebApp, como son las clases de contenido por ejemplo texto, imágenes graficas, fotografías, imágenes video, audio, etc. 3
Ingeniería de Software II – Ingeniería Web – Pablo Pintado MBA
Así como todas las clases de análisis visibles para el que se crean para la interacción con la WebApp. Estas se derivan del análisis gramatical de los casos de uso. El Modelo de Interacción Las WebApp que proveen “conversación” con el final deben ser modelado su interacción por medio de cuatro elementos: - casos de uso (proporcionan una visión unidimensional de la interacción) - diagramas de secuencia: (maneja dos dimensiones) representación abreviada de la forma como interactúa las acciones del con las clases de contenido y análisis - diagramas de estado (tres dimensiones), muestra a más del comportamiento una información acerca de los patrones de navegación potenciales que no proporciona los casos de uso y diagramas de secuencia. - prototipo de interfaz de . Si bien la creación del prototipo de interfaz de es una actividad de diseño, se recomienda hacerlo ya en el análisis (mientras más pronto mejor) porque se pueden obtener requerimientos adicionales al momento que el vea el prototipo El Modelo de Configuración Las WebApps deben ser construidas para que funcionen en una diversidad de ambientes (clientes y servidores), por lo que se deben especificar las características de hardware y software soportados, así como también especificar las interfaces bien definidas y seguras para la interacción con las bases de datos y el resto de aplicaciones de la empresa y asociadas. Análisis relación-navegación Se deben establecer los vínculos apropiados entre los objetos de contenido y las funciones. El ARN (análisis relación navegación) sirve para determinar la estructura de relación de la aplicación (relaciones potenciales en los dominios que pueden implementarse como vínculos más adelante), así como las estructuras de navegación apropiadas sobre estos vínculos, meta-información y navegaciones adicionales. El ARN se organiza en cinco pasos: - análisis de los participantes: identifica las diversas categorías de . - análisis de elementos: se identifica los objetos de contenido y los elementos funcionales. - análisis de relaciones: se describe las relaciones entre elementos WebApp - análisis de navegación: examina como los s pueden acceder a elementos individuales o grupos de elementos - análisis de evaluación: considera temas pragmáticos como por ejemplo: costo/beneficio asociados con la implementación de las relaciones definidas en los dos pasos anteriores. Análisis de navegación. Para definir los requisitos de navegación siempre el debe saber dónde está y a donde va. Se debe considerar los requisitos que dictan como navegara cada categoría de de un elemento a otro. Esto se lo hace al detalle a nivel del diseño, sin embargo, en esta etapa se consideran los requisitos de navegación globales mediante las siguientes preguntas: MODELADO DE DISEÑO PARA APLICACIONES WEB Introducción de diseño En pequeños WebApp deben invertirse poco tiempo en el diseño porque se asume que los WebApp tienen la característica de inmediatez y volatilidad. Sin embargo en WebApp más grandes (más de 100 objetos) deben invertirse más tiempo porque debe aplicarse la calidad al software. Esta calidad de software WebApp cuenta con varios requisitos que deben cumplirse como son: facilidad de uso, funcionalidad, confiabilidad, eficiencia, facilidad de mantenimiento. A estos requisitos les podemos adicionar otros como: seguridad, disponibilidad, escalabilidad. Pirámide del Diseño IWeb. El diseño para Ingeniería Web es una mezcla adecuada de estética, contenido y tecnología que descansa en una pirámide de 6 niveles que son los pasos a seguir en el Diseño.
4
Ingeniería de Software II – Ingeniería Web – Pablo Pintado MBA
Diseño de la interfaz de la WebApp Toda interfaz de debe tener las características: fácil de usar, fácil de aprender (en Web no debería haber capacitación), fácil navegar, intuitiva, consistente, eficiente, libre de errores y funcional; ofreciendo al final una experiencia satisfactoria y gratificante. Los objetivos de una interfaz WebApp son: - establecer una ventana consistente con el contenido y funcionalidad que proporciona - guiar al a través de una serie de interacciones con la WebApp - organizar las opciones de navegación y el contenido disponible para el . El diseño de la interfaz inicia con el desarrollo de las jerarquías de El Ingeniero Web debe diseñar la interfaz de modo que conteste a las siguientes preguntas (conforme navegue el en la Web): - Dónde estoy? o A que se ha tenido o Informar la ubicación en la jerarquía de contenido - Que puedo hacer ahora? o Indicar sus opciones actuales (funciones disponibles, vínculos vivos, contenido relevante) - Donde he estado, a donde voy? o Facilitar la navegación o Facilitar un mapa (implementado de forma fácil de entender). Principios del diseño de la interfaz. Las interfaces efectivas son comprensibles y ofrecen al una sensación de control. No preocupa al final de trabajos internos (le es transparente), así como realizan el máximo trabajo mientras demandan un mínimo de información a los s. Con la finalidad de cumplir con esto se plantean los siguientes principios: - Anticipación, Comunicación , Consistencia , Autonomía, Eficiencia, Flexibilidad, Ley de Fitt, Objetos de interfaz humana, Reducción de latencia, Facilidad de aprendizaje, Metáforas, Mantener la integridad del producto de trabajo, Legibilidad, Estado de rastro, Navegación visible, Rapidez de lectura, Evitar signos de construcción, Los s prefieren no desplazarse, Menús de navegación y los encabezados deben estar diseñados de manera consistente, La estética no debe sustituir la funcionalidad, Opciones de navegación deben ser obvias Flujo de trabajo para el diseño de la interfaz: 1. revisar la información contenida en el modelo de análisis y refinarla conforme se requiera 2. desarrollar el bosquejo de la plantilla de la interfaz de la WebApp 3. correlacionar los objetivos del con acciones especificas de la interfaz 4. Definir un conjunto de tareas de que estén asociadas con cada acción. (cada acción del por ejemplo comprar un producto está relacionado con un conjunto de tareas que fueron identificadas en el análisis y ahora en el diseño se las correlaciona su interacción para identificar asuntos de navegación, objetos de contenido y funciones) 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 diseño estético (con la ayuda del diseñador grafico) 7. Identificar los objetos de la interfaz del que se requieran para implementarla 8. Desarrollar una representación de procedimiento (comportamiento) de la interacción del con la interfaz (es opcional, se puede representar con UML: diagramas de secuencia, actividad y de estado)
5
Ingeniería de Software II – Ingeniería Web – Pablo Pintado MBA
9.
Describir la plantilla de la interfaz para cada estado (es opcional, si realizo el paso 8, en función del paso 2 y 5 se debe especificar las plantillas para cada estado) 10. Refinar y revisar el modelo de diseño de la interfaz (revisar toda la interfaz para confirmar que exista consistencia y por sobre todo facilidad de uso). Diseño Estético (gráfico) También conocido como diseño grafico, debe ser hecho por un “artista” o especialista en diseño grafico. Para realizar esta fase se debe regresar a la jerarquía de s desarrollado en el análisis, preguntando quienes son los s de la WebApp y que “apariencia” desean. No existen reglas absolutas para el diseño de plantillas, sin embargo se enumeran los siguientes lineamientos generales: - no temerle al espacio vació - resaltar el contenido, (el 80% debe ser contenido y el resto para la navegación y otras características) - Organizar los elementos de plantilla de arriba a la izquierda hacia abajo a la derecha (la mayor prioridad se la coloca a arriba a la izquierda) - Agrupar navegación, contenido y función geográficamente dentro la pagina (los humanos buscamos patrones virtualmente en todas las cosas, por lo que se debe conservarse un orden, porque caso contrario el tendrá una frustración en la búsqueda de información) - Preferible no permitir el uso de la barra de desplazamiento (la de arriba hacia abajo, y mucho menos la de izquierda a derecha) - Considerar la resolución y el tamaño de la ventana de navegador cuando se diseñe la plantilla (1280x800) - Los medios audiovisuales (imágenes, video, sonido) utilizados deben ser de lo más liviano posible para evitar paginas lentas (considerar la realidad del servicio de Internet de la región del ). Diseño de Contenido Se enfoca desde dos puntos de vista: - del Ingeniero Web que diseña los objetos de contenido y sus relaciones - del diseñador grafico o publicista que se ocupa de la representación de la información del objeto de contenido. Luego del modelo de contenido en el análisis que se especificaron ciertos atributos de las clases de contenido, se procede con la inserción de atributos específicos de implementación propios del diseño. Una vez que se detallan todos los objetos de contenido se deben diseñar la parte estética (apariencia y percepción adecuada), así como se debe estructurar el numero de objetos que se insertaran en una página web conforme las necesidades del y las restricciones impuestas por rapidez en descarga y conexiones de Internet. Diseño Arquitectónico El diseñador arquitectónico debe identificar la arquitectura de contenido (como se estructura los objetos de contenido para su presentación y navegación) y arquitectura de WebApp (la estructuración de la aplicación para gestionar la interacción con el , manejo de tareas internas, efectuar navegación y presentar el contenido). Arquitectura de Contenido Se centra en la definición de la estructura hipermedia global de la WebApp. - Estructura lineal. Cuando existe una secuencia predecible de interacciones (con alguna variación o desviación). - Estructura en retícula. Cuando el contenido está organizado categóricamente en dos o más dimensiones. - Estructura jerárquica. Son las más comunes, en donde su flujo de control es vertical por medio de las ramificaciones verticales, pero adicionalmente pueden tener control (flujo) horizontal por medio de ramificaciones de hipertexto pudiendo pasarse de una rama a otra directamente, sin embargo hay que tener cuidado con esta funcional adicional porque pueden causar confusión al . - Estructura en red. Denominada “Web pura”, está diseñado para poder navegar por medio de vínculos de hipertexto virtualmente a cualquier pagina del sistema, este enfoque es el más flexible pero al mismo tiempo puede ser el más confuso. Arquitectura de WebApp Aquí se describe la infraestructura que va a tener la solución WebApp. Existe una variedad de formas de diseñar esta arquitectura/infraestructura, sin embargo todas llevan el concepto de “multicapa”, que separan el manejo de la interfaz , navegación, comportamiento de la aplicación y de los datos. La arquitectura MVC Modelo-Vista-Controlador es usada por varias soluciones WebApp, que desacopla la interfaz del de la funcionalidad WebApp y del contenido de la información. - Modelo: el contenido de la aplicación y la lógica de procesamiento, desde aquí se acceden a los datos - Vista: contiene las funciones especificas de la interfaz - Controlador: gestiona el al modelo y vista y coordina el flujo entre ellos.
6
Ingeniería de Software II – Ingeniería Web – Pablo Pintado MBA
Otra de las alternativas de arquitectura es basada en el concepto de “multicanal” llamada Arquitectura Middleware, en donde igualmente está separado la interfaz , de las reglas del negocio y datos, pero aquí ya no solo se diseña pensando en un único front-end Web sino mas bien en varios canales que pueda proveer el servicio (Web, ATM, Celular, Kiosco, PDA, etc.). La capa Middleware contiene manejo de interfaces, las reglas de negocio, el control de flujo, a datos y otros sistemas; bajo el concepto de reutilización por todos los canales. Diseño Navegación Una vez establecido la arquitectura de la WebApp, se diseña las rutas de navegación que utilizaran los s al acceder al contenido y las funciones WebApp. Para esto se debe tomar en cuenta la semántica y sintaxis de la navegación. Semántica de Navegación: identificar la semántica “sentido” de navegación para los diferentes tipos de s, esto se lo toma de las categorías de y se desarrolla un USN (Unidades Semánticas de Navegación) para cada caso de uso, en estos USN se describen los requisitos de navegación, aquí se muestra como el actor se mueve entre los objetos de contenido y la funcionalidad WebApp. Sintaxis de Navegación: se define la “mecánica” de navegación, teniendo varias opciones como: - vinculo de navegación individual: que son vínculos basados en texto, iconos, botones y metáforas graficas - Barra de navegación horizontal: la lista de principales categorías de contenido o funcionales en una barra (de cuatro a siete categorías) - Columna de navegación vertical: similar a la horizontal con la particularidad que al momento de seleccionar una puede expandir a subcontenidos en forma de árbol - Pestañas: es una variación de la de barra o columna pero que dan la sensación de marca - Mapas de sitio: proporciona una tabla de contenido incluyente para la navegación hacia todos los contenidos y funcionalidad de la WebApp. En la mayoría de casos se elige navegaciones horizontales o verticales pero no ambas a la vez. Diseño a nivel de Componentes El diseño de componentes para WebApp se los hace de manera similar que para los sistemas convencionales orientados a objetos (sensibles al cambio y reducen la propagación de efectos secundarios cuando ocurren cambios), pues estos varían más bien por su ambiente de implementación y marcos de trabajo. Estos componentes deben ser diseñados bajo los principios: - Principio de Abierto Cerrado (PAC). Debe estar abierto para extensión pero cerrado para modificación. - Principio de Sustitución de Liskov (PSL). Permita al componente seguir funcionando si se cambia el uso de clase principal a una clase derivada, esto exige que toda subclase se apegue al contrato de la superclase. - Principio de Segregación de la Interfaz (PSI). Es mejor tener muchas interfaces específicas del cliente que una interfaz de propósito general. Es decir, no se debe tener una sola interfaz que tengan una variedad de funcionalidad que los diferentes tipo de cliente ocupan solo una parte de ella. - Principio de Equivalencia entre Reutilización y Versión (PER). Agrupar las clases reutilizables en paquetes que pueden manejarse y controlarse a medida que evolucionan nuevas versiones. Este principio va relacionado también con el principio que las clases que no se reutilizan juntas no deben agruparse juntas. - Principio del Cierre Común (PCC): las clases que cambien juntas deben permanecer juntas. Para esto deben juntarse clases que atiendan la misma área de función o comportamiento. Métricas de diseño para WebApp Las métricas de diseño deben ser creadas para facilitar al Ingeniero Web para medir la calidad de una forma cuantitativa/cualitativa, debiendo responder a las siguientes preguntas: - La interfaz del promueve la facilidad de uso? - La estética de la WebApp es apropiada para el dominio de la aplicación y confortable para el ? - El contenido está diseñado en una forma que proporciona la mayor información con el menor esfuerzo? - La navegación es eficiente y directa? - La arquitectura de la WebApp se ha diseñado para acomodar las metas y objetivos de los s, la estructura de contenido y funcionalidad y flujo de navegación requerido para usar el sistema de manera efectiva? - Los componentes están diseñados en una forma que reduce la complejidad de procedimientos y aumenta la confiabilidad y el desempeño?. PRUEBAS EN APLICACIONES WEB Como en todo software desarrollado, debe aplicarse un plan de pruebas desde el inicio y no esperar al final del proyecto para detectar errores. Es así que metodologías de proyectos como MSF tienen dentro de su planificación general del
7
Ingeniería de Software II – Ingeniería Web – Pablo Pintado MBA
proyecto un punto dedicado a la planeación de pruebas para poder preparar los ambientes y personal adecuado para las pruebas que por cierto son de diferentes tipos. - el contenido: evaluación sintáctica (ortografía y gramática de contenido) y semántica (exactitud de la información presentada y consistencia entre objetos de contenido y objetos relacionados) - la función: comprobar la concordancia con los requisitos del cliente - estructura: se comprueba que se entregue adecuadamente el contenido y la funcionalidad de la WebApp. - facilidad de uso: para cada categoría de , que va relacionado con la sintaxis y semántica de la navegación - navegabilidad: comprobar la sintaxis y semántica de navegación así como comprobar que esté controlado todo flujo, por ejemplo: vínculos rotos, vínculos inadecuados, etc.) - desempeño: se prueba en una diversidad de condiciones operativas, configuraciones, y cargas para saber que el software responde adecuadamente a cargas extremas - compatibilidad: se comprueba que la WebApp funciona en varias configuraciones huésped tanto del lado del cliente como del servidor e infraestructura de seguridad - interoperabilidad: se prueba para asegurar que la WebApp realiza interfaces adecuadas con otras aplicaciones y/o bases de datos, y que estas sean con un buen desempeño - seguridad: se prueba la vulnerabilidad potencial. Estrategias de Pruebas 1. revisar el modelo de contenido (sintáctica y semántica) 2. revisar el modelo de interfaz para confirmar que todos los casos de uso se pueden acomodar 3. revisar el modelo de diseño para descubrir errores de navegación 4. revisar la interfaz del para descubrir errores en la presentación o en los mecanismos de navegación 5. se prueban los componentes funcionales de forma individual (se cambia el concepto de unidad que en orientado a objetos era la clase ahora es la pagina Web que tiene encapsulado contenido, vínculos, procesamiento, etc. Así como también la unidad pueda ser un componente funcional. Es importante de igual manera se debe hacer pruebas de integración entre componentes). 6. se prueba la navegación a través de toda la arquitectura, para esto se aplica los casos de uso que se prueban contra el diseño de la navegación (USN) y luego con la aplicación en si 7. se prueba en diversas configuraciones ambientales para comprobar su compatibilidad. Se crea una matriz de referencia cruzada que define todos los probables sistemas operativos, navegador, plataformas de hardware y protocolos de comunicación. 8. se realizan pruebas de seguridad con el objetivo de encontrar vulnerabilidades 9. se hacen pruebas de desempeño para valorar como afecta el aumento del tráfico, que características de uso provocan degradación, cuales son los componentes responsables de la degradación y como esta degradación afecta a los objetivos y requisitos globales de la WebApp 10. se prueba la WebApp en una porción de población controlada y monitoreada de s finales. Los resultados de esta prueba servirán para mejorar la interacción, errores de contenido, navegación, facilidad de uso, compatibilidad, confiabilidad y desempeño de la WebApp. Se debe hacer un plan de pruebas que por lo general se definen en el planeamiento general del proyecto, en este plan se identifican: - tipo y objetivo de pruebas aplicar, - tareas que se aplicaran en la prueba, - la forma en la que se evaluara los resultados de las pruebas (métricas, valoración, niveles o puntuación). -
Prueba de Contenido sintáctica (ortografía y gramática de contenido) semántica (exactitud de la información presentada y consistencia entre objetos de contenido y objetos relacionados). Esta evaluación que se hace para cada objeto de contenido debe el examinador responder a las siguiente preguntas: o la información realmente es precisa (concisa y exacta)? o la plantilla del objeto de contenido es fácil de entender para el ? o La información anidada en un objeto de contenido se encuentra con facilidad? o La información presentada internamente es consistente con la información de otros objetos de contenido? o El contenido es ofensivo, engañoso o abre la puerta a pleitos? o El contenido infringe derechos de autor o marcas registradas? o El estilo estético del contenido entra en conflicto con el estilo estético de la interfaz global?
8
Ingeniería de Software II – Ingeniería Web – Pablo Pintado MBA
-
Un grupo de pruebas adicionales en cuanto a la semántica es para los WebApp que construyen objetos de contenido dinámicos que se crean en tiempo real en base a una base de datos. Para esto se deben observar varios factores: o Pruebas que descubran errores cometidos al traducir la solicitud del en una forma que pueda procesar la DBMS o Pruebas para comprobar errores en la comunicación con la base de datos o Validar que los datos brutos provenientes de la DBMS hacia el servidor y este hacia el cliente estén correctamente formateados para crear los objetos de contenido o Probar el formato y compatibilidad de presentación de los objetos de contenido dinámico al con diferentes configuraciones de ambiente del cliente Estructurales/arquitectura (que se entregue adecuadamente el contenido y la función de la WebApp. Que pueda ser extensible en contenido y funcionalidad) CMS.
Prueba de Interfaz del La verificación y validación de la interfaz del se lo hace en tres puntos del proceso, en el análisis (formulación y análisis de requisitos), en el diseño (al diseñar la interfaz que garantice la calidad) y durante las pruebas donde básicamente se prueban ejecutando la aplicación. Los objetivos que se obtienen con las pruebas de interfaz son: - las características de la interfaz se prueban para asegurar que las reglas del diseño, la estética y el contenido visual relacionado están a disposición del sin error alguno - los mecanismos individuales de la interfaz se prueban en forma unitaria (por ejemplo se prueba html dinámico, cgi, carrito de compras, etc.) - la interfaz se prueba frente cada caso de uso (USN) para descubrir errores de semántica, y facilidad de uso - la interfaz se prueba dentro de una diversidad de ambientes para asegurar su compatibilidad. Pruebas de semántica de la interfaz. Una vez que se ha probado de forma unitaria cada mecanismo de interfaz, se procede con la prueba semántica que evalúa cuan bien el diseño se ocupa de los s, ofreciendo una dirección clara, manteniendo consistencia de lenguaje y enfoque. Para esto se sugiere probar cada caso de uso (categorías de ) versus el diseño de la interfaz para confirmar que no hay errores y si los hubiere como los maneja y su recuperación. Pruebas de compatibilidad. Como sabemos, el puede tener diferentes ambientes (sistemas operativos, navegador, plataformas de hardware), por lo que se debe hacer pruebas de compatibilidad para descubrir errores asociados con un ambiente específico. Para esto se debe definir un conjunto de configuraciones de computadoras cliente más comunes y en función de estas armar las pruebas. Prueba al nivel de Componentes Conocidas como pruebas de función, que intentan descubrir errores en la funcionalidad de la WebApp. Para esto existen algunos métodos de prueba: - Partición de equivalencia. Cuyo dominio de entrada se divide en categorías o clases de entrada y a partir de estos se derivan los casos de prueba. Se hacen pruebas con cada categoría mientras las otras permanecen constantes, por ejemplo en una página que importe el código postal, aquí se hace pruebas posibles con el código postal mientras los otros valores permanecen constantes - Análisis de valores límite. Probar los valores máximos o mínimos de campos o atributos que maneja el componente o la función - Pruebas de ruta. Para comprobar y garantizar que se ha ejercitado toda ruta posible en su funcionamiento. Para cada caso se debe especificar la entrada y salida esperada. Existen circunstancias en las que la funcionalidad es tan extensa que complica probar todas las posibles situaciones, por lo que una sugerencia seria acudir a un análisis de riesgo para obtener los casos de prueba de mayor riesgo, como por ejemplo: - Cual funcionalidad es la mas importante para el propósito - Cuales áreas del sitio amerita más dura interacción con la DB? - Cuales mecanismos específicos (cgi, applets, activex) son los más complejos? - Que tipos de problemas causara la mayoría de las quejas o la peor publicidad? - Que áreas del sitio serán las más populares? - Que partes del sitio tendrán mayores riesgos de seguridad?. Pruebas de Navegación Las pruebas de navegación garantizan que todos los mecanismos que permiten al de la WebApp viajar a través de ella sean funcionales y validar que cada USN pueda ser alcanzado por la categoría de adecuada. La primera prueba de navegación inicia con la prueba de interfaz. Estas pruebas inicialmente son probadas por los Ingenieros Web para luego pasar que prueben los s. Prueba de sintaxis de navegación. Con cada mecanismo de navegación se prueba: vínculos navegación, redirigir (destinos removidos), mapas de sitio, motores de búsqueda. 9
Ingeniería de Software II – Ingeniería Web – Pablo Pintado MBA
Prueba de semántica de navegación. Se deben probar los USN (unidad semántica de navegación). Si no se han hecho los USN en el análisis, se puede tomar los casos de uso para armar casos de prueba de navegación respondiendo a las siguientes preguntas: Pruebas de Configuración En las pruebas de compatibilidad en pruebas de interfaz se probaron solo del lado del cliente, mientras que en estas pruebas de configuración se prueban un conjunto de probables configuraciones de cliente y servidores. Del lado del servidor: - la WebApp es totalmente compatible con el sistema operativo del servidor? - Los archivos de sistema, directorios y datos de sistema relacionados se crean correctamente cuando la WebApp esta operativa? - Las medidas de seguridad del sistema permiten a la WebApp ejecutarse y dar el servicio a los s sin interferencia y a un buen desempeño? - La WebApp se ha probado con la configuración de servidor distribuido (cluster o balanceo de carga)? - La WebApp está integrada adecuadamente con la base de datos (incluyendo diferentes versiones de DB)? - Si se usan proxys, las diferencias en configuraciones se han abordado?. Del lado del cliente: - hardware: u, memoria, dispositivos de impresión, monitor - sistemas operativos: normales y especiales para equipos móviles - software de navegación - componentes de interfaz del : activex, applets java, otros - Plug in: quicktime, realplayer, adobe, otros - Conectividad: cable, dsl, Modem, proxys, otros - Aplicaciones que corren al mismo tiempo. Pruebas de Desempeño Se aplican para descubrir problemas de desempeño que se presentan debido a la falta de recursos en el lado del servidor, ancho de banda de red inapropiada, capacidades inadecuadas de bases de datos, capacidades/defectuosos de sistemas operativos, funcionalidad mal diseñada, u otros conflictos de hardware o software (seguridad) que impidan un buen desempeño. Esto conducirá a comprender como el sistema responde a cierta carga (numero de s activos, numero de transacciones, volumen de datos, etc.) y a poder recolectar métricas para poder modificar el diseño o acoplar soluciones (hardware/software apropiadas) para mejorar el rendimiento. Las pruebas deben responder a las siguientes preguntas: - en qué punto (s, transacciones, carga de datos) el desempeño se vuelve inaceptable? - Que componentes del sistema son responsables de la reducción del desempeño? - Cuál es el tiempo de respuesta promedio para los s en una variedad de condiciones de carga? - Que ocurre cuando se aplican cargas que rebasan la capacidad máxima del servidor?. Para contestar a estas preguntas se hacen las pruebas de desempeño comunes (carga y tensión). Pruebas de carga. Para esta prueba se consideran variables: - N: número de s concurrentes - T: numero de transacciones en línea por por unidad de tiempo - D: la carga de datos procesada por el servidor por transacción. De estas variables el Ingeniero Web obtiene valores promedios aceptables y si en el momento de la prueba encuentra una disminución precipitada de desempeño se debe revisar el porqué. Pruebas de tensión. Es una continuación de la prueba de carga, en donde las variables N, T y D se fuerzan para poder superar los límites operativos. Con esta prueba se responden a las siguientes preguntas: - el sistema se degrada o el servidor se desconecta cuando se rebasa su capacidad? - El software emite mensajes al cliente y al soporte técnico del sitio que se no puede alcanzar el servidor? - El servidor pone en cola las peticiones que no alcanza a resolverlas para ir atendiendo poco a poco como su capacidad lo permita? - Las transacciones se pierden conforme se rebasa los límites? - La integridad de datos se pierde cuando se rebasa los límites? - Si el sistema falla, cuánto tarda en estar en línea de nuevo? - Ciertas funciones del WebApp se descontinúan cuando el servidor llega a sus umbrales (memoria, procesador, disco)?. Una variación de pruebas de tensión son las llamadas pruebas pico, que son las mismas pruebas de tensión pero se lo hace muy repentino llegar o sobrepasar el límite volviendo a la normalidad y luego nuevamente sobrepasando el límite para efectos de poder comprobar cuan bien que el sistema/servidor se recupera regresando a su normalidad.
10
Related Documents 3h463d
Ingenieria Web Resumen 39221e
September 2020 0
Ingenieria Web 2v124m
August 2020 0
Ingenieria Web 2v124m
November 2020 0
Resumen Ingenieria Financiera 4yvr
March 2021 0
Resumen Ingenieria Industrial 45295a
April 2022 0
Resumen Pagina Web 5u1a2k
December 2019 29More Documents from "Carlos Delgado" 1o6d2t
Bellos Cabellos 5iq6i
April 2022 0
Mahieu, Juegos A La Hora De La Siesta 4w1b6a
December 2019 85
Lista De Precios Ensayos Geo Gestion 53f9
May 2022 0
Ingenieria Web Resumen 39221e
September 2020 0
Camilo Echeverry Correa 2c4y7
January 2023 0