SG17 (Septiembre-Octubre 2007)

SEP-OCT 2007 www.sg.com.mx

Dirección EditorialPedro Galván

Dirección de OperacionesMara Ruvalcaba

Arte y DiseñoDavid GutiérrezOscar 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.

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

Ilustración www.tollhaus.com.mx

Ventas Claudia Perea

Natalia Sánchez

Marketing y RPDafne Vidal

Circulación y Suscripciones Daniel López

AdministraciónAraceli Torres

[email protected]

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

directorio

Al pensar en sistemas de software, muy probablemente nos venga a la mente la idea de una aplicación en una arquitectu-ra multicapa, con su base de datos normali-zada, sus objetos de negocio con servicios bien definidos, y su capa de presentación a la última moda usando Ajax o WPF. Perfec-to, 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 nues-tro 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 canti-dad de dispositivos y sistemas que usamos a diario, que podrían ser mejorados a tra-vé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. Sim-plemente queremos invitarlos a darse cuenta de que el software de mañana es el software embedded. Así que si no quere-

mos quedar relegados, debemos empezar a ver cómo le vamos a entrar.

La recta finalConforme 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 cuen-ten contigo esos días.• Tomarte tus vitaminas para que tengas mu-cha energía y aproveches cada segundo.• Hacer una lista de lo que le quieres pregun-tar a los speakers cuando hables con ellos.• Ponerte de acuerdo con tus cuates que también van a ir.

AMCISQueremos 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 errataEn la edición Julio-Agosto 2007 de SG, al final de la página 35 debería decir: “… in-crementar el volumen de producción”.

— Equipo Editorial

Editorial

// CONTENIDO

02

SEP-OCT 2007www.sg.com.mx

Columnas

Tejiendo Nuestra Red 06por Hanna Oktaba

Mejora Continua 08por Luis Cuellar

Tendencias en Software 42por Luis Daniel Soto

Columna Invitada 44 por Crescencio Villaseñor

EntrevistasOrlando Rincón,Miguel Serrano,Gavin King.

14

Productos

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

Prácticas

REQUERIMIENTOS 28Obtención de RequerimientosCésar Guerra explica en detalle las diferentes técnicas existentes para obtener los requerimientos de un sistema de software.

PROGRAMACIÓN 32Expresiones RegularesRevisamos minuciosamente la sintáxis de las expresiones regulares paar que por fin te decidas a perderles el miedo.

GESTIÓN DE RECURSOS 36Tips para Reclutar DesarrolladoresEn 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 40Inclusión y Extensión de Casos de UsoUno 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.

EN PORTADA

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

18contenido sep-oct 2007

03

// CONTENIDO

En Cada Número

NOTICIAS y EVENTOS 04 FUNDAMENTOS 48

INFRAESTRUCTURA 50 CARRERA 56


// NOTICIAS

04

CIISA 2007Con 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, contan-do con reconocidos ponentes como Ken Van Wyk, del Software Engineering Institute, y Pamela Perrott, de Construx Software.

3ra Cumbre de Gobierno y Tecnología IDCEl pasado 27 de agosto, en la Ciudad de México, se reali-zó 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 proveedo-ras 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 de-creto de austeridad en las áreas de sistemas.

Oracle presenta Oracle Database 11gOracle presentó en la Ciudad de México, la más reciente versión de su base de datos Oracle® Database 11g. “Ora-cle 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 ca-racterísticas más innovadoras de Oracle Database 11g po-demos mencionar: la manipulación de datos XML de forma nativa, la habilidad para realizar pruebas y gestionar cam-bios 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.


// EVENTOS

05

6 de Septiembre 20072do. Seminario Mejores Prácticas y Tecnologías de Vanguardia para la Dirección de ProyectosMPA y PMI capítulo MéxicoTecnológico de Monterrey, Campus Ciudad de MéxicoInfo: www.mympa.org/Chapters/MexicoCity e-mail: [email protected]

11 de Septiembre 2007 IDC Innovation Forum Centro Banamex, Cd. de MéxicoInfo: www.idc-eventos.com/innovation07/ e-mail: [email protected]

12 al 14 de Septiembre 2007XXXI Reunión Nacional CIAPEM Veracruz 07 Comité de Informática de la Administración Pública Estatal y MunicipalWTC, Boca del Río, VeracruzInfo: www.ciapem.veracruz.gob.mx

19 al 21 de Septiembre 2007Gartner 10th Annual Conference: The Future of IT 2007 Centro Banamex, Cd. de MéxicoInfo: www.gartner.com/mx/econite-mail: [email protected]

20 al 22 de Octubre 2007DigIT 2007 - Congreso Internacional de TITecnológico de Monterrey, Campus PueblaInfo: www.saties.com e-mail: [email protected]

25 de Septiembre 2007Encuentro Internacional de Computación 2007 Morelia, Michoacán Info: enc.smcc.org.mx

4 al 6 de Octubre 2007 IX Congreso Internacional de Sistemas Computacionales Tecnológico de Monterrey, Campus Guadalajara Info: www.congresoisc.come-mail: [email protected]

4 al 7 de Octubre 2007Creanimax 2007 Festival deAnimación y VideojuegosCANIETI, IJALTI Expo Guadalajara, Guadalajara, Jalisco Info: www.creanimax.com

8 y 9 de Octubre 20072° Foro de Desarrollo y Pruebas de Software del Estado de GuanajuatoPoliforum León, GuanajuatoInfo: www.concyteg.gob.mx

10 de Octubre 2007 Congreso AMITI 2007: México ReinventadoCentro Banamex, Cd. de México Info: www.congresoamiti.com/

18 al 20 de Octubre 2007 ENLi 2007 Encuentro Nacional de Linux y Software LibreBenemérita Universidad Autónoma de Puebla (BUAP), Puebla Info: www.enli.org.mx

24 y 25 de Octubre 2007 Cutter Summit 2007 Hotel JW Marriott, Cd. de MéxicoInfo: www.cutter.com.mx/summit07/2007 e-mail: [email protected]

24 al 26 de Octubre 2007 XX Congreso Nacional y VI Congreso Internacional de Informática y Computación - ANIEI 2007 Universidad Autónoma de Chihuahua, Chihuahua, MéxicoInfo: www.aniei.org.mx e-mail: [email protected]

29 al 31 de Octubre 2007 SG’07 Conferencia y Expo SG Software GuruHotel Sheraton Centro Histórico, Cd. de México Info: www.sg.com.mx/sg07 e-mail: [email protected]

Empresas recientemente evaluadas en CMMI:Empresa Evaluación Fecha Apoyado por Lead Appraiser IIDEA Solutions CMMI 3 abril 2007 Innevo Jorge Boria, Livewareilinium CMMI 2 agosto 2007 Innevo Jorge Boria, Liveware


/*TEJIENDO NUESTRA RED*/

06

En junio de 2007, los que fuimos socios fundadores tomamos la do-lorosa decisión de cerrar la AMCIS. La Asociación Mexicana para

la Calidad en la Ingeniería de Software nació de una inquietud y en-tusiasmo de varias personas. El objetivo que nos movía era aprender juntos y compartir el conocimiento y las experiencias.

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

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 eferves-cencia de la incipiente industria de hardware y software y de la visión del ITESO para vincularse con ella.

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

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

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 con-tamos con la colaboración de AMITI para invitar a Suz García del Soft-ware 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 mexi-canas de la calidad como Arnoldo Díaz de Certum. Uno de los semina-rios fue dedicado completamente a pruebas de software y el último en 2003 anunciaba por igual el nacimiento de CMMI que de MoProSoft.

El éxito de los primeros seminarios y de las reuniones mensuales fue tal que no nos quedaba de otra sino constituirnos como una asocia-ció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 maes-trí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 tar-de-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 tra-bajos de tesis de maestría. Empezamos a tener una lista de correos de los interesados que crecía de manera impresionante.

Durante el año 2002 Teresa Márquez, una alumna de doctorado de Cien-cias Sociales, nos investigó como caso de estudio de una red de transfe-rencia 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.

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, Tecnolo-gí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.

// COLUMNA// COLUMNA


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

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ía-mos 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 in-dustria 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 debe-mos ofrecer desde la academia. La retroalimentación mutua es la clave para que ambos sectores crezcan y cumplan con su papel en la socie-dad. Otro logro muy importante para mi es tener este espacio en Soft-ware Gurú que sin la AMCIS difícilmente me lo hubieran ofrecido.

—Hanna Oktaba

SEP-OCT 2007 www.sg.com.mx08

Como 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 Mon-terrey 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 argu-mento las múltiples noticias en la televisión sobre plagas de ra-tas, fraudes con comida para perros, juguetes asesinos y demás. Debo confesar que escuchando de estos asuntos y habiendo es-tado 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 tra-tando 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 habitan-tes, llena de rascacielos y edificios modernos. Es sumamente cos-mopolita y se puede ver en las calles a personas de todas las nacio-nalidades, 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 reco-nozca 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.

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. Tecnología y trabajo en equipoY ya que hablamos de Enrique Canales, viene a colación una de sus frases que más admiro:

“La tecnología no tiene nada que ver con los mejores sistemas, ni las he-rramientas 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 per-sonal: ¿Qué sabes hacer que nadie más sabe hacer?, ¿Puedes re-petir 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é preocupa-da por estas preguntas.

El problema es que aunque todos nosotros nos hagamos esta pre-gunta y logremos diferenciarnos, en un mundo global ya no es sufi-ciente. 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 tec-nología a un nivel más alto, entonces nos preguntamos: ¿Qué sabe-mos 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!!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 for-ma 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?, ¿Quere-mos competir?, ¿Seguiremos el ejemplo que China está poniendo o nos sentaremos a verlos pasar? La carrera ya inició. ¡A correr!

—Luis R. Cuellar

/*MEJORA CONTINUA*/

Pésame por un MentorA 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.

// COLUMNA// COLUMNA


/* LO QUE VIENE*/// PRODUCTOS

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 de-sarrollo 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 Perfor-mance 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.0Contract-First, Document-Driven Web Services

Interface21, la empresa creadora del popular fra-mework 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 (contract-first) 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.

WebLogic Server Virtual EditionMira 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 aplicacio-nes, 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 virtuali-zació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 Ser-ver Virtual Edition agregue soporte para Xen a finales del 2007 y para Virtual PC en el 2008.

OpenProjAhora tus Gantts Serán Libres

A los administradores de proyecto les dará mu-cho gusto saber que ahora cuentan con una op-ció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 histo-gramas 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 archi-vos de MS Project y Primavera.

Hemos descargado la versión más reciente de OpenProj (beta 3) y consideramos que la fun-cionalidad 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 expe-riencia 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 pro-ducto interesante y con futuro.

Mayor información en www.openproj.org


/* HERRAMIENTAS*/// PRODUCTOS

SQLiteLa base de datos embebidaPor Filein Rómmel León

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. [email protected]

El uso de las bases de datos ya se ha exten-dido de los servidores hacia los dispositivos móviles. El desarrollo constante de la tecno-logía conjuntamente con los nuevos requeri-mientos de las empresas ha llevado a crear diversos métodos de almacenamiento de información en dispositivos móviles, embe-bidos y empotrados.

La demanda de bases de datos para dispo-sitivos móviles como PDAs y teléfonos ce-lulares 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í respon-der más rápidamente ante la competencia. Esta necesidad ha provocado que el almace-namiento de los datos en estos dispositivos haya mejorado tanto en capacidad como en herramientas. Gracias a esto, actualmente contamos con diversas opciones de maneja-dores 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 dis-positivos 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 imple-menta 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ási-cas 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 siste-mas de escritorio, sin necesidad de realizar procesos complejos de importación y expor-tación de datos, ya que existe compatibilidad al 100% entre las diversas plataformas dispo-nibles, haciendo que la portabilidad entre dis-positivos y plataformas sea transparente.

HistoriaSQLite 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ísticasEstas son algunas de las características prin-cipales 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 depen-dencias 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 SQLiteSQLite está construida en C, lo cual facilita la migración a diversas plataformas de siste-mas 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ónde SQLiteGracias a que SQLite es software libre, es posible encontrar una gran cantidad de com-ponentes, 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 mo-dernos como Java, Perl, Python, PHP, Ruby, C#, lenguajes más antiguos como Pascal, SmallTalk, Clipper, o lenguajes poco cono-cidos como Suneido, REXX, S-Lang, para to-dos 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 SQLiteLas características y plataformas previamente mencionadas hacen de SQLite una excelente opción en diversos casos tales como:• Cuando se requiere una base de datos integrada dentro de una aplicación. SQLite es una excelente opción por su facilidad de configuración. El inconveniente es que no escala a bases de datos demasiado grandes (en el orden de los terabytes).• Para realizar demostración de aplicaciones que utilizan un RDBMS (¿Para que utilizar un manejador de BD pesado que ocupa grandes recursos de sistema cuando solo se requiere hacer un demo de una aplicación?) • Como cache local de un manejador de base de datos empresarial. Esto acelera el tiempo de respuesta y reduce la carga sobre la base de datos central.


• Para aplicaciones en dispositivos móviles que manejan una BD local que se sincroniza por batch con una base de datos remota.• Almacenamiento persistente de objetos, configuraciones y preferencias de usuario. Permite fácilmente crear una estructura para almacenar configuraciones de la aplicación.

¿Y en México?Actualmente podemos citar diversas aplicacio-nes que ya se han desarrollado para el merca-do móvil en México. Por ejemplo en el estado de Veracruz en la zona cañera de Lerdo de Te-jada, al sur del estado veracruzano, algunos ingenios ya cuentan con un sistema de captura de datos móvil el cuál usa SQLite para capturar en terminales móviles la información en sitio, y posteriormente a través de GPRS se envía la

información a la base central del ingenio. Esta base central utiliza un motor propietario, pero gracias a la interoperatibilidad de SQLite es posible manejar la misma estructura de datos en la Terminal móvil con SQLite, que en la base de datos central con el motor propietario. Esta aplicación ha permitido a estos ingenios tener la información al instante desde las zonas ca-ñeras, lo que se ve reflejado en la calidad de la caña que se introduce al batey, ya que entre más fresca entre la caña al ingenio, más ren-dimiento 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 reco-lectada durante el día en zonas cañeras ubica-das 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 em-bebidos, 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

// ENTREVISTA

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 ins-trumento definitivo. Debido a mí deseo de trabajar fundamentalmen-te 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 fundamen-tal entre un ingeniero de sistemas y un antropólogo, son disciplinas complementarias para trabajar en sistemas y ecosistemas que pue-den 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 estu-vo 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 pro-yecto social que responde especialmente a esa visión de construir un espacio donde las nuevas generaciones puedan, a través de sus con-tactos 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 meca-nismos tradicionales que se han usado como resistencia popular.

¿Cómo se compara ParqueSoft con esfuerzos similares en otros países?A pesar de que tenemos el perfil de incubadora de empresas, no se-guimos 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 ecosis-tema 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 investi-gació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 in-cubadoras trabajan transversalmente con todas las generaciones, ParqueSoft tiene su foco en las nuevas generaciones que son final-mente un gran acelerador por sus capacidades de educación e inno-vació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 desarro-llo tenemos una gran oportunidad en esta industria. Nuestros ecosis-temas 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 construyen-do nuevos algoritmos, que se esté innovando sobre ellos y se produz-can eficiencias no con los métodos tradicionales sino con respuestas naturales. Por esto, pienso que toda América Latina es un gran eco-

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.

Orlando Rincón


Conoce a los Key Speakers de

sistema para la innovación, especialmente en torno a la algoritmia en la ingeniería de sistemas. Aquellos que logran educarse y logran con-seguir 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 perso-nas 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 platafor-mas culturales sobre las cuales se están construyendo los tejidos humanos, cada vez hacen menos interesante la ciencia y la tecnolo-gía para los niños y los jóvenes. Todos los gobiernos deben hacer es-fuerzos 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 edu-cación + el entretenimiento, que combinadas con TICs, pueden pro-ducir 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 tec-nología. Creo que en todos los países de América Latina debemos hacer enormes esfuerzos de invertir en esto, especialmente donde están las grandes concentraciones de nuestra población, que es en

los sectores populares. Esto ya está desarrollado, es muy fácil de implementar, requiere pocos esfuerzos y su impacto es muy grande. Por un parque de estos pueden pasar diariamente 5 mil, 6 mil niños para tener una población impactada al mes de ciento cincuenta mil a doscientos mil jóvenes que experimentan, trabajan y se entretienen con estos instrumentos de ciencia y tecnología y finalmente termi-nan 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 ha-ciendo. 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 In-geniería de Sistemas, las ciencias de la computación cada vez pene-tren 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 di-recto 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 infor-mació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 acele-ración en el desarrollo de América Latina.

15SEP-OCT 2007www.sg.com.mx

Fotografía cortesía de etakano.com

// ENTREVISTA

Miguel Serrano es uno de esos “gurús” en mejora de procesos de software. Fue el pri-mer 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. Mi-guel es investigador adjunto en el Centro de Investigación en Matemáticas (CIMAT) y diri-ge 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 in-vestigació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 cono-cimiento 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 estric-to con la calidad de las evaluaciones. Por lo

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 per-sona ha evaluado. La calidad de las evalua-ciones es un asunto serio que tenemos que cuidar en México y Latinoamérica.

¿Qué lecciones nos puedes compartir de la ex-perencia que has tenido en América Latina?Considero que en América Latina existe una percepción equivocada de que los proce-sos son principalmente para las empresas grandes. Sin embargo, a nivel mundial está demostrado que la mayoría de las organi-zaciones que los implementa no son gran-des 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 em-presas 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 ven-taja adicional de que ha sido adoptado por muchas organizaciones en el mundo, y por lo tanto es considerado como el estándar in-ternacional de facto. Asi que si tu enfoque es vender al extranjero, tal vez CMMI sea la me-jor opción. Aunque se ha manejado la idea de que CMMI solo es para empresas gran-des, 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 mun-dial de software. Como en todo, las empresas más competitivas, que producen con la me-jor calidad y mejor precio, son los ganadores para exportar y vender a nivel mundial. En el caso de México, al mismo tiempo que enfren-ta el reto de competir internacionalmente, también está el caso de empresas multina-cionales, líderes en la industria, que se están estableciendo aquí. Esto genera un gran reto de supervivencia para las organizaciones lo-cales, por lo que es imperativo que adopten tecnologías innovadoras, atraigan el mejor re-curso humano, y adopten las mejores prácti-cas y procesos respaldados por evaluaciones reconocidas internacionalmente.

Miguel Serrano

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 fac-tor 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 consulto-res 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.


¿Por qué nos deberíamos interesar en Seam?Hay dos cosas únicas sobre Seam. La primera es que es el único mo-delo 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 conver-tirá 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 es-tado 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 incor-porar 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 respec-to a tecnologías competidoras, especialmente cuando se trata del desarrollo de aplicaciones empresariales de gran escala. Los len-guajes 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

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 em-pieza 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 pa-rece 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 indus-tria. 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.

// ENTREVISTA

Gavin es posiblemente la persona con mayor liderazgo a nivel mundial en el área de Java empresarial. Saltó a la fama por desa-rrollar Hibernate, un framework open source para ORM (mapeo ob-jeto-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.

Gavi

n Ki

ng

SEP-OCT 2007www.sg.com.mx 17

18

>>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 completa-mente diferentes a los que la mayoría de los desarrollado-res 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 pre-ocupa por el mundo físico, y por lo tanto se enfoca en proble-mas 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.


19

El software del mundo f ísico

EmbeddedSoftware


El software es un elemento indispensa-ble en una muy amplia gama de dispo-sitivos que utilizamos continuamente

para nuestra vida diaria. Ya sea en la comodi-dad 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 soft-ware, 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 ca-sos, van más allá con aplicaciones para en-tretenimiento y seguridad. Lo mismo sucede con electrodomésticos, teléfonos, aviones, máquinas automáticas de venta, cajeros au-tomáticos, y edificios inteligentes.

Hay varias definiciones de embedded soft-ware. Las más tradicionales lo definen como “procesamiento de información que está inte-grado 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 pri-mera definición es relevante para entender los retos a los que se enfrenta el desarrollador de software embedded, y la segunda para enten-der 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 com-puesta de 26% (los proyectos se vuelven cada vez más complejos) y el número de desarrolladores especializados en em-bedded 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 ace-lerada que la industria en su conjunto.

Múltiples jugadores participan en el merca-do embedded de software. Microsoft (Win-dows CE, Windows XP Embedded), Wind River (VxWorks, Linux), Symbian (Symbia-nOS), Palm, y Green Hills (INTEGRITY) desa-

rrollan sistemas operativos y herramientas de desarrollo con capacidades embedded. Cada proveedor sigue enfoques diferentes depen-diendo de su experiencia y posicionamien-to 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 herramien-tas 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 ca-lidad técnica en sus productos, atributos fun-damentales en el mundo embedded.

Atributos del Desarrollo EmbeddedEl desarrollo de embedded software presen-ta 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 desa-rrollo de software embedded son: confiabili-dad, 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, esperan-do 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ícu-los, los clientes desean obtener características como alto grado de reuso, mantenibilidad, y fle-xibilidad que históricamente no han sido prio-ridad en el desarrollo de software embedded. La posibilidad de combinar todos estos atribu-tos presenta dificultades de ingeniería de soft-ware 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.

TendenciasConforme el hardware en general continúa su inexorable mejora en la relación poder/pre-cio, empieza a ser posible utilizar cada vez más hardware de propósito general en lugar de hardware dedicado para una solución ver-tical específica. Cada vez son más los dispo-sitivos embedded que utilizan arquitecturas SoC (System-On-Chip) en lugar de circuitos integrados especializados. El uso de hard-ware de propósito general simplifica enorme-mente la portabilidad del software embedded entre diferentes dispositivos.

Los sistemas operativos embedded son com-pactos y altamente eficientes. Por lo mismo en algunos casos no ofrecen al desarrollador mu-chas de las facilidades que sí se encuentran en sistemas de escritorio. Conforme los usuarios demandan más funcionalidad en sus disposi-

Embedded SoftwareEstado Actual y Tendencias

Por Héctor Obregón

Fig 1. Retos para el Desarrollo de Software Embedded.

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

Confiabilidad

Recursos deHardwareLimitados

Tiempo RealRespuesta en

Las fallas no pueden ser resueltas con ayuda del usuario

Las expectativas de los usuarios son más altas

Memoria limitadaEnergía limitada, bajo consumo de energíaFuentes de energía alternativa inestables (celdas solares,movimiento)

Las operaciones del software deben ejecutarse en periodos exactos

Las operaciones del software deben ejecutarse en periodos limitados(soft real time)

(hard real time)

Las consecuencias de una falla pueden ser muy graves, incluso lapérdida de vidas (control industrial, aeronáutica, automotriz)

(No Ctrl-Alt-Del)


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 desarro-llador elegir únicamente aquellas funciones que son necesarias para una solución específi-ca. 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 siste-mas embedded son de alto nivel. Éstos permi-ten a los desarrolladores ser más productivos y ofrecer más funcionalidad por hora/hombre trabajada. En las fronteras del desarrollo em-bedded, como el desarrollo para teléfonos y PDAs de consumidor final (donde más se pare-ce al desarrollo de software para computadora personal) podemos encontrar ya ambientes virtuales de ejecución como el Microsoft .NET Micro Framework, Microsoft .NET Compact Fra-mework o el Java Platform Micro Edition. Estos ambientes facilitan enormemente el desarrollo de soluciones embedded para los desarrolla-dores que están acostumbrados al desarrollo tradicional. No obstante, para aplicaciones embedded donde se requiere un nivel de pre-cisión y control elevado, aún no son adecua-dos. Lo que es particularmente cierto para las llamadas aplicaciones de tiempo real.

En muchas aplicaciones embedded se pre-senta el concepto de ejecución en tiempo real. Por ejemplo: en un motor de auto fun-cionando a 6 mil revoluciones por minuto, el cigüeñal da una vuelta en exactamente 10 milisegundos. Una computadora de adminis-tració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.

Para poder enfrentar estos requerimientos necesitamos un sistema operativo de tiem-po 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.

Construir una aplicación con requerimientos de tiempo real duro que además sea reusable, por-table 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 ten-dencias involucradas en el desarrollo de soft-ware 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 > Siste-mas operativos modulares

Todas estas tendencias que hemos consi-derado para el desarrollo de software em-bedded tienen el mismo objetivo: aumentar la productividad de los desarrolladores de software embedded manteniendo a salvo los atributos fundamentales que han dife-renciado 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.

Característica “Duro” “Suave”

Tiempo de respuesta Requerido Deseado

Desempeño bajo Predecible Degradadocarga pico

Control del ritmo Ambiente Computadora

Redundancia Activa Punto de verificación

Detección de errores Autónoma Asistida por usuario

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”. Salz-burg: Universität Salzburg.• Venture Development Corporation. (2004). “Embedded Software Trends”.

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

terminate

time

release

logicalview

physicalview

Logical Execution Time (LET)

task invocation

running running



ZigbeeComunicación para Dispositivos

Por Christian P. García

22


En los últimos años el uso de computado-ras 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 en-cuentran en televisores, equipos de sonido, la-vadoras, 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 directa-mente la demanda de desarrollo de software. Surgen nuevas aplicaciones, nuevas necesida-des y con ello nuevas oportunidades de desa-rrollo. 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 pro-puestas para resolver el problema de comuni-cación inalámbrica en este tipo de redes, entre ellas se encuentra Zigbee, misma que presen-taremos a continuación. Desde su arquitectura hasta su aplicación. Abordando temas como ahorro de energía, interoperabilidad, interco-nectividad, seguridad, implementaciones exis-tentes en el mercado y áreas de oportunidad.

¿Qué es Zigbee y Quién lo Promueve?La alianza Zigbee es un ecosistema internacio-nal 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 per-mita 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 habili-tará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ámbri-cas basado en el estándar para redes inalámbri-cas de área personal (WPANs) IEEE 802.15.4.

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

(Europa) y 915 MHz (EEUU). Tiene una velo-cidad 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 desem-peñ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 des-empeñ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 im-porta. El mismo Bluetooth que se compara constantemente con Zigbee tiene diferentes capacidades en cuanto a velocidad de trans-misió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 co-municación, ya que entre más nodos existan dentro una red, mayor número de rutas alter-nas 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órica-mente pueden existir hasta 16,000~ diferen-tes 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 ran-go de transmisión, siempre y cuando existan otros nodos intermedios que los interconec-ten. Esta propiedad incrementa significativa-mente 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 ac-tuar como “centro de confianza” al almacenar y administrar las llaves de seguridad. Sola-mente puede haber un coordinador por red. • Ruteador: además de ejecutar alguna fun-ció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.

Figura 1. Tecnologías inalámbricas.

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

23

-Acceso

-Seguridad-Ventilación

-Seguridad-Ventilación

-Iluminación

-Monitoreo

-Monitoreode pacientes

corporal

-Rastreo de equipo-Control de procesos

-Manejo de energía

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

-Medicióninteligente-Control de

consumo

-Puntos de venta-Servicios de redalternativos

AUTOMATIZACIÓN

TELECOMUNI-CACIONES

MEDICIÓNAUTOMATIZADA

AUTOMATIZACIÓN

CONTROL

CUIDADO DE

PERSONAL

INDUSTRIAL

DEL HOGAR

COMERCIAL DEEDIFICIOS

SALUD 0:48´34

ZigBeeControl inalámbrico quesimplemente funciona

24

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

ArquitecturaZigbee es una pila (stack) de protocolos, que semejante al modelo de referencia OSI está constituido por diferentes capas indepen-dientes una de otra, y cada una de ellas cum-ple funciones especificas. La figura 2 ilustra las diferentes capas que conforman la pila.

• La capa de más bajo nivel es la capa físi-ca, que en conjunto con la capa de acceso al medio, brindan los servicios de transmi-sión de datos por el aire, punto a punto. Estas dos capas están descritas por el es-tá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 di-rigidos a otros nodos en la red (el algorit-mo 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 recibi-dos, cifrarlos y autentificarlos. • La siguiente capa es la de soporte a la aplicación que es la responsable de mante-ner 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.

Cada capa se comunica con sus capas sub-yacentes 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 ta-reas especificas: el módulo de seguridad que es quien provee los servicios para cifrar y autentifi-car los paquetes, y el módulo de administración del dispositivo Zigbee, que es quien se encarga de administrar los recursos de red del dispositi-vo local, además de proporcionar a la aplicación funciones de administración remota de la red.

Áreas de Aplicación El mercado para las redes Zigbee compren-de una amplia variedad de aplicaciones que sería imposible enumerar en unos cuantos párrafos. Cada vez que platico con alguien

sobre este tema terminamos la conversación con un nuevo escenario de aplicación, algu-nos 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 produc-tos 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 cuan-tos bytes esporádicamente, que es el caso de una aplicación para automatizar el hogar. Al usar esta tecnología no tendrías que ca-blear 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.

Otra de las aplicaciones que ha tomado fuer-za, es la de los sistemas de medición avanza-da, medidores de agua, luz y gas que forman

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 in-teractuar 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 importan-te respaldo para la gestión energética y para las soluciones de consumo eficiente por par-te 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 identifi-cació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 al-gunas de las múltiples aplicaciones que se le pueden dar a las redes en cuestión.

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

Video

Monitoreo& Control

Datos

Voz

Bluetooth TM

TM

Red Celular

ZigBee

UWB

2.5G/3G

802.11 a

802.11 g

802.11 lb

Wi-FiIrDA

Más lejosMás cerca Rango de cobertura

Más

lent

oTr

asnf

eren

cia

de

dat

os

Más

ráp

ido

Transferenciade Datos

RedesInalámbricasde sensores y

control

AplicacionesInalámbricas

de Datos

AplicacionesInalámbricas

de Video

OEM

ZigBee

IEEE

APLICACIONES/PERFILES

CAPA DE RED

CAPA FISICA

CAPA DE ACCESO AL MEDIO

CAPA DE SOPORTEA LA APLICACIÓN

Aplicación

ZigBee

Silicio

Figura 3. Áreas deaplicación de Zigbee.

Figura 2. Pila de protocolos Zigbee.


Los sistemas embedded se encargan de hacer una tarea específica diseñando tanto el hardware como el software para ese fin, del que difícilmente se puede modificar su com-portamiento. 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 actua-dores. 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 CELas 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 op-erativos 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.

TutorialHabiendo 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 integra-das 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, espe-cialmente 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 almace-namiento 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.

ConociendoWindows CE

Tutorial Para Iniciar un Programa de Forma AutomáticaPor Carlos Maya


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 IniciarProgra-ma.cpp que fue generado automáticamente y que debemos editar para que haga lo que nosotros deseamos. En este caso, alimente-mos el código del listado 1 en nuestro archivo cpp.


Para arrancar el programa que acabamos de agregar, abrimos la carpe-ta 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 eje-cutar el programa aplicativo de forma automática. Entonces construi-mos el proyecto agregado a la imagen y lo cargamos a la plataforma en la que estamos probando. Debemos también tener el programa aplica-tivo cargado ya en el dispositivo de almacenamiento. En la figura 4 se muestra la pantalla de inicio de la imagen donde al cargar se ejecuta el programa: IniciarPrograma.exe desde la imagen, y espera unos segundos a que se carguen los dispositivos de almacenamiento. Posteriormente ejecuta el programa aplicativo como se muestra en la figura 5.

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

#include “stdafx.h”

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

ConclusionesEn Windows CE se puede configurar nuestra aplicación según lo requiera, desde los módulos a utilizar, como del comportamien-to 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 conexio-nes 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 Stu-dio 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.

Figura 1. Agregando un proyecto a laimagen de CE.

Figura 2. Creando un proyecto WCE tipo consola.

Figura 3. Agregando llaves al registry. Figura 5. Pantalla de ejecución automática.Figura 4. Pantalla principal de Windows CE 6.0.

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



/* REQUERIMIENTOS*/// PRÁCTICAS

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 valida-ción de requisitos. Además, establece una actividad de gestión de requerimientos para manejar los cambios, mantenimiento y ras-treabilidad 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 RequerimientosExiste un gran número de técnicas para obtener requerimientos. A continuación describo las más utilizadas. Hay que aclarar que nin-guna de estas técnicas es suficiente por sí sola y que es recomen-dable 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 experien-cia por parte del analista. La entrevista se puede definir como un “in-tento 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 cuen-ta al realizar entrevistas:• Preparación. Es necesario documentarse e investigar la situa-ció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 directi-vos 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 simple-mente responder “si” o “no”.

Desarrollo Conjunto de Aplicaciones ( JAD ) Es una técnica que se utiliza para promover la cooperación y el trabajo en equipo entre usuarios y analistas. Consiste en realizar sesiones en las que participan usuarios expertos del dominio jun-to 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 preparar-las y hacerlas sino también en redactar un conjunto de requisitos coherente a partir de opiniones diferentes de los distintos entre-vistados. • 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 adquie-ren 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éto-dos 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 in-formado 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 discre-pancias entre los desarrolladores y los usuarios.

Obtención de RequerimientosTécnicas y Estrategia Por César Guerra

28


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 pro-totipos incrementa los costos en las etapas iniciales de un proyecto, pero esto se recupera en etapas posteriores gracias al mejor enten-dimiento de los requerimientos por parte de los desarrolladores. En algunos casos también se utiliza como un medio para formalizar la aceptación previa del cliente de los requisitos del proyecto.

Observación Por medio de esta técnica el analista obtiene información de pri-mera 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ác-tica. Los observadores experimentados saben qué buscar y cómo evaluar la relevancia de lo que observan. Estudio de documentación Varios tipos de documentación, como manuales y reportes, pue-den proporcionar al analista información valiosa con respecto a las organizaciones y a sus operaciones. La documentación difícil-mente refleja la forma en que realmente se desarrollan las activi-dades, o donde se encuentra el poder de la toma de decisiones. Sin embargo, puede ser de gran impotancia para introducir al analista al dominio de operación y el vocabulario que utiliza.

Cuestionarios El uso de cuestionarios permite a los analistas reunir informa-ció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 am-plia distribución asegura el anonimato de los encuestados, situa-ció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 encuesta-dos llenar el cuestionario. Es recomendable conseguir apoyo de

la alta dirección para solicitar a las personas de la organización que contesten el cuestionario.

Al igual que con las entrevistas, se debe seleccionar a los encues-tados. 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 propues-ta. Esta técnica se puede utilizar para identificar un primer con-junto de requisitos en aquellos casos donde no están muy claras las necesidades que hay que cubrir, o cuando se esta creando un sistema que habilitará un servicio nuevo para la organización.

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

Puntos de Vista Cualquier sistema de software no trivial debe satisfacer las nece-sidades 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 requeri-mientos que tengan conflicto entre sí, o incluso se contradigan.

Los métodos orientados a puntos de vista (viewpoints) toman en consideración estas perspectivas diferentes y las utilizan para estructurar y organizar tanto el proceso de obtención, como los requerimientos mismos. Uno de estos métodos es el método VORD (Definición de Requerimientos Orientado a Puntos de Vis-ta), el cual provee un marco de trabajo orientado para la obten-ció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 re-ciben 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

“Un sistema no tiene éxito si no se ajusta a los factores sociales y

organizaciones que rigen a la empresa”.


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 des-cripció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 informa-ció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 inte-racción distinto, o la selección de un servicio del sistema, se docu-mentan 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 proporciona-dos 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 mo-delos 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 siste-mas 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 utili-zará. 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 espe-cialmente efectiva para descubrir dos tipos de requerimientos:1. Los requerimientos que se derivan de la forma en la que la gen-te trabaja realmente más que de la forma en la que las definicio-nes de los procesos establecen que debería trabajar. 2. Los requerimientos que se derivan de la cooperación y conoci-miento de las actividades de la gente.

Los estudios etnográficos pueden revelar los detalles de los pro-cesos 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 requerimien-tos 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 obten-ció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 desper-dicio 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-

/* REQUERIMIENTOS*/// PRÁCTICAS

“Los estudios etnográficos pueden revelar los detalles de los

procesos críticos”.

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. [email protected]


tearán preguntas. Tan sólo se observará y se tomarán notas o dibujos. Conviene ase-gurarse 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 limita-ciones. 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 reco-gido 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, Obser-vación y orientados a Puntos de Vista.

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

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

ConclusiónEl 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.


/* PROGRAMACIÓN*/// PRÁCTICAS

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

Si es la primera vez que te acercas al concepto de expresiones regu-lares –también conocidas como “regex” en el argot de la programa-ció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:

am // este es nuestro patrón. Si lo comparamos con: am // coincide ambicion // coincide campamento // coincide mano // 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 litera-les, 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 lengua-jes 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 ca-dena de texto que tenga una estructura conocida.

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

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 diferen-tes condiciones tales como agrupaciones, alternativas, comodines, multiplicadores, etcétera.

Los metacaracteres más usados son: . * ? + [ ] ( ) { } ^ $ | \.

A continuación los explicamos de forma detallada.

Metacaracteres de posicionamiento, o anclasLos 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 caracte-res comparada. Cuando usamos el signo ‘$’ estamos indicando que el patrón debe aparecer al final del conjunto de caracte-res. O más precisamente, antes de un caracter de nueva línea.

Ejemplo:

De la misma forma, la expresión ^$ se puede utilizar para encon-trar líneas vacías, donde el inicio de una línea es inmediatamen-te seguido por el final de ésta.

Los metacaracteres ‘^’ y ‘$’ también conocidos como anclas (an-chors) ya que no representan otros caracteres, sino posiciones en una cadena.

Escapando caracteresPuede 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 in-vertida \ convierte en normales a los caracteres especiales.

Ejemplo:

Expresiones RegularesConócelas y Piérdeles el MiedoPor Pedro Galván


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 caracteresLos 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 ñ. Po-drí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 cla-ses 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 ca-racter ^ 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:


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:

DelimitaciónLos paréntesis se pueden utilizar para definir un subconjunto dentro de una expresión. Por ejemplo, para capturar la parte correspondien-te 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 se-cuencia de caracteres “http://” y seguido de esto tengo una subex-presión, la cual estoy delimitando con los paréntesis, y aplico una ex-presión a este segmento en específico, en este caso estoy buscando una cadena que coincide con cualquier caracter excepto el ‘/’.

AlternativasEl 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 expre-sió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 coin-cide 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 po-demos terminar con expresiones difíciles de entender, y por lo tanto de mantener.

Cuantificadores o MultiplicadoresLos 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.

Estos metacaracteres se aplican al caracter (o agrupación) que les precede, e indican el número de veces que se puede encontrar di-cho 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 multiplici-dad de 1 a n. Los siguientes ejemplos dejan esto más claro:

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.

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

/* PROGRAMACIÓN*/// PRÁCTICAS

ConclusiónEn 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.

“A través de metacaracteres podemos definir diferentes condiciones tales

como agrupaciones, alternativas, co-modines, multiplicadores, etcétera”.

Una Multitud de InnovacionesNueva Generación de Laptops Basadas en Tecnología de Procesador Intel® Centrino®

// PUBLIRREPORTAJE

Ad

am S

avag

e y

Jam

ie H

ynem

an, d

el p

rogr

ama

de

tele

visi

ón M

ythb

uste

rs, c

omp

aran

una

com

put

ador

a p

orta

til d

e 19

71 c

on u

na la

pto

p m

oder

na c

on t

ecno

logí

a In

tel®

Cen

trin

o® D

uo.

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.

Procesadores másvelocesEn el corazón de las nuevas laptops se encuentra la generación más re-ciente 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 activi-dad, para lograr un menor consumo de energía.

Gráficos formidablesLa familia de chipsets Mobile Intel 965 Express es la arqui-tectura 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ápidaIntel® Next-Gen Wireless-N es la solución opcional para LANs inalámbri-cas 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 turbocargadoIntel® Turbo Memory es una característica opcional que mejora el des-empeñ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 negociosComo parte de esta nueva generación, se ha lanzado la nueva mar-ca Intel® Centrino® Pro, la cual está dirigida a usuarios de nego-cios, 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 adminis-tració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 acti-vidad de los sistemas.

PCs de escritorio más compactas, silenciosas y estilizadasVale la pena mencionar que Intel® también utilizará estos nuevos avan-ces en su tecnología móvil para incor-

porarlos en PCs de escritorio, de tal forma que se pue-dan desarrollar nuevos diseños de PCs de escritorio más compactos, silenciosos y de alto desempeño.

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)


/* GESTIÓN DE RECURSOS */// PRÁCTICAS

Tips para ReclutarDesarrolladoresRegla #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 des-cribir a nuestro equipo. Siempre me gustó la simplicidad de esa fra-se. 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 con-ciente de que la mayoría de los currículums que revisarás, son gen-te 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 so-lucionar infinidad de problemas: ¿Cómo debería funcionar este software? ¿Qué tecnologías debería utilizar? ¿Cuál sería una ar-quitectura 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 perso-nas 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 efec-tiva de inteligencia. Aun así, no conozco a nadie tonto que haya conseguido un doctorado del M.I.T.

¿Es curioso?¿A nuestro candidato le interesa entender como funcionan las co-sas? ¿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 resol-verlo. 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 desarro-llo de software): “… a veces las personas inteligentes y curiosas dedican tanto tiempo a analizar la mejor forma de atacar un pro-blema, 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 mu-chas personas que vienen de la academia y la investigación sue-len 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 his-toria de un candidato que no obtuvo un trabajo en una empresa de software. Sucede que el candidato estaba técnicamente ca-lificado, 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ámi-ca del equipo, se convertirá en un cáncer y terminará afectando negativamente el desempeño del equipo. Al evaluar a un candi-dato, debes preguntarte ¿Me gustaría trabajar con esta persona? ¿Le entusiasmará a él trabajar con nosotros? ¿Sus experiencias (tanto en el trabajo con en su vida personal) complementan las del resto del equipo?


¿Cuenta con la experiencia adecuada?Noten que estoy dejando para el último la pregunta de la experiencia. Es cierto que la experiencia es importante, pero creo que es sobrevaluada. Probablemente es el único criterio que una persona puede mejorar con el tiempo. En la organización donde laboro actualmente utilizamos Java 5, JBoss 4, y Maven 2. ¿Debería rechazar a un buen candida-to 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 traba-jo 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ículumEl 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 pro-yecto 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 per-sonas que han trabajado en una gran variedad de cosas. Las personas cuya experiencia esta centrada exclusivamente en una tecnología o plataforma, probablemente reprue-ban el criterio de la curiosidad.• ¿El candidato ha avanzado en su carrera? Las personas inteligentes que dan resulta-dos, no se quedan estancadas en una posición durante mucho tiempo.

Paso 2: La entrevista telefónicaSi el currículum de la persona es suficientemente interesante como para continuar, en-tonces 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 últi-mo proyecto?”, “¿Qué disfrutaste más de tu último proyecto?”, o “¿Qué quisieras haber hecho diferente en tu último proyecto?”. Los buenos candidatos acostumbran tener res-puestas interesantes a estas preguntas.


/* GESTIÓN DE RECURSOS */// PRÁCTICAS

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.

• 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 de-tectar zoquetes, y no el de tomar una decisión final. No pierdas de-masiado tiempo en esta llamada. Quince minutos debería ser tiempo suficiente detectar si esta persona es alguien con quien no te gusta-rí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 entre-vista, 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 ha-blar 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 habili-dad de trabajar con otros. De forma similar, un analista debería poder escribir requerimientos para un sistema ejemplo, y un pro-ject manager debería desarrollar un plan.

Las preguntas raras como “¿Cuántas gasolineras hay en la ciu-dad?” 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 pregun-ta capciosa, para que la persona no se distraiga tratando de en-contrar 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 con-testado si esta persona cumple los criterios o no.

Paso 4: La decisiónAl llegar el momento de tomar una decisión, las personas que en-trevistaron 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 defi-nitivamente 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 probable-mente 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, en-tonces 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-tech-nology-teams-rule-1-no-chumps y fue traducida y publicada por SG con el permiso del autor.

ConclusiónContratar 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).

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, laborato-rios, administración, centros de investigación, etc.) y aprobadas por un organismo reconocido. Tienen el carácter de acuerdos documen-tados y contienen las especificaciones técnicas o criterios precisos para ser usados consistentemente como reglas, guías, o definicio-nes de características, asegurando de esta forma que los materia-les, 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 simplifi-car y a incrementar la fiabilidad y eficiencia de los bienes y servicios que utilizamos, así como a mejorar el bienestar de la sociedad y re-dunda en el beneficio común. Las normas o estándares son, por tanto, documentos de aplicación voluntaria, elaborados por las partes inte-resadas, por consenso y aprobados por un organismo reconocido.

En el ámbito internacional, la ISO (Organización Internacional de Nor-malizació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 responsabili-dad 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 participa-ció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 traba-jo (GT) para cubrir temas específicos. • Subcomités (SC): tienen las mismas atribuciones que el TC y auto-nomí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 empren-didos 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 infor-mar sobre los progresos técnicos de un tema determinado, dar recomendaciones sobre la ejecución de un trabajo y facilitar infor-mació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 Telecomuni-caciones 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 institu-ciones 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 Tecnolo-gías de la Información.

Para mayor información, consulte:http://www.normalizacion-nyce.org.mx/php/loader.php?c=normas.php&page=11

// PUBLIRREPORTAJE

Conceptos básicos sobre los estándares de T.I.


// UML

INCLUSIÓN Y EXTENSIÓN DE CASOS DE USOLIDIANDO CON LA CONFUSIÓNPor Sergio Orozco y Lety Ortiz

Sergio Orozco es director general e instructor senior de Milestone Consulting. Lety Ortiz es instructora y consultora en la misma empresa. Ambos se especia-lizan en temas relacionados con UML. Milestone Consulting (UML Value Added Training Center), es una empresa especializada en capacitación práctica-inten-siva 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. [email protected] www.milestone.com.mx

Un tema que genera mucha polémica entre la gente que modela ca-sos 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 man-tener el modelo simple, incluso si esto significa utilizar menos elemen-tos 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 adentrar-nos en algunos pormenores del lenguaje unificado.

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 rela-ción de la que se trate: ya sea <<include>> o <<extend>>.

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

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 segun-do 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 pro-ceso 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”.

Figura 2. Ejemplo de Include

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


Figura 3. Ejemplo de Extend

Casos de AbusoUno de los riesgos que existe cuando la gente sabe que puede utili-zar 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 so-lamente causan confusión. Mucha gente, y sobre todo la que arras-tra 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.

Figura 4. Abuso de relaciones

Es importante comprender que el objetivo de estos tipos de relacio-nes 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 en-tendemos esto y somos congruentes, obtendremos un beneficio real para el proyecto; fin último del uso de UML.

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 comu-nicar 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 activi-dad, de estados, o simplemente un texto en una especificación.

Relaciones de Análisis o DiseñoOtra 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 navegabi-lidad entre funciones. Pensemos en cierta funcionalidad que co-rresponde 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 funcio-nalidad 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. Simple-mente 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 RetrabajoUna 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 5. Identificación de reuso

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 aprovechar-las adecuadamente, buscando el beneficio real que deberían de pro-porcionar 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.


En septiembre del año pasado, Forrester Research realizó una en-cuesta 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. Mu-chos productos empaquetados de distintas funcionalidades son parte de la misma “categoría”. Finalmente, las páginas personales se consi-deran 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 Inter-net 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 empre-sas Fortune adoptarán aspectos tecnológicos pero difícilmente replica-rá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: crea-ció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á imple-mentar 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 mode-los 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 em-presas, sino el salto directo a la etapa de “Software más servicios” o “Siguiente Web”, donde la combinación de software administrado in-ternamente y software como servicio se convierte en la norma. El ser-

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 desarro-lladores 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 olvide-mos 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, permi-tiendo organizar y visualizar los resultados de búsquedas múltiples.

—Luis Daniel Soto

El Impacto del Web 2.0 en la EmpresaLos Diferentes Escenarios

/*TENDENCIAS EN SW*/// COLUMNA

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


Las patentes de software pueden definirse como monopolios de 20 años que se conceden en algunas oficinas de patentes en el

mundo, sobre funcionalidades, algoritmos, representaciones y otras acciones que se pueden llevar a cabo con una computadora. En la jerga que se usa para las patentes, se suele sustituir dicho término por la expresión “invención implementada por computadora” que incluye tanto las polémicas patentes de software como las gene-ralmente 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 conceder-se a dichas patentes, si es que deben ser instituidas en absoluto:

• Los detractores de las patentes de software argumentan que cual-quier programa informático está compuesto de millones de compo-nentes (procedimientos, algoritmos,...) muchos de los cuales po-drí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 lle-gar 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 es-fuerzo 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 soft-ware 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 desigualda-des 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 des-de hace tiempo las patentes de software. Sin embargo, en Europa,

el Artículo 52 de la Convención de la Patente Europea excluye ex-presamente 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 inexis-tencia, 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 mo-mento, 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 creci-miento de todas es la de las patentes de software.

Legislación en MéxicoFinalmente, 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 progra-mas, documentación y bases de datos. Las responsabilidades del Registro son las de orientar a autores, y procurar resolver controver-sias 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 diferen-cia 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 progra-madores, 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 pa-tentes de software y se reglamenten de forma adecuada, el examen de fondo será más ágil y práctico, con la consecuencia del incremen-to de más patentes otorgadas en este campo.

Patentes de SoftwareConociendo la legislaciónPor Crescencio Villaseñor y Gloria Isla

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

// COLUMNA INVITADA

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 capacita-ció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, arqui-tectos, 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.

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 inter-cambio de ideas sobre tecnologías que están formando el futuro del mercado. Dentro del ecosistema de developerWorks, los desa-rrolladores colaboran abiertamente, crean aplicaciones innovado-ras y comprenden tecnologías avanzadas, como GRID Computing y Service-Oriented Architectures (SOA).

developerWorks es uno de los portales para desarrolladores pione-ros en el modelo Web 2.0 para participación y colaboración de la co-munidad. A través del uso de tecnologías como blogs, wikis, podca-ts, 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 necesa-rias para aprovechar las tecnologías Web 2.0 y entender como es que estas herramientas se pueden aplicar dentro de sus organizaciones.

Por donde comenzarPara 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.

developerWorksEl portal ideal para desarrolladores

// PUBLIRREPORTAJE

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


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 adi-cionales —describiendo el contenido, el sig-nificado 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 huma-nos”. 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án-tica, lo primero que tenemos que conocer es que existen diferentes niveles. La figura 1 ilustra los elementos de lo que se ha deno-minado el espectro semántico.

Figura 1. El espectro semántico

MetadatosEl primer nivel dentro del espectro semánti-co 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 infor-mació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 te-mas, 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íaEl siguiente nivel de semántica es la taxo-nomía, que es una jerarquización de la in-formació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ánti-ca 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 defini-ció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 conti-nente, y una sub-clasificación es México, que a su vez esta sub-clasificado por estados.

Figura 2. Ejemplo de una taxonomía

TesauroEl 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 te-sauros al ejemplo expuesto anteriormente.

Figura 3. Ejemplo del uso de tesauros

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

Espectro SemánticoUn primer acercamientoPor Víctor Lorenzana

// FUNDAMENTOS

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.


Modelo conceptualEl 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 conoci-miento 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 in-formación adicional sobre los conceptos de un dominio, y específicamente de las relacio-nes 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.

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

ConclusiónAunque 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.


// INFRAESTRUCTURA

Redes de Datos de SensoresMetodología para la Recolección, Administración y Presentación de DatosPor Paul Javier Manchego Revilla

// INFRAESTRUCTURA

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 interco-nexión y computación. Algunas redes, como las que monitorean el medio ambiente, consisten de muchos nodos que generan datos cada se-gundo haciendo el total de volumen de datos generados muy grande. Sin embargo para la mayoría de aplicaciones, las mediciones de sen-sores individuales son de menor importancia y los usuarios están generalmente más interesa-dos en extractos que combinan un conjunto de mediciones de datos de sensores en una esta-dística más simple y sólida. Es por ello que mu-chas 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 distribui-das. Las librerías digitales permiten a las orga-nizaciones cooperar en proyectos comunes, reuniendo su información en un portal de recur-sos 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 SensoresPara 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 “La-boratorio de Escuela Virtual” el cual tiene como objetivo primordial crear una federación de di-versas redes de sensores para permitir usar sus datos para propósitos educativos.

Federación es un modelo organizacional usado para agrupar socios independientes que es-tán de acuerdo en seguir ciertos estándares y practicas de negocio para cumplir un objetivo común. Este modelo organizacional se ha utili-zado 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 fe-deración. Las redes de sensores generalmente proporcionan registros con la fecha, hora y ubi-cació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 publi-car descripciones formales de las capacidades, ubicación e interfaces de los sensores asi como sus propias observaciones. Clientes y servido-res 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 DatosPasemos ahora a como podría operar un siste-ma de administración de datos de sensores fe-derado. En una federación con un número con-siderable 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 cen-tral permitiría que los datos de sensores estén siempre disponibles y asegura niveles acepta-bles de calidad de servicio para los consumido-res. Además, la federación no debe estar limi-tada 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 federa-ción, las nuevas fuentes de datos deben ser re-gistradas 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 prime-ro denominado “push” permite que bloques de datos sean enviados desde la fuente hasta el repositorio persistente. El segundo es denomi-nado “pull” y permite que mensajes de consulta especiales puedan ser enviados directamente a las fuentes de datos. Estos mensajes de con-sulta pueden estar limitados a simples tareas predefinidas tales como “obtener el estado ac-tual 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.


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 adap-tadores 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 compleji-dades 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óxi-do de carbono (CO) en el ambiente.

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

Figura 2. Ejemplo de una arquitectura

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.

Conclusión


/* GADGETS */// TECNOLOGÍA// TECNOLOGÍA

Canon

EOS 40DCanon dio a conocer el modelo 40D de su línea de cámaras digitales. Este modelo está dirigido a consumidores avanza-dos 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 proce-samiento de imá-genes. De hecho, soporta la toma continua (conti-nuous shooting) de hasta 75 foto-grafí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 ha-cia finales de octubre.

Yoggie

Pico PersonalYoggie es una empresa israelí que provee productos para seguridad informáti-

ca, 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 encar-garse 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 deci-

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

Verballs

Internet PhoneNo 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ófo-no 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.


/* GADGETS */// TECNOLOGÍA

Dell

Precision M4300Nuestra 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 pro-cesador Intel Core 2 Duo T7700 a 2.4 GHz y 4 MB de cache L2), pantalla de 15.4’’ con resolu-

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

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

NEC

Multisync LCD205WXM y LCD225WXM


INDEX

Anunciante Páginas Sitio

Avantare 43 www.avantare.comAMITI 47 www.amiti.org.mxCreanimax F3 www.creanimax.comCONCYTEG 13 www.concyteg.gob.mxe-Quallity 37 www.e-quallity.netENLi 55 www.enli.org.mxIBM 46 www.ibm.com/developerworksIntel 11,35 www.intel.com.mx Itera 33 www.itera.com.mxMilestone Consulting F4 www.milestone.com.mxNetec 53 www.netec.com.mxNYCE 39 www.nyce.com.mxRoca Sistemas 45 www.rocasistemas.com.mxSafeNet 09 www.safenet-inc.comSG’07 F2-1 www.sg.com.mx/sg07Sun Microsystems 07 www.sun.com.mxS&C 31,51 www.syc.com.mx TenStep 49 www.tenstep.com.mx

TENEMOS UN ESPACIO RESERVADO PARA TISi deseas anunciarte contáctanosen el (55) 5239 5502 o en [email protected]

DIRECTORIO

55

SEP-OCT 2007 www.sg.com.mx56 www.softwareguru.com.mx

Derivado de las presiones del mercado por elevar la madurez y capacidad de las áreas de TI, así como la necesidad de generar va-lor 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, cos-tosos, 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 ob-teniendo lo que estoy pagando respecto a tecnología?

Es ante estas preguntas que recurrimos al apoyo de un consultor (o una empresa con-sultora) de procesos y calidad de TI.

El consultor de procesos y calidad es un in-dividuo con vasto conocimiento teórico res-pecto a casi cualquier aspecto de la opera-ció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 mode-los 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 re-comendación. Muchos consultores de pro-cesos y calidad son percibidos como perso-nas muy arrogantes, que siempre quieren tener la razón, o que son extremadamente teóricos. La verdad es que no es válido ba-sar 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 hom-bre 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 no-sotros no tengamos que reinventar la rueda (un mal muy común en la industria de TI). El consultor de procesos y calidad es un indivi-duo 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 re-lacionarse con otros para llevarlos por un

camino, si es necesario enseñándoles cómo caminar, pero más comúnmente sólo corri-giendo la dirección y dejando que el cliente llegue a sus propias preguntas y conclusio-nes, y haga las cosas como mejor le conven-ga, 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 resuel-van 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 res-puestas óptimas. El consultor cuestiona todo el tiempo, y nos enseña a nosotros mismos a cuestionar, siempre constructi-vamente. El consultor nos podrá adelantar un poco con su experiencia y conocimien-tos 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 mis-ma que ejecutará los procesos.

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

// CARRERA

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.

ConclusiónPara 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 indi-viduos, 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 impli-ca una oportunidad para el desarro-llo de habilidades interpersonales, pensamiento analítico y deductivo y cuestiones de planeación estratégi-ca que difícilmente se encuentran dentro de otros trabajos relaciona-dos a la tecnología.

SG17 (Septiembre-Octubre 2007)

Documents

Transcript of SG17 (Septiembre-Octubre 2007)