SG #17

Redes de Datos de Sensores. Metodología para la Recolección, Administración y Presentación de Datos.

Anonymous — Wed, 28 Nov 2007 23:04:35 +0000

Redes de Datos de Sensores. Metodología para la Recolección, Administración y Presentación de Datos. Anonymous Wed, 11/28/2007 - 17:04

Publicado en

SG #17

Infraestructura

Autor

Paul Manchego

Una red de sensores consiste de un número de nodos que combinan capacidades de medición física como temperatura o concentración de algún elemento, con capacidades de interconexión y computación. Algunas redes, como las que monitorean el medio ambiente, consisten de muchos nodos que generan datos cada segundo haciendo el total de volumen de datos generados muy grande. Sin embargo para la mayoría de aplicaciones, las mediciones de sensores individuales son de menor importancia y los usuarios están generalmente más interesados en extractos que combinan un conjunto de mediciones de datos de sensores en una estadística más simple y sólida. Es por ello que muchas organizaciones que administran redes de sensores usan la Internet para publicar dichos extractos y de esta forma facilitar su uso.

Una de las tendencias actuales de recolección de datos usada por la comunidad científica es la iniciativa de las librerías digitales distribuidas. Las librerías digitales permiten a las organizaciones cooperar en proyectos comunes, reuniendo su información en un portal de recursos compartidos. Sin embargo, estas soluciones podrían no ser adecuadas para organizaciones que no desean hacer públicos sus repositorios de datos. Ante este problema, en el presente artículo explico como estructurar un sistema de administración de datos de sensores dentro de un esquema de federación.

Federación de Redes de Sensores

Para proteger la autonomía de las fuentes de datos podemos aplicar una federación de redes de sensores. Una implementación prototipo usando tecnologías Web ha sido desarrollada para un proyecto holandés denominado “Laboratorio de Escuela Virtual” el cual tiene como objetivo primordial crear una federación de diversas redes de sensores para permitir usar sus datos para propósitos educativos.

Federación es un modelo organizacional usado para agrupar socios independientes que están de acuerdo en seguir ciertos estándares y practicas de negocio para cumplir un objetivo común. Este modelo organizacional se ha utilizado desde hace siglos en diferentes ámbitos, y es una excelente opción para este caso.

En mi visión, los participantes de una federación de redes de sensores pueden ser agrupados de acuerdo a sus roles en:

Productores de datos. Son redes de sensores independientes que desean participar en la federación. Las redes de sensores generalmente proporcionan registros con la fecha, hora y ubicación junto con los datos de observación que sus nodos capturan.
Consumidores de datos. Son organizaciones privadas tales como escuelas, universidades, etc. que desean usar datos de sensores para propósitos educativos y de investigación.
Proveedores de servicios. Son entidades que pueden consumir y procesar datos de sensores para producir información más útil, es decir con mayor valor agregado.
Operadores. Administran la operación.

Utilizando esquemas de XML podemos publicar descripciones formales de las capacidades, ubicación e interfaces de los sensores asi como sus propias observaciones. Clientes y servidores en Internet pueden interpretar datos XML permitiendo la evaluación de los datos. En este contexto, el sistema de administración de datos de sensores facilitará las tareas de gestión de los distintos participantes de la federación.

Sistema de Administración de Datos

Pasemos ahora a como podría operar un sistema de administración de datos de sensores federado. En una federación con un número considerable de redes de sensores independientes, los datos de sensores pueden ser primero reunidos en un almacén de datos persistente y luego ser publicados para los consumidores. Esta solución de almacenamiento de datos central permitiría que los datos de sensores estén siempre disponibles y asegura niveles aceptables de calidad de servicio para los consumidores. Además, la federación no debe estar limitada a un conjunto pequeño de interfaces para redes de sensores específicas. Esta debe crecer dinámicamente y soportar un rango amplio de fuentes de datos. Dicha solución debe soportar los siguientes servicios:

Registro de fuentes de datos. En la federación, las nuevas fuentes de datos deben ser registradas a través del sistema de administración de datos de sensores. Una vez que la fuente es registrada en el sistema, los datos pueden ser recolectados periódicamente además de ser procesados y presentados en formatos de fácil visualización. Esto es posible debido a que el sistema posee un servicio de recolección de datos que permite la interacción con diversas fuentes de datos a través de Internet.
Recolección de datos. Dos mecanismos son posibles para la recolección de datos. El primero denominado “push” permite que bloques de datos sean enviados desde la fuente hasta el repositorio persistente. El segundo es denominado “pull” y permite que mensajes de consulta especiales puedan ser enviados directamente a las fuentes de datos. Estos mensajes de consulta pueden estar limitados a simples tareas predefinidas tales como “obtener el estado actual del sensor”. En la federación, las redes de sensores que usan el mecanismo “pull” poseen servicios web como una puerta para el mundo exterior. Esta solución también es denominada virtualización de redes de sensores. Asimismo, si las redes de sensores no desean lidiar con la complejidad de construir servicios web, ellas pueden usar el mecanismo “push” para enviar sus datos directamente al repositorio central. Aunque estas redes de sensores no necesitan construir sus propios servicios web, deben poseer una estación base capaz de usar servicios web remotos suministrados por la federación y que serán usados para enviar datos.

El servicio de recolección de datos posee un diseño extensible basado en adaptadores. Los adaptadores son generados dinámicamente y permiten al sistema capturar datos de sensores desde las diversas fuentes. Los adaptadores están basados en clases “Proxy” que encapsulan las complejidades de usar un servicio web y expone dicha complejidad a través de una simple interfaz. Durante el proceso de registro de una fuente de datos, el sistema obtiene toda la información necesaria para la generación de su adaptador asi como la descripción XML de su servicio Web (WSDL). Dicha información es luego usada por el sistema para invocar los diversos métodos que el servicio Web de la fuente de datos posee.

La figura 1 muestra una representación esquemática del registro, recolección y presentación de los datos de sensores. La figura 2 muestra una representación esquemática de los datos enviados por un teléfono celular con conexión a Internet y con la capacidad de medir concentraciones de monóxido de carbono (CO) en el ambiente.

Figura 1. Proceso de registro, recolección y presentación de datos

Figura 2. Ejemplo de una arquitectura

Bio

Paul Manchego es Master en Ciencias de la Computación. Realizó sus estudios en la Universidad de Amsterdam, Holanda. Ha participado en numerosos proyectos de investigación científica en las área de Computación Grid y Telemáticas Aplicadas. Actualmente se desempeña como Arquitecto de Sistemas en la empresa Dextra Technologies.

SQLite: La Base de Datos Embebida

Anonymous — Wed, 28 Nov 2007 20:32:35 +0000

SQLite: La Base de Datos Embebida Anonymous Wed, 11/28/2007 - 14:32

Publicado en

SG #17

Herramientas y Tecnologías

Autor

Filein Rómmel

El uso de las bases de datos ya se ha extendido de los servidores hacia los dispositivos móviles. El desarrollo constante de la tecnología conjuntamente con los nuevos requerimientos de las empresas ha llevado a crear diversos métodos de almacenamiento de información en dispositivos móviles, embebidos y empotrados.

La demanda de bases de datos para dispositivos móviles como PDAs y teléfonos celulares ha crecido exponencialmente en los últimos años debido a la necesidad de las empresas de tener la información al instante de lo que sucede en el campo y así responder más rápidamente ante la competencia. Esta necesidad ha provocado que el almacenamiento de los datos en estos dispositivos haya mejorado tanto en capacidad como en herramientas. Gracias a esto, actualmente contamos con diversas opciones de manejadores de bases de datos para móviles, y una de mis favoritas es SQLite, que es en la que se enfoca este artículo.

¿Qué es SQLite?

SQLite es una herramienta de software libre, que permite almacenar información en dispositivos empotrados de una forma sencilla, eficaz, potente, rápida y en equipos con pocas capacidades de hardware, como puede ser una PDA o un teléfono celular. SQLite implementa el estándar SQL92 y también agrega extensiones que facilitan su uso en cualquier ambiente de desarrollo. Esto permite que SQLite soporte desde las consultas más básicas hasta las más complejas del lenguaje SQL, y lo más importante es que se puede usar tanto en dispositivos móviles como en sistemas de escritorio, sin necesidad de realizar procesos complejos de importación y exportación de datos, ya que existe compatibilidad al 100% entre las diversas plataformas disponibles, haciendo que la portabilidad entre dispositivos y plataformas sea transparente.

Historia

SQLite apareció en mayo del año 2000 de la mano de su creador D. Richard Hip, quién ha liberado las diferentes versiones de SQLite en base a la licencia GPL por lo que su código es de dominio público y puede ser modificado por cualquier persona. Gracias a esto, SQLite ha sido mejorada a lo largo de 7 años por un gran número de colaboradores y también ha sido migrada a diversas plataformas.

Características

Estas son algunas de las características principales de SQLite:

La base de datos completa se encuentra en un solo archivo.
Puede funcionar enteramente en memoria, lo que la hace muy rápida.
Tiene un footprint menor a 230KB.
Es totalmente autocontenida (sin dependencias externas).
Cuenta con librerías de acceso para muchos lenguajes de programación.
Soporta texto en formato UTF-8 y UTF-16, así como datos numéricos de 64 bits.
Soporta funciones SQL definidas por el usuario (UDF).
El código fuente es de dominio público y se encuentra muy bien documentado.

Plataformas de SQLite

SQLite está construida en C, lo cual facilita la migración a diversas plataformas de sistemas operativos y de dispositivos. Dado que una base de datos de SQLite se almacena por completo en un solo archivo, está puede ser exportada a cualquier otra plataforma y tener interoperatibilidad al 100% sin ningún requerimiento de programación adicional o cambios de configuración.

Las plataformas principales dónde SQLite se encuentra funcionando son:

Windows 95, 98, ME, 2000, XP y Vista
Windows CE & Pocket PC
Mac OSX
Linux
OpenEmbedded
PalmOS
Symbian

Lenguajes de Programación de SQLite

Gracias a que SQLite es software libre, es posible encontrar una gran cantidad de componentes, librerías y drivers para interactuar con SQLite desde una gran diversidad de lenguajes y plataformas de programación. Ya sea que estemos utilizando lenguajes modernos como Java, Perl, Python, PHP, Ruby, C#, lenguajes más antiguos como Pascal, SmallTalk, Clipper, o lenguajes poco conocidos como Suneido, REXX, S-Lang, para todos podemos encontrar librerías y ejemplos de código para SQLite.

http://www.sqlite.org/cvstrac/wiki?p=SqliteWrappers ofrece más información sobre “wrappers” para SQLite sobre diferentes plataformas y lenguajes.

Aplicaciones de SQLite

Las características y plataformas previamente mencionadas hacen de SQLite una excelente opción en diversos casos tales como:

Cuando se requiere una base de datos integrada dentro de una aplicación. SQLite es una excelente opción por su facilidad de configuración. El inconveniente es que no escala a bases de datos demasiado grandes (en el orden de los terabytes).
Para realizar demostración de aplicaciones que utilizan un RDBMS (¿Para que utilizar un manejador de BD pesado que ocupa grandes recursos de sistema cuando solo se requiere hacer un demo de una aplicación?)
Como cache local de un manejador de base de datos empresarial. Esto acelera el tiempo de respuesta y reduce la carga sobre la base de datos central.
Para aplicaciones en dispositivos móviles que manejan una BD local que se sincroniza por batch con una base de datos remota.
Almacenamiento persistente de objetos, configuraciones y preferencias de usuario. Permite fácilmente crear una estructura para almacenar configuraciones de la aplicación.

¿Y en México?

Actualmente podemos citar diversas aplicaciones que ya se han desarrollado para el mercado móvil en México. Por ejemplo en el estado de Veracruz en la zona cañera de Lerdo de Tejada, al sur del estado veracruzano, algunos ingenios ya cuentan con un sistema de captura de datos móvil el cuál usa SQLite para capturar en terminales móviles la información en sitio, y posteriormente a través de GPRS se envía la información a la base central del ingenio. Esta base central utiliza un motor propietario, pero gracias a la interoperatibilidad de SQLite es posible manejar la misma estructura de datos en la Terminal móvil con SQLite, que en la base de datos central con el motor propietario. Esta aplicación ha permitido a estos ingenios tener la información al instante desde las zonas cañeras, lo que se ve reflejado en la calidad de la caña que se introduce al batey, ya que entre más fresca entre la caña al ingenio, más rendimiento puede tener y por lo tanto se eleva la producción de azúcar. Otra de las ventajas de la aplicación móvil es evitar que los jefes de zona regresen al final de la jornada a capturar un par de horas más toda la información recolectada durante el día en zonas cañeras ubicadas a veces hasta más de 100 km del ingenio.

Aquí entre nos…

SQLite es una base de datos muy eficaz para cualquier desarrollo en ambientes embebidos, pues ofrece un alto rendimiento, eficacia, seguridad, estandarización e inter operabilidad. Todo esto la ha catapultado a convertirse en la base de datos de facto para desarrollos móviles y empotrados.

Referencias y Recursos

Michael Owens. “The Definitive Guide to SQLite”. Mayo 2006, Apress.
http://www.sqlite.org
http://sqlite.phxsoftware.com
http://www.superwaba.com
http://php.net/sqlite
http://sqlite-wince.sourceforge.net
http://www.mono-project.com/SQLite

Bio

Filein Rómmel León es líder de proyectos en la empresa Dynamic Logistics. Ha desarrollado soluciones móviles y embedded bajo entornos como .NET Compact Framework , J2ME, SuperWaba y Embedded C++, utilizando diferentes tecnologías de comunicación como IrDA y Bluetooth, WiFi, GPRS y RFID. f.leon@dynamic-logistics.com.mx

Entrevista con Orlando Rincón

Anonymous — Wed, 28 Nov 2007 20:28:17 +0000

Entrevista con Orlando Rincón

Anonymous Wed, 11/28/2007 - 14:28

Publicado en

SG #17

Entrevista

Orlando es una de las personas más interesantes que puedes llegar a conocer. Es una mezcla de hacker, empresario y altruista. En 1984, fundó Open Systems Ltd, una de las empresas de tecnología más exitosas en Colombia, con ventas anuales superiores a los 10 millones de dólares. Durante el tiempo que estuvo al frente de esta empresa, se convenció de que su país necesitaba una nueva generación de emprendedores con visión social. Fue así que en 1999 vendió su participación en Open Systems y fundó ParqueSoft, una incubadora de empresas de tecnología.

Actualmente ParqueSoft alberga más de 100 empresas que desarrollan proyectos en sistemas geográficos, animación digital y CRM, entre otros, acumulando ventas anuales superiores a los 50 millones de dólares. Pero lo que más inspira de ParqueSoft, es que el promedio de edad de los integrantes es inferior a los 24 años y en su mayoría provienen de clases sociales populares.

Así que piénsalo dos veces antes de juzgar a este señor despelucado, vestido en jeans y camiseta.

Eres ingeniero en sistemas con estudios de antropología. ¿Cómo se relacionan estos campos?
En la universidad donde yo estudié, un ingeniero de sistemas es concebido fundamentalmente como un administrador con bases científico-matemáticas, una persona capaz de modelar sistemas y de obtener eficiencia en sistemas. No necesariamente en sistemas de información sino sistemas en general, obviamente con una base computacional importante porque finalmente termina siendo el instrumento definitivo. Debido a mí deseo de trabajar fundamentalmente sobre sistemas sociales y a que el principal componente de estos es el ser humano, estudié antropología, que estudia la cultura de las sociedades y organizaciones humanas. Esa es la mezcla fundamental entre un ingeniero de sistemas y un antropólogo, son disciplinas complementarias para trabajar en sistemas y ecosistemas que pueden ser modelados como herramientas científicas alrededor de los seres humanos.

¿Qué te motivó a realizar algo como ParqueSoft?
ParqueSoft responde a una necesidad muy grande que siempre estuvo presente en mi vida: hacer un gran proyecto social. Desde joven, cuando fui líder estudiantil, tuve muchas inquietudes por contribuir a mejorar los sectores populares y producir igualdad social. Siempre tuve mucha inquietud por el tema de la ciencia y la tecnología como un enorme vehículo para reducir todas estas diferencias que se presentan en nuestros territorios latinoamericanos. ParqueSoft es un gran proyecto social que responde especialmente a esa visión de construir un espacio donde las nuevas generaciones puedan, a través de sus contactos con el arte, la ciencia y la tecnología, desarrollar propuestas de economía para acortar estos caminos de diferencia social que hay en América Latina, como una respuesta democrática diferente a los mecanismos tradicionales que se han usado como resistencia popular.

¿Cómo se compara ParqueSoft con esfuerzos similares en otros países?
A pesar de que tenemos el perfil de incubadora de empresas, no seguimos los métodos formales de las incubadoras. Las incubadoras tradicionales se basan en un business plan y metodologías basadas en la administración de negocios. ParqueSoft basa todo su ecosistema fundamentalmente en la fuerza y la diferencia genética de los emprendedores que lideran sus células económicas. ParqueSoft también se diferencia muchísimo de iniciativas similares porque a su vez es un gran centro de formación de talento humano, de investigación, de prácticas de producción con calidad a altísimo nivel. Pero más que nada es un gran centro de convergencia donde se articulan muchos temas, lo que hace que termine siendo un gran centro de relaciones sociales que terminan siendo un acelerador de negocios. Otra diferencia está en el enfoque generacional: mientras otras incubadoras trabajan transversalmente con todas las generaciones, ParqueSoft tiene su foco en las nuevas generaciones que son finalmente un gran acelerador por sus capacidades de educación e innovación, así como la capacidad de energía que tienen para aplicarle a sus proyectos.

¿Consideras que los latinoamericanos tenemos características antropológicas que podamos explotar como fortalezas para
desarrollar software?
Creo que todas la personas que vivimos en países en vías de desarrollo tenemos una gran oportunidad en esta industria. Nuestros ecosistemas urbanos y rurales son ecosistemas que no están planeados, y esto implica que las personas deben constantemente sobreponerse a su entorno, lo cual demanda que todo el tiempo se estén construyendo nuevos algoritmos, que se esté innovando sobre ellos y se produzcan eficiencias no con los métodos tradicionales sino con respuestas naturales. Por esto, pienso que toda América Latina es un gran ecosistema para la innovación, especialmente en torno a la algoritmia en la ingeniería de sistemas. Aquellos que logran educarse y logran conseguir las bases de estas ciencias y de estas tecnologías tienen una gran ventaja competitiva gracias a que viven en estos ecosistemas, especialmente para proponer nuevos sistemas de alta innovación.

En México vivimos el problema de que cada vez hay menos personas interesadas en la ciencia e investigación. ¿Tienes sugerencias de que hacer para revertir esta tendencia?
Este no es un problema único de México, es un problema global. Las nuevas prácticas de vida, los medios de comunicación y las plataformas culturales sobre las cuales se están construyendo los tejidos humanos, cada vez hacen menos interesante la ciencia y la tecnología para los niños y los jóvenes. Todos los gobiernos deben hacer esfuerzos para recuperar ese interés y gusto por las ciencia básicas.

Gracias a las TICs hoy se puede establecer, con inversiones mínimas, centros que produzcan inclusión digital y fomenten el gusto hacia la ciencia y la tecnología. En Colombia hemos desarrollado proyectos orientados a los sectores populares para poder aproximar a los niños y a los jóvenes a la ciencia y la tecnología.

Se ha creado una nueva era, la del Edutainment, la era de la educación + el entretenimiento, que combinadas con TICs, pueden producir un gusto por la ciencia y la tecnología muy diferente al que se producía en los 80s o 90s. ParqueSoft tiene una gran propuesta para ello denominada ParqueSapienx: parques de inclusión digital que aproximan a los jóvenes hacia el arte digital, la ciencia y la tecnología. Creo que en todos los países de América Latina debemos hacer enormes esfuerzos de invertir en esto, especialmente donde están las grandes concentraciones de nuestra población, que es en los sectores populares. Esto ya está desarrollado, es muy fácil de implementar, requiere pocos esfuerzos y su impacto es muy grande. Por un parque de estos pueden pasar diariamente 5 mil, 6 mil niños para tener una población impactada al mes de ciento cincuenta mil a doscientos mil jóvenes que experimentan, trabajan y se entretienen con estos instrumentos de ciencia y tecnología y finalmente terminan divirtiéndose en este entorno y logrando una gran proximidad con este paradigma del siglo XXI.

¿Qué mensaje dejas a nuestros lectores?
Mi mensaje es que no solamente piensen en lo que ellos están haciendo. Yo creo que todos los que trabajamos en la industria de TICs no sólo debemos pensar en el presente, sino trabajar en el futuro. Por eso es tan contundente y determinante que pensemos en las nuevas generaciones. Hay que hacer que los sistemas de información, la Ingeniería de Sistemas, las ciencias de la computación cada vez penetren a más sectores de la población, y en todos los niveles escolares. De ahí que todos los que de alguna u otra manera hemos tomado algo de conocimiento o ventaja competitiva entorno a este tema, debemos hacer enormes esfuerzos para juntarnos y masificar el conocimiento sobre las TICs, su potencial y todo lo que pueden representar para la evolución de nuestras sociedades y el desarrollo de nuestros países. Por eso es tan importante que todos los que tienen conocimiento directo con los sistemas de información, estén concientes del enorme poder que representan las tecnologías de la información frente al reto del siglo XXI, y que hagamos un esfuerzo por trabajar de múltiples maneras para producir inclusión digital y llevar tecnologías de información a los mayores sectores de la población tanto civil como de los sectores productivos, pequeñas empresas y gobierno. Esta es una gran propuesta alrededor de las TICs que produciría una gran aceleración en el desarrollo de América Latina.

Obtención de Requerimientos. Técnicas y Estrategia

Anonymous — Wed, 28 Nov 2007 19:58:22 +0000

Obtención de Requerimientos. Técnicas y Estrategia Anonymous Wed, 11/28/2007 - 13:58

Publicado en

SG #17

Requerimientos

Autor

César Arturo Guerra

Como sabemos, un área de conocimiento de gran importancia en el desarrollo de software, es la ingeniería de requerimientos. Esta comprende las actividades de obtención (captura, descubrimiento y adquisición), análisis (y negociación), especificación, y validación de requisitos. Además, establece una actividad de gestión de requerimientos para manejar los cambios, mantenimiento y rastreabilidad de los requerimientos.

El proceso de obtención de requisitos, cuya finalidad es llevar a la luz los requisitos, no solo es un proceso técnico, sino también un proceso social que envuelve a diferentes personas, lo que conlleva dificultades añadidas a su realización.

Técnicas Para la Obtención de Requerimientos

Existe un gran número de técnicas para obtener requerimientos. A continuación describo las más utilizadas. Hay que aclarar que ninguna de estas técnicas es suficiente por sí sola y que es recomendable combinarlas para obtener requerimientos completos.

Entrevistas

La entrevista es de gran utilidad para obtener información cualitativa como opiniones, o descripciones subjetivas de actividades. Es una técnica muy utilizada, y requiere una mayor preparación y experiencia por parte del analista. La entrevista se puede definir como un “intento sistemático de recoger información de otra persona” a través de una comunicación interpersonal que se lleva a cabo por medio de una conversación estructurada. Debe quedar claro que no basta con hacer preguntas para obtener toda la información necesaria. Es muy importante la forma en que se plantea la conversación y la relación que se establece en la entrevista.

Estos son algunos de los aspectos más importantes a tener en cuenta al realizar entrevistas:

Preparación. Es necesario documentarse e investigar la situación de la organización analizando los documentos disponibles, de tal forma que la entrevista se enfoque en aquellos aspectos que están solamente en la mente del entrevistado y que no son accesibles por otros medios como la observación o el análisis de documentos.
Entrevistar al personal adecuado. La mayoría de los analistas adoptan un enfoque top-down, comenzando a entrevistar a directivos para que brinden un panorama general de hacia donde deberían ir las cosas, y terminando por hablar con los empleados que aportan detalles importantes de la operación.
Duración. Una entrevista debería durar a lo sumo un par de horas.
Formato. Se recomienda utilizar preguntas abiertas, donde los entrevistados puedan elaborar y dar detalles, más allá de simplemente responder “si” o “no”.

Desarrollo Conjunto de Aplicaciones ( JAD )

Es una técnica que se utiliza para promover la cooperación y el trabajo en equipo entre usuarios y analistas. Consiste en realizar sesiones en las que participan usuarios expertos del dominio junto a analistas de software. La idea es aprovechar la dinámica de grupos aplicando un proceso de trabajo sistemático y organizado, apoyado por elementos visuales de comunicación y comprensión de soluciones.

Las razones que sirven de base a JAD son las siguientes:

Las entrevistas requieren mucho tiempo, no solo en prepararlas y hacerlas sino también en redactar un conjunto de requisitos coherente a partir de opiniones diferentes de los distintos entrevistados.
Es más difícil apreciar posibles errores en la especificación de requisitos, ya que sólo el analista revisa el documento. En el JAD todo el grupo puede actuar como revisor y detectar defectos.
El JAD propugna una participación más profunda de los usuarios en el proyecto, hasta tal punto que los usuarios que participan adquieren un cierto sentido de propiedad en el sistema que se construye.

El JAD no se utiliza demasiado, debido a que requiere una mayor organización que las entrevistas y porque el ambiente o los métodos de trabajo convencionales en las empresas no facilitan este tipo de actividades (falta de tiempo, dificultad de coordinación de tanta gente, dificultad para convencer a la dirección, etc.). No obstante las empresas que han implantado este método han informado de importantes ahorros de tiempo en el desarrollo de software, así como de una mayor satisfacción de los usuarios con los sistemas construidos.

Desarrollo de Prototipos

Los prototipos suelen consistir en versiones reducidas, demos o conjuntos de pantallas (que no son totalmente operativos) de la aplicación pedida. Esta técnica es particularmente útil cuando:

El área de la aplicación no está bien definida (posiblemente por ser algo muy novedoso).
El costo del rechazo de la aplicación por los usuarios es muy alto.
Es necesario evaluar previamente el impacto del sistema en los usuarios y en la organización.

Los prototipos de sistema permiten a los usuarios experimentar para ver cómo éste ayuda a su trabajo. Fomentan el desarrollo de ideas que desembocan en requerimientos. Además de permitir a los usuarios mejorar las especificaciones de requerimientos, el desarrollo de un prototipo tiene otras ventajas:

Al demostrar las funciones del sistema se identifican las discrepancias entre los desarrolladores y los usuarios.
Durante el desarrollo del prototipo, el personal del desarrollo de software puede darse cuenta de que los requerimientos son inconsistentes y/o están incompletos.
Aunque limitado, se dispone rápidamente de un sistema que funciona y demuestra la factibilidad y usabilidad de la aplicación a administrar.
El prototipo se utiliza como base para escribir la especificación para la producción.

En general, el uso de esta técnica es un medio que permite solventar objeciones del usuario del tipo: “No sé exactamente lo que quiero, pero lo sabré cuando lo vea”. Por lo general, la construcción de prototipos incrementa los costos en las etapas iniciales de un proyecto, pero esto se recupera en etapas posteriores gracias al mejor entendimiento de los requerimientos por parte de los desarrolladores. En algunos casos también se utiliza como un medio para formalizar la aceptación previa del cliente de los requisitos del proyecto.

Observación

Por medio de esta técnica el analista obtiene información de primera mano sobre la forma en que se efectúan las actividades. Este método permite observar la forma en que se llevan a cabo los procesos y, por otro, verificar que realmente se sigan todos los pasos especificados. Como sabemos, en muchos casos los procesos son una cosa en papel y otra muy diferente en la práctica. Los observadores experimentados saben qué buscar y cómo evaluar la relevancia de lo que observan.

Estudio de documentación

Varios tipos de documentación, como manuales y reportes, pueden proporcionar al analista información valiosa con respecto a las organizaciones y a sus operaciones. La documentación difícilmente refleja la forma en que realmente se desarrollan las actividades, o donde se encuentra el poder de la toma de decisiones. Sin embargo, puede ser de gran impotancia para introducir al analista al dominio de operación y el vocabulario que utiliza.

Cuestionarios

El uso de cuestionarios permite a los analistas reunir información proveniente de un grupo grande de personas. El empleo de formatos estandarizados para las preguntas puede proporcionar datos más confiables que otras técnicas; por otra parte, su amplia distribución asegura el anonimato de los encuestados, situación que puede conducir a respuestas más honestas.

El inconveniente es que la respuesta puede ser limitada, ya que es posible que no tenga mucha importancia para los encuestados llenar el cuestionario. Es recomendable conseguir apoyo de la alta dirección para solicitar a las personas de la organización que contesten el cuestionario.

Al igual que con las entrevistas, se debe seleccionar a los encuestados. El analista debe asegurar que el conocimiento y experiencia de éstos califiquen para dar respuestas a las preguntas.

Tormenta de ideas ( Brainstorming )

Consiste en reuniones con cuatro a diez personas donde como primer paso sugieren toda clase de ideas sin juzgar su validez –por muy disparatadas que parezcan–, y después de recopilar todas las ideas se realiza un análisis detallado de cada propuesta. Esta técnica se puede utilizar para identificar un primer conjunto de requisitos en aquellos casos donde no están muy claras las necesidades que hay que cubrir, o cuando se esta creando un sistema que habilitará un servicio nuevo para la organización.

ETHICS ( Implementación Efectiva de Sistemas Informáticos desde los puntos de vista Humano y Técnico )

Constituye un método bastante evolucionado para fomentar la participación de los usuarios en los proyectos. Creado por E. Mumford en 1979, coordina la perspectiva social de los sistemas con su implementación técnica. Un sistema no tiene éxito si no se ajusta a los factores sociales y organizacionales que rigen a la empresa. Se busca la satisfacción de los empleados en el trabajo a través de estudios integrales. Los requisitos técnicos del sistema serán los necesarios para mejorar la situación de los empleados (y, por lo tanto, su productividad) en función de dichos análisis.

Puntos de Vista

Cualquier sistema de software no trivial debe satisfacer las necesidades de un grupo diverso de interesados (stakeholders). Cada uno de estos puede tener intereses diferentes en el sistema de software, y por lo tanto sus necesidades pueden generar requerimientos que tengan conflicto entre sí, o incluso se contradigan.

Los métodos orientados a puntos de vista (viewpoints) toman en consideración estas perspectivas diferentes y las utilizan para estructurar y organizar tanto el proceso de obtención, como los requerimientos mismos. Uno de estos métodos es el método VORD (Definición de Requerimientos Orientado a Puntos de Vista), el cual provee un marco de trabajo orientado para la obtención y documentación de requerimientos. Las etapas principales de este método son:

Identificación de puntos de vista, que implica descubrir los que reciben los servicios del sistema e identificar los servicios específicos que se suministran a cada punto de vista.
Estructuración de puntos de vista, que comprende agrupar los relacionados en una jerarquía. Los servicios comunes se ubican en los niveles altos de la jerarquía y se heredan los puntos de vista de bajo nivel.
Documentación de puntos de vista, que comprende refinar la descripción de éstos y los servicios identificados.
Trazado del punto de vista del sistema, que comprende identificar los objetos en un diseño orientado a objetos utilizando la información del servicio encapsulado en los puntos de vista.

Escenarios

Estos se utilizan para documentar el comportamiento del sistema cuando se le presentan eventos específicos. Cada evento de interacción distinto, o la selección de un servicio del sistema, se documentan como un escenario de eventos distinto. Los escenarios de eventos incluyen una descripción del flujo de datos y las acciones del sistema, y documenta las excepciones que puedan surgir.

Las convenciones para los diagramas utilizados en los escenarios de eventos son:

Los datos proporcionados desde un punto de vista o proporcionados a éste se representan como elipses.
Las entradas y salidas de la información de control se ubican en la parte superior de cada recuadro.
Las salidas de datos se ubican a la derecha de cada recuadro. Si no están encerradas, significa que pertenecen al sistema.
Las excepciones se muestran en la parte inferior del recuadro. Si existen varias excepciones posibles, éstas se encierran en un recuadro.
El nombre del siguiente evento esperado después de completar el escenario se muestra en un recuadro sombreado.

Los Casos de Uso son una técnica que se basa en escenarios para la obtención de requerimientos. Actualmente se han convertido en una técnica fundamental que se utiliza para analizar y describir modelos de sistemas orientados a objetos. En su forma más simple, un caso de uso identifica a los actores involucrados en una interacción y nombra al tipo de ésta.

Etnografía

Los sistemas de software no existen de forma aislada; se utilizan en un contexto social y organizacional, y los requerimientos de sistemas de software se derivan y se restringen acorde a ese contexto. Satisfacer esos requerimientos sociales y organizacionales es crítico para el éxito del sistema. Una razón de por qué muchos sistemas de software se entregan pero nunca se utilizan es porque no se toma en cuenta la importancia de este tipo de requerimientos.

La etnografía es una técnica de observación que se puede utilizar para entender los requerimientos sociales y organizacionales. Un analista se sumerge por sí solo en el entorno laboral donde el sistema se utilizará. El trabajo diario se observa y se hacen notas de las tareas reales en las que los participantes están involucrados. La etnografía es especialmente efectiva para descubrir dos tipos de requerimientos:

Los requerimientos que se derivan de la forma en la que la gente trabaja realmente más que de la forma en la que las definiciones de los procesos establecen que debería trabajar.
Los requerimientos que se derivan de la cooperación y conocimiento de las actividades de la gente.

Los estudios etnográficos pueden revelar los detalles de los procesos críticos que otras técnicas de obtención de requerimientos a menudo olvidan. Sin embargo, puesto que se centran en el usuario final, este enfoque no es apropiado para descubrir los requerimientos organizacionales o del dominio. La etnografía tampoco está diseñada para identificar nuevas propiedades a agregar al sistema. Por lo tanto, la etnografía no es un enfoque completo para la obtención de requerimientos y debe utilizarse en conjunto con otras técnicas, como el análisis de casos de uso.

Estrategia para la obtención de requerimientos

Hemos descrito un número considerable de técnicas para la obtención de requerimientos. A continuación sugiero una estrategia de cómo aplicar estas técnicas dentro de un proceso ordenado y que aproveche al máximo cada técnica. Esto evitará que los analistas con poca experiencia caigamos en un error muy común, que es el de pasar demasiado pronto a las entrevistas, lo cual es un desperdicio de tiempo.

Los pasos de la estrategia sugerida son:

Aprender todo lo que se pueda de los documentos, formularios, informes y archivos existentes. Es sorprendente lo que se puede aprender de un sistema sin necesidad de quitarle tiempo a la gente.
De ser posible, se observará el sistema en acción. No se plantearán preguntas. Tan sólo se observará y se tomarán notas o dibujos. Conviene asegurarse de que las personas observadas saben que no se les está evaluando. En caso contrario, harán su trabajo de manera más eficaz que lo normal.
Diseñar y distribuir cuestionarios para aclarar cuestiones que no se comprenden bien. Será también buen momento para solicitar opiniones sobre los problemas y las limitaciones. Los cuestionarios requieren que los usuarios inviertan una parte de su tiempo. Pero son ellos los que pueden elegir cuándo les viene mejor hacerlo.
Realizar entrevistas (o sesiones de trabajo en grupo, como JAD). Como ya se ha recogido una base de requerimientos iniciales en los pasos anteriores, se pueden utilizar las entrevistas para verificar y aclarar las cuestiones y los problemas de mayor dificultad. En este punto se pueden llegar a aplicar algunas de las otras técnicas cómo Escenarios, Tormenta de ideas, Puntos de Vista, ETHICS y Desarrollo de Prototipos.
Se verifican los requerimientos a través del uso de técnicas como Entrevistas, Observación y orientados a Puntos de Vista.

Esta estrategia no es intocable. Aunque habría que desarrollar una estrategia de investigación de hechos para todas las fases pertinentes del desarrollo de sistemas, cada proyecto tiene sus propias particularidades. A veces, la observación o los cuestionarios pueden no ser apropiados. Pero debería mantenerse la idea de recabar siempre todos los hechos que sea posible antes de concertar entrevistas.

Referencias

Flaaten, P. O., McCubbrey, D.J., O´Riordan, P.D., Burgués, K., “Foundations of Business Systems”. Chicago (EE.UU.), The Dryden Pres, 1989.
Raghavan, S., Zelesnik, G., Ford, G., “Lecture Notes on Requirements Elicitation”. CMU/SEI-94-EM-10, Pittsburgh (E.E.U.U.), Software Engineering Institute (Carnegie Mellon University), 1994.
Kontonya, G. & Sommerville I., “Requirements Engineering: Processes and Techniques”. John Wiley and Sons, 2002.
Kotonya, G. y Sommerville, I. (1996). “Requirements Engineering with viewpoints”. BCS/IEE Software Engineering J.

Bio

Cesar Arturo Guerra García es profesor-investigador en el área de Tecnologías de Información de la Universidad Politécnica de San Luis Potosí. Sus áreas de interés son Ingeniería de Software, Ingeniería de Requerimientos, Modelado de sistemas y Administración de Proyectos. Ha trabajado como desarrollador y líder de proyectos en IBM y Softtek. Egresado de la Maestría en Ciencias de la Computación del Centro de Investigación Científica y de Educación Superior de Ensenada, CICESE. guerra@upslp.edu.mx

Tips para Reclutar Desarrolladores: No se aceptan zoquetes

Anonymous — Wed, 28 Nov 2007 19:53:50 +0000

Tips para Reclutar Desarrolladores: No se aceptan zoquetes

Anonymous Wed, 11/28/2007 - 13:53

Publicado en

SG #17

Personas

Autor

Rob di Marco

En una de las empresas donde trabajé anteriormente, utilizábamos la frase “No se aceptan zoquetes” (en inglés, no chums) para describir a nuestro equipo. Siempre me gustó la simplicidad de esa frase. La verdad es que existen muchísimos zoquetes en el desarrollo de software, y pueden hacer que tu trabajo sea miserable.

Al contratar a un nuevo integrante para tu equipo, debes estar conciente de que la mayoría de los currículums que revisarás, son gente con la que no deseas trabajar. Si esto se te hace mala onda, o no estás de acuerdo, entonces espera a que pases uno o dos años trabajando con zoquetes en tu equipo, y verás si no te convences.

Entonces, la pregunta es: ¿cómo podemos evitar contratar zoquetes?

¿Qué buscar en un candidato?
Yo evalúo a los candidatos alrededor de cinco criterios:
• ¿Es inteligente?
• ¿Es curioso?
• ¿Encajará en el equipo?
• ¿Cuenta con la experiencia adecuada?
Veamos a qué me refiero con cada una de estas preguntas

¿Es inteligente?
¿Cuenta el candidato con la capacidad mental suficiente para realizar su trabajo? El desarrollo de software requiere poder solucionar infinidad de problemas: ¿Cómo debería funcionar este software? ¿Qué tecnologías debería utilizar? ¿Cuál sería una arquitectura adecuada? ¿Qué patrones podrían servir? ¿Cómo se debería probar? Estas preguntas no son triviales, y contestarlas requiere buenas habilidades analíticas, aprendizaje de nuevos conocimientos (tanto técnicos como del negocio), comprensión de herramientas, y sobre todo la capacidad de retener y organizar ideas contradictorias en tu cabeza.

El candidato también debe ser capaz de lidiar con el reto de otras personas buscando resolver el mismo problema. Al tipo de personas a las que busco, les encanta ser retadas por otras personas inteligentes.

Vale la pena hacer un paréntesis para recalcar que la inteligencia y la educación no son lo mismo. Un título es prueba de un cierto nivel de educación, pero no necesariamente es una prueba efectiva de inteligencia. Aun así, no conozco a nadie tonto que haya conseguido un doctorado del M.I.T.

¿Es curioso?
¿A nuestro candidato le interesa entender como funcionan las cosas? ¿Lee frecuentemente? ¿Ha bajado el código fuente de algún proyecto de software libre para entenderlo?

Yo busco personas que quieran entender cual es el problema de negocio que buscamos resolver, y cual es la mejor forma de resolverlo. No me interesan los autómatas que simplemente ejecutan lo que les digo. Los ingenieros más innovadores, en el fondo son personas muy curiosas, que ansían entender mejor el mundo.

¿Termina las cosas?
Tal y como dice Joel Spolsky (reconocido escritor sobre desarrollo de software): “… a veces las personas inteligentes y curiosas dedican tanto tiempo a analizar la mejor forma de atacar un problema, que olvidan la importancia de realmente hacer algo.” Bien dice la frase que entregar el 80% hoy es mejor que entregar el 100% nunca.

¿El candidato alguna vez ha entregado software a producción? Se sorprenderían de la cantidad de desarrolladores que nunca ha tenido código en sistemas en producción reales. ¿Han tenido que desarrollar un sistema bajo presión? ¿Pueden lidiar con la presión? ¿Disfrutan el sentimiento de completar algo? ¿Persisten hasta que un problema es resuelto? Es en este punto donde muchas personas que vienen de la academia y la investigación suelen fallar. La mentalidad y presión en una organización dedicada a desarrollar software profesionalmente es muy diferente a la del mundo académico.

¿Encaja en el equipo?
En el libro Peopleware, Tom DeMarco y Tim Lister describen la historia de un candidato que no obtuvo un trabajo en una empresa de software. Sucede que el candidato estaba técnicamente calificado, pero los entrevistadores consideraron que no encajaría en el equipo, porque no le parecían chistosas las mismas bromas que al resto del equipo.
Es un criterio arbitrario, pero si alguien no encajará en la dinámica del equipo, se convertirá en un cáncer y terminará afectando negativamente el desempeño del equipo. Al evaluar a un candidato, debes preguntarte ¿Me gustaría trabajar con esta persona? ¿Le entusiasmará a él trabajar con nosotros? ¿Sus experiencias (tanto en el trabajo con en su vida personal) complementan las del resto del equipo?

¿Cuenta con la experiencia adecuada?
Noten que estoy dejando para el último la pregunta de la experiencia. Es cierto que la experiencia es importante, pero creo que es sobrevaluada. Probablemente es el único criterio que una persona puede mejorar con el tiempo. En la organización donde laboro actualmente utilizamos Java 5, JBoss 4, y Maven 2. ¿Debería rechazar a un buen candidato simplemente porque no ha utilizado estas tecnologías? De ninguna manera.

Una persona inteligente y curiosa que encaje en el equipo y quiere hacer un buen trabajo puede aprender estas herramientas fácilmente. En un par de meses estará al mismo ritmo que el resto del equipo. Hay que recordar que no quiero contratar a alguien para un proyecto temporal de 3 meses. Quiero contratar a una persona que espero que se mantenga durante años en el equipo.

¿Cómo encontrar estas características?
Ahora que sabemos que buscar en una persona, vamos a ver como encontrarlo.

Paso 1: Leer el currículum

El primer paso para filtrar a los zoquetes, es analizando su currículum. Estas son algunas de las cosas en las que me fijo:
• ¿Hay algo interesante en el currículum sobre lo que me gustaría hablar (algún proyecto interesante, o logro importante)? Cuando ves un currículum y todos los logros parecen cosas que deberían requerir un esfuerzo mínimo, significa que el candidato está reprobando los criterios ya sea de inteligencia, curiosidad, o resultados.
• En el caso de recién graduados o becarios, me fijo en las clases optativas que eligieron. Si fueron clases difíciles, es porque son curiosos y les gustan los retos.
• ¿Qué tanta diversidad hay en su carrera profesional? Me gusta ver currículums de personas que han trabajado en una gran variedad de cosas. Las personas cuya experiencia esta centrada exclusivamente en una tecnología o plataforma, probablemente reprueban el criterio de la curiosidad.
• ¿El candidato ha avanzado en su carrera? Las personas inteligentes que dan resultados, no se quedan estancadas en una posición durante mucho tiempo.

Paso 2: La entrevista telefónica

Si el currículum de la persona es suficientemente interesante como para continuar, entonces el siguiente paso es el filtro telefónico. Esta es una prueba sencilla simplemente para saber si queremos invertir más tiempo en evaluar a la persona en cuestión. Algunas preguntas de ejemplo podrían ser:
• Una pregunta técnica sencilla como: “¿Cuál es la diferencia entre un list y un set?” o “¿Cuál es la diferencia entre una clase abstracta y una interfase?” Si el candidato no puede contestar eso bien, entonces no tiene mucho caso continuar.
• Una pregunta de reflexión como: “¿Cuál fue el mayor reto que enfrentaste en tu último proyecto?”, “¿Qué disfrutaste más de tu último proyecto?”, o “¿Qué quisieras haber hecho diferente en tu último proyecto?”. Los buenos candidatos acostumbran tener respuestas interesantes a estas preguntas.
• Una pregunta para saber que tan enterado esta, como: “Existen tecnologías nuevas con las que te gustaría trabajar y (por qué)?”, o “Recientemente has leído algún libro/website que haya tenido impacto en la forma en que trabajas?”. Con estas preguntas intento averiguar la curiosidad y motivación del candidato.

Recuerda que el objetivo de la entrevista telefónica es intentar detectar zoquetes, y no el de tomar una decisión final. No pierdas demasiado tiempo en esta llamada. Quince minutos debería ser tiempo suficiente detectar si esta persona es alguien con quien no te gustaría trabajar, o si vale la pena traerla para una entrevista personal.

Paso 3: La entrevista personal

El objetivo de la entrevista personal es descubrir si podemos afirmar que el candidato cumple con los cinco criterios. Durante la entrevista, deberías pensar cówmo es que las respuestas de la persona te ayudan a averiguar si cumple con los criterios. A mi me gusta que las entrevistas sean conducidas por un par de personas hablando en un ambiente informal con el candidato durante alrededor de una hora. Considero que al menos tres grupos diferentes deberían hablar con un candidato para lograr obtener un rango adecuado de opiniones. Es mejor si los grupos se ponen de acuerdo previamente sobre las áreas que van a explorar, para minimizar el traslape.

Típicamente me gusta comenzar con una pregunta sencilla para que el candidato comience a hablar, y luego ya sigo con preguntas más complicadas. Durante una entrevista, el candidato debería demostrar realmente como haría un trabajo. Por ejemplo, en el caso de estar reclutando a un desarrollador, el candidato debería escribir algo de código. Observar como programa una persona da una gran perspectiva hacia su inteligencia, creatividad y habilidad de trabajar con otros. De forma similar, un analista debería poder escribir requerimientos para un sistema ejemplo, y un project manager debería desarrollar un plan.

Las preguntas raras como “¿Cuántas gasolineras hay en la ciudad?” también pueden ser buenas, ya que pueden darnos una perspectiva a como es que esta persona piensa sobre resolver un problema. Solo asegúrate de que la pregunta no sea una pregunta capciosa, para que la persona no se distraiga tratando de encontrar una respuesta exacta, sino que se enfoque en el proceso de decisión de la respuesta.

Conforme realices más y más entrevistas, irás agarrando práctica y haciendo mejores preguntas. Solo recuerda que estás tratando de decidir si el candidato cumple con los cinco criterios, así que trata de orientar tus preguntas hacia los criterios donde tengas dudas. Lo que debes evitar es salir de la entrevista sin haber contestado si esta persona cumple los criterios o no.

Paso 4: La decisión

Al llegar el momento de tomar una decisión, las personas que entrevistaron al candidato deberían discutir al respecto. La opinión típicamente gira alrededor de las siguientes cuatro calificaciones: definitivamente no, probablemente no, probablemente si, o definitivamente si. Para que una persona sea contratada, debe haber al menos alguien que diga definitivamente si, y ninguno que diga definitivamente no. En cuanto a las personas que dijeron probablemente si o probablemente no, me gusta averiguar que es lo que no les gustó de la persona, y si los demás vieron algo similar. El objetivo es lograr un consenso. Si no hay consenso, entonces no se contrata a la persona. Si todos dan un probablemente si, entonces tampoco se contrata (aunque en este caso puede indicar que las entrevistas no fueron efectivas). Sin embargo, el objetivo es reclutar a las mejores personas y evitar a los zoquetes, así que no podemos arriesgarnos.

Lección importante: Cuando haya duda, no contrates.
*La versión original de este artículo se encuentra publicada en inglés en http://www.innovationontherun.com/effective-technology-teams-rule-1-no-chumps y fue traducida y publicada por SG con el permiso del autor.

Conclusión

Contratar a las mejores personas y evitar zoquetes un trabajo arduo. Requiere mucho tiempo y esfuerzo, pero es esencial para tener un gran equipo. Mi forma de evaluar y reclutar gente es elitista. Pero sucede que dedico más tiempo a mi trabajo que a mi familia, mis amigos o mis hobbys, así que lo menos que puedo pedir es trabajar con personas que respeto y con las que disfruto trabajar.

Se que corro el riesgo de que se me escurran algunos buenos elementos sin que los contrate. El sistema descrito está diseñado para minimizar los falsos positivos (es decir, reclutar zoquetes) a costa de tener falsos negativos (no contratar a un buen candidato).

Bio

Rob Di Marco actualmente participa en el desarrollo de una empresa startup y complementa esto con actividades como consultor estratégico de tecnología. Anteriormente fue el vicepresidente de tecnología en la empresa Health Market Science (HMS), y gerente de desarrollo de software para The Adrenaline Group, una empresa de consultoría en desarrollo de software en Washington, D.C..

Patentes de Software. Conociendo la Legislación

Anonymous — Wed, 28 Nov 2007 19:49:58 +0000

Patentes de Software. Conociendo la Legislación

Anonymous Wed, 11/28/2007 - 13:49

Publicado en

SG #17

Autor

Las patentes de software pueden definirse como monopolios de 20 años que se conceden en algunas oficinas de patentes en el mundo, sobre funcionalidades, algoritmos, representaciones y otras acciones que se pueden llevar a cabo con una computadora. En la jerga que se usa para las patentes, se suele sustituir dicho término por la expresión “invención implementada por computadora” que incluye tanto las polémicas patentes de software como las generalmente aceptadas “invenciones asistidas por compu

Hoy día hay un acalorado debate sobre qué alcance debe concederse a dichas patentes, si es que deben ser instituidas en absoluto:

• Los detractores de las patentes de software argumentan que cualquier programa informático está compuesto de millones de componentes (procedimientos, algoritmos,...) muchos de los cuales podrían ser patentables por sí mismos, o incluso estar ya patentados en otros inventos. Por otro lado, generalmente es imposible dilucidar si un código determinado incumple alguna patente porque para llegar a tal certidumbre sería necesario evaluar todas las patentes de software existentes en las distintas oficinas de patentes, e incluso así, quedaría la duda.

• Generalmente es preciso un proceso judicial para determinar con certidumbre si una patente está siendo infringida por determinado programa o no. Obviamente, tanto la búsqueda exhaustiva como los pleitos de patentes, son actividades vetadas a las PYME por el gran esfuerzo humano y económico que les supondría, lo que las dejaría fuera del mercado por no ser competitivas en este terreno. A todo lo anterior se suma que en muchos casos una o unas pocas patentes de software son suficientes para monopolizar alguna funcionalidad informática.

• Por otra parte, las personas implicadas en el movimiento de software libre advierten que el uso de patentes impediría el desarrollo de muchos proyectos que no pueden pagar licencia a costa de dejar de ser libres.

• Desde un punto de vista social se argumenta que las patentes de software privatizan el conocimiento, acentuando las desigualdades sociales y geográficas mediante la exclusión de la mayoría de la población como productores e incluso como consumidores de los objetos de dichas patentes.

En Estados Unidos o Canadá, la legislación vigente contempla desde hace tiempo las patentes de software. Sin embargo, en Europa, el Artículo 52 de la Convención de la Patente Europea excluye expresamente los “programas para ordenador”, pero según el Artículo 53 esto sucede sólo cuando sean reclamadas “como tales”. La controversia en Europa está en la interpretación de ese “como tales”. La interpretación de la Oficina Europea de Patentes deja la frase “programas de ordenador como tales” reducida a la inexistencia, pues lo define como el código fuente y el código objeto de los programas informáticos, algo que nadie se plantea patentar porque ya está protegido por el copyright.

En una base global, 4 millones de patentes son válidas en este momento, y se solicitan aproximadamente 700.000 nuevas patentes cada año. Tan solo la Oficina Europea de Patentes recibe más de 150.000 solicitudes por año, y en más de la mitad de esos casos se expide una patente. Vale la pena notar que la mayor área de crecimiento de todas es la de las patentes de software.

Legislación en México
Finalmente, en México, la Ley de la Propiedad Industrial regula el otorgamiento de patentes en el país a las invenciones de productos o de procesos. En ella se menciona que los programas de cómputo no son considerados invenciones, por lo que en México no existen tales patentes.

Los programas de software solamente se pueden proteger mediante el Registro Público del Derecho de Autor; en él se registran programas, documentación y bases de datos. Las responsabilidades del Registro son las de orientar a autores, y procurar resolver controversias según la Ley Federal de Derecho de Autor y su reglamento.

Es muy importante que los creadores de aplicaciones, programas y bases de datos tengan siempre muy claro esto, ya que a diferencia de la práctica Americana, en México no se conceden patentes de software, sin importar si ya exista una patente concedida en Estados Unidos; esto muy a menudo resulta confuso para programadores, fábricas de software, y otras empresas desarrolladoras, pues es común que se piense que sí es posible el otorgamiento de dichas patentes en México simplemente mediante la adopción de las reivindicaciones de la patente otorgada en otro país, como ocurre generalmente en otros casos de patentes que no son de software.

Cuando finalmente se llegue a una conclusión mundial sobre las patentes de software y se reglamenten de forma adecuada, el examen de fondo será más ágil y práctico, con la consecuencia del incremento de más patentes otorgadas en este campo.

Bio

Crescencio Villaseñor es Consultor de Patentes de Clarke Modet & Co. México.

Gloria Isla es Directora General de Clarke Modet & Co. México. Clarke & Modet es la empresa líder en asesoría de Propiedad Industrial e Intelectual en países de habla hispana. www.clarkemodet.com

El Impacto del Web 2.0 en la Empresa. Los Diferentes Escenarios

Anonymous — Wed, 28 Nov 2007 19:47:13 +0000

El Impacto del Web 2.0 en la Empresa. Los Diferentes Escenarios Anonymous Wed, 11/28/2007 - 13:47

Publicado en

SG #17

Tendencias en Software

Autor

Luis Daniel Soto Maldonado.

En septiembre del año pasado, Forrester Research realizó una encuesta entre tomadores de decisión en TI en Estados Unidos, y los resultados arrojaron que el 64% de los encuestados tenían una reacción positiva al tema “Web 2.0”. Particularmente, la esperanza de estas personas está en que Web 2.0 agilice la construcción de aplicaciones de software.

¿Está realmente sucediendo esto?

Antes de contestar la pregunta, consideremos algunos antecedentes:
• Gartner fue de los primeros en señalar que la palabra “portal” es uno de los términos más confusos de la informática: Tanto los sitios dirigidos a consumidor, las puertas de acceso a industrias verticales, el sitio de una empresa en particular, su intranet, y su extranet, son portales. Muchos productos empaquetados de distintas funcionalidades son parte de la misma “categoría”. Finalmente, las páginas personales se consideran también portales que ofrecen mini-aplicaciones denominadas widgets, gadgets o similares.
• El concepto “Web 2.0” es sinónimo de tecnologías como RSS (Really Simple Sindication), Ajax, redes sociales, folksonomies, RIA (Rich Internet applications) y otros. Los distintos proveedores de portales tienen un interés fuerte de llevar a las empresas estas tendencias.

Ante esto, podemos prever tres escenarios que nos hablan de niveles diferentes de adopción:

• Escenario A: Web 2.0 solo fue un mito. Una gran cantidad de empresas Fortune adoptarán aspectos tecnológicos pero difícilmente replicarán los aspectos sociales de participación del Web 2.0, resultando en un bajo impacto de negocio.
• Escenario B. Enterprise 2.0. La historia puede ser diferente si se logra un enfoque en el aspecto humano y de transformación de cultura: creación de contenidos producidos por los usuarios, inteligencia colectiva y clasificación de comunidades. Esto no será algo sencillo de lograr, ya que Gartner estima que el 75% de las organizaciones no podrá implementar este tipo de funcionalidad, debido a restricciones de privacidad y normas de industrias reguladas. La capacidad de permitir a otros usuarios crear composición de servicios (meshups) y los nuevos modelos de negocio basados en publicidad implican retos no solo técnicos, sino también en cuanto a políticas y regulaciones.
• Escenario C. Software+Servicios. El “Web 2.0” no existe en las empresas, sino el salto directo a la etapa de “Software más servicios” o “Siguiente Web”, donde la combinación de software administrado internamente y software como servicio se convierte en la norma. El servicio puede ser ofrecido por diversos canales o el mismo proveedor del software. De hecho, un principio básico es una gran facilidad para intercambiar y combinar dichos modelos en el logro de la solución. Este modelo cuenta con valor sumamente interesante para empresas de TI (ver https://partner.microsoft.com/40044198 )

Según las estadísticas de estudios realizados por Microsoft en América Latina, en los próximos 18 meses se duplicará el número de desarrolladores Web en esta región. Esto se debe por un lado al rezago que tenemos en esta área, y por otro a que se trata de un área de desarrollo a nivel global. Esto le da gran relevancia al tema del “Siguiente Web”.

No obstante, mi opinión personal es que si bien es crítico avanzar el desarrollo web y aprovechar las bondades del Web 2.0, no debemos perder de vista que esto solo es parte de la ruta y no debemos dejar que nos distraiga del objetivo central: simplificar dramáticamente la construcción de software y democratizar este proceso. No nos olvidemos de ello.

Por último, los invito a que le echen un vistazo a Tafiti (www.tafiti.com). Es un website experimental para ejemplificar una aplicación web basada en Silverlight. Tafiti significa “investigar” en Swahili, y este sitio provee un conjunto de herramientas orientadas a apoyar la investigación, permitiendo organizar y visualizar los resultados de búsquedas múltiples.

Bio

Luis Daniel Soto es director de Divulgación Tecnológica para América Latina en Microsoft México. Es jurado del “Gran Orden del Honor al Mérito Autoral” en software del INDAUTOR/SEP y fundador de diversas asociaciones de TI. Luis Daniel obtuvo el primer lugar en el concurso nacional para software de exportación en 1989. blogs.msdn.com/luisdans

Conociendo Windows CE, Tutorial Para Iniciar un Programa de Forma Automática

Anonymous — Fri, 07 Sep 2007 16:14:26 +0000

Conociendo Windows CE, Tutorial Para Iniciar un Programa de Forma Automática Anonymous Fri, 09/07/2007 - 11:14

Publicado en

SG #17

Autor

Carlos Maya

Los sistemas embedded se encargan de hacer una tarea específica diseñando tanto el hardware como el software para ese fin, del que difícilmente se puede modificar su comportamiento. Entonces, siempre que el sistema se enciende, el software ejecuta ciertas tareas para inicializar el hardware, y en conjunto realizan el trabajo asignado.

Muchos sistemas embedded consisten básicamente de un microcontrolador, el cual cuenta con diversos periféricos encargados de entradas y salidas; acondicionadores de señales y actuadores. Tales sistemas son básicamente programados en lenguaje ensamblador y en lenguajes de nivel medio como son BASIC o C, entre otros. El principal requerimiento en este tipo de sistemas es el tiempo real, donde la respuesta a una entrada debe cumplir un tiempo limitado. Pero existen otras aplicaciones con funcionalidad más diversa, que posiblemente requieran manejar cantidades grandes de datos, presentar una interfaz de usuario, manejar bitácoras, etcétera. Ejemplos de esto son los kioscos para punto de venta, o los reproductores digitales de música. En este tipo de sistemas los microcontroladores pierden sentido, y se requiere de mucho más recursos —como codecs de audio o video—, además de un manejo de memoria más extenso y la capacidad de procesamiento multitarea.

La plataforma Windows CE
Las aplicaciones de software embedded se pueden desarrollar en lenguajes de bajo nivel, como ensamblador. Sin embargo, en la mayoría de los casos esto no es práctico ni productivo. Es así que se han desarrollado plataformas de más alto nivel para sistemas embedded. Tal es el caso de Windows CE. Una de sus características más importantes es que, es un sistema operativo configurable creado por Microsoft para sistemas embedded, de tal forma que se parte de un kernel con un footprint cercano a los 300KB y dependiendo de los módulos que se desee agregar (existen alrededor de 700 módulos de funcionalidad específica) se termina con un sistema operativo tan pequeño o grande como sea necesario para nuestro sistema. De hecho, se considera que Windows CE es en realidad una plataforma para generar sistemas operativos a la medida, para sistemas embedded. La ventaja que tenemos aquí es que contamos con una plataforma que, aunque no tiene todo el potencial de un desktop, provee un ambiente parecido donde se puede emplear un subset de APIs de Windows, compact framework, SQL mobile, multitareas, para programar en lenguajes como el C# o C++, que en conjunto con las herramientas de Visual Studio facilitan enormemente el desarrollo de estos sistemas.

Tutorial
Habiendo introducido lo que es Windows CE, ahora me enfocaré en explicar una técnica que se puede ser utilizar para iniciar programas desde fuera de la imagen del OS de Windows CE.

Sucede que en Windows CE existe la posibilidad de agregar aplicaciones que estén integradas a la imagen del sistema operativo, pero el inconveniente de este método es que cada vez que se requiera modificar algo en el sistema aplicativo, se tendría que reemplazar la imagen completa del sistema operativo, lo que nos consume mayor tiempo y ancho de banda, especialmente cuando las actualizaciones se realizan de forma remota. Para evitarlo, aquí planteo un método de arrancar un programa fuera de la imagen del sistema operativo para el cual hay que considerar los siguientes puntos:

• La imagen debe tener los drivers necesarios para soportar un dispositivo de almacenamiento masivo (CF, HDD, DOM, etcétera).
• El sistema aplicativo debe existir en cualquier unidad de almacenamiento no volátil.
• Es deseable que sea configurable el nombre del sistema aplicativo. Esto es útil para el desarrollo y pruebas.

Comencemos considerando que tenemos previamente configurada la imagen del sistema operativo, entonces creamos un subproyecto WCE tipo consola, tal como muestra la figura 1.

Posteriormente ponemos el nombre del subproyecto, que en este caso se llamará: “IniciarPrograma”. Escogiendo un proyecto vacío, y el tipo de proyecto como una aplicación de consola para Windows CE (ver figura 2).

Una vez hecho esto, en el explorador de soluciones podremos encontrar el subproyecto que acabamos de crear. Si abrimos la carpeta de código fuente encontraremos el archivo IniciarPrograma.cpp que fue generado automáticamente y que debemos editar para que haga lo que nosotros deseamos. En este caso, alimentemos el código del listado 1 en nuestro archivo cpp.

Para arrancar el programa que acabamos de agregar, abrimos la carpeta de parámetros del subproyecto IniciarPrograma y editamos el archivo IniciarPrograma.reg de tal forma que el registro HKEY_LOCAL_MACHINE/init quede con los valores ilustrados en la figura 3.

Creamos ahora el archivo AutoRun.ini en hard disk (que es el nombre que le asigna Windows CE al dispositivo principal de almacenamiento), y de éste leemos la ruta del programa aplicativo a ejecutar.
En este momento ya contamos con todo lo necesario para poder ejecutar el programa aplicativo de forma automática. Entonces construimos el proyecto agregado a la imagen y lo cargamos a la plataforma en la que estamos probando. Debemos también tener el programa aplicativo cargado ya en el dispositivo de almacenamiento. En la figura 4 se muestra la pantalla de inicio de la imagen donde al cargar se ejecuta el programa: IniciarPrograma.exe desde la imagen, y espera unos segundos a que se carguen los dispositivos de almacenamiento. Posteriormente ejecuta el programa aplicativo como se muestra en la figura 5.

// IniciarPrograma.cpp : Defines the entry point for the console application.

#include “stdafx.h”

int _tmain(int argc, TCHAR *argv[], TCHAR *envp[])
{
OutputDebugString(_T(“En espera para cargar drivers”));
Sleep(8000); //Tiempo de espera de 8 segundos
OutputDebugString(_T(“Fin de espera para cargar drivers”));
FILE *pfile;
char cArchivo[200];
cArchivo[0] = ‘\n’;
//Se abre el archivo que nos indica que programa arrancar
pfile = fopen(“Hard Disk\\AutoRun.ini”,”r”);
if(pfile == NULL)
{
fprintf(stderr,”No se puede abrir el archivo”);
exit(EXIT_FAILURE);
}
//Se lee la ruta del programa a arrancar
fgets(cArchivo,200,pfile);
fclose(pfile);
if(cArchivo[0] != ‘\n’) //Verificamos que no este vacio el string
{
TCHAR wArchivo[200];
//Mostramos el Archivo a arrancar, se puede omitir
printf(“Arrancando archivo: %s”,cArchivo);
Sleep(60000);
//Se tranforma los datos para Unicode
MultiByteToWideChar(CP_ACP,MB_PRECOMPOSED,cArchivo,-1,wArchivo,200);
//Se crea el proceso
CreateProcess(wArchivo,NULL,NULL,NULL,0,0,NULL,NULL,NULL,NULL);
}
return 0;
}

Listado 1. Código de inicialización del programa

Figura 1. Agregando un proyecto a la imagen de CE.

Figura 2. Creando un proyecto WCE tipo consola.

Figura 3. Agregando llaves al registry.

Figura 4. Pantalla principal de Windows CE 6.0.

Figura 5. Pantalla de ejecución automática.

Conclusiones
En Windows CE se puede configurar nuestra aplicación según lo requiera, desde los módulos a utilizar, como del comportamiento en sí de cada uno de ellos. En este artículo vimos un ejemplo sencillo de cómo inicializar un programa, pero se pueden realizar muchas otras tareas, ya que se tiene una buena parte del código fuente de Windows y la posibilidad de manipular con mucha flexibilidad el registry. Por ejemplo: se pueden definir conexiones GPRS a través de módem, que el dispositivo funcione como

web server, modificar la interfaz de usuario de diversos diálogos de configuración, etcétera. Otra gran ventaja de Windows CE es que el desarrollo se puede hacer con lenguajes de alto nivel y podemos disponer de muchas librerías que facilitan y aceleran la programación, además de que simplifican el mantenimiento de dichas aplicaciones. También debemos tener en cuenta que podemos trabajar desde el ambiente de desarrollo de Visual Studio 2005, aprovechando todas sus capacidades.

Acerca del autor
Carlos Maya es programador móvil en la empresa emLink. Ha desarrollado sistemas bajo la plataforma Windows CE como InfoLink y SalesLink CRM, que son sistemas de levantamiento de información en campo y relación con el cliente. Adicionalmente ha desarrollado soluciones a la medida para clientes como Bimbo, Multipack, ADO, Comex, Pearson Educación, Video Turismo, entre otros.