SG17 (Septiembre-Octubre 2007) by Revista Software Guru

// CONTENIDO

directorio Dirección Editorial Pedro Galván Dirección de Operaciones Mara Ruvalcaba Arte y Diseño David Gutiérrez Oscar Sámano Consejo Editorial Francisco Camargo, Ralf Eder, Raúl Trejo, Guillermo Rodríguez, ITESM-CEM; Hanna Oktaba, UNAM-AMCIS; Luis Cuellar, Softtek; Luis Vinicio León, e-Quallity - ITESO.

Editorial

Colaboradores Jorge Palacios, Luis Daniel Soto, Susana Tamayo, Dennise Taffoya, Filein León, Rommy Bitar, Hector Obregón, Christian P. García, Carlos Maya, Cesar Guerra, Víctor Lorenzana, Sergio Orozco, Leticia Ortíz, Paul Manchego, Axel Nissim.

Al pensar en sistemas de software, muy probablemente nos venga a la mente la idea de una aplicación en una arquitectura multicapa, con su base de datos normalizada, sus objetos de negocio con servicios bien definidos, y su capa de presentación a la última moda usando Ajax o WPF. Perfecto, eso está muy bien. Ahora hagámonos a la idea de que eso en que acabamos de pensar, y que es en lo que basamos nuestro modus vivendi actualmente, en unos años no será más que un nicho. Suena difícil de creer, ¿no? Esa industria de tantos billones de dólares… ¿un nicho? Pues si. El día de mañana cuando nuestros hijos hablen de software, seguramente se van a referir a aquel que hace que funcione su consola de videojuegos, su mascota-robot, o su ropa inteligente. Piensen en la cantidad de dispositivos y sistemas que usamos a diario, que podrían ser mejorados a través de software. Prácticamente todo. Posiblemente se estén preguntando en qué momento cambió la línea editorial de SG hacia gadgets y estilo de vida digital. No se preocupen, ese no es el caso. Simplemente queremos invitarlos a darse cuenta de que el software de mañana es el software embedded. Así que si no quere-

SEP-OCT 2007

mos quedar relegados, debemos empezar a ver cómo le vamos a entrar. La recta final Conforme leen estas líneas, estamos con los últimos preparativos para SG ’07, y esperamos que ustedes estén haciendo lo propio. He aquí una lista de sugerencias: • Avisarle a tu jefe y usuarios que no cuenten contigo esos días. • Tomarte tus vitaminas para que tengas mucha energía y aproveches cada segundo. • Hacer una lista de lo que le quieres preguntar a los speakers cuando hables con ellos. • Ponerte de acuerdo con tus cuates que también van a ir. AMCIS Queremos agradecer a la AMCIS por el apoyo que siempre dio a SG. Aunque la AMCIS haya cerrado, sabemos que hay muchas personas interesadas en la mejora de procesos, y SG estará apoyando para que esta comunidad se mantenga. Fe de errata En la edición Julio-Agosto 2007 de SG, al final de la página 35 debería decir: “… incrementar el volumen de producción”. — Equipo Editorial

Ilustración www.tollhaus.com.mx Ventas Claudia Perea Natalia Sánchez Marketing y RP Dafne Vidal Circulación y Suscripciones Daniel López Administración Araceli Torres Contacto info@softwareguru.com.mx +52 55 5239 5502

SG Software Guru es una publicación bimestral editada por Brainworx S.A. de C.V., Malinche no. 6, Col. El Parque, C.P. 53398, Naucalpan, México. Queda prohibida la reproducción total o parcial del contenido sin previo aviso por escrito de los editores. Todos los artículos son responsabilidad de sus propios autores y no necesariamente reflejan el punto de vista de la editorial. Reserva de Derechos al Uso Exclusivo: 04-2004-090212091400-102. Certificado de licitud de título: 12999. Certificado de licitud de contenido:10572. ISSN: 1870-0888. Registro Postal: PP15-5106. Se imprimió en agosto de 2007 en Litográfica Roma. Distribuido por Comercializadora Alieri y Sepomex.

www.sg.com.mx

contenido sep-oct 2007

EN PORTADA Embedded Software

Abrimos la puerta al mundo del software embedded, lo que significa y los retos que implica.

Productos LO QUE VIENE 10 Spring Web Services, OpenProj, JGear, y WebLogic Server Virtual Edition 12

HERRAMIENTAS SQLite

Columnas

Prácticas

Tejiendo Nuestra Red por Hanna Oktaba

Tendencias en Software por Luis Daniel Soto

Mejora Continua por Luis Cuellar

Columna Invitada por Crescencio Villaseñor

REQUERIMIENTOS Obtención de Requerimientos

César Guerra explica en detalle las diferentes técnicas existentes para obtener los requerimientos de un sistema de software.

PROGRAMACIÓN Expresiones Regulares

Revisamos minuciosamente la sintáxis de las expresiones regulares paar que por fin te decidas a perderles el miedo.

En Cada Número Noticias y Eventos

INFRAESTRUCTURA

Fundamentos

Carrera

Entrevistas

Orlando Rincón, Miguel Serrano, Gavin King.

www.sg.com.mx

50 56

GESTIÓN DE RECURSOS 36 Tips para Reclutar Desarrolladores En esta guía, Rob Di Marco elabora sobre los cinco criterios que debe cumplir un buen desarrollador de software, y cómo averiguar si un candidato cumple con ellos.

UML 40 Inclusión y Extensión de Casos de Uso Uno de los temas más polémicos y confusos del modelado de casos de uso es el de las relaciones includes y extends. En este artículo vemos cuando se apilca cada uno, y cómo evitar su abuso.

SEP-OCT 2007

// NOTICIAS

CIISA 2007 Con el objetivo de promover la competitividad de las empresas con base en el conocimiento, la innovación y el desarrollo tecnológico, el pasado mes de julio en la ciudad de Guadalajara, se llevó a cabo la segunda edición del Congreso Internacional en Ingeniería de Software y sus Aplicaciones – CIISA 2007. Organizado por el Tecnológico de Monterrey y el SIE Center, es uno de los pocos eventos realizados en México, que cubren la necesidad de la industria por conocer los diferentes temas de la ingeniería de software. Esta edición del congreso se enfocó en tres temas específicos: pruebas de software, seguridad y software embebido, contando con reconocidos ponentes como Ken Van Wyk, del Software Engineering Institute, y Pamela Perrott, de Construx Software.

3ra Cumbre de Gobierno y Tecnología IDC El pasado 27 de agosto, en la Ciudad de México, se realizó la 3ra. Cumbre de Gobierno y Tecnología, organizada por IDC México. Dicho foro es único en su tipo, ya que reúne a la comunidad de funcionarios públicos con los proveedores de tecnología, para juntos definir el rumbo que deben tomar las TI en la Administración Pública. Ponentes representantes de diferentes entidades gubernamentales, empresas proveedoras de TI, y analistas de IDC, presentaron y analizaron temas de interés específico para la Administración Pública, entre los que podemos mencionar: la evaluación de proyectos de outsourcing, el nuevo modelo de adquisición de TI, y el decreto de austeridad en las áreas de sistemas.

Oracle presenta Oracle Database 11g Oracle presentó en la Ciudad de México, la más reciente versión de su base de datos Oracle® Database 11g. “Oracle Database 11g, resultado de los 30 años de experiencia en diseño de bases de datos, ofrece gestión de información empresarial, de siguiente generación”, comentó William Hardie, vicepresidente de Producto de Oracle. Entre las características más innovadoras de Oracle Database 11g podemos mencionar: la manipulación de datos XML de forma nativa, la habilidad para realizar pruebas y gestionar cambios utilizando datos reales, una excelente mejora en la compresión de datos, y más de 300 nuevas funcionalidades que sin duda, harán mucho más sencillo el trabajo de los desarrolladores, y mucho más productivo el negocio.

SEP-OCT 2007

www.sg.com.mx

// EVENTOS

4 al 7 de Octubre 2007

6 de Septiembre 2007

Creanimax 2007 Festival de Animación y Videojuegos

2do. Seminario Mejores Prácticas y Tecnologías de Vanguardia para la Dirección de Proyectos MPA y PMI capítulo México Tecnológico de Monterrey, Campus Ciudad de México Info: www.mympa.org/Chapters/MexicoCity e-mail: infompa@advisicon.com

CANIETI, IJALTI Expo Guadalajara, Guadalajara, Jalisco Info: www.creanimax.com

8 y 9 de Octubre 2007

2° Foro de Desarrollo y Pruebas de Software del Estado de Guanajuato

11 de Septiembre 2007

IDC Innovation Forum

Poliforum León, Guanajuato Info: www.concyteg.gob.mx

Centro Banamex, Cd. de México Info: www.idc-eventos.com/innovation07/ e-mail: idc@simrel.com.mx

10 de Octubre 2007

Congreso AMITI 2007: México Reinventado 12 al 14 de Septiembre 2007

XXXI Reunión Nacional CIAPEM Veracruz 07

Centro Banamex, Cd. de México Info: www.congresoamiti.com/

Comité de Informática de la Administración Pública Estatal y Municipal WTC, Boca del Río, Veracruz Info: www.ciapem.veracruz.gob.mx

18 al 20 de Octubre 2007

19 al 21 de Septiembre 2007

Gartner 10th Annual Conference: The Future of IT 2007 Centro Banamex, Cd. de México Info: www.gartner.com/mx/econit e-mail: latin.america@gartner.com

ENLi 2007 Encuentro Nacional de Linux y Software Libre Benemérita Universidad Autónoma de Puebla (BUAP), Puebla Info: www.enli.org.mx

24 y 25 de Octubre 2007

Cutter Summit 2007

20 al 22 de Octubre 2007

Hotel JW Marriott, Cd. de México Info: www.cutter.com.mx/summit07/2007 e-mail: eventos@cutter.com

Tecnológico de Monterrey, Campus Puebla Info: www.saties.com e-mail: camsolis@itesm.mx

24 al 26 de Octubre 2007

DigIT 2007 - Congreso Internacional de TI

25 de Septiembre 2007

XX Congreso Nacional y VI Congreso Internacional de Informática y Computación - ANIEI 2007

Morelia, Michoacán Info: enc.smcc.org.mx

Universidad Autónoma de Chihuahua, Chihuahua, México Info: www.aniei.org.mx e-mail: atencionasociados@aniei.org.mx

4 al 6 de Octubre 2007

29 al 31 de Octubre 2007

Tecnológico de Monterrey, Campus Guadalajara Info: www.congresoisc.com e-mail: informes@congresoisc.com

SG Software Guru Hotel Sheraton Centro Histórico, Cd. de México Info: www.sg.com.mx/sg07 e-mail: sg07@softwareguru.com.mx

Encuentro Internacional de Computación 2007

IX Congreso Internacional de Sistemas Computacionales

Empresas recientemente evaluadas en CMMI:

Empresa IIDEA Solutions ilinium www.sg.com.mx

Evaluación CMMI 3 CMMI 2

Fecha abril 2007 agosto 2007

SG’07 Conferencia y Expo

Apoyado por Innevo Innevo

Lead Appraiser Jorge Boria, Liveware Jorge Boria, Liveware SEP-OCT 2007

// COLUMNA // COLUMNA

/*TEJIENDO NUESTRA RED*/

AMCIS

Mis recuerdos

La Dra. Hanna Oktaba es profesora de la UNAM a nivel licenciatura y posgrado. Sus áreas de interés son Ingeniería de Software, Tecnología Orientada a Objetos, Modelos de Procesos de Software y Mejora de Procesos. Es fundadora de la AMCIS. Actualmente es miembro de International Process Research Group (IPRC). También es Directora Técnica del proyecto COMPETISOFT.

n junio de 2007, los que fuimos socios fundadores tomamos la dolorosa decisión de cerrar la AMCIS. La Asociación Mexicana para la Calidad en la Ingeniería de Software nació de una inquietud y entusiasmo de varias personas. El objetivo que nos movía era aprender juntos y compartir el conocimiento y las experiencias.

dedicado al estudio de la ISO 15504. Durante este seminario participamos varios académicos y gente de la industria. La asistencia, y el entusiasmo por conocer las normas internacionales llegaron a su apogeo. Los que fuimos promotores sentimos que este era el momento para formalizar las actividades.

Hace diez años, en 1997 tomé mi año sabático que coincidió con que la amiga de toda mi vida mexicana, que inició hace 24 años (pero eso es otra historia), Gloria Quintanilla fue nombrada gerente de Calidad en Tecnosys, recién adquirido por IBM de México. Su responsabilidad era cambiar la forma de trabajar de los grupos de desarrollo de software para poder cumplir con la norma ISO 9000:1995. Gloria me invitó para que durante mi sabático la apoyara en esta aventura. Reconozco la visión del director de Tecnosys, Martín Méndez, que no solamente aceptó la participación de una académica sin experiencia en la “vida real”, sino que nos apoyó años después en el 2002, junto con su socio Víctor Baez, para que la Secretaría de Economía nos diera su voto de confianza para la creación de MoProSoft.

Las reuniones mensuales no fueron las únicas actividades. Desde el 1998 tuvimos la oportunidad de organizar seis Seminarios de Calidad de Software. En el primero de este mismo año tuvimos de invitado ni más ni menos que a Watts Humphrey, quien nos dio la conferencia sobre Team Software Process en las instalaciones de IBM. Luego contamos con la colaboración de AMITI para invitar a Suz García del Software Engineering Institute a un curso de CMM. Posteriormente, con la revista Soluciones Avanzadas armamos un evento importante con varios invitados de Europa y EEUU, así como nuestras estrellas mexicanas de la calidad como Arnoldo Díaz de Certum. Uno de los seminarios fue dedicado completamente a pruebas de software y el último en 2003 anunciaba por igual el nacimiento de CMMI que de MoProSoft.

Regresando al inicio, en este mismo año 1997, Francisco López Lira estuvo reuniéndose con un grupo de amigos de varias empresas que también estaban interesados en temas de calidad. Nos enteramos unos de otros y decidimos convocar a la primera reunión conjunta de lo que llamamos, Circulo de Calidad de Software. En septiembre de 1997 tuvimos nuestra primera reunión, en las instalaciones de Tecnosys de la calle Martín Meldalde. La plática estuvo a cargo de Francisco, quien explicó el modelo CMM, y tuvimos 22 asistentes. El entusiasmo y el interés fue tal que no nos quedó de otra que prometer una reunión mensual con un expositor de algún tema de interés. Desde el principio tuvimos una participación muy entusiasta de una mujer “maravilla” responsable por la calidad de la empresa Compac de Guadalajara, que llegaba religiosamente cada mes al DF y nos convenció de tener una reunión foránea en Guadalajara del Círculo de Calidad en enero de 1998. Allá tuvimos la oportunidad de presenciar la primera efervescencia de la incipiente industria de hardware y software y de la visión del ITESO para vincularse con ella.

El éxito de los primeros seminarios y de las reuniones mensuales fue tal que no nos quedaba de otra sino constituirnos como una asociación, lo cual se formalizó en septiembre de 1999. Desde ese entonces, el grupo SETI nos ofreció sus espacios en la colonia Roma para las reuniones mensuales. Los ponentes fueron tanto gente de la industria que quería compartir su conocimiento, como los alumnos de maestrías que estudiaban algún tema de interés. Logramos reunir gente de la industria, gobierno y la academia que venían a disfrutar una tarde-noche y platicar de sus “penas”. Los temas que se presentaban abarcaban todas las áreas de ingeniería de software, los modelos y las normas, las experiencias y las herramientas. Editamos unos cuantos “Cuadernos de Calidad de Software” basados principalmente en trabajos de tesis de maestría. Empezamos a tener una lista de correos de los interesados que crecía de manera impresionante.

Pronto ya no cabíamos en las instalaciones de Tecnosys y pedimos “posada” en el INEGI de Patriotismo, cuya Dirección de Política Informática nos apoyó con el espacio para las reuniones mensuales. A principios de 1999, Infonavit –bajo la Dirección de Sistemas encabezada por Víctor Baez– nos ofreció un espacio para realizar un Seminario

SEP-OCT 2007

Durante el año 2002 Teresa Márquez, una alumna de doctorado de Ciencias Sociales, nos investigó como caso de estudio de una red de transferencia informal de conocimiento contra la incertidumbre en software. Gracias a la gente experta en diversos temas, reunida alrededor de la AMCIS, pudimos armar el primer diplomado en el país sobre la Calidad de Software. Sus primeras ediciones en el año 2002 se dieron en la Ciudad de México y en Irapuato.

www.sg.com.mx

En 2002 tuvimos la suerte de que se estaba definiendo PROSOFT y que una de las estrategias hablaba de elevar la capacidad de procesos de la industria de software nacional. Este tema nos fue familiar, ya que teníamos en nuestras filas gente especializada, lo que nos permitió tener un papel importante para convencer que para apoyar al sector de la micro y pequeña industria de software se necesitaba algo más adecuado. Esta iniciativa se convirtió en los proyectos de MoProSoft, EvalProSoft y Pruebas controladas de ambos, que evolucionaron en la Norma mexicana NMX-059: Modelo de Procesos y de Evaluación para la Industria de Software. Gracias a los proyectos emprendidos por la AMCIS y al movimiento en los estados que ha fomentado el programa de PROSOFT, algunos colegas de Chihuahua, Veracruz, Jalisco y Nuevo León tuvieron la inquietud de formar los capítulos de la asociación. Otros, que han aprendido con la AMCIS han formado sus propias consultorías o negocios alrededor de temas de calidad. Todo esto nos llena de orgullo, nos hace sentir que cumplimos con los objetivos de la asociación.

www.sg.com.mx

Sin embargo, en los últimos meses las expectativas del mundo exterior rebasaron nuestras posibilidades de cumplirlas. La asociación requería de dedicación de tiempo completo y nosotros solo le podíamos regalar el tiempo robado a nuestros empleos y familias. Tampoco teníamos recursos para mantener su operación. Por eso tomamos la decisión de cerrar las puertas. La cerramos con tristeza pero también con el sentimiento de misión cumplida. El tema de calidad para la industria de software mexicana ya no se puede soslayar. ¿Y a mi que me dio la AMCIS? Los diez últimos años de mi vida académica han cambiado por completo. Me di cuenta de cuánto se puede aprender de la vida real de la industria y cuánto le podemos y debemos ofrecer desde la academia. La retroalimentación mutua es la clave para que ambos sectores crezcan y cumplan con su papel en la sociedad. Otro logro muy importante para mi es tener este espacio en Software Gurú que sin la AMCIS difícilmente me lo hubieran ofrecido. —Hanna Oktaba

SEP-OCT 2007

// COLUMNA // COLUMNA

/*MEJORA CONTINUA*/

Pésame por un Mentor A Correr Luis R. Cuellar es Director de Calidad a nivel mundial de Softtek Information Services. Luis es reconocido por la American Society for Quality (ASQ) como Certified Quality Manager, Certified Software Engineer, y Six Sigma Black Belt. En los últimos cinco años ha estado a cargo de la definición e implantación de la estrategia para CMMI5 y Six Sigma a través de las diferentes áreas del centro de desarrollo de Softtek.

omo muchos de ustedes saben, el pasado 19 de junio falleció Enrique Canales, Tecnólogo, Filósofo y Artista. Yo tuve el honor de conocer al Ingeniero Canales en una plática que impartió en Monterrey hace alrededor de 14 años, y puedo decir sin exagerar que esas ocho horas cambiaron por completo todas mis ideas sobre la definición, planeación y administración de la tecnología. Sus ideas expuestas en presentaciones, libros y artículos marcaron un nuevo rumbo a mi vida profesional que se vislumbra aun en mi forma actual de pensar sobre temas de calidad, tecnología, procesos y demás. Mi más sincero pésame a su familia, descanse en paz.

¡Aguas con China! En agosto tuve la oportunidad de viajar a China con la finalidad de echar un vistazo a algunas compañías de desarrollo de software. Desde que anuncié sobre los planes de mi viaje a mis familiares y amigos, la mayoría trató de disuadirme, utilizando como argumento las múltiples noticias en la televisión sobre plagas de ratas, fraudes con comida para perros, juguetes asesinos y demás. Debo confesar que escuchando de estos asuntos y habiendo estado anteriormente en India, los relatos me preocuparon un poco. Me imaginé un país con poca infraestructura, con gran corrupción claramente notable en la calle, y gente con poco conocimiento tratando de programar algo en computadoras baratas dentro de una bodega. Sin embargo, la China que conocí es muy diferente a esto, totalmente diferente. Beijing (en español Pekín) es una ciudad de 30 millones de habitantes, llena de rascacielos y edificios modernos. Es sumamente cosmopolita y se puede ver en las calles a personas de todas las nacionalidades, haciendo negocios en China y enseñando a China a hacer negocio con el resto del mundo. La gente es sumamente amigable, con una tremenda sed por ser parte del mundo global, tremendas ganas de aprender y hacer lo que sea necesario para que se le reconozca su habilidad y destreza. La cultura es de cooperación y ayuda mutua. Adicionalmente, como consecuencia de la regla actual de que cada familia puede tener máximo un hijo, las familias hacen un gran énfasis en la educación de esos hijos únicos.

“La tecnología no tiene nada que ver con los mejores sistemas, ni las herramientas más avanzadas. Tecnología es saber hacer lo que nadie más sabe hacer”. Esta frase tiene muchas implicaciones. Las primeras son a nivel personal: ¿Qué sabes hacer que nadie más sabe hacer?, ¿Puedes repetir esa acción con el mismo resultado consistentemente?, ¿Estás trabajando en cómo mejorarlo para que siempre estés delante de los demás? Si la respuesta a cualquiera de estas preguntas es negativa, entonces eres un “commodity” y tu trabajo tarde o temprano se lo llevará otra persona más barata, otra persona que sí esté preocupada por estas preguntas. El problema es que aunque todos nosotros nos hagamos esta pregunta y logremos diferenciarnos, en un mundo global ya no es suficiente. La carrera en la que estamos compitiendo no es de individuos, es de compañías, o incluso de países. Si llevamos la frase sobre tecnología a un nivel más alto, entonces nos preguntamos: ¿Qué sabemos hacer como compañía que ninguna compañía sabe hacer?, ¿Qué sabemos hacer como país que ningún otro país puede o sabe hacer? En un mundo globalizado, el problema no lo vamos a resolver solos, lo vamos a resolver en grupos, tenemos que ponernos de acuerdo en qué queremos y hacia donde vamos. La India inició con el desarrollo de Software hace aproximadamente 30 años. Según los listados del SEI de finales del 2006, India tiene 204 empresas con assesments de CMMI. En comparación, México tiene 15 assesments. Nuestra excusa es que en México iniciamos formalmente con desarrollo de software a distancia para Estados Unidos hace cerca de 10 años, así que es comprensible que India nos lleve tanta ventaja. Por otro lado, China inició fuertemente con desarrollo a distancia hace aproximadamente 5 años, y actualmente cuenta con 240 empresas con assesments de CMMi. Esto nos dice por un lado que China definitivamente está decidida a aparecer en la foto, y por otro que el tiempo no es pretexto suficiente.

¡¡Y Arrancan!!

Tecnología y trabajo en equipo

Lo interesante de saber hacer algo, es que te da las bases para aprender a hacer nuevas cosas. Entre más cosas sabes hacer en forma repetible y mejorando constantemente, más cosas aprendes que te ayudan a diferenciar de los demás. En la carrera del desarrollo de software a distancia, parece ser que China está decidida a ocupar la cabeza lo antes posible. ¿Nosotros en qué lugar queremos quedar? ¿Estamos listos para competir?, ¿Sabemos como competir?, ¿Queremos competir?, ¿Seguiremos el ejemplo que China está poniendo o nos sentaremos a verlos pasar? La carrera ya inició. ¡A correr!

Y ya que hablamos de Enrique Canales, viene a colación una de sus frases que más admiro:

—Luis R. Cuellar

Posiblemente se pregunten ¿y eso qué tiene que ver con calidad y con mi trabajo diario? Bueno, pues sucede que China también le ha entrado a la carrera por la industria del software, y debemos estar muy atentos y aprender. Actualmente vemos a India como el gran líder en esta carrera, pero ante lo que he visto en China, yo dudo que India logre mantenerse como líder por mucho tiempo.

SEP-OCT 2007

www.sg.com.mx

SEP-OCT 2007

// PRODUCTOS

/* LO QUE VIENE*/

JGear

Plugins de Lujo para Eclipse

CodeGear –la división de herramientas de desarrollo de Borland– lanzó JGear, un conjunto de plugins de Eclipse orientados a extender las capacidades de Eclipse para desarrollo empresarial con Java. JGear está orientado a resolver lo que CodeGear considera como las debilidades principales de Eclipse: • Optimización del desempeño (performance tuning) de las aplicaciones • Arquelogía del código • Configuración de frameworks y servidores • Colaboración con otros miembros del equipo JGear está formado por tres componentes: JGear Performance for Eclipse, JGear LiveSource for Eclipse, y JGear Team for Eclipse. Este último producto existe en la edición cliente y servidor (algo similar al Team Foundation Server de Microsoft). Mayor información en www.codegear.com

Spring Web Services 1.0

Contract-First, Document-Driven Web Services

Interface21, la empresa creadora del popular framework Spring para desarrollo con Java, anunció la disponibilidad de Spring Web Services 1.0, que es un stack completo para desarrollar y consumir web services con SOAP y POX (Plain Old XML). Spring-WS implementa funcionalidad altamente buscada por los desarrolladores de web services, tales como el WS-I Basic Profile, y la capacidad de manejar servicios de contrato previo (contractfirst) dirigidos por documentos. El framework también es capaz de procesar mensajes XML con diferentes APIs como DOM, JDOM, StAX y dom4j. Otra capacidad atractiva es el módulo para mapeo objeto/XML, el cual provee soporte para JAXB 1 y 2, así como Castor, XMLBeans, JiBX y XStream.

OpenProj

Ahora tus Gantts Serán Libres

WebLogic Server Virtual Edition Mira Mamá, ¡Sin Sistema Operativo!

BEA Systems dio a conocer su producto WebLogic Server Virtual Edition. Lo interesante de esta edición de su servidor de aplicaciones, es que se ejecuta directamente sobre VMWare, sin necesidad de tener un sistema operativo. Esto es posible gracias al uso de LiquidVM, que es un JVM (java virtual machine) habilitado para funcionar sobre hipervisores. LiquidVM reemplaza el ambiente de un sistema operativo tradicional, reduciendo sustancialmente la utilización de recursos de hardware. Este producto refleja la importancia de la tecnología de virtualización, y porqué Microsoft está tan interesado en no quedarse atrás: los hipervisores como VMWare, en conjunto con máquinas virtuales como la de Java, pueden llegar a hacer innecesarios a los sistemas operativos. Se espera que WebLogic Server Virtual Edition agregue soporte para Xen a finales del 2007 y para Virtual PC en el 2008.

SEP-OCT 2007

A los administradores de proyecto les dará mucho gusto saber que ahora cuentan con una opción open source y multiplataforma para generar y dar seguimiento a sus planes de proyecto. La herramienta en cuestión se llama OpenProj, y es un producto desarrollado por la empresa Projity. Entre las capacidades de OpenProj están las obvias como WBS, diagramas de Gantt e histogramas de recursos, hasta otras más avanzadas como redes PERT y costeo por valor ganado (earned value). OpenProj está disponible para Linux, Unix, Mac y Windows, y puede abrir archivos de MS Project y Primavera. Hemos descargado la versión más reciente de OpenProj (beta 3) y consideramos que la funcionalidad es bastante buena en términos del motor y sus capacidades. Sin embargo, su punto débil está en su usabilidad, que todavía no está a la par de la de productos comerciales (la experiencia también puede variar dependiendo de la versión de JRE que tengas, ya que el GUI utiliza Swing). Aun así, consideramos que es un producto interesante y con futuro. Mayor información en www.openproj.org www.sg.com.mx

www.sg.com.mx

SEP-OCT 2007

// PRODUCTOS

/* HERRAMIENTAS*/

SQLite

La base de datos embebida Por Filein Rómmel León

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. 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.

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

SEP-OCT 2007

www.sg.com.mx

• 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

www.sg.com.mx

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 interoperabilidad. 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. • www.sqlite.org • sqlite.phxsoftware.com • www.superwaba.com • php.net/sqlite • sqlite-wince.sourceforge.net • www.mono-project.com/SQLite

SEP-OCT 2007

// ENTREVISTA

Conoce a los Key Speakers de

Orlando Rincón

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.

SEP-OCT 2007

¿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 ecowww.sg.com.mx

Fotografía cortesía de etakano.com

sistema 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 www.sg.com.mx

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. SEP-OCT 2007

// ENTREVISTA

Es bien sabido que cualquier país que pretenda tener una participación importante en la industria global de software requiere contar con una masa crítica de empresas acreditadas en modelos de procesos como CMMI. En el caso particular de México, ProSoft define una estrategia justamente con ese propósito, y a raíz de esto se ha apoyado a muchas empresas para sus proyectos de mejora y evaluación. Sin embargo, un factor que comúnmente queda en el olvido en este tipo de esfuerzos es el de las personas. Para mejorar su capacidad de procesos, la industria requiere consultores de procesos experimentados y profesionales, que conozcan y entiendan la problemática de las empresas locales. En pocas palabras, necesitamos gurús locales de mejora de procesos.

Miguel Serrano Miguel Serrano es uno de esos “gurús” en mejora de procesos de software. Fue el primer mexicano en conseguir la autorización del SEI como Lead Appraiser de SCAMPI (SCAMPI es el modelo de evaluación para CMMI), y es el pionero de esa generación de gurús de procesos que necesita nuestro país, y la región de América Latina en general. Miguel es investigador adjunto en el Centro de Investigación en Matemáticas (CIMAT) y dirige su propia empresa, MS SPI Solutions, la cual provee servicios en mejora y evaluación de procesos de software. ¿Qué tipo de trabajo haces en el CIMAT? El trabajo en el CIMAT se enfoca a la investigación (desarrollo y presentación de papers), y a la enseñanza y asesoría de alumnos. También hay un componente importante de vinculación y asesoría con la industria de software, instituciones de gobierno y otras instituciones académicas para ayudarlos a aplicar modelos como PSP, TSP, CMMI, SCAMPI y PSM. El trabajo de investigador es realmente apasionante, ya que me permite la propagación del conocimiento y evangelización de mis ideas de mejora de procesos y calidad del software alrededor del mundo. ¿Qué retos enfrentas como Lead Appraiser? Un reto presente para todos los SCAMPI Lead Appraisers es que el SEI es muy estricto con la calidad de las evaluaciones. Por lo

SEP-OCT 2007

tanto, hay que ser muy profesional en las evaluaciones, ya que los lead appraisers que realizan evaluaciones de mala calidad (a causa de falta de ética y profesionalismo, ignorancia, o negligencia) pueden perder la autorización del SEI e incluso se podría desacreditar a las empresas que esta persona ha evaluado. La calidad de las evaluaciones es un asunto serio que tenemos que cuidar en México y Latinoamérica. ¿Qué lecciones nos puedes compartir de la experencia que has tenido en América Latina? Considero que en América Latina existe una percepción equivocada de que los procesos son principalmente para las empresas grandes. Sin embargo, a nivel mundial está demostrado que la mayoría de las organizaciones que los implementa no son grandes empresas, sino organizaciones muy similares a nuestras PyMEs. Por ejemplo, de acuerdo con la versión más reciente del “Maturity Profile” que lista resultados de evaluaciones de CMMI/SCAMPI publicado por el SEI en Marzo 2007, el 45.9% de empresas evaluadas son empresas con menos de 100 empleados. ¿Cuál es tu opinión sobre la adopción de MoProSoft en comparación con CMMI? Dependiendo de sus intereses y objetivos, cada organización decide cual es el modelo que más le conviene implementar. Existen varios modelos, pero todos buscan el mismo

fin y se basan en los mismos fundamentos teóricos. En el caso de CMMI, ofrece la ventaja adicional de que ha sido adoptado por muchas organizaciones en el mundo, y por lo tanto es considerado como el estándar internacional de facto. Asi que si tu enfoque es vender al extranjero, tal vez CMMI sea la mejor opción. Aunque se ha manejado la idea de que CMMI solo es para empresas grandes, yo no estoy de acuerdo con esto. Por otro lado, la ventaja que tiene MoProSoft es que cuenta con algunas areas (e.g., Gestión de Negocio) con las que el CMMI no cuenta, y que ayudan a las PyMES en sus iniciativas de mejora. ¿Cuál es tu visión sobre la oportunidad que tiene la industria mexicana de software? Existe un gran mercado en la industria mundial de software. Como en todo, las empresas más competitivas, que producen con la mejor calidad y mejor precio, son los ganadores para exportar y vender a nivel mundial. En el caso de México, al mismo tiempo que enfrenta el reto de competir internacionalmente, también está el caso de empresas multinacionales, líderes en la industria, que se están estableciendo aquí. Esto genera un gran reto de supervivencia para las organizaciones locales, por lo que es imperativo que adopten tecnologías innovadoras, atraigan el mejor recurso humano, y adopten las mejores prácticas y procesos respaldados por evaluaciones reconocidas internacionalmente. www.sg.com.mx

Gavin es posiblemente la persona con mayor liderazgo a nivel mundial en el área de Java empresarial. Saltó a la fama por desarrollar Hibernate, un framework open source para ORM (mapeo objeto-relacional). Actualmente labora en JBoss – que ahora es parte de Red Hat–, dirigiendo el desarrollo de Seam, un framework para desarrollo de aplicaciones web. Gavin también dirige el desarrollo del JSR-299 (Web Beans), y representa a Red Hat en el desarrollo de las especificaciones de JSF 2.0, EJB 3.1 y JPA 2.0.

¿Por qué nos deberíamos interesar en Seam? Hay dos cosas únicas sobre Seam. La primera es que es el único modelo integrado de programación construido alrededor de estándares de Java. Y cuando digo integrado, no me refiero simplemente a que permita ejecutar varias tecnologías de forma conjunta, sino a tener un modelo de componentes unificado, que pueda ser utilizado por diferentes servicios (GUI, BPM, persistencia, etc). Seam es la primera iteración de este modelo. La segunda iteración es lo que se convertirá en el estándar Web Beans. Lo otro que hace especial a Seam es su arquitectura, que está especialmente diseñada para el manejo de estados. Las arquitecturas web tradicionales utilizan un enfoque sin estados (stateless), lo cual considero ridículo ya que un objeto sin estado es una contradicción. Lo que sucede en la mayoría de los casos es que los desarrolladores tienen que implementar manualmente la gestión de estados en sus aplicaciones. ¿Que está pasando en el área de ORM? Creo que el tema de la persistencia de objetos está resuelto, y que la industria ha decidido que ORM es la estrategia adecuada. Cuando desarrollas sistemas que requieren utilizar datos legados, realmente no tienes otra opción más que usar ORM (a menos de que quieras escribir código JDBC a mano, lo cual es tedioso, poco productivo, y difícil de mantener). Para aquellos casos donde no se necesita incorporar datos legados, utilizar ORM ya es casi tan sencillo como usar una base orientada a objetos, con la ventaja adicional de que otras aplicaciones externas pueden aprovechar tu modelo relacional. Creo que el principal problema de ORM que queda por resolver (y que estamos atacando en Seam) es la falta de un buen modelo para manejar contextos de persistencia extendida a través de una transacción. Hasta ahora, los desarrolladores tienen que lidiar con el uso de LazyInitializationException, NonUniqueObjectException, y similares, sin darse cuenta de que en el fondo esto es una limitación de la arquitectura que están usando. Esto puede ser resuelto con un modelo de programación conversacional, consciente de estado, como el que utiliza Seam o Web Beans. ¿Qué impacto ha tenido que Java se haya abierto como software libre? Creo que todavía es muy temprano para concluir algo al respecto. A largo plazo, podría ser grandioso para Java. Todo depende de que tan buen trabajo se haga para incorporar la innovación que surja de esto. Afortunadamente, Java todavía lleva mucha ventaja respecto a tecnologías competidoras, especialmente cuando se trata del desarrollo de aplicaciones empresariales de gran escala. Los lenguajes de scripting están de moda, pero éstos tienen limitaciones bien sabidas y documentadas, y nadie cuerdo usaría un lenguaje de scripting para un proyecto con más de 3 desarrolladores y un ciclo de desarrollo de más de un año. Yo soy un gran fan de Groovy, pero www.sg.com.mx

Gavin King

// ENTREVISTA

estoy consciente de que complementa a Java, no compite con él. De ninguna manera soy fan de Ruby, ni de Rails, creo que se les está dando mucho más crédito del que merecen. Muchos equipos de desarrollo están optando por simplemente usar un web container como Tomcat en lugar de un servidor de aplicaciones Java EE completo. ¿Consideras que Java EE ya está “sobrado”? Cualquier software maduro puede ser considerado como sobrado. Después de un par de años en el mercado, cualquier software empieza a desarrollar funcionalidad que solo es requerida por el 10% de los usuarios, y por lo tanto no requerida por el 90%. Sin embargo, el hecho es que casi cada usuario depende de un 10% diferente de la funcionalidad. Es así que para cada usuario individual, el software parece estar sobrado, pero entre todos no se pueden poner de acuerdo en qué parte(s) son las que sobran. ¿Quién es la persona en la industria de software que más admiras? Si no se me permite mencionar a mis amigos, entonces diría que Kent Beck. Su trabajo ha tenido un enorme impacto positivo en la industria. Pero en realidad, la persona a las que más respeto es Marc Fleury (fundador de JBoss que recientemente se retiró). Marc construyó una empresa a partir de la nada, y para la mayoría de los que formamos parte de ella, fue la empresa más humana y emocionante para la que hemos trabajado. SEP-OCT 2007

>>Conforme los microprocesadores son cada vez más poderosos y baratos, encontramos más y más pro-

ductos que contienen microprocesadores para dotarlos de cierta inteligencia. Los relojes, los automóviles, las cámaras, los reproductores de música; todos ellos ejecutan software. El término de software embedded, o embebido, se refiere a los sistemas de cómputo que residen —en muchos casos sin que el usuario siquiera se entere— dentro de estos productos. Desarrollar software embedded involucra retos completamente diferentes a los que la mayoría de los desarrolladores de software estamos acostumbrados. Mientras que en el desarrollo de aplicaciones empresariales, siempre estamos buscando olvidarnos del mundo físico, y nos enfocamos en abstracciones como entidades de información y procesos de negocio, en el desarrollo de software embedded sucede todo lo contrario. El software embedded es el software que se preocupa por el mundo físico, y por lo tanto se enfoca en problemas como medir el tiempo, ser capaz de detectar y responder a eventos en el ambiente, y lidiar con restricciones físicas. Es así que el software embedded no es simplemente software para dispositivos pequeños, sino que se desarrolla bajo un paradigma totalmente diferente al que los desarrolladores de software empresarial estamos acostumbrados. En las siguientes páginas compartimos tres artículos que nos abren la puerta a este mundo y el tipo de retos que se enfrentan al desarrollar software embedded.

SEP-OCT 2007

www.sg.com.mx

Embedded Software El software del mundo fĂsico

www.sg.com.mx

SEP-OCT 2007

Embedded Software

l software es un elemento indispensable en una muy amplia gama de dispositivos que utilizamos continuamente para nuestra vida diaria. Ya sea en la comodidad de nuestro hogar o en la oficina, así como en aplicaciones para la industria, representa un porcentaje cada vez mayor en el costo de desarrollo de muchos productos. Un buen ejemplo: el automóvil. Hace unos 30 años, la mayoría de los autos no incluían nada de software, operando completamente a partir de principios eléctricos y mecánicos. Hoy todos los autos en venta cuando menos cuentan con sofisticados sistemas de administración de la electrónica del motor y en muchos casos, van más allá con aplicaciones para entretenimiento y seguridad. Lo mismo sucede con electrodomésticos, teléfonos, aviones, máquinas automáticas de venta, cajeros automáticos, y edificios inteligentes. Hay varias definiciones de embedded software. Las más tradicionales lo definen como “procesamiento de información que está integrado profundamente con procesos físicos”. De manera bastante más amplia podemos entenderlo como “software que se ejecuta en dispositivos distintos de una computadora personal o un servidor de cómputo”. La primera definición es relevante para entender los retos a los que se enfrenta el desarrollador de software embedded, y la segunda para entender la oportunidad de negocio que representa el mercado de software para dispositivos. ¿De qué tamaño es el mercado? De 1980 a 2005 el volumen de líneas de código por proyecto creció a una tasa anual compuesta de 26% (los proyectos se vuelven cada vez más complejos) y el número de desarrolladores especializados en embedded ha crecido 8% anual (generando más empleos en la especialidad). En 2004 el mercado total era ya de 23 mil millones de dólares. Es un segmento de la industria del software que crece de manera más acelerada que la industria en su conjunto. Múltiples jugadores participan en el mercado embedded de software. Microsoft (Windows CE, Windows XP Embedded), Wind River (VxWorks, Linux), Symbian (SymbianOS), Palm, y Green Hills (INTEGRITY) desa-

Estado Actual y Tendencias Por Héctor Obregón Confiabilidad Recursos de

Hardware Limitados

Respuesta en Tiempo Real

Las fallas no pueden ser resueltas con ayuda del usuario (No Ctrl-Alt-Del)

Las expectativas de los usuarios son más altas Las consecuencias de una falla pueden ser muy graves, incluso la pérdida de vidas (control industrial, aeronáutica, automotriz)

Memoria limitada

Energía limitada, bajo consumo de energía

Fuentes de energía alternativa inestables (celdas solares, movimiento)

Las operaciones del software deben ejecutarse en periodos exactos (hard real time)

Las operaciones del software deben ejecutarse en periodos limitados

(soft real time)

Fig 1. Retos para el Desarrollo de Software Embedded.

rrollan sistemas operativos y herramientas de desarrollo con capacidades embedded. Cada proveedor sigue enfoques diferentes dependiendo de su experiencia y posicionamiento en el mercado. Microsoft, por ejemplo: apuesta a facilitar el desarrollo embedded al integrar sus herramientas de desarrollo para embedded dentro de su familia de herramientas de desarrollo para el escritorio (Visual Studio). Otros proveedores, como Wind River o Green Hills se especializan en este espacio buscando ganar, ofreciendo estabilidad y calidad técnica en sus productos, atributos fundamentales en el mundo embedded.

Atributos del Desarrollo Embedded El desarrollo de embedded software presenta retos para los desarrolladores de software que son diferentes a los que se presentan en el desarrollo tradicional para computadoras o servidores. Los tres atributos que típicamente tienen consideraciones especiales en el desarrollo de software embedded son: confiabilidad, limitaciones en recursos de hardware, y respuesta en tiempo real. La figura 1 ilustra y explica de forma más detallada dichos retos. Adicionalmente, cada vez son más los clientes que solicitan sistemas de este tipo, esperando obtener también los mismos atributos que cualquier proyecto de software. En particular, conforme el software se vuelve un componente

más importante del costo de muchos artículos, los clientes desean obtener características como alto grado de reuso, mantenibilidad, y flexibilidad que históricamente no han sido prioridad en el desarrollo de software embedded. La posibilidad de combinar todos estos atributos presenta dificultades de ingeniería de software y hay algunas tendencias interesantes al respecto. Todas estas tendencias comparten la búsqueda de mayores niveles de abstracción en el desarrollo de software embedded.

Tendencias Conforme el hardware en general continúa su inexorable mejora en la relación poder/precio, empieza a ser posible utilizar cada vez más hardware de propósito general en lugar de hardware dedicado para una solución vertical específica. Cada vez son más los dispositivos embedded que utilizan arquitecturas SoC (System-On-Chip) en lugar de circuitos integrados especializados. El uso de hardware de propósito general simplifica enormemente la portabilidad del software embedded entre diferentes dispositivos. Los sistemas operativos embedded son compactos y altamente eficientes. Por lo mismo en algunos casos no ofrecen al desarrollador muchas de las facilidades que sí se encuentran en sistemas de escritorio. Conforme los usuarios demandan más funcionalidad en sus disposi-

Héctor Obregón (msdnfan.blogspot.com) es fundador y Director General de emLink (www.emlink.com.mx), empresa de desarrollo de software que implementa soluciones en clientes corporativos como Televisa, Comex, MetLife y SAM’s Club, entre otros. Adicionalmente, Héctor es Microsoft MSDN Regional Director, Microsoft MVP para Windows Embedded y miembro del comité de dirección de la Comunidad .NET de México D.F.

SEP-OCT 2007

www.sg.com.mx

Fig 2. El concepto de tiempo lógico de ejecuciòn

tivos, los sistemas operativos han aumentado su complejidad y las funciones que ofrecen. Sin embargo, es fundamental que mantengan un núcleo altamente confiable y predecible. Por esta razón los sistemas operativos embedded más complejos (como Windows XP Embedded, Windows CE y Linux Embedded) son también altamente modulares, permitiendo al desarrollador elegir únicamente aquellas funciones que son necesarias para una solución específica. La modularidad en los sistemas operativos facilita el desarrollo de aplicaciones cada vez más complejas limitando las consecuencias en deterioro de confiabilidad que son críticas en sistemas embedded. Los lenguajes utilizados para desarrollar sistemas embedded son de alto nivel. Éstos permiten a los desarrolladores ser más productivos y ofrecer más funcionalidad por hora/hombre trabajada. En las fronteras del desarrollo embedded, como el desarrollo para teléfonos y PDAs de consumidor final (donde más se parece al desarrollo de software para computadora personal) podemos encontrar ya ambientes virtuales de ejecución como el Microsoft .NET Micro Framework, Microsoft .NET Compact Framework o el Java Platform Micro Edition. Estos ambientes facilitan enormemente el desarrollo de soluciones embedded para los desarrolladores que están acostumbrados al desarrollo tradicional. No obstante, para aplicaciones embedded donde se requiere un nivel de precisión y control elevado, aún no son adecuados. Lo que es particularmente cierto para las llamadas aplicaciones de tiempo real. En muchas aplicaciones embedded se presenta el concepto de ejecución en tiempo real. Por ejemplo: en un motor de auto funcionando a 6 mil revoluciones por minuto, el cigüeñal da una vuelta en exactamente 10 milisegundos. Una computadora de administración de la electrónica del motor se enfrenta a límites inamovibles en cuanto al tiempo que puede utilizar para calcular funciones como por ejemplo: determinar en qué momento la bujía de un cilindro debe disparar su chispa. www.sg.com.mx

release

Logical Execution Time (LET)

logical view

task invocation running

physical

terminate

time

running

view

Para poder enfrentar estos requerimientos necesitamos un sistema operativo de tiempo real. Los sistemas operativos de este tipo pueden garantizarnos tiempos precisos de respuesta para cada una de sus funciones en un hardware determinado. Los sistemas de tiempo real pueden ser duros o suaves. Característica

“Duro”

“Suave”

Tiempo de respuesta

Requerido Deseado

Desempeño bajo carga pico

Predecible Degradado

Control del ritmo

Ambiente Computadora

Redundancia Activa

Punto de verificación

Detección de errores Autónoma Asistida por usuario

Construir una aplicación con requerimientos de tiempo real duro que además sea reusable, portable y de fácil mantenimiento, en definitiva no es una tarea trivial. Para contribuir a lograrlo, en el año 2000 el proyecto Giotto de la Universidad de California en Berkeley creó el concepto de tiempo lógico de ejecución (Logical Execution Time): una abstracción del tiempo físico real de ejecución que permite construir sistemas que garanticen un tiempo de ejecución de manera independiente del hardware. La siguiente lista resume las principales tendencias involucradas en el desarrollo de software embedded:

• Circuitos dedicados > Hardware de propósito general • Lenguaje ensamblador > Lenguajes de alto nivel y ambientes virtuales de ejecución • Tiempo real físico > Tiempo real lógico • Sistemas operativos compactos > Sistemas operativos modulares Todas estas tendencias que hemos considerado para el desarrollo de software embedded tienen el mismo objetivo: aumentar la productividad de los desarrolladores de software embedded manteniendo a salvo los atributos fundamentales que han diferenciado históricamente a las aplicaciones embedded. Podemos esperar que estas tendencias se intensifiquen en el futuro del desarrollo embedded, como parte de la inexorable búsqueda por ofrecer más y mejor funcionalidad a nuestros usuarios en cada vez menos tiempo.

Referencias • Henzinger, T. A. (2000). “The Fixed Logical Execution Time Assumption”. • Jerraya, A. A. (2005). “Longterm Trends for Embedded Software Design”. CEPA 2 Workshop. Brussels. • Pree, D. W. (2005). “Trends in Embedded Software Engineering”. Salzburg: Universität Salzburg. • Venture Development Corporation. (2004). “Embedded Software Trends”.

SEP-OCT 2007

Zigbee

Comunicaci贸n para Dispositivos Por Christian P. Garc铆a

SEP-OCT 2007

www.sg.com.mx

n los últimos años el uso de computadoras se ha incrementado notablemente, y no sólo me refiero a las computadoras de escritorio o portátiles; sino que también incluyo esas pequeñas computadoras que se han ido posicionado en nuestro entorno cotidiano sin hacerse notar mucho: computadoras que se encuentran en televisores, equipos de sonido, lavadoras, automóviles, ventiladores, sistemas de alarma entre otros; y al igual que cualquier otra computadora, éstas requieren de software para funcionar. Es un fenómeno que afecta directamente la demanda de desarrollo de software. Surgen nuevas aplicaciones, nuevas necesidades y con ello nuevas oportunidades de desarrollo. Una de ellas son las redes inalámbricas de sensores: pequeños dispositivos con poder de procesamiento y radio comunicación que con un par de baterías AA pueden operar por años sin mantenimiento alguno, además son lo suficientemente baratos como para integrarlos en televisores, modulares, lámparas, sensores, etcétera; con la finalidad de habilitar el control y monitoreo remoto. Existen actualmente varias tecnologías propuestas para resolver el problema de comunicación inalámbrica en este tipo de redes, entre ellas se encuentra Zigbee, misma que presentaremos a continuación. Desde su arquitectura hasta su aplicación. Abordando temas como ahorro de energía, interoperabilidad, interconectividad, seguridad, implementaciones existentes en el mercado y áreas de oportunidad.

¿Qué es Zigbee y Quién lo Promueve? La alianza Zigbee es un ecosistema internacional de compañías (Motorola, Philips, Samsung, Honeywell y Siemens entre otras) cuyo objetivo es habilitar redes inalámbricas con capacidades de control y monitoreo que sean confiables, de bajo consumo de energía y de bajo costo; todo basado en un estándar público global que permita a los fabricantes alrededor del mundo crear productos que sean compatibles entre ellos. Una de las tareas más importantes de la alianza es definir el conjunto de protocolos que habilitarán la comunicación entre los dispositivos, y es a esta definición de protocolos a la que se le conoce como Zigbee. En otras palabras: ZigBee es un protocolo de comunicaciones inalámbricas basado en el estándar para redes inalámbricas de área personal (WPANs) IEEE 802.15.4.

Resumen Técnico Zigbee es una tecnología inalámbrica que opera en las bandas libres ISM (Industrial, Scientific & Medical) de 2,4 GHz, 868 MHz

-Acceso -Seguridad -Ventilación -Iluminación

-Monitoreo de pacientes -Monitoreo corporal

CUIDADO DE SALUD PERSONAL

AUTOMATIZACIÓN COMERCIAL DE EDIFICIOS

-Puntos de venta -Servicios de red alternativos TELECOMUNICACIONES

ZigBee Control inalámbrico que simplemente funciona

0:48´34 MEDICIÓN AUTOMATIZADA

-Rastreo de equipo -Control de procesos -Manejo de energía

-Medición inteligente -Control de consumo

-Seguridad

CONTROL INDUSTRIAL

-Ventilación AUTOMATIZACIÓN DEL HOGAR

-Control de iluminación

-Control de acceso -Irrigación del jardín

Figura 1. Tecnologías inalámbricas.

(Europa) y 915 MHz (EEUU). Tiene una velocidad de transmisión de 250 Kbps y un rango de cobertura de 10 a 75 metros. A pesar de coexistir en la misma frecuencia con otro tipo de redes como WiFi o Bluetooth su desempeño no se ve afectado, esto es debido a su baja tasa de transmisión y, a características propias del estándar IEEE 802.15.4. Como se puede apreciar en la figura 1, Zigbee cubre un área en la que otras tecnologías no desempeñan un buen papel, ya que fueron diseñadas a partir de diferentes requerimientos. Como es el caso de UWB (Ultra Wide Band) alta velocidad de transmisión sin importar el poco alcance, o bien el caso de las redes celulares donde el alcance es lo que más importa. El mismo Bluetooth que se compara constantemente con Zigbee tiene diferentes capacidades en cuanto a velocidad de transmisión y rango de cobertura. Zigbee se caracteriza por la capacidad de operar redes de gran densidad, situación que ayuda a aumentar la confiabilidad de la comunicación, ya que entre más nodos existan dentro una red, mayor número de rutas alternas existen para garantizar que un paquete llegue a su destino. Cada red Zigbee tiene un identificador de red único, lo que permite que coexistan varias redes en un mismo canal de comunicación sin problema alguno. Teóricamente pueden existir hasta 16,000~ diferentes redes en un mismo canal y cada red puede estar constituida por hasta 65,000~ nodos, obviamente estos limites se ven truncados por algunas restricciones físicas (memoria disponible, ancho de banda). Por otra parte,

Zigbee también delimita las características de la red y esto lo hace en función del área de aplicación en la que se utilice. Es también un protocolo de comunicación multi-salto, esto quiere decir que existe comunicación entre dos nodos aun cuando estén fuera del rango de transmisión, siempre y cuando existan otros nodos intermedios que los interconecten. Esta propiedad incrementa significativamente el área de cobertura de la red. Una de las características de mayor valor de Zigbee es su topología de malla (MESH), que permite a la red auto recuperarse de problemas en la comunicación aumentando su confiabilidad. Zigbee define tres tipos de dispositivos diferentes: • Coordinador: es el dispositivo que inicia una red, y forma la raíz de ésta. Es capaz de almacenar información de su red, y puede actuar como “centro de confianza” al almacenar y administrar las llaves de seguridad. Solamente puede haber un coordinador por red. • Ruteador: además de ejecutar alguna función aplicativa, un ruteador puede funcionar como intermediario, sirviendo como puente de datos hacia otros dispositivos. • Dispositivo final: contiene solamente la funcionalidad necesaria para hablar con su nodo padre; no puede pasar datos a otros dispositivos. Por lo general este tipo de dispositivo mantiene desactivado el radio transmisor la mayor parte del tiempo, con la finalidad de consumir la menor cantidad de energía posible y así obtener una larga vida de las baterías, lo cual es uno de los principales beneficios de Zigbee.

Christian P. García actualmente es director de ingeniería de software de Ubilogix, empresa que se dedica al desarrollo de embedded software especializada en comunicación inalámbrica. Es egresado del CICESE, donde obtuvo el grado de maestro en Ciencias de la Computación por su trabajo en el diseño de protocolos de comunicación enfocándose en movilidad transparente en IP, el cual fue publicado por la editorial Springer en su serie LNCS. Los últimos años se ha dedicado a la investigación y desarrollo en redes inalámbricas de sensores, y participó en el desarrollo de una de las implementaciones de Zigbee certificadas.

www.sg.com.mx

SEP-OCT 2007

En cuanto a seguridad se refiere, se utiliza el estándar estadounidense AES128 para cifrado y autentificación de los paquetes que viajan por el aire.

APLICACIONES/PERFILES CAPA DE SOPORTE A LA APLICACIÓN

Figura 3. Áreas de aplicación de Zigbee.

Aplicaciones Inalámbricas de Video

UWB 802.11 g 802.11 a

IrDA

Aplicaciones Inalámbricas de Datos

Trasnferencia de datos

Silicio

Más rápido

Video

ZigBee

IEEE

CAPA FISICA

• La capa de más bajo nivel es la capa física, que en conjunto con la capa de acceso al medio, brindan los servicios de transmisión de datos por el aire, punto a punto. Estas dos capas están descritas por el estándar IEEE 802.15.4. • La siguiente es la capa de red, la cual brinda los métodos necesarios para: iniciar la red, unirse a la red, enrutar paquetes dirigidos a otros nodos en la red (el algoritmo de enrutamiento de malla está basado en el protocolo Ad Hoc On-Demand Vector Routing – AODV), proporcionar los medios para garantizar la entrega de paquete al destinatario final, filtrar paquetes recibidos, cifrarlos y autentificarlos. • La siguiente capa es la de soporte a la aplicación que es la responsable de mantener el rol que el nodo juega en la red, filtrar paquetes a nivel de aplicación, mantener la relación de grupos y dispositivos con los que la aplicación interactúa y simplificar el envío de datos a los diferentes nodos de la red. En el nivel conceptual más alto, se encuentra la capa de aplicación que no es otra cosa que la aplicación misma.

Aplicación

CAPA DE ACCESO AL MEDIO

Vo z

Wi-Fi 802.11 lb

Red Celular 2.5G/3G

Bluetooth

ZigBee Más lento

Zigbee es una pila (stack) de protocolos, que semejante al modelo de referencia OSI está constituido por diferentes capas independientes una de otra, y cada una de ellas cumple funciones especificas. La figura 2 ilustra las diferentes capas que conforman la pila.

ZigBee

CAPA DE RED

Arquitectura

Figura 2. Pila de protocolos Zigbee.

OEM

Transferencia de Datos

Más cerca

Monitoreo & Control Rango de cobertura

Redes Inalámbricas de sensores y control

Más lejos

Áreas de Aplicación

sobre este tema terminamos la conversación con un nuevo escenario de aplicación, algunos quizás un tanto ficticios pero la mayoría completamente realizables. El detalle está en encontrar quien financie el desarrollo. Actualmente cerca de 300 compañías se han integrado a la alianza Zigbee; un gran número de ellas se encuentran desarrollando productos que van desde electrodomésticos hasta teléfonos celulares, impulsando el área que les interesa respectivamente. En la figura 3 se presentan los grupos más dominantes de aplicaciones que están en la mira de Zigbee. Hay que recordar que Zigbee está diseñado para aplicaciones que transmiten unos cuantos bytes esporádicamente, que es el caso de una aplicación para automatizar el hogar. Al usar esta tecnología no tendrías que cablear los interruptores y los podrías cambiar de lugar sin problema alguno, sin contar que podrías apagar o prender las luces de tu casa a través de Internet o utilizando tu teléfono celular cuando estás de vacaciones.

parte de una red con otros dispositivos como displays ubicados dentro de las casas, que pueden monitorear el consumo de energía y no sólo eso, sino que también pueden interactuar con electrodomésticos o cualquier otro sistema eléctrico como bombas de agua o calefacción, con la finalidad de aprovechar mejor la energía. Zigbee goza de un importante respaldo para la gestión energética y para las soluciones de consumo eficiente por parte de la industria de los servicios públicos; y por parte de los patrocinadores de las redes energéticas inteligentes en varios países. Otra área de aplicación prometedora es el rastreo de bienes, también está en la lista la identificación vehicular, nodos ubicados en vehículos que permiten identificar al vehiculo a distancia y descargar información que ha recopilado por un periodo de tiempo determinado. Este tipo de escenarios se encuentran al alcance de la tecnología actual. Las anteriores son sólo algunas de las múltiples aplicaciones que se le pueden dar a las redes en cuestión.

El mercado para las redes Zigbee comprende una amplia variedad de aplicaciones que sería imposible enumerar en unos cuantos párrafos. Cada vez que platico con alguien

Otra de las aplicaciones que ha tomado fuerza, es la de los sistemas de medición avanzada, medidores de agua, luz y gas que forman

Como lo mencioné al inicio de este artículo, la demanda del desarrollo de software sigue en aumento, incluido el software embebido.

Cada capa se comunica con sus capas subyacentes a través de una interfase de datos y otra de control, las capas superiores solicitan servicios a las capas inferiores y las inferiores reportan resultados a las superiores. Además de las capas mencionadas, a la arquitectura se integran otro par de módulos que realizan tareas especificas: el módulo de seguridad que es quien provee los servicios para cifrar y autentificar los paquetes, y el módulo de administración del dispositivo Zigbee, que es quien se encarga de administrar los recursos de red del dispositivo local, además de proporcionar a la aplicación funciones de administración remota de la red.

SEP-OCT 2007

www.sg.com.mx

Conociendo Windows CE

Tutorial Para Iniciar un Programa de Forma Automática Por Carlos Maya

os 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. www.sg.com.mx

SEP-OCT 2007

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.

SEP-OCT 2007

www.sg.com.mx

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.

Figura 2. Creando un proyecto WCE tipo consola.

#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 3. Agregando llaves al registry.

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

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.

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.

www.sg.com.mx

SEP-OCT 2007

// PRÁCTICAS

/* REQUERIMIENTOS*/

Obtención de Requerimientos Técnicas y Estrategia Por César 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”.

SEP-OCT 2007

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: 1. El área de la aplicación no está bien definida (posiblemente por ser algo muy novedoso). 2. El costo del rechazo de la aplicación por los usuarios es muy alto. 3. 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: 1. Al demostrar las funciones del sistema se identifican las discrepancias entre los desarrolladores y los usuarios.

www.sg.com.mx

“Un sistema no tiene éxito si no se ajusta a los factores sociales y organizaciones que rigen a la empresa”.

2. 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. 3. Aunque limitado, se dispone rápidamente de un sistema que funciona y demuestra la factibilidad y usabilidad de la aplicación a administrar. 4. 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.

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.

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.

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.

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.

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.

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

www.sg.com.mx

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: 1. 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. 2. Estructuración de puntos de vista, que comprende agrupar los

SEP-OCT 2007

// PRÁCTICAS

/* REQUERIMIENTOS*/

“Los estudios etnográficos pueden revelar los detalles de los procesos críticos”.

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. 3. Documentación de puntos de vista, que comprende refinar la descripción de éstos y los servicios identificados. 4. 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: 1. Los datos proporcionados desde un punto de vista o proporcionados a éste se representan como elipses. 2. Las entradas y salidas de la información de control se ubican en la parte superior de cada recuadro. 3. Las salidas de datos se ubican a la derecha de cada recuadro. Si no están encerradas, significa que pertenecen al sistema. 4. Las excepciones se muestran en la parte inferior del recuadro. Si existen varias excepciones posibles, éstas se encierran en un recuadro. 5. 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: 1. 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. 2. 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: 1. 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. 2. De ser posible, se observará el sistema en acción. No se plan-

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

SEP-OCT 2007

www.sg.com.mx

teará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. 3. 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. 4. 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. 5. 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.

Conclusión El analista o ingeniero de requerimientos enfrenta una gran cantidad de retos al tratar de obtener los requerimientos de un sistema de software. Sin embargo, un analista con experiencia será capaz de aplicar una o más de las técnicas descritas en el presente artículo, con el objetivo de realizar una buena tarea de obtención de requerimientos. Como trabajo futuro se planea realizar una investigación a distintos tipos de proyectos de desarrollo de software, con el objetivo de determinar los principales atributos o características que influyen en la efectividad de cada una de las técnicas mostradas anteriormente, y de esta manera tratar de obtener una mayor confiabilidad al momento de seleccionar una u otra de las diferentes técnicas de educción de requerimientos.

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. www.sg.com.mx

SEP-OCT 2007

// PRÁCTICAS

/* PROGRAMACIÓN*/

Expresiones Regulares Conócelas y Piérdeles el Miedo Por Pedro Galván

Una expresión regular es una cadena de caracteres que es utilizada para describir o encontrar patrones dentro de otros strings, en base al uso de delimitadores y ciertas reglas de sintaxis. La mayoría de los programadores no se dan el tiempo de aprender a aplicar las expresiones regulares, lo cual es una lástima ya que son de gran utilidad. Cuando aprendas a aplicar las expresiones regulares, te darás cuenta de lo poderosas que son, la gran cantidad de problemas que pueden resolver, y lo mucho que aumentará tu productividad al programar.

Los metacaracteres reciben este nombre porque no se representan a ellos mismos, sino que son interpretados de una manera especial. Por ejemplo, a través de metacaracteres podemos definir diferentes condiciones tales como agrupaciones, alternativas, comodines, multiplicadores, etcétera. Los metacaracteres más usados son: . * ? + [ ] ( ) { } ^ $ | \. A continuación los explicamos de forma detallada.

Si es la primera vez que te acercas al concepto de expresiones regulares –también conocidas como “regex” en el argot de la programación– te animará saber que muy probablemente ya las has usado aún sin saberlo, al menos en su vertiente más básica. Por ejemplo, el comando dir *.txt para obtener un listado de todos los archivos con extensión txt es una forma muy sencilla de expresión regular, donde el patrón * coincide con cualquier cadena de caracteres. Veamos el ejemplo sencillo de un patrón y las cadenas con las que podría coincidir:

Metacaracteres de posicionamiento, o anclas Los signos ‘^’ y ‘$’ sirven para indicar donde debe estar situado nuestro patrón dentro de la cadena para considerar que existe una coincidencia.Cuando usamos el signo ‘^’ queremos decir que el patrón debe aparecer al principio de la cadena de caracteres comparada. Cuando usamos el signo ‘$’ estamos indicando que el patrón debe aparecer al final del conjunto de caracteres. O más precisamente, antes de un caracter de nueva línea. Ejemplo:

am am ambicion campamento mano

// este es nuestro patrón. Si lo comparamos con: // coincide // coincide // coincide // no coincide

Se trata sencillamente de ir cotejando un patrón (pattern) -que en este ejemplo es la secuencia de letras ‘am’- con una cadena (subject) y ver si dentro de ella existe la misma secuencia. Si existe, decimos que hemos encontrado una coincidencia (match). Estos ejemplos son muy sencillos ya que utilizan patrones literales, es decir que solo encontramos coincidencias cuando hay una ocurrencia exacta. De hecho, normalmente no es necesario usar expresiones regulares si vamos a textos exactos. Todos los lenguajes tienen funciones de string para este propósito. El poder de las expresiones regulares radica precisamente en la flexibilidad de los patrones, que pueden ser confrontados con cualquier palabra o cadena de texto que tenga una estructura conocida.

Caracteres y metacaracteres

De la misma forma, la expresión ^$ se puede utilizar para encontrar líneas vacías, donde el inicio de una línea es inmediatamente seguido por el final de ésta. Los metacaracteres ‘^’ y ‘$’ también conocidos como anclas (anchors) ya que no representan otros caracteres, sino posiciones en una cadena.

Escapando caracteres Puede suceder que necesitemos incluir en nuestro patrón algún metacaracter como signo literal, es decir, por si mismo y no por lo que representa. Para indicar esta finalidad usaremos como caracter de escape a la barra invertida ‘\’. Como regla general, la barra invertida \ convierte en normales a los caracteres especiales. Ejemplo:

Nuestro patrón puede estar formado por un conjunto de caracteres (letras, números o signos) acompañado de metacaracteres que representan a otros caracteres o permiten una búsqueda contextual.

SEP-OCT 2007

www.sg.com.mx

El comodín ‘.’ El metacaracter ‘.’ (punto) es el comodín por excelencia. Un punto en el patrón representa cualquier caracter excepto nueva línea. Ejemplo:

Observa en el ejemplo anterior como el patrón coincide con cualquier caracter (incluido el de espacio en blanco) seguido de una l.

Clases de caracteres Los corchetes ‘[ ]’ definen una clase de caracteres y permiten encontrar cualquiera de los caracteres dentro de un grupo. Imaginemos que queremos encontrar la palabra “niño”, pero también queremos encontrar en caso de que la hayan escrito con n el lugar de ñ. Podríamos lograr esto con una clase de caracter, de forma que la expresión regular ni[ñn]o se interpretaría como “n, seguida de i, seguida ya sea de ñ o n, seguida de o”. La mayoría de los metacaracteres pierden su significado al ser utilizados dentro de clases de caracteres. Es así que la expresión [a.] se refiere literalmente a la letra a y al caracter punto. Un caso especial es el caracter ‘^’, que al ser utilizado al comienzo de una clase de caracteres significa negación. Es decir que la expresión [^a] se refiere a cualquier cadena que NO contenga la letra a. Este significado se pierde si el ‘^’ no está al inicio de la clase de caracteres, así que la expresión [a^] se refiere a la letra a y al caracter ^ literalmente. Así como la mayoría de los metacaracteres pierden su significado especial al ser utilizados dentro de corchetes, existe un caracter que solamente al ser utilizado dentro de corchetes adquiere un significado especial. Este es el caracter ‘-‘ (guión), el cual se utiliza dentro de una clase de caracteres para indicar un rango. Por ejemplo, si queremos referirnos a un caracter hexadecimal, en lugar de definir la clase [01234567890abcdefABCDEF] utilizaríamos [0-9a-fA-F], que es mucho más conveniente. Veamos ejemplos con algunas clases de caracteres:

www.sg.com.mx

SEP-OCT 2007

// PRÁCTICAS

/* PROGRAMACIÓN*/

“A través de metacaracteres podemos definir diferentes condiciones tales como agrupaciones, alternativas, comodines, multiplicadores, etcétera”.

Algunos lenguajes de programación definen atajos para clases de caracteres que son comúnmente utilizadas. La siguiente tabla muestra algunos de los atajos más comunes:

Estos metacaracteres se aplican al caracter (o agrupación) que les precede, e indican el número de veces que se puede encontrar dicho elemento para que haya una ocurrencia. Los tres metacaracteres cuantificadores son ‘?’ ‘*’ ‘+’. El ‘?’ indica una multiplicidad de 0 o 1, el ‘*’ indica una multiplicidad de 0 a n, y el ‘+’ indica una multiplicidad de 1 a n. Los siguientes ejemplos dejan esto más claro:

Delimitación Los paréntesis se pueden utilizar para definir un subconjunto dentro de una expresión. Por ejemplo, para capturar la parte correspondiente al hostname de un url, utilizaría una expresión como http://([^/]) lo que estoy diciendo con esta expresión es que primero tengo la secuencia de caracteres “http://” y seguido de esto tengo una subexpresión, la cual estoy delimitando con los paréntesis, y aplico una expresión a este segmento en específico, en este caso estoy buscando una cadena que coincide con cualquier caracter excepto el ‘/’.

Alternativas

También es posible indicar la multiplicidad exacta que es aceptable para un cuantificador. Para esto se utilizan las llaves ‘{ }’, y la sintaxis es primero indicar el valor mínimo de la multiplicidad, seguido de una coma, y luego el valor máximo de la multiplicidad.

El metacaracter ‘|’ (barra vertical) significa “o” (or). Permite buscar diferentes alternativas de expresiones (más bien subexpresiones), dentro de una sola expresión. Esa definición sonó muy enredada, así que mejor expliquémoslo con un ejemplo. Imaginemos que tenemos la expresión Doña y la expresión Don. Cada una es una expresión separada, pero si definimos la expresión Don|Doña entonces tenemos una sola expresión que coincide con cualquiera de las dos subexpresiones. También podemos utilizar los paréntesis para delimitar el alcance de una alternativa. En este caso, la expresión Do(n|ña) nos daría el mismo resultado que la expresión Don|Doña. Sin embargo, hay que tener cuidado con abusar del uso de paréntesis, porque podemos terminar con expresiones difíciles de entender, y por lo tanto de mantener.

Cuantificadores o Multiplicadores Los metacaracteres que hemos visto nos informan si nuestro patrón coincide con la cadena a comparar. Pero ¿y si queremos comparar con nuestra cadena un patrón que puede estar cero, una o mas veces? Para esto usamos un tipo especial de metacaracteres: los multiplicadores.

SEP-OCT 2007

Conclusión En este artículo hemos estudiado la sintaxis y metacaracteres utilizados para definir expresiones regulares. Ahora lo que queda es que escojas el lenguaje de programación de tu preferencia y comiences a experimentar con el uso de expresiones regulares. Te garantizo que es una habilidad que te será de gran utilidad.

Referencias • Autor anónimo. “Expresiones regulares”. www.ignside.net/man/php/regex.php • Mike Malone. “The bare minimum that every programmer should know about regular expressions. http://immike.net/blog

www.sg.com.mx

// PUBLIRREPORTAJE

Una Multitud de Innovaciones

Nueva Generación de Laptops Basadas en Tecnología de Procesador Intel® Centrino®

Procesadores más veloces En el corazón de las nuevas laptops se encuentra la generación más reciente del procesador Intel® Core® 2 Duo, que ofrece un desempeño sin precedentes. El bus de sistema tiene una velocidad de 800 Mhz y provee switcheo dinámico de frecuencia. Esto significa que la frecuencia de reloj del bus así como el voltaje se ajustan dinámicamente dependiendo de la actividad, para lograr un menor consumo de energía.

Gráficos formidables La familia de chipsets Mobile Intel 965 Express es la arquitectura de chipsets de siguiente generación para laptops que utilizan la Tecnología de procesador Intel® Centrino® Duo. Entre las nuevas características clave se cuentan: • Una suite de controladores diseñados para explotar las capacidades visuales de Microsoft Windows Vista Premium. • Intel® Clear Video Technology, que incluye varias características (ProcAmp API, detección y corrección de modo de película, aceleración de hardware MPEG2 y WMV9, desentrelazado avanzado) que hacen posible una mejor experiencia en video de alta definición. • Intel® Graphics Media Accelerator X3100 ofrece una mayor frecuencia del núcleo gráfico de 500 MHz y hasta 384 MB de memoria de video.

Conexión inalámbrica más potente y rápida Intel® Next-Gen Wireless-N es la solución opcional para LANs inalámbricas que además de soportar los estándares IEEE 802.11a/b/g también provee soporte para el anteproyecto 802.11n, que ofrece velocidades de hasta 300 Mbps y un alcance de hasta 70 metros.

Desempeño turbocargado Intel® Turbo Memory es una característica opcional que mejora el desempeño, acorta el tiempo de inicio y prolonga la vida de la batería. En sí, es un módulo de memoria no volátil que incrementa el desempeño del sistema al mismo tiempo que reduce el consumo de energía.

Laptops que se traducen en negocios Como parte de esta nueva generación, se ha lanzado la nueva marca Intel® Centrino® Pro, la cual está dirigida a usuarios de negocios, e incorpora las características innovadoras que se encuentran en las PCs de escritorio con la tecnología Intel® vPro. Una de estas

características es la tecnología Intel® Active Management Technology, la cual provee capacidades de administración inalámbrica de la PC, así como protección y reparaciones remotas, con lo cual se mejora la productividad, los ahorros para TI y el tiempo de actividad de los sistemas.

PCs de escritorio más compactas, silenciosas y estilizadas Vale la pena mencionar que Intel® también utilizará estos nuevos avances en su tecnología móvil para incorporarlos en PCs de escritorio, de tal forma que se puedan desarrollar nuevos diseños de PCs de escritorio más compactos, silenciosos y de alto desempeño.

Adam Savage y Jamie Hyneman, del programa de televisión Mythbusters, comparan una computadora portatil de 1971 con una laptop moderna con tecnología Intel® Centrino® Duo.

Este verano, Intel® lanzó la nueva generación de Tecnología de Procesador Intel® Centrino® para computadoras portátiles. Las características de esta nueva generación se resumen en procesadores más veloces, gráficos formidables, señales inalámbricas más potentes y rápidas, y desempeño turbocargado.

Los elementos de la tecnología Intel Centrino Duo: • Procesador Intel® Core™2 Duo • Chipset Mobile Intel® 965 Express • Tarjeta de red Intel® Next-Gen Wireless-N • Intel® Turbo Memory (Opcional)

// PRÁCTICAS

/* GESTIÓN DE RECURSOS */

Tips para Reclutar Desarrolladores Regla #1: No se Aceptan Zoquetes Por 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.

SEP-OCT 2007

¿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.

¿Encajan 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?

www.sg.com.mx

¿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.

www.sg.com.mx

SEP-OCT 2007

// PRÁCTICAS

/* GESTIÓN DE RECURSOS */

• 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).

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.

SEP-OCT 2007

www.sg.com.mx

// PUBLIRREPORTAJE

Conceptos básicos sobre los estándares de T.I. Las normas o estándares son especificaciones técnicas, de carácter voluntario, consensuadas, elaboradas con la participación de las partes interesadas (fabricantes, usuarios / consumidores, laboratorios, administración, centros de investigación, etc.) y aprobadas por un organismo reconocido. Tienen el carácter de acuerdos documentados y contienen las especificaciones técnicas o criterios precisos para ser usados consistentemente como reglas, guías, o definiciones de características, asegurando de esta forma que los materiales, productos, procesos y servicios son apropiados para lograr el fin para el que se concibieron. La elaboración de estándares, o normalización, contribuye a simplificar y a incrementar la fiabilidad y eficiencia de los bienes y servicios que utilizamos, así como a mejorar el bienestar de la sociedad y redunda en el beneficio común. Las normas o estándares son, por tanto, documentos de aplicación voluntaria, elaborados por las partes interesadas, por consenso y aprobados por un organismo reconocido. En el ámbito internacional, la ISO (Organización Internacional de Normalización) y la IEC (Comisión Electrotécnica Internacional) tienen por objeto favorecer el desarrollo de la normalización en el mundo, con vistas a facilitar los intercambios comerciales y las prestaciones de servicios entre los distintos países. Los trabajos desarrollados por ISO cubren prácticamente todos los sectores de la técnica, con excepción del campo eléctrico y electrotécnico, cuya responsabilidad recae en IEC. Los miembros de ISO o IEC son los organismos que representan la normalización de un país. Tan sólo un organismo de cada país puede ser miembro de estas organizaciones. La participación en los comités técnicos de ISO/IEC puede ser como miembro “P” (participante) o bien “O” (observador). Los órganos de trabajo técnicos de ISO son los siguientes: • Comités Técnicos (TC): su función principal es el desarrollo de las normas internacionales y su revisión, en caso de que fuera necesario. Cada TC puede, si así lo cree conveniente debido a la amplitud de su campo de actuación, establecer subcomités (SC) y/o grupos de trabajo (GT) para cubrir temas específicos. • Subcomités (SC): tienen las mismas atribuciones que el TC y autonomía para realizar sus trabajos, con la única obligación de mantener informado al TC de sus actividades. • Grupos de Trabajo (GT): se crean para trabajos específicos emprendidos por el comité/subcomité. Los documentos elaborados por ISO/IEC son de dos tipos: • Norma internacional (ISO/IEC): norma elaborada por los miembros participantes en un comité técnico, subcomité o grupo de trabajo y aprobada por votación entre todos los participantes.

• Informe Técnico (TR): documento técnico elaborado para informar sobre los progresos técnicos de un tema determinado, dar recomendaciones sobre la ejecución de un trabajo y facilitar información y datos distintos a los que generalmente están contenidos en una norma. En México, el organismo de normalización para los temas de Electrónica, Tecnologías de Información y Telecomunicaciones es Normalización y Certificación Electrónica, A.C., NYCE. Desde hace doce años, NYCE ha generado numerosos estándares para la industria nacional. Hoy se vislumbra una enorme oportunidad para el país en la industria de software, por ello NYCE se ha abocado a generar 38 estándares para apoyar el desarrollo de este sector.

La actuación de NYCE, A.C. se enmarca en la concepción y homologación de normas de Tecnologías de la Información en materias de seguridad, métricas, servicios, procesos, madurez de capacidades, etc. Esto es una pieza fundamental para garantizar la confianza de individuos e instituciones en la sociedad de la información. Así, cabe formular los objetivos de la actuación del organismo, según los siguientes apartados: • Apoyar la integración de los sectores público y privado de nuestro país en los procesos de normalización nacional e internacional en el campo de la seguridad de las Tecnologías de la Información. • Apoyar el desarrollo de las normas de seguridad de las Tecnologías de la Información en los ámbitos nacional e internacional. • Canalizar la normalización nacional e internacional en el campo de la seguridad de las Tecnologías de la Información hacia las políticas y directrices de Tecnologías de la Información de los sectores público y privado de nuestro país. • Apoyar la difusión y uso de las normas de seguridad de las Tecnologías de la Información. Para mayor información, consulte: http://www.normalizacion-nyce.org.mx/php/loader.php? c=normas.php&page=11

// UML

INCLUSIÓN Y EXTENSIÓN DE CASOS DE USO LIDIANDO CON LA CONFUSIÓN Por Sergio Orozco y Lety Ortiz

Un tema que genera mucha polémica entre la gente que modela casos de uso es la elección entre la relación de <<include>> y <<extend>>. Lo peor es que muchas de esas discusiones generan muy poco valor en el resultado final en el modelo y en cambio quitan tiempo valioso del proyecto. Esto se debe a que dichas relaciones, muchas veces no son del todo comprendidas por la persona que la modela, y mucho menos son comprendidas por las personas que leen el modelo. Así que al final no se le saca el provecho que en todo caso debería de tener dicha elección. En el artículo en que hablamos de los casos de uso [SG jun2006: Los casos de uso y el valor del sistema] comentábamos que es mejor mantener el modelo simple, incluso si esto significa utilizar menos elementos gráficos de UML, si eso va a facilitar el modelado y la comunicación en el proyecto. Pero, después de todo este tiempo y de los diferentes temas que hemos venido tratando, es importante avanzar y adentrarnos en algunos pormenores del lenguaje unificado.

Figura 1. Relacionando casos de uso

Include. En términos muy simples, cuando relacionamos dos casos de uso con un “include”, estamos diciendo que el primero (el caso de uso base) incluye al segundo (el caso de uso incluído). Es decir, el segundo es parte esencial del primero. Sin el segundo, el primero no podría funcionar bien; pues no podría cumplir su objetivo. Para una venta en caja, la venta no puede considerarse completa si no se realiza el proceso para cobrarla en ese momento. El caso de uso “Cobrar Renta” está incluido en el caso de uso “Rentar Video”, o lo que es lo mismo “Rentar Video” incluye (<<include>>) “Cobrar Renta”.

Antes que todo, ¿qué es el “include” y el “extend”? Gráficamente lo que mostramos es una relación de dependencia entre el par de casos de uso, con el nombre correspondiente al tipo de relación de la que se trate: ya sea <<include>> o <<extend>>. Figura 2. Ejemplo de Include

Estas, son relaciones que usamos para ligar gráficamente dos casos de uso, cuyos flujos de eventos están unidos, normalmente en una sola sesión del usuario. En otras palabras, un caso de uso que está ligado, por medio de una de estas dos relaciones, a otro caso de uso; también podría leerse o ejecutarse como un sólo caso de uso en lugar de dos. Obviamente, hay una razón por la cual decidimos separarlos en dos, lo cual explicaremos más adelante. Imagina el conjunto de pasos que ocurren al realizar una compra en una tienda departamental. Seguramente no tendrás problema en visualizar el conjunto de pasos para solicitar la autorización de la tarjeta de crédito con la que vas a pagar, ligado a los pasos donde el vendedor registra los productos a comprar. Es decir, los flujos de eventos de ambos procesos forman una sola cosa; juntos podrían formar un solo caso de uso, en lugar de dos casos de uso unidos por alguna de estas relaciones que aquí estamos tratando.

Extend. La polémica al querer seleccionar una de las dos relaciones es que en el “extend” también podemos ver, desde la perspectiva del usuario, a los dos flujos como si fueran uno sólo. Y en ciertos escenarios el caso de uso base no podría cumplir su objetivo si no se ejecutara la extensión. Pero la principal diferencia entre estos dos tipos de relación, es que en el caso del “extend” hay situaciones en que el caso de uso de extensión no es indispensable que ocurra, y cuando lo hace ofrece un valor extra (extiende) al objetivo original del caso de uso base. En cambio en el “include” es necesario que ocurra el caso incluído, tan sólo para satisfacer el objetivo del caso de uso base. Ejemplo: Puedes “Realizar Venta” sin “Acumular Puntos de Cliente VIP”, cuando no eres un cliente VIP. Pero, si eres un cliente VIP sí acumularás puntos. Por lo tanto, “Acumular Puntos” es una extensión de “Realizar Venta” y sólo se ejecuta para cierto tipo de ventas, no para todas.

Sergio Orozco es director general e instructor senior de Milestone Consulting. Lety Ortiz es instructora y consultora en la misma empresa. Ambos se especializan en temas relacionados con UML. Milestone Consulting (UML Value Added Training Center), es una empresa especializada en capacitación práctica-intensiva y consultoría en UML, BPMN y PM. Milestone Consulting es la primer empresa mexicana miembro de la OMG, además de ser REP del PMI. info@milestone.com.mx www.milestone.com.mx

SEP-OCT 2007

www.sg.com.mx

Relaciones de Análisis o Diseño

Figura 3. Ejemplo de Extend

Casos de Abuso Uno de los riesgos que existe cuando la gente sabe que puede utilizar estas relaciones en sus modelos de casos de uso, es que pueden llegar a abusar de éstas, usándolas aun cuando no es necesario y solamente causan confusión. Mucha gente, y sobre todo la que arrastra prácticas de métodos estructurados, la suele utilizar en exceso. No es raro ver modelos de casos de uso que llegan a tener decenas de inclusiones y extensiones, incluso las inclusiones y extensiones se vuelven a extender a varios niveles, generando una maraña de casos de uso que no ofrecen valor al ser mostrados explícitamente.

Otra situación donde abusamos de estas relaciones se da cuando queremos representar la unión de casos de uso por una decisión de diseño del sistema, específicamente por cuestiones de navegabilidad entre funciones. Pensemos en cierta funcionalidad que corresponde a la ejecución de cierto caso de uso en un sistema (por ejemplo “Registrar Préstamo de un Video”). Si durante el diseño de interfase de usuario se decide agregar un botón que invoque funcionalidad de otro caso de uso (digamos, “Consultar Promociones”), esto no significa que haya una relación entre ambos casos de uso. No hay ni inclusión ni extensión entre estos casos de uso. Simplemente estamos hablando de una facilidad otorgada por la interfaz de usuario, la cual permite navegar fácilmente entre las diferentes funciones del sistema.

Reuso: Evitando el Retrabajo Una de las razones por las cuales deberías de considerar el uso de este tipo de relaciones, es porque identificas que hay pasos que son iguales en dos o más casos de uso. No querrás tener que escribir y darle mantenimiento a esos pasos en los documentos asociados a cada uno de ellos. Peor aún, no querrás correr el riesgo de que esos pasos se diseñen, programen y prueben de maneras diferentes y con esfuerzos aislados por ti o tu equipo de desarrollo. Finalmente son la misma cosa, ¿para qué querríamos trabajar doble? Lo que queremos es economizar, ser más eficientes en el desarrollo, y ahí es cuando viene el beneficio de identificar estos tipos de relaciones; porque es una oportunidad de identificar reuso.

Figura 4. Abuso de relaciones

Es importante comprender que el objetivo de estos tipos de relaciones NO consiste (remarco la negación) en motivar la división de los casos de uso en la mayor cantidad de pedazos. Debe de existir una razón importante para que decidamos dividir un caso de uso en dos que serán unidos por medio de alguna de estas relaciones. Si entendemos esto y somos congruentes, obtendremos un beneficio real para el proyecto; fin último del uso de UML. Figura 5. Identificación de reuso

La razón por la que la gente suele partir sus casos de uso en infinidad de “include” y “extend” es porque quieren conocer, entender y comunicar el máximo detalle de los casos de uso en el diagrama. Hay quien llega a utilizar, erróneamente, estas relaciones para mostrar el orden en que se ejecutan estos casos de uso. Debemos de recordar que al modelar el diagrama de casos de uso no buscamos analizar el detalle, y mucho menos los flujos. Todo ese detalle lo podremos plasmar en otro tipo de diagramas, como los diagramas de interacción, de actividad, de estados, o simplemente un texto en una especificación. www.sg.com.mx

Si te sientes preparado para desarrollar modelos de casos de uso más sofisticados y de mayor valor, entonces considera la posibilidad de utilizar estos tipos de relaciones. Sólo asegúrate de aprovecharlas adecuadamente, buscando el beneficio real que deberían de proporcionar en tu modelo y proyecto con base en las recomendaciones mencionadas. Y recuerda unificar los criterios dentro de tu empresa para que el lenguaje sea realmente unificado o estandarizado dentro de tu empresa. SEP-OCT 2007

// COLUMNA

/*TENDENCIAS EN SW*/

El Impacto del Web 2.0 en la Empresa Los Diferentes Escenarios

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

n 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 ser-

SEP-OCT 2007

vicio 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. —Luis Daniel Soto

www.sg.com.mx

SEP-OCT 2007

// COLUMNA INVITADA

Patentes de Software Conociendo la legislación Por Crescencio Villaseñor y Gloria Isla

as 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 computadora”, que son, en última instancia, aquellas invenciones físicas tradicionales que incluyen software en su funcionamiento. 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.

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

SEP-OCT 2007

www.sg.com.mx

SEP-OCT 2007

// PUBLIRREPORTAJE

developerWorks

El portal ideal para desarrolladores

IBM tiene un portal de acceso GRATUITO a tu alcance, donde podrás encontrar un sin fin de herramientas que te serán de gran ayuda. Se trata de IBM developerWorks, un portal líder en el mercado que ofrece acceso GRATUITO a herramientas de desarrollo y capacitación para desarrolladores. Esos recursos y soluciones te ayudarán a crear e implementar aplicaciones en sistemas heterogéneos.

¿Quiénes se benefician con los recursos devoloperWorks? • Desarrolladores de software, hardware y microcódigo. • Probadores, analistas y arquitectos. • Equipo técnico de TI. • Asociados de Negocio de IBM. • Estudiantes, equipo técnico y cuerpo docente de universidades.

Características • Portal de acceso gratuito. • Descargas gratuitas de Software IBM. • Acceso centralizado a herramientas, demos y entrenamiento para IBM Software Development Platform. • Recursos gratuitos para desarrolladores, administradores, arquitectos, diseñadores y probadores. • Road Maps de proyectos de TI para el ambiente on demand. • Contenido técnico práctico organizado por producto y tecnología.

developerWorks es uno de los portales para desarrolladores pioneros en el modelo Web 2.0 para participación y colaboración de la comunidad. A través del uso de tecnologías como blogs, wikis, podcats, chats y foros, developerWorks permite una mayor comunicación, eficiencia y productividad para sus miembros. Asimismo, a través de este modelo los desarrolladores aprenden las habilidades necesarias para aprovechar las tecnologías Web 2.0 y entender como es que estas herramientas se pueden aplicar dentro de sus organizaciones.

Por donde comenzar Para obtener el beneficio gratuito de las herramientas y recursos ofrecidos por el developerWorks: • Ingresa a ibm.com/developerworks • Suscríbete al newsletter de developerWorks en: ibm.com/developerworks/newsletter • Descarga los productos de evaluación. • Realiza tutoriales on-line. • Participa en los eventos técnicos y webcasts. • Solicita demos en DVD.

Capacitando en tecnologías abiertas developerWorks ofrece un ambiente para que los desarrolladores de todo el mundo participen en eventos técnicos on-line y off-line buscando no sólo conocimiento y capacitación, sino también intercambio de ideas sobre tecnologías que están formando el futuro del mercado. Dentro del ecosistema de developerWorks, los desarrolladores colaboran abiertamente, crean aplicaciones innovadoras y comprenden tecnologías avanzadas, como GRID Computing y Service-Oriented Architectures (SOA).

Regístrate ahora mismo en el portal de IBM developerWorks www.ibm.com/developerworks

www.sg.com.mx

SEP-OCT 2007

// FUNDAMENTOS

Espectro Semántico Un primer acercamiento Por Víctor Lorenzana

Recientemente hemos escuchado el término Web semántica, si buscamos en Wikipedia encontraremos que está definida así: “la Web semántica (del inglés semantic web) es la idea de añadir metadatos semánticos a la World Wide Web. Esas informaciones adicionales —describiendo el contenido, el significado y la relación de los datos— deben ser dadas de manera formal, de forma que sea posible evaluarlas automáticamente por máquinas. El destino es mejorar la World Wide Web ampliando la interoperabilidad entre los sistemas informáticos y reducir la necesaria mediación de operadores humanos”. Sin embargo, creo que es importante entender los conceptos que están alrededor de la Web semántica, y que nos permitirán ir asimilando lo que hoy está definido y que es la base para la actual y futuras tecnologías asociadas a este concepto. Para entender mejor el concepto de semántica, lo primero que tenemos que conocer es que existen diferentes niveles. La figura 1 ilustra los elementos de lo que se ha denominado el espectro semántico.

Figura 1. El espectro semántico

Metadatos El primer nivel dentro del espectro semántico son los metadatos, que son datos acerca de los datos. Quienes han desarrollado páginas web, recuerdan que en HTML existe la etiqueta “meta”, que permite proveer información sobre el documento, tal como quién es el autor de la página, la tecnología con la que se desarrolló, las palabras claves. Estos valores fueron utilizados por los primeros buscadores para separar información por temas, o por autor, o por palabras claves. Esta información permitiría hacer búsquedas más inteligentes. Sin embargo, los meta tags de HTML no tuvieron el éxito deseado, debido a que las personas que desarrollaban estas páginas no entendían la importancia de este tipo de información. Los meta tags han sido prácticamente abandonados, pero existen iniciativas nuevas, como el estándar Dublín Core, que prometen dar una mejor solución a este problema.

Taxonomía El siguiente nivel de semántica es la taxonomía, que es una jerarquización de la información. Este concepto se utiliza en las ciencias biológicas para clasificar a los seres vivos, pero también puede ser utilizado para clasificar información de cualquier índole. De hecho, lo hemos utilizado de una forma natural en muchas aplicaciones. Un ejemplo de esto es un sistema de archivos basado en directorios y subdirectorios. Cabe mencionar que cada nivel de semántica contiene al anterior. Así, el concepto de taxonomía puede ser usado en conjunción con el de metadatos. Entonces, un sistema de directorios incluirá dentro de su definición, un conjunto de metadatos, como lo son

los permisos, fecha de creación, propietario, entre otros. La figura 2 muestra un ejemplo sencillo de clasificación, en donde tenemos un continente, y una sub-clasificación es México, que a su vez esta sub-clasificado por estados.

Figura 2. Ejemplo de una taxonomía

Tesauro El siguiente nivel semántico es el tesauro, que es una extensión de las taxonomías para agregar elementos como sinónimos, homónimos, abreviaciones y antónimos. La figura 3 muestra como podríamos extender con tesauros al ejemplo expuesto anteriormente.

Figura 3. Ejemplo del uso de tesauros

Vemos entonces que el elemento Distrito Federal es equivalente a D.F. y DF, así que ahora sabemos que podemos encontrarlo en cualquiera de esas formas y se refiere a lo mismo.

Víctor Hugo Lorenzana González es consultor en INFOTEC, un centro público para la investigación y desarrollo perteneciente al CONACYT. Ha dedicado los últimos cinco años a la investigación y aplicación de conceptos semánticos aplicados a portales de colaboración y conocimiento. Víctor es Ingeniero en Computación de la Facultad de Ingeniería de la UNAM.

SEP-OCT 2007

www.sg.com.mx

Modelo conceptual El siguiente elemento semántico es el modelo conceptual. Este provee un mapa de información en base a una topología de red multirelación. Las dos notaciones más usadas para esto son Topic Maps, y RDF (Resource Description Framework). Formalmente, el modelo conceptual es una representación de un dominio, o área de conocimiento en el que se identifican: • Sus principales entidades o conceptos. • Las relaciones entre estas entidades. • Los atributos de las entidades de información y las relaciones existentes entre las mismas. La figura 4 muestra un ejemplo de un modelo conceptual.

Figura 4. Un mapa de tópicos representando un modelo coneptual

El último nivel del espectro semántico son las ontologías. Las ontologías representan información adicional sobre los conceptos de un dominio, y específicamente de las relaciones que hay entre ellos. Se utilizan para deducir nuevas relaciones de información en base a un modelo conceptual existente. Así, por ejemplo, si tenemos relaciones de información en donde A conduce a B, y B conduce a C, se puede generar una nueva relación donde A conduce a C.

Conclusión Aunque todavía no se ha logrado implementar el concepto de Web Semántica en su concepción ideal, es cierto que se están haciendo esfuerzos importantes por implementar dichos conceptos para la creación de aplicaciones que permitan procesar la información de la misma forma que un humano. INFOTEC se ha dedicado en los últimos años a hacer investigación y desarrollo en materia de utilización del concepto de redes semánticas. Como parte de este esfuerzo, hemos construido la herramienta INFOTEC WebBuilder Open Source, la cual implementa estos conceptos semánticos para estructurar la información que se genera en un sitio Web, permitiendo al cibernauta llegar facilmente a la información deseada.

Referencias • Michael C. Daconta, et al. “The Semantic Web”. Wiley, 2003. www.sg.com.mx

SEP-OCT 2007

// INFRAESTRUCTURA

Redes de Datos de Sensores

Metodología para la Recolección, Administración y Presentación de Datos Por Paul Javier Manchego Revilla

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.

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.

SEP-OCT 2007

www.sg.com.mx

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

Conclusión Este artículo presenta un análisis de los requerimientos esenciales para construir un sistema de administración de datos de sensores en el contexto de una federación. Además presenta la arquitectura del sistema con sus componentes más importantes y explica algunos escenarios para probar aspectos críticos de los mecanismos de recolección de datos de sensores.

www.sg.com.mx

SEP-OCT 2007

////TECNOLOGÍA TECNOLOGÍA

/* GADGETS */

Yoggie

Pico Personal Yoggie es una empresa israelí que provee productos para seguridad informática, y uno de sus productos más recientes es Pico. En si, Pico es una pequeña computadora con un procesador Intel a 520 MHz y sistema operativo Linux, que se conecta por interfaz USB a una computadora portátil para encargarse de todas las actividades relacionadas con la protección y seguridad, tales como firewall, antivirus, antispyware, y antiphishing. Esto ofrece dos grandes ventajas, la primera es una mejora notable en el desempeño, ya que ahora tu computadora ya no dedica recursos propios para ejecutar software de seguridad. La otra gran ventaja de Pico es que ofrece una separación física para aislar a tu computadora de los ataques, tal como si estuviera detrás de un firewall dedicado. Lo que sucede es que Pico se encarga de recibir todo el tráfico de la red, y solo hasta que lo analiza y decide que es seguro, entonces ya lo reenvía a tu computadora. Por el momento, no hemos encontrado un distribuidor local de Pico, pero se puede adquirir por Internet en www.yoggie.com por un precio de $179 dólares.

Canon

EOS 40D Canon dio a conocer el modelo 40D de su línea de cámaras digitales. Este modelo está dirigido a consumidores avanzados y semiprofesionales, y viene a reemplazar al 30D. Utiliza un sensor de imagen CMOS de 10.1 Megapixeles para lograr imágenes de gran calidad y nitidez. Llama la atención que la 40D utiliza el nuevo procesador DIGIC III, que es el mismo que viene en el modelo profesional EOS-1D Mark III. Gracias al uso del DIGIC III, la 40D obtiene un gran desempeño en el enfoque y procesamiento de imágenes. De hecho, soporta la toma continua (continuous shooting) de hasta 75 fotografías continuas a una velocidad de 6.5 cuadros por segundo. La 40D estará disponible en Estados Unidos a finales de septiembre, y se espera que esté disponible en México hacia finales de octubre.

SEP-OCT 2007

Verballs

Internet Phone No sólo lucen simpáticos y coloridos, sino que en realidad tienen un uso. Estos peculiares personajes son nada más y nada menos que un teléfono para hablar por Internet a través de Skype. Con los Verballs también se puede reproducir MP3, son compatibles con mensajeros instantáneos y software de telefonía. El micrófono manos libres y las bocinas están acústicamente aislados para eliminar el eco. Si se desea cuenta con entradas para audífonos para llamadas privadas. Es compatible con PC.

www.sg.com.mx

NEC

Multisync LCD205WXM y LCD225WXM Son dos nuevos monitores de la serie LCD Multisync 5 de 20 y 22 pulgadas de pantalla ancha. Están diseñados para cumplir con las necesidades de los usuarios más exigentes, y entre sus características principales están su base giratoria, tiempo de respuesta de cinco milisegundos, razón de alto contraste de 1000:1, resolución nativa de 1680 x 1050, ángulos de visión de hasta 176 grados y bocinas con resonancia inferior. Su bisel ultra delgado los hace perfectos para configuraciones de monitores múltiples.

Dell

Precision M4300 Nuestra más reciente ambición en cuanto a laptops se refiere, es la Mobile Workstation Dell Precision M4300. Podemos decir que esta es una computadora para usuarios cuya máxima prioridad es el desempeño. En su configuración más avanzada, la M4300 puede incluir procesador Intel Core 2 Duo T7700 a 2.4 GHz y 4 MB de cache L2), pantalla de 15.4’’ con resolución WUXGA+ (1920x1200), 4 GB de RAM a 667 Mhz, disco duro de 160 GB a 7200 RPM, y tarjeta de video NVIDIA Quadro FX 360M con 512 MB de memoria.

www.sg.com.mx

SEP-OCT 2007

www.sg.com.mx

INDEX

DIRECTORIO

TENEMOS UN ESPACIO RESERVADO PARA TI Si deseas anunciarte contáctanos en el (55) 5239 5502 o en ventas@softwareguru.com.mx

www.sg.com.mx

Anunciante

Páginas

Sitio

Avantare AMITI Creanimax CONCYTEG e-Quallity ENLi IBM Intel Itera Milestone Consulting Netec NYCE Roca Sistemas SafeNet SG’07 Sun Microsystems S&C TenStep

43 47 F3 13 37 55 46 11,35 33 F4 53 39 45 09 F2-1 07 31,51 49

www.avantare.com www.amiti.org.mx www.creanimax.com www.concyteg.gob.mx www.e-quallity.net www.enli.org.mx www.ibm.com/developerworks www.intel.com.mx www.itera.com.mx www.milestone.com.mx www.netec.com.mx www.nyce.com.mx www.rocasistemas.com.mx www.safenet-inc.com www.sg.com.mx/sg07 www.sun.com.mx www.syc.com.mx www.tenstep.com.mx

SEP-OCT 2007

// CARRERA

El Papel del Consultor de Procesos de TI Habilidades, experiencia y expectativas Por Axel Nissim

Derivado de las presiones del mercado por elevar la madurez y capacidad de las áreas de TI, así como la necesidad de generar valor real para el negocio, las organizaciones de TI cada vez se interesan más en adoptar modelos de calidad. Ante todo esto, llegamos a las inevitables preguntas: ¿Qué es lo que pasa con los proyectos de TI que los hace tan especiales, riesgosos, costosos, y proclives al fracaso total? ¿Qué es la calidad y la mejora de procesos? ¿CMMI o ITIL? ¿Cómo aumento la productividad de mi operación de TI? ¿Cómo se si estoy obteniendo lo que estoy pagando respecto a tecnología? Es ante estas preguntas que recurrimos al apoyo de un consultor (o una empresa consultora) de procesos y calidad de TI. El consultor de procesos y calidad es un individuo con vasto conocimiento teórico respecto a casi cualquier aspecto de la operación, administración, planificación y entrega de servicios de TI. Un consultor de procesos y calidad debe tener amplia experiencia en reingeniería de procesos, y dominar modelos como CMMI, ITIL, y Six Sigma. Además, estos individuos por lo general cuentan con amplia experiencia de primera mano en las trincheras de la operación de servicios de TI; muchos de ellos han recorrido el camino de programador, analista, líder de proyecto, gerente de proyectos, y en algunos casos incluso han sido directores. En resumen, los consultores a quienes nos referimos suelen ser enciclopedias andantes respecto a la manera de desarrollar y entregar productos y servicios de TI, así como una antología de anécdotas prácticas y maneras de resolver problemas en multitud de entornos.

¿Qué esperar del Consultor de Procesos y Calidad? Como tal, el consultor de Procesos y Calidad es una persona más, así que no debemos

esperar de él la ejecución de un milagro. A pesar de todo su bagaje tecnológico, y tal vez un poco a causa de el, los consultores de procesos y calidad también pueden ser muy proclives a equivocarse, tanto como todas las demás personas. Las palabras de un consultor de procesos y calidad deben ser interpretadas cuidadosamente, y sus recomendaciones deben ser ejecutadas solo cuando quede claro el beneficio que se espera obtener, y el costo de ejecutar la recomendación. Muchos consultores de procesos y calidad son percibidos como personas muy arrogantes, que siempre quieren tener la razón, o que son extremadamente teóricos. La verdad es que no es válido basar nuestra visión de estos consultores en un estereotipo. La principal aportación que hace un consultor de procesos y calidad, es, desde mi punto de vista, el poner en el radar de la compañía las mejores prácticas, y un camino probado para implementarlas. Es cierto que el consultor nos puede ahorrar meses y hasta años hombre de sumergirnos en los libros, modelos, estándares y prácticas de tecnología, pero más que esto, su principal valor consiste en haber vivido en carne propia estos, y no solo saberlos recitar de memoria. El consultor es necesario porque promueve la transferencia de conocimientos a través de las barreras entre empresas. Gracias a su experiencia diversa, aporta puntos de vista basados en problemas reales que ya han sido resueltos en el pasado, para que nosotros no tengamos que reinventar la rueda (un mal muy común en la industria de TI). El consultor de procesos y calidad es un individuo capaz de comunicar las cosas simples y las complicadas a nivel de los ejecutivos más altos, y a la vez de comunicarlo al becario que acaba de entrar a la empresa. Un consultor de procesos y calidad es ante todo un mentor, una persona capaz de relacionarse con otros para llevarlos por un

camino, si es necesario enseñándoles cómo caminar, pero más comúnmente sólo corrigiendo la dirección y dejando que el cliente llegue a sus propias preguntas y conclusiones, y haga las cosas como mejor le convenga, siempre respaldado por un marco teórico sustentable. ¿Pero cómo? ¿El consultor no está aquí para darme la pistola y balas de plata que resuelvan mis problemas? No, el consultor está aquí para enseñarnos a hacer las preguntas apropiadas a la situación, y para guiarnos en nuestro proceso de encontrar las respuestas óptimas. El consultor cuestiona todo el tiempo, y nos enseña a nosotros mismos a cuestionar, siempre constructivamente. El consultor nos podrá adelantar un poco con su experiencia y conocimientos teóricos, pero la verdad es que ninguna solución de mejora de procesos es exitosa si no se implementa por y para la gente misma que ejecutará los procesos.

Conclusión Para todos aquellos interesados en unirse al gremio, les puedo decir que en conjunto, la profesión de Consultor de Calidad puede ser muy gratificante para cierto tipo de individuos, otorgando gran proyección a futuro y conocimientos extensos acerca de todas las áreas de una empresa o de un departamento de tecnología, a un nivel mucho más profundo que la implementación de soluciones específicas. Aunque es un trabajo asociado a la tecnología, no es del todo tecnológico, e implica una oportunidad para el desarrollo de habilidades interpersonales, pensamiento analítico y deductivo y cuestiones de planeación estratégica que difícilmente se encuentran dentro de otros trabajos relacionados a la tecnología.

Axel Nissim Sánchez es Consultor de Calidad de Tata Consultancy Services. Actualmente trabaja llevando a un cliente a nivel 5 de CMMI. Anteriormente, se desempeñó como Director General de Entrempresarios.com y como investigador y desarrollador de software en Francia.

SEP-OCT 2007