SG26 (Noviembre 2009 - Enero 2010)

• Usabilidad en Redes Sociales • Programación Paralela • Gestión de Datos

Software Guru CONOCIMIENTO EN PRÁCTICA No.26 • Noviembre 2009-Enero 2010 • www.sg.com.mx

[ ESPECIAL ]

SG´09

Así se vivió [ ENTREVISTA ]

Per Kroll

Mejora de Procesos Inteligente

Model Driven Development La Evolución del Desarrollo de Software

México, $65.00

Noticias • Eventos • Carrera • Gadgets • Fundamentos • Infraestructura • Biblioteca

[ Herramientas ] Manymoon

SG Software Guru mucho más que una revista… conocimiento sg.com.mx difusión SGGuía consulta publicidad colaboración perfiles revista digital herramientas educación SG Campus espacio virtual especialización sgcampus.com.mx publicidad aplicaciones interacción capacitación Investigación estadísticas información actualización evaluación Eventos estrategia perfiles promoción evaluación organización

// CONTENIDO

directorio Dirección Editorial Pedro Galván Dirección de Operaciones Mara Ruvalcaba Coordinación Editorial Alejandro Escamilla

Editorial

Arte y Diseño Dafne Ortega, Oscar Samano Consejo Editorial Jorge Valdés - PMI; Luis Cuellar - Softtek; Luis D. Soto - Microsoft; Hanna Oktaba - UNAM; Ralf Eder, Raúl Trejo - ITESM; Emilio Osorio - Sistemas Humanos; Luis Vinicio León - e-Quallity, Gloria Quintanilla - Itera.

El desarrollo dirigido por modelos ha sido un tema recurrente en la industria durante la última década. Su popularidad ha tenido sus altos y bajos en estos años, pero es innegable que poco a poco ha ido evolucionando y cada vez suena menos descabellada la visión de generar aplicaciones ejecutables a partir de modelos. Compartimos con ustedes en este número una serie de artículos para ayudarlos a entender mejor este paradigma, y que puedan decidir que tan aplicable es a sus organizaciones y proyectos.

Un año más se nos ha ido, y con él SG cumple 5 años de publicación (¡sí, cinco!). Ha sido un recorrido con grandes logros y satisfacciones, que no han llegado sin su dosis de sudor y lágrimas. En el transcurso de estos años también hemos podido desarrollar con su apoyo varios proyectos como nuestro congreso anual, SG Guia y SG Campus, gracias a los cuales SG es ahora mucho más que una revista. Queremos aprovechar este momento para darle las gracias a todos los que han hecho esto posible: los lectores, colaboradores, clientes y staff de SG.

02

NOV-ENE 2010

En el afán de manternos vigentes tanto en nuestro contenido como en nuestro formato, hemos iniciado una serie de cambios que nos ayudarán a abrir más el desarrollo de contenidos. Como parte de ello, en los próximos meses estaremos reclutando voluntarios que nos apoyen en la generación, revisión y edición de artículos. Si estás interesado en colaborar, por favor escríbenos a editorial@sg.com.mx. Si deseas mantenerte al tanto de los contenidos que estamos desarrollando, sigue nuestra cuenta en twitter (@RevistaSG). También te informamos que puedes consultar en http://delicious.com/RevistaSG las ligas a los artículos en Internet que utilizamos como referencias para desarrollar los contenidos de SG. El 2010 pinta como un año con grandes retos y oportunidades. La única forma de salir adelante será mediante la colaboración; juntos podemos lograrlo. Les deseamos felices fiestas navideñas y un prospero 2010. » Equipo Editorial

Colaboradores Hector González, Fernando Labastida, Mike Armas, Ivar Jacobson, Javier Castañón Beatríz Rios, Luis Rodríguez, Luis Joyanes, Ricardo Rangel, Michael D’Mello, Victoria Gromova, Tom Mochal, Berenice Ruíz, Enrique Ledesma, José Luis Flores, Lourdes Sánchez, Cesar Guerra, Juan Pablo Bernabé.

Ventas Claudia Perea Marketing y RP Paulina Olivares Circulación y Administración Edgar Dorantes Desarrollo Web Nathanael Gutiérrez Contacto info@sg.com.mx +52 55 5239 5502 SG Software Guru es una publicación trimestral 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: En trámite. Certificado de licitud de título: 12999. Certificado de licitud de contenido:10572.

ISSN: 1870-0888. Registro Postal: PP15-5106. Se imprimió en noviembre de 2009 en Preprensa Digital.

Distribuido por Sepomex.

www.sg.com.mx

contenido nov - ene 2010

26

EN PORTADA MDD

26

Descubre en qué consiste el desarrollo dirigido por modelos.

Especial 20

Sg ‘09

Conoce los detalles sobre todo lo que sucedió en SG ‘09 Conferencia y Expo.

Productos LO QUE VIENE 14 Flash Platform Services, Google Go, Rational SDS for Cloud y Visual Studio.

Columnas Columna Invitada por Fernando Labastida

08

Prueba de Software por Luis Vinicio León

50

Tejiendo Nuestra Red por Hanna Oktaba

10

48

Mejora Continua por Luis Cuellar

12

Programar es un Modo de Vida por Gunnar Wolf

52

Tierra Libre por Emilio Osorio

47

Entregando Valor por Gloria Quintanilla Tendencias en Software por Luis Daniel Soto

54

Herramientas Manejo colaborativo de tareas usando Manymoon.

16

Prácticas Usabilidad Usabilidad en Redes Sociales

34

Compartimos los resultados del estudio hecho a la usabilidad de redes sociales y buscadores.

Gestión de Datos Combinación de Datos

38

Mostramos algunos ejemplos del uso avanzado de JOINs para combinar datos de distintas fuentes.

Programación 40 Algoritmos Paralelos Usando Plantillas

En Cada Número Noticias y Eventos

04

FUNDAMENTOS

60

CARRERA

56

GADGETS

62

24

La librería Thread Builiding Blocks nos facilita la migración de código serial hacia código paralelizable.

PM CORNER Manejo de Cambios de Alcance

46

Tom Mochal comparte tips y para manejar de forma adecuada los cambios de alcance en un proyecto.

Entrevista Per Kroll

www.sg.com.mx

NOV-ENE 2010

03

// NOTICIAS

XXX Convención Nacional Anual CANIETI En medio de un ambiente de diálogo y colaboración se llevó a cabo del 15 al 18 de octubre la XXX Convención Nacional Anual de CANIETI, contando con la participación de representantes de industria y gobierno, quienes tuvieron la mejor disponibilidad para lograr el objetivo de unificar esfuerzos por el desarrollo y crecimiento de las TIC´s. Entre los conferencistas destacó la presencia del titular de la SCT, Juan Molinar Horcasitas, quien más allá de querer tapar el rezago que tenemos en telecomunicaciones, se mostró consciente del problema y pidió la colaboración de la industria. Destacó el panel con los senadores Yeidckol Polevnsky, Federico Döring y Francisco Javier Castellón, quienes reconocieron la incongruencia de los impuestos a telecomunicaciones y la necesidad de aprovechar el espectro inalámbrico que ofrece CFE.

X Encuentro Iberoamericano de Ciudades Digitales La ciudad de Veracruz recibió a los participantes del X Encuentro Iberoamericano de Ciudades Digitales, efectuado el 21 y 22 de octubre, bajo la temática “Los gobiernos locales como factor clave del desarrollo socioeconómico: la oportunidad del uso de las TICs”, mismas que se han constituido como un importante canal de vinculación entre el gobierno y la ciudadanía. México fue distinguido como sede de este encuentro, organizado en conjunto con la AHCIET, organismo que integra a empresas de telecomunicaciones en América Latina y España. En dicho marco fueron entregados los Premios Iberoamericanos que reconocen prácticas de buen gobierno la través del uso de las TICs, entre los que cabe mencionar a la ciudad de Puebla, México, como ganador de Ciudad Metropolitana.

Gartner: The Future of IT 2009 Del 1 al 3 de septiembre se realizó en la Ciudad de México la 12ª conferencia “The Future IT” organizada por Gartner. Entre los temas que dominaron la agenda de conferencias estuvieron inteligencia de negocios, virtualización, outsourcing y cómputo en la nube. Como parte del evento se realizó el “Gartner CIO Day” con actividades exclusivamente para los CIOs asistentes, que incluyeron comidas ejecutivas, mesas redondas y actividades privadas entre asistentes y analistas.

04

NOV-ENE 2010

www.sg.com.mx

// EVENTOs

18 de noviembre 2009

26 de noviembre 2009

Salón Los Candiles Polanco, Ciudad de México.

Info: www.gob20.org.mx

SHCP Expo Reforma Canaco, Ciudad de México.

Info: www.seguridad-shcp.org

25 de noviembre 2009

26 y 27 de noviembre 2009

Restaurante El Lago en Chapultepec, Salón Fuente 1.

Info: http://bit.ly/65zWbA

Museo del Transporte y Exposiciones, Xalapa, Ver. Auditorio del Estado, Guanajuato, Gto. Info: www.gulev.org.mx

Gobierno 2.0, Camp México 2009

Red Hat Enterprise Virtualization

5to. Día de la Seguridad de la Información

Tour GULEV Software Libre

Aniversario de MoProSoft

IBM Software Summit 2009

Con el objetivo de conmemorar el 4to. aniversario de la creación de MoProSoft, el pasado 29 de octubre la Asociación de Usuarios MoProSoft, Secretaría de Economía y NYCE, presentaron un Cirtuito Tecnológico enfocado en analizar su impacto a los cuatro años de su publicación como norma mexicana, y vislumbrar su futuro. Durante el evento se presentaron testimonios de consultores que participaron desde la creación de MoProSoft, así como los principales retos y logros de las empresas que han implantado este modelo.

Del 31 de agosto al 3 de septiembre se realizó el IBM Software Summit 2009 en la Ciudad de México. Cada día del evento estuvo dedicado a una división de software en IBM: Lotus, Websphere, Rational y DB2. Entre los conferencistas destacó Steven Robinson, Vicepresidente Mundial de Rational, quien comentó sobre los retos que enfrentan las organizaciones de software modernas, tales como la coordinación de equipos geográficamente distribuidos y la necesidad de escalar prácticas de desarrollo ágil a nivel organizacional.

Cutter Summit Latin America 2009

CIAPEM 2009

Cutter Consortium organizó del 28 al 30 de octubre en la Ciudad de México la edición para Latinoamérica del Cutter Summit 2009. Como ya es costumbre, Tom DeMarco estuvo al frente del grupo de conferencistas que incluyó a Mike Rosen, Ron Blitstein y Rogelio Oliva. Los temas que dominaron la agenda fueron gobierno de TI, arquitectura orientada a servicios (SOA) y outsourcing.

Del 23 al 25 de septiembre en la ciudad de Pachuca, Hidalgo se realizó la XXXIII Reunión Nacional del CIAPEM, instancia nacional que contribuye a orientar el desarrollo tecnológico en el país, llevando como tema central “La Innovación Gubernamental”. El objetivo se fijó en continuar implementando nuevas prácticas y procesos que han sido rebasados por la tecnología, por el conocimiento humano y por la misma sociedad, logrando así ser más eficientes brindando mejores servicios.

Steve Feuerstein en México Quest organizó una conferencia en México con la presencia de Steve Feuerstein, uno de los principales autores y evangelistas sobre PL/SQL. Una numerosa cantidad de asistentes se hizo presente, lo que denota el amplio interés que existe respecto a este lenguaje. La conferencia de Steve se enfocó en mejores prácticas para la programación con PL/SQL, así como tips para aprovechar las características incluidas en las versiones recientes.

Empresas evaluadas en modelos de calidad Empresa SIEENA SOFTWARE AD INFINITUM

EXPERT SISTEMAS

www.sg.com.mx

Evaluación CMMI N3 CMMI N3 CMMI N3

Fecha Julio 2009 Agosto 2009 Agosto 2009

Lead Appraiser José Alfredo Calvo José Alfredo Calvo José Alfredo Calvo

NOV-ENE 2010

05

// INDUSTRIA

Industria de TI en México Hacia el Desarrollo Y Sinergia de los Clusters Por Héctor González Después de un 2009 complicado en muchos sentidos, bien vale la pena revisar el estatus de la industria de software en México, qué avances se han tenido, qué pendientes hay y hacia donde vamos.

Antecedentes Desde el 2002 en que se creó el Prosoft para el impulso de la industria de software, hasta el 2008 se han puesto en marcha proyectos del orden de los 10 mil millones de pesos con una inversión conjunta del Gobierno Federal, Gobiernos Estatales e Iniciativa Privada. De esta forma, las empresas del Sector de Tecnologías de Información han logrado llevar su producción de los 700 millones de dólares en el 2002, a 5,750 millones de dólares estimados para el 2009. La tabla 1 muestra mayor información al respecto.

Perfil de la Industria de TI

2002

2008

2009e

En este período de tiempo hemos visto también como se ha integrado una industria de TI a nivel nacional, de tal forma que hoy casi todos los estados participan en el Prosoft. Así mismo la industria está conformada a través de diversas organizaciones, asociaciones, clusters, secciones especializadas en cámaras, etc. A la fecha se tienen identificados 24 clusters de TI, los cuales a su manera han definido estrategias, programas y proyectos orientados a promover la industria. Algunas organizaciones han obtenido más apoyos y recursos que otras, otras se han organizado mejor, otras tienen una visión a un plazo mayor.

Los proyectos y logros varían, pero el interés común es el deseo de consolidar una industria regional, enfocada a aprovechar las oportunidades que el mercado nos ofrece. Según en NASSCOM, se estima que para el 2013, los mercados globales de offshoring de TI serán de $71 miles de millones de dólares.

La Búsqueda de sinergia Empresas del Sector

2,095

2,134

2,350

Nivel de Producción

700 mdd

5,162 mdd

5,750 mdd

Exportaciones de TI

50 mdd

1,787 mdd

2,200 mdd

Estados con políticas de TI

4

32

32

Tasa de Crecimiento de la Industria

-1%

16%

11%

Empresas de TI con certificados de calidad

4

129

205

Clusters Tecnológicos

0

23

32

Parques Tecnológicos

0

12

22

Universidades con programas de T. I.

47

121

157

Tabla 1. Cifras de la industria de TI en México 2002-2009e. Fuente: AT Kearney, Select, AMITI, CANIETI, ANIEI

Durante este mismo lapso, el desarrollo de la industria de Tecnologías de Información ha reflejado un crecimiento promedio cercano al 15% anual. Este crecimiento le ha permitido a nuestro país desarrollar un perfil de industria con reconocimiento global. El Índice de Ubicación de Servicios Globales 2009 de AT Kearney coloca a México en el lugar 11 a nivel mundial de preferencia de outsourcing para el mercado de Estados Unidos, y de acuerdo a Gartner representamos el 4to. Lugar en la subcontratación de servicios de TI.

Hablamos de la proximidad que México tiene al mayor consumidor global de servicios de TI, así como otras ventajas competitivas; sin embargo, nos encontramos que aún no podemos capitalizar esos apoyos ni esas oportunidades que se nos presentan. A 6 años del inicio del Prosoft todavía hace falta una integración nacional que nos permita saber qué es lo que estamos haciendo en cada región, y cómo aprovechar las fortalezas nacionales y desarrollar sinergias que faciliten el crecimiento y consolidación de las empresas de Tecnologías de Información en nuestro país.

Con el objetivo de resolver este problema, en junio de este año la Cámara Nacional de la Industria de Electrónica, de Telecomunicaciones y Tecnologías de Información (CANIETI) creó la Vicepresidencia Nacional de Desarrollo de Clusters. Dicha vicepresidencia está encabezada por su servidor, y el objetivo es coordinar el desarrollo integral de los clusters de T. I. en México. Desde esta organización buscamos desarrollar las sinergias necesarias para: • Incorporar la participación de la Industria, Academia, Gobierno, Asociaciones y Organizaciones de TI en general involucradas en el desarrollo del Sector de Tecnologías de Información en México.

• Integrar el perfil regional de clusters que permita complementar y explotar las fortalezas regionales de acuerdo a sus características naturales, potencializando el crecimiento de la Industria.

• Compartir experiencias del desarrollo regional de los clusters.

• Articular esfuerzos conjuntos que permitan optimizar la inversión de recursos y despliegue de estrategias.

• Apoyar el desarrollo de una estrategia nacional de la Industria de Software y Tecnologías de Información.

Hector J. González es Socio-Fundador y Presidente de Kernel Technologies Group. Desde el 2003 ha colaborado en la formación de diversas empresas integradoras de Software como: Empeira, Qataria y Origo; ha participado activamente en múltiples organizaciones como: AMPI, AMITI, AETI, CSOFTMTY, CANIETI y el IMEF, desde junio de este año es Vicepresidente Nacional de Clústeres de CANIETI. hgonzalez@kerneltechnologies.com

06 16

NOV-ENE 2010

www.sg.com.mx

Encuentro Nacional de Clusters Como primera actividad de la VP de desarrollo de clusters, se convocó al 1er. Encuentro Nacional de Clusters de TI con el objeto de retomar, aquella iniciativa de Foros Nacionales de clusters, pero con otro enfoque. En lugar de la batuta la traigan el gobierno federal y/o estatal, el objetivo es que seamos los propios empresarios los que tomemos el compromiso de establecer las bases para la integración de una Industria de TI nacional que permita optimizar los recursos y apoyos disponibles, así como desarrollar las sinergias necesarias para consolidar nuestra industria, que nos permita jugar un rol protagónico a nivel internacional, de tal forma que nos asegure aprovechar las oportunidades que el mercado ofrece y capitalizar las ventajas que gozamos.

Durante el 1er. Encuentro Nacional de Clusters, que se celebró el pasado 15 de Octubre 2009, se contó con la representación de los estados de Baja California, Guerrero, Jalisco, Michoacán, Nuevo Leon, Nayarit, Oaxaca, Querétaro, Sinaloa, Sonora, Tabasco, Tlaxcala, Yucatán, Zacatecas y el Distrito Federal mediante la participación de los siguientes organismos: CANIETI (Nacional, Occidente, Sureste, Noroeste), IJALTI, Coecytjal, Fidsoftware, TISonora, CSoftMty, ProSoftware, InteQSoft, Cluster TIM, CITI Tabasco, CITI Yucatan, I&DT Software, CTI Tlaxcala, Cluster Strategic (Jalisco), Cluster TI Oaxaca, INayTI, Cluster de TI Zacatecas. Se contó también con la participación de los operadores de los programas: Fondo PYME, Prosoft, Mexico First y Mexico IT. Durante el Encuentro, el Lic. Omar Ibarra Nakamichi, Director General de Desarrollo Empresarial y Oportunidades de Negocio de la Secretaría de Economía, presentó los Esquemas de Fomento y Apoyo a Industria de TIC’s, resaltando en particular los programas México Emprende y Empresas Gacela, los cuales están disponibles y también pueden ser aprovechados por las empresas de TICs.

Los principales puntos que se tocaron durante esta reunión fueron: • Necesidad de establecer una vocación país de la industria.

• Relevancia en haber retomado este tipo de encuentros para el crecimiento y madurez de la industria de software nacional, y que la organización del mismo sea liderada por los empresarios.

• Novedades para Prosoft 2010: La convocatoria será abierta para que cualquiera pueda subir proyectos, se tiene contemplado realizar una sola convocatoria aunque a petición de la industria SE está considerando abrir más convocatorias, se establecerá un mecanismo para medir el desempeño de los organismos promotores.

• Posibilidad de abrir México First a esquemas donde solo participen empresarios, sin estar atenidos a que los estados apoyen.

• Esquemas de financiamiento y comercialización. Se anunciaron nuevos esquemas para el financiamiento del sector que se darán a conocer a principios del 2010. También se hará una revisión de las aceleradoras para darles un mayor enfoque hacia la comercialización.

Conclusión A pesar de los logros que ha tenido nuestra industria en los últimos años, todavía hay mucho camino por recorrer. Estamos conscientes de los ajustes que hay que hacer, y uno de ellos es promover la sinergia entre los distintos clusters en el país.

Con la VP de desarrollo de Clusters de CANIETI, se busca estructurar los clústeres de México, con el fin de que puedan integrar lo que se conoce como “Triple Hélice”, comprometiendo la participación de la Iniciativa Privada, Academia y Gobierno, en la planeación y ejecución de las acciones y proyectos requeridos para alcanzar el crecimiento económico, social y cultural de una región a través del desarrollo de una o varias industrias, en nuestro caso en el sector de Tecnologías de Información.

1er. Encuentro Nacional de Clusters

www.sg.com.mx

NOV-ENE 2010

17 07

// COLUMNA INVITADA

¿Tiene Sentido Crear un Silicon Valley en México?

Un Vistazo al Emprendimiento Global de TI Por Fernando Labastida

E

l famoso emprendedor tecnológico Paul Graham argumenta que cuando se formó Silicon Valley como centro de startups tecnológicos, no tenían otro centro contra el cuál competir. Sin embargo, si hoy en día intentamos crear un centro de startups de tecnología es mucho más difícil porque al crear nuevos startups estos se irían a otros centros ya establecidos. Dado que Silicon Valley ya tiene una masa crítica de recursos tales como inversionistas, universidades, emprendedores, etc., difícilmente pueden competir otros centros de emprendimiento.

quien a los 19 años fundó la empresa Core Security Technologies, que actualmente tiene sede en Boston y genera ventas millonarias. Pero estos casos de emprendedores e inversionistas locales son la excepción que comprueba la regla: no hay masa critica en América Latina. Es cierto que hay esfuerzos gubernamentales en varios países para impulsar a los emprendedores de TI, ¿pero es válido tratar de crear otros “Silicon Valleys” en América Latina? ¿Qué esperanzas tiene un país como México para crear una serie de startups que formen masa crítica?

Por ejemplo, si Guadalajara lograra incubar startups con financiamiento local, aquellos que quieran convertirse en empresas globales eventualmente tendrán que ir al Silicon Valley.

Esto es porque para llegar al siguiente nivel tendrán que recibir inversión de capital de riesgo, y la mayoría del capital de riesgo se encuentra en Silicon Valley. Roman Stanek, CEO de Good Data, en su reciente artículo “Avoiding the Cargo Cult” (http://bit.ly/14xZMT) comenta que aún para un startup de Europa es necesario irse al Silicon Valley para realmente poder competir al nivel mundial.

Aprovechando las ventajas de los países emergentes

Bling Nation, un startup fundado por el empresario argentino Wenceslao Casares, con sede en Palo Alto, California, recientemente levantó $20 millones de dólares de capital de inversión (http://bit.ly/38GHaT). ¿Hubieran recibido esa inversión si se hubieran quedado en Argentina?

De acuerdo con el ex-inversionista de capital de riesgo Alan Colmenares, sí es posible obtener este tipo de inversión en Latinoamérica. En su reciente artículo “Argentina: Vinos, Bife e Innovación Digital de Talla Mundial” (http://bit.ly/3KECwK), Colmenares pone como ejemplo el fondo argentino Aconcagua Ventures, el cual apoya a startups locales que buscan trascender a nivel global. Dicho fondo fue creado por Emiliano Kargieman,

Regresando a Alan Colmenares, en otro artículo reciente “Empresas de Mercados Emergentes Compiten Mejor” (http://bit. ly/14SxKH) describe una entrevista con Sridhar Vembu, director general de Zoho Corporation, empresa exitosa de aplicaciones de software, con más de 2 millones de usuarios.

Aunque Zoho está basado en Pleasanton, California, la mayoría de sus más de mil empleados están basados en India y China.

Vembu comenta que los startups de mercados emergentes no tienen que lamentar la falta de recursos de un Silicon Valley. Lo que deben hacer es aprovechar las ventajas que ofrecen sus países. Sus consejos para los startups de mercados emergentes: 1. Tener mucha paciencia. Los startups en los mercados emergentes no crecen con la misma velocidad que los startups en Silicon Valley.

2. No cuentas con el mismo capital humano con que cuentan en Silicon Valley o Boston. Tienes que desarrollar tu propio capital humano.

En cuanto al tema del capital humano, Vembu reconoce la dificultad de encontrar personal.

Típicamente lo que se hace es buscar egresados de la universidad y entrenarlos con el riesgo de que dejen la empresa tan pronto estén entrenados. Sridhar, en cambio, co-

mienza con egresados de secundaria. Le lleva más tiempo entrenarlos, pero estos jóvenes tienen mucho mayor lealtad a la empresa y están comprometidos con llevarla al éxito, en lugar de andar buscando una posición en otra empresa que les de un poco más de dinero.

¿Existen modelos semejantes en México?

Zacatecas no es conocido como un centro de desarrollo tenológico, pero Zacsoft (www. zacsoft.com), una empresa de desarrollo de aplicaciones para el iPhone, puede cambiar eso. Zacsoft, liderado por Raymundo Ceja, está lanzando al mercado mexicano y estadounidense una aplicación Software-as-a-Service (SaaS) que permite a los periódicos lanzar aplicaciones de noticieros para el iPhone.

Zacsoft recluta jóvenes recién graduados de la preparatoria y les da una capacitación intensiva por medio de Bootcamps.

Los desarrolladores aprenden diferentes tecnologías tales como .NET, Ajax, Flex, Air, MySQL, e incluso aprenden diseño para web y 3D, edición de video, y creación de videojuegos. Es un modelo muy exitoso para Zacsoft. ¿Pero es replicable? Yo digo que sí. Más emprendedores latinoamericanos están regresando a sus países como “Angel Investors,” inversionistas de capital en cantidades más pequeños para iniciar un startup. Esto es lo que está haciendo Andrés Barreto de PulsoSocial, que saliendo de Grooveshark se ha convertido en inversionista ángel para financiar startups en Latinoamérica.

Finalmente, para mercadear un startup no es necesario estar atado a una localidad en particular. La existencia del Internet, del blogging, los medios sociales, te permite llevar a cabo una campaña de marketing de contenidos internacional para crear una barrera de entrada para tus competidores y ser conocido mundialmente.

Fernando Labastida es el presidente de Latin IT Marketing (latinitmarketing.com) una consultoría de mercadotecnia que ayuda a empresa de software de América Latina entrar al mercado estadounidense por medio del marketing de contenidos. Ha trabajado durante más de quince años como ejecutivo de ventas, tanto en el mercado Norteamericano como en el mercado Latinoamericano. Esta felizmente casado y tiene cuatro hijos. fernando@labastida.com @flabastida

08

NOV-ENE 2010

www.sg.com.mx

www.sg.com.mx

NOV-ENE 2010

09

// COLUMNA

/*TEJIENDO NUESTRA RED*/

Pasado, Presente y Futuro de MoProSoft A siete años de su nacimiento La Dra. Hanna Oktaba es profesora de la UNAM a nivel licenciatura y posgrado. Sus áreas de interés son Ingeniería de Software, Tecnología Orientada a Objetos, Modelos de Procesos de Software y Mejora de Procesos. Actualmente es miembro de International Process Research Group (IPRC). También es Directora Técnica del proyecto COMPETISOFT.

H

ace siete años apenas se gestaba la idea de crear un modelo propio de procesos de software basado en las mejores prácticas de los modelos existentes, para elevar el nivel de capacidades de nuestra industria. Hoy estamos a punto de venderlo en “cómodas mensualidades”, llamados perfiles, como la norma internacional ISO/ IEC 29110 para organizaciones muy pequeñas (de 1-25 personas).

Les propongo que hagamos un pequeño recorrido por la historia de MoProSoft para poder vislumbrar su futuro.

Gestación 2002-2004 En mayo de 2002, me tocó como presidenta de la AMCIS y coordinadora de la estrategia 6 (alcanzar niveles internacionales en capacidad de procesos) de Prosoft, presentar los posibles caminos para la adopción de procesos y evaluaciones para la industria de software mexicana. La propuesta consistió en dos opciones, con el análisis de sus respectivas ventajas y desventajas.

Para nuestra sorpresa, a pesar de la oposición de algunos empresarios y gracias al apoyo de otros, la SE eligió el Plan B. En consecuencia entre 2002 y 2004 se realizaron tres proyectos que terminaron en la generación de la norma mexicana para la industria de software: • MoProSoft - modelo de procesos - documento base para la Norma Mexicana para la Industria de Desarrollo y Mantenimiento de Software.

• EvalProSoft – método de evaluación - otro documento base para la norma.

• Pruebas controladas del modelo de procesos para el desarrollo de software (MoProSoft) y su método de evaluación (EvalProSoft) hasta en cuatro empresas.

Los tres proyectos fueron financiados por Secretaría de Economía y se llevaron a cabo bajo los convenios con la Facultad de Ciencias, UNAM, dentro del programa Prosoft. En los proyectos participó gente experta de la AMCIS.

Plan A Este camino recomendaba: generar una versión ISO9001:2000 con la interpretación en SW-CMM nivel 2 y 3; capacitar auditores ISO en esta versión; promover la certificación de empresas de software en esta versión; e introducir normatividad que exija la certificación para la contratación.

Formalización como norma y adopción

Ventajas: Disponibilidad de normatividad y certificación nacional, reconocimiento ISO internacional, introducción a plazo relativamente corto 1-2 años.

NMX-I-059-NYCE-2005 Tecnología de la Información-SoftwareModelos de procesos y de evaluación para desarrollo y mantenimiento de software • Parte 01: Definición de conceptos y productos • Parte 02: Requisitos de procesos (MoProSoft) • Parte03: Guía de implantación de procesos • Parte 04: Directrices para la evaluación (EvalProSoft)

Desventajas: Capacitación de consultores y auditores.

Para sostener este plan contabamos con un mapeo entre ISO9001:2000 y SW-CMM nivel 2 y 3, resultado de una tesis de maestría.

El éxito de las pruebas controladas ha llevado a la SE a impulsar la formalización de los modelos de MoProSoft y EvalProSoft como norma mexicana. En 2005 AMCIS presenta documentos elaborados en los proyectos de SE ante el subcomité de Software del NYCE, los cuales se convirtieron en la norma mexicana:

Plan B Generar un modelo nacional de procesos y de evaluación de capacidades compatible con ISO15504.

Para darle soporte a la norma, NYCE crea el organismo Verificador, el cuál puede evaluar a las empresas en el cumplimiento de la norma. Para estimular el uso de la norma la SE, a través del programa Prosoft, ofrece apoyo económico a las empresas de desarrollo de software para la consultoría y la verificación.

Ventajas: Tener versión nacional del modelo internacional ISO específico para la industria de software y en español, y tener un modelo y una evaluación compatibles con CMMI.

Promoción iberoamericana 2006-2008

Desventajas: Para crear este proyecto se requiere crear un grupo industria- academia. También requiere un mayor tiempo (2-5 años).

Para sostener este plan solamente teníamos la confianza en el conocimiento de los miembros de la AMCIS y una pizca de intuición femenina.

10

NOV-ENE 2010

La importancia del proyecto de la norma en México fue reconocida por Dr. Mario Piattini, Universidad Castilla-La Mancha, España quien nos invitó para formular y llevar a cabo el proyecto COMPETISOFT: Mejora de procesos para fomentar la competitividad de la pequeña y mediana industria del software de Iberoamérica. En el proyecto participaron 23 grupos de investigación de 13 países iberoamericanos, financiado parcialmente por CYTED (Ciencia y Tecnología para el Desarrollo). www.sg.com.mx

El proyecto tuvo como resultado, entre otras cosas, la publicación de dos libros. El primero “Software Process Improvement for Small and Medium Enterprises, Techniques and Case Studies”, dirigido al mercado internacional, y el segundo “COMPETISOFT: Mejora de Procesos Software para Pequeñas y Medianas Empresas y Proyectos”, dirigido al mercado hispano parlante.

Otro resultado importante de este proyecto es que Perú ya adoptó la norma mexicana como NORMA TÉCNICA PERUANA 291.100 – MoProSoft, y Argentina, Uruguay y Colombia están probando la versión publicada en el libro COMPETISOFT para ver si lo incorporan en sus países.

Reconocimiento internacional a través de ISO/IEC 2006-2010 A partir del 2006 el Working Group 24 (WG24) del Subcomité 7 del ISO/IEC JTC 1 aceptó utilizar la norma mexicana NMX-I-059 para la industria de software como la base para el estándar internacional ISOIEC 29110 – Software Engineering – Lifecycle Profiles for Very Small Entities (VSE).

La propuesta de México es ofrecer los procesos de la capa de Operación de MoProSoft como Perfil Básico, los de Gerencia como Perfil Intermedio y el de Alta Dirección como Perfil Avanzado. La emisión del Perfil Básico de este nuevo estándar está prevista para el año 2010.

www.sg.com.mx

Estrategias de México para el futuro Tenemos que capitalizar el hecho de que México fue pionero en proponer modelo de procesos distinto, dirigido principalmente a las pequeñas empresas de desarrollo de software. Por lo tanto necesitamos pensar en dos objetivos a futuro: • Alinear nuestra norma MNX-I-059- NYCE-2005 con la ISO/IEC29110 para tener el reconocimiento internacional de nuestras evaluaciones y aprovechar el tiempo de tenerla ya vigente en México.

• Organizar a todos los interesados en el uso apropiado de MoProSoft y otros estándares para elevar la competitividad de la industria de software en México.

Se dice fácil pero requiere de entendimiento y convergencia de muchos actores. Otros países ya entendieron el valor de lo que hemos propuesto en México. ¿Y nosotros?

» Por Hanna Oktaba

Referencias: [1]. Oktaba H; Piattini M.”Software Process Improvement for Small and Medium Enterprises, Techniques and Case Studies”.Information Science Reference, Hershey – New York, abril de 2008 [2]. Oktaba H; Piattini M; Pino F; Orozco MJ; Alquicira C.“COMPETISOFT: Mejora de Procesos Software para Pequeñas y Medianas Empresas y Proyectos”. editorial Ra Ma, España, noviembre de 2008

NOV-ENE 2010

11

// COLUMNA

/*MEJORA CONTINUA*/

¡Yo No Quiero Cambiar!

Sólo hay dos razones básicas 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.

Y

a estamos en el cierre de año y es un buen momento para detenernos, respirar tranquilamente y filosofar un poco.

Durante una de las conferencias a las que recientemente asistí, me preguntaron: ¿Cómo haces para implementar procesos cuando las personas no quieren cambiar? Antes de continuar déjenme mencionar enfáticamente: “No se puede implementar algún cambio si las personas que deben cambiar no quieren hacerlo”. No importa si eres el jefe de todos, si los amenazas, si los vigilas o contratas un policía para que siga sus pasos. Si no quieren cambiar, aunque logres que hagan lo que requieres al corto plazo, en cuanto dejes de vigilar las cosas regresaran a como estaban.

Para ejemplificar esto sólo recuerden qué sucede cuando queremos cambiar algo en nuestra forma de vida; bajar de peso, hacer ejercicio, dejar de fumar; no importa cuánto te digan o qué hagan tus seres queridos, siempre se encuentra la forma de no hacer las cosas que no quieres hacer.

Como dice un libro que leí: sólo hay dos razones básicas por lo que una persona no hace un cambio, una es porque no sabe y la otra porque no quiere. Anteriormente hemos platicado sobre los cinco elementos básicos que se requieren contemplar para generar un cambio: Visión, Habilidades, Incentivos, Recursos y Planes.

Vamos a enfocarnos en la parte de incentivos.

Cuando se menciona la palabra incentivo lo primero que se piensa es en asignar dinero al problema. Definitivamente el dinero es el incentivo por excelencia, pero no es el único y peor aún, muchas veces es uno de los peores incentivos para un cambio. ¿Cómo es que el dinero puede ser un incentivo negativo? Pues el problema es que dar dinero pasa muy rápido de ser un diferenciador que excede expectativas a ser lo mínimo esperado, y pasa de ser un motivador para cambiar a ser un desmotivador que genera molestia. Esto no quiere decir que

12

NOV-ENE 2010

nunca se tenga que utilizar dinero sino que se debe tener mucho cuidado cuando se utiliza.

Jerarquía de necesidades Al plantear incentivos lo primero y más importante es escuchar y aprender qué mueve a las personas con las que estamos trabajando, qué es exactamente lo que queremos incentivar y con cuanta fuerza para así identificar cómo cambiamos el medio ambiente de la organización para que cada quien obtenga lo que quiere obtener.

El psicólogo Abram Maslow generó un documento llamado “La teoría de la motivación humana”. En él identifica diferentes niveles de necesidades y menciona como estas necesidades se complementan unas a otras en forma de pirámide, siendo los incentivos más básicos los más indispensables y al ir cubriendo estas necesidades, el siguiente nivel se hace ahora más indispensable, así hasta el nivel superior.

El nivel más básico de necesidades son las psicológicas y se refiere a las necesidades esenciales del cuerpo. Una vez cubiertas, las siguientes son de seguridad que se refieren a necesidades de seguridad personal, financiera, salud, etc. Aquí están las necesidades de dinero, una vez que la cantidad de dinero cubre un nivel suficiente para vivir bien deja de tener tanta importancia como motivador y pasamos a nivel de amor y pertenencia, se refiere a la necesidad de integrarse a un grupo social. Aquí es donde por ejemplo nos motiva pertenecer a un grupo que está cambiando. El siguiente nivel es el de autoestima, se refiere a la necesidad de ser respetado, por eso a veces es buena idea incluir a las personas en las definiciones o darle importancia a lo que ya está definido. Finalmente la autoactualización se refiere a la necesidad de superarse, por lo cual algunas personas aceptan el cambio cuando se percibe que van a aprender algo nuevo o van a desarrollarse en nuevas técnicas. Estar

en un nivel de necesidades u otro no es importante, lo importante del modelo es su función como punto de referencia y apoyo, para establecer qué podemos cambiar.

El camino al éxito depende del primer paso Algunas recomendaciones para definir cómo generar un plan de motivación: • Conócete a ti mismo: ¿Qué te motiva? ¿por qué? ¿en qué momentos se incrementa tu motivación? ¿en qué momento baja? ¿cómo puedes controlarlo? Entre más entiendas cómo los motivadores te afectan a ti, más fácil es entender como le pueden afectar a los demás y cómo reconocer que es motivante y que no.

• Escuchar, escuchar, escuchar. Una de las cualidades más importantes para implementar procesos es saber escuchar. No es suficiente escuchar lo que las personas dicen, sino qué es lo que quisieron decir. Cuando alguien dice “no tengo tiempo de hacer lo que me pides”, ¿quiere decir que le falta tiempo?, ¿o que como es algo nuevo no tiene tiempo de aprenderlo?, o tal vez en realidad signifique que su jefe no lo evalúa por eso. Para establecer una solución que beneficie a todos debes ser un experto escuchando lo que se dice y lo que se quiere decir.

• Experimenta: Motivar personas no es una ciencia exacta, es una constante investigación. Cada estrategia que definimos y cada cambio a los motivadores se debe evaluar y ajustar cuando es necesario.

El nivel de motivación nos ayuda a acelerar o frenar las iniciativas de cambio. Es importante evaluar constantemente si las personas no saben y no quieren, y ante todo no debemos olvidar las palabras de Zig Ziglar: “La gente continuamente dice que la motivación no es sostenible, pues tampoco la limpieza –por eso recomendamos atender ambas cosas diariamente”.

» Por Luis Cuellar www.sg.com.mx

www.sg.com.mx

NOV-ENE 2010

13

// PRODUCTOS

/* LO QUE VIENE*/

Flex y Flash Platform Services

Rational SDS for Cloud

Mantienen paso firme

Aprovechando la nube para transformar la entrega de software

En el frente de Flash se avecinan cosas interesantes. Flex 4, nombre clave Gumbo, actualmente se encuentra disponible como beta, y será liberado a principios del 2010. El grueso de las características de esta nueva versión están dirigidas a facilitar la integración de diseño y desarrollo de aplicaciones, además de poder aprovechar las nuevas capacidades introducidas en Flash 10. Por otro lado, Adobe recientemente dio a conocer Adobe Flash Platform Services. Dichos servicios agregan capacidades colaborativas a las aplicaciones tales como audio, chat y video. También facilitan la integración con redes sociales tales como Facebook y MySpace, e incluso habilitan capacidades para monitorear la distribución y uso de las aplicaciones en estas redes sociales, de tal forma que se puedan monetizar con mayor facilidad.

Una necesidad común en el desarrollo de software empresarial es la de establecer y administrar ambientes para desarrollo, pruebas y preproducción. Típicamente esta es una tarea que requiere conseguir hardware y asignar personal a que instale y configure cada ambiente. IBM Rational Software Delivery Services for Cloud Computing (SDS) es una herramienta que permite generar dichos ambientes en la nube, de forma sencilla y acelerada. A través de las herramientas de gestión de aplicaciones de IBM Rational, SDS habilita la generación en tiempo real de ambientes con productos preconfigurados de IBM. Dichos ambientes pueden ser hospedados en nubes privadas hospedadas por el cliente, o en la nube pública de IBM para desarrolladores.

Más información en www.adobe.com/flashplatform/services

Más información en www.ibm.com/cloud/developer

Go Visual Studio 2010

Tu nuevo lenguaje

Modelado y depuración

14

Todo parece indicar que Visual Studio 2010 será liberado en la primavera del 2010, junto con la versión 4 del .Net Framework. Las nuevas características de esta versión están enfocadas en el desarrollo colaborativo, modelado de sistemas y depuración. Una de las funcionalidades más importantes que agrega VS 2010 es Intellitrace, que es como el equivalente a la “caja negra” de un avión. Intellitrace permite grabar una aplicación durante su ejecución de tal forma que posteriormente se pueda revisar en conjunto el video de la ejecución de la aplicación junto con toda la información interna de depuración. Como es de esperarse, VS 2010 también incorpora capacidades para aprovechar tecnologías modernas como multicore y cómputo en la nube.

Google lanzó un nuevo lenguaje de programación llamado “Go”. Este lenguaje está dirigido a la programación de sistemas e infraestructura, tal como C o C++, pero optimizado para sistemas multiprocesador que deben soportar escalabilidad masiva. Go busca combinar lo mejor de los lenguajes actuales, combinando la simplicidad y velocidad de desarrollo de lenguajes dinámicos como Python con el desempeño y seguridad de lenguajes compilados como C. Go no está dirigido a principantes, tampoco es un lenguaje muy complicado. Es orientado a objetos y soporta características como clausuras (closures) y reflexión. En cuanto a nivel de complejidad, es equiparable a Java o C#. Go es software libre bajo licencia BSD.

Más información en www.microsoft.com/visualstudio

Más información en golang.org

NOV-ENE 2010

www.sg.com.mx

www.sg.com.mx

NOV-ENE 2010

15

// PRODUCTOS

/*HERRAMIENTAS*/

Manejo Colaborativo de Tareas Usando Manymoon Caso práctico del proyecto “SG09 Conferencia y Expo” Por Mara Ruvalcaba

Uno de los grandes retos que enfrentamos al dirigir proyectos en la actualidad es la complejidad que se agrega al contar con equipos distribuidos; es decir, los integrantes se localizan físicamente en diferentes lugares. Este fue el principal reto que visualicé al iniciar la planeación del congreso SG ‘09, ya que por ser la primera vez que se realizaría fuera de la ciudad de México, el equipo se encontraba en diferentes ciudades.

Con el objetivo de resolver este problema, lo primero que decidí fue buscar una herramienta que me permitiera manejar el proyecto coordinando al equipo distribuido. La herramienta que escogiera requería ser lo suficientemente sencilla para que realmente todos los integrantes la pudieran usar, así como contar con un espacio común que permitiera registrar y consolidar todos los entregables del proyecto (una especie de repositorio de artefactos). Adicionalmente, el patrocinador del proyecto se encontraba en la ciudad de Monterrey y yo querá minimizar la cantidad necesaria de viajes para realizar el seguimiento al proyecto, por lo que tenía que asegurar una excelente comunicación que le permitiera conocer en todo momento lo que estábamos realizando en SG como proveedores “remotos”, así como todas las tareas que se debían cubrir.

• Manejo de integrantes del proyecto • Integración de tareas con Google Calendar

Pantalla 1. Pantalla de inicio

En SG normalmente trabajamos los proyectos alineados a un plan de trabajo (el que por lo general solo entiendo yo, y tengo que “traducir” a los demás), y para trabajar de manera colaborativa nos apoyamos en herramientas como Google Apps, donde se asignan las tareas específicas, se manejan los documentos, y se crean sitios para definir nuevos proyectos. Para poder manejar la realización del congreso, éstas herramientas no eran suficientes, necesitaba algo más integrado, más sencillo y efectivo. Fue así que nos dimos a la tarea de buscar una aplicación en línea, que de primera instancia cumpliera con el requisito de manejar las tareas del proyecto.

Una de las primeras herramientas que identificamos fué Manymoon (www.manymoon.com), una herramienta en línea que permite el manejo colaborativo de tareas, y que además está basada en un modelo de red social. Empecé a utilizarla y me sorprendió su funcionalidad y facilidad de uso, por lo que decidí aplicarla para SG ‘09.

En este artículo comparto cómo es que usamos esta herramienta para administrar el proyecto de organización de SG ‘09 Conferencia y Expo.

La funcionalidad básica y los “nice to have” Entre la principal funcionalidad de Manymoon se encuentrá: • Manejo de proyectos • Manejo de tareas privadas o compartidas • Carga de archivos o liga a documentos localizados en Google Docs

16

NOV-ENE 2010

Pantalla 2. Boletín de estatus

Entre otras funcionalidades bastante agradables (very nice-tohave) están: • El boletín, una especie de “facebook feed” donde puedes conocer lo que recientemente hicieron cada uno de los integrantes del proyecto • Los avisos vía email o RSS sobre modificaciones a tareas y avisos de tareas pendientes • Una especie de twitter donde comunicas en qué estas trabajando www.sg.com.mx

“Manymoon reúne la funcionalidad básica y la experiencia del usuario esperada”.

Apta para diferentes perfiles de usuarios

Ambiente social y manejo de equipos distribuidos

Manymoon es una herramienta muy intuitiva y cuenta con una interfaz gráfica muy limpia y consistente. Al decir consistente me refiero a que independientemente de la página en donde te encuentres, siempre te “mueves” de la misma manera, siempre realizas las funciones y localizas la información de la misma forma. Esto me animó a mostrar la herramienta a los diferentes integrantes del proyecto: desarrolladores, diseñadores, y vendedores, entre otros. La prueba de fuego era ver si con una explicación de aproximadamente 10 minutos serian realmente capaces de utilizar la funcionalidad básica de la herramienta. La respuesta fue positiva: todos entendieron y utilizaron contentos la herramienta.

La funcionalidad que permite invitar a los diferentes miembros del proyecto a integrarse al equipo está basada en un concepto de red social. Esto permite comunicar el perfil de cada uno y mantener conecciones entre los diferentes miembros del proyecto (y de diferentes proyectos). Esto nos ayudó mucho porque la mayoría de las personas no se conocían (ni se conocerían hasta la fecha del congreso), y tendrían que trabajar en equipo. Usando esta aplicación, por lo menos conocieron sus fotos y perfiles y se pudieron comunicar de diferentes maneras.

Complejidad y múltiples proyectos Para el proyecto necesitaba contar con una aplicación que me permitiera manejar por lo menos unas 300 tareas (terminamos registrando 250 tareas). Manynoon soporta esta cantidad, pero me di cuenta de que si dividía el proyecto en mini-proyectos, dependiendo del tipo de tareas, podría incluir en cada proyecto solo a las personas que participarían en esas tareas (varias personas terminaron asignadas en varios proyectos).

Esto también resolvió el problema de compartir tareas estratégicas e información confidencial únicamente con los directivos del proyecto, resolviendo el requisito de seguridad y rápido acceso. Finalmente esto también me abrió la opción de integrar a algunos proveedores al uso de la herramienta.

En evaluaciones a Manymoon que encontré en Internet se considera que es una herramienta para uso personal o de pequeños negocios, con unas lista de 10 a 15 tareas. Yo considero que dependiendo de cómo lo manejes, puede soportar proyectos grandes y complejos.

Pantalla 4. Miembros del proyecto

El manejo de tareas Manymoon permite crear fácilmente una tarea y maneja los atributos básicos que debe tener una tarea como: nombre, fecha de término, prioridad, estatus (abierta, terminada, cancelada), responsable (permite asignar varios). También maneja opciones más avanzadas como: agregar documentos, agregar hiperligas, ligar la tarea a un calendario, y hasta permite crear tareas recurrentes.

Algo muy útil es que permite agregar comentarios a cada tarea, lo que permite conocer el estatus real de cada una. Cualquier integrante del proyecto puede agregar comentarios, así como mandar avisos vía email a las personas que decida avisar sobre la actualización de la tarea. No es necesario que el director del proyecto ande como policía molestando a la gente y perdiendo el tiempo pidiendo el estatus. Cada quien es responsable de actualizar la tarea y de compartir lo que está pasando.

Pantalla 3. Lista de Proyectos

www.sg.com.mx

En la lista de tareas podemos desplegar las tareas por responsable, por estatus (ej. solo abiertas, prioridad alta), así como ordenarlas, visualizar fechas de cierre, y agregar comentarios.

NOV-ENE 2010

17

// PRODUCTOS

/*HERRAMIENTAS*/

Pantalla 5. Lista de tareas

Pantalla 7. Milestones

La colaboración e integración con el mundo Actualmente muchas empresas utilizan Google Apps para trabajar de manera colaborativa, y en SG es la herramienta que normalmente utilizamos. Fue de gran ventaja el contar con la integración de Manymoon a Google Docs y Google Calendar, pues también a muchos integrantes del proyecto les pareció bastante familiar poder desarrollar documentos en Google Docs y después poder asignarlos a tareas en Manymoon. Adicionalmente, tener los documentos en Google Docs nos permitió economizar el espacio de almacenamiento usado en Manymoon, el cual es limitado (dependiendo del plan que contrates).

Pantalla 6. Detalles de una tarea

El valor agregado: manejo de milestones

La pantalla 8 muestra la lista de documentos pertenecientes a un usuario. Esta lista permite localizar de una forma sencilla cualquier documento, sin tener que buscarlo dentro de cada proyecto o tarea. Un mismo documento puede estar ligado a varios proyectos o tareas. El ícono previo al nombre del documento indica el tipo de archivo, y los que no incluyen ícono son ligas a documentos localizados en Google Docs.

Una característica muy importante al planear un congreso es que la fecha es realmente inamovible. La fecha de ejecución del congreso no se puede cambiar, por lo tanto es indispensable el no permitir el retraso en las tareas. El congreso se empieza a planear 8 meses antes, y desde entonces se inician las tareas con la meta de ejecutar el congreso en la fecha planeada y con la calidad esperada.

Algo que realmente ayuda a mantener las tareas en tiempo es el manejo de milestones o hitos, pues permite asegurar que cada tarea tiene una fecha límite, y tiene una razón de ser, ya que está enfocada en lograr un objetivo claro del proyecto. Cuando empecé a utilizar Manymoon me llevé la muy grata sorpresa de que, de una manera muy sencilla permitía definir milestones y después asignar tareas “arrastrándolas” dentro de cada milestone. Esta fue una funcionalidad que no esperaba, fue un valor agregado que me convenció de que Manymoon sería una herramienta mucho más completa, y no un simple manejo de un ToDo List.

18

NOV-ENE 2010

Pantalla 8. Documentos de un usuario

www.sg.com.mx

Ya casi para finalizar el proyecto, un mes antes de la ejecución del congreso, Manymoon agregó la integración con Google Calendar. ¡Justamente lo que en ese momento necesitaba!

Opté por crear un calendario en Google que contuviera todas las actividades relacionadas con el congreso, y a este ligué los 10 proyectos que tenía creados en Manymoon. De esta forma, al desplegar el calendario (en Manymoon o en Google calendar) se podían ver todas las tareas necesarias para ejecutar el congreso, y era fácilmente identificar los días que tendrían mayor carga de trabajo.

Manymoon también crea los milestones en el calendario, solo que les antepone las letras “MS”.

incluye funcionalidades interesantes como la creación de plantillas de proyecto, y monerías como agregar tu logo, avisos vía RSS, e imprimir en PDF. Manymoon es una herramienta bastante accesible, que para proyectos pequeños bien permite trabajar con la membresía gratuita ó standard. Te sugiero contratar niveles adicionales conforme identifiques que incrementan las necesidades en tu proyecto.

Lo que más me gustó Sobre la funcionalidad, lo que más me gustó fue la ideología de ligar las tareas a un milestone, y por supuesto la integración con Google Docs y Google Calendar. Por otro lado, me agradó mucho que cuando tuve problemas de funcionalidad, reporté el problema y la gente de soporte lo resolvió en menos de 24 horas (mi problema era que no me permitía usar nombres de proyectos con acentos o con apóstrofes).

Lo que mejoraría La verdad extrañé poder visualizar el proyecto con una gráfica de Gantt, pero creo que eso es más que nada un capricho. Lo que sí me hizo falta fue el poder contar con dependencias entre tareas. Por ejemplo muchas veces hace falta poder saber qué tarea se necesita terminar antes de poder empezar la siguiente. Esto sería una funcionalidad muy útil para la dirección de proyectos (para visualizar la ruta crítica) y espero que pronto la agreguen.

Conclusión

Imagen 9. “ProjectCalendar”

Los tags Los tags son un atributo novedoso, que en general se utiliza para “etiquetar” o describir mejor una pieza de información, y que posteriormente sirve para encontrar dicha pieza o relacionarla con otros elementos. Manymoon permite agregar tags a un proyecto o tarea, y hasta a tu perfil. Agregar tags a una tarea por ejemplo, te ayuda a identificar los skills necesarios para realizar dicha tarea, lo que te permitirá definir a quien debes asignar a esa tarea. Agregar tags a un proyecto ayudan a describirlo mejor, no necesitas crear una descripción larga y compleja, simplemente con tags puedes describirlo mejor.

Por ejemplo, para el proyecto “SG09 - Conferencias”, se definieron los siguientes tags: lineamientos, convocatoria, evaluación, semblanzas, conferencistas, fotos, comité, presentaciones, y reconocimientos, los que prácticamente describen de qué trata el proyecto.

Las opciones de uso Manymoon ofrece diferentes opciones, o lo que llama membresías. La membresía básica no tiene costo e incluye el manejo ilimitado de proyectos, tareas e integrantes, un espacio para almacenar de hasta 5Mb, pero únicamente se puede ligar un solo proyecto a Google Calendar.

Debido a que yo necesitaba más espacio para almacenar, así como la opción de ligar varios proyectos a Google Calendar, entonces contraté la opción de $20dls al mes (precio bastante razonable), que además

www.sg.com.mx

Además de la funcionalidad previamente mencionada, Manymoon cuenta con las opciones de crear tareas a partir del envío de un mail, manejar time sheets (hojas de tiempos), y manejar eventos, opciones que no mencioné en detalle porque en realidad no las he utilizado a profundidad. Sí quiero hacer énfasis en el manejo de time sheets porque creo que para el manejo de proyectos de desarrollo de software, esta es una funcionalidad que puede ayudar bastante al control de tiempos por recurso, y por consiguiente, al control adecuado del presupuesto del proyecto.

En la actualidad el éxito de los proyectos se podrá alcanzar, así como el éxito la sociedad en sí, en la medida en que se realicen de una manera realmente colaborativa. Manymoon es una herramienta realmente colaborativa, que reúne la funcionalidad básica y la experiencia del usuario esperada, y por si fuera poco, cuenta con un excelente desempeño. Manymoon está dirigido principalmente a negocios y proyectos pequeños, pero no está limitado a eso.

Usar Manymoon me ayudó a cambiar la forma en la que normalmente trabajaba, abriendo mi panorama a nuevas herramientas que permiten aprovechar una forma de trabajo colaborativo y social, explotando el concepto de Enterprise 2.0. En SG ya utilizamos esta herramienta para manejar todos nuestros proyectos, y planeamos seguir seguir explorando nuevas herramientas que nos ayuden a trabajar mejor.

NOV-ENE 2010

19

CONFERENCIA Y EXPO

E

n esta ocasión SG09 se realizó en Monterrey, Nuevo Léon y fue presentado por el Consejo de Software de Nuevo León (Csoftmty). Debido a la importancia que ha cobrado la industria de TI en el estado, el Consejo de Software de Nuevo León (Csoftmty), en conjunto con el gobierno estatal, se dieron a la tarea de continuar contribuyendo al auge y desarrollo de la industria, decidiendo así presentar en esta ciudad SG09, consolidando al estado como uno de los lugares más convenientes para el desarrollo de software en el país.

De esta manera y después de muchos preparativos en conjunto, se llevó a cabo exitosamente del 27 al 30 de septiembre, la cuarta edición de SG´09 Conferencia y Expo. Esta edición logró consolidarse como un evento de clase mundial, manteniendo una alta calidad tanto en su contenido, como en su organización. A lo largo de cuatro días, el evento reunió a más de 800 profesionistas, directivos y estudiantes de software provenientes de toda la República Mexicana, así como de diversos países de América Latina.

20

NOV-ENE 2010

www.sg.com.mx

•Llegamos a más de 600 asistentes virtuales

•Participaron más de 30 voluntarios de diferentes universidades de Monterrey

• Los asistentes a SG´09 provinieron de 23 estados de la república

•Más de 36 horas de capacitación continua

www.sg.com.mx

NOV-ENE 2010

21

Así se vivió

Inauguración Para la inauguración tuvimos como invitado de honor al Gobernador del Estado de Nuevo León, José Natividad González Parás, quien fue acompañado por representantes de organizaciones tales como la Secretaria de Desarrollo Económico, el Consejo de Software de Nuevo León, Monterrey Ciudad Internacional del Conocimiento, CANIETI, AETI y MIT Cluster entre otros. Como parte de la apertura del evento, Eduardo Ruíz Esparza, Presidente de CANIETI, nos compartió un panorama sobre la industria de software en México, a quien continuó Guillermo Safa, Director de Csoftmty, enfocándose en el desarrollo de la industria en Nuevo León.

Keynotes Uno de los elementos de SG Conferencia y Expo que genera mayor expectativa son las conferencias magistrales. A través de los años hemos presentado a reconocidos gurús internacionales, y este año no fué la excepción. El equipo de conferencistas magistrales de este año estuvo formado por Molly Holzschlag, quien nos habló sobre diseño de websites basado en estándares, Scott Hanselman, quien presentó las últimas tendencias sobre desarrollo web, Luis Cuellar compartiendo experiencias sobre empresas mexicanas, Per Kroll quien nos habló sobre métodos ágiles, y por último Luke Hohmann tratando el tema de innovación en el desarrollo de software. El objetivo fue brindar temas dirigidos a cada perfil de nuestra audiencia: programadores, diseñadores, gerentes, directivos y empresarios. A pesar de que todas las conferencias magistrales fueron de gran interés, el mejor evaluado fue Scott Hanselman, quien presentó un tema muy interesante, además de que es un excelente y divertido conferencista.

Tutoriales Los tutoriales se realizaron el domingo previo al inicio de conferencias. Bajo un ambiente de estudio y talleres totalmente prácticos, los asistentes pudieron aprender de los expertos, las tecnologías más novedosas y las prácticas más efectivas. Agradecemos a las empresas participantes y a todos los instructores y damos un reconocimiento especial a Alpha Consultoría, cuyo tutorial “Equipos Virtuales de Alto Desempeño” fue el mejor evaluado por los asistentes.

Sedes virtuales SG ‘09 no solo gozó de asistencia presencial, sino también virtual. Un grupo de universidades y clusters tecnológicos fueron habilitados como sedes virtuales para recibir en vivo todas las conferencias. Esto fue una gran innovación y sin duda un gran reto, ya que estuvimos transmitiendo en vivo por internet las conferencias de 4 salones simultáneos, logrando reunir a más de 600 asistentes virtuales. Agradecemos a todas las sedes virtuales por su apoyo y confianza en nosotros.

28 22

NOV-ENE 2010

Eventos sociales En esta ocasión tuvimos dos eventos sociales muy divertidos. La noche previa al inicio de conferencias realizamos un paseo por el canal de Santa Lucía.

Tomamos la embarcación acompañados de la música de mariachi con un super ambiente. Llegamos a la Macroplaza y nos dirigimos a un bar ubicado en el Barrio Antiguo de la ciudad con la finalidad de “romper el hielo”, compartiendo entre todos experiencias y expectivas del congreso. La noche siguiente tuvimos mesas de casino y juego de Rock Band en la zona de expo, donde participaron asistentes, expositores e incluso conferencistas como Molly y Scott, quienes se llevaron los aplausos al ser los rockstars VIP de la noche. Todos los asistentes concursaron por excelentes premios, jugando y participando con sus equipos en el concurso de Rock Band.

Día de Líderes El último día del evento se realizó lo que denominamos “día de líderes”, cuyo objetivo fue reunir directivos tanto de organizaciones usuarias como proveedoras de tecnologías de información para conocer tendencias, mejores prácticas y compartir ideas. Contamos con la participación de conferencistas de muy alto nivel, tal como Frances Karamouzis, vicepresidente de investigación en Gartner, quien cubrió el tema de outsourcing de TI; y por segunda ocasión en SG Conferencia y Expo, contamos con la participación de Tim Lister, consultor de Cutter Consortium, quien facilitó un panel con CIOs de organizaciones como Alestra, Gobierno de Nuevo León, Sigma Alimentos y Elektra. La tarde de este día estuvo dedicada a la actividad de “juegos de innovación”, donde los asistentes realizaron distintas actividades orientadas a conocer mejor los requerimientos y expectativas de sus clientes y proveedores.

Patrocinadores y Organismos de Apoyo No podemos dejar de agradecer a Secretaría de Economía, por apoyar el evento mediante el programa Prosoft, así como a todas las empresas patrocinadoras y organismos que apoyaron el evento, como son: IBM, Microsoft, Opera Software, Softtek, AETI, CANIETI, MIT Cluster, 4D, Alpha Consultoria, EISEI, ErmesTel, eQuallity, Gelattina, IIDEA, Infotec, Kernel, Manpower, Matersys Group, Neoris, UANL, UR, Epicor, Innevo, Intellekt, InterSoftware, Itera, Maseca, Milestone, Qualtop, Pearson, Scio, SynergyJ, ALAPSI, AMESOL, AMITI, ANIEI, Gamers, Warp, JustManager, Logitech, Monólogos de la Cantina y Netec.

Así concluyó SG´09. No podemos negar que fue agotador, tanto para organizadores como asistentes, pero bien valió la pena. ¡Nos vemos en el próximo evento de SG!

www.sg.com.mx

Juegos

de Innovación

En el contexto del día de líderes SG09, la tarde del 30 de septiembre se llevó a cabo la actividad de “Juegos de Innovación”. En esta actividad participaron directivos de organizaciones usuarias y proveedoras de servicios de Tecnologías de Información con el propósito de identificar y compartir mejores prácticas para la contratación y ejecución de proyectos de TI. Esto es algo sin precedentes en México y los resultados generaron mucho aprendizaje, por lo que queremos compartir con ustedes algunos de los aspectos más relevantes.

La dinámica Para cumplir con este propósito de colaboración y flujo de ideas, decidimos que lo ideal era aplicar el concepto de juegos de innovación. Los juegos de innovación son juegos serios diseñados para ayudar a entender mejor a tus clientes, son una iniciativa que ha cobrado gran popularidad en los últimos años en industrias de alta innovación. Para facilitar los juegos contamos nada mas y nada menos que con Luke Hohmann. Luke es precisamente creador del concepto de “Innovation Games” y autor del libro con el mismo nombre. Es un facilitador de talleres muy reconocido en Silicon Valley, y desde que lo contactamos le interesó mucho la oportunidad de hacer juegos de innovación en México.

Los juegos Los juegos realizados fueron los siguientes: • Build the Product Box. Los clientes definieron a su proveedor de TI ideal mientras que los proveedores hicieron lo propio, definiendo a su cliente ideal. www.sg.com.mx

• Nightmare. En este juego, los asistentes plasmaron en dibujos cual sería su cliente/proveedor de pesadilla, áquel con el que jamás quieren volver a trabajar.

• Remember the Future. Este juego simula que estamos en el futuro, cerrando un proyecto que fue todo un éxito. La dinámica consiste en que tanto clientes como proveedores recuerden las acciones que realizaron a lo largo de la ejecución del proyecto, que contribuyeron al éxito de este.

Lecciones aprendidas Entre las peticiones de los proveedores destacó la idea de la simbiosis (si al cliente le va bien, al proveedor también) y lealtad ya que es común que los clientes soliciten propuestas y prototipos que no son pagados y que simplemente utiliza para “robar ideas” y contratar a otro proveedor o implementarlas internamente. Por su parte, los clientes comentaron que sus proveedores ideales tendrían experiencia real en lo que dicen hacer, especialización en tecnologías y/o verticales específicas, referencias comprobables, y programas reales de mejora continua. Vale la pena resaltar que entre las peticiones de los clientes no se mencionó en ningún momento un bajo precio.

Cuando el facilitador hizo notar esto, los clientes comentaron que el precio no es una barrera de entrada, y que la mayoría de las organizaciones están dispuestas a pagar un “premium” por un servicio que cumpla las características indicadas. En cuanto a los elementos de las pesadillas, los clientes se quejaron de los proveedores que una vez que consiguen un contrato, se despreocupan por el beneficio del cliente y se dedican a dar excusas.

Conclusión Los juegos de innovación son una excelente forma de conocer y entender las necesidades de tu cliente o contraparte. La idea de realizarlos involucrando tanto a clientes como proveedores de una industria específica fue muy buena, e incluso Luke Hohmann estaba muy entusiasmado al respecto porque no es algo que se logre fácilmente. Planeamos organizar más frecuentemente este tipo de eventos, llevando los juegos de innovación a los distintos clusters del país.

NOV-ENE 2010

23

// ENTREVISTA

Per Kroll Per Kroll es Arquitecto en Jefe en el grupo de Desarrollo de Experiencia e Innovación en IBM Rational. Parte de sus responsabilidades es la de asesorar la transformación de un grupo de más de 20 mil desarrolladores de software en IBM hacia procesos de desarrollo ágiles.

También dirige el proyecto de Eclipse Process Framework, una herramienta basada en la plataforma Eclipse para gestionar procesos de desarrollo de software.

Per participó como conferencista magistral en SG ‘09 Conferencia y Expo, y tuvimos oportunidad de platicar con él para conocer más sobre su trabajo y perspectivas.

¿Podrías darnos un breve panorama de lo que consistió tu conferencia en SG ‘09?

La plática se enfocó en dos puntos. El primero fue simplemente hacer ver que no existe una forma única de hacer desarrollo ágil; no existe ningún método “listo para usarse” que funcione para todos.

Las organizaciones que desean adoptar ágil deben comprender que deben ajustar los procesos en base al tipo de problemas que buscan resolver, así como al contexto de la organización.

El otro tema que manejé en mi plática fue el de métricas. En la industria de software tenemos el problema de que muchas organizaciones se embarcan en esfuerzos de mejora de procesos, pero no tienen forma de medir qué es lo que les está funcionando y qué no, así que simplemente están adivinando cuáles son las prácticas que les traen beneficios. ¿Cuáles son los problemas más comunes con las métricas de software?

Por lo pronto encontramos que la mayoría de las organizaciones de software no tienen métricas establecidas. En el caso que las tengan, tienden a recolectarse de forma manual, esto quita tiempo a los desarrolladores y es susceptible a errores humanos o malas intenciones. Otro problema es que las métricas solo son de interés para los gerentes pero no para el equipo, por lo que no hay un sentido de responsabilidad. ¿Solamente se deberían llevar métricas para datos “duros” (ej. costo) o también para datos “suaves” (ej. motivación)?

Existen dos grandes tipos de métricas: las de resultados y las de control. Las primeras te indican si se está cumpliendo un objetivo específico, las segundas si se está trabajando de la forma que se había acordado para poder cumplir los objetivos.

Nosotros identificamos tres niveles de métricas: el nivel de negocio que se enfoca en métricas de valor, como sería el retorno de inversión; luego está el nivel operacional donde nos enfocamos en métricas de efectividad, como la productividad, el tiempo para implementar un proyecto (time to market); el último nivel es el de prácticas, es decir las métricas para determinar si un proceso se está ejecutando de forma adecuada y si el equipo está satisfecho con la forma en la que se está trabajando. Las métricas de los dos primeros niveles son de resultados, mientras que las métricas del nivel de prácticas son de control. A final de cuentas, los tres niveles están ligados. Es decir, la forma en la que el equipo trabaje (métricas de control), afectará los resultados operativos y esto a su vez afectará el valor entregado al negocio.

24

NOV-ENE 2010

¿Cómo se relaciona esto la mejora de procesos?

Lo que hemos encontrado es que muchas organizaciones de software que se embarcan en iniciativas de mejora, deciden adoptar marcos genéricos y los adoptan al 100%. Esto rara vez es exitoso, ya que las organizaciones adoptan más prácticas de las que necesitan, lo cual es costoso e inútil.

Hagamos una analogía, imagínate que decides entrenarte para poder correr un maratón. Para ello, seguramente recurrirás a un entrenador. Lo primero que el entrenador hará será hacerte una evaluación para conocer tus fortalezas y debilidades. En base a ello, te hará un plan de entrenamiento basándose en tu estado actual y los objetivos que deseas; tal vez se enfoque en aumentar tu fuerza, tu resistencia, tu técnica de respiración, tu alimentación, etcétera.

Conforme vaya avanzando tu entrenamiento y en base a los resultados que se vayan obteniendo, el plan de entrenamiento se irá adaptando para poder cumplir los objetivos establecidos.

Esto mismo debe hacerse cuando una organización desea mejorar sus resultados de desarrollo de software. Es decir, en lugar de ponerse a implantar de principio a fin un proceso genérico, primero debe establecer sus objetivos, luego evaluarse para saber cual es su estado, en base a esto determinar en qué necesita enfocarse para lograr los objetivos establecidos, e ir adaptando dicho plan conforme se vayan teniendo resultados. Esto es lo que llamo adopción de prácticas incremental. ¿Entonces, en lugar de buscar lograr algún nivel de CMMI deberíamos enfocarnos en adoptar prácticas?

Así es. Dependiendo de qué es lo que busca el equipo (mejorar la calidad, el tiempo de desarrollo, la satisfacción del usuario, etc) se deben identificar las prácticas que tengan mayor impacto hacia esos objetivos e implementarlas de forma incremental. ¿Cuales serían algunas de esas prácticas que se podrían adoptar incrementalmente?

Por ejemplo desarrollo iterativo, integración continua, arquitecturas basadas en componentes, desarrollo dirigido por pruebas. ¿Alguna recomendación para los lectores?

Les recomiendo que busquen información sobre el “Measured Capability Improvement Framework” (MCIF), que es la iniciativa en la que trabajo, y que captura mucho de lo que he comentado aquí. www.sg.com.mx

www.sg.com.mx

NOV-ENE 2010

25

26

NOV-ENE 2010

www.sg.com.mx

A

finales del siglo XX el modelado Orientado a Objetos alcanzó su madurez, llevando a UML como uno de sus estándares más avanzados. A pesar del progreso notable que esto representó, la industria del desarrollo de software aun no puede responder con la velocidad necesaria a las organizaciones que requieren cambiar rápidamente sus reglas de negocio. Y si agregamos a esto la rápida evolución de la tecnología en un ambiente altamente interconectado con diversas plataformas, el integrar los diversos sistemas de una organización se vuelve complejo y demandante. Es en este tipo de problemas donde no basta con las nuevas tendencias en la industria de cómputo, donde el desarrollo rápido de aplicaciones (RAD por sus siglas en inglés), la arquitectura orientada a servicios (SOA) y la computación en nube, no son suficientes.

Desarrollo Dirigido por Modelos (MDD)

Buscando eficiencia en un entorno cambiante Una oportunidad crítica para tu organización consiste en integrar los sistemas internos a una arquitectura que contemple una visión a largo plazo. Es necesario integrar lo que se está desarrollando con lo que se ha construido y con lo que se desarrollará, además de integrar todo con los sistemas de nuestros clientes, proveedores y socios de negocios. Para lograr una arquitectura así, adoptar estándares industriales apropiados es una decisión vital, ya que la estrategia de integración de los procesos de negocio debe contemplar una plataforma tecnológicamente neutral que dure al menos para los próximos veinte años y que al mismo tiempo permita continuar y evolucionar la operación del negocio.

Para poder integrar sistemas de software con tecnologías diversas (EJB/J2EE, .NET, XML, SOAP, etcétera) y que puedan adaptarse rápidamente a las cambiantes necesidades del negocio, la tendencia es apostar al desarrollo dirigido por modelos (Model Driven Development, MDD). En este paradigma de desarrollo, los artefactos principales del desarrollo son los modelos (no los programas) que son transformados para “disparar” la generación de otros artefactos. MDD implica una generación semi-automática de los programas a partir de los modelos. Bajo este enfoque, un experto del negocio puede expresar su conocimiento en un lenguaje formal de modelado y el equipo de tecnologías

www.sg.com.mx

de la información define cómo se implementará. Y si se desea, el mismo modelo puede implementarse hacia plataformas diferentes (Java, .Net, CORBA). De un mismo modelo independiente de plataforma, que representa el conocimiento del negocio, se pueden generar diversos artefactos dependientes de plataforma sin tanto esfuerzo.

Al desarrollo basado en modelos, también se le conoce como Ingeniería Basada en Modelos (Model Driven Engineering, MDE) y de él se derivan distintas propuestas. La Arquitectura Dirigida por Modelos (Model Driven Architecture, MDA) propuesta por el Object Management Group (OMG), es posiblemente la más conocida. Sin embargo existen otras propuestas como la de Modelos de Objetos Adaptables (Adaptive Object Models) y Metamodelos, que intentan facilitar el construir sistemas, dinámicos y adaptables. Esta última estrategia se encuentra altamente relacionada con la investigación de reglas de negocio, específicamente cuando se necesitan medios para describir las reglas de negocio y automáticamente generar implementaciones.

El principio básico detrás del desarrollo basado en modelos es que si sabemos que algo va a cambiar en una forma predecible, modelemos la descripción del cambio de tal forma que sea fácil cambiarlo. En otras palabras: si algo va a cambiar mucho, hazlo fácil de cambiar.

NOV-ENE 2010

27

Model Driven Architecture (MDA) La Alternativa del OMG al MDD Por Mike Armas

U

na de las iniciativas de mayor importancia en el Object Management Group (OMG) es la arquitectura dirigida por modelos (Model Driven Architecture o MDA), que es un marco de trabajo de arquitecturas para desarrollo de software, con tres metas principales: portabilidad, interoperabilidad y reusabilidad. Un aspecto fundamental de MDA es su habilidad para contemplar el ciclo completo de desarrollo, cubriendo análisis, diseño, programación, pruebas, despliegue y mantenimiento.

MDA resuelve los retos de los sistemas actuales altamente conectados y constantemente cambiantes, tanto en reglas de negocio como en tecnología proponiendo un marco de trabajo para una arquitectura que asegura: • Portabilidad, aumentando el re-uso de las aplicaciones y reduciendo el costo y complejidad del desarrollo y administración de las aplicaciones.

• Interoperabilidad entre plataformas, usando métodos rigurosos para garantizar que los estándares basados en implementaciones de tecnologías múltiples tengan todos idénticas reglas de negocio.

• Independencia de plataforma, reduciendo el tiempo, costo y complejidad asociada con aplicaciones desplegadas en diferentes tecnologías.

• Especificidad del dominio, a través de modelos específicos del dominio, que permiten implementaciones rápidas de aplicaciones nuevas, en una industria específica sobre diversas plataformas.

• Productividad, permitiendo a los desarrolladores, diseñadores y administradores de sistemas usar lenguajes y conceptos con los que se sienten cómodos, facilitando la comunicación e integración transparente entre los equipos de trabajo.

Conceptos básicos de MDA

• Puntos de vista del sistema. MDA especifica tres puntos de vista en un sistema: independiente de cómputo, independiente de plataforma y específico de plataforma. El punto de vista independiente de cómputo se enfoca en el contexto y los requisitos del sistema, sin considerar su estructura o procesamiento. El punto de vista independiente de plataforma se enfoca en las capacidades operacionales del sistema fuera del contexto de una plataforma específica, mostrando sólo aquellas partes de la especificación completa que pueden ser abstraídas de la plataforma. El punto de vista dependiente de plataforma agrega al punto de vista independiente los detalles relacionados con la plataforma específica. Una plataforma es un conjunto de subsistemas y tecnologías que proveen un conjunto coherente de funcionalidad por medio de interfaces y patrones de uso. Los clientes de una plataforma hacen uso de ella sin importarles los detalles de implementación. Estas plataformas pueden ser sistemas

operativos, lenguajes de programación, bases de datos, interfaces de usuario, soluciones de middleware, etc.

• Independencia de Plataforma. Cualidad que un modelo puede exhibir cuando es expresado independientemente de las características de otra plataforma.

• Modelo de Plataforma. Describe un conjunto de conceptos técnicos de una plataforma, representando sus elementos y los servicios que provee. También especifica las restricciones en el uso de estos elementos y servicios por otras partes del sistema.

• Transformación de Modelos. Proceso de convertir un modelo a otro dentro del mismo sistema. Una transformación combina el modelo independiente de plataforma con una definición de otra plataforma, para producir un modelo específico a una plataforma correspondiente a un punto de vista del sistema, como interfaz de usuario, información, ingeniería, arquitectura, etc.

Elementos de MDA

La clave para una integración e interoperabilidad exitosa reside en el uso y administración inteligente de los metadatos en todas las aplicaciones, plataformas, herramientas y bases de datos. Para todos estos el concepto de negocio de un cliente es el mismo, la definición del cliente no cambia sin importar la plataforma, aplicación o herramienta. Los estándares principales de MDA (UML, MOF, XMI y CMW) son la base para construir esquemas coherentes para crear, publicar y administrar modelos en una arquitectura dirigida por modelos, sin importar el tipo de sistema que se va a construir. La figura 1 ilustra la arquitectura de MDA. (Ver Figura 1) • Meta Object Facility (MOF). MOF es un lenguaje común y abstracto para la especificación de meta-modelos, que sirve como un modelo común para UML y CMW. MOF es una arquitectura de metamodelos de cuatro capas. La especificación de MOF provee: i) Un modelo abstracto de los objetos y sus relaciones; ii) un conjunto de reglas para mapear un metamodelo a interfaces independientes del lenguaje; iii) reglas definiendo el ciclo de vida, composición y semántica de los modelos basados en MOF; iv) una jerarquía de interfaces reflexivas definiendo operaciones genéricas para descubrir y manipular las propiedades de los meta-modelos basados en MOF. • Common Warehouse Metamodel (CWM). Es un meta-modelo que especifica interfaces que pueden ser usadas para habilitar el intercambio de metadatos de almacenes de datos e inteligencia de negocio, entre distintas herramientas, plataformas y metadatos en ambientes heterogéneos y distribuidos de almacenes de datos. CMW se basa en tres estándares: MOF, UML y XMI. Los modelos CMW permiten a los usuarios rastrear el linaje de los datos, mediante objetos que describen de donde vienen los datos y cuándo y cómo se crearon los datos.

Mike Armas colabora como consultor e instructor en Milestone Consulting, empresa especializada en la capacitación práctica y consultoría en modelado de sistemas con UML, BPMN y SysML. Milestone participa como la primer empresa mexicana miembro de la OMG desde hace varios años. info@milestone.com.mx www.milestone.com.mx

28 26

NOV-ENE 2010

www.sg.com.mx

Figura 1. Arquitectura de MDA

• Unified Modeling Language (UML). El Lenguaje de Modelado Unificado (UML) sirve como notación base para la definición de CMW. Dado que UML utiliza una definición precisa, a partir de sus modelos visuales se pueden realizar traducciones automáticas a otros lenguajes formales.

• XML Metadata Interchange (XMI). Estándar que mapea el MOF al estándar de XML del World Wide Web Consortium. XMI define como los tags de XML se usan para representar en XML modelos serializados que cumplan con el estándar de MOF. Esto facilita el intercambio de modelos entre diversos modelos y herramientas.

Modelos MDA

MDA especifica tres modelos básicos de un sistema, correspondientes a los puntos de vista expresados anteriormente. Estos modelos pueden verse como niveles de abstracción donde en cada nivel pueden construirse varios modelos • Modelo Independiente de Cómputo. Al modelo independiente de cómputo (Computation Independent Model o CIM) se le conoce como

www.sg.com.mx

el modelo del dominio o del negocio, por que se modela en términos familiares a los expertos del negocio, representa exactamente lo que se espera del sistema, sin contemplar toda la información relacionada con la tecnología con el objetivo de mantenerse independiente de cómo será implementado el sistema. Este modelo salva el abismo existente entre los expertos del negocio y los responsables de las tecnologías de información. En una especificación MDA el modelo CIM debe ser rastreable a las construcciones que lo implementan ya sean independientes o específicas a una plataforma.

• Modelo Independiente de Plataforma. El modelo independiente de plataforma (Platform Independent Model o PIM) exhibe un grado de independencia tal que permite mapearlo a una o varias plataformas, Esto se logra definiendo una serie de servicios abstrayéndolos de los detalles técnicos para que otros modelos especifiquen cómo será la implementación.

• Modelo Específico de Plataforma. El modelo específico de plataforma combina la especificación de un PIM con los detalles para indicar como el sistema usa una plataforma en particular.

NOV-ENE 2010

29 27

El Proceso MDA

Un sistema complejo puede incluir varios modelos relacionados entre sí, organizados a través de varios niveles de abstracción, con mapeos definidos de un conjunto de modelos hacia otro y que pueden incluir: • Un CIM que contenga todas las reglas del negocio definidas en el modelo del proceso de negocio.

• Un PIM que defina el modelo conceptual completo con todas sus relaciones.

• Uno o varios PSM para generar componentes de ejecución y pruebas del sistema.

La idea básica de MDA, más allá de los modelos CIM/PIM/PSM, es utilizar los dos conceptos clave: Modelo y Transformación.

El primer paso es construir un modelo conceptual (PIM) expresado en UML, el cual será transformado hacia varios PSM. Las figuras 2 a 6 muestran el ejemplo de cómo un PIM se transforma en varios PSM, uno para el modelo de datos, otro para las interfaces distribuidas y otro para las clases de implementación. Estas transformaciones de un PIM en varios PSM pueden realizarse las veces que se requiera. Si se hacen cambios al modelo conceptual se pueden regenerar los PSM automáticamente. En el sitio web de MDA (www.omg.org/mda) se puede encontrar una lista de herramientas capaces de realizar estas transformaciones.

Figura 4. Capa de Descripción de Datos

Figura 5. Modelo Session Bean

Figura 2. Modelo Conceptual

Figura 6. Modelo C#

Pensando en la Transición

Figura 3. Transformaciones MDA

30

NOV-ENE 2010

Moverse de un enfoque tradicional de desarrollo de software a uno dirigido por modelos no es sencillo, requiere de un proyecto formal con planeación, patrocinadores y recursos. El esfuerzo es importante, pero las ventajas son muchísimas. La promesa de la arquitectura dirigida por modelos es facilitar la creación de modelos y transformaciones automáticas, buscando flexibilidad a largo plazo en términos de: Obsolescencia tecnológica: Nueva infraestructura puede ser incorporada y soportada fácilmente por los diseños existentes.

Portabilidad: Funcionalidad existente se puede migrar a nuevos ambientes y plataformas Productividad: La generación automática de los PSM acelera el desarrollo Integración: Los puentes de integración entre sistemas pueden realizarse usando modelos y transformaciones.

Calidad: Existen modelos ejecutables de UML, con los cuales los modelos pueden probarse antes de la implementación. Lockheed Martin Aeronautics realizó este tipo de pruebas con el software de misión del F16. www.sg.com.mx

Tomando la Temperatura de UML Pasado, Presente y Futuro Por Ivar Jacobson

Este artículo fue traducido y editado por SG con permiso del autor.

La versión original se encuentra en http://bit.ly/77N0eJ

M

ás de doce años han pasado desde que el Lenguaje de Modelado Unificado (UML) se convirtió en un estándar. Durante esos años, la percepción de UML ha variado desde las alturas del cielo hasta las profundidades de la tierra.

A inicios de los 1990s existían 26 métodos publicados para orientación a objetos, la mayoría de ellos con su propia notación. UML fue creado para buscar resolver por lo menos el problema de la notación. Como la mayoría de ustedes sabe, Grady Booch, Jim Rumbaugh y un servidor iniciamos el diseño de lo que eventualmente se convirtió en UML, pero rápidamente muchas otras personas se unieron al esfuerzo y la OMG apadrinó el resultado y lo hizo público como estándar. UML rápidamente hizo superfluas al resto de las notaciones. Conforme sus notaciones se hicieron obsoletas, los métodos correspondientes también dejaron de ser usados, dejando al Proceso Unificado que había adoptado UML como base, como el estándar de facto como proceso para desarrollar software. En esos tiempos, la adopción de UML se esparció como el fuego.

Críticas y la pérdida de interés

En retrospectiva, debimos haber sabido que tal éxito inicial seguramente tendría sus consecuencias negativas, conforme las expectativas iniciales no se cumplieron. Todos esperaban que sucedieran cosas mágicas, pero después de todo UML era tan solo una notación, no una bala de plata. Para empeorar esto, las herramientas de software para modelar UML no eran buenas, algunas eran avanzadas pero difíciles de usar. Todas las herramientas fueron vendidas en exceso, haciendo creer a los compradores que la herramienta era la solución. Muchos clientes quedaron decepcionados al darse cuenta que el mero hecho de hacer diagramas en UML no mejoró mágicamente sus resultados de desarrollar software. Conforme pasó el tiempo, la adopción de UML se frenó.

UML también encontró a un grupo de detractores. Fue criticado por el mundo académico. El gran David Parnas llamó a UML el “Undefined Modeling Language” (lenguaje de modelado no definido), una crítica muy exagerada pero no infundada. La crítica dolió. www.sg.com.mx

Los líderes originales del movimiento ágil también estaban fuertemente en contra del modelado. Para ellos era el “Unnecessary Modeling Language” (lenguaje de modelado no necesario). Ellos decían “no modeles, solo programa”.

Por su parte, Microsoft no soportó inicialmente a UML, ya que a fin de cuentas apoyarlo solamente fortalecería a sus competidores. Lo que ellos hicieron fue moverse en la dirección de los lenguajes de dominio específico (Domain Specific Language, DSL).

Después del año 2003 el interés en UML bajó considerablemente.

UML definitivamente estaba perdiendo su inercia.

Regresa el interés

A pesar de todo esto, ahora encontramos que el péndulo va en la otra dirección y el interés en UML está regresando. Ya existe un buen número de herramientas buenas y fáciles de usar. La crítica por parte de la academia ha disminuido. El desarrollo ágil ha sido adoptado por empresas grandes que encuentran valor en una estrategia que combine el desarrollo ágil con el modelado “inteligente”. La gente utiliza UML aunque el escepticismo en las herramientas se mantiene; mucha gente trabaja con diagramas en pizarrones y casi no usa herramientas. Microsoft se ha dado cuenta que los lenguajes de dominio específico no reemplazan el rol de UML y que los clientes quieren usar UML, así que Microsoft ya respalda UML fuertemente.

Perspectiva a futuro

Hoy el mundo ve hacia UML con una perspectiva más balanceada. Ya no es vendido como una “bala plateada” como hace diez años. Tampoco es tan malo como los agilistas acusaron hace 5 años. Utilizado de forma adecuada, es una herramienta práctica para aumentar el nivel de abstracción del nivel del código al nivel de todo el sistema.

Ahora su uso está aumentando, pero con un mayor sentido común.

Aun así, UML se ha hecho complejo y torpe. Para el 80% de los sistemas de software, solo se requiere el 20% de UML. Sin embargo, no es sencillo encontrar un subconjunto de UML al que podamos identificar como el UML “esencial”. Debemos encontrar formas más inteligentes de usar UML. NOV-ENE 2010

31

Los Modelos como Foco del Desarrollo

La Evolución del Desarrollo de Software Por Javier Castañón

M

odel Driven Development (MDD o desarrollo dirigido por modelos) es un enfoque para la construcción de sistemas de software, cuyo foco no es la producción de programas de cómputo, sino la creación de modelos, a partir de los cuales se generan los programas. Para contextualizar la descripción, es importante tener en mente que MDD pretende mejorar el desarrollo de software mediante un avance en el plano de tecnologías de programación, no se centra en procesos o métodos de desarrollo.

[Nota del editor: Este artículo se enfoca en la visión de MDD de tener modelos ejecutables o transformables a código. Por lo tanto, aquellas estrategias que no se basan en modelos ejecutables, como “Agile Model Driven Development” o “Domain Driven Development” están fuera del contexto.]

MDD parte de la idea de que se ha dado una evolución en el nivel de abstracción utilizado para desarrollar software, acercándose cada vez más a representaciones familiares para los humanos, o dicho de otra manera utilizando abstracciones de más alto nivel. El objetivo es abstraerse de los detalles técnicos de la plataforma, lo que ayuda a incrementar la productividad de los desarrolladores, por ejemplo: lenguaje de alto nivel vs. lenguaje ensamblador vs. lenguaje máquina. Desde la perspectiva de MDD, el siguiente paso en este “proceso evolutivo” es generar código a partir de modelos que faciliten la especificación, comprensión, desarrollo y mantenimiento del software. Lo anterior gracias a la utilización de: 1) abstracciones más cercanas al dominio del problema que se quiere resolver y 2) modelos independientes de la tecnología, los cuales son menos susceptibles de ser afectados por cambios en la tecnología. En MDD la reutilización no ocurre en los componentes de software generados, sino en el conocimiento inmerso en el propio modelo, el cual es compartido entre diferentes equipos de trabajo o productos.

Como ya se dijo, los modelos son el elemento esencial de MDD. En general, un modelo

es una representación simplificada de algo que puede o no existir, y por tanto puede utilizarse para especificar, describir o manipular algo de una manera más conveniente.

Para que un modelo pueda ser interpretado por la computadora, debe contener significados precisos, lo cual se consigue al utilizar lenguajes de modelado con sintaxis, semántica y notación bien definidas. El lenguaje de modelado está descrito a su vez por medio de un meta-modelo creado por un metalenguaje, y así sucesivamente hasta que el meta-modelo de un lenguaje esté descrito en el propio lenguaje. Esto explica la tremenda complejidad de la especificación de UML 2.x comparada con la relativa sencillez de la versión 1.x, pues la versión 2.0 del lenguaje cubre estas formalidades.

Características de un modelo

Un buen modelo debe cumplir las siguientes características: • Abstraer para incluir lo esencial y omitir los detalles irrelevantes.

• Ser facil de entender, para que pueda ser una herramienta de comunicación efectiva.

• Ser preciso, representando fielmente el dominio del problema.

• Ser predecible, haciendo posible predecir cómo se comportará.

• No menos importante, un modelo debe ser económico en su creación.

Una vez que un sistema ha sido especificado con un conjunto de modelos, éstos son trans-

formados ya sea en otros modelos intermedios o directamente en código. Dependiendo del tipo de transformación, existen limitantes claras: si sólo se generaron plantillas de código a partir del modelo, lo más probable es que el modelo deje de utilizarse, pues generalmente en un proyecto nunca sobran los recursos para mantener “documentación”. Si la herramienta utilizada tiene capacidades de ingeniería inversa, es posible que el modelo también termine abandonándose cuando la complejidad del código impida que éste pueda convertirse nuevamente en parte del modelo después de haberse modificado manualmente el código. Por ello, una herramienta MDD moderna debería generar programas completos no sólo fragmentos o plantillas de código. Al llegar a este punto, el lenguaje de modelado se ha convertido efectivamente en un lenguaje de programación.

Diversidad y retos en MDD

Las aproximaciones a MDD no son homogéneas. Por lo que respecta a lenguajes de modelado, hay una escuela de pensamiento que afirma que deberían preferirse lenguajes específicos de dominio o DSL por sus siglas en inglés (Domain Specific Language). En contraparte hay otra corriente que piensa que lo mejor es utilizar un lenguaje de modelado de propósito general con la capacidad de extenderse con abstracciones propias de un dominio, como es el caso de UML. Igualmente existen soluciones heterogéneas en la búsqueda de una estrategia efectiva para conseguir una adecuada separación de intereses (separation of concerns). Algunos enfoques promueven el uso de un conjunto fijo de perspectivas, en tanto que otros han desarrollado técnicas denominadas “Modelado Orientado a Aspectos”.

La generación de código a partir de modelos, no se da sin sus problemas. Uno muy

Javier Castañón es un profesional de TI interesado en temas de ingeniería de software. Las opiniones expresadas por él son exclusivamente personales. @javier_castanon

30 32

NOV-ENE 2010

www.sg.com.mx

Referencias [1] Huy N. Pham, et. al. “Applying Model-Driven Development to Pervasive System Engineering.” Proceedings of the 1st International Workshop on Software Engineering for Pervasive Computing Applications, Systems, and Environments Vol. 7.

IEEE Computer Society, 2007.

[2] France, Robert, & Bernhard Rumpe. “Model-driven Development of Complex Software: A Research Roadmap.” 2007 Future of Software Engineering. IEEE Computer Society, 2007.

[3] Bran Selic. “The Pragmatics of Model-Driven Development.” IEEE Software, Vol. 20 No. 05.

[4] Jack Greenfield, et al. Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools. Wiley, 2004.

[5] Stephen J. Mellor, et al. MDA Distilled. Addison-Wesley Professional, 2004.

[6] MSDN - Software Factories. http://bit.ly/1Qs9iY [7] Autores varios. “Patterns: Model-Driven Development Using IBM Rational Software Architect”. IBM Redbooks. http://bit.ly/ixgyJ

importante es la rastreabilidad (traceability).

Cuando ocurre un problema en el código generado, puede ser muy complicado encontrar qué parte del modelo debe corregirse, y más complicado corregir código generado que no se comprende. Se requiere el equivalente de profilers y debuggers para los modelos, y éstos deberían poder iniciarse, pausarse, detenerse para observar con detenimiento su ejecución. Otro problema es la eficiencia del código generado, ya sea vista en términos de desempeño, escalabilidad, uso de recursos, etc. por lo que una buena herramienta MDD debería permitir la integración transparente de fragmentos de código escritos manualwww.sg.com.mx

mente para resolver puntos críticos. Esto es el equivalente a escribir rutinas en lenguaje C o ensamblador e incorporarlas en programas escritos en otros lenguajes.

to a MDD. Entre ellas KerMeta (http://bit. ly/3HHvuC), ATL (http://bit.ly/fUK79), ModelPro (http://bit.ly/3pQbHs). y AndroMDA (http://bit.ly/4724jn).

MDD en práctica

Conclusión

Dos de las iniciativas MDD con más visibilidad son Model Driven Architecture (MDA) del OMG y Software Factories de Microsoft.

Un elemento crucial que las diferencia es que MDA busca la independencia de la plataforma mientras que Software Factories no.

Existen herramientas de código abierto y libre que permiten tener un acercamien-

Aún si MDD siguiese como hasta ahora, sin adoptarse de manera generalizada, las lecciones aprendidas durante su desarrollo pueden resultar valiosas para enfrentar la complejidad del software. O tal vez ocurra lo mismo que con otros generadores de código: los compiladores, cuestionados tras su introducción algunas décadas atrás, se han convertido en una tecnología cotidiana.

NOV-ENE 2010

31 33

// PRÁCTICAS

/*USABILIDAD*/

La Usabilidad en Comunidades Virtuales y Redes Sociales Evaluando la Experiencia de Usuario Por Beatríz Rios, Luis Rodríguez, Luis Joyanes

Desde los años 70 cuando el concepto de “usabilidad” comenzó a utilizarse hasta hoy, se ha consolidado como una disciplina imprescindible en el proceso de desarrollo de software y de hardware. Tan es así, que es considerada como un factor estratégico de las empresas tecnológicas y de comercio electrónico.

de tecnologías que permite agilizar la interacción entre el navegador y el usuario. Proporcionar una interfaz moderna, dinámica y ágil es de suma importancia, pero lo es más evitar los envíos y peticiones al servidor sin antes verificar que los datos a enviar en los formularios, son correctos.

La usabilidad como rama de interacción persona-computadora ha adquirido un lugar en el diseño web gracias a la legislación de los gobiernos, pues exigen implementar sitios que sean “accesibles y usables”. Ahora es imprescindible cumplir con las pautas y recomendaciones de la W3C (World Wide Web Consortium) en el desarrollo de sitios web.

Técnicas de evaluación de la Usabilidad

Estas leyes consideran no solo la accesibilidad al sitio, sino a sus “contenidos”, es en este sentido donde la usabilidad toma su importancia: la facilidad de uso, una interfaz sencilla y la eficiencia en los servicios que proporciona.

Algunos de los términos mencionados están muy unidos y son complementarios, aunque no son equivalentes. Al cumplir requisitos de accesibilidad y usabilidad básicos en los elementos técnicos de una web como: estructura de contenidos, vínculos, contraste de color, efectos y movimientos, formularios, tablas, etc., se mejoran las condiciones de uso para la mayor parte de las personas.

Usabilidad en la Web 2.0 La Web 2.0 nace de la propia acción social en interacción con un contexto tecnológico nuevo y se caracteriza por ofrecer una interfaz especialmente ágil y flexible, en un conjunto de servicios y aplicaciones como: Weblogs, la llamada Folksonomía: como Flickr, Youtube, MySpace, Facebook, Hi5, menéame, Digg, Twitter, etc. Todas ellas tienen un común denominador: la tecnología AJAX. La principal característica de la nueva Web 2.0 muestra una combinación creativa

Para desarrollar una plataforma capaz de satisfacer adecuadamente los requerimientos de los usuarios se necesita un gran equipo de desarrollo, pero sobre todo de profesionales especialistas en diseño de presentaciones que cubran todos los aspectos relacionados con la accesibilidad y usabilidad de un sitio de esta naturaleza.

Existen diversas técnicas de evaluación de la usabilidad, algunas de ellas son: • Prototipado temprano (Early prototyping) • Guías de diseño o directrices (Guidelines) • Evaluación heurística (Heuristic evaluation) • Diseño iterativo (Iterative design) • Métricas • Navegación • Observación • Cuestionarios • Encuestas • Testeo de usuarios • Benchmarking

Factores clave a evaluar en la usabilidad De acuerdo a las técnicas seleccionadas se puede evaluar el grado de usabilidad en los sitios, sin embargo la métrica elegida determinará en gran medida los resultados esperados. Aunque no todo depende de la técnica usada sino también de otros factores como son:

Beatríz Ríos Velázquez Catedrática del Instituto Tecnológico de San Luis Potosí, México. Maestra en Ciencias de la computación, Doctoranda en Ingeniería Informática en Ing. Software por la Universidad Pontifica de Salamanca en Madrid. Actualmente se encuentra realizando investigación para el desarrollo de su tesis doctoral en TI, Web 2.0, Redes sociales, Usabilidad y Empresas 2.0. beatriz.rios@live.com

34

NOV-ENE 2010

www.sg.com.mx

“La nueva Web 2.0 muestra una combinación creativa de tecnologías que permiten agilizar la interacción entre el navegador y el usuario”.

La etapa en que se utiliza Al plantear el proyecto, en la fase de análisis se puede utilizar “prototipado temprano”. Durante el desarrollo se podría aplicar “diseño iterativo” y ya en la etapa post-diseño se puede recurrir a la técnica de “testeo de usuarios”.

La parte de la página en la que se utiliza Dentro del mapa del sitio web (site map) existen elementos clave que determinarán el grado de usabilidad dentro de todo el contexto. También existirán partes en las que aparezcan vínculos a otras páginas. La homogeneidad es muy importante en el diseño, pero además la eficiencia en la respuesta es un factor a considerar. Por ejemplo, la administración y gestión en el acceso y autenticación de usuarios, es una de las partes más importantes y que deberían de ser evaluadas con técnicas desarrolladas específicamente para la parte de administración.

El objetivo que se desea conseguir en la parte que se evalúa Si la parte que se evalúa debe permitir realizar una tarea en un tiempo corto, que no implique el llenado de un formulario o la petición de datos de entrada con un límite de duración, se deberá considerar una técnica que contenga los parámetros exactos para esa petición.

a obtener la mejor experiencia del usuario, algunos de ellos son: • Dimensiones de usabilidad según ISO 9241-11 • Aceptación del producto según Nielsen • Aceptación del producto según Sackel • End-User Computing Satisfaction Instrument (EUCSI) • Technology Acceptance Model (TAM) • Software Usability Measurement Inventory (SUMI) • Post-Study System Usability Questionnaire (PSSUQ) • El cuestionario por satisfacción de la interacción del usuario (QUIS)

Test de usuarios Con el propósito de lograr la usabilidad óptima en el diseño de interfaz de usuario durante el desarrollo de un producto, se siguen los procesos del ciclo de vida de la ingeniería de la usabilidad, donde la realización del test con usuarios es una parte muy importante. Testeo con usuarios, card-sorting, personajes, prototipado, técnicas de analítica Web, son algunas de las técnicas para mejorar la usabilidad de un sitio Web. “Un test de usabilidad es una medida empírica de la usabilidad de una herramienta, sitio o aplicación, tomada a partir de la observación sistemática de usuarios llevando a cabo tareas reales”. (Mercovich, 1999)

El público objetivo al que está dirigido Es muy común que los usuarios no utilizan todas las potencialidades de un sitio web simplemente porque no saben que existen ni para que sirven. Si los usuarios a los que está dirigido el sitio saben exactamente lo que pueden y no pueden hacer dentro del sitio, sacarán mejor provecho de él.

El test de usabilidad de un sitio, permitirá: • Verificar la existencia de problemas de usabilidad en el sitio.

• Encontrar soluciones para los problemas encontrados.

• Establecer una medida inicial contra la cual comparar a los competidores, futuros desarrollos o modificaciones al sitio actual.

El objetivo fundamental es detectar problemas de diseño de interacción para poder corregirlos.

Métodos de obtención de resultados

Registro de usuarios

Para conseguir mejores resultados al aplicar la ingeniería de usabilidad al sitio, se deben considerar las técnicas de evaluación en conjunto con los métodos de obtención de resultados enfocados

Actualmente el registro de usuario aparece en casi la mayoría de los sitios Web, como un servicio opcional y completamente gratuito como usuario de la página, permitiendo que elija su nombre de

Dr. Luis Rodríguez Baena Profr. Lenguajes y Sistemas Informáticos e Ingeniería de Software, Experto en temas de usabilidad y testeo con usuarios, en la Universidad Pontificia de Salamanca en Madrid. http://bit.ly/8C1NGt, luis.rodriguez@upsam.net

www.sg.com.mx

NOV-ENE 2010

35

// PRÁCTICAS

/*USABILIDAD*/

usuario y contraseña, para poder usar servicios como: publicaciones, tutoriales, ligas a sitios de interés, descargas gratuitas, subir, bajar, cargar fotos, videos, películas, etc., enlaces privados del sitio, envío de comentarios y aportaciones, envío y recibo de mensajes, usar las aplicaciones del sitio, suscripción a boletines electrónicos. Y aunque en ocasiones el registro no es obligatorio, el hacerlo permitirá al usuario ampliar el abanico de posibilidades de operación y buen uso de los recursos que el sitio proporciona.

Formularios

Los campos en los registros de usuario de los formularios no están optimizados para los servicios, contenidos y acciones que se ofrecen por lo que es posible mejorar la experiencia de usuario en los formularios de registro cuando se mejore la usabilidad.

Objetivo principal Evaluar la experiencia de usuario a partir del acceso y registro de usuarios en comunidades y redes sociales en Internet según metodologías de usabilidad.

“Un formulario usable es un formulario que será sin dudas completado y enviado con éxito.” (Cabrera, 2004) Para el usuario el acceso a la web incluye dentro de muchas otras cosas, la interacción con la captura de información particular. Los formularios son uno de los principales puntos de contacto de los usuarios en internet. Se tiene que cuidar mucho su diseño, ya que si se aplican reglas inadecuadas, se provocará una gran frustración y malestar en los visitantes y lo más grave, el abandono súbito para nunca desear volver.

Desarrollo de la investigación Con el objetivo de poder determinar el grado de la usabilidad en los formularios de comunidades virtuales y redes sociales y contribuir a proporcionar datos verídicos en un escenario real, se ha desarrollado una investigación con usuarios reales, estudiantes de Informática básica, en una ONG (Organización No Gubernamental) en España, donde acude una gran diversidad de estudiantes, de género, edad, cultura, nacionalidad, niveles educativos y distintas habilidades, que han ayudado a determinar la población objetivo y muestra.

Basados en la experiencia docente, atendiendo un número de estudiantes en el centro, se experimenta que: • El acceso en el registro de usuarios y la administración para el trámite de servicios a través de un sitio, no siempre satisface las recomendaciones de usabilidad.

• En redes sociales, algunos de los registros con formato restringen el acceso inmediato a los contenidos y a otro tipo de usuarios.

• Los procesos que conllevan la entrada de datos son los que mayores problemas causan a usuarios inexpertos.

• La disposición de los campos de entrada de datos, sus etiquetas y la información solicitada no siempre es la más adecuada.

Imagen 1. Ejemplo de formulario de registro

Metodología • Se analizaron las comunidades y redes sociales más populares.

• Se analizaron distintos tipos de sitios web y los tipos de procesos de entrada de datos que utilizan.

• Se analizaron distintos tipos de formularios comunes en el ámbito de redes sociales, sus campos, etiquetas, lenguaje, y validaciones para asegurar la usabilidad.

Luis Joyanes Aguilar Dr. Ingeniería Informática, Dr. Sociología, Lic. Ciencias físicas, Lic. Enseñanza superior militar y Dr. Honoris y causa por la Universidad Antenor Orrego de Trujillo (Perú). Catedrático, Ex-Decano de la facultad de Informática y Director del departamento de posgrado de la Universidad Pontificia de Salamanca en Madrid. Profesor del posgrado de sociología en Guatemala, Universidad de Oviedo, Complutense y Politécnica, en España. Ha publicado más de 40 libros y 80 artículos sobre tecnologías de la Información y diversos lenguajes de programación. http://bit.ly/1pyvUx luis.joyanes@upsam.net

36

FEB-ABR NOV-ENE 2009 2010

www.sg.com.mx

“Si se aplican reglas inadecuadas se provocará una gran frustración y malestar en los visitantes”.

• Se evaluaron y seleccionaron diversas técnicas a utilizar para la obtención de mejores resultados. En base a las técnicas estudiadas, se seleccionó una muestra tomando en cuenta los factores clave para evaluar la usabilidad y la técnica utilizada.

• Las distintas pruebas que se usaron fueron: - Análisis de 60 pautas para formularios usables - Comparativa Benchmark - Evaluación heurística - Test de usuarios - Cuestionario post-test Selección de la población y la muestra: Se seleccionaron 2 comunidades virtuales, eligiendo sitios de registro y acceso gratuito a correo electrónico, 2 de los gigantes mas competidos: Yahoo y Gmail.

En el ámbito de las redes sociales, se evaluaron 3 de ellas, se seleccionaron de acuerdo a las estadísticas de las más accedidas y populares. En este apartado es importante aclarar que por cuestiones de nacionalidad se eligieron las redes más accedidas en nuestra región: MySpace, Facebook y Hi5.

La edad promedio de los participantes fue de 20 años, la nacionalidad fue en su mayoría de Sudamérica y de España, el nivel promedio de estudios fue de Bachillerato, y la experiencia con ordenadores fue casi nula.

El servicio de correo de Yahoo! salió mejor evaluado, porque los datos a llenar fueron pocos y muy sencillos de comprender, la sesión no caduca, y las letras de seguridad son legibles.

De las redes sociales evaluadas, MySpace y Facebook fueron evaluadas satisfactoriamente, pero fueron rebasadas por mucho por Hi5, donde se encontraron muy pocos fallos por usuarios inexpertos.

Conclusiones El avance vertiginoso de las nuevas tecnologías enfocadas a ofrecer una gran variedad de aplicaciones a los nuevos perfiles de usuarios de la Web 2.0, obliga a los diseñadores realizar productos orientados a satisfacer las necesidades de todo tipo de usuarios, pero sobre todo garantizará mayor éxito si el diseño se orienta al usuario más inexperto de forma tal, que si ellos son capaces de completar la tarea, cualquiera lo hará.

Referencias [1] Eduardo Mercovich. “Cómo hacer un test de usabilidad de un sitio” http://bit.ly/4t55Vk [2] Javier Cabrera. “Formularios Usables”. http://bit.ly/5JHYVg Más referencias en http://delicious.com/RevistaSG/usabilidad

Resultados finales

Resultados Los resultados concluyeron que Gmail, aunque tiene más aspecto de diseño de Web 2.0, no satisface la usabilidad por completo. Tiene más puntos a mejorar. Un problema común fue que en los captcha para evitar registro automatizado los caracteres son ilegibles y no permiten pasar al siguiente punto fácilmente. Los fallos se dieron principalmente en: • Libertad y control de parte del usuario • Prevención de errores • Flexibilidad y eficiencia en el uso • Ayudar al usuario a reconocer, diagnosticar y recuperarse de los errores.

Aunque el servicio de correo Gmail es en la actualidad muy utilizado, requiere que los usuarios sean expertos para poder aprovechar todas las facilidades que provee, a diferencia del que mejor evaluado ha salido. Podemos concluir que Gmail está dirigido a usuarios con un mayor nivel de estudios y habilidades informáticas para poder aprovechar mejor los recursos que provee.

www.sg.com.mx

Servidor correo Yahoo

Porcentaje Acierto: 96,15% Porcentaje Error: 3,85%

Servidor correo Gmail

Porcentaje Acierto: 80,77% Porcentaje Error: 19,23%

Red social MySpace

Porcentaje Acierto: 96,15% Porcentaje Error: 3,85%

Red social Facebook

Porcentaje Acierto: 76,92% Porcentaje Error: 23,08%

Red social Hi5

Porcentaje Acierto: 100% Porcentaje Error: 0%

Tabla 1.0 Resultados finales

FEB-ABR NOV-ENE 2009 2010

37 35

// PRÁCTICAS

/*GESTIÓN DE DATOS*/

Combinación de Datos El uso de JOIN y los Conjuntos de Datos por Ricardo Rangel

Para obtener información de una base de datos relacional frecuentemente se requiere combinar registros que se encuentran en tablas diferentes. Cualquier persona con conocimientos de SQL sabe que esto se logra por medio de la instrucción JOIN. Sin embargo, el verdadero potencial de esta instrucción se alcanza cuando nos damos cuenta de que los JOINS no solamente pueden combinar tablas, sino que son capaces de combinar conjuntos de datos.

denominado ConjuntoD, y unirlos mediante su campo en común (Campo1).

SELECT TablaA.Campo1, ConjuntoD.Campo2 FROM TablaA LEFT JOIN (SELECT B.Campo1, B.Campo2 FROM TablaB INNER JOIN TablaC on TablaB.Campo1=TablaC.Campo1) AS ConjuntoD ON TablaA.Campo1 = ConjuntoD.Campo1

En este artículo daremos un vistazo a cómo se puede aplicar esta instrucción para realizar consultas que combinan conjuntos de datos diversos.

Ejemplo 3. Combinación de tablas y conjuntos de datos

Un breve repaso

Como pueden apreciar, en este ejemplo estamos combinando los datos de Tabla A con los elementos de ConjuntoD, que a su vez es una combinación de los datos de las tablas B y C.

Antes de proseguir, recordemos la estructura básica de una sentencia JOIN. La sentencia del ejemplo 1 nos permite obtener todos los datos de la TablaA, combinados con los datos de la TablaB, unidos por medio del CampoX, el cual se encuentra disponible en ambas tablas. En esta sentencia hacemos un INNER JOIN, que es el tipo más común.

SELECT * FROM TablaA INNER JOIN TablaB ON TablaA.CampoX = TablaB.CampoX

Ejemplo 1. Join básico

Combinando conjuntos de datos En este contexto, nos referimos a un conjunto de datos como una consulta de una o varias tablas a la que se puede acceder como si fuera una sola entidad. Podemos crear un conjunto de datos en SQL y bautizarlo con un alias para poder referirnos a él. El ejemplo 2 muestra como obtener un conjunto de datos y asignarle un alias.

SELECT * FROM (SELECT Campo1 + ‘.’ + Campo2 as AliasCampo FROM Tabla) AS AliasTabla WHERE AliasTabla.AliasCampo=X

Ejemplo 2. Uso de alias Ahora veamos una aplicación de alias y joins. Vamos a combinar los registros de una tabla (TablaA) con los elementos de un conjunto

Una necesidad común para utilizar JOINS es cuando generamos reportes de detalle donde toda la información necesaria se debe mostrar en una sola pantalla. Lo que no sabe la persona que lo solicita, es que toda esta información se encuentra dispersa por toda la base de datos y que para presentarla junta es necesario combinar varios conjuntos de datos.

El ejemplo 4 muestra como combinar información de dos conjuntos.

SELECT ConjuntoA.Campo1, ConjuntoB2.Campo1 FROM (SELECT Campo1, Campo2 FROM TablaA WHERE Campo1=X) AS ConjuntoA LEFT JOIN (SELECT * FROM (SELECT Campo1, Campo2 FROM TablaB) AS ConjuntoB) as ConjuntoB2 ON ConjuntoA.Campo1 = ConjuntoB2. Campo1

Ejemplo 4. Combinación de conjuntos

Ricardo Rangel Ramírez es Licenciado en Informática egresado de la Universidad de Ecatepec y cuenta con cinco años de experiencia desarrollando Software en plataforma .Net para varias empresas. Actualmente trabaja en el Departamento de Sistemas de Stanhome de México y en un proyecto independiente para Internet. Sus principales habilidades son la Gestión y Explotación de Información, el Análisis, Diseño y Desarrollo de Sistemas, así como la automatización de Procesos en Bases de Datos. riccardorangel@hotmail.com

38

NOV-ENE 2010

www.sg.com.mx

“Cuando toda la información se encuentra dispersa, es necesario combinar varios conjuntos de datos”.

El campo en común entre ambos conjuntos de datos es Campo1. Nótese como se tuvieron que crear dos alias para el ConjuntoB. Esto es necesario cuando unimos dos conjuntos de datos y necesitamos hacer referencia a algún campo en particular como en el caso de ConjuntoB2.Campo1

Combinando sin tener un campo en común Bien, ya hemos dicho que se pueden unir tablas o conjuntos de datos por medio de un campo en común, pero ¿qué pasa si necesitamos juntar información que no tiene ningún campo en común? Lo que debemos de hacer es crear un campo ficticio que nos ayude a unir las cosas, en este caso crearemos un campo llamado Conexión con un valor de 1.

SELECT ConjuntoA.Campo1, ConjuntoA.Campo2, ConjuntoB2.Campo3, ConjuntoB2.Campo4 FROM (SELECT Conexion=1, Campo1, Campo2 FROM TablaA WHERE Campo1=X) AS ConjuntoA LEFT JOIN (SELECT * FROM (SELECT Conexion=1, Campo3, Campo4 FROM TablaB) AS ConjuntoB) as ConjuntoB2 ON ConjuntoA.Conexion = ConjuntoB2.Conexion

Ejemplo 5. Combinación forzada por un campo ficticio Como se podrán imaginar, es necesario que nuestro campo Conexion tenga el mismo valor en ambos conjuntos de datos para que funcione.

De esta forma podemos unir fácilmente información muy distinta una de otra, por ejemplo al unir información de Ventas con Gastos.

www.sg.com.mx

Combinando bases de datos diferentes ¿Qué pasa cuando nos solicitan un reporte con información que se encuentra en bases de datos diferentes?

La mayoría de los motores de base de datos cuenta con mecanismos para poder conectarse a otras bases de datos, incluso con manejadores diferentes (Ej: SQL Server hacia Oracle o MySQL).

El ejemplo 6 muestra como hacer un join desde una base de datos en SQL Server hacia una base de datos externa utilizando la instrucción OPENDATASOURCE. Notarán que estamos enviando el user/password como parte del string de conexión, lo cual no es una buena práctica, pero para los fines de este artículo no hay problema.

SELECT TA.Campo1, TB.Campo2, TB.Campo3 FROM TablaA TA INNER JOIN OPENDATASOURCE(‘SQLOLEDB’,’DataSource=.;User ID=sa;Password=’).BaseDeDatos.DBO.TablaB as TB ON TA.Campo1= tb.Campo1 WHERE TB.Campo2=X

Ejemplo 6. Combinación de tablas en bases de datos diferentes.

Conclusión Las aplicaciones de software frecuentemente requieren obtener información dispersa entre distintas fuentes. En este artículo hemos visto algunas técnicas muy útiles para manejar fuentes diversas como conjuntos de datos que se pueden combinar.

NOV-ENE 2010

37

// PRÁCTICAS

/*PROGRAMACIÓN*/

Algoritmos Paralelos Usando Plantillas Aplicación de Threading Building Blocks por Michael D’Mello y Victoria Gromova

Las plantillas de clases (class templates) son un mecanismo que permite describir tipos de datos genéricos para manejar otros tipos de datos. Por ejemplo, las “clases contenedoras” como listas, pilas y colas, permiten manejar sus contenidos de forma genérica sin importar el tipo específico de los objetos que contienen. Esta capacidad no se limita a ser utilizada en clases contenedoras, otra posibilidad es aplicarla para encapsular algoritmos de propósito general, como ciclos por ejemplo. El uso de plantillas de clases incluso se puede extender para habilitar nuestro código a ejecutarse de forma adecuada en computadoras con capacidad de procesamiento paralelo.

Threading Building Blocks es una librería de código abierto que provee plantillas para cómputo paralelo. Al usar TBB, el desarrollador representa el trabajo paralelo como un conjunto de tareas que son despachadas por la librería hacia un grupo administrado de threads (hilos de ejecución). Este artículo ilustra cómo aprovechar las plantillas de la librería TBB. Comenzamos con un simple ciclo “for” entre elementos que no tienen dependencias entre sí y luego mostramos un ejemplo más avanzado para el recorrido de un árbol binario.

Fundamentos TBB trabaja por medio de la descomposición de los programas en tareas y el mapeo de dichas tareas a un grupo de threads. Una tarea representa un rango de datos a procesarse, junto con las operaciones que se realizarán en estos datos. El tamaño de las tareas depende tanto de la cantidad de procesamiento a realizarse en cada unidad, como del número de datos que pueden procesarse juntos.

El programador rara vez tiene forma de modificar la cantidad de procesamiento en cada unidad, pero sí puede variar el número de unidades de datos que se procesan juntos y de esta forma controlar que las tareas tengan el tamaño adecuado. Es importante que esto se logre, ya que si las tareas son demasiado grandes, algunos nodos de procesamiento paralelo se usarán mucho más que los demás, lo cual es ineficiente. Por otro lado, si las tareas son de-

masiado pequeñas, también hay ineficiencia porque se desperdicia demasiado procesamiento en coordinar la ejecución de tantas tareas tan pequeñas. Para ayudar en el manejo de estos casos, la librería TBB provee al desarrollador con un mecanismo para regular el tamaño de los datos.

Por ejemplo, en el caso de un ciclo “for”, la librería permite que el desarrollador especifique un parámetro denominado grain size (tamaño de grano) que es utilizado por la librería para definir cuantas iteraciones serán repartidas entre cada hilo de ejecución. El valor ideal del grain size depende de la naturaleza del algoritmo así como la configuración del hardware, así que puede ser un cálculo complicado. Por ello, TBB provee un mecanismo llamado “autoparticionador” que dinámicamente estima el grain size y que típicamente provee resultados suficientemente buenos.

Ejemplo: ciclo sin dependencias Para los casos más sencillos de paralelismo de datos basado en ciclos, TBB provee plantillas de funciones para ayudar a convertir el código del ciclo serial a código paralelo equivalente. En este caso, la plantilla parallel_for simplemente reemplaza el ciclo serial tomando tres argumentos: el rango del índice del ciclo, una referencia a una clase definida por el usuario que contiene el cuerpo del ciclo, y un tamaño de datos o particionador. Todos los elementos necesarios para el manejo de hilos, mapeo de tareas a hilos y coordinación para la ejecución de tareas son manejadas por la librería de forma transparente para el desarrollador. Es así que los desarrolladores pueden paralelizar sus códigos al utilizar prácticas estándar de orientación a objetos.

El listado 1 muestra la implementación serial de un ciclo for. void SerialArrayProcessing (item_type* data) { for (size_t i = 0; i < item_count; ++i) { foo (data[i]); } } Listado 1. Implementación serial de ciclo for

Michael D’Mello es Ingeniero Senior de Consultoría Técnica en la división de productos para desarrolladores en Intel. Cuenta con más de 18 años de experiencia profesional, especializándose en cómputo paralelo. Es Doctor en Química por la Universidad de Texas en Austin.

40

NOV-ENE 2010

www.sg.com.mx

“Los desarrolladores pueden paralelizar sus códigos al utilizar prácticas estándar de orientación a objetos”.

En esta situación podemos utilizar el template parallel_for. Este template recibe dos parámetros: el rango o espacio de iteración, y el objeto de la función. El manejo de espacios de iteración en TBB requiere que la clase modelada implemente una interfaz con las siguientes operaciones: • bool empty(): función que regresa “true” si el rango en cuestión está vacío.

• bool is_divisible(): función que regresa “true” si el rango se puede dividir en dos mitades.

• Un constructor que toma dos parámetros: el primero es la referencia al rango y el segundo es tbb::split, un objeto capaz de dividir el rango en varias partes.

La librería TBB también provee implementaciones de espacios de iteración de 1 y 2 dimensiones, blocked_range<T> y blocked_range2d<T> respectivamente. El espacio de iteración de una dimensión puede usarse en este ejemplo para representar un rango de valores de tipo T donde T tiene el tamaño size_t de nuestro ejemplo.

El listado 6 muestra como quedaría la clase manejando sub-rangos. class Body { item_type* data; public: Body (item_type* _data) : data (_data) {} void operator() (tbb::blocked_range<size_t>& r) const { for (size_t i = r.begin(); i != r.end(); ++i) { foo (data[i]); } } }; Listado 2. Clase que modifica el ciclo para manejar sub-rangos

El operador de llamada a la clase Body depende del objeto de espacio de iteración, y en esencia contiene el cuerpo del ciclo “for” original, pero modificado para que pueda trabajar con sub-rangos.

El código de alto nivel se muestra en el listado 3. #include “tbb/task_scheduler_init.h” #include “tbb/blocked_range.h” #include “tbb/parallel_for.h” void ParallelArrayProcessing (item_type* data) { tbb::parallel_for (tbb::blocked_range<size_t> (0, item_count, grain_size), Body (data)); } Listado 3. Invocación de parallel_for

www.sg.com.mx

El parallel_for divide recursivamente en mitades el espacio de iteración dado, que en este ejemplo es el intervalo medio abierto [0, item_ count). Esto crea tareas más pequeñas que dependen de sub-rangos más pequeños. La función parallel_for divide un rango en sub-rangos hasta que sean menor o iguales a grain_size, que es el tamaño de rango de datos que el desarrollador considera óptimo. En caso que se desee usar el auto-particionador que dinámicamente estime el grain_size adecuado, nuestro código requeriría la modificación indicada en el listado 4. void ParallelArrayProcessing (item_type* data) { tbb::parallel_for(tbb::blocked_range<size_t> (0, item_count), Body (data), tbb::auto_partitioner()); } Listado 4. parallel_for con auto-partición

Para ejecutar tbb::parallel_for, el programa debe inicializar la agenda de tareas de TBB creando un objeto de tipo task_scheduler_init. El constructor default de este objeto creará un grupo de threads e inicializará las estructuras de datos internas de TBB. Es así que la función main para invocar nuestro código quedaría como en el listado 5. void main () { tbb::task_scheduler_init tbb_init; ParallelArrayProcessing (data); } Listado 5. Inicialización de TBB

Recorrido de un árbol por recursividad Los algoritmos de alto nivel que la librería TBB provee son convenientes para el desarrollador porque esconden la complejidad del manejo de tareas y threads.

El programador de tareas (task scheduler) de TBB provee una interfaz de C++ simple que puede ser utilizada para asignar, generar y combinar tareas. Con la interfaz del programador de tareas también es posible expresar un amplio rango de algoritmos. Por ejemplo, con él podemos expresar fácilmente paralelismo recursivo y anidado de forma escalable.

Para ilustrar esto, veamos el listado 6, que contiene la implementación serial para el recorrido de un árbol binario.

NOV-ENE 2010

41

// PRÁCTICAS

/*PROGRAMACIÓN*/

struct binary_tree { item_type data; binary_tree* left; binary_tree* right; }; void foo (item_type& item) { // hacer trabajo } void SerialTreeTraversal (binary_tree* root) { if (!root) return; foo (root->data); SerialTreeTraversal (root->left); SerialTreeTraversal (root->right); } Listado 6. Recorrido de árbol serial

El listado 7 tiene el código que podemos utilizar para hacer el recorrido del árbol binario de forma paralela.

Notemos primero que este algoritmo recursivo puede ser visto como un árbol de tareas. Es así que creamos una nueva clase MyRecursiveTask usando tbb::task como clase base. La clase tbb::task contiene el método virtual execute que debe ser implementado por quienes hereden esta clase base. El método execute será invocado cuando alguno de los threads ejecute la tarea que estamos manejando como objeto.

También es importante darnos cuenta que el método MyRecursiveTask conceptualmente es muy similar a la función SerialTreeTraversal que ya habíamos definido (en las ramas que no están vacías aplica la función foo a los datos almacenados en el nodo raíz de la rama y crea dos nuevas tareas MyRecursiveTask para las ramas no vacías a la izquierda y derecha). Los nuevos objetos de tarea hijos deben ser asignados por el método especial task::allocate_child. Cuando un nuevo objeto tarea es asignado, la nueva tarea se puede agendar para ejecución al invocar el método task::spawn.

Para nuestro ejemplo, una tarea crea dos tareas adicionales que agregamos a la lista tbb::task_list y luego generamos la lista de tareas invocando spawn_and_wait_for_all(list). Generar una lista de tareas típicamente brinda mejor desempeño que generar las tareas de forma individual.

42

NOV-ENE 2010

Todas las tareas de TBB son agendadas de acuerdo a su relación padre-hijo. Una tarea padre espera a sus hijos y para ello necesita saber a cuantos hijos debe esperar. Esto se logra con una llamada al método set_ref_count(count) donde “count” es el número de hijos + 1. #include “tbb/task_scheduler_init.h” #include “tbb/task.h” class MyRecursiveTask: public tbb::task { binary_tree* root; public: MyRecursiveTask (binary_tree* node): root (node) {} tbb::task* execute () { if (!root) return NULL; foo (root->data); int count = 1; tbb::task_list list; if( root->left ) { ++count; list.push_back (*new (allocate_child()) MyRecursiveTask (root->left)); } if( root->right ) { ++count; list.push_back (*new (allocate_child()) MyRecursiveTask (root->right)); } set_ref_count(count); spawn_and_wait_for_all(list); return NULL; } }; Listado 7. Implementación paralela del recorrido de árbol

El código de alto nivel que invoca a MyRecursiveTask se muestra en el listado 8. La función ParallelTreeTraversal primero invoca la versión sobrecargada (overloaded) del operador new y el método estático tbb::task::allocate_root para crear una tarea raíz. La tarea raíz es una tarea especial que no tiene padre.

Para este ejemplo, la tarea raíz es un objeto root_task del tipo MyRecursiveTask. Entonces, tbb::task::spawn_root_and_wait será llamado para iniciar la creación de nuevas tareas del mismo tipo que las ramas; esto se hace recursivamente. Antes de llamar a la función ParallelTreeTraversal, el programa debe inicializar un programador de tareas.

www.sg.com.mx

“TBB provee plantillas de funciones para ayudar a convertir el código serial a código paralelo equivalente”.

void ParallelTreeTraversal (binary_tree* root) { tbb::task& root_task = *new (tbb::task::allocate_root ()) MyRecursiveTask (root); tbb::task::spawn_root_and_wait (root_task); } void main () { binary_tree* tree = new binary_tree(); CreateATree (tree); tbb::task_scheduler_init tbb_init; ParallelTreeTraversal (tree); DeleteATree (tree); }

división de rangos continúa mientras que la raíz de la rama en cuestión no esté vacía y el sub-rango izquierdo o derecho no sea nulo. El listado 10 muestra el contenido de la clase Body. class Body { public: void operator() (MyRange& r) const { if (r.node) foo (r.node->data); } };

Listado 8. Código para invocar el recorrido paralelo

Listado 10. Clase Body

Uso de un espacio de iteración personalizado

Cuando el rango ya no se puede dividir más, MyRange::is_divisible regresa falso. El operador de la clase Body es invocado y si la hoja no es NULL entonces la función “foo” es aplicada a los datos almacenados en el nodo hoja. El listado 11 muestra el código que lo invoca.

Por default el espacio de iteración de TBB es genérico. Para el ejemplo del ciclo utilizamos el espacio de iteración tbb:blocked_range<T> pero incluso podemos ir más allá e implementar un espacio específico a un problema. Por ejemplo, el algoritmo de recorrido de árbol también se puede implementar utilizando tbb:parallel_for, sin usar recursividad explícita. El listado 9 muestra cómo se puede implementar el espacio de iteración para los nodos del árbol.

void ParallelTreeTraversal (binary_tree* root) { tbb::parallel_for (MyRange (root), Body ()); } Listado 11. Código de invocación

class MyRange { public: binary_tree* node; MyRange (binary_tree* _node ) : node (_node) {} MyRange (MyRange& r, tbb::split) : node (r.node->right) { foo (r.node->data); r.node = r.node->left; } bool empty() const { return !node; } bool is_divisible() const { return !empty() && (node->left || node->right); } }; Listado 9. Espacio de iteración para nodos del árbol

El código MyRange::MyRange (MyRange& r, tbb::split) indica un constructor divisor. Toma un rango (en este caso, una rama del árbol) y aplica la función foo a los datos almacenados en la raíz de dicha rama y la divide en dos sub-ramas. La rama derecha se asigna a el rango en cuestión, mientras que la rama izquierda se convierte en un sub-rango nuevo. La

www.sg.com.mx

Esta implementación se basa en el hecho de que la función parallel_for divide el trabajo de forma recursiva, de tal forma que la implementación no requiere utilizar recursividad de forma explícita. Utilizando espacios de iteración personalizados le permite al desarrollador controlar por completo la forma en que el trabajo se distribuye entre tareas. Esto puede ser muy útil cuando un dato acarrea información acerca de la complejidad del trabajo de sus elementos.

Conclusión Hemos ilustrado la estrategia de paralelismo basado en la descomposición de tareas para implementar un árbol binario por medio de recursión explícita y por medio de la definición de un espacio de iteración personalizado. Hemos podido hacer todo esto sin necesidad de hacer grandes cambios al código serial, gracias a los elementos provistos por la librería Threading Building Blocks. Conoce más sobre TBB en www. threadingbuildingblocks.org.

NOV-ENE 2010

43

// UML

En esta ocasión dedicamos la sección de UML a un querido colaborador que en incontables veces puso su dedicación y esfuerzo para compartir su conocimiento con todos nosotros.

Esta página permanece en blanco como tributo a la memoria de Carlos Marco Macías Medina.

Todo el equipo editorial de la revista Software Guru acompañamos a su familia y amigos en el dolor que los aflige por tan grande pérdida.

Descanse en paz:

Charlie Macías Medina

Charlie Macías es arquitecto en jefe e instructor senior en Milestone Consulting. Primer empresa mexicana miembro de la OMG, especializada en la capacitación práctica y consultoría en modelado de sistemas y negocios con UML, BPMN y SysML. Puedes contactarnos en info@milestone.com.mx www.milestone.com.mx Q.E.P.D.

44

NOV-ENE 2010

www.sg.com.mx

// COLUMNA INVITADA

Internet para Todos La Revolución que Viene

por Oscar Mondragón, Celeste North, Pedro Galván, et. al.

E

l movimiento #internetnecesario es la punta de iceberg de una auténtica revolución. El muy mencionado movimiento social vía Twitter ha conseguido probar en nuestro propio espacio político que basta el tener un sustrato organizacional de una red social para convocar y movilizar a los ciudadanos hacia un objetivo político.

Un hashtag ha podido quizás partir en dos la historia de la participación política en México. Antes se necesitaba un sindicato, un partido político, una ONG u otra forma de organización compleja y costosa para conseguir irrumpir en la escena política. Hoy queda claro que una causa valiosa para las comunidades que se entretejen en las redes sociales puede horadar su propio camino hacia los centros de decisión política del país y posicionar sus demandas en el cénit del debate nacional.

Por ello, un grupo de ciudadanos que participamos en distintas áreas de la industria de TI, queremos invitar a la comunidad a que juntos llevemos varios pasos más adelante el ímpetu de #internetnecesario, hasta su última consecuencia.

Si el acceso a internet es imprescindible para una sociedad moderna, según va el razonamiento del movimiento, la causa se quedará corta si tan sólo sirve para no cobrar impuestos al porcentaje de la población que hoy usa internet en México. #internetnecesario debe ser entonces un movimiento para garantizar acceso a internet auténticamente universal para todos los mexicanos, sin discriminadores de por medio.

La propuesta México cuenta hoy con una última red pública, la de la CFE. Dicha red sirve a casi toda la población en el país. Nuestra propuesta concreta es que esta red sea utilizada como el cimiento de una red nacional de WiMax que proporcione 1 Mbps de ancho de banda a cada ciudadano sin costo alguno.

El Estado mexicano no ha concesionado aun los rangos de frecuencias sobre los que opewww.sg.com.mx

ra WiMax. La existencia de la red de CFE y la disponibilidad pública de estas frecuencias abre una oportunidad para, como país, dar varios pasos hacia el futuro a un costo económico reducido.

Si mil antenas de WiMax pudieran cubrir la totalidad de las tres grandes urbes de México en un inicio, la inversión necesaria para ello sería de menos de la mitad de lo que el IEPS a las telecomunicaciones recaudaría en un año [1]; una ganga por donde se le vea.

El impacto Imaginar un país cubierto por una nube de WiMax a la que cada ciudadano tiene acceso sin costo alguno nos da la oportunidad de pensar en un futuro donde renace el espacio de emprendimiento e innovación que los monopolios nos han cerrado y sobre el cual podemos transitar hacia una época de mayor prosperidad. Para millones de mexicanos, poder contar con servicios de telecomunicaciones básicos a un costo de cero, representaría una oportunidad única de progreso intelectual y material.

Hay que atreverse a pensar en grande y eso es lo que está detrás de esta propuesta: la grandeza de un país donde más del 80% de la población pueda acceder a los servicios que caben dentro de 1 Mbps, como VoIP, TV de definición estándar y navegación en el web, vía inalámbrica y sin costo alguno.

Es posible especular que pronto el mercado comenzaría a ofrecer aparatos de todo tipo para acceso a la red. Veríamos teléfonos móviles que utilicen la red de Internet en lugar de las redes celulares, aparatos que replicarían las funcionalidades de una caja de televisión por cable, y las ubicuas netbooks que sin tener que cubrir el costo de acceso quedarían al alcance de millones de personas en México. Todo sin plazos forzosos, sin contratos leoninos y sin costos exhorbitantes. Es decir, México podría acabar con los efectos perniciosos de sus monopolios sin tener que tocarlos siquiera, sin litigios eternos, sin prostitución legislativa, sólo con tecnología.

Las compañías de telecomunicaciones existentes se verían entonces motivadas a ofrecer servicios de alto valor agregado. Acceso a Internet a más de 10 Mbps, TV en HD bajo demanda, aplicaciones en la nube, son tan sólo una muestra de las múltiples oportunidades de negocios que se abrirían para los actuales incumbents. México a la par de Japón en términos de acceso digital. Ninguna otra política pública tiene este alcance.

Cómo participar La propuesta completa está aun gestándose. Por el momento la estamos desarrollando por medio de un wiki disponible en: http://internetparatodos.sandino.net Es un trabajo en curso y necesitamos refinarla y enriquecerla para que pueda ser presentada a las autoridades correspondientes. Te invitamos a que te sumes a este esfuerzo y nos ayudes a hacerlo realidad.

Es necesario que ingenieros que conozcan sobre WiMax y sobre la red de CFE contribuyan los ángulos técnicos necesarios. Hay que hacer un cálculo preciso de los costos de implementación y mantenimiento y para ello necesitamos que economistas u otros profesionales capaces de contribuir con esta información ayuden en estas áreas. Se necesita hacer una revisión de los hechos que acompañan a la propuesta.

La visión de un México firmemente plantado en este siglo sólo puede ser el producto de una gran acción colectiva. Sólo si todos queremos que así sea y contribuimos nuestra parte será posible lograrlo.

Nunca antes los mexicanos habíamos tenido de frente en el camino una oportunidad de este tipo. Ojalá que el entusiasmo de #internetnecesario no se agote en sus estrechos fines, ojalá México logre acceder a su futuro en la revolución tecnológica de 2010.

Referencias [1] Ernesto Piedras. “Consideraciones Acerca de la Propuesta Fiscal para Telecomunicaciones” http://bit.ly/2zFGpL NOV-ENE 2010

45

// PM CORNER

Maneje los Cambios de Alcance con la Disciplina Adecuada No lo tome personalmente Por Tom Mochal Traducción: Enrique Ledesma y José Luis Flores

Todo proyecto primero debe obtener consenso sobre el alcance y los requerimientos del proyecto antes de que se acepte un cambio.

Después de esto, el objetivo a alcanzar por parte de la gestión del cambio es reconocer que hay un proceso para permitir que el cliente tome las decisiones de cambio al proyecto.

El director de proyecto sólo debe estar seguro de presentar la información apropiada para que el patrocinador pueda tomar una decisión inteligente basada en realidades. Muchos administradores de proyecto hacen un trabajo pobre en gestionar el alcance porque no quieren ser vistos en actitud de ofender al cliente.

Sin embargo, esto de ninguna manera debe formar parte de la ecuación. En vez de esto, el trabajo del director del proyecto es asegurarse de que la gestión del cambio se realice de manera efectiva, y que el patrocinador tenga la información que necesita para tomar la mejor decisión posible sobre si debe aceptarse o no el cambio en el alcance.

Cuando empieza un proyecto se debe obtener un consenso exacto con su cliente sobre lo que se está creando. En los niveles más altos este acuerdo se alcanza mediante la aprobación del “Acta de constitución del proyecto”. En los niveles bajos, el acuerdo se logra a través de la aceptación de los requerimientos. Cuando estos dos documentos han sido aprobados, se tiene la información necesaria para proceder durante el resto del proyecto.

Sin embargo, como con la muerte y los impuestos, el cambio es inevitable. Existen dos razones. Primero, es casi imposible para cualquier persona definir antes de tiempo con exactitud lo que será la solución final, por lo tanto, pueden cambiar los requerimientos mientras la solución se está desarrollando. Segundo, las condiciones generales de las empresas cambian a través del tiempo. Algunos de estos cambios forzarán reestructuración en el alcance del proyecto en formas que no se pueden conocer antes de tiempo.

Entonces, ¿qué va a decir cuando los inevitables cambios empiecen a llegar? Si dice sí antes de comprender las consecuencias hacia el proyecto, incrementará su posibilidad de fracaso. Si dice no, puede introducir un conflicto con el cliente y correr el riesgo de entregar una solución que no atiende las necesidades del mismo.

No lo tome personalmente – use su proceso La mejor respuesta es seguir el proceso de solicitud de cambio de alcance. Este proceso debe incluir el comprender el valor al negocio de realizar el cambio, así como el impacto sobre el presupuesto y cronograma del proyecto. Entonces puede llevar esta información al patrocinador del proyecto para la decisión aprobatoria. La gestión del cambio del alcance realmente es el arte de hacer que el patrocinador tome las decisiones una vez que entiendan todos los hechos y sus implicaciones.

Como siempre, se deben establecer los procedimientos de cambio del alcance basándose en el tamaño del proyecto. En proyectos pequeños, no debe preocuparse mucho. Probablemente el proyecto empezará y terminará antes de que exista un cambio en la empresa, la mayor parte de los requerimientos serán relativamente bien conocidos. El Director de Proyecto podrá evaluar rápidamente una solicitud de cambio pequeña y trabajar con el patrocinador para determinar si debe ser aceptada.

Para proyectos grandes, el cambio del alcance es muy importante y debe ser dirigido de manera correspondiente. El equipo completo, incluyendo el cliente, debe ser sensibilizado para entender cuándo se está haciendo una solicitud de cambio al alcance del proyecto. La solicitud debe ser documentada y enviada al Director del Proyecto.

El cambio se analiza y la información resultante correspondiente al cambio, el beneficio, costo e impacto de no aceptar el cambio son llevados ante el patrocinador. Entonces el cliente determina si acepta o no el cambio. Si es aprobado entonces se realiza el cambio correspondiente en el presupuesto y el cronograma. Si el cambio no es aprobado, se hace la anotación correspondiente y el proyecto sigue su camino.

Lo simpático del asunto es que si se deja que el patrocinador del proyecto decida sobre la aceptación del cambio en el alcance, por lo general rechazarán la solicitud. Ellos entienden la necesidad de entregar algo, aunque no cumpla con el 100% de sus necesidades, después refinar la solución a través del tiempo. De hecho, el patrocinador tiene mucho menos paciencia para las solicitudes de cambio del alcance que el administrador de proyecto, esto eliminará las solicitudes de cambio frívolas y marginales de manera inmediata.

Tom Mochal es Presidente de TenStep, Inc. y fundador de The TenStep Group; red de negocios que ayuda a organizaciones con programas de formación, consultoría y soporte basado en los procesos alrededor del mundo. Es autor de los libros Lessons in Project Management y Lessons in People Management.

Escribe para numerosos websites y newsletters con más de 650 columnas publicadas sobre administración de proyectos. Texto adaptado por Enrique Ledesma es Director Ejecutivo de TenStep Ecuador y José Luis Flores Pérez es Director Editorial de TenStep Latinoamérica

46

NOV-ENE 2010

www.sg.com.mx

/*TIERRA LIBRE*/

// COLUMNA

Un Programa Exitoso es un Programa Sencillo Las Dos Caras de la Moneda Emilio Osorio colabora actualmente como Consultor Asociado para Sun Microsystems México. Ha trabajado en desarrollos basados en Java desde 1996 y actualmente se dedica a ayudar a equipos de desarrollo a aprovechar las ventajas del Software Libre y los métodos ágiles en sus organizaciones.

Ferviente entusiasta de la aplicación social de la tecnología, a últimas fechas está involucrado con Organizaciones de la Sociedad Civil. Emilio estará encantado de recibir sus comentarios y quejas en oemilio@gmail.com

A

través del paso del tiempo los programadores tendemos a querer hacer cada vez más complejos los programas que escribimos.

Puede ser porque busquemos usar algoritmos más complejos, o bien porque los estándares y soluciones “universales” de modelado exigen mayor cantidad de líneas en el mismo tiempo para lograr la misma funcionalidad. Si a esto le sumamos un sin fin de “arquitecturas y modelos” al parecer inventados para un futuro de ciencia ficción, siempre declarado en grandes conferencias de analistas que le dicen a la gente de negocio lo que quieren realmente escuchar: “si usas mi suite RumbaConcert integrada de análisis, modelado, diseño y construcción, el código automágicamente se generará y casi ni necesitarás programadores.”

Desgraciadamente estas mágicas suites provocan que existan programas más grandes y complejos que resuelven la misma problemática en pos de una aparente “ventaja de modelado”. Por lo consiguiente, programadores con menos experiencia, producen menos funcionalidad en una tasa de líneas de código mucho mayor a la que programadores con experiencia y sin magia producirían.

Alguna vez alguien dijo: si sigo optimizando este código me quedaré con una línea de código y no me querrán pagar, mejor lo dejo como está. Algunos dirán que cada vez escriben menos líneas de código manualmente, gracias al uso de frameworks. Sin embargo dichos frameworks al final del día le suman al programa mucho más código del necesario y el resultado real es que el programa tardará mas en ejecutarse. Los ciclos de reloj parecen insignificantes pero no son gratuitos.

En el caso particular del modelado, con mucha tristeza, he presenciado que casi siempre que se introduce una “herramienta” para resolver el problema de cómo imaginar la estructura de un sistema, confundimos la utilidad de un modelo como una herramienta de análisis para convertirlo en un intento de “generador” de código de un sistema. Si es que el modelado formal tiene alguna utilidad, no

www.sg.com.mx

es otra que como una estrategia de comunicación de ideas al equipo de desarrollo. Buscar que un modelo sea en si una representación de un sistema es tan equivocado como aquel celebre dicho “el mapa no es el territorio”. El modelo de un sistema no se puede diseñar, el modelo “emerge” a partir de un ejercicio iterativo e incremental de construcción y pruebas.

En el otro lado de la moneda existen las complejidades agregadas a los programas, por considerar que el uso de patrones es la respuesta a la correcta programación para la solución de un problema, incluso a pesar de haber otras soluciones. En ese contexto, pareciera ser que mientras más patrones tenga un programa es mucho mejor. Debemos tener cuidado con que nos de uno de estos ataques de “patronitis” y rellenemos nuestra aplicación de patrones sin que hagan falta.

En el caso de Java, lenguaje con el que he trabajo los últimos años, encuentro que la programación es simple, a pesar de que se basa en componentes bastante complejos como el JVM y Garbage Collector. Sin embargo su utilización es transparente para nosotros y por lo tanto óptima; siempre que sigamos los lineamientos básicos de estilo, algoritmia y sentido común al momento de programar. Las APIs de soporte en sí no son tan sencillas como las anteriores, pero precisamente es lo que le da la robustez a las aplicaciones generadas con ésta tecnología y permite a los programadores la especialización.

Por favor, la próxima vez que generen una sola línea de código, pregúntense: “¿mi programa sigue siendo lo suficientemente simple para resolver de forma adecuada el problema?” Si la respuesta es sí, continúen. En caso contrario, les pido que replanteen la solución de una forma más sencilla. Quizás les tome algunos minutos encontrar la solución, pero está justo ahí enfrente del teclado.

» por Emilio Osorio

NOV-ENE 2010

47

// COLUMNA

/*PROGRAMAR ES UN MODO DE VIDA*/

Codificación de Caracteres Entendiendo el Por Qué de Unicode Gunnar Wolf es administrador de sistemas para el Instituto de Investigaciones Económicas de la UNAM; entusiasta y promotor del Software Libre, desarrollador del proyecto Debian GNU/Linux desde el 2003, miembro externo del Departamento de Seguridad en Cómputo de DGSCA-UNAM desde 1999.

H

ace un par de días recibí uno de esos correos que parecen venir de una época ya superada y olvidada hace años. Dicho correo comenzaba con la frase: Para evitar problemas de compatibilidad, este correo no incluye acentos ni enies.

En efecto, este problema casi ha desaparecido del correo, y ese pretexto sencillamente ya no resulta ni siquiera una excusa adecuada para quien le da flojera escribir el español correctamente. Sin embargo, no en todos los campos podemos hablar de un éxito tan grande como en el manejo del correo electrónico. Si bien para los hispanoparlantes el correo funcionó casi bien desde un principio, cuando el uso de Internet dio su gran salto cuantitativo en los 90s, para los nativos de muchas culturas alrededor del mundo se hizo imperativo encontrar cómo comunicarse confiablemente.

Pero el problema viene de mucho más atrás. Repasemos rápidamente la historia de los esquemas de codificación de caracteres.

Repaso histórico La codificación a partir de la cual se originan todos los esquemas en uso hoy en día nació en 1963, revisado/ratificado en 1967 con el nombre de ASCII (Código Estándar Americano para el Intercambio de Información). ASCII es un código de 7 bits, permitiendo la representación de hasta 128 caracteres: 32 caracteres de control, 34 símbolos, 52 caracteres de texto (mayúsculas y minúsculas) y 10 dígitos.

128 caracteres adicionales. Sin embargo, no surgió un estándar para su uso. Además, muchos de estos caracteres fueron empleados para incluir caracteres semigráficos que permitieran construir interfaces amigables al usuario.

En 1981, IBM puso a la venta su IBM PC. Contaba con una tarjeta de video con páginas de códigos reprogramables. El espacio de caracteres podía ser redefinido por software; los caracteres cargados por omisión se denominaron página de códigos 437 (CP437), dando soporte parcial para algunos lenguajes europeos. Pero debido a los caracteres semigráficos este espacio no era suficiente, por lo que era necesario activar una página de código alternativa —para el español, la CP850. La situación mejoró al popularizarse los entornos gráficos y dejar de depender de éstos caracteres especiales.

Entonces, las hojas de código similares pudieron agruparse y fue así que nacieron conjuntos de caracteres como el ISO-8859-1 para los lenguajes occidentales.

El problema se presenta al intercambiar archivos con usuarios de otras páginas: los datos que usan una página son indistinguibles de los que usan otra. Si compartieras un archivo ISO8859-1 con una persona de Europa oriental (ISO-8859-2), los caracteres acentuados aparecerían modificados, aparentemente corruptos. La situación de los lenguajes de Asia oriental era mucho peor aún, dado que plantear el uso de un alfabeto de 256 caracteres resultó imposible, y estos países desarrollaron esquemas paralelos de representación.

Sobra decir que el ámbito del cómputo ha cambiado drásticamente desde 1963. La computadora debía representar apenas la información indispensable para ser comprendida por sus operadores, y en la propuesta original, ASCII no incluía ni siquiera letras minúsculas.

Pero ya en 1964 aparecieron las máquinas de escribir con la capacidad de guardar (y corregir) páginas en cinta magnética. Fue sólo cuestión de tiempo para que estas capacidades quedaran al alcance de todo mundo.

En 1988, desarrolladores de Xerox y Apple, se reunieron para atacar este problema de raíz. Lanzaron la iniciativa del sistema Unicode, buscando aprovechar los grandes avances de más de 20 años del cómputo para lograr un conjunto de caracteres apto para todo el mundo. Pronto su iniciativa logró captar la atención y el respaldo de otros líderes. Para 1996 se publicó la especificación Unicode 2.0, permitiendo un espacio de más de un millón de puntos de código independientes, reteniendo compatibilidad hacia atrás completa con ISO-8859-1.

Todos los idiomas europeos que utilizan el alfabeto latino, a excepción del inglés, requieren de diferentes tipos de signos diacríticos.

Para acomodar esto, hacia fines de los 70s todas las computadoras ampliamente desplegadas habían estandarizado en un tamaño de palabra de 8 bits, con lo que se creó un ASCII ampliado que daría

Unicode es tan grande que su representación interna no está libre de polémica. Sin entrar en detalles técnicos, las dos principales representaciones son UTF-8 (utilizada en sistemas basados en Unix, y en general, para toda transmisión sobre redes de datos) y UTF-16 (en uso principalmente en sistemas Windows). UTF-8 está

48

NOV-ENE 2010

www.sg.com.mx

“Unicode es tan grande que su representación interna no está libre de polémica”.

basado en elementos individuales de 8 bits, mientras que el átomo en UTF-16 es de 16 bits, por lo que típicamente UTF-8 es más compacto y por lo tanto más robusto para transmisiones sobre la red. Un punto importante a tener en cuenta es que la representación binaria de texto ASCII heredado es idéntica a su representación en UTF-8, pero no así con UTF-16. Para más detalles respecto a diferencias entre estas dos representaciones, ver “Wikipedia Comparación” en la lista de referencias.

¿Por qué es diferente el manejo de Unicode?

Hasta antes de Unicode, todo lo que teníamos que saber respecto a un esquema de codificación se limitaba a elegir la salida adecuada, o interpretar la entrada como debía ser. Pero Unicode tiene muchas particularidades que requieren de un manejo especial. Algunos de ellos, son: • Longitud de una cadena. Como programadores estamos acostumbrados a que la longitud en caracteres de una cadena sea igual a su tamaño en bytes; Unicode rompe con este supuesto. Para medir la longitud de una cadena Unicode tenemos que evaluar la cadena completa y encontrar cuáles partículas son de qué tamaño, ya que un caracter puede medir entre uno y seis bytes. Además hay caracteres “combinantes”, que no ocupan un espacio por sí sólos sino que modifican el caracter anterior.

• No todas las cadenas son válidas. Con los esquemas tradicionales de 8 bits, todo conjunto de caracteres es válido. Al hablar de las representaciones de Unicode, hay cadenas que resultan inválidas. Si has visto una página Web donde los caracteres con diacríticos aparecen substituídos por caracteres en forma de rombo con un signo de interrogación dentro ( ), éste caracter denota que el procesamiento de Unicode no pudo completarse.

Sin embargo, no todas las aplicaciones son tan benignas como un navegador — Una base de datos debe negarse a guardar datos mal-formados — por lo cual debemos estar conscientes del tipo de excepciones que recibiremos si nuestro usuario nos da datos inválidos.

• Caracteres definidos semánticamente, no visualmente. Los caracteres en Unicode no buscan únicamente representar un grupo de grafías, sino que su significado. En tiempos del ASCII nos acostumbramos a utilizar la representación gráfica más cercana a un caracter. Por ejemplo, nos acostumbramos a representar a la multiplicación ya sea con la letra «x» o con el asterisco; con Unicode podemos usar –cual debe ser– el símbolo (U+2715).

Los alemanes y griegos ya no confunden la β (beta, U+0392) www.sg.com.mx

con la ß (Eszett o S fuerte, U+00DF). Aunque esta capacidad de Unicode es una ventaja, también puede llevarnos a confusiones.

Por ejemplo, si bien en ASCII con CodePage 850 sólo podemos representar a una letra acentuada de una manera (la letra á está en la posición 160), en Unicode puede representarse de esta misma forma, o como la combinación de una ‘a’ minúscula y un caracter combinante de acento agudo (U+0300): á. Esto permite la gran expresividad que requieren algunos alfabetos, pero nos obliga a considerar más casos especiales al enfrentarnos a Unicode desde el punto de vista del desarrollador de sistemas.

Conclusión Viendo sólamente estos puntos, puede que muchos de ustedes los vayan poniendo en la balanza, y les parezca que migrar a Unicode es demasiado dificil y no vale la pena.

Sin embargo, sencillamente, no nos queda opción: El mundo entero va avanzando en ese sentido. Si bien tenemos la fortuna de ser nativos de una cultura que utiliza el alfabeto dominante en Internet, no podemos ignorar que formamos parte de un mundo plenamente globalizado, y que los días de vivir en nuestra islita feliz de un sólo alfabeto han terminado.

» Por Gunnar Wolf

Referencias [1]. (Spolsky 2003) The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!) http://bit.ly/2Wv9B8 [2]. (Jennings 1999-2004) Annotated history of character codes http://bit.ly/14nllX [3]. (Dürst 1997) The Properties and Promizes of UTF-8 http://bit.ly/3RxG1T [4]. (Czyborra 1995-2000) Unicode in the Unix Environment http://bit.ly/2h4kDH [5]. (Wood 1999-2009) Combining Diacritical Marks http://bit.ly/3qqZ1A [6]. (Wikipedia Comparación) Comparison of Unicode encodings http://bit.ly/1UotOO

NOV-ENE 2010

49

// COLUMNA

/*PRUEBA DE SOFTWARE*/

Certificaciones Internacionales para Testers II El Camino de la Certificación Luis Vinicio León Carrillo es actualmente Director General de e-Quallity, empresa especializada en prueba de software, de la que es cofundador. Fue profesor-investigador en el ITESO durante varios lustros, que incluyeron una estancia de posgrado en prueba de software en Alemania, en la que abordó aspectos formales de esa disciplina. Es autor de varias publicaciones nacionales e internacionales, e invitado frecuente en eventos relacionados con la prueba de software.

E

n el número anterior comenzamos a abordar el tema de las certificaciones internacionales como tester. Hablamos sobre el perfil psicológico particular de los probadores, así como de los planes de carrera que las empresas ofrecen para el crecimiento profesional de los mismos. Describimos también un esquema genérico de certificación de 3 niveles que es común en muchas organizaciones certificadoras internacionales.

En esta entrega concluiremos el tema de certificaciones para testers, ahondando en el caso de México.

Retos de la prueba de software en México El servicio de la prueba de software ha mostrado ser altamente exportable, en particular porque no suele formar parte del negocio central de los clientes, además de que en la mayoría de los casos no involucra riesgos significativos, lo que facilita mucho la decisión de dar las pruebas en outsourcing. El tamaño de este mercado representa una oportunidad muy atractiva.

La industria de prueba de software en México aún no se ha ganado un nombre a nivel internacional. Esto se debe principalmente a que: • Nuestra industria se encuentra aún estructurándose y especializándose. Esto es lo que percibió recientemente Martin Pol, guru internacional en prueba de software, en su reciente visita a nuestro país.

• Aún hay pocas empresas especializadas en la disciplina, y son muy escasas las que conocen o trabajan con modelos de calidad especializados en prueba como TMM (Test Maturity Model) o TPI (Test Process Improvement).

• Aún hay relativamente pocos testers es-

pecializados, y aquellos con una certificación internacional son muy escasos.

Estas circunstancias evidencian por un lado las ventajas de diferenciación que una certificación internacional puede traer a la carrera de un tester, pero por otro también dejan ver porqué México no aparece aún en el radar mundial de prueba de software. Esto es algo que como país se busca revertir en el corto plazo con esfuerzos a nivel industria de TI como las aceleradoras TechBA, la iniciativa Mexico IT, o la creación y fortalecimiento de clusters. También hay esfuerzos de algunas empresas individuales por mejorar sus procesos de prueba, de hecho hemos apoyado a varias se han certificado.

En el lado de las certificaciones para personas, la mejor herramienta que tenemos es el programa Mexico First, que tiene por misión proporcionar apoyo económico y logístico para que en los siguientes 3 años se certifiquen 60,000 profesionistas de TI en nuestro país.

Alternativas de certificación como tester En el proceso de selección de una certificación internacional es importante tener claro el objetivo que se busca. Algunos criterios genéricos que pueden resultar de utilidad para seleccionar la organización que emite la certificación son: • La especialización y el nivel de reconocimiento del que goza la organización en la industria.

• El alcance geográfico que tiene.

• El grado de accesibilidad con que cuenta, tanto en términos económicos (habrá

algunas que tendrán mejor relación costobeneficio) como geográficos (comenzando por dónde se puede realizar el examen).

Una intención que nos han expresado muchos testers en los cursos que hemos ofrecido en una buena cantidad de ciudades del país, es buscar una certificación que les ayude en su desarrollo profesional en México, y que al mismo tiempo les facilite involucrarse en proyectos internacionales, principalmente con empresas estadounidenses. Este objetivo personal concuerda con el interés de la industria mexicana de prueba de software de exportar el servicio al consumidor más grande del mundo de servicios y productos de TI: los Estados Unidos. Más ahora que ese país se encuentra en recuperación económica, a diferencia de nosotros.

Tomando como base este objetivo, es recomendable seleccionar un organismo con un amplio reconocimiento internacional, y que haga notar por medio de la certificación que el “idioma internacional” (inglés) tampoco es un problema. Por ello, una buena opción sería un organismo con base en Estados Unidos.

Existen distintos organismos internacionales que emiten certificaciones, cada uno con su base de personas certificadas, precios, prerrequisitos y niveles de certificación. Entre los que más destacan se encuentran el Quality Assurance Institute, el International Institute for Software Testing, y el International Software Testing Qualifications Board.

Nosotros asistimos regularmente a congresos internacionales de prueba en Estados Unidos y en Europa. Gracias a ello hemos

Berenice Ruíz Eguino es consultora de e-Quallity en proyectos de mejora de organizaciones de prueba. A lo largo de su trayectoria profesional ha actuado también como tester senior, administradora de proyectos de prueba nacionales e internacionales, y directora de operaciones. Ha sido profesora de la Universidad Autónoma de Guadalajara, institución en la que realizó sus estudios de Maestría en Ciencias Computacionales.

50

NOV-ENE 2010

www.sg.com.mx

tenido contacto personal con varios de esos organismos certificadores, y consideramos que la mejor opción es el American Software Testing Qualifications Board (ASTQB), que es el capítulo estadounidense del International Software Testing Qualifications Board (ISTQB). Lo consideramos así por: • Su focalización en prueba de software, y su nivel de reconocimiento y penetración (más de 100,000 personas certificadas en alrededor de 40 países) • Los precios que maneja (es una asociación sin fines de lucro, pero sí vela por su autosustentabilidad) • La estratificación de sus certificaciones (básica, intermedia y avanzada) • La accesibilidad para la aplicación de los exámenes de certificación (se pueden hacer en nuestro país)

Oportunidades para los testers en México Consideramos que los testers en México tienen buenas oportunidades de crecimiento profesional, pues se encuentran en un sector que

www.sg.com.mx

va creciendo y estructurándose, y que ofrece servicios que se exportan cada vez más.

Por otra parte, los profesionales de esta disciplina también tienen la oportunidad de recibir apoyo de nuestro gobierno a través de Mexico First para obtener una certificación internacional. El apoyo económico que se puede alcanzar en este esquema depende en cierto sentido de la estrategia de cada entidad federativa, pero puede llegar a cubrir hasta el 80% del costo de una certificación internacional, que incluye los cursos de preparación para la misma.

En nuestro país, Mexico First tiene la estrategia de apoyar también los cursos en México que preparan al candidato para el examen, buscando asegurar que se logra la certificación. Eso hace posible que se pueda solicitar apoyo a Mexico First para asistir a un curso de preparación en alguna ciudad de nuestro país, y luego presentar el examen quizás ahí mismo. En principio, uno puede presentar directamente los exá-

menes de certificación. En algunos casos, es posible hacerlo en el marco de algunos congresos internacionales de prueba de software en Estados Unidos. Se organiza de esta manera para que el candidato pueda prepararse con algunos cursos antes de presentar el examen.

Conclusión Las certificaciones internacionales en prueba de software pueden ayudar a posicionar a México como un proveedor confiable de servicios especializados en prueba de software, con una estrategia semejante a la que se está siguiendo con TSP y PSP. Adicionalmente, estas certificaciones son también de gran utilidad en el desarrollo profesional de las personas.Las oportunidades están puestas, sólo falta aprovecharlas.

» Por Luis Vinicio León / Berenice Ruíz

NOV-ENE 2010

53 49

// COLUMNA

/*ENTREGANDO VALOR*/

Más Vale Prevenir que Lamentar Profundizando en administración de riesgos de TI Gloria Quintanilla es Directora de Innovación y Desarrollo de Itera. Cuenta con más de 20 años de experiencia en dirección y gestión de proyectos y servicios de TI. Ha sido miembro del Comité Técnico Nacional de Normalización en Sistemas de Calidad. Fue miembro fundador y presidente en dos ocasiones de la AMCIS. Actualmente es VP de Estándares del Capítulo México del Project Management Institute (PMI) y es Coordinadora del Comité Técnico Nacional para la atención de la ISO en Administración de Proyectos. Gloria es Instructor COBIT Autorizado por ISACA y sus certificaciones incluyen: Auditor Líder ISO 9000, Project Management Professional, ITIL Service Manager, Certified RUP Consultant y Certified MSF Practitioner.

E

n la columna anterior comentamos que el Gobierno corporativo de TI tiene 5 áreas clave de enfoque: Alineación estratégica, entrega de valor, administración de riesgos, administración de recursos y medición del desempeño.

En esta columna profundizaremos en algunos aspectos de la “Administración de riesgos de TI”.Es importante notar que los riesgos de TI son riesgos del negocio. Conforme avanza la tecnología se incrementa la correlación entre los riesgos asociados con el uso, operación, involucramiento, influencia y adopción de las TI en una organización y el incremento en el impacto y las probabilidades de lograr los objetivos de negocio.

Los riesgos de TI pueden ser clasificados en tres grandes grupos: • Riesgos en la entrega de los servicios de TI, asociados con el desempeño y disponibilidad de los servicios y que pueden ocasionar destrucción o reducción de valor a la organización.

• Riesgos en la entrega de una solución de negocio, asociados con la contribución esperada de TI a la mejora o creación de nuevas soluciones de negocio.

• Riesgos en la entrega de beneficios, asociados con la pérdida de oportunidades de usar la tecnología para mejorar la eficiencia y eficacia de los procesos de negocio o para usar la tecnología como habilitador de nuevas iniciativas de negocio.

El síndrome asociado a una pobre administración de los riesgos de TI se puede identificar por la presencia de uno de los siguientes síntomas: • “Toco madera” Los ejecutivos del negocio y responsables de TI administran los riesgos pretendiendo que no está. Pero los riesgos existen, independientemente de que se detectan o reconocen por la organización.

• “Visión corta” Los riesgos de TI son manejados de manera independiente a los riesgos de negocio. La perspectiva de TI prevalece -“Sólo se cayó el sistema 10 minutos”-, sobre la de negocio – “Sufrimos fuertes pérdidas en ventas por transacciones no realizadas”• “El vaquero solitario”. La organización celebra, premia y comenta las acciones heroicas de los valientes que salvan el día y evitan grandes pérdidas por eventos inesperados.

• “El cuerpo de bomberos”. Un equipo de especialistas de TI dedicados a resolver los incidentes continuos de los servicios de TI que ocurren en la operación.

• “Concurso de talentos”. Se atienden los riesgos del patrocinador que canta y hace el show más atractivo, desviando recursos valiosos de aquellos riesgos que por su magnitud deberían de ser atendidos con prioridad.

• “Yo tenía 10 perritos”. Pérdidas de valor y activos del negocio derivados de eventos que ocurren sin ser identificados.

La magnitud del impacto de los riesgos de TI es para la mayoría de las

52

NOV-ENE 2010

organizaciones enorme, sin embargo no se equilibra con el esfuerzo y la inversión para administrar y controlar los riesgos, ésta es un área que no recibe la atención suficiente. Para asegurar que TI sostiene a los objetivos de negocio y evitar la pérdida del valor creado es indispensable atender este aspecto mediante la implementación en la organización de un marco de control de riesgos, que para ser efectivo necesita de una serie de actividades que involucran a todos en la organización, desde la alta dirección hasta los niveles operativos. ¿Cómo podemos avanzar? ISACA (Information Systems Audit and Control Association) emitió un marco metodológico para la administración de los riesgos de TI que se suma a la familia de productos COBIT. La publicación, denominada en inglés “Enterprise Risk: Identify, Govern and Manage IT Risk; The Risk IT Framework” puede ser obtenida en el sitio de ISACA (www.isaca.org). Esta publicación viene a llenar un vacío que existía entre las metodologías de riesgos genéricas (como la ISO 31000) y las específicas asociadas a la administración de riesgos de seguridad de la información (como la ISO 27001). Risk IT provee un marco de procesos para la administración de riesgos compuesto de 9 procesos, organizados en tres dominios: Gobierno de riesgos • Establecer y mantener una perspectiva de riesgos común • Integrar con la administración de riesgos empresarial • Tomar decisiones de negocio conscientes de los riesgos Evaluación de riesgos • Recolectar datos • Analizar riesgos • Mantener el perfil de riesgos Respuesta a los riesgos • Articular los riesgos • Gestionar los riesgos • Reaccionar a eventos De estos tres dominios el menos común de encontrar en otros estándares y modelos de riesgo es el de Gobierno de Riesgos. En el corazón de este dominio hay algunos elementos clave que establecen un cambio de cultura:

Apetito y Tolerancia al Riesgo Apetito. La cantidad de riesgo que una organización está dispuesta a aceptar cuando está decidida a lograr sus objetivos.

Tolerancia. Desviaciones del nivel establecido por las definiciones de apetito de riesgos. www.sg.com.mx

Responsabilidad y Rendición de Cuentas Responsabilidad. La responsabilidad pertenece a aquellos que deben de asegurarse que las actividades para la evaluación y la respuesta a los riesgos se realicen.

Rendición de Cuentas. Este concepto es más difícil, no sólo por su traducción (del inglés accountability) sino también por nuestra cultura. La rendición de cuentas pertenece al individuo (no más de uno) que aprueba la ejecución o acepta el resultado de una actividad. En este sentido es el responsable último ante la organización si el resultado no se logra.

Es más fácil determinar y establecer a un responsable de ejecutar, que a un responsable de rendir cuentas.

Consciencia y Comunicación Consciencia. Es una parte fundamental de la cultura organizacional de prevención. Las organizaciones con consciencia de los riesgos entienden que éstos deben ser bien comprendidos y conocidos, esto no implica que se deban evitar o eliminar todos ellos. Toda decisión de inversión requiere un balance entre los riesgos y los beneficios esperados. Este tipo de organizaciones esperan que los riesgos se identifiquen, se comuniquen y se analicen para una toma de decisiones adecuada. Esta consciencia repercute en que los asuntos relacionados a riesgos se atienden en una forma alineada a las prioridades de la organización.

www.sg.com.mx

Comunicación. Es clave en el establecimiento de esta cultura. Las personas nos sentimos incómodas hablando de riesgos. Es fundamental cambiar esta actitud por una en la que se entiendan los beneficios de no cegarse ante los riesgos y de ver en la atención de ellos un elemento de ahorro y la posibilidad de evitar desastres.

Adicionalmente al marco Risk IT, ISACA elaboró una guía complementaria para la implementación llamada “The Risk IT Practitioner Guide” (está por publicarse pronto). Les recomiendo la lectura de estos dos documentos para entender los fundamentos de la administración de los riesgos y obtener lineamientos de diseño e implementación de una cultura de prevención que sustituya a la de atención de desastres (a pesar del espíritu del bombero que desde niños llevamos adentro).

La respuesta no está en sólo un modelo, otros marcos de referencia contienen metodologías que complementan el control de riesgos.

Algunos de estos son, las normas ISO (31000 y 27000); el área de conocimiento de gestión de riesgos del PMBOK, la certificación del PMI Certified Professional in Risk Management (CPRM); la categoría de procesos del CMMI, Risk Management; el proceso de ITIL, Risk Management, y las metodologías inglesas del British Standards.

» por Gloria Quintanilla

NOV-ENE 2010

51

// COLUMNA

/*tendencias en SOFTWARE*/

América Latina y el Cómputo Móvil Un panorama fresco para reducir la brecha digital Luis Daniel Soto Director de Divulgación Tecnológica para Microsoft. Responsable de la cuarta área de trece a nivel mundial en atención a desarrolladores de software. Coordina el esfuerzo de un grupo de 100 personas encargadas de Divulgación Tecnológica en América Latina.

Ingeniero en computación por la Fundación Arturo Rosenblueth, especialista en el tema de liberación al mercado de nuevas tecnologías y toma electrónica de decisiones. luisdans@microsoft.com luisdans.com\Twitter

E

l acelerado cambio de la industria de TI en Latinoamérica nos lleva a realizar un análisis sobre algunos datos importantes, para saber que rumbo debemos seguir. En esta ocasión quiero platicar con ustedes acerca del desarrollo de aplicaciones para dispositivos móviles, la oportunidad que representa para nuestra región, y los retos que enfrenta.

Antes de mirar hacia adelante, demos un repaso sobre lo que está sucediendo en América Latina en términos de Tecnologías de Información: • El cómputo llegó a América Latina hace 50 años. Internet ha cumplido 40 años, la mensajería instantánea más de una década.

• Uruguay y Costa Rica han sido exitosos en encarar la necesidad de exportar software. Brasil goza de auge en TI por un gran consumo interno.

Argentina vive intensamente la era web 2.0. Chile está experimentando un despertar acelerado en TI y desea el liderazgo regional. En México, el gobierno ha invertido significativamente en desarrollar esta industria.

• Las redes sociales han generado un resurgimiento de la actividad emprendedora en la región. Más de 3500 startups participan en el programa Microsoft BizSpark solo en nuestra geografía. Aun gran cantidad de desarrolladores y estudiantes no participa de los beneficios del web 2.0.

La oportunidad y retos del cómputo móvil El teléfono celular es hoy el ambiente de cómputo más ubicuo con un 50% de penetración sobre la población mundial. Solo 14% son teléfonos inteligentes como Palm, iPhone, BlackBerry, con sistemas operativos como Windows Mobile, Symbian y Android; otro 14% solo tienen estrictamente llamadas telefónicas y SMS; y el 72% intermedio son teléfonos con cámara, color, Java e Internet limitado.

Desde una perspectiva de demanda hay un fuerte interés por mejorar el acceso desde teléfonos con capacidades intermedias. Uno de los problemas clave es que los fabricantes de celulares no apoyan a los desarrolladores de aplicaciones móviles. Tradicionalmente las tiendas de los operadores recibían 40% ó 50% de los ingresos por las aplicaciones vendidas. Apple rompió el modelo pagando 70% al desarrollador, pero el bajo costo de las aplicaciones ha provocado competencia intensa. Para complicar más la situación, cerca de un 25% de las aplicaciones son gratuitas, lo que causa más presión en las aplicaciones comerciales. Como comentario al margen, les comparto el dato de que en el desarrollo de aplicaciones móviles son más costosas las actividades de pruebas que las de análisis y construcción.

Con los datos recabados podemos puntualizar que la mayor oportunidad en América Latina está alrededor de la creación de aplicaciones para teléfonos inteligentes, por contar con una base de usuarios altamente participativa. Al mismo tiempo se requiere continuar avanzando en acceso a internet, acortar la brecha de acceso a sistemas de información, aumen-

54

NOV-ENE 2010

tar y mejorar servicios de e-gobierno. También es necesario fomentar la participación en redes sociales y dotar de esta capacidad a los usuarios.

Va a ser muy interesante vivir la transformación hacia aplicaciones móviles: la complejidad en construcción de software tiene que reducirse; la monetización debe incrementarse para los desarrolladores con el apoyo directo de los operadores; la capacidad de extender y actualizar las aplicaciones tiene que evitar la necesidad de re-certificarse y re-distribuirse ya que no es factible recuperar una aplicación que tenga problemas serios de seguridad.

OneApp: una alternativa La respuesta a la problemática descrita no existe hoy… vale la pena abrir espacios para experimentar en éste campo. Una posibilidad es la iniciativa OneApp de Microsoft.

OneApp es una máquina virtual que opera en la mayoría de teléfonos con Java, Brew y Simbian, ejecuta código JavaScript de forma muy completa.

Hay un repositorio centralizado de aplicaciones globales para permitir al ISV llegar a cualquier mercado, pero ofreciendo al operador de redes control en la experiencia de la tienda de aplicaciones. La única desventaja de este modelo es el no poder acceder a capacidades muy específicas de los dispositivos, tales como gráficas aceleradas. Los applets han sido optimizados a un promedio de 10k para reducir el consumo de ancho de banda. Actualmente este sistema está entrando en pruebas piloto en países emergentes http://bit.ly/2rzQ7h

La web de dispositivos a largo plazo El apetito de los consumidores por los dispositivos electrónicos portátiles ya se ha retomado pese a la reciente crisis mundial. Si bien hoy los celulares y PC son significativamente la mayor plataforma habrá que monitorear de cerca a los lectores de libros electrónicos, dispositivos de solo acceso a internet y sistemas de consumo de información en cable y voz.

La riqueza de sensores (cámaras, micrófonos, GPS, triangulación Wi-fi) interconectados con estos dispositivos en un mundo aumentado con tecnologías RFID, NFC, resultará en nuevas fronteras de realidad mixta.

Conclusión Dada la transformación del ecosistema, América Latina vuelve a tener una vez más la opción de participar efectivamente o continuar rezagado. Nuestro reto será apalancar las redes sociales para producir un cambio mayor.

» Por Luis Daniel Soto www.sg.com.mx

www.sg.com.mx

NOV-ENE 2010

53

// CARRERA

Competencias Transversales del Talento en TI Entendiendo qué son y cómo se obtienen por Lourdes Sánchez

Uno de los retos más grandes que enfrenta nuestra industria es el de desarrollar el capital humano suficiente en cantidad y calidad.

Para lograr esto requerimos que los egresados de carreras universitarias afines a TI cuenten con las habilidades y conocimientos que demanda la industria para ser productivos lo antes posible. El proyecto “Modelo de vinculación empresa-academia-gobierno para el desarrollo en capacidades de capital humano en Tecnologías de la Información” (Talento en TI) tiene el objetivo de desarrollar un modelo que permita alinear las capacidades de capital humano, entre los requerimientos de la industria y la oferta académica. Dicho proyecto cuenta con el apoyo del Banco Interamericano de Desarrollo (BID) y de la Sociedad Academia Industria Gobierno en Tecnologías de la Información (IMPULSA TI), entre otros organismos.

El proyecto Talento en TI está formado por cinco componentes, que de manera integral apoyarán a la formación de capital humano para el área de TI. Uno de los componentes del proyecto establece la construcción de las competencias de los perfiles del Modelo Paracurricular. En este artículo hablaremos específicamente sobre los avances relacionados con la definición de competencias, así como su relación con las mejores prácticas en el desarrollo de software.

La brecha entre los egresados y lo que la sociedad requiere En la época actual la sociedad es de la información. El mundo está cambiando de forma acelerada impulsado por la ciencia y tecnología que crecen en forma logarítmica. Cuando la generación de un nuevo conocimiento se da, éste se convierte en un factor multiplicador y aún más cuando la comunidad científica y tecnológica interactúan.

Actualmente, la calidad de los profesionistas no se determina por su perfil académico o cantidad de conocimiento, sino por su capacidad de adaptación al cambio tecnológico. Por consiguiente, hoy en los procesos formativos se da importancia creciente al estudiante como sujeto activo del aprendizaje. Por esta razón, el énfasis debe dirigirse cada vez más a que el estudiante adquiera una serie de habilidades, conocimientos y competencias, y menos a la sola acumulación de los saberes de una disciplina.

Por otro lado, es evidente la desarticulación del sistema educativo cuando la formación superior pierde el horizonte de la sociedad, del sector empresarial y empresarial. El solo pensar que es necesario realizar pruebas a los egresados antes de ingresar al sector productivo como un requisito de aseguramiento de calidad académica, nos indica la falta de coherencia del sistema educativo pues refleja una desconfianza mutua entre el sector académico y las empresas. Debido a ello es cada vez más

grande la brecha que se genera entre los egresados de las instituciones de enseñanza superior y lo que la sociedad requiere.

Esto hace indispensable buscar alternativas que permitan a mediano plazo disminuir la distancia. Una alternativa es encontrar puntos de coincidencia que permitan determinar cual o cuales deben ser los conocimientos o habilidades que se requieren de una preparación dentro del contexto de un Modelo Paracurricular.

¿Qué son las competencias?

La primera interrogante por resolver es “¿qué son las competencias?

Las definiciones de competencias en la actualidad son muy diversas y generan confusión. Dicha diversidad y confusión se debe a que las competencias son entidades más amplias y difusas que los constructos psicológicos tradicionales. Las competencias combinan elementos que los constructos psicológicos tienden a separar: lo cognoscitivo (conocimientos y habilidades), lo psicomotriz o conductual (hábitos, destrezas), lo afectivo (motivaciones, actitudes, rasgos de personalidad) y lo psicofísico (visión). Además los constructos asumen que los atributos o rasgos son inherentes al individuo, a diferencia de las competencias que están claramente contextualizadas; es decir que para ser observadas, es necesario que la persona esté en el contexto de la acción de un trabajo o profesión. Esto establece en sí la diferencia, mientras que los constructos intentan generar variables unidimensionales que garanticen homogeneidad conceptual y métrica para cada una de ellas. La competencias se plantean como multidimensionales en sí mismas y con una relación directa con el contexto en que se expresan.

Las competencias son procesos a través de los cuales las personas realizan actividades o resuelven problemas de la vida cotidiana y del contexto laboral-profesional con idoneidad, mediante la articulación del saber hacer, saber conocer y saber ser, con conciencia crítica y autoresponsabilidad por las acciones llevadas a cabo. Cuando se habla de competencias científicas se hace referencia a la capacidad de establecer un cierto tipo de relación con las ciencias como un conjunto de saberes, capacidades y disposiciones que hacen posible actuar e interactuar de manera significativa en situaciones, en las cuales se requiere producir, apropiar o aplicar comprensiva y responsablemente los conocimientos científicos.

Para obtener resultados es indispensable tener certeza en el concepto de competencia, así como una clasificación que sea flexible y competitiva en ambos ámbitos el académico y el industrial. De estas diversas alternativas se puede concluir que las competencias: • Son características permanentes en los individuos.

• Se manifiestan cuando se ejecuta una tarea o se realiza un trabajo.

Ma. de Lourdes Sánchez Guerrero es profesor investigador Titular “C” en la Universidad Autónoma Metropolitana. Adicionalmente es Presidenta de la Asociación Nacional de Instituciones de Educación en Tecnologías de la Información (ANIEI), coordinadora de la estrategia 2 (Capital Humano) del PROSOFT, y representante de México en el Centro Latinoamericano de Estudios en Informática CLEI.

56

NOV-ENE 2010

www.sg.com.mx

• Están relacionados con la ejecución exitosa en una actividad, ya sea laboral o de otra índole.

• Tienen una relación causal con el rendimiento laboral, es decir, no solamente están asociadas con éxito, sino que se asume que realmente lo causan.

• Pueden ser generalizables en más de una actividad.

En base a lo anterior, podemos definir una competencia como: “lo que hace que la persona utilice las mejores prácticas para realizar un trabajo o una actividad y sea exitosa en la misma. Esto implica la conjunción de conocimientos, habilidades, disposiciones y conductas específicas.”

Marco de referencia Después de acordar qué es una competencia, la siguiente interrogante es: ¿Cómo sabemos cuáles son las competencias requeridas en una línea de producción de software? Lo más recomendable es tomar como marco de referencia las normas y estándares para el proceso de desarrollo de software que establecen “las mejores prácticas internacionales”.

De esta manera podemos resumir las características de la metodología por medio de los siguientes pasos: 1. Las normas establecen las mejores prácticas internacionales para desarrollar software.

2. Las mejores prácticas representan la mejor forma de construir una línea de producción de software de calidad internacional.

3. Conocidas las mejores prácticas podemos generar las competencias necesarias para que los individuos puedan realizarlas.

Si se toman las mejores prácticas de las normas de software como base para la generación de competencias, se obtiene un marco de referencia sólido que soporta dichas habilidades. Estas habilidades responden por lo tanto, a una forma sistemática de trabajar. La generación de competencias se puede asociar a una certificación legalmente válida, como consecuencia las mejores prácticas dan la base para la generación de los programas de capacitación (contenidos) y certificación de individuos para adquirir éstas “habilidades”. Quienes pueden adquirir estas competencias son los estudiantes de las diferentes carreras de TI y personas con experiencia técnica en el campo laboral.

Ejemplo para Ingeniería de Requerimientos Como ejemplo, vamos a aplicar esta metodología para definir las competencias asociadas a la disciplina de de ingeniería de requerimientos.

Usaremos como base la norma mexicana NMX-I-006/NYCE-2006 Tecnología de la información – evaluación de proyectos – parte cinco, grupo de Procesos de Ingeniería, proceso Adquisición de los Requerimientos.

La norma establece: ING.1 Adquisición de los Requerimientos Resultados del proceso: 1. Se establece comunicación continua con el cliente.

2. Se definen y fundamentan los requisitos acordados con el cliente.

3. Se establece un mecanismo de control de cambios referenciado a las necesidades de cambio del cliente.

4. Se establece un mecanismo para vigilar de manera continua las necesidades del cliente.

5. Se establece un mecanismo para garantizar que los clientes puedan determinar fácilmente el estado y disposición de sus solicitudes. www.sg.com.mx

6. Se identifican las mejoras que se originan del cambio tecnológico y de las necesidades del cliente y se administra su impacto.

Prácticas Base Las prácticas base correspondientes a los resultados del proceso anterior se enumeran a continuación: ING.1.PB1: Obtener los requisitos y solicitudes del cliente.

ING.1.PB2: Comprender las expectativas del cliente.

ING.1.PB3: Acordar requisitos.

ING.1.PB4: Establecer la referencia de los requisitos del cliente.

ING.1.PB5: Administrar los cambios hechos a los requisitos del cliente.

ING.1.PB6: Establecer los mecanismos de consulta del cliente.

Resultado de la Práctica 1. Se establece comunicación continua con el cliente.

2. Se establece un mecanismo para vigilar de manera continua las necesidades del cliente.

3. Se definen y fundamentan los requisitos acordados con el cliente.

4. Se establece un mecanismo de control de cambios referenciado a las necesidades de cambio del cliente.

5. Se establece un mecanismo para vigilar de manera continua las necesidades del cliente.

Tomando en consideración estas prácticas, se pueden definir las siguientes competencias de referencia: laboral haciendo uso de los conocimientos y herramientas adquiridas.

• Técnicas de entrevista.

• Comunicación Oral y Escrita.

• Trabajo en Equipo.

• Análisis y Síntesis de Información.

• Redacción de Informes.

• Control de cambios.

• Administración de Reuniones, seguimiento de acuerdos y redacción de minutas.

• Conocimiento de una herramienta informática para la obtención de requisitos.

• Capacidad crítica.

• Modificar intencionalmente y conscientemente la estrategia de au • toaprendizaje a partir de la detección de las propias necesidades.

• Adaptar y resolver inteligentemente las situaciones propias de la complejidad

Conclusión En la construcción de los referentes necesarios para la vinculación entre la industria, la academia y el gobierno, se considera fundamental para los trabajos de IMPULSA TI la definición de las competencias de referencia de los cinco perfiles del Modelo Paracurricular. Cabe mencionar que existen dos niveles de competencias. Las competencias de referencia son las necesarias para que los individuos sean productivos desde su ingreso al mundo laboral, y pueden ser empleadas en cualquier perfil de TICs; y las competencias específicas, las necesarias para que los individuos puedan realizar un trabajo o actividad de su perfil profesional.

Para conocer más sobre los perfiles del Modelo Paracurricular visita: www.aniei.org.mx

NOV-ENE 2010

57

// TECNOLOGÍA

/*INFRAESTRUCTURA*/

Virtualización Open Source Bienvenidos a la Siguiente Generación Por César Guerra

Los centros de datos se enfrentan con mayor frecuencia al reto de bajar los costos de operación de la infraestructura, al mismo tiempo de innovar su plataforma y cumplir con objetivos a largo plazo como el ser más eficientes en el uso energético, es decir, menos Watts por Ghz; enfriamiento y uso inteligente del espacio en rack. Los fabricantes de hardware han hecho los primeros avances al proveer nuevas tecnologías “más verdes” con diseños compactos y el reto ha quedado en el software para innovar en la consolidación y “virtualización de recursos” o últimamente llamada cloud computing.

nistración avanzada de memoria, redes y almacenamiento. Además agrega funciones de alta disponibilidad y migración de máquinas virtuales en tiempo real.

KVM permite que las máquinas virtuales sean calendarizadas como cualquier otro proceso, a partir de los distintos schedulers que provee el núcleo, y de su parametrización. Es posible asignar hasta 16 procesadores virtuales a una máquina virtual y hacer un uso inteligente de estos desde el sistema operativo padre.

En este reto, la integración de software y hardware resulta vital. La comunidad de software libre ha trabajado en el tema de virtualización desde hace muchos años, los frutos de este trabajo quedan plasmados en Qemu, Xen y Libvirt por mencionar algunos. Con estas tecnologías vimos nacer las primeras plataformas de virtualización empresarial open source, sin embargo, cada uno de los proyectos avanzaba a su propio ritmo y el consolidarlos en una sola plataforma de virtualización era lento e ineficiente. Eventualmente la comunidad concentró los esfuerzos en tres proyectos: un nuevo hypervisor, API’s de desarrollo estándar y unificadas con los nuevos hypervisores y una nueva consola de administración gráfica.

Todo esto denominado la “siguiente generación de software de virtualización basada en open source”.

KVM (Kernel-based Virtual Machine) es el nuevo hypervisor que provee una nueva infraestructura de virtualización en Linux, en esta ocasión (y a diferencia de otras soluciones) ofrece una integración total con el núcleo del sistema operativo. KVM utiliza las extensiones de procesadores modernos (Intel VT y AMD-V) para implementar un ambiente de virtualización acelerado directamente por el hardware.

En el modelo de virtualización de KVM, el sistema operativo administra las máquinas virtuales como procesos normales de Linux, utilizando así tanto las ventajas del sistema operativo Linux directamente, como la calendarización y priorización de procesos, la admi-

Figura 1. Modelo de Virtualización con SPICE

En cuanto al uso de la memoria, KVM se desmarca de Xen al permitir el ‘overcommit’, que es la capacidad de asignar más memoria virtual que la que contiene el hardware físico, para así aumentar la cantidad de máquinas virtuales en un mismo servidor. Esto es posible gracias a una función especial llamada “Page Sharing”; de esta forma, cuando KVM encuentra que varias máquinas virtuales contienen porciones de memoria idénticas, consolida las copias y libera la memoria restante.

César Guerra Egresado de Sistemas. Apasionado de la Tecnología, Linuxero desde hace 10 años. Trabaja en Red Hat México apoyando en las actividades de pre venta, Servicios Profesionales y demás sombreros tecnológicos. Considera que el reto a vencer en la siguiente década es reducir el impacto ecológico de la información, tanto su proceso como consumo.

58

NOV-ENE 2010

www.sg.com.mx

“KVM es el nuevo hipervisor que provee una nueva infraestructura de virtualización en Linux”.

KVM permite crear configuraciones sofisticadas y avanzadas de seguridad de redes, filtrado de paquetes, QoS, ruteo y bridging entre máquinas virtuales y las interfaces de red físicas a través de los mecanismos incluidos en Linux. Es posible crear escenarios sofisticados de conectividad y seguridad de servicios sin importar el sistema operativo virtualizado.

En cuanto a la facilidad para la administración del Almacenamiento, Linux provee una amplia diversidad de mecanismos de administración de dispositivos de almacenamiento local y remoto, con alta disponibilidad y redundancia. KVM puede hacer uso de todas estas tecnologías.

KVM ha tomado mucha inercia en la comunidad y en la integración con la infraestructura de Linux y se ha establecido como la opción preferida de la virtualización empresarial open source. Así mismo, el nuevo protocolo de despliegue remoto de máquinas virtuales, SPICE, viene a aportar nuevas capacidades y a otorgar un nivel superior de experiencia accediendo el display de los equipos remotos.

SPICE es un protocolo inicialmente desarrollado por Qumranet que provee una funcionalidad superior para visualización de “clientes virtualizados”. SPICE expone hacia el exterior los eventos de hardware generados por una máquina virtual y son administrados por KVM. Esto permite que las máquinas virtuales puedan exportar audio, video y dispositivos USB de forma bidireccional entre un servidor y un cliente, habilitando así dispositivos como webcams o headsets y aplicaciones como video conferencia y VoIP. Entre las capacidades innovadoras están el poder tener más de un monitor exportado, y tener resolucio-

www.sg.com.mx

nes HD. Es con la unión entre SPICE, KVM y la nueva consola de administración lanzada por Red Hat en Noviembre del 2009, que se cumple la promesa del cómputo ubicuo, de fácil acceso y administrable para los data centers.

Interoperabilidad entre tecnologías de virtualización Con la llegada de nuevos hypervisor a la escena empresarial, hemos de mencionar que Xen no ha desaparecido, sino se ha reutilizado el esfuerzo de tener API’s unificados y compatibles para la administración del hypervisor y que hoy también integra a KVM. Libvirt y VDSM son APIs que exponen funciones del hypervisor hacia el exterior. De esta forma es posible acceder y ejecutar comandos remotamente a un servidor con máquinas virtuales desde una consola de administración. Esto ha habilitado el desarrollo de nuevas consolas gráficas de administración de los recursos virtuales.

De manera paralela al constante esfuerzo por perpetuar La Ley de Moore, se han hecho grandes avances en desarrollar software que provea gran desempeño escalabilidad, predictibilidad y facilidad de administración. Así es como un sistema Operativo Linux, con un nuevo hypervisor, un nuevo protocolo de despliegue y API’s de administración unificadas, dan suficiente impulso a la “siguiente generación de software de virtualización basada en open source”, que busca posicionarse en los centros de datos al ofrecer una alternativa eficiente, escalable, flexible y confiable, sin un costo de adquisición y con el costo de operación más bajo que se alinea con el objetivo de las empresas en tiempos de reducción de presupuestos y conciencia ecológica.

NOV-ENE 2010

59

// fundamentos

Diseños Deteriorados Cómo Detectarlos y Evitarlos Por Juan Pablo Bernabé

Las aplicaciones de software típicamente están sujetas a cambios para acomodar nuevas necesidades. Dichos cambios poco a poco van afectando el diseño del software, pudriéndolo poco a poco. Al principio no es tan grave, una verruga por ahí, un parche por allá, pero el diseño original todavía es visible. Sin embargo, conforme el tiempo pasa, la descomposición va aumentando hasta que domina el diseño de la aplicación. Eventualmente, el esfuerzo requerido para hacer el más sencillo de los cambios es tan alto que se requiere rediseñar la aplicación.

Inmovilidad. La inmovilidad es la resistencia del software a ser reutilizado en otros proyectos o parte de otros proyectos. Pasa muchas veces que un programador descubre que necesita un módulo que es muy parecido a otro que ha desarrollado otro programador. Sin embargo, también pasa muchas veces que el módulo en cuestión depende demasiado de la aplicación en la que está integrado. Después de mucho trabajo los desarrolladores descubren que el trabajo necesario para separar las partes reutilizables de las partes no reutilizables es demasiado alto. Y entonces el software simplemente se rescribe en vez de ser reutilizado.

Síntomas de un diseño en deterioro

Viscosidad. La viscosidad del diseño es la dificultad de mantener la filosofía del diseño original. Cuando se afronta un cambio los programadores encuentran normalmente más de una manera de realizarlo. Algunas de estas formas preservan la filosofía del diseño y otras no. Cuando las formas de implementar el cambio preservando el diseño son más difíciles de realizar que las que no lo preservan, entonces la viscosidad del diseño es alta. Es fácil hacerlo mal y difícil hacerlo bien.

Hay cuatro síntomas principales que nos indican que un diseño se está deteriorando. Estos son: rigidez, fragilidad, inmovilidad y viscosidad. A continuación se explican.

Rigidez. Es la tendencia del software a ser difícil de cambiar, incluso en las cosas más sencillas. Cada cambio produce una cascada de cambios en módulos dependientes. Un cambio sencillo en un módulo puede requerir una gran cantidad de ajustes a lo largo de todo el sistema. Cuando una aplicación toma este camino, los gerentes temen decir a los programadores que arreglen pequeños problemas que no son críticos. Esto sucede porque no se tiene certeza del esfuerzo requerido para realizar cambios. El miedo del gerente puede llegar a ser tan agudo que se niegue a realizar modificaciones en la aplicación. De manera que lo que empezó siendo un diseño ineficiente acaba siendo una mala política de gestión del sistema.

Fragilidad. Muy relacionada con la rigidez está la fragilidad. La fragilidad es la tendencia que tiene el software a generar fallas cuando sufre un cambio. Es común que las fallas ocurran en sitios o módulos que no están relacionados conceptualmente con el área que se está cambiando. Ante esto, cada vez que los gerentes autorizan un cambio tienen miedo de que el programa “truene” por algún lugar inesperado. Conforme la fragilidad empeora, la probabilidad de que el software falle incrementa con el tiempo, acercándose cada vez más a 1. Este software es imposible de mantener. Cada arreglo lo hace peor, introduciendo más problemas de los que son solucionados. Un sistema frágil provoca que los gerentes y los clientes tengan la impresión de que los desarrolladores han perdido el control del software, perdiéndose así la credibilidad de los desarrolladores. Y frases como “Descompones más de lo que arreglas”, comienzan a ser habituales.

Causas del deterioro Requisitos cambiantes. Los requerimientos del sistema tienden a cambiar de formas imprevistas en el diseño inicial. En realidad, ese no es el problema sino que a menudo los cambios son hechos por programadores que no están familiarizados con el diseño original.

Entonces, aunque los cambios funcionen, violan el diseño original.

Poco a poco los cambios continúan y las violaciones se acumulan hasta que el diseño se rompe. Para evitar esto, debemos realizar diseños que soporten modificaciones sin perder su consistencia. Adicionalmente, las decisiones de diseño deben estar documentadas y comunicadas para que cuando otras personas realicen cambios a la aplicación, se respeten los lineamientos de diseño.

Control de dependencias. Los cambios que tienden a deterior el diseño son aquellos que introducen nuevas dependencias. Cada una de las cuatro causas mencionadas anteriormente están relacionadas directa o indirectamente con dependencias entre módulos del software. Es así que debemos controlar cuidadosamente las dependencias entre módulos. Los principios y técnicas de la orientación a objetos nos ayudan a minimizar estas dependencias.

Referencias [1] Robert C. Martin. Design Principles and Design Patterns. http://bit.ly/3bA65c

Juan Pablo Bernabé es ingeniero en desarrollo de software, diplomado en técnico programador analista por el instituto IPDATA, Sun Certified Java Programmer y entusiasta programador desde los 11 años de edad. Ha la tabajado para diversas consultoras transnacionales como Accenture y Tim W. E. en esta última laborando en Lisboa, Portugal. Actualmente trabaja para Indra en el sector financiero como Analista de Sistemas y es colaborador en la web UNIXMEXICO (www.unixmexico.org/)

60

NOV-ENE 2010

www.sg.com.mx

INDEX

DIRECTORIO

Anunciante Alpha Consultoría CASENET Compushow Comunicarum E-Quallity Gelattina Itera Manpower Milestone NYCE SG Campus SG Guía Software Gurú SG Revista Digital Sistemas Humanos

Páginas 51 13 61 53 59 55 11 9 4F 3F 15 1 2F 39 63

Sitio www.alpha-consultoria.com.mx www. casenet.com.mx www.compushow.com.mx www.comunicarum.com www.e-quallity.net www.gelattina.com www.iteraprocess.com www.manpowerprosessional.com.mx www.milestone.com.mx www.nyce.org.mx www.sgcampus.com.mx www.sg.com.mx/guia www.sg.com.mx www.sg.com.mx www.humanos.com.mx/agiles

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

NOV-ENE 2010

61

// tecnología

/*gadgets*/

i.Tech

Solar Voice 908 Motorola

Dext con Motoblur Motorola anuncia la disponibilidad del Motorola Dext con Motoblur, el primero teléfono móvil en México con la plataforma Android. Gracias a esto es capaz de sincronizar contactos, publicaciones, mensajes y fotos desde diversas fuentes de información y redes sociales.

Este dispositivo cuenta con teclado full QWERTY y pantalla de alta resolución para facilitar el acceso a redes sociales, aplicaciones web, correo electrónico y LastFM. El equipo incluye además GPS integrado, acelerómetro, red 3G, red Wi-Fi y cámara. Otras prestaciones que se encuentran en el Moto Dext son: seguridad de la información gracias a la tecnología Motoblur el usuario puede borrar toda la información con un simple comando remoto; cámara fotográfica de 5 Megapixeles con autoenfoque y capacidad de publicar instantáneamente las imágenes en diversas redes sociales; cámara de video a 24 cuadros por segundo; reproductor de MP3; tarjeta MicroSD opcional de entre 8 y 32 GB.

En México el tema del Bluetooth y conciencia ecológica esta de moda. La empresa I.Tech presenta un producto que cubre con esta dos expectativa; el solarvoice 908 un manos libres que utiliza energía solar para restaurar la batería, se carga bajo el sol en una base que puedes poner, por ejemplo, en el tablero de tu auto o en la ventana mas cercana a tu lugar de trabajo. Solar Voice 908 cuenta con radio FM, identificador de llamadas, ajuste automático de volumen y versión 2.1 de Bluetooth.La bateria del dispositivo puede durar cinco horas en modo de conversación normal y en tiempo de espera puede llegar a durar 140 horas después de que esté completamente cargada.

Hay varias opciones para que los usuarios puedan cargar el auricular, ya sea por USB normal, base de carga o carga a través de energía solar. Ademas cuenta con las siguientes características: tecnología de reducción de ruido, dictado por voz, redial del último número, transferencia de llamada del auricular al celular y viceversa, auto reenlace de la conexión Bluetooth.n espera.

Sony

VAIO W mini notebook Sony México lanza su nueva familia de mini portátiles VAIO W mini notebook, con un tamaño de 26 x 17 centímetros y 1.2 kg de peso, ofrece un diseño compacto sin comprometer espacio con un procesador Intel Atom de 1.66GHz1Mobile, velocidad de bus 667MHz, memoria de 1GB DDR2 SDRAM, disco duro de 250GB, bluetooth, webcam y micrófono integrado, Wi-Fi 802.11b/g/n, dos puertos USB y Microsoft Windows 7. Una de las características interesantes de esta línea es el sistema “LED backlight” que permite que las imágenes se vean realmente brillantes, con detalles definidos y colores vivos. Cuenta con una pantalla LCD de 10.1 pulgadas con resolución 1366:768.

Otra característica es el software VAIO Media Plus que permitirá a los usuarios compartir fotos, videos y música. Todo el contenido digital se encuentra en un solo sitio y se transmite a otros aparatos , como un televisor o consolas de video juegos. La nueva VAIO W mini notebook está disponible en tiendas Sony Style y departamentales en el mercado mexicano.

62

NOV-ENE 2010

www.sg.com.mx

www.sg.com.mx

NOV-ENE 2010

63

// BIBLIOTECA

Software Process Improvement for Small and Medium Enterprises Hanna Oktaba, Mario Piattini Information Science Reference, 2008

01

En numerosas ocasiones se ha hecho referencia en artículos de SG a este libro. Básicamente, es un compendio que captura la experiencia y aprendizaje de diversos autores respecto al tema de mejora de procesos de software en pequeñas y medianas organizaciones. Como se podrán imaginar, muchos de los contenidos fueron desarrolladores por consultores e investigadores de América Latina. De hecho, la convocatoria de autores para esta obra fue difundida en el sitio web de SG hace unos años, así que en cierta forma podemos ponernos nuestra estrellita por haber participado en su desarrollo. El libro está dirigido principalmente a gerentes e ingenieros de procesos en empresas de software, y explica a fondo las particularidades que tienen las organizaciones pequeñas de software y el por qué requieren de modelos de mejora que se ajusten a estas necesidad. Mucho del conocimiento capturado en la obra sirvió para desarrollar la nueva norma ISO/IEC 29110 (Software Life Cycle Profiles for Very. Small Enterprises), que como saben, tiene sus bases en MoProSoft.

Consulta algunas páginas de este libro en http://bit.ly/1zTcY2

Don’t Just Roll the Dice: A usefully short guide to software pricing Neil Davidson Red Gate Books, 2009

02

Todos los que hemos tenido la necesidad de ponerle precio a un software, sabemos que no es algo trivial, y que precisamente en muchos casos se termina sacando un precio de la manga, o como sugiere el título del libro, tirando los dados. Don’t Just Roll the Dice es, como su subtítulo indica, una guía corta y útil para definir el precio de software que deseemos comercializar; provee tanto información teorica, como casos de estudio y consejos prácticos. Entre sus páginas encontrarás temas como economía básica, psicología de precios, elementos a tener en cuenta al establecer una política de precios, un análisis de las estrategias de precio más comunes para el software, y por último provee un checklist de gran utilidad al defi-

64

NOV-ENE 2010

nir el precio para tu propio software. Lo mejor de todo es que “Don’t Just Roll the Dice” está disponible como e-book gratuito. Así que mejor descárgalo y evalúalo por tí mismo.

Descárgalo en http://bit.ly/1yhE26

www.sg.com.mx

Aﾃｱo 05 No. 26

www.sg.com.mx

SOFTWARE GURU CONOCIMIENTO EN PRﾃ，TICA

Noviembre 2009 - Enero 2010