Un hombre con una idea nueva es un loco hasta que la idea triunfa
Mark Twain


Construcción de Aplicaciones
Plataforma Internet
Enfoque y Metodología de DocIRS
José Enrique González Cornejo

 

El artículo trata acerca de la metodología de construcción de aplicaciones en plataforma Internet, que ha ido adquiriendo y consolidando DocIRS, a lo largo de más de 22 años. DocIRS tiene la fortaleza de configurar robusta y rápidamente un sistema computacional de control y seguimiento, centralizado en una base de datos sobre Internet, a partir de sus librerías y método (Simple-DocIRS). El enfoque de DocIRS es la comunicación efectiva de los protagonistas del sistema, con una constante innovación del producto y dedicación al negocio del cliente. La presente metodología está en directa correlación con la metodología general de procesos de DocIRS y sus procedimientos de entendimiento y acuerdos. El documento se ha estructurado mediante de 18 capítulos, con temas que abarcan temas desde el Diseño Conceptual hasta la Mantención y Seguimiento. El accesos a los capítulo se puede realizar mediante el Índice.


I. Introducción

El logro de los propósitos de la puesta en producción de una aplicación Web tiene por objetivo la solución y plena satisfacción de un cliente final. Este logro, - según nuestra experiencia -, se alcanza enmarcado en la metodología Simple-DocIRS, su estrategia de desarrollo y en los lineamientos que intentaremos describir a continuación.

Los factores o atributos de calidad de una aplicación sobre plataforma Internet que explican la satisfacción del cliente, son aquellos relacionados con:

i)  La especificidad (pertinencia y significación para el negocio del cliente);

ii) La calidad y utilidad de los contenidos ( Ver Acerca de la Calidad de una Aplicación);

iii) La calidad del servicio y asistencia al cliente; (Ver Soporte y Modelo de Atención de DocIRS)

iv) La calidad del diseño de la aplicación.(Ver Síntesis gráfica de la Metodología General de DocIRS)

La importancia del diseño de la aplicación, se basa en que éste será el que materialice el modelamiento y diseño funcional realizado para la solución del problema. El diseño siempre finaliza con la interacción entre usuario y la aplicación, y por tanto la herramienta es la que posibilita el logro de los objetivos esperados  por el cliente.


 Ejemplo:

Un Gerente de Proyecto desea controlar el estado de sus proyectos u otra acción de monitoreo y seguimiento. Requiere almacenar y recuperar  información desde diferentes puntos remotos, desde una base de datos centralizada  que opere sobre plataforma Internet.

Le interesa verificar en línea el cumplimientos de compromisos intermedios y finales, metas, fechas, complicaciones, variables no contempladas, documentación que se ha ido generando, etc.

Está demostrado, que la Carta Gantt no es suficiente para controlar este objetivo en forma certera, dado que es una interpretación inicial estática de los que va a pasar. Especialmente cuando se involucran múltiples proyectos, subproyectos, hitos y diversas áreas.

Luego, ¿Que funcionalidad se debe incorporar para suplir esa necesidad? Respuesta: comunicación PMOy comunicación efectivamediante una aplicación  de carácter PMO (Project Management Office)

Es decir, funcionalidades que capturen y comuniquen las evidencia de lo qué está pasando a causa del carácter dinámico y de permanentes cambios de las actividades. Por tanto, el correcto diseño de la aplicación, no sólo debe contener las fichas y datos de actualización, sino que también un sistema de comunicación de alertas, registro de versiones, consignación de compromisos, entregables y mensajería, a fin que el cliente consiga su objetivo. 

Conclusión: El constructor debe comprender el requerimiento e implementar una solución que responda a las necesidades del cliente.

Ver Proyectos Importantes Realizados
 

De ahí que, es necesario construir un diseño pertinente y robusto que sea comprensible, de fácil uso, amigable, claro, intuitivo y con estándares de simple aprendizaje para el cliente.

En general los estándares ya están aprendidos, dado que actualmente son universales y están definidos por los objetos simples que se utilizan en todos los browser.

A fin de poder asegurar que un diseño que cumpla con estos requisitos, no basta simplemente con un levantamiento y diseño regido por las normas tradicionales (Diagramas, UML, descripción de procesos), es imprescindible el entendimiento del equipo de Procesos con el cliente, la comunicación con el equipo de Desarrollo, la adopción de técnicas, procedimientos y métodos que aseguren empíricamente la adecuación del diseño a las necesidades, habilidades y objetivos del usuario. (Ver Protocolo DocIRS)

Bajo esta línea de trabajo, DocIRS ha ido aprendiendo, adoptando y abordando formas de cómo diseñar aplicaciones Web usables y accesibles a través de la aplicación. Esta metodología, más empírica que teórica, ha convergido en lo que podría definirse hoy como Diseño Centrado en el Usuario. La historia de nuestros trabajos que se iniciaron con Programación Extrema (Levantábamos requerimientos mientras desarrollábamos, lo que nos trajo innumerables problemas y pérdidas, pero que nos enseñó en la práctica, la necesidad de planificar, documentar, comunicar el entendimiento, y construir prototipos previos).

El objetivo de DocIRS cuando se construye una aplicación Web centrada en el cliente, es alcanzar a través de ella un servicio integral. Este se resume en el siguiente diagrama de contexto.

II. Usabilidad y Accesibilidad

DocIRS, está certificado ISO 9001:2008, utiliza el concepto que define usabilidad como el "grado de eficacia, eficiencia y satisfacción con la que usuarios pueden lograr objetivos específicos, dentro de un contexto de uso".

De donde se distinguen dos tipos de atributos

i) Cuantificables de forma objetiva: Son aquellos que asociados a la eficacia o número de errores cometidos por el usuario ,durante la realización de una tarea, y eficiencia o tiempo empleado por el usuario para la consecución de una tarea. (Estos datos pueden ser capturados en un LOG que está inserto en validación de sesión de cada formulario)

ii) Cuantificables de forma subjetiva: Son aquellos recogidos desde la percepción del cliente, en encuestas, cuestionarios, focus-Group  tales como la satisfacción de uso.

Por tanto, la definición acerca de la usabilidad de una aplicación debe ser entendida siempre en relación con la forma y condiciones de uso por parte de sus usuarios, así como con las características y necesidades propias de ellos. Un diseño no es en sí mismo usable: "lo es para clientes específicos en contextos de uso específicos".(ó Pertinencia y Significación)

La orientación de DocIRS en la construcción de software no es genérica, es decir, no intenta que una aplicación Web sea usable independientemente de quién y cómo la use.

La dirección y experiencia de DocIRS es práctica, y directamente relacionada a los requerimientos específicos del cliente, cuya solución no está cubierta  en el mercado. Por eso  normalmente todas nuestras aplicaciones se diseñan con la intención de satisfacer las necesidades de una audiencia concreta y determinada, por lo que será más usable cuanto más adaptado esté su diseño a esta audiencia específica. (Ver Video Entrevista UCV y Modelo de Atención)

Directamente relacionado a este concepto, se sitúan la funcionalidades de acceso y la navegación, las cuales se refieren a la posibilidad de acceso. En concreto, a que el diseño, como prerrequisito imprescindible para ser usable, posibilite el acceso a todos sus potenciales clientes, sin exclusiones pero con los atributos y privilegios pertinentes. A este efecto, se construye matriz de perfiles [Usuario x Privilegios] que es consultada en el instante de la autenticación ver Capitulo XIV. Normas de Seguridad de la Aplicación Web

Un diseño usable requiere delimitar su audiencia potencial, con lo perfiles necesarios, con la diversidad y heterogeneidad de necesidades de acceso presentadas por estos clientes específicos.

III. Arquitectura

La mayoría de los clientes interactúa mediante la interfaz de la aplicación. Sin embargo, el uso de la aplicación depende no sólo del diseño de la interfaz, sino también de su arquitectura - estructura y organización - en otras palabras, del componente no visible del diseño. Efectivamente, la estructura interna de un sistema o su arquitectura (no visible completamente para el usuario) tiene una gran influencia en la forma de utilización del sistema.

Nuestro enfoque en cuanto a la arquitectura de las aplicaciones (ver Arquitectura en Capas) se basa fundamentalmente en lograr eficientemente el almacenamiento y recuperación de datos, cuyos espacios y rotulación sean apropiados para su flexibilidad futura. Es decir, definir una correcta arquitectura de información es facilitar al usuario la recuperación de información. Esto se consigue por un lado posibilitando que el usuario pueda encontrar respuesta oportuna y exacta (disminuir el área de incertidumbre del usuario). Este objetivo se logra a través del diseño y esquemas de interpretación (definición de índices, clasificaciones, buscador, integración con otros sistemas y  exportabilidad de los datos desde el sitio, etc..). En este caso, construir sistemas que generen mapas de navegación  automáticos y pertinentes juega un rol crucial de intérprete en el proceso de respuesta, con libertad al usuario en sus desplazamientos, fomento de la creatividad e integración de conocimiento. (Ver Herramientas de Navegación)

IV. Diseño Web para el Cliente

Para asegurar empíricamente que una aplicación sobre un sitio cumpla con los niveles de uso requeridos, el diseñador necesita de una metodología, de técnicas y procedimientos ideados para tal fin.

Asumiremos que todo el proceso de diseño y desarrollo del sitio Web debe estar conducido por el usuario, sus necesidades, características y objetivos.

Centrar el diseño en sus clientes (en oposición a centrarlo en las posibilidades tecnológicas o interpretaciones propias) implica involucrar desde el comienzo a los clientes en el proceso de desarrollo del sitio; conocer cómo son, qué necesitan, para qué usan el sitio; testar el sitio con los propios clientes; investigar cómo reaccionan ante el diseño, cómo es su experiencia de uso; e innovar siempre con el objetivo claro de mejorar la experiencia del usuario.  (Ver RobotDocIRS : que es una herramienta construida para cumplir con dichos objetivos de prototipo instantáneo que es como una onda transversal a todas las fases del proyecto de automatización, lo que transforma una metodología plana y lineal de documentación UML, en un método experimental que deja exactamente documentado, comunicado y especificado el sistema para los constructores. Ver Metodología DocIRS)

Como indica el esquema, la fase de Modelamiento, cuenta con dos grandes actividades. Definición del Proyecto y Construcción del Prototipo en un proceso cíclico e iterativo. Esto quiere decir que todo lo que se diseñe debe ser constantemente evaluado a través del resultado, para así poder corregir errores de usabilidad desde los primeros momentos del desarrollo. Evaluar el sitio Web únicamente una vez finalizado su desarrollo haría mucho más costosa la reparación de errores, ya que siempre es más económico reconducir un diseño que rediseñar completamente el sitio.

Fase I – Modelamiento: En esta fase se realiza la definición del proyecto, el levantamiento de procesos, el rediseño, el diseño de aplicaciones, el plan de implementación.

Fase II – Implementación: En esta segunda fase se realiza la construcción de las aplicaciones para el plan piloto y su implementación.

Fase III – Plan Piloto: La última fase consiste en desarrollar el plan piloto, medir los resultados de éste y realizar las mejoras a los rediseños para su posterior implementación masiva.

V. Planificación

Todo proyecto debe comenzar por una correcta planificación. En esta etapa se identifican los objetivos del sitio, así como las necesidades, requerimientos y objetivos del Cliente.

Confrontando esta información se definen los requerimientos del sitio Web, entre los que podemos contar requerimientos técnicos (back-end y front-end), recursos humanos y perfiles profesionales necesarios, y adecuación del presupuesto disponible.

Se trata, pues, de establecer un equilibrio entre lo que puede ofertar por parte de DocIRS y lo que requiere el Cliente. El sitio Web - sus contenidos y diseño - debe cumplir precisamente este cometido: servir de medio para la consecución de objetivos por parte de ambas partes.

Aquí lo importante es obtener información precisa, las necesidades y objetivos del cliente. Qué necesita, Cuáles son sus objetivos, Cómo se comporta y actúa, Cuál será el contexto de uso y Cómo afectará a la interacción, experiencia y conocimientos previos.

La respuesta a estas preguntas se resuelve estudiando los usuarios a través de métodos de levantamiento. Éstos engloban métodos de aproximación contextual, estudios de campo, métodos de aproximación por grupos y métodos de aproximación individual (encuestas, cuestionarios y entrevistas). Cuanto más conozcamos al cliente, más adaptado será el diseño y más satisfactoria la experiencia del usuario final.

Es decir, entendemos la planificación como la interpretación modular de las metas requeridas en un proceso de negocio del cliente. Metas que deberán tomar forma y automatizarse en un sistema computacional orientado al objeto, de modo de minimizar los efectos secundarios en las partes del sistema.  Esto implica las siguientes etapas:

i) Fragmentación de la información, partición en formularios o páginas. (Ver Programación con Diseño Modular o Top-Down)

ii) Definición de las relaciones entre las particiones de información.

iii) Definición de los enlaces, nodos o hipervínculos que establecerán los recorridos potenciales del cliente a través del sistema.

Teniendo en cuenta los siguientes aspectos:

- Criterios funcionales.

- Niveles de interactividad.

- Aspectos relativos a la navegación.

Como se puede ver, la etapa de planificación se basa casi completamente en la recogida, análisis y ordenación de toda la información posible, con el objetivo de tener una base sólida sobre la que poder tomar decisiones de diseño en las siguientes etapas del proceso.

La etapa de Diseño es el momento del proceso de desarrollo para la toma de decisiones acerca de cómo diseñar o rediseñar, en base siempre al conocimiento obtenido en la etapa de planificación, así como a los problemas de usabilidad descubiertos en etapas de prototipo y evaluación.

VI. Modelado del Usuario

 Toda la información obtenida de nuestros clientes, realizados en la anterior fase de planificación debe servir como base para comenzar el diseño, pero para ello se debe resumir y sintetizar dicha información.

 Este paso se denomina modelado del usuario y consiste en la definición de clases o perfiles de clientes en base a atributos comunes. Los atributos sobre los que se hará la clasificación dependen de la información que se tenga de la audiencia, pero normalmente se tratarán de atributos tales como necesidades de información, condiciones de acceso, experiencia y conocimientos.

 En general en DocIRS, se distinguen tres perfiles:

i)       Super-Administrador (Los constructores y mantenedores de los servidores donde opera el sitio y su base de datos).

ii)     Administrador: que es aquel usuario asignado por el cliente, que puede cambiar parámetros, asignar usuarios, modificar datos, etc.

iii)   Usuario, que visualiza, exporta y puede intervenir en áreas limitadas de la aplicación.

VII. Diseño Conceptual

El objetivo de la fase de Diseño Conceptual es definir el esquema de organización, funcionamiento y navegación del sitio. No se especifica qué apariencia va a tener el sitio, sino que se centra en el concepto mismo del sitio su arquitectura de información. DocIRS, trabaja en un estilo minimalista, dejando el diseño visual hacia el momento en que está la arquitectura y distribución de los objetos ya estructurada.

Los sitios Web son sistemas formados por conjuntos de páginas interrelacionadas por enlaces unidireccionales, pudiendo cada una de estas páginas contener sub-elementos con entidad propia, contenidos multimedia y herramientas interactivas.

La "estructura" del sitio Web se refiere precisamente a las conexiones y relaciones entre páginas, a la topología de la red de páginas, así como diferenciando los elementos de información contenidos en las páginas; y la "navegación" a las posibilidades y forma en que cada página presenta las opciones de desplazamiento hacia otras páginas. (ver Programación Modular)

La definición de la estructura del sitio puede hacerse desde dos enfoques diferentes y complementarios: aproximación descendente y ascendente. En la descendente se trata de estructurar del "todo" a las "partes", dividir los contenidos en páginas y definir los enlaces entre páginas.

Una vez definida la estructuración del sitio es necesario documentarla, para así tener un modelo de referencia sobre el que sustentar el desarrollo del sitio. La forma de documentar arquitecturas se suele hacer a través de grafos y esquemas, con el objetivo de que sean de fácil y rápida comprensión por todos los miembros del equipo de desarrollo.

VIII. Diseño Visual y Definición del Estilo

 En esta fase se especifica el aspecto visual del sitio Web: composición de cada tipo de página, aspecto y comportamiento de los elementos de interacción y presentación de los objetos.

El prototipo de DocIRS opera con una relación de orden, en cuanto a la importancia de los objetos en cada formulario. Por tanto, distribuyendo los elementos de información y navegación según su relevancia en zonas de mayor o menor jerarquía visual - por ejemplo, las zonas superiores de la interfaz poseen más jerarquía visual que las inferiores.

 Además de la posición de cada elemento en la interfaz, existen otras técnicas para jerarquizar información como son: uso del tamaño y espacio ocupado por cada elemento para otorgarle importancia en la jerarquía visual, utilización del contraste de color para discriminar y distribuir información, uso de efectos tipográficos para enfatizar contenidos, rotura de la simetría y uso de efectos de relieve / profundidad para resaltar elementos, etc.

 En síntesis, DocIRS construye primero la aplicación sin ningún estilo visual y con un máximo de objetos simples y propios del HTLM, sin imágenes ni “pirotecnia”, para posteriormente cuando el motor esté probadamente  funcionando, montar el estilo (uso de hojas CSS). Esta debe mantener una coherencia y estilo común entre todas las páginas, proporcionando una consistencia visual a todo el sitio

 IX. Prototipo

La evaluación del uso del sitio Web se debe realizar desde las primeras etapas de diseño. Este proceso en DocIRS, se implementa, a través de prototipos utilizando nuestras librerías de rutinas y especialmente el RobotDocIRS.

Esta etapa Prototipo, se basa en la elaboración de modelos, maquetas o versiones preliminares de la interfaz del sitio. Su aspecto no se corresponde exactamente con el que tendrá el sitio una vez finalizado, pero pueden servir para evaluar el sitio sin necesidad de esperar a su implementación.

El prototipo, según nuestra experiencia, es enormemente útil, dado que con métodos convencionales, hay un largo retraso antes de que el cliente consiga ver cualquier resultado. Así mismo el desarrollo puede durar tanto tiempo que las reglas del negocio del cliente podrían haber cambiado, lo que en la mayoría de los casos, lo obliga a intentar cambiar los requerimientos como parte del contrato.

Junto con el prototipo se agregan como valor adicional los siguientes beneficios:

i) La especificación documentada de los requerimientos del cliente para el constructor es certera. Esto significa, que no existe un área de incertidumbre que induzca a nuevos pedidos, a re-construir requerimientos, a generar mal entendidos para reformular el proyecto. 

ii) El prototipo entregado contiene el 80% de lo que es una construcción de aplicaciones sobre plataforma Internet. En efecto, el prototipo DocIRS, junto a la documentación entregada son equivalentes a un plano, su descripción y maqueta aceptada 100% por el cliente.

iii) El prototipo hace converger, en muy corto tiempo, hacia un diseño aceptable por el cliente y factible de construir a los desarrolladores, limitando a un mínimo los cambios de reglas, ahorrando tiempo de desarrollo, sin exponer la calidad, el costo del producto y malos entendidos entre las partes.

X. Evaluación y Revisión

La evaluación del uso - la etapa más importante en el proceso - se puede realizar a través de varios métodos o técnicas y sobre diferentes representaciones del sitio.

 DocIRS tiene para cada construcción de aplicaciones Web, crea y replica en sus servidores tres ambientes físicos diferentes, que están conectados a Internet con sus correspondientes niveles de seguridad:

i) Ambiente de Desarrollo

ii) Ambiente de Prueba

iii) Ambiente de Producción

Cada uno de ellos con su propia Base de Datos, donde se lleva a cabo la revisión: En Desarrollo son los propios analistas programadores quienes deben  verificar y aplicar métodos de inspección del sitio Web del sistema, antes de pasarlo a Ambiente de Pruebas.  (Ver Acerca Fases de Programacion)

En Ambiente de Pruebas, es el Ingeniero de Procesos, que ha estado a cargo del levantamiento y diseño funcional, quien revisa por parte de DocIRS. Así mismo sobre este mismo ambiente la contraparte, el cliente, también revisa y vela por que se haya cumplido con los requerimientos establecidos.

XI. Método por inspección: evaluación heurística

En cada uno de estos ambientes se aplican métodos de inspección del uso de un sitio Web identificando errores y problemas de diseño.

Esta evaluación heurística tiene como ventaja la facilidad y rapidez con la que se puede llevar a cabo, dado que se lleva a cabo por un grupo reducido de evaluadores que, en base a su propia experiencia, fundamentándose en reconocidos principios de uso contrastando finalmente los resultados.

DocIRS construye todas sus aplicaciones en forma simple, con simbología e iconos que facilitan la acción del usuario. La mensajería no es redundante, está asociada a las validaciones de las reglas internas de los objetos y se intenta a través de ella, mejorar el ingreso de datos y guiar al usuario en su navegación. 

Ayuda y Documentación: DocIRS se caracteriza por dedicar y situar como una de las partes más importantes de un sitio Web, la Ayuda, Manuales o documentación. Así mismo, DocIRS tiene dentro de sus normas proporcionar esta documentación en forma organizada con índices analíticos y en línea con la aplicación. (Ver Tratamiento documental)

XII. Método del Piloto con Usuarios

El test con usuarios responde a un plan de pruebas que se basa en la observación y análisis de cómo un grupo de usuarios reales utiliza el sitio Web, anotando los problemas de uso con los que se encuentran para poder solucionarlos posteriormente. Esta revisión se realiza en Ambiente de Pruebas y desde allí deben aparecer lista de errores, cambios y modificaciones en forma iterativa hasta obtener la aprobación del cliente.

XIII. Implementación y Paso a Producción

En la implementación del sitio es recomendable utilizar estándares (HTML, XHTML...) para asegurar la futura compatibilidad y escalabilidad del sitio. Esto se debe a que, aunque puede ser tentador utilizar tecnologías propietarias, el panorama tecnológico puede hacerlas desaparecer o cambiar en poco tiempo.

Igualmente es recomendable separar en la implementación contenido de estilo, mediante el uso de hojas de estilo (CSS) del lado del cliente y uso de bases de datos del lado del servidor. De esta forma se facilitará tanto el rediseño del sitio como la posibilidad de adaptación dinámica del diseño a las necesidades de acceso de cada tipo de usuario.

En esta etapa del desarrollo se debe llevar, así mismo, un control de calidad de la implementación, supervisando que todo funcione y responda a cómo había sido planificado, ya que la utilización del sitio depende directamente de la funcionalidad. Si algo no funciona, sencillamente no se puede usar.

Nuestra experiencia, nos está llevando cada vez a aproximarnos con más fuerza a hacer realidad nuestros fundamentos teóricos, acerca del diseño y desarrollo de aplicaciones (Ver Fundamentos). En efecto, los años 2001 y 2002 significaron para DocIRS comenzar un cambio hacia otra arquitectura de diseño de aplicaciones distribuidas. Organizar el trabajo en capas, con componentes, con tratamiento binario y atómico de los objetos, con articulación con sistemas corporativos externos, abriendo una gama de soluciones que sólo podían desplegarse construyendo bajo esta arquitectura. (Además, hoy se incorpora a este concepto los Servicios Web XML o Web Services)

Este avance ha ocasionado un cambio significativo en la forma de encarar el desarrollo de aplicaciones distribuidas, principalmente por el rápido crecimiento de Internet. Trayendo consigo nuevas tecnologías y lenguajes "ad hoc" que hacen que las redes existentes tengan que adaptarse a esta forma de comunicación, creándose así las Intranets, Extranets y re-adaptación de servicios y redes. La arquitectura DNA (Distributed iNternet Applications) está diseñada para solucionar problemas que no involucren al usuario. Es decir, que se construyan soluciones rápidas por los especialistas en los servidores, sin complicar ni al usuario ni su máquina.

Un problema a tener en cuenta, dice relación con los scripts que deben construirse, pues ellos tienen que ser compatibles para los browser más utilizados tales como Explorer(IE), Firefox Mozilla, Opera, etc. Nótese que Firefox Mozilla no admite vbscript y obliga a utilizar Dom Javascript( Document Object Model) .

Implementar soluciones basadas en DNA involucra crear aplicaciones divididas en capas funcionales que se comunican entre sí. Este concepto por sí mismo no significa nada nuevo, pero DNA provee protocolos estándares e interfaces pre-implementadas que permiten al desarrollador concentrarse en construir la lógica del sistema, sin preocuparse por cómo las partes se intercomunican.

XIV. Normas de Seguridad de la Aplicación Web

 

Nuestras normas básicas de seguridad están basadas en la metodología tradicional de la seguridad de las aplicaciones y servicios Web, pero con algunas encriptaciones y variantes propias  de DociRS. En general, definimos en una tabla especial de la base de datos la matriz de usuarios y privilegios para posterior a la autenticación incluir la variable de sesión en cada página.

Las variables de sesión almacenan y muestran información mantenida durante la visita (o sesión) de un usuario. El servidor crea un objeto de sesión diferente para cada usuario y lo mantiene durante un período de tiempo establecido o hasta que se pone fin al objeto explícitamente.

Los principios básicos que configuramos en las aplicaciones son:

i)                    Validación de las transacciones.La entrada y salida de información es el principal mecanismo que dispone un "hacker " para enviar o recibir código malicioso contra el sistema. De ahí que, en todo momento debe verificarse que cualquier dato de entrada o salida sea validado el formato que se espera. Las características de estos datos deben estar predefinidas.

ii)         Diseños simples. Los mecanismos de seguridad deben diseñarse para que sean los más sencillos posibles, evitando sofisticaciones que compliquen a los usuarios.

iii)        Utilización y reutilización de componentes de confianza. Debe evitarse reinventar y desarrollar código constantemente. Por tanto, cuando exista un componente que resuelva un problema de forma correcta, lo más inteligente es documentarlo y re- utilizarlo. (Crear librerías, sistematizar y parametrizar ó RobotDocIRS )

iii)        Defensa en profundidad. Siempre armar cadenas de componentes que se confronten. Es decir, no confiar en que una sola componente realizará su función de forma permanente y bajo cualquier situación. Es decir, disponer de los mecanismos de seguridad para que cuando una componente falle ante un determinado evento, otras sean capaces de detectarlo.

iv)        Seguridad basada en nuestras fuerzas. Con esto nos referimos a que se deben crear variantes propias y no confiar la seguridad sólo en mecanismos externos. Por ejemplo, la utilización de SSL garantiza que el tráfico en tránsito entre el servidor y el cliente se encuentra cifrado, pero nada más. Poner mucha atención cuando se trabaja con el método GET (y eventualmente POST) para pasar parámetros

v)         Ocultar códigos o directorios no funciona. Basar elementos de seguridad, asumiendo que el “perverso”  desconoce las direcciones y funcionamiento no impide que pueda ser descubierto. Es necesario, operar con Logín, Password, ingreso de claves anti-robot y encriptaciones.

vi)       Verificación de Privilegios. Los sistemas deben diseñarse para que funcionen con los menos privilegios posibles. Igualmente, es importante que los procesos únicamente dispongan de los privilegios necesarios para desarrollar su función, de forma que queden compartimentados.

vii)       Ofrecer la mínima información. Ante una situación de error o una validación negativa, los mecanismos de seguridad deben diseñarse para que cualquier operación posterior sea igualmente denegada.

XVI. Mantenimiento y seguimiento

 Un sitio Web no es una entidad estática, es un objeto vivo cuyos contenidos cambian; cuya audiencia, necesidades y perfiles cambian, y que por lo tanto requiere de continuos rediseños y mejoras.

Estos rediseños deben ser muy sutiles, no se puede cambiar el aspecto y diseño de forma drástica de un día para otro, pues aunque estos cambios estén fundamentados en problemas de uso descubiertos post-ambiente de Producción, los cambios pueden resultar pésimos para los actuales usuarios que ya estaban acostumbrados y familiarizados con el actual diseño.(Ver Acerca de la Calidad de una Aplicación)

Los problemas de uso no detectados durante el proceso de desarrollo pueden descubrirse a través de varios métodos, principalmente a través de los mensajes y opiniones de los usuarios, y su comportamiento y uso del sitio.

XVII. Opiniones de los Usuarios

Esta información puede ser obtenida de forma pasiva - a través de los mensajes enviados por los usuarios acerca de problemas que han tenido con el uso del sitio - o de forma activa - por medio de cuestionarios y encuestas realizadas sobre la audiencia -.

Las opiniones expresadas por los usuarios indican posibles problemas en el uso, pero no son en sí mismas la respuesta a estos problemas. Si la satisfacción es baja, habrá que mejorar las rutinas y presentación involucradas en el problema .

XVIII. Comportamiento del Usuario y Uso del sitio

Una vez que el sitio Web ha sido pasado a producción y es usado diariamente, tenemos a nuestra disposición una nueva fuente de información sobre el comportamiento del usuario. Los archivos "log" que van almacenando el registro de entradas de los usuarios. Estas cadenas de texto plano, DocIRS las trata en formato XML y se pueden almacenar en un archivo de texto o en una base de datos. Cada cadena de texto contiene una serie de datos  acerca de la transacción registrando cada una de las peticiones de páginas realizadas por los clientes al servidor: 

Se registra la siguiente información:

  • Mesa de Trabajo DocIRS

  • Dirección IP del cliente

  • Identidad del usuario

  • Password de acceso

  • Fecha y hora de la petición

  • Método

  • Path o directorio de la página en el servidor

Estos archivos Log de registro de los movimientos del usuario sobre la aplicación son realmente de una información muy valiosa que correctamente analizada permite mejorar significativamente el sitio. Nótese que entendemos por aplicaciones Web a todo aquél software que interacciona con el usuario utilizando, - en general -  el protocolo HTTP.

Ejemplo de captura de datos para el LOG con ASP:

<html>
<body>
<p>
<b>Browser:</b>
<%Response.Write(Request.ServerVariables("http_user_agent"))%>
</p>
<p>
<b>IP</b>
<%Response.Write(Request.ServerVariables("remote_addr"))%>
</p>
<p>
<b>DNS de la IP</b>
<%Response.Write(Request.ServerVariables("remote_host"))%>
</p>
<p>
<b>Metodo</b>
<%Response.Write(Request.ServerVariables("request_method"))%>
</p>
<p>
<b>Dominio</b>
<%Response.Write(Request.ServerVariables("server_name"))%>
</p>
<p>
<b>Puerto</b>
<%Response.Write(Request.ServerVariables("server_port"))%>
</p>
<p>
<b>Software Servidor</b>
<%Response.Write(Request.ServerVariables("server_software"))%>
</p>
</body>
</html>

 

 


Artículos Relacionados