Universidad Tecnológica de Huejotzingo

Tecnologías de la Información y Comunicación

Ingeniería del software III

Estándares de iure y de facto

Prof. Luis Alberto Santos Peña

Integrantes:

Aguilar Vargas Edgar Einard

Espinoza Soledad Beatriz

Lidia Nieto Hernández

Felipe Gerardo Martínez de Jesús

ESTANDARES

Es un requisito, regla o recomendación basada en principios probados y en la práctica. Representa un acuerdo de un grupo de profesionales oficialmente autorizados, también sirve como tipo, modelo, norma, patrón o referencia, y es un acuerdo documentado lo más común posible

Dichos acuerdos o normas se establecen en base a un consenso. Por lo que los estándares son normas vivas, dinámicas y cambiantes. Por ello debe haber organizaciones que se ocupen, no sólo de fijarlos, sino también de mantenerlos.

Los estándares contienen las especificaciones técnicas y de calidad que deben reunir todos los productos y servicios para cumplir satisfactoriamente con las necesidades para las que han sido creados y para poder competir en condiciones de igualdad, es decir, sin el impedimento de las barreras técnicas o incompatibilidades que pudieran obedecer a diferentes formatos según las especificaciones de cada país o empresa.

Por ejemplo: podemos estandarizar cosas tan simples como el tamaño y peso de los tornillos, o hasta el tamaño y peso de un automóvil, o hasta las dimensiones de un sobre o de los folios

En informática, un ejemplo típico de estándares lo forman los distintos protocolos de comunicación entre ordenadores e internet que a su vez podemos construir sistemas o plataformas de aprendizaje, entornos de aprendizaje o sistemas de e-learning. Estas tecnologías educativas facilitan el proceso de aprendizaje y su gestión.

La difusión completa de las tecnologías educativas no se comprende sin una estandarización de las mismas, estandarización que será clave para asegurar la interoperabilidad entre los distintos sistemas de enseñanza.

La educación es un fenómeno global que exige la participación de diversas instituciones, centros y organismos. Cada uno de ellos puede apoyarse en un entorno de aprendizaje para realizar su labor. Estos entornos no tienen por qué ser iguales, y, por tanto, se hace necesario buscar formas para que sistemas de aprendizaje.

Distintos puedan compartir contenidos, herramientas, experiencias, etc., dicho de otra forma: necesitamos buscar formas de asegurar la interoperabilidad entre plataformas de aprendizaje o entornos virtuales educativos.

Además, la interoperabilidad es uno de los dos objetivos generales propuestos por el consorcio W3C (World Wide Web Consortium) para alcanzar la implementación de la Web Semántica (el otro es la evolutividad).

Gracias a ello podemos trabajar en un mercado universal, algo importante dentro de la economía global actual; es más, los estándares son básicos para la industria, ya que el retorno de la inversión depende de ellos, por tanto, son un requisito de la economía del conocimiento.

CATEGORIZACIÓN DE ESTÁNDARES SEGÚN CARÁCTER LEGAL

Estándar legal

Lo estándares legales son aquellos normalizados por organizaciones como CEN/CENELEC y aquellos adoptados por diferentes directivas, leyes o decretos en los distintos gobiernos y ámbitos legislativos de la Unión Europea, y para los que su uso se hace obligatorio en entornos públicos. Ejemplo de estos estándares podría ser el sistema métrico decimal, el horario o el monetario, aunque también lo serían para el ámbito de aplicación geográfico correspondiente estándares como:

Estándar nacional\

Son estándares nacionales aquellos normalizados o ratificados por los cuerpos de estandarización nacionales de cada país. Así, para España lo será AENOR, mientras que para EE.UU. lo será ANSI, por ejemplo.

Estándar internacional

Son aquellos estándares normalizados o adoptados oficialmente por organismos de estandarización internacionales formados por los representantes legales de cada gobierno. Es el caso de ISO/IEC principalmente. A veces estos estándares se denominan “estándares de iure”.

Estándar local

Son aquellos estándares promovidos, generados, adoptados o ratificados por consorcios industriales que representan a una parte importante de la industria. Pero que los productos son hechos en un país y que no se pueden hacer en otras partes de igual manera.( W3CConsorcio para la World Wide Web)

OBJETIVO DE LOS ESTANDARES

Es hacer las cosas más fáciles, definiendo características de objetos y sistemas que se utilizan cotidianamente, ya que les permite a los usuarios tener más confianza con dichos artículos. Como por Ejemplos: teclado de teléfono y el teclado QWERTY.

El teclado QWERTY es la distribución de teclado más común. Fue diseñado y patentado por Christopher Sholes en 1868 y vendido a Remington en 1873. Su nombre proviene de las primeras seis letras de su fila superior de teclas.

La distribución QWERTY no fue inventada para reducir la velocidad y en consecuencia evitar que la máquina se trabara, la realidad es totalmente diferente y se diseño con dos propósitos:

Lograr que las personas escribieran más rápido distribuyendo las letras de tal forma que se puedan usar las dos manos para escribir la mayoría de las palabras.

Evitar que los martillos de las letras chocaran entre ellas, en los primeros diseños.

Se explica que en 1956 un estudio diseñado por los Servicios de Administración General de Estados Unidos determinaron que las personas que usaban QWERTY eran casi tan rápidos, o más rápidos, como aquellos que usan la distribución Dvorak, no hay necesidad de aprender otros sistema de distribución porque simplemente no vale la pena ni el esfuerzo.

En pocas palabras: la distribución QWERTY no fue pensada específicamente para escribir más lento y los teclados Dvorak no logran hacer escribir más rápido.

En este teclado, según la técnica de mecanografía más difundida, en posición de reposo, cuatro dedos de cada mano se colocan sobre la fila central de teclas. Para poder encontrar esta posición sin tener que mirar el teclado, las teclas correspondientes a los dedos índices de cada mano (F y J) suelen tener algún rasgo distintivo al tacto.

Esta disposición de teclado se llevó a los ordenadores para desplazar más fácilmente a las máquinas de escribir en las oficinas. De esta forma, las personas encargadas de 'mecanografiar' documentos seguían sabiendo manejar los nuevos teclados informáticos.

El teclado QWERTY tiene versiones para diferentes lenguas. Hay países, como Alemania, que intercambian la tecla "Y" y la tecla "Z", con lo que se convierte en teclado QWERTZ. En Francia y Bélgica hay más cambios y las primeras 6 teclas alfabéticas tienen la secuencia AZERTY. En la disposición española y latinoamericana se incluye la letra "Ñ".

Beneficios

Una terminología común

Permite a los diseñadores discutir los mismos conceptos y hacer valoraciones comparativas

El mantenimiento y la evolución

Todos los programas tienen la misma estructura y el mismo estilo

Una identidad común

Lo que hace que todos los sistemas sean fáciles de reconocer

Reducción en la formación

Los conocimientos son más fáciles de transmitir de un sistema a otro

Salud y seguridad

Si los sistemas han pasado controles de estándares es difícil que tengan comportamientos inesperados

Toda industria funciona con estándares como por ejemplo:

Arquitectura de sistemas.

La arquitectura de sistemas va más allá de los equipos y el software, incluidos los componentes y los factores adicionales que forman parte del proceso de diseño de SyTI. La mejor analogía es un plan de trabajo para un sistema de SyTI. El plan tiene en cuenta elementos claves como la infraestructura para formación de redes, la conectividad y las comunicaciones.

Los estándares son muy importantes en la consideración de la arquitectura. Muchas características podrían incluirse en la categoría de arquitectura de sistemas. Este manual se centra en dos de ellas con aplicación específica en el sector de atención de salud: sistemas abiertos y computación en red.

El diseño de la arquitectura de sistemas correcta para una institución de atención de salud es probablemente el paso técnico más importante. Desde la perspectiva de la tecnología de la información, la arquitectura de sistemas tiene la misma finalidad que un plan de trabajo cuando se aplica a la construcción de un edificio físico.

El plan detallado define el punto final, cómo se verá el edificio después de finalizado y los estándares a observar durante la construcción. Una vez que se acuerda un plan de trabajo se puede empezar a construir con la seguridad de que la solución final quedará bien. Esto es válido también para el diseño de una solución de SyTI para atención de salud.

Uno podría extender aun más la metáfora del edificio en el contexto de los SyTI de salud:

(“Imagine una arquitectura de TI como la planificación de una ciudad más que la construcción de una casa solamente. La arquitectura proporciona códigos de construcción que limitan las opciones de diseño a corto plazo en aras de la comunidad, pero estos códigos no determinan la clase de edificios que necesitan las personas. Al igual que los códigos de construcción, una arquitectura de TI debe comprender un conjunto de estándares, pautas y determinaciones de dirección que permitan la implementación empresarial paso por paso sin sacrificar la integración”.)

Cuando una organización elige un sistema comercial propietario el proveedor determina automáticamente la arquitectura. En realidad, muchas instituciones, particularmente las más pequeñas, eligen sistemas propietarios porque no quieren centrar los recursos en temas de definición de la arquitectura de sistemas. No obstante, dado que actualmente el énfasis en el entorno de SyTI radica en los sistemas abiertos, y dado que un sistema abierto requiere generalmente más planificación desde su comienzo, las instituciones que aspiran a arquitecturas abiertas necesitarán equiparse con información técnica detallada. Una vez más, es considerable la cantidad de publicaciones fácilmente accesibles, pero corresponde un resumen de los criterios para la selección de los sistemas abiertos.

Más adelante se hará hincapié en las ventajas y los inconvenientes detallados del sistema abierto en comparación con el sistema propietario, pero baste decir aquí que una arquitectura de sistemas abiertos bien definida, en combinación con una buena estrategia empresarial para servicios de salud, ofrece las siguientes ventajas:

· Permite compartir recursos, una función imprescindible en las instituciones de servicios de salud en evolución actualmente.

La vinculación entre la institución y las estrategias técnicas permite una mejor toma de decisiones, al identificar claramente temas empresariales claves y demostrar las vinculaciones entre la estrategia empresarial y la estrategia de SyTI.

· Un conjunto definido de estándares permite a los usuarios reunir los módulos necesarios más rápidamente y aprovechar las oportunidades del mercado conforme van surgiendo.

· Ofrece respaldo para el acceso transparente de usuarios a los recursos del sistema (conexión única y seguridad, por ejemplo).

· Los servicios comunes (elementos fundamentales reutilizables) pueden ayudar a reducir los costos futuros de mantenimiento.

· Puede simplificar la administración de sistemas y reducir los costos mediante el uso de servicios de distribución y comunicación comunes.

· El acceso transparente a los recursos ayuda a los desarrolladores de aplicaciones a implantar soluciones nuevas.

· El uso de una arquitectura técnica contribuye a eliminar problemas potenciales de integración de tecnología en el futuro.

· Una arquitectura técnica define claramente las tecnologías para la organización, las cuales permiten el desarrollo de capacidad en áreas específicas.

Los sistemas abiertos comparados con los sistemas Propietarios

Los sistemas de información se introdujeron inicialmente con componentes de software — incluidos sistemas operativos, activadores e incluso algunos lenguajes — que eran propiedad exclusiva del proveedor. En realidad, muchos sistemas de información para atención de salud en el mercado actual son de "marca registrada". En general, los términos "sistemas propietarios", “de marca registrada” y “cerrados” se usan indistintamente en este trabajo para indicar características del sistema que el proveedor conserva fuera del dominio público.

Se presenta una analogía con el sector de los componentes estereofónicos. En los años sesenta, los fabricantes de equipos estereofónicos acordaron fabricar la mayoría de sus partes componentes

para que fuesen intercambiables mediante conexiones estándar. De tal manera, los parlantes de un fabricante se conectarían al sintonizador de otro fabricante, etc. En la actualidad la tendencia en realidad se revirtió, con fabricantes que producen sistemas enteros, incluidos sintonizadores, parlantes, amplificadores, tocacintas y bandejas de CD conectados; es decir, un sistema cerrado o de marca registrada.

Esos sistemas de marca registrada en el escenario de los SyTI para atención de salud todavía gozan de éxito ininterrumpido debido a algunas ventajas muy tangibles de que se tratan en la próxima sección. Sin embargo, la tendencia mundial es inexorablemente hacia sistemas abiertos que utilizan estándares reconocidos.

La definición actual y más aceptada de sistemas abiertos es un entorno que implementa especificaciones lo suficientemente amplias para interfaces, servicios y formatos de datos auxiliares a fin de que todas las aplicaciones adecuadamente diseñadas:

· Permitan transferencia ("porting") sin cambios o cambios mínimos en una variedad de arquitecturas de equipo

· Funcionen con aplicaciones en sistemas locales y remotos que tienen diversas arquitecturas

· Interactúen con usuarios de una manera común que permita transferir fácilmente los conocimientos técnicos de los usuarios entre diferente arquitecturas de equipos Las especificaciones abiertas son especificaciones mantenidas por un proceso abierto de consenso público. Contienen generalmente normas internacionales a medida que son adoptadas. También pueden contener especificaciones formuladas por empresas o consorcios privados cuando el mantenimiento de la especificación se transfiere a un proceso con consenso o control público. Las influencias para contribuir en la dirección del entorno de sistemas abiertos son variadas. Como se muestra a continuación:

Comparación de sistemas abiertos y sistemas de marca registrada

Industria informática

Una de las principales herramientas que han permitido a las distintas herramientas informáticas poder interactuar y así proporcionar una experiencia satisfactoria al usuario han sido los estándares. Los estándares, o parte de ellos como se comprobará en adelante, han sido la herramienta base de la interoperabilidad informática. Son los que han permitido definir cómo interactuaran los miles o millones de componentes informáticos que existen.

Sin embargo, estándares existen de muchos tipos y según de cuál de ellos se esté hablando, se estarán garantizando unas funcionalidades y unas capacidades de interoperabilidad técnica distintas. Así, los estándares se pueden clasificar en función de diversas características. Las dos principales probablemente, de cara a las implicaciones que tienen de cara a su uso son cómo de abiertos/cerrados y permisivos/exclusivos son, y qué carácter legal tienen.

También es interesante observar qué organismo ha emitido y es responsable del estándar, así como su ámbito geográfico de aplicación. De hecho, se comprobará que las diferencias legales entre distintos entornos geopolíticos, van a determinar que un determinado estándar pueda ser considerado diferentemente dependiendo del lugar donde se emplee o comercialice.

Sin embargo, y fuera de toda categoría, un estándar, para poder denominarse como tal, al menos requiere cumplir una característica: sus especificaciones son públicas y accesibles cuando más a un precio simbólico. La especificación de un estándar, a su vez, es aquel conjunto de documentos donde se define cómo llevar a cabo un desarrollo de software o hardware que siga ese estándar.

Estándares de pantallas, teclados, conectores, incluso mobiliario

Estándares de la interfaz

Objetivo:

Conseguir un software más fácil y seguro, estableciendo unos requisitos mínimos de fabricación, eliminando inconsistencias y variaciones innecesarias en las interfaces

Beneficios

Una terminología común

o Permite a los diseñadores discutir los mismos conceptos y hacer valoraciones comparativas

El mantenimiento y la evolución

o Todos los programas tienen la misma estructura y el mismo estilo

Una identidad común

o Lo que hace que todos los sistemas sean fáciles de reconocer

Reducción en la formación

o Los conocimientos son más fáciles de transmitir de un sistema a otro

Salud y seguridad

o Si los sistemas han pasado controles de estándares es difícil que tengan comportamientos inesperados

TIPOS DE ESTÁNDARES Y CLASIFICACION DE ESTÁNDARES SEGÚN APERTURA Y EXCLUSIVIDAD

ESTÁNDARES DE IURE

Son generados por comités con estatus legal y gozan del apoyo de un gobierno o institución para producir estándares

Para hacer un estándar de iure se ha de seguir un proceso complejo:

Documento preliminar público

Enmiendas

Aprobación (tras cierto tiempo, a veces año)

Ejemplo: ANSI C

Estándares de iure - Comités

En Informática tienen estatus legal para definir estándares de iure:

o ISO Asociación Internacional para Estándares

o IEC Comisión Electrotécnica Internacional

o ANSI Instituto Nacional Americano para Estándares

o IEEE Instituto de Ingenieros Eléctricos y Electrónicos Americano

o CEN Comité Europeo para la Estandarización

o W3C Consorcio para la World Wide Web

Estándares de iure en IPO

Los estándares de la interfaz son relativamente recientes. Algunos de los más importantes son:

o ISO/IEC 9126: Evaluación de productos software: características de calidad y directrices para su uso

o ISO 9241: requisitos ergonómicos para trabajar con terminales de presentación visual (VDT)

o ISO/IEC 10741: interacción de diálogos

o ISO/IEC 11581: símbolos y funciones de los iconos

o ISO 11064: diseño ergonómico de centros de control

o ISO 13406: requisitos ergonómicos para trabajar con presentaciones visuales basadas en paneles planos

o ISO 13407: procesos de diseño centrados en la persona para sistemas interactivos

Algunos aspectos cubiertos por la ISO 9241 (requisitos ergonómicos para trabajar con terminales de presentación visual):

o Requisitos de la presentación visual

o Requisitos de teclado

o Diseño de estaciones de trabajo y requisitos de las posturas

o Requisitos para la visualización con reflejos

o Requisitos para colores visualizados

o Requisitos para dispositivos de entrada no-teclado

o Principios de diálogos

o Presentación de información

o Diálogos de menús

o Diálogos de manipulación directa

o Diálogos para completar formularios

Estándares de facto

Son estándares que nacen a partir de productos de la industria que tienen un gran éxito en el mercado o desarrollos hechos por grupos de investigación en la Universidad que tienen una gran difusión

Son aceptados como tales por su uso generalizado

Su definición se encuentra en manuales, libros o artículos

Ejemplos:

Sistema X-Windows

Es una implementación de código abierto del sistema X Window que incluye Xorg y XFree86™. En las versiones de FreeBSD hasta FreeBSD 4.10-RELEASE y FreeBSD 5.3-RELEASE el sistema X window que se instalará por defecto es XFree86, el servidor X11 distribuido por el proyecto XFree86. Después de FreeBSD 5.3-RELEASE el sistema X Window pasó a ser Xorg, el servidor X11 distribuido por la Fundación X.Org.

Lenguaje C

o C es un lenguaje de programación de propósito general que ofrece economía sintáctica, control de flujo y estructuras sencillas y un buen conjunto de operadores. No es un lenguaje de muy alto nivel y más bien un lenguaje pequeño, sencillo y no está especializado en ningún tipo de aplicación. Esto lo hace un lenguaje potente, con un campo de aplicación ilimitado y sobre todo, se aprende rápidamente. En poco tiempo, un programador puede utilizar la totalidad del lenguaje.

Este lenguaje ha sido estrechamente ligado al sistema operativo UNIX, puesto que fueron desarrollados conjuntamente. Sin embargo, este lenguaje no está ligado a ningún sistema operativo ni a ninguna máquina concreta. Se le suele llamar lenguaje de programación de sistemas debido a su utilidad para escribir compiladores sistemas operativos, aunque de igual forma se puede desarrollar cualquier tipo de aplicación.

o Estructura

main( )

{

}

#include <stdio.h>

main( )

{

printf("Hola amigos!\n");

}

Los tipos de datos básicos definidos por C son:

o caracteres,

o números enteros

o números en coma flotante.

Los caracteres son representados por char, los enteros por short, int, long y los números en coma flotante por float y double. Los tipos básicos disponibles y su tamaño son:

Char Carácter (normalmente 8 bits)

Short Entero corto con signo (normalmente 16 bits)

Int Entero con signo (depende de la implementación)

Unsigned Entero sin signo (depende de la implementación)

Long Entero largo con signo (normalmente 32 bits)

Float Flotante simple (normalmente 32 bits)

Double Flotante doble (normalmente 64 bits)

Normas CUA

Estándar de facto desarrollado por IBM y Microsoft Define los componentes de la interfaz que deben mantenerse entre aplicaciones

Desde el punto de vista de la especificación, que es donde verdaderamente se define cada estándar al menos técnicamente, los estándares se pueden categorizar en función de su especificación es más abierta o menos, y coincidentemente y de forma respectiva, más permisivos o menos.

La exclusividad es la característica que indica si el estándar puede ser utilizado más o menos libremente por aquellos que no son sus propietarios y bajo qué condiciones. La exclusividad es una característica legal.

La apertura es la característica que permite llevar a cabo la implementación técnica y la comercialización y distribución del estándar sin restricciones legales o técnicas. Mientras más restricciones técnicas o legales tenga menos abierto será es estándar.

Las restricciones legales vienen dadas principalmente por la licencia, o contrato de uso, que provean los posibles propietarios del estándar a los implementadores del mismo. La licencia puede ser pública y común para todos, puede ser una licencia libre, puede ser una licencia secreta.

Así, se puede definir la siguiente escala de apertura y exclusividad:

EXCLUSIVO Y CERRADO >

INCLUSIVO Y ABIERTO

No estándar >

o La especificación de aquello a lo que se refiera el estándar (formato, protocolo, metodología, métrica, etc.) no es pública, ni tampoco ha sido normalizada ni reconocida por ningún cuerpo de estandarización internacional, nacional o incluso industrial.

Estándar cerrado >

o La especificación del estándar ha sido hecha pública, pero sin embargo, existen determinadas restricciones legales (principalmente patentes, pero también derechos de autor, marcas, etc.) que impiden que se pueda implementar el estándar libremente por parte de aquellos que no lo desarrollaron o adquirieron sus derechos. Así, los términos de la licencia de implementación de las especificaciones no son públicos ni comunes para todos los posibles agentes del mercado interesados en implementar el estándar, esto es, en crear aplicaciones o herramientas informáticas que sigan cumplan con lo definido en las especificaciones del estándar. De esta forma, cada implementador se ve forzado a llegar a un acuerdo particular con cada uno de los propietarios de cada una de las exclusividades legales que forman el estándar. Esto puede imposibilitar a muchos desarrolladores (empresas o personas) llevar a cabo una implementación compatible con el estándar, y, en todo caso, puede discriminar a unos frente a otros en los términos obtenidos para la licencia.

Generalmente este tipo de estándares quedan delimitados a un círculo pequeño y semimonopolístico de agentes que son los que pasan a controlar el mercado que genera el estándar.

Como cuerpos de estandarización que pueden proveer este tipo de estándares se puede encontrar a ECMA, una asociación industrial europea formada por muchas de las mayores multinacionales informáticas, y que en su proceso de estandarización no provee las suficientes garantías para que los miembros del comité técnico de estandarización en cuestión desvelen las patentes y otras restricciones a las que está sometido el estándar en definición o ratificación.

Estándar RAND >

o Un estándar RAND es aquel estándar cuya especificación ha sido normalizada y es pública, y que ha sido licenciada bajo unos términos comunes para todo el mercado. Las patentes y otras posibles restricciones legales a las que esté sometido el estándar parcial o totalmente habrán sido hechos públicos durante el proceso de estandarización. Esto incluye al menos aquellos que los miembros del comité de estandarización tengan en posesión, no así aquellos que sean externos o que no cuenten con:

Generalmente la forma “RAND” es el mínimo de apertura e inclusividad exigido por muchos de los principales organismos de estandarización (por ejemplo, ISO, IEC, OASIS, etc.) El término RAND proviene de las siglas en inglesas de la expresión “Reasonable and Non Discriminatory”, sin embargo, y como se constata incluso mediante importantes pleitos en curso, dicho término muy al contrario frecuentemente implica términos de licenciamiento que son poco razonables y muy discriminatorios. El hecho de que la licencia sea común para cualquier implementador, no significa que la propia licencia no discrimine a partes del mercado o que los costes de licenciamiento no sean abusivos (véase el pleito entre Nokia y Qualcomm actualmente abierto en EE.UU.)

Así, es frecuente que licencias RAND discriminen a modelos de desarrollo como los de código abierto, pues muchas veces obligan a que las implementaciones del estándar oculten el código (algo imposible para estos modos de desarrollo). También es común que no permitan la libre redistribución del software por parte de los usuarios del mismo, con lo que resultan discriminados los modelos de libre distribución como el software libre que en su definición contienen el derecho del usuario a distribuir libremente el software libre que recibe.

Por otro lado, al igual que los anteriores tipos de estándares, el documento de especificación, es público, pero no por ello tiene que ser gratuito, pudiendo tener un coste simbólico.

Estándar abierto >

o Un estándar abierto ha de disponer su especificación de forma pública (aunque quizá sujeta a algún pago simbólico en concepto de derechos de autor del documento en sí), el estándar ha de ser inclusivo y haber sido desarrollado y estar mantenido en un proceso de estandarización abierto.

Todo el que esté interesado podrá implementarlo sin ninguna restricción, ni pago, si sujeto a derecho de exclusión alguna. Las licencias de los posibles propietarios del estándar o sus partes han de conceder esos derechos de forma gratuita y sin condición alguna a todos los agentes interesados en su implementación, independientemente de su modelo de desarrollo, situación geopolítica, grado de cumplimiento con la especificación, etc. En otras palabras estas condiciones equivalen a la expresión “libres de regalías”.

Los descritos son los mínimos términos de licenciamiento requeridos por ejemplo por cuerpos de estandarización tan importantes como W3C, el responsable de todos los formatos y protocolos de la web. Por supuesto, todos los otros cuerpos de estandarización aceptan estos términos de licenciamiento de estándar abierto, pues sobrepasan los mínimos requeridos por los mismos en cuanto a liberación de exclusividades.

Para mayor precisión, el Marco Europeo de Interoperabilidad, documento oficial emitido por la Comisión Europea en el año 2004, define los estándares abiertos como aquellos cuya especificación y sus documentos de apoyo cumplen como mínimo las siguientes condiciones:

o Estándar libre.

o Un estándar libre es aquel estándar abierto para el que existe una implementación de referencia completa de dicho estándar bajo una licencia libre, o incluso, licencia GPL. En caso contrario su especificación habrá de estar disponible de forma gratuita y sin condición alguna.

La característica de estándar no la da cuan extendido está el uso del mismo. En algunos casos,

cuando el objeto en cuestión está muy difundido se le suele denominar coloquialmente “estándar de

facto”, pero un estándar de facto no tiene por que ser estándar en realidad si no cumple con las

características mínimas requeridas a su especificación. Así, algo secreto puede ser denominado

coloquial “estándar” dentro de un organismo o empresa, pero en realidad no lo es, pues un estándar

pierde el sentido desde el momento en que sólo puede ser usado por conjunto cerrado de agentes.

En ese caso sería un mero acuerdo interno a lo más.

Estas influencias se clasifican en cuatro categorías principales:

· Estándares de facto - Un estándar de facto es una especificación de amplia implementación y uso. Los estándares de facto pueden ser abiertos o de propiedad. El público en general puede obtener la especificación para un estándar de facto en sistemas abiertos. Existe un proceso para que el público controle el contenido futuro de la especificación. . Un ejemplo de una norma de facto abierta sería el leguaje de marcación de hipertexto (HTML) utilizado para presentar información en Internet. Al contrario,

Windows de Microsoft y la Arquitectura de Redes de Sistemas (SNA) de IBM son ejemplos de normas de facto de propiedad

· Estándares de jure - Los estándares de jure son producidos por un grupo con condición jurídica, y emanan de una institución del gobierno o una organización internacional reconocida. Para crear el estándar, el grupo de jure debe seguir un proceso abierto que permite a todos participar para llegar al consenso. Este proceso para lograr el consenso es el más prolongado de todos los procesos de sistemas abiertos. La Clasificación Internacional de Enfermedades de la Organización Mundial de la Salud (CIE) es un ejemplo de estándar de jure.

· Consorcios - Desde 1988 se han formado muchos consorcios de sistemas abiertos. Los consorcios son generalmente organizaciones sin fines de lucro financiadas por miembros con un interés común en definir algún aspecto del entorno de los sistemas abiertos. Los consorcios a menudo incorporan estándares de facto y de jure existentes; luego abordan

Guía de estilo

Es un documento que recoge normativas y patrones básicos relacionados con el “aspecto” de un interfaz para su aplicación en el desarrollo de nuevas “pantallas” dentro de un entorno concreto. (sitio web de contenidos, nuevas secciones, entorno de aplicaciones).

Especificaciones de Guías de estilo

Para asegurar la consistencia de las diferentes partes de un sistema o de una familia de sistemas es fundamental basar su diseño en un conjunto de principios y directrices

Por este motivo es importante para las organizaciones que desarrollan softwaredisponer de una guía que puedan seguir sus desarrolladores

Estas guías se denominan guías de estiloy varían mucho en sus objetivos

o Estas guías se denominan guías de estilo y varían mucho en sus objetivos.

o Destinatarios de las Guías de Estilo

o Son creadas inicialmente como documentos voluminosos muy vistosos que ilustran sobre la apariencia del interfaz de un sistema.

Los problemas que puede tener una quia de estilo son las siguientes:

o Su problema más grave es su falta de usabilidad: Están pensadas desde una perspectiva de diseño y marketing y no tienen en cuenta las necesidades de sus verdaderos destinatarios que son los diseñadores y Programadores de interfaz.

Para tener Una buena Guía de Estilo debe de tener lo suiguiente:

o Integrarse de manera eficiente en el proceso de trabajo de un programador ofreciendo criterios y ayudando en la toma de decisiones en aspectos de diseño de interfaz.

Para que una guia de estilo no sea una carga deberan de tener el siguiente puto:

o Han de ir acompañadas por acciones de promoción y formación y materiales de apoyo que ahorren trabajo al programador.

Crear una Guía de Estilos

Es necesario un equipo único de especialistas los cuales realizaran las siguientes actividades:

o Documentar: crear documentación de carácter visual, compuesta de literatura esencial, ejemplos razonados.

o Formar: dar charlas introductorias, cursos breves periódicos con el objetivo de desarrollar un criterio de usabilidad.

o Dar soporte: desde el arranque hasta el cierre del proyecto resolviendo dudas, detectando nuevas necesidades que se puedan plantear e incorporándolas a la Guía.

o Detección de patrones: identificación de patrones que puedan derivar en componentes de interfaz reutilizables para su uso por los diferentes equipos de desarrollo.

o Investigación e innovación: tener identificados patrones reutilizables y componentes libera recursos de realizar tareas repetitivas y de escaso valor añadido para la detección de líneas de mejora del interfaz, metodología y procesos de desarrollo. (Adecuación a estándares técnicos, accesibilidad, mejoras, tecnologías alternativas).

o Programar y realizar test y pruebas con usuarios: conocer la apreciación de los usuarios de las soluciones incorporadas permitirá realizar correcciones e introducir mejoras.

Tipos de Guías de estilo

Existen dos tipos de guias de estilos que son los siguientes:

o Guías de estilo comerciales

Son producidas por fabricantes de software y hardware, y son en general estándares de facto

o Apple

Ejemplos de Guías de estilo Apple (1985)1)

2)

3)

o

o

o

o

o

o

4)

o Motif

OSF (Open Software Foundation)

o OS/2

o Windows

o Open Look

SUN Microsystems y AT&T

o CDE, Common Desktop Environment

Interfaz gráfica para UNIX

Desarrollado por IBM, HP, Novell y SUN

Aprobado por X/Open, organización de estándares en el mundo UNIX

Basado en estándares de facto de la industria como X.11, Motif y Tooltalk

o Java Swing

Java permite la ejecución de un mismo programa en distintas plataformas utilizando la interfaz gráfica correspondiente, gracias al AWT (Abstract Window Toolkit)

Con la aparición del conjunto de componentes Swing, parte de las JFC (Java Foundation Classes), se dispone de una apariencia gráfica propia, denominada Metal

Además de Metal existen otras apariencias:como:

o Motif look and feel

o Windows look and feel

o MacOs look and feel

Guias de estilo Corporativas

Contienen directrices que se concretan a muy bajo nivel

Ayudan a las empresas a dar un mismo estilo a todos sus productos

Si una organización desea desarrollar su propio estilo corporativo, primero ha de escoger una guía de estilo comercial

Esta guía se aumenta con unas características propias que produzcan una

Guía deestilodelproducto

Guía deestilodelproducto

Guía deestilodelproducto

Guías de estilo de la suite de productos

Guías de estilo corporativas

Guías de diseño de las plataformas (Windows, OS/2, UNIX)

Estándares internacionales (ISO, DIN)

o Guías de estilo (CUA)

Estándar de facto desarrollado por IBM y Microsoft

Define los componentes de la interfaz que deben mantenerse entre aplicaciones

Objetivos:

Usabilidad y consistencia de la aplicación

Consistencia entre aplicaciones

o Sistema de ventanas CUA

o Principios básicos de diseño

Los usuarios tienen el control del diálogo

Los usuarios tienen que desarrollar un modelo conceptual de la interfaz

Uso de metáforas

Metáfora de la sobremesa: los usuarios ven carpetas y documentos, no programas y archivos. El sistema establece la asociación datos-programas

Sistema dirigido por el usuario

Consistencia

Hacer la interfaz transparente

o Modelo gráfico

Las aplicaciones comparten la pantalla

Cada una tiene asignada una parte o ventana

Ventana activa: aquella con la que el usuario interacciona

Niveles del modelo gráfico:

Presentación

o Precentacion

Representa el aspecto visual de la interfaz

Las aplicaciones tienen dos tipos de elementos que hay que presentar:

Objetos

Cualquier cosa que el usuario pueda manipular

Son el centro de atención del usuario

Acciones

Permiten al usuario crear o manipular objetos

Se realizan mediante combinaciones de menús y cajas de diálogo

o Acciones

Menús

Menús desplegables

Menús en cascada (no más de dos niveles)

Cajas de diálogo

Presentan/recogen información

Ventana móvil de tamaño fijo

Aparece durante el procesamiento de una acción del usuario, cuando serequiere información para completarla

Se utiliza una elipsis (...) tras el nombre del botón o elemento de menú que abre la caja

No usan menús. Usan botones para llamar a las acciones

Botones: confirmar, cancelar, ayuda

Tipos de cajas de diálogo

No modal

Permite a los usuarios continuar con su trabajo sin completar el diálogo

Modal

Requiere que los usuarios completen la caja de diálogo antes de continuar

Acciones

Caja de mensajes

Es un tipo especial de caja de diálogo que se utiliza exclusivamente para mostrar mensajes a los usuarios

o Interacción

Es el nivel a través del cual los usuarios interaccionan con los componentes de la interfaz

Consta de:

Selección de objeto

Los usuarios apuntan a un objeto que desean manipular y lo seleccionan de manera visible

Ejecución de la acción

Se selecciona una opción de menú y si es preciso se completa con una caja de diálogo

La ejecución de la acción debe ser visualiza

Consta de :

Selección de objeto

Los usuarios apuntan a un objeto que desean manipular y lo seleccionan de manera visible

Ejecución de la acción

Se selecciona una opción de menú y si es preciso se completa con una caja de diálogo

La ejecución de la acción debe ser visualizada

Selección del objeto

Ejecución del objeto

o Facetas de un interfaz:

Significado: es la base del interfaz. Recoge el contenido o información de la pantalla. Textos, campos de formularios, botones, menús.

Comportamiento: trata el funcionamiento del interfaz. Cómo se comporta cuando un usuario envía un formulario (validaciones), hace clic en un enlace.

Aspecto: apariencia final de un sistema: colores, tipografía, disposición de los elementos en pantalla (layout). Las Guías de Estilo, generalmente se centran en el “Aspecto”. Puntos como diseño y maquetación (colores, tipografías y píxeles), y apenas incluye criterios o casuística para aplicar en el proceso de diseño de interfaz

Consideraciones

Los estándares y guías proporcionan una base sobre la cual realizar el diseño y desarrollo

Sin embargo, el uso de guías no garantiza que la interfaz sea usable

Es mejor seguir las guías que no hacerlo. Puede que podamos hacer un diseño mejor sin guías, pero son muchas más las ventajas que aportan que las desventajas

Es conveniente dar facilidades a los diseñadores y programadores:

Proporcionar ejemplos en la documentación.Incorporar las guías a las herramientas

Dar formación y entrenamiento