SG22 (Noviembre 2008 - Enero 2009)

Page 1






// CONTENIDO

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

Editorial

Coordinación Editorial Alejandro Escamilla Arte y Diseño Grisel Otero

Muchos hemos oído acerca de Cómputo en la Nube, pero ¿qué es esto?, ¿dónde se está aplicando?, ¿qué opinión tienen los expertos al respecto? Más allá de la moda, es importante entender cuales son los conceptos fundamentales de este modelo, así como el impacto que tendrá en la forma en que desarrollamos software. En cuanto a la portada, seguramente se preguntarán qué fumamos para salir con el concepto artístico. Queremos aclarar que no se usaron sustancias alucinantes durante su desarrollo (no que nos conste), ni nos basamos en libros de “Donde está Wally”. Simplemente le explicamos a nuestra diseñadora, Grisel Otero, el concepto de cloud computing, y le pedimos que ella hiciera una interpretación artística de él. Después del shock inicial de ver su propuesta, nos dimos cuenta de cómo ella entiende y plasmó el concepto: básicamente, una masa de elementos diversos que a pesar de ser diferentes, tienen elementos comunes, convergen y generan sinergia ... y justamente eso es lo que es. Desde hace tiempo que teníamos ganas de entrevistar a Tom DeMarco, y por fin se nos hizo. Tom es una de esas personas que nos hace abrir los ojos y darnos cuenta de tantas cosas. Muchas gracias a Tom y a la gente de Cutter Consortium por facilitar esta entrevista.

02

NOV-ENE 2009

En este número tenemos también la edición 2008 de nuestra Encuesta de Salarios, que se está convirtiendo en el reportaje más esperado del año. Para complementar el resto del contenido de este número, ofrecemos un panorama sobre ofuscación de código, un artículo bastante completo sobre RFID, así como las secciones de costumbre con prácticas de ingeniería de software, y la perspectiva de nuestros columnistas. Queremos también aprovechar esta oportunidad para recordarles sobre el proyecto más reciente de SG, denominado SG Campus. Este es un servicio de aprendizaje continuo en línea para profesionistas de TI. Ya están abiertos varios cursos y los resultados han sido muy satisfactorios. Si todavía no te unes a SG Campus, hazlo en www.sgcampus.com.mx. Dado que el último número del año, no queremos quedarnos sin desearles unas felices fiestas navideñas, y un próspero 2009. Ante el panorama financiero que hemos vivido últimamente, sabemos que esto último será complicado. Pero bien dicen que “a río revuelto, ganancia de pescadores”. Así que hay que ponernos las pilas para aprovechar esta oportunidad. » Equipo Editorial

Consejo Editorial Jorge Valdés - PMI; Luis Cuellar - Softtek; Francisco Camargo, Luis D. Soto - Microsoft; Hanna Oktaba - UNAM; Ralf Eder, Raúl Trejo, Guillermo Rodríguez - ITESM CEM; Emilio Osorio - Sistemas Humanos; Luis Vinicio León - e-Quallity. Colaboradores Carlos Coello, Benjamín Alonso, Guillermo Morales, Javier Espadas, Pablo Resendiz, Gilbert Corrales, Juan Olivares, Sandokan Barajas, Victor García, Miguel Armas, Francisco Vaca, Carlos Ordoñez, Beatríz Ríos, Luis Joyanes, Shannon Cepeda, Romeo Márquez, Gunnar Wolf , Susana Tamayo. Ventas Claudia Perea Circulación y Administración Edgar Dorantes 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: 04-2004-090212091400-102. Certificado de licitud de título: 12999. Certificado de licitud de contenido:10572. ISSN: 1870-0888. Registro Postal: PP15-5106. Se imprimió en octubre de 2008 en Roma Color, S.A. de C.V. Distribuido por Sepomex.

www.sg.com.mx


contenido nov 2008 - ene 2009

26

EN PORTADA Cloud Computing

Te mostramos los recursos ilimitados del “Cómputo en la nube”

Especial

Encuesta de Salarios 2008.

18

Productos LO QUE VIENE 12 VSTS 210, Mono 2.0 y Oracle Beehive. Herramientas 14 Beneficios de la Automatización de Pruebas. TUTORIAL Silverlight, Parte 2.

Columnas

Prácticas

Tejiendo Nuestra Red por Hanna Oktaba

08

Tendencias en Software por Luis Daniel Soto

48

Mejora Continua por Luis Cuellar

10

Prueba de Software por Luis Vinicio León

50

Columna Invitada por Carlos Ordoñez

46

PROGRAMACIÓN Ofuscación de Código

36

Conozcamos como proteger nuestro código para que no sea reutilizado por terceros.

ADMINISTRACIÓN DE BASE DE DATOS Diseño de Base de Datos

40

Aprendamos a utilizar los catálogos para hacer más eficiente nuestra manera de codificar.

En Cada Número Noticias y Eventos

04

GADGETS

60

INDUSTRIA

06

FUNDAMENTOS

62

INFRAESTRUCTURA

52

CARRERA

64

24

16

ARQUITECTURA Una Receta para Desarollar Arquitecturas

42

Presentamos el marco de trabajo para desarrollar arquitecturas propuesto por The Open Group.

PM CORNER La integración de un equipo de trabajo funcional

44

Tácticas y técnicas para integrar de manera eficiente a tu equipo de trabajo.

Entrevista

Tom DeMarco

www.sg.com.mx

NOV-ENE 2009

03


// NOTICIAS

XXIX Convención Nacional CANIETI Tras tres días de reunión, debate y reflexión conjunta, concluyó la XXIX Convención Nacional CANIETI, la cual bajo el título “Gobierno, Academia e Industria: Triple Play Ganador” reunió a representantes de estos sectores con un solo objetivo: sentar las bases del desarrollo de las industrias representadas en el corto y mediano plazo. La Convención fue inaugurada por el Presidente Constitucional de México, el Lic. Felipe Calderón Hinojosa, y precedida por el Presidente Nacional de CANIETI, el Dr. Eduardo Ruiz Esparza, quien agradeciendo el dinamismo y visión de los afiliados, así como al apoyo de los programas del Gobierno Federal, comentó que ha sido posible mejorar la posición competitiva de nuestro país en cinco posiciones, con respecto de otros jugadores internacionales, mencionando los programas más sobresalientes: ProSoft, MexicoIT, ProMedia y Mexico FIRST.

IBM Rational Comes to You, México 2008 El pasado 10 de septiembre se realizó en la ciudad de México el evento “IBM Rational Comes To You”, donde los asistentes tuvieron acceso a varios de los temas y conferencistas que estuvieron presentes unos meses antes en la conferencia anual de Rational que se celebra en Orlando (IBM Rational Software Development Conference). Entre los conferencistas estuvo Terry Quatrani, que es la evangelista en jefe de Rational y quien había estado recientemente en México como keynote speaker en SG ’08 Conferencia y Expo. El tema que dominó las sesiones fue la nueva familia de herramientas Rational Team Concert, la cual está construida sobre Jazz, una nueva plataforma open source para el desarrollo de herramientas de colaboración.

Cutter Consortium Summit América Latina La edición para América Latina del Cutter Summit 2008 se llevó a cabo del 1 al 3 de octubre en el Hotel JW Marriott en la ciudad de México. El evento reunió a expertos del campo tales como Tom DeMarco, Robert Benson, Tim Lister, Alfredo Funes, Lou Mazzuchelli, Mike Rosen y Alejandro Pisanty. El tema con el que se abrió el Summit fue el de “Manejo Efectivo de las Finanzas de TI”, el cual cobra especial importancia ante la actual situación económica. Como parte de la exposición de este tema se revisaron a detalle prácticas y recomendaciones para estimar y monitorear el costo total de un servicio de TI, y cómo justificar su valor hacia la alta dirección.

04

NOV-ENE 2009

www.sg.com.mx


// EVENTOs

5 al 7 de Noviembre 2008

BAJA TECH Business Solutions 2.0 Grand Hotel Tijuana, Baja California Info: www.itbaja.com/web-bajatech e-mail: enlace@itbaja.com

11 al 13 de Noviembre 2008

Agile Management - Creating Business & Technical Value Cutter Consortium Hotel JW Marriott, Cd. de México Info: www.cutter.com.mx/eventos2008 e-mail: agile@cutter.com.mx

5 y 6 de Noviembre 2008

Seminario Gratuito “Squeeze your metrics” Avantare, MS SPI Solutions, y Secretaría de Economía Torre Insurgentes de Secretaría de Economía, Cd. de México e-mail: capacitacion@avantare.com

12 al 14 de Noviembre 2008

50 Años de la Computación en México Palacio de Minería, Cd. de México Info: computo50.unam.mx

12 al 14 de Noviembre 2008

SEPG LA 2008 – Combinando Disciplina con Métodos Ágiles

5 al 7 de Diciembre 2008

ESI Tecnalia, SEI, y ESICenter Cono Sur Hotel Hermitage, Mar del Plata, Argentina Info: www.esi.es/SEPGLA e-mail: sepgla@esi.es

WTC, Cd. de México Info: www.exporobotica.com.mx e-mail: info@exporobotica.com.mx

Expo Robótica, Ciencia y Tecnología

CIAPEM 2008

CIISA 2008

Los pasados 1ro. al 3 de octubre, en Mundo Imperial Acapulco, se llevó a cabo la XXXII Reunión Nacional del Comité de Informática de la Administración Pública Estatal y Municipal (CIAPEM). Encabezado por el gobierno de Guerrero en el período 20082009, el CIAPEM tendrá como objetivo establecer políticas y vínculos entre las administraciones estatales, municipales, federales y privadas que permitan acelerar el crecimiento constante y equitativo de la aplicación y uso de las tecnologías de información. De igual manera buscará establecer una metodología para definir la situación actual que mantienen el uso de la tecnología y las comunicaciones, impulsando a la Sociedad de la Información y el uso de las TICs en México.

Del 3 al 5 de septiembre se realizó en la ciudad de Guadalajara, Jalisco el Congreso Internacional de Ingeniería de Software y sus Aplicaciones (CIISA) 2008. Este evento fue organizado por el SIE Center de México en conjunto con el Tec de Monterrey Campus Guadalajara, y apoyado por la Secretaría de Economía y el Gobierno del Estado de Jalisco. Se contó con la presencia de prestigiados conferencistas como Watts Humphrey y Suzzane Garcia del SEI, Lauro Cantú de Gartner, y Kerrie Holley de IBM, entre otros. Los temas centrales fueron arquitectura de software, calidad, y tecnologías de desarrollo, agregando también un espacio para explorar oportunidades de negocio.

Congreso Internacional ANIEI 2008

DebConf 8

Organizado por la ANIEI y teniendo como sedes el ITESM Campus Monterrey, la Universidad de Monterrey y la Universidad Regiomontana, se llevó a cabo el XXI Congreso Nacional y VII Congreso Internacional de Informática y Computación, los días 1, 2 y 3 de Octubre. Con el objetivo de aportar conocimientos y experiencias a nuestros próximos profesionales en tecnologías de la información, el congreso presentó conferencistas e investigadores de prestigio reconocidos a nivel mundial, contando con la asistencia de más de 1,300 estudiantes y egresados de las carreras de TI.

El noveno congreso de desarrollo de Debian, DebConf, fue celebrado del 10 al 16 de agosto, en la ciudad de Mar del Plata, Argentina. Participaron aproximadamente 250 desarrolladores, de 37 países, en más de 100 charlas y talleres programados. Además durante la semana previa de trabajo (3 al 9 de agosto), se llevó a cabo el DebCamp, enfocado en el trabajo colaborativo. Participaron personalidades tales como el líder del proyecto Debian, Steve McIntyre, y el jefe de tecnologías Linux y Open Source de Hewlett Packard, Bdale Garbee. Los temas incluyeron la organización del equipo global, internacionalización, desarrollos y políticas internas, virtualización, y administración de sistemas y redes.

www.sg.com.mx

NOV-ENE 2009

05


// INDUSTRIA

50 Años de la Computación en México Reseña histórica

Por Alejandro Escamilla

Este año estamos celebrando los 50 años de la computación en México, y se han venido realizando una serie de eventos al respecto. Aprovechemos esta oportunidad para echar un vistazo a los principales acontecimientos durante estos 50 años.

No obstante, para instituciones privadas como el ITAM, la UDLA, o el ITESM, fue un período clave para la formación y crecimiento de su plantilla de doctores en computación dirigidos hacia la investigación.

La primera computadora en México

En la década de los noventas, el CONACYT da un fuerte impulso a la realización de investigación a nivel nacional y se crean nuevos centros de investigación tales como: El Centro de Investigación en Computación (CIC) del Instituto Politécnico Nacional, el Laboratorio Nacional de Informática Avanzada (LANIA) en Xalapa, Veracruz; la Coordinación de Ciencias Computacionales del Instituto Nacional de Astrofísica, Óptica y Electrónica (INAOE) y el Departamento de Ciencias de la Computación del Centro de Investigación Científica y de Educación Superior de Ensenada (CICESE), entre otros.

La historia comienza en 1955, año en que el Ing. Sergio Beltrán López plantea al Dr. Nabor Carrillo Flores (entonces rector de la UNAM) la adquisición de una computadora. El Ing. Beltrán se había interesado en esto a raíz de los resultados de un proyecto de resolución de ecuaciones simultáneas que hicieron en conjunto con la Universidad de California en Los Angeles (UCLA). En la resolución de este proyecto los investigadores mexicanos habían tardado 9 meses, mientras que la UCLA solo había tardado 3 semanas utilizando una computadora IBM-650. Fue así que la UNAM firmó un contrato con IBM para rentar una IBM-650 por un total de $25,000 pesos mensuales. El 8 de junio de 1958 abrió sus puertas el Centro de Cálculo Electrónico (el CCE), ubicado en el sótano de la antigua Facultad de Ciencias, donde se instaló la IBM-650. Esta máquina operaba con un tambor magnético con capacidad para 20,000 dígitos, realizaba 1,300 operaciones de suma y resta por segundo y funcionaba con lectora y perforadora de tarjetas, adoptando un sistema numérico llamado bi-quinario. Las primeras tareas que se le encomendaron a esta computadora fueron las de resolver problemas de astronomía, física e ingeniería química.

Se unen otras universidades Posteriormente, en 1961 el IPN inauguró su centro de cómputo, el CENAC, y en 1964 el ITESM instaló su primera computadora, y poco después inauguró la primera carrera de computación en el país. La UNAM, el IPN y el ITESM se convirtieron en polos de atracción de estudiantes curiosos y tenaces que deseaban acercarse a ese nuevo universo de la computación.

Los primeros posgrados El Centro Nacional de Cálculo del IPN instituyó a fines de los años sesenta la primera maestría en ciencias de la computación. La UNAM hizo lo propio en 1975. Para finales de los años 70, el Instituto de Investigaciones en Matemáticas Aplicadas y Sistemas (IIMAS) de la UNAM contaba con 20 doctores en computación.

La década perdida La década de los ochenta fue muy difícil para las ciencias de la computación en México. En un periodo menor a tres años, todos los grupos de investigación de las universidades públicas en México se redujeron considerablemente y en algunos casos desaparecieron por completo. A finales de esa década, el escenario económico en las universidades públicas hizo muchos estragos en los grupos de investigadores dedicados al cómputo; a este episodio de la historia de la computación en México se le denominó “La década perdida”.

16 06

NOV-ENE 2009

Nuevo impulso de Conacyt

La llegada del siglo XXI En la primera década de este siglo, se dieron avances notables como el primer enlace internacional de voz sobre IP nativo en 2002 ; el primer enlace de comunicación interactiva con formato para televisión digital en Internet en 2003 , la Inauguración de la Red Inalámbrica Universitaria (RIU) en 2006, la inauguración de la supercomputadora KanBalam en 2007 entre otros.

Conclusión En estos 50 años de la computación en México se ha demostrado el desarrollo que ha tenido esta floreciente ciencia gracias al tenaz esfuerzo de hombres y mujeres que están convencidos de que en este país hay oportunidad de alcanzar un sueño. Tal es el caso de los más de 400 doctores en computación o áreas similares que se encuentran en diferentes instituciones de educación superior en nuestro país. Vale la pena reflexionar sobre las palabras del Dr. Renato Iturriaga durante la conferencia de inauguración de los festejos por los 50 años de la computación en México: “La computación en el mundo ha tenido avances espectaculares y en el futuro lo serán aún más. Pero toda esa tecnología no ira al frente del hombre, sino detrás de él. El desarrollo de la computación en México lo han realizado, y lo están realizando, personas. Dicho desarrollo solo tiene sentido en tanto esté orientado a servir a los intereses de la sociedad en general y de las personas en lo individual. En 24 siglos no ha perdido vigencia el aforismo de Protágoras: el hombre es la medida de todas las cosas.”

Referencias: [cs.cinvestav.mx/SemanaComputoCINVESTAV/Computo.html] [lajornadadeoriente.com.mx/2008/01/28/puebla/] [computo50.unam.mx/computoenmexico2.html] www.sg.com.mx


// industria

25 Años Haciendo Investigación Un Vistazo al Pasado, Presente y Futuro en el CINVESTAV-IPN Por Carlos Coello

El año 1983 evoca para muchos, incontables memorias. Ese año se introdujo la IBM PC XT; la revista Time eligió a la computadora como la “máquina del año” (en vez del tradicional “hombre del año”), dedicándole su portada del ejemplar del 3 de enero; ARPANET estandarizó el protocolo TCP/IP (el cual se sigue usando hoy en día en Internet) y también se anunció el lanzamiento del Windows de Microsoft. Qué lejanos lucen esos días, en que aparecían los discos compactos en el mercado por primera vez y el uso del correo electrónico y el internet eran prácticamente desconocidos. El Centro de Investigación y de Estudios Avanzados del Instituto Politécnico Nacional (CINVESTAVIPN) contaba en aquel entonces con 7 minicomputadoras, distribuidas en los Departamentos de Fisiología, Farmacología, Toxicología e Ingeniería Eléctrica. Así mismo, habían decenas de microcomputadoras y se tenía acceso a un mainframe a través de diversas terminales. El Departamento de Ingeniería Eléctrica del CINVESTAV-IPN llevaba ya, en aquel entonces, varios años de impartir cursos sobre computación electrónica tales como “Introducción a la Computación”, “Teoría de Autómatas” y “Arquitectura de Computadoras”, entre otros. Así mismo, el uso de computadoras electrónicas se hacía cada vez más común. Fue en esta atmósfera que se gestó una propuesta1 para establecer un Departamento de Computación en el CINVESTAV-IPN hacia principios de 1983. En este punto, bien vale la pena reconocer los esfuerzos que realizaron los Dres. Héctor Nava Jaimes (entonces Director General del CINVESTAV-IPN), Juan Milton Garduño (entonces Jefe del Departamento de Ingeniería Eléctrica) y Adolfo Guzmán Arenas (fundador y primer Jefe de la Sección de Computación del CINVESTAV-IPN) para llevar a cabo esta empresa. Fue así como se gestó una propuesta que contemplaba 3 etapas. La primera etapa arrancó en el mismo 1983, creándose la Sección de Computación del Departamento de Ingeniería Eléctrica. Sin embargo, por diversas razones, fue hasta el año 2006 (más de 20 años después de lo esperado) que la segunda etapa, la creación del Departamento de Computación, se volvió finalmente una realidad2. La tercera etapa, creación de secciones dentro del Departamento de Computación, bien podría tomar más tiempo del que el autor viva para volverse una realidad. Actualmente, el Departamento de Computación del CINVESTAV-IPN cuenta con 16 investigadores de tiempo completo y 7 investigadores más en el CINVESTAV Tamaulipas. A la fecha ha graduado a más de 280 estudiantes de maestría y doctorado. En la semana del 1 al 5 de septiembre, se celebraron los 25 años de existencia de los programas de computación en el CINVESTAV-IPN3,

contando con destacados conferenciastas como: el Dr. Edmund Clarke (ganador del Premio Turing 20074 por haber desarrollado la herramienta conocida como Model Checking) de la Universidad Carnegie-Mellon, el Dr. Héctor García Molina (quien tiene el factor H más alto en computación a nivel mundial) de la Universidad Stanford, y el Dr. Alan Kay (ganador del Premio Turing 2003 y pionero de la POO e interfaces gráficas) del Viewpoints Research Institute, entre otros eminentes expertos. En este evento participaron también los 4 únicos computólogos de México que ostentan el nivel 3 en el Sistema Nacional de Investigadores: el Dr. Adolfo Guzmán Arenas, el Dr. Felipe Lara Rosano, el Dr. José Luis Marroquín Zaleta y el Dr. Carlos Artemio Coello Coello. Durante el evento se realizaron mesas redondas tratando temas como la situación actual de la computación en México, se llevó a cabo el “Primer Encuentro de Estudiantes que Cursan un Doctorado en Computación en México”, y el concurso de cuento titulado “La Computación del Siglo 21: entre lo natural y lo artificial de la inteligencia y la vida”. Tras la culminación de este año de celebraciones, bien nos vendría abrir un espacio para reflexionar sobre la dirección hacia donde quisiéramos que se moviera el grueso de la comunidad de computación en México en los años por venir. Ciertamente, esperamos un crecimiento importante de una comunidad que cuenta actualmente con unos 550 doctores, con un consecuente aumento del número de posgrados, así como de nuestra capacidad para vincularnos con el sector productivo. Sin embargo, también se espera que este crecimiento conlleve a una mayor consolidación de nuestros investigadores, de manera que esta comunidad tenga mayor peso específico en la toma de decisiones en torno a políticas científicas en México. De lograrlo, ese sería, sin duda, el mejor homenaje que se le podría rendir a una disciplina que, querámoslo o no, ha cambiado para siempre nuestro modo de vida.

Referencias [ 1. Anónimo. “Propuesta de Creación del Departamento de Computa ción del CIEA del IPN. Etapa I: Sección de Computación”. Presentado por el Departamento de Ingeniería Eléctrica, CIEA del IPN. 1983. ] [ 2. Coello Coello, Carlos Artemio. “El Departamento de Computación del Cinvestav”. Cinvestav. Abril-Junio 2007 . Vol. 26. No. 2, pp. 4-13. ] [ 3. cs.cinvestav.mx/SemanaComputoCINVESTAV ] [ 4. El Premio Turing (Turing Award) es otorgado por la Association for Computing Machinery (ACM), y es considerado como el reconocimiento técnico más importante que se otorga en el área de computación. ]

Carlos Artemio Coello Coello se doctoró en Ciencias de la Computación en la Universidad Tulane (en Estados Unidos), en 1996, haciendo trabajo pionero en el área de “optimización evolutiva multi-objetivo”. Actualmente es Investigador 3-D y Jefe del Departamento de Computación del CINVESTAV-IPN. Pertenece al Sistema Nacional de Investigadores (nivel 3) y a la Academia Mexicana de Ciencias.

www.sg.com.mx

NOV-ENE 2009

17 07


// COLUMNA

/*TEJIENDO NUESTRA RED*/

Aprovechando Áreas de Procesos de MoProSoft Reunión del WG24 en México

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.

L

a próxima reunión del grupo de trabajo WG24 del subcomité SC7 del JTC1 ISO/IEC se realizará del 10 al 14 de noviembre de este año en la Ciudad de México en las instalaciones de CANIETI. En esta ocasión se revisarán los comentarios, enviados por los países participantes en SC7, sobre la siguiente versión, Proposal Draft, de la ISO/IEC TR 29110 Software Engineering — Lifecycle Profiles for Very Small Enterprises (VSE). Este documento consta de las siguientes partes: • Part 1. Overview • Part 2. Framework and Taxonomy • Part 3. Assessment Guide • Part 4-1. Specification – Basic Profile • Part 5-1. Management and Engineering Guide – Basic Profile La primera parte explica por qué se decidió hacer un trabajo especial para acercar los estándares internacionales a organizaciones, departamentos o proyectos con menos de 25 personas, llamados Very Small Enterprises (VSE). La parte 2 propone marco y posible taxonomía para crear perfiles, subconjuntos de estándares existentes, con la finalidad de satisfacer necesidades específicas de este tipo de organizaciones. La parte 3 ofrece guía para la aplicación de evaluaciones de los perfiles usando como referencia el estándar ISO/IEC 15504-2. La parte 4-1 y 5-1 contienen la especificación y la guía de interpretación, respectivamente, del primer perfil definido para VSE, llamado Perfil Básico. A continuación trataré de contestar brevemente las siguientes preguntas:

08

NOV-ENE 2009

¿A quién está dirigido este perfil? y ¿qué elementos de NMX-I-059-NYCE-2005 MoProSoft se aprovecharon para crearlo? El Perfil Básico está dirigido a las VSE con las siguientes características: Financieras • Fuerte dependencia de ganancias de cada proyecto, • Necesidad de ingreso frecuente de dinero, • Proyectos de bajo presupuesto, bajo riesgo y duración de unos cuantos meses.

Relación con el Cliente • Un cliente por proyecto • Satisfacción del cliente depende de: • Cumplimiento de requerimientos que pueden cambiar durante el proyecto. • Información sobre los avances. • Entregas a tiempo. • Baja tasa de defectos encontrados después de la entrega.

Proceso Interno • Desarrollo de software bajo contrato u orden de trabajo. • Prácticas precarias de administración de proyectos y de desarrollo de software. • Desarrollo progresivo y consistente con los requerimientos del cliente. • Un solo canal de comunicación entre el grupo de desarrollo y el cliente. • Productos a desarrollar pueden tener más de una versión y estas deben ser resguardadas y controladas. • Gestión de recursos humanos, infraestructura y del portafolio de proyectos se realiza de manera informal.

Aprendizaje y Crecimiento • Conciencia de la importancia de estándares. • Falta de recursos humanos informados o capacitados en estándares. • Falta de conocimientos sobre la mejora de procesos y las evaluaciones.

Para crear la guía de interpretación del Perfil Básico se aprovecharon los dos procesos de la categoría de operación de MoProSoft, llamados en inglés Project Management y Software Implementation. Se eligieron las actividades, tareas, productos y roles de estos procesos correspondientes a los siguientes elementos:

Proceso de Administración de Proyectos Específicos (Project Management) • Planificación del proyecto con la identificación y estimación de tareas para un ciclo y su calendarización. • Monitoreo del avance del proyecto, acciones correctivas y cierre del proyecto con aceptación del cliente. • Recepción y análisis de las solicitudes de cambio tanto del cliente como del equipo de desarrollo. El análisis considera el impacto de cambio sobre los aspectos técnicos, costo y tiempo. Si el caso lo amerita, se actualiza el plan del proyecto. • Reuniones de revisión con el equipo de trabajo y con el cliente registrando los acuerdos. • Identificación y registro de riesgos durante el proyecto. • Identificación de elementos de configuración de software, definición y aplicación de www.sg.com.mx


la estrategia de control de versiones, resguardo y recuperación. • Aseguramiento de calidad de producto y de procesos mediante el cumplimiento de requerimientos y del plan del proyecto.

Proceso del Desarrollo y Mantenimiento de Software (Software Implementation) • Realizar tareas acorde al plan del proyecto. • Definición y análisis de requerimientos, con el fin de asegurar que sean correctos y susceptibles a ser probados, se validan con el cliente, se resguardan como línea base y se comunican a los interesados. • Se desarrolla el diseño arquitectónico detallado y se establece la trazabilidad con los requerimientos.

www.sg.com.mx

• Se producen componentes de software de acuerdo al diseño, se les aplican pruebas unitarias para asegurar la consistencia con el diseño y con los requerimientos. Se establece la trazabilidad de los componentes con el diseño y con los requerimientos. • Se definen pruebas para la integración de los componentes. Se integran los componentes aplicando las pruebas, se registran los defectos y se corrigen. • Se integra y resguarda la configuración de software con la documentación correspondiente y los manuales de usuario, operación y mantenimiento. • Se realizan las actividades de verificación y validación de los productos seleccionados para asegurar la consistencia entre ellos y la satisfacción del cliente.

Los defectos encontrados quedan registrados y corregidos manteniendo el control de versiones y el resguardo correspondiente. Los que conocen MoProSoft fácilmente identificarán lo que quedó incluido en el Perfil Básico y los que quieren conocerlo a mayor detalle pueden solicitar los documentos al comité de normalización de CANIETI. Una buena noticia que quiero compartir para finalizar esta entrega es que México cambió el estatus ante el ISO/IEC JTC1 SC7 dejando ser miembro O (Observador) y convirtiéndose en miembro P (Participante), lo que significa que no solamente podemos emitir comentarios sobre las normas sino que también podemos votar por ellas. » Por Hanna Oktaba

NOV-ENE 2009

09


// COLUMNA

/*MEJORA CONTINUA*/

“Premio Nacional de Calidad”, y La Norma MoProSoft Estrategias de Implantación 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.

Premio Nuevo León a la Calidad

E

l mes pasado SOFTTEK ganó el premio Nuevo León de Calidad. Esta es la primera vez que una empresa de software gana este premio. Me parece que a veces estamos dando mucha importancia a certificaciones estadounidenses con la finalidad de incrementar nuestras exportaciones pero tal vez estamos menospreciando recursos muy importantes que tenemos en nuestro país. El Premio Nuevo León de Calidad que se hace disponible en todos los estados de la República y la norma MoProSoft, son opciones que tenemos en nuestro país para establecer márgenes de mejora continua en nuestra industria de software. Mi experiencia es que estos modelos, aunque no todos están totalmente enfocados al desarrollo de software (MoProsoft sí está ligada directamente al software), se adaptan bastante bien a las ideas de manejo de procesos, toma de decisiones en base a métricas y mejora continua que son la base de todo modelo de calidad, adicionalmente las normas mexicanas tienden a ser más amplias a diferencia de CMMI. MoProSoft abarca no sólo el desarrollo de Software en sí, sino también temas complementarios como la planeación estratégica y prácticas de ecosistema de la organización. Creo que como industria de software deberíamos investigar más sobre estas normas y buscar como pueden apoyar a nuestras estrategias de calidad.

Estrategias de implantación La semana pasada mientras realizaba una presentación, volvió a surgir la duda de si es mejor hacer implantaciones proyecto por proyecto, o si es mejor implementar prácticas individuales en toda la organización (lo que en métodos numéricos se le conoce como “Depth First o Breath First”).

10

NOV-ENE 2009

Lo que yo veo en la industria del software en México es que tenemos comprada la idea de que lo más importante es implementar a profundidad un concepto en un proyecto para después pasar al siguiente. En mi opinión esta es la razón principal por la que los proyectos de implementación fallan. Implementar a profundidad sólo funciona en organizaciones pequeñas, ya que ésta puede hacerse rápido en todos los proyectos, pero en una organización mayor a esto es un fracaso. Por ejemplo, supongamos que implementamos un modelo para estimar el costo de cambios dentro de los proyectos. Usualmente lo que se hace es tomar los proyectos que tienen la mayor cantidad de problemas con el crecimiento de número de requerimientos y se asigna el proyecto a la persona que tiene más experiencia en estimar para que haga lo necesario para cambiar la forma en la que se está estimando el cambio. Esta persona maneja la resistencia al cambio, el entendimiento de la problemática del cliente en especifico, y seguramente después de algo de trabajo se logrará arreglar la situación con ese primer proyecto y estaremos listos para continuar al siguiente. Desafortunadamente, los demás líderes de proyecto se sienten atacados por el éxito descrito anteriormente, y se dedican a argumentar que su proyecto es muy diferente y por lo tanto estas prácticas no son aplicables a su proyecto. Mientras esto sucede, nuestro proyecto inicial termina y nuestro experto en estimación es reasignado como analista en un proyecto dirigido por otra persona, por lo que ya no tiene el control, y tampoco tiene la habilidad de convencer al líder actual de cómo manejar la estimación. Esto hace que se pierda el trabajo y finalmente lo que tenemos es a un experto constantemente asignándose a

proyectos en problemas y tratando de sacar adelante la situación. La otra forma de implementar esto mismo sería: generar un curso del nuevo modelo de estimación, y entrenar a todos los líderes de proyecto. Después se auditan los proyectos para evaluar quien implementó qué, y se crea una estrategia en donde el experto en estimación salta de proyecto en proyecto asesorando a los líderes para que cada vez apliquen mejor el proceso de estimación. Como primer paso, logramos que todos entiendan que la estimación se logra en base a definir tamaños de los productos, que entiendan cómo calcular líneas de código o puntos funcionales en sus proyectos. Después que entiendan como pasar de líneas funcionales a horas, y así sucesivamente. Esta estrategia ofrece las siguientes ventajas: 1. Nuestro experto en estimación invierte un tiempo muy parecido al anterior, pero ahora ayudando y convenciendo más que haciendo él mismo. 2. Permite que la responsabilidad de la estimación recaiga en donde tienen que recaer, el líder del proyecto. 3. No se esta detrás de los problemas todo el tiempo. Cuando un líder sale de un proyecto y pasa a otro, el otro líder está más o menos en el mismo nivel que estaba él en su proyecto, por lo que permite que hablen el mismo idioma y que pueda aplicar lo que aprendió en su proyecto anterior para mejorar el nuevo proyecto. A final de cuentas vamos pasando de un modelo reactivo a un modelo pasivo. ¿Qué nos acerca mas a nuestro objetivo?. » Por Luis Cuellar www.sg.com.mx


www.sg.com.mx

NOV-ENE 2009

11


// PRODUCTOS

/* LO QUE VIENE*/

VSTS 2010 Nue va s

c a pa c i d a d e s d e m o d e l a d o y t e s t i n g

Mono 2.0 Ya

Microsoft dió a conocer los planes para la próxima generación de sus herramientas y plataforma de desarrollo: Visual Studio 2010 y .NET 4.0. Como parte de esta plataforma también habrá una nueva versión de la herramienta para la colaboración de equipos de trabajo, Visual Studio Team System (VSTS) 2010. Las innovaciones en VSTS 2010 se enfocan principalmente en mejorar las capacidades para el modelado visual y la administración de pruebas de software. Las nuevas capacidades de modelado en VSTS 2010 son un componente central de la iniciativa de modelado de Microsoft, conocida con el nombre clave “Oslo”. La información que ha liberado Microsoft hasta el momento es bastante vaga, y se espera que el panorama quede más claro después de la conferencia de desarrolladores (PDC 2008) que se realizará a finales de octubre. Más información en msdn.microsoft.com

l l e g ó s up e r c h a n g o

Mono 2.0 por fin fue liberado. Mono es una implementación en software libre del Framework .NET de Microsoft. A pesar de que todavía le falta bastante para cubrir todo el espectro de APIs de .NET, con esta versión ya se soportan los componentes de mayor relevancia y que utilizan el grueso de las aplicaciones. Entre los APIs soportados por Mono 2.0 resaltan ADO.NET 2.0, ASP.NET 2.0, Windows. Forms 2.0, System.XML 2.0, System.Core (LINQ), y System.Drawing 2.0. En el área del compilador, la capacidad de mayor importancia en esta versión es el soporte completo de C# 3.0, incluyendo LINQ to Objects, y LINQ to XML. Mono funciona en una gran variedad de plataformas que van desde las tradicionales como Windows, Linux y OS X, hasta el iPhone y el Nintendo Wii. Más información en www.mono-project.com

Beehive Oracle

se une al

Web 2.0

e mpr e s a r i a l

Durante el reciente Oracle OpenWorld, uno de los nuevos productos que recibió mayor atención fue Oracle Beehive. Beehive es una plataforma integrada para colaboración empresarial. Esencialmente, es una plataforma que busca integrar espacios de trabajo colaborativos, calendarios, mensajería instantánea y correo electrónico. A pesar de que en el mercado ya existen productos empresariales con funcionalidad muy similar, tales como Lotus Connections y Microsoft Sharepoint, Oracle argumenta que su producto brinda ventajas en cuanto a seguridad e integración con productos de terceros. Aun así, seguramente lo que estaremos viendo es que las empresas optarán por una u otra solución dependiendo del resto de la infraestructura que ya tengan. Aquellos clientes que ya estén usando el middleware de Oracle, seguramente se sentirán más cómodos con Beehive que con las opciones competidoras. Más información en www.oracle.com/products/middleware/beehive

12

NOV-ENE 2009

www.sg.com.mx


www.sg.com.mx

NOV-ENE 2009


// PRODUCTOS

/*herramientas*/

Beneficios de la Automatización de Pruebas Ahorrando Tiempo y Recursos Por Benjamín Alonso

¿Cómo sabes que el sistema funciona? Una respuesta común a esta pregunta es “porque el equipo de testing le echó un vistazo”. El problema viene al tener que determinar la extensión y profundidad de las pruebas realizadas. Si eres afortunado y trabajas en una empresa con buenos procesos, podrás acreditar lo probado a través de una lista de casos de prueba. Si trabajas en una empresa de clase mundial, entonces hay una gran posibilidad de que tengas la fortuna de tener a tu disposición herramientas para la gestión y automatización de pruebas. De acuerdo con Elfriede Dustin, las herramientas de automatización de pruebas consolidan y mejoran la efectividad de las pruebas siempre y cuando se manejen las expectativas, se entiendan las herramientas, y se seleccione una herramienta compatible con el ambiente de programación. Si necesitas probar un sistema no trivial que conste de algo más que unas cuantas pantallas y reportes, entonces es muy posible que por medio de pruebas manuales no logres realizar todas las pruebas que necesitas para verificar la calidad del sistema. Con la ayuda de herramientas de automatización puedes ejecutar más pruebas, lo cual se traduce en una mayor cobertura del sistema que se está probando. Capers Jones, en su libro de estimación de costos de software, menciona que las pruebas de funcionalidad, regresión y rendimiento son comúnmente apresuradas (o incluso omitidas) por presiones de tiempo. Esto resulta en sistemas con baja calidad. ¿Alguna vez te has visto en la necesidad de apurar u omitir alguna de estas pruebas? ¡Por supuesto que sí! Es una práctica común en los proyectos de desarrollo. Las compañías más exitosas automatizan sus pruebas para mejorar la flexibilidad de su equipo de desarrollo. Algunas de las metas de sus esfuerzos incluyen: • Detectar cambios desestabilizadores en nuevas construcciones del sistema. • Exponer defectos de regresión tan pronto como es posible. • Reportar problemas rápidamente porque esto facilita su corrección.

Beneficios de las pruebas automatizadas Las herramientas de automatización no van a solucionar todos tus problemas de pruebas. Sin embargo, puedes obtener muchos beneficios con una implementación apropiada. Hablemos de algunos de estos beneficios: • Mejor organización de las pruebas. Cuando inicias la automatización de tus pruebas, analizas de manera más estructurada. Examinas tu sistema como ingeniero, ya no de manera empírica. Al crear casos de pruebas formulas preguntas tales como: ¿es repetible esta prueba?, ¿con qué frecuencia necesito ejecutar esta prueba?, ¿tiene alguna semejanza esta prueba a pruebas existentes?, ¿cómo automatizaría esta prueba? • Realización de un mayor número de pruebas. Algunos de los problemas hallados por la automatización, tal vez no hubieran sido encontrados utilizando solo pruebas manuales, debido a limitantes de tiempo. • Mejoras en la comunicación con el equipo. Kaner, Bach, y Pettichord argumentan que la automatización fortalece las pruebas al proporcionar un sistema para recolectar y diseminar información de manera eficaz, proporcionando retroalimentación oportuna al equipo de programación. • Estabilización temprana del código. Conforme encontremos los errores más temprano, tendremos más rápido una base de código estable. Esto evitará retrabajo posterior ya que no estaremos construyendo encima de un código con errores. • Habilitación de pruebas de regresión. Con un conjunto apropiado de pruebas, y habilitados por una herramienta de automatización, cada que generamos un nuevo build de nuestro sistema de software podemos probarlo por completo. Esto es de vital importancia, ya que de acuerdo con un estudio realizado por Capers Jones, en promedio el 7% de las correcciones de defectos inyectan a su vez un nuevo defecto.

Benjamín Ruvalcaba Alonso tiene más de 18 años de experiencia en proyectos de informática. Ha trabajado en Microsoft, GE, y otras empresas públicas y privadas. Ha dedicado los últimos seis años al testing de diversas aplicaciones web en ambientes .Net. Puedes contactarlo en benalonso@pickyware.com

14

NOV-ENE 2009

www.sg.com.mx


“¿Alguna vez te has visto en la necesidad de apurar u omitir alguna de estas pruebas? ¡Por supuesto que sí!”.

De hecho, Dustin argumenta que si las pruebas de regresión no estuvieran automatizadas, ciertas pruebas regresivas nunca serían ejecutadas, dejando grandes vacíos en los esfuerzos de prueba. • Mayor confiabilidad en los resultados. El sistema de automatización no se cansa, nunca tiene prisa, y mientras las pruebas o su información no cambie, deben de obtener siempre el mismo resultado; son consistentes, confiables, y repetibles. Como seres humanos te cansas, preocupas, o simplemente apresuras en sacar tu trabajo a tiempo. Todo esto lleva a simples errores humanos que afectan tu capacidad de ser eficiente en pruebas rutinarias. La automatización de pruebas repetitivas que requieren una ejecución frecuente, te permite tiempo para integrar pruebas más complejas, probar nuevas funciones dentro de la aplicación y su integración con el resto del sistema. • Capacidad para aplicar pruebas complicadas. Algunos tipos de prueba son difíciles de aplicar o muy complicadas de ejecutar de manera manual; entre esta rama podemos encontrar aquellas en las que es necesario el acceso a la base de datos para verificar que la información del sistema sea correcta, o tal vez sea preciso hacer cálculos manuales para verificar la validez de los resultados arrojados por el sistema. Muchas herramientas de automatización proporcionan estas funcionalidades. Además, los sistemas de automatización nos pueden auxiliar a introducir grandes cantidades de información, configurar la versión de prueba de la base de datos, y generar información aleatoria entre otras cosas.

Como No Justificar el Testing Después de revisar los principales beneficios de la utilización de herramientas de pruebas automatizadas, quiero compartir con ustedes algunas recomendaciones planteadas por James Bullock acerca de lo que debemos evitar a toda costa al justificar un esfuerzo de testing hacia nuestros superiores. • La narrativa sin fin. Una cosa es hacerle ver a nuestros superiores que sabemos de lo que estamos hablando, y otra es perderlos en los detalles técnicos. Lo que tus jefes quieren que les contestes es ¿cuánto?, ¿cómo?, y ¿dónde?; Debes estar preparado para contestar estas preguntas en forma abreviada, concreta, y veraz.

www.sg.com.mx

• Vender funcionalidades en lugar de beneficios. Cuando hablamos de testing se nos olvida mencionar cómo beneficia al cliente, producto, o empresa. Tendemos a hablar de todo lo que vamos a poder hacer sin mencionar los beneficios. No importa lo avanzada que sea la herramienta de automatización o ese nuevo proceso manual que deseas implementar, si no puedes ligarlo a beneficios tangibles. Necesitas identificar que el testing, ya sea automatizado o no, sí beneficia al cliente, producto o empresa. • La solución única. A algunos de nosotros nos gusta pensar que nuestra función es la más importante en la compañía. Sin embargo, tenemos que observar nuestro trabajo como una pieza más en el ecosistema de la empresa. Esto nos facilita analizar cómo nuestra labor complementa y asiste a otras áreas. Somos más valiosos como parte integral de la empresa que como un elemento aislado de la misma.

Conclusión Hoy en día, la automatización de pruebas es una tarea esencial para proporcionar un servicio de testing adecuado. Los sistemas que probamos han crecido tanto en tamaño como en complejidad. Necesitamos tener el tiempo de probar las nuevas funcionalidades de nuestros sistemas sin ignorar la funcionalidad previa. Una estrategia de automatización implementada apropiadamente nos ayudará a lograrlo junto con los demás beneficios mencionados en este artículo.

Referencias [ Bullock, James. “Calculating the Value of Testing”. Software Testing and Quality Engineering. May/June 2000 ] [ Jones, Capers. Estimating Software Costs: Bringing Realism to Estimating. McGraw Hill, 2007. ] [ Dustin, Elfriede. Effective Software Testing: 50 Specific Ways to Improve Your Testing. Addison-Wesley, 2002.] [ Kaner, Cem; Bach, James; Pettichord, Bret. Lessons Learned in Software Testing: A Context Driven Approach. Wiley, 2001.]

NOV-ENE 2009

15


// PRODUCTOS

/*tutorial*/

Desarrollo de Aplicaciones Silverlight Parte 2. Eventos desde XAML y Javascript Por Guillermo Morales

Bienvenidos a esta segunda parte de nuestro tutorial sobre desarrollo de aplicaciones Silverlight. En base a lo que hicimos en la parte 1 (SG Num. 21), deberíamos tener los siguientes archivos: • crearSilverlight.js • Default.html • Mixaml.xaml • Silverlight.js

Respondiendo al click del mouse

Height=”100” Width=”100” Canvas.Left=”100” Canvas.Top=”50” Stroke=”Black” StrokeThickness=”10” Fill=”Blue”/>

<TextBlock x:Name=”miTexto” Canvas.Left=”70” Canvas.Top=”180” Text=”Dame Click” FontSize=”30”/> </Canvas>

Noten que tanto el TextBlock como el Rectangle, tienen una propiedad x:Name por medio de la cual podemos identificar a cada elemento dentro del XAML. Utilizaremos esto más adelante en el código Javascript. Al visualizar nuestra página web, obtendremos lo que se ve en la siguiente figura.

Vamos a crear un elemento que pueda responder a eventos del mouse, para comenzar a darle más interacción a nuestros sitios Silverlight. La forma y el concepto son muy sencillos: en el XAML se declaran los eventos que queremos estar observando, y se indica la función de Javascript que debe dispararse con cada evento. Dichas funciones de Javascript las podemos definir en el archivo HTML o en un archivo .js. Veamos como se implementa esto en código. Primero, modificaremos nuestro archivo XAML para que quede como el listado 1. Listado 1. mixaml.xaml <Canvas Width=”300” Height=”300” xmlns=”http://schemas.microsoft.com/client/2007” xmlns:x=”http://schemas.microsoft.com/winfx/2006/xaml”> <Canvas.Background> <LinearGradientBrush EndPoint=”0.5,1” StartPoint=”0.5,0”> <GradientStop Color=”#FFDCEF1B” Offset=”0”/> <GradientStop Color=”#FF801A1A” Offset=”1”/> </LinearGradientBrush> </Canvas.Background> <Rectangle x:Name=”r1” MouseEnter=”r1Entrar” MouseLeave=”r1Salir” MouseLeftButtonDown=”r1Abajo” MouseLeftButtonUp=”r1Arriba”

Insertando código javascript El siguiente paso es definir las funciones de Javascript que respondan a los eventos que se disparan desde el XAML. Para esto, insertaremos en nuestra página web el código Javascript del listado 2. Este código lo pueden insertar dentro del mismo bloque de código <script> donde se encuentra la obtención de la referencia al plugin de Silverlight que ya se tiene. Listado 2. Funciones en Javascript function r1Entrar(sender, args) { sender.stroke = “red”; sender.findName(“miTexto”).Text = “Rojo”; }

Guillermo Morales colabora actualmente en InterSoftware, empresa dedicada a la capacitación especializada en desarrollo de software. Con un perfil técnico, se ha desenvuelto en varias áreas del proceso de desarrollo de aplicaciones, desde la implementación, hasta la administración de proyectos. Es cofundador de la comunidad de desarrollo en México www.developersdotnet.com en donde frecuentemente se reúne con otros expertos de desarrollo de aplicaciones para la difusión de nuevas tecnologías.

16

NOV-ENE 2009

www.sg.com.mx


“Crearemos un elemento que pueda responder a eventos del mouse, para comenzar a darle más interacción a nuestros sitios Silverlight”.

function r1Salir(sender, args) { sender.stroke = “black”; sender.findName(“miTexto”).Text = “Negro”; } function r1Abajo(sender, args) { sender.stroke = “yellow”; sender.findName(“miTexto”).Text = “Diste Click”; } function r1Arriba(sender, args) { sender.stroke = “Green”; sender.findName(“miTexto”).Text = “Verde”; }

En este código podemos observar dos cosas: • Los eventos disparados desde el XAML, reciben dos parámetros:

• Mediante el método findName localizamos a elementos específicos dentro del XAML, en este caso, el objeto que estamos localizando y manipulando es el Rectángulo al cual nombramos “miTexto”. Con esto tenemos una página cuyos elementos XAML disparan eventos en javascript.

Conclusión Ya tenemos una página cuyos elementos XAML responden al comportamiento del mouse y disparan funciones javascript.En futuros artículos incluiremos una animación, un video y más eventos para atraparlos con el mouse. Suerte, y hasta la próxima.

- sender: Corresponde al objeto que inicia la acción - args: Corresponde a información relacionada al evento disparado

www.sg.com.mx

NOV-ENE 2009


Encuesta de Salarios 2008 Por Pedro Galván

Ha llegado ese momento del año en que echamos un vistazo a la compensación que recibimos por nuestro trabajo y evaluamos qué tan justa es la compensación que recibimos, y cuales son las habilidades o características que debemos desarrollar para aspirar a un mejor salario. Sin más preámbulo, compartimos con ustedes los resultados de la Encuesta de Salarios SG 2008.

Acerca de la fuente de información La información que se muestra aquí es resultado de una encuesta abierta contestada por 2,162 personas a través del sitio web de SG durante el mes de octubre del 2008.

Salarios a primera vista

Primero, lo primero. Y eso es averiguar como están actualmente los salarios de profesionistas de tecnologías de información en México. La tabla 1 muestra el tabulador de salarios por rangos, indicando el porcentaje de personas que caen en cada uno. Rango de salario mensual Menos de 4 mil 4 a 6 mil 7 a 10 mil 11 a 15 mil 16 a 20 mil 21 a 25 mil 26 a 30 mil 31 a 40 mil 41 a 50 mil 51 a 60 mil 61 a 80 mil Más de 80 mil

66 103 296 354 351 278 214 199 97 48 44 43

3.15% 4.92% 14.14% 16.91% 16.77% 13.28% 10.22% 9.51% 4.63% 2.29% 2.10% 2.05%

Tabla 1. Tabuladores de salario mensual

18

NOV-ENE 2009

www.sg.com.mx


El promedio ponderado de estos valores nos indica que el salario promedio de un profesionista de TI en México es de $22,570 pesos mensuales. Este valor significa un aumento de 13% comparado con el valor obtenido en el 2007, de $19,946. Habría que comparar esto con la inflación real en este periodo de tiempo para determinar si hubo un aumento real en el salario o si simplemente fue un ajuste inflacionario.

Remuneración adicional

Aunque el principal componente de la compensación laboral es el salario, otro elemento muy importante son las remuneraciones adicionales. La tabla 2 es un tabulador del valor al que ascienden las prestaciones recibidas anualmente, tales como aguinaldo, bonos, reparto de utilidades, etc. Rango de compensación extra anual Ninguna Menos de 10 mil De 10 a 25 mil De 25 a 50 mil De 50 a 100 mil Más de 100 mil

21% 20% 27% 16% 9% 6%

Tabla 2. Tabulador de compensación extra anual

Prestaciones

Como elemento final de la compensación tenemos a las prestaciones. La tabla 3 indica las prestaciones más comunes, y el por-

www.sg.com.mx

centaje de los encuestados que recibe cada una. Estos valores son prácticamente iguales a los de hace un año.

Prestación Gastos médicos mayores Horario flexible Préstamos Bonos por desempeño Gastos médicos menores Teléfono celular Trabajo desde casa Ayuda para educación Automóvil Ayuda familiar Departamento Acciones (stock options)

% 44.7% 36.5% 33.1% 29.5% 22.2% 19.2% 13.5% 12.1% 7.2% 6.5% 6.1% 4.5%

Como es costumbre, varios colegas internacionales (o expatriados) nos hicieron favor de contestar la encuesta. Mostramos el listado de aquellos países de los que obtuvimos un mínimo de 10 respuestas. Otros países fueron descartados por tener una muestra de respuestas demasiado pequeña como para ser confiable.

Estado DF NL Edomex Querétaro Jalisco

Salario

%

28,899 25,885 22,232 21,031 19,842

35.2% 8.3% 9.7% 4.5% 8.7%

Tabla 4. Estados con salarios más altos

Tabla 3. Prestaciones recibidas

De acuerdo a la región

El DF recuperó su liderazgo en este año como el estado de la República con los mejores sueldos para profesionistas de software, dejando a Nuevo León en segundo lugar y al Estado de México en tercero. Como es de esperarse, estos estados son también los que emplean a un mayor porcentaje de los profesionistas de software en nuestro país. En la no muy honrosa lista de los estados con los sueldos más bajos tenemos a Tlaxcala, Colima, Chiapas, Oaxaca y Veracruz.

NOV-ENE 2009

19


los. En países desarrollados, estas empresas son las que ofrecen los salarios más altos, ya que son las que tienen mayor necesidad de talento e innovación. Sin embargo, en nuestro país parece ser todo lo contrario.

Estado Tlaxcala Colima Chiapas Oaxaca Veracruz

Salario

%

9,667 11,273 11,632 11,708 12,127

0.7% 0.5% 0.9% 0.6% 2.9%

En la tabla 8 mostramos un cruce entre el tipo de organización y el esquema de pago manejado (nómina, honorarios o externo subcontratado). Como era de esperarse, las áreas usuarias son las que tienen un porcentaje mayor de personas en esquema de nómina, con casi el 85% de su personal. En cambio, las empresas proveedoras de servicios tienen solamente un 48% en nómina y el resto están por honorarios o contratados como independientes.

Tabla 5. Estados con salarios más bajos

País USA España Perú Chile Colombia Argentina

Salario 64,588 41,000 20,938 20,333 12,600 9,667

Tabla 6. Resultados de otros países

Tipo de organización

La tabla 7 divide las respuestas obtenidas a partir del tipo de organización donde laboran. El patrón es el mismo que hemos encontrado en años anteriores. Las empresas proveedoras de servicios de TI son las que ofrecen los mejores salarios (aunque ofrecen prestaciones muy bajas, mientras que las áreas usuarios son las que ofrecen la compensación total (salario mas prestaciones) más alta. Aunque la mayoría de los profesionistas de TI todavía laboran en áreas usuarias, poco a poco va aumentando el porcentaje que labora en empresas proveedoras. Esto es una consecuencia natural de la tercerización de los servicios de TI.

Tipo

Salario

Prestaciones

%

Proveedor de servicios Area de sistemas Distribuidor de producto de TI Otra organización Desarrollo de productos empaquetados Educación/Capacitación

25,122.48 23,102.14 21,986.11 20,314.01

1,680.30 2,600.71 2,708.33 2,155.80

28.5% 44.7% 1.7% 9.9%

19,906.25 15,150.35

1,625.24 1,739.51

8.4% 6.8%

Tabla 7. Salarios y prestaciones por tipo de organización

Tipo Proveedor de servicios Área usuaria Distribuidor/Canal ISV Educación

Nómina

Honorarios

Externo

48.0% 84.5% 67.7% 70.4% 80.8%

40.0% 13.1% 29.4% 19.5% 16.1%

12.0% 2.4% 2.9% 10.1% 3.1%

Tabla 8. Relación entre tipo de organización y esquema de pago

Género

Como podemos ver en la tabla 9, la participación del sexo femenino en nuestra profesión sigue siendo muy baja, y con un salario significativamente menor. La diferencia de salario es del 33%, la cual es prácticamente igual que la estimada el año anterior (33%).

Genero Femenino Masculino

Salario 17,513.25 23,423.23

% 14.4% 85.6%

Tabla 9. Salario por género

Un punto que llama la atención sobre los resultados de este año es el salario promedio en los ISV. Estas son las empresas que se dedican a desarrollar productos de software propios para posteriormente comercializar-

20

NOV-ENE 2009

Edad y Experiencia

Tal como lo hemos visto en las encuestas de años anteriores, el salario de un profesionista de TI sube paulatinamente de acuerdo a su edad, y llega a un máximo entre las personas que tienen 50 a 59 años. Posteriormente baja drásticamente después de los 60.

www.sg.com.mx


Como es de esperarse, el comportamiento respecto a los años de experiencia es similar, tal como se puede apreciar en la tabla 11. Analizando esta tabla, vemos que le hacen falta más escalas después de los 10 años de experiencia, para poder analizar a este segmento en mayor detalle. Haremos ese ajuste para la próxima encuesta de salarios.

Estado

Salario

18 a 24 25 a 29 30 a 39 40 a 49 50 a 59 60 o mas

11,410 17,378 25,563 37,166 46,276 27,143

% 14.6% 31.9% 40.5% 10.4% 2.3% 0.3%

Función

Salario

Alta Dirección Dirección de sistemas Ventas Arquitecto Project Manager Consultor Seguridad Administrador de sistemas TI en General DBA Aseguramiento de Calidad Desarrollador Soporte Redes Docente Webmaster

45,263.9 41,892.9 30,902.4 28,754.5 27,498.4 23,553.9 23,404.8 21,450.8 21,351.4 17,800.0 17,449.4 17,256.9 14,884.6 13,939.4 13,710.5 12,913.0

% 3.4% 4.7% 2.0% 5.4% 14.9% 8.0% 1.0% 6.3% 6.6% 2.6% 3.8% 31.2% 3.7% 1.6% 2.7% 2.2%

Tabla 10. Salarios de acuerdo a la edad Tabla 12. Salarios por función

Estado Menos de un año 1a3 3a5 5 a 10 Mas de 10

Salario

%

10,328 12,746 17,706 23,304 33,871

6.4% 20.8% 17.1% 25.0% 30.7%

Tabla 11. Salarios de acuerdo a la experiencia

De acuerdo al tipo de trabajo

Como sabemos, existe una gran cantidad de perfiles y tipos de trabajo en nuestra profesión. Obviamente, unos son mejor pagados que otros. Como es de esperarse, los directores son los mejor pagados, pero veamos como se compara el sueldo para el resto de las funciones. Hay que resaltar que en comparación con los resultados del año anterior, el único perfil cuyo salario promedio no aumentó es el de webmaster. Y si tomamos en cuenta la inflación, nos daremos cuenta que la compensación real disminuyó. Tal parece que conforme las herramientas han hecho más fácil la instalación y administración de sitios web, hay más personas que pueden hacer esta actividad y por lo tanto este perfil se ha devaluado.

www.sg.com.mx

Escolaridad

El máximo grado de estudios completado brinda un fiel reflejo de la compensación a la que se puede aspirar. En esta ocasión, nos llama la atención el hecho de que la compensación de quienes tienen maestría quedó por debajo de quienes solamente tienen otro tipo de postgrado (como un diplomado) que requiere menos dedicación. La explicación pudiera estar en que este tipo de postgrados normalmente están más apegados a las actividades reales que se realizan en el trabajo, y por lo tanto es más fácil aplicar los conocimientos adquiridos. Adicionalmente, al requerir menos esfuerzo, permiten que las personas no se tengan que despegar tanto de su trabajo y por lo tanto no afectan tanto su ritmo de crecimiento profesional.

Escolaridad Doctorado Postgrado Maestria Universidad titulado Universidad sin titular Bachillerato

Salario 40,523 31,201 29,827 21,853 17,552 16,848

% 1.1% 6.1% 16.2% 46.3% 27.5% 2.8%

Tabla 13. Salario por grado de estudios terminado

Conocimientos y habilidades

Los profesionistas de software nos enorgullecemos principalmente por nuestros conocimientos técnicos, y sabemos que estos tienen un gran impacto en el salario al que podemos aspirar. En términos de estos conocimientos, el patrón se mantiene respecto a años anteriores. Cobol y Mainframe siguen siendo el lenguaje y plataforma mejor pagados.

NOV-ENE 2009

21


Lenguaje Cobol .Net JEE Flex Perl JME JSE ASP C VB Delphi Php

Salario 30,909 27,827 26,577 26,000 24,719 23,928 23,639 23,256 23,039 20,432 19,807 18,530

% 3.9% 20.7% 26.7% 3.2% 4.7% 4.3% 32.5% 25.5% 17.8% 34.1% 7.7% 23.6%

Tabla 14a. Lenguajes de programación

Plataforma

Salario

Mainframe Unix AS400 Windows Mobile Windows Mac Linux DOS Tabla 14b. Plataformas

33,454 28,607 27,898 25,907 22,423 22,212 21,777 21,300

% 4.7% 27.8% 5.6% 10.3% 90.0% 7.2% 36.0% 12.8%

Base de Datos

Salario

DB2 Informix Sybase Oracle SQL Server PostgreSQL MySQL Firebird

29,251 27,965 27,342 26,217 23,140 20,656 20,025 19,015

% 13.5% 8.8% 6.5% 39.3% 59.8% 9.8% 38.9% 3.2%

Tabla 14c. Bases de datos

Aplicación BPM BI CRM ERP

Salario 35,922 28,978 28,734 24,483

% 7.9% 24.6% 14.5% 52.3%

Tabla 14d. Aplicaciones empresariales

Otras habilidades EDI PM Procesos Test UML Redes Diseño Gráfico

Salario 29,022 28,045 26,431 26,294 22,970 20,234 18,150

Tabla 14e. Otras habilidades

Conclusión

% 3.3% 51.0% 35.7% 24.6% 44.9% 27.4% 19.1%

Certificaciones

La mejor forma de demostrar nuestros conocimientos sobre alguna práctica o tecnología específica es una certificación. La certificación reina sigue siendo la de Project Management Professional (PMP) del PMI. Por otro lado, la gran demanda de consultores de SAP que ha habido en los últimos años ha provocado que esta certificación aumente su valor significativamente, ya que de tener un sueldo promedio hace un año de poco más de 30 mil pesos, este año supera los 40 mil. Otra certificación que también se está codiciando bastante es la de Microsoft Systems Engineer, cuyo sueldo promedio aumentó más de 10 mil pesos respecto al año pasado.

Certificación PMP SAP Microsoft - Systems Engineer Seguridad Sun - Solaris OMG - UML Oracle IBM - DB2 Calidad - SQA IBM - Rational Microsoft - DBA Ingeniería de software (SEI) Microsoft - Solution Developer Sun - Java Microsoft Professional Linux

Salario

%

43,215 40,826

5.5% 2.1%

40,794 38,000 37,048 35,929 35,577 35,405 35,023 34,229 31,000

1.6% 1.6% 1.0% 1.3% 3.1% 1.0% 2.1% 1.2% 1.4%

29,429

3.7%

28,039 27,981

3.1% 7.7%

26,418 25,900

7.0% 2.9%

Tabla 15f. Salario por Certificaciones

Los salarios de los profesionistas de TI aumentaron alrededor de un 13% del 2007 al 2008. Las posiciones de mayor complejidad administrativa tales como la alta dirección, la gerencia de proyectos y las ventas son las que acaparan los mayores sueldos. La excepción es el perfil de arquitecto de sistemas, el cual es netamente técnico y alcanza a manejar un salario mayor que el de un gerente de proyectos. En el caso de los conocimientos técnicos y certificaciones, Cobol sobre Mainframe se mantiene como la que es mejor compensada, debido a la escasez de personal. .Net y Java EE se mantienen como opciones bien compensadas ya que la cantidad de personal calificado disponible no es suficiente para la demanda del mercado. Para el 2009, el panorama económico actual nos hace pensar que los salarios no recibirán un ajuste más allá de la inflación. La recomendación es mantenerse en su empleo actual y aprovechar el año para desarrollar sus habilidades y conocimientos, con miras a que las cosas mejoren hacia final de año. Hay que ser cautelosos pero tampoco es para alarmarse, ya que la demanda existente de profesionistas de TI asegura que cualquier persona con dominio de inglés y capacidad para desarrollar software tenga un empleo estable.

28 22

NOV-ENE 2009

www.sg.com.mx


Las Mejores Empresas para Trabajar Prácticas de RH que llevan al Éxito Por Emmanuel Olvera

Recuerdo perfectamente cuando en un congreso internacional de Recursos Humanos, uno de los ponentes preguntó cuantos directores generales había presentes entre la audiencia, y menos de cinco manos se levantaron entre cientos de participantes. ¿No sería importante que los directores generales conocieran las mejores prácticas para la gestión de recursos humanos? ¿No les interesará conocer el impacto que tienen estas prácticas en la rentabilidad del negocio? En un estudio realizado por Hay Group entre empresas del Fortune 500 se detectaron las 7 mejores prácticas comunes entre estas empresas, y resultó que 3 de estas prácticas están directamente relacionadas con el factor humano. GE, Toyota, Berkshire Hathaway, Nokia, y BMW son algunas de las organizaciones que encabezan este ranking, y son de las empresas más admiradas del planeta. Entre 2004 y 2007, por ejemplo, brindaron a sus accionistas una rentabilidad media de 19,6 por ciento, casi el triple que el 7,1 por ciento del ranking de Standard & Poor’s para el mismo período. ¿Qué han hecho para llegar (y mantenerse) en la cima? ¿Cuáles son los factores que explican el desempeño sobresaliente? A continuación doy una breve descripción de las prácticas de RH comunes entre estas organizaciones: 1. El éxito a través de las personas. Probablemente, el factor más importante que distingue a estas empresas es un enfoque para lograr el éxito a través de la gente. Los líderes de estas organizaciones dedican el 30 por ciento de su tiempo a desarrollar talento y entrenar al personal. Estas compañías son más proclives a implementar estrategias y métricas relacionadas con el cuidado del capital humano. Suelen tener planes de sucesión bien definidos y contratar al CEO dentro de la organización. Como expresó Jack Welch, ex CEO de GE: “Mi trabajo principal era desarrollar talento. Era un jardinero que proveía agua y otros nutrientes a nuestras mejores 750 personas. Por supuesto, también tuve que eliminar algunas malas hierbas”. 2. Fuerte cultura organizacional. La cultura organizacional representa, en general, la forma en que se hacen las cosas y los valores que guían la conducta de los miembros de la compañía. En las empresas más admiradas, los líderes suelen compartir una visión común sobre la cultura actual y cómo debería ser en el futuro. Esta cultura tiende a promover la iniciativa individual y el trabajo en equipo, impulsando la innovación y la lealtad de los empleados.

portantes en tiempos de inseguridad económica. Y, precisamente, las empresas más admiradas son más exitosas en mantener altos niveles de lealtad y motivación en tiempos difíciles. Una de las claves es asegurar que las oportunidades de ascenso y crecimiento personal estén disponibles para todos, sin importar cuál sea el contexto económico. Las Mejores en México Hace unos meses, Great Place To Work Institute publicó los resultados de su estudio para determinar cuales eran las mejores empresas para trabajar en México. En el área de Tecnologías de Información y Telecomunicaciones, la lista de las mejores empresas en México para trabajar en el 2008 de acuerdo con Great Place To Work es la siguiente: 1. Compusoluciones 2. IBM 3. Nokia 4. Compac 5. EADS 6. Everis 7. Ingram Micro 8. Microsoft 9. NCR 10. Nextel 11. Perot System 12. Pink Elephant 13. Progress Software 14. Sabre 15. Telefónica Movistar Creo que hay que reconocer y aprender del esfuerzo que estas empresas hacen al interior y exterior de sus organizaciones, al crear un ambiente óptimo donde los colaboradores se pueden sentir reconocidos, valorados, recompensados para desarrollar al máximo su potencial humano y profesional. Dichas empresas desarrollan estrategias que van más allá de retener y desarrollar a su personal. Adicionalmente cuentan con el apoyo y compromiso por parte de la dirección o presidencia de la empresa junto con el área de RH para crear este tipo de cultura organizacional con enfoque centrado en el colaborador.

Referencias [ greatplacetowork.com.mx ] [ materiabiz.com ]

3. Profundo compromiso del empleado. El entusiasmo por el trabajo y la alineación con el éxito organizacional son particularmente im-

Emmanuel Olvera Avendaño es responsable del área de Reclutamiento y Selección en Resource IT de México. Ha colaborado por más de 4 años en el área de Recursos Humanos en varias empresas de Tecnologías de la Información en México. Es egresado de la Maestría en Desarrollo Humano por la Universidad de Celaya. http://eolvera.blogspot.com

www.sg.com.mx

NOV-ENE 2009

23


// ENTREVISTA

Tom DeMarco es uno de los decanos de nuestra profesión. Fue reconocido en 1986 con el premio Warnier por su “contribución vitalicia al campo de la computación”, y en 1999 con el premio Stevens por su “contribución a los métodos de desarrollo de software”. Es autor de algunos de los libros más reconocidos en la gestión de proyectos de software, tales como “Peopleware”, “The Deadline”, y “Waltzing with Bears”. Actualmente, Tom es socio distinguido en Cutter Consortium. Se dedica a dar consultoría estratégica en TI, y realiza actividades de investigación en el litigio de proyectos. Tom estuvo en México durante el Cutter Summit en el mes de octubre, y tuvimos oportunidad de platicar con él.

24

NOV-ENE 2009

www.sg.com.mx


¿Qué haces en el litigio de proyectos? La litigación se da cuando fracasa un proyecto subcontratado. Entonces, se trae a un tercero (como yo) para investigar qué salió mal en el proyecto, y si las fallas corresponden al cliente o al proveedor. Esto puede parecer poco atractivo, pero para mi es fascinante porque me permite ser un “arqueólogo” de los proyectos. ¿Consideras que la práctica de desarrollo de software realmente ha evolucionado en los últimos 20 años? Me extraña esta pregunta. Yo creo que hemos transformado el mundo. Gracias a las TI, el mundo hoy es completamente diferente a lo que era hace 20 años. Lo hemos convertido en un mundo donde los bits ya son más importantes que los átomos. No hubiéramos podido lograrlo sin hacer las cosas bien. Tal vez puedas voltear a ver las prácticas de la industria y pensar: “eso es simplemente lo que Yourdon o Dijkstra plantearon hace 30 años, no hay un avance”. Para mí el avance es que hemos tomado eso y lo hemos llevado de los laboratorios a la industria, a una industria que ha cambiado al mundo. ¿Entonces por qué hay un índice tan alto de fracaso en proyectos de TI? Las personas que promueven los índices de fracaso en los proyectos son reporteros tratando de vender una historia, y es difícil vender una historia con buenas noticias. Yo soy un ingeniero, y para nosotros el fracaso es algo sobre lo que se construye. Es algo necesario para poder hacer algo grandioso. Por supuesto que hay proyectos que fracasan, y yo creo que continuamente aprendemos de ellos. ¿Cómo ha cambiado el rol de los profesionistas de software en este tiempo? Los roles técnicos han evolucionado sustancialmente en cuanto a que se han especializado. Hace 30 años, tanto los compiladores, como los sistemas operativos, y aplicaciones de negocio eran construidos usando las mismas técnicas y lenguajes. Hoy en día, puedes conocer a otro profesionista de software y darte cuenta de que no tienes nada de que platicar con él debido a que hacen cosas completamente diferentes. Por otro lado, creo que la comunidad de gerentes de proyecto también ha madurado bastante. Creo que todos hemos comprendido www.sg.com.mx

que el aspecto sociológico de los proyectos es igual o más importante que el tecnológico. La formación de equipos de personas en nuestra industria es algo único. La noción de tener a 20 o 30 personas realizando tareas intelectuales en conjunto –donde nadie es dueño de todo sino que cada quien es dueño de una pequeña parte– es algo que no tiene muchos paralelos en el mundo antes de nosotros, y que sirve de guía en cuanto a la forma de trabajar en otras industrias hacia el futuro. ¿Podrías dar un ejemplo de este impacto en otras industrias? Por ejemplo, uno de mis clientes es Pixar, quienes hacen las películas de animación. Si analizamos la forma en la que se desarrolla una de sus películas, y un proyecto de software, encontramos una gran cantidad de analogías. Tienen los mismos elementos y patrones: la formación de equipos intelectuales con habilidades diversas y complementarias, la planeación de actividades, el diseño, la implementación, la gestión de la configuración de los artefactos. Este es un ejemplo de cómo la evolución que se ha dado en la forma en que trabajamos en la industria de TI, se está propagando a otros campos. Considerando la triada de “herramientas, personas y procesos”, ¿cual nos hace falta trabajar más? Cuando mencionas “herramientas, procesos y personas” implicas que hay una especie de balance, pero en realidad no lo hay. El proceso y las herramientas son elementos menores de un proyecto. Los procesos son el aspecto más fácil de ver y representar, y por lo tanto tendemos a exagerar su importancia. Sin embargo, su importancia es mucho menor que la de aspectos humanos tales como el desarrollo de talento o la formación de equipos. ¿Cual es la habilidad más importante que debe tener un desarrollador de software? Precisamente la habilidad de desarrollar nuevas habilidades. Nuestro campo cambia continuamente y no podemos estancarnos en un solo método ni tecnología. Esto aplica no solo a las personas, sino también a las organizaciones. ¿Qué tan importante es que un proyecto salga en costo y tiempo? La capacidad de predecir efectivamente el costo y tiempo de un proyecto es algo de-

seable, pero no es lo más importante. La obsesión de poder predecir efectivamente nos obliga a adoptar estrategias de mayor control, lo cual se traduce en menor velocidad. Esta presión se da principalmente cuando el valor de lo que construimos es marginal respecto a su costo. Si voy a construir un sistema que está presupuestado en un millón de dólares y va a traer un millón y medio de ganancias, entonces debo tener mucho cuidado porque el proyecto puede terminar costando más que su ganancia. Pero si voy a desarrollar un proyecto que va a costar un millón de dólares y va a traer 200 millones de ganancia, entonces no importa si termina costando más de lo planeado. ¿Alguien se acuerda de si Photoshop se terminó a tiempo? No, lo que importa es que cambió al mundo. Ante esto, la pregunta que hago a los lectores de SG es ¿Por qué están construyendo sistemas cuyo valor es tan cercano a su costo? Mi recomendación es que digan no a estos proyectos y busquen aquellos cuyo valor sea al menos 10 veces su costo. ¿Qué tendencias de la industria llaman tu atención actualmente? Una de las tendencias que estoy vigilando y que creo que tendrá un gran impacto en la industria es la de las tiendas de aplicaciones, como la Apple App Store. Creo que este concepto de tener un mercado en línea donde los usuarios puedan adquirir aplicaciones por unos cuantos dólares es algo que no debemos perder de vista. Lo que esto hace es habilitar a legiones de desarrolladores de software independientes para que puedan obtener dinero por sus servicios directamente del mercado, sin intermediarios. Es cierto que Apple (o las otras empresas que coordinan tiendas de este tipo) son una especie de intermediario, pero su interés principal es facilitar la transacción, más por el efecto que esto tendrá en la venta de su hardware, que por la comisión que puedan llevarse. Actualmente, las ventas del Apple App Store exceden el millón de dólares diarios. Apple se lleva una comisión del 30%, pero aun así estamos hablando de 700 mil dólares diarios que de pronto le están llegando a la comunidad de desarrolladores de software. Y esto es solo el principio. Estamos hablando de algo que puede cambiar la forma en la que se desarrolle y mercadee el software hacia el futuro. NOV-ENE 2009

25


El Nuevo Esquema de Entrega de Servicios de TI Por Pedro Galvรกn

30 26

NOV-ENE 2009

www.sg.com.mx


“Cómputo en la nube” (cloud computing) es el término que mayor atención genera actualmente en la industria de Tecnologías de Información. Descrito de forma sencilla, el cómputo en la nube permite a los usuarios acceder a través del Internet a un fondo de recursos de cómputo virtualmente ilimitado. A diferencia del esquema tradicional de TI, los usuarios de la nube tienen poca visibilidad y control de la infraestructura subyacente, y solo interactuan con la nube a través de los APIs proporcionados por los proveedores de la nube. Lo más importante de este esquema es que permite a los usuarios adquirir recursos de cómputo dinámicamente en un esquema de autoservicio, y solamente pagar lo que utilizan, tal como sucede con servicios públicos como la energía eléctrica, o el agua.

Una definición más formal

¿Qué servicios hay en la nube?

Gartner define el cómputo en la nube como “un estilo de cómputo donde se entregan como servicio capacidades de TI escalables masivamente, a clientes externos a través de tecnologías de Internet”. Los detalles de traducción hacen que la redacción de esta definición no sea muy clara, así que detengámonos a analizar esta definición.

Actualmente, los servicios más comunes que se puede adquirir a través de la nube son:

El concepto fundamental es que se basa en la entrega de servicios; es decir, resultados a diferencia de componentes o productos. La implementación no importa siempre y cuando los resultados se puedan definir y medir en términos de un acuerdo de servicio. Este paradigma implica el pago basado en el uso, no en los activos físicos. El costo puede ser pagado por completo por el cliente, o subsidiado (por ejemplo, a través de publicidad). El segundo concepto importante de esta definición es el de la escalabilidad masiva. Las economías de escala reducen el costo de los servicios. La escalabilidad también implica flexibilidad, y barreras de entrada bajas para los clientes.

¿Qué efecto tiene esto? Para los proveedores de servicios de TI, cloud computing significa la posibilidad de proveer servicios especializados de TI, de forma industrializada. Es decir, que dichos servicios no tengan que construirse de forma individualizada para un cliente específico. Por otro lado, para los usuarios de servicios de TI, significa que pueden enfocarse en aprovechar dichos servicios sin tener que preocuparse por cómo implementarlos y mantenerlos.

www.sg.com.mx

• Almacenamiento de datos. Por ejemplo Amazon Simple Storage Services en el caso de las empresas, o Windows Live Skydrive en el caso de personas. • Capacidad de cómputo para “rentar” ciclos de CPU sin necesidad de comprar servidores. Tal vez el servicio más conocido es el Elastic Compute Cloud (EC2) de Amazon. • Servicios aplicativos, a través del esquema SaaS (software as a service). Uno de los proveedores pioneros de este esquema es salesforce.com, que ofrece servicios de CRM sin que los usuarios tengan que comprar software; simplemente acceden a la aplicación desde su navegador por medio de Internet. Estos ejemplos representan apenas el inicio, y en los próximos meses seremos testigos de cómo aumentan y evolucionan para entregar servicios complejos a toda clase de negocios y personas.

Referencias: [ [

Autores varios. Cloud Computing: Defining and Describing an Emerging Phenomenon. Gartner Research. Junio 2008. ] Kumar, Sushil. Oracle Database Backup in the Cloud. Oracle Whitepaper, Septiembre 2008. ]

NOV-ENE 2009

27


La Nueva Frontera Por Pablo Resendiz

El estado de la nube Cloud Computing es un término que se ha adueñado de diversos ámbitos del mundo de las TI. La definición de este término era, al principio una práctica donde se utilizaban recursos de varias máquinas para crear una “supercomputadora virtual”. Fue utilizado principalmente para proyectos cooperativos que requerían de una gran cantidad de poder de procesamiento, con un presupuesto limitado. De esta manera, se reunían computadoras en línea, descargando un programa cliente que permitía utilizar una parte del poder de procesamiento de la computadora inscrita y con todas ellas, armar una supercomputadora virtual. Actualmente, “Cloud Computing” es la condensación de las actividades del usuario en línea, haciendo que lo único esencial para realizar esas tareas sea una computadora, acceso a Internet y un navegador. Hemos dado el salto gigantesco que eso significa, en términos de estar anclados, en el siglo pasado, a las máquinas de casa u oficina, enfrentando una realidad de la que apenas alcanzamos a utilizar una pequeña parte de su potencial: múltiples dispositivos adaptados a un uso particular, unidos a una gran nube de dispositivos de otros tipos, todos ellos accediendo a la misma información con idéntica facilidad y coherencia. Estas actividades pueden ser el envío de correos electrónicos, el compartir documentos en línea para su edición y el respaldo de información.

La nube perfecta Hoy en día, existen empresas enfocadas a proporcionar todo tipo de recursos para satisfacer cualquier aplicación que se les pida, utilizando un gran poder de procesamiento y almacenamiento disponibles, lo que permite que el usuario tenga acceso a un número de recursos virtualmente ilimitados para tareas específicas. La nube será sin duda, la nueva frontera. Y ésta se extenderá en dos ámbitos: el de usuario y el corporativo. Actualmente, el usuario ya disfruta de sus beneficios, experimentando una transición gradual pero estable de las actividades que usualmente tenía frente a un monitor en distintos dispositivos portátiles, además de tener acceso a sus datos, disponibles desde cualquier terminal tras una autenticación simple, pero que deberá ser robusta y confiable. Esta práctica cautivará poco a poco a los usuarios, que demandarán cada vez más

28

NOV-ENE 2009

su correo, agenda y procesador de textos en un estado permanente, evitando así, estar lejos de él o encontrarse con una computadora apagada. De entre estas aplicaciones la que experimenta un alto aumento es la de almacenamiento en línea. Pero la evolución que marcará la tendencia más fuerte es la del mercado corporativo. Es cierto que el Cloud Computing nos ha demostrado su vulnerabilidad en un par de ocasiones (servicios de correo, agenda y documentos compartidos inaccesibles por horas y a veces días), sin embargo, la tecnología seguirá avanzando lo suficiente como para que sea confiable en un esquema de implementación corporativo similar al que tuvo en su momento el propio correo electrónico empresarial. Con esta evolución, las empresas comenzarán a tener los datos más allá de sus muros de protección y gozarán de costos menores, funciones de acuerdo a sus necesidades, y soporte para una colaboración sencilla, y sobre todo segura. Poco a poco, los centros de datos corporativos estarán fuera de las empresas. Las únicas que seguirán con esta tendencia serán las que por su tamaño, tengan que recurrir a un data center propio, su nube particular.

El software, pieza clave de la nube Actualmente, la guerra de sistemas operativos es el precedente de la conjunción de aplicaciones que experimentaremos en la plataforma de la nube. El sistema operativo deberá responder a tres exigencias: Seguridad, Estabilidad y Competencia. Sea cual sea la plataforma (Windows, MacOS, Linux), deberá tener en cuenta que los usuarios requieren sistemas amigables con el usuario, que utilicen los recursos de las computadoras de manera óptima, y que no representen un problema de configuración, compatibilidades o restricciones excesivas. Por su parte, el navegador será la puerta de entrada a este conjunto, utilizando recursos de ambos lados de la línea, cada uno en su medida, para ejecutar las tareas necesarias. En este posible estado de las cosas entra una pregunta fundamental: ¿Qué pasará con el software de aplicación como lo conocemos? La apuesta principal en este sentido es el Software as a Service (SaaS, por sus siglas en inglés), una platafor-

www.sg.com.mx


tar el sistema, por lo que bajarán sus costos y su riesgo de inversión. ma que está íntimamente relacionada con el concepto de ultraportabilidad que plantea el Cloud Computing. Los analistas de Gartner aventuran que en 2011, el gasto en SaaS alcanzará el 25% de la inversión total en software. Mientras que otro estudio de la consultora Saugatuck Technology, indica que el porcentaje de empresas y ejecutivos de TI que utilizan al menos una tecnología SaaS aumentó de un 11% a un 26% en el 2006. Por su parte Saugatuck Technology prevé que para el 2010, el 65% de las organizaciones habrá introducido al menos una aplicación siguiendo el modelo de SaaS, dicho así; las compañías de TI dedicadas al software encontrarán una nueva parcela para explotar. Esta tendencia contará con tres actores principales: • Usuarios Finales. Los usuarios comenzarán a utilizar un esquema de pagos por software basados en cuotas mensuales. Con esta opción, podrán probar y evaluar el servicio online en lugar de proporcionar recursos de su CPU necesarios para analizar el software, o instalarlo en sus máquinas. Al no estar atado a un espacio físico, la implementación y el mantenimiento del software se puede administrar desde cualquier lugar. Los datos tendrán una estructura central, accesible y segura, en lugar de estar dispersos en varios servidores y computadoras. Además, el usuario no tendrá que experimentar pérdida de datos en caso de una falla eléctrica o descarga en su localidad. • Organizaciones. Ahorrarán en costos de aplicación, debido a que no tendrán que invertir en un área especializada para sopor-

Esto representa un reto enorme para las compañías de software que opten por este camino, ya que la disponibilidad de la solución deberá ser total. En este esquema, las caídas del servicio o las “horas muertas” deberán desaparecer. Esto significa que la garantía de disponibilidad de la aplicación y su correcta funcionalidad, son parte del servicio que otorga la compañía proveedora del software y no puede darse el lujo de una pérdida de disponibilidad, ya que eso repercutirá negativamente en su percepción con los usuarios y clientes. Esto dará como resultado mejores aplicaciones, que tengan un acercamiento más práctico a las necesidades del usuario y con una calidad exigida que beneficiará al usuario. • Distribuidores Independientes de Software (ISVs). El software puede desplegarse en un entorno controlado centralizado, con lo que se reducen las llamadas al escritorio de ayuda así como los costos de soporte. Esto permite una respuesta más rápida a los posibles problemas que pudieran presentarse y una mayor eficiencia en el manejo de recursos de los ingenieros involucrados. Al ser un entorno de acceso controlado, los usuarios no tendrán que preocuparse por actualizaciones constantes o que los hagan perder tiempo o utilizar a su departamento de TI. Estas actualizaciones serán transparentes para el usuario y no afectarán su trabajo, sino que mejorarán las aplicaciones sin que el usuario se moleste por configurar. Además, el tema de la seguridad será un factor fundamental para los proveedores del

servicio, quienes tendrán que invertir más y de mejor manera en un esquema que permita autentificaciones confiables de los usuarios. Con estas aplicaciones la confianza en el servicio crecerá, ya que el usuario se sentirá tranquilo de que sus datos están seguros, a prueba de robo, modificación o ingreso no autorizado. En la cuestión financiera, los ISVs tendrán una mejora en el manejo de sus finanzas, ya que el esquema de servicio de software les creará una cartera de pagos programados mensualmente, lo que traerá una estabilidad que permitirá administrar mejor las entradas de Investigación y desarrollo. Las pequeñas y medianas empresas entrarán a este sistema, permitiendo que la base de clientes de los ISV crezca. El software ya no será una herramienta que requiera una experiencia previa de manejo o un despliegue de aplicaciones de instalación complejas. Con esto, las PyMEs podrán utilizar esta tendencia para mejorar sus procesos y optimizar sus recursos de TI.

Cuando la lluvia nos alcance El Cloud Computing será una de las soluciones que más ahorro va a suponer a las empresas, al ser un esquema libre, con amplio mercado y gran competitividad, cuyo único costo fijo será la conexión a Internet. Las empresas que ofrecen este esquema naciente deben tener eso en cuenta al momento de diseñar su estrategia de negocios y productos. ¿Está realmente la industria preparada para el Cloud Computing? Los primeros resultados son alentadores. Será la tecnología la que determine el rostro del mercado y las aplicaciones que ganarán la próxima apuesta, la siguiente frontera de TI: Las nubes.

Pablo Reséndiz se desempeña actualmente como Gerente de Negocios de Soluciones BURA (Backup, Recovery & Archiving) en EMC México. Con una experiencia de más de 10 años en la Industria TI, ha trabajado en empresas como IBM; desarrollándose como Ingeniero de Soporte a ventas para soluciones de Administración de Contenido.

www.sg.com.mx

NOV-ENE 2009

29


¿Modelo, Plataforma o Servicio? Por Javier Mijail Espadas Pech M.C.

Recientemente me encontraba impartiendo una clase de Arquitecturas de Software. En un experimento rápido pregunté si alguien conocía el término Software-as-a-Service (SaaS). La respuesta fue una rotunda negativa de todos. Luego pregunté si alguien había usado alguna vez Google Docs y la gran mayoría respondió afirmativamente. Les comuniqué mi conclusión: aunque no conocían el término, ya habían usado SaaS.

Ahora bien, antes de definir ciertos conceptos en cuanto a este tema, creo que es importante mencionar algunas tendencias de negocio en este mercado; Gartner predice que: • Para el 2010, 20% de las compañías de comercio electrónico usarán el modelo SaaS y 15% de las grandes compañías reemplazarán sus soluciones de ERP con soluciones basadas en SaaS. • Para el 2011, 25% de los nuevos negocios de software usarán el modelo SaaS. • Para el 2012, las suites de BPM (Business Process Management) serán embebidas en soluciones SaaS y más del 66% de los ISVs (Independent Software Vendors) ofrecerán sus servicios como SaaS. IDC también estima que las empresas gastarán US$14.8 billones en soluciones SaaS y que dos de cada tres negocios considerarán comprar software con modelos de subscripción. Estas cifras son verdaderamente importantes, ya que representan un amplio mercado en la industria del software para los próximos años. Ejemplos de negocios que usan este enfoque son Salesforce.com, Google Apps, Appian, OpSource, CogHead, entre otros. Con esta tendencia, es importante también definir la forma en que este tipo de software es desarrollado y entregado al cliente. Este artículo analizará este aspecto y sus implicaciones en la metodología tradicional del desarrollo del software.

30 32

NOV-ENE 2009

Conceptos SaaS Para comenzar, podemos decir que SaaS no es una tecnología ni una metodología. Tampoco es un modelo de negocio específico. SaaS es un enfoque que consiste en varios componentes: • Un modelo de negocio basado en subscripción. • Una plataforma SaaS que permite desarrollar y desplegar aplicaciones sobre demanda. • Proveedores que desarrollan y/o comercializan esas aplicaciones. • Un modelo de entrega a través de Internet hacia múltiples clientes. El modelo de subscripción debe soportar diferentes tipos de cobro, como son pago por transacción o periodo de tiempo. Los clientes de SaaS, a diferencia de los modelos ASP (Application Service Provider), son entidades de negocio y no usuarios finales. La plataforma SaaS provee soporte para diferentes aplicaciones, tanto las que son entregadas para los clientes como para aplicaciones propias de los proveedores. Comúnmente se usa el termino tenant para referirse tanto a los clientes como proveedores que usan la plataforma para consumir o proveer las aplicaciones SaaS. • Plataforma SaaS. Una plataforma debe proveer infraestructura (tanto de hardware como de software) que soporte el desarrollo y entrega de aplicaciones sobre Internet como servicios. Arquitecturas comunes tienen los siguientes atributos de diseño: www.sg.com.mx


1. Multi-tenant. La arquitectura soporta múltiples clientes y proveedores. 2. Versión simple. Existe una versión de cada aplicación y es compartida para todos los clientes. 3. Separación lógica de datos. Cada tenant tiene su propio dominio de información, pero almacenados en una misma base de datos. 4. Contenedor de dominio. Es un punto de entrada a las aplicaciones de un proveedor. 5. Integración de aplicaciones. Las aplicaciones SaaS deben comunicarse entre sí, pero mantenerse independientes. 6. Componentes de soporte. La plataforma proporciona componentes compartidos para las aplicaciones: seguridad y autenticación, manejo de cuentas de usuario, logging, control de uso y métricas, soporte para diferentes modelos de subscripción, entre otros componentes importantes.

3. Soportadas por componentes compartidos de la plataforma. 4. En sentido estricto, solo deben contener lógica de negocio e interfaz de usuario.

Impacto sobre el desarrollo de software Actualmente los proveedores de SaaS no han establecido las mejores prácticas para desarrollar este tipo de aplicaciones ni tampoco estándares en la industria. Las metodologías tradicionales son suficientes para desarrollar modelos SaaS muy simples, pero cuando se trata de especializar y escalar hacia un negocio más avanzado, aún se carece de técnicas bien establecidas. Por el lado de ingeniería de software, las aplicaciones SaaS presentan diferencias en cuanto a su ingeniería de requerimientos con las aplicaciones empaquetadas (por ejemplo, desde la perspectiva del cliente, la instalación y mantenimiento son diferentes). Pioneros del modelo SaaS argumentan que se requiere un enfoque alterado de ingeniería de software para este tipo de aplicaciones. Una pregunta importante es cómo el enfoque SaaS afecta a los proveedores de software y su incentivo a invertir en el desarrollo de productos. Transformar un producto empaquetado a un modelo SaaS no es una simple cuestión de reescribir código. Estas compañías necesitan examinar sus modelos de ingeniería y mercadeo para adaptarse a este nuevo enfoque de negocio y de desarrollo.

Figura 1. Arquitectura SaaS

La figura 1 muestra la arquitectura de alto nivel de una plataforma SaaS. En el nivel más alto se encuentran las aplicaciones proporcionadas por los proveedores. La plataforma expone componentes de soporte para estas aplicaciones. Otros servicios son de meta-datos y administración de tenants. Infraestructura de software y hardware también es proporcionada por la plataforma. Sobre esta arquitectura, las aplicaciones SaaS son desarrolladas, desplegadas y entregadas a un número considerable de clientes. Figura 2. Ciclo de Vida en Aplicaciones SaaS

• Aplicación SaaS. Básicamente, una aplicación es una serie de módulos y funciones que puede ser desplegada bajo demanda dentro de una plataforma. Una aplicación SaaS es desarrollada acorde a la plataforma que la soporta. Las características de estas aplicaciones pueden definirse como sigue: 1. Accedidas por Internet. 2. Desarrolladas y desplegadas sobre una plataforma específica. www.sg.com.mx

La figura anterior describe que las actividades son diferentes a un producto tradicional. Una de las causas principales de estas diferencias, es que las aplicaciones SaaS están acopladas a una plataforma y en cada etapa esta plataforma juega un rol importante en el ciclo de vida SaaS. La siguiente tabla analiza el impacto en cada etapa del desarrollo cuando el software es entregado como producto y como servicio. NOV-ENE 2009

33 31


Una Vista al Futuro de S+S Por Gilbert Corrales

Gracias al acelerado crecimiento en el acceso a Internet de avanzada y a la disponibilidad de redes inalámbricas, la naturaleza de como las personas interactúan ha cambiado. La sociedad inclina su balanza hacia la simplicidad de servicios y de aplicaciones de software interconectadas que “sencillamente funcionan”; mientras que los negocios consideran con mayor seriedad las economías basadas en servicios tales, que les permitan escalar a la vez de reducir costos de infraestructura, permitiendo implementaciones a la carta o bajo modelos de subscripción. Este mes, Microsoft introdujo su plataforma de servicios en la nube, Live Mesh, con la fe de servir mejor a este cambio. Como medio de lanzamiento a una serie de ofertas de desarrollo e implementación, Mesh permite que tanto personas como empresas puedan sacar provecho de una infraestructura diseñada desde sus inicios para escalar y soportar la demanda de acceso a la información que vivimos hoy en día, independientemente del lugar o dispositivo que tengamos a mano. Para Microsoft, Live Mesh es una combinación entre una plataforma y un conjunto de experiencias diseñadas para traer “a la vida” las computadoras tradicionales y otros dispositivos. Haciendo que estos puntos de interacción sean consientes de su disponibilidad y existencia, Live Mesh permite a sus usuarios el poder administrar, acceder y compartir archivos y aplicaciones de manera simple y distribuida a lo largo de un amplio mundo de dispositivos. Live Mesh pertenece a una iniciativa mayor llamada el Live Platform Services, cuyos inicios datan del año 2005, encerrando toda una colección de Interfaces de Desarrollo que permiten el acceso a diferentes servicios de infraestructura que Microsoft provee bajo la marca Live y dando poder tanto a servicios gratuitos como Live Spaces, Messenger y Photo Gallery, así como a aplicaciones de terceros.

34

2008 NOV-ENE 2009

La magia detrás del Mesh Hasta el día de hoy cada vez que iniciamos el desarrollo de una aplicación distribuida o de acceso a servicios, tendemos a pensar en todas las diferentes estrategias y soluciones posibles para nuestros problemas, invirtiendo gran parte de nuestro tiempo en tareas que repetimos con cada solución y cada dispositivo que incluyamos. Sin embargo con la introducción de esta nueva plataforma, Microsoft espera minimizar la cantidad de tareas repetidas y permitirnos como desarrolladores, el enfocarnos en lo realmente necesario: la lógica de negocios y la composición de una experiencia perfecta para nuestros clientes. Tres capas definen la plataforma Mesh, con una cuarta que nos engloba el conjunto de experiencias con las que, como usuarios finales interactuamos. Desde la infraestructura física, servicios generalizados, así como toda una base de Protocolos e Interfaces de los que sacaremos provecho desarrollando y publicando nuestros servicios, Live Mesh se presenta como el cimiento sobre el cual el futuro de nuestras interacciones podran ser construidas. • Servicios de infraestructura. Así como otros servicios Live, Mesh tiene sus fundaciones en una infraestructura diseñada desde el día uno, para soportar las necesidades de alta disponibilidad y escalabilidad del mundo actual. Con servicios de infraestructura y de administración que permiten no solo el acceso y almacenamiento de datos, sino tambien la disponibilidad de toda una gama de medios computacionales, Live Mesh permitira que tanto individuos como organización puedan publicar aplicaciones y servicios propios, haciéndolos disponibles a nuestras organizaciones y clientes a través de la nube y por medio de sus propios Mesh. Siempre dentro de los confines de seguridad y respaldo propios de una plataforma de dicha magnitud.

www.sg.com.mx


• Plataforma de servicios. Sobre la capa de infraestructura la Plataforma de Servicios pone a nuestra disposición, en una segunda capa, el acceso a una serie de funcionalidades generales de las cuales podremos sacar provecho para construir tanto aplicaciones como servicios orientados a la nube. Algunos de estos servicios son el de Identificación y Directorio, como el Live ID, coordinación de conectividad y acceso entre dispositivos y, hasta almacenamiento y sincronización de nuestros datos entre los diferentes dispositivos que conformen nuestro Mesh, siendo la nube otro mas de estos puntos. • Pilar de desarrollo. Parte fundamental de Live Mesh es la incorporación de un pilar de desarrollo. Esta capa nos expone toda la funcionalidad de la Plataforma de Servicios a través de un conjunto de Protocolos e Interfaces, conocidas como MeshFX, que corren sobre un motor de composición de servicios llamadao MOE o Mesh Operating Engine. Este motor es accesible desde todas las plataformas soportadas por Mesh incluyendo PC y Macs así como dispositivos móviles y navegadores Web tradicionales. Este ultimo con su propia experiencia llamada Live Desktop, una solución Web que provee acceso a toda la información, aplicaciones y dispositivos disponibles en el Mesh, utilizando como base de desarrollo las herramientas y protocolos Web comunes hoy en día. • Experiencias del Live Mesh. En este cuarta capa se engloban todas aquellas experiencias que, tomando provecho de la plataforma descrita por los 3 niveles anteriores, nos proveen los medios de acceso necesarios para llevar a cabo nuestras tareas, sacando provecho del poder de procesamiento y de la experiencia disponible desde nuestros dispositivos. Este capa esta compuesta no solo por los servicios de interacción básicos que Live Mesh provee, sino también por la gama de aplicaciones y servicios que nosotros y otros desarrolladores dentro de la comunidad construyen y hacen disponible a nuestro Mesh.

Funcionando en un mundo de armonía: FeedSync Live Mesh tiene como parte de su misión, el proveer una plataforma de servicio que haga posible el incorporar las capacidades necesarias para que estas estén disponibles virtualmente desde cualquier lugar, donde exista conectividad a la web, de manera ágil, segura y eficiente. Con un motor de almacenamiento con capacidades para poder llevar a cabo nuestras tareas de manera desconectada y de la misma manera, una vez resumida la conectividad, poder sincronizar los cambios con los diferentes puntos de nuestro Mesh, esta plataforma permite desde el punto de vista de usuario, así como el desarrollo, la simplificación de nuestro día a día, trayendo en si armonía dentro de nuestra información y una accesibilidad casi universal. Fundación de esta característica es la sincronía de datos. Mesh implementa FeedSync entre sus capas, una tecnología desarrollada por Microsoft que utiliza los protocolos de RSS y ATOM, proveyendo así un mecanismo para sincronizar información entre 2 o más puntos de manera instantánea o asíncrona. Es con base a estos protocolos que nuestras aplicaciones podrán sacar provecho de capacidades de desconexión sin mayores complejidades, lo cual hace mantener copias sincronizadas de nuestros datos una tarea tan simple como el habilitar dichos puntos dentro de nuestro Mesh, traduciéndose así en una plataforma esencial para el éxito de nuestros servicios.

Nuestro futuro en la nube Live Mesh no es mas que el inicio de un mundo interconectado, un mundo en el que nuestras vidas inician a tener acceso a los recursos a la hora y lugares indicados. Es nuestra realidad la que cambia y evoluciona según estas necesidades y esta en nosotros hacerla realidad a lo largo de toda una gama de servicios y aplicaciones que, como sociedad 2.0 estamos empezando a dar luz. Nuestro futuro es disperso y accesible a todas horas. Nuestro futuro es una nube de conexiones sincronizadas entre nuestra realidad física y virtual que unidas nos facilitarán el día a día. Hagámosla realidad!

Gilbert Corrales, es Evangelista de Tecnología de Aggiorno y Profesor de Diseño de la Interacción en Cenfotec Costa Rica. Con más de 7 de años de experiencia en la industria, ha trabajado en proyectos tanto de investigación como comerciales para compañías como Unisys, Intel, y la agencia interactiva Schematic; Gilbert se enfoca en el diseño de la interacción con visión en tecnologías Web y medios de uso alternativos.

www.sg.com.mx

2008 NOV-ENE 2009

35


Desarrollo de aplicaciones SaaS

Análisis

El impacto en el proceso de desarrollo de software presentado anteriormente debe ser tomado en cuenta cuando una aplicación es desarrollada como servicio. Las metodologías tradicionales son ahora analizadas y redefinidas para cumplir los nuevos requerimientos impuestos por este nuevo enfoque. Podemos redefinir las actividades de cada etapa en esta propuesta:

La etapa de análisis debe ser realizada también desde la perspectiva de negocio. Esto es debido a que cada aplicación tratará de satisfacer las necesidades de un amplio número de clientes. La definición de los procesos de negocio que soportará cada aplicación es un paso importante en este tipo de aplicaciones, ya que debe permitir la personalización y definición de procesos similares para cada cliente. • Análisis de procesos de negocio. En esta actividad se deben analizar los procesos de negocio que serán automatizados con la aplicación. Por ejemplo, si se desarrolla un CRM, se deben analizar los procesos de venta y su integración con otros procesos como cadenas de suministro, por ejemplo. Cada proceso con sus actividades, roles y reglas de ejecución debiera ser documentado. • Desarrollar casos de uso. Tarea formal en metodologías existentes, que debiera hacerse para documentar y modelar las funcionalidades de la aplicación. Artefactos tradicionales son casos de uso descriptivos y sus diagramas.

Diseño La fase de diseño consiste en desarrollar documentación que soporte la etapa de construcción.

Figura 3. Redefinición de las actividades en el ciclo de vida SaaS.

El desarrollo de aplicaciones sobre plataformas SaaS requiere de consideraciones en los diferentes escenarios del ciclo de vida del software.

Requerimientos En el enfoque tradicional, los requerimientos consisten en definir una serie de funciones que satisfagan las necesidades de un cliente. En el caso de las aplicaciones SaaS, los desarrollos son meramente basados en un modelo de negocio. Eso es, una aplicación SaaS debe cumplir con los requerimientos de un mercado meta. Debido a que las aplicaciones serán consumidas por un gran número de subscriptores (empresas clientes) y cada uno puede tener potencialmente un número grande de usuarios, entonces más requerimientos nofuncionales son introducidos al proceso, como por ejemplo: soporte para alta concurrencia, almacenamiento escalable, virtualización/ clustering entre otros. Las actividades propuestas son: • Definición de un plan de requerimientos de negocio. Deben ser identificadas las características del plan de negocio (del proveedor) para ser transformadas a requerimientos funcionales. • Análisis del mercado meta. Catalogar y puntualizar las necesidades principales del mercado meta. Se deben evaluar las necesidades del mercado y definir características de alto valor para los clientes potenciales. En esta actividad se van identificando los requerimientos no-funcionales que se mencionaron anteriormente. • Definición de las funcionalidades. Puntualizar las características principales como funciones de cada aplicación que será entregada como servicio. Estas funcionalidades deben ser completamente alineadas al mercado y no a los requerimientos de un solo proveedor.

32

NOV-ENE 2009

• Investigación de tecnologías. Es importante en esta etapa hacer investigación sobre las tecnologías que soporten las necesidades identificadas. Un artefacto entregable puede ser un documento de investigación acerca de plataformas SaaS, proveedores existentes, frameworks, componentes Web 2.0, etc. • Evaluación de tecnologías. Es importante definir cuál es la plataforma y las tecnologías que serán usadas en el proceso de desarrollo. Las pruebas de concepto en esta etapa son necesarias, para realmente determinar si la plataforma y tecnologías cumplen con los requerimientos tanto de negocio como técnicos. • Arquitectura de servicios. En este caso, las decisiones arquitecturales están basadas en las premisas SaaS y la plataforma que las soporta. Debido a que las plataformas SaaS están diseñadas para ofrecer una infraestructura de servicios, los componentes de la aplicación deberían ser diseñadas bajo este enfoque. • Ingeniería de procesos de negocio. Incluso cuando la aplicación debe proveer una definición predeterminada del proceso de negocio que ejecutará, su valor incrementa cuando es posible redefinir cada proceso de acuerdo al cliente. • Documentación tradicional. Esta actividad involucra diversas tareas comunes como diagramas UML. Se trata de la documentación formal de la aplicación y depende de las especificaciones de la misma. • Diseñar casos de prueba. Esta tarea resulta obviamente importante para cualquier desarrollo serio. Se deben incluir mecanismos de pruebas unitarias, de integración, de rendimiento, etc. • Prototipos. Los recursos y la agilidad de generar y desplegar aplicaciones en plataformas SaaS puede ser explotado a través de la construcción de prototipos.

www.sg.com.mx


Implementación Además de las tareas comunes involucradas en la implementación, dentro del desarrollo SaaS es necesario considerar a la plataforma que soporta las aplicaciones. • Desarrollo de servicios de negocio. Se trata de codificar las interfaces principales de la aplicación, así como sus implementaciones. • Integración con los servicios de la plataforma. Desarrollar el código para consumir los servicios que la aplicación necesita para operar. Estos servicios consumidos pueden ser de seguridad, logging, métricas, etc. • Desarrollar la lógica de negocio. Implementación de las reglas de negocio para los módulos de la aplicación. • Desarrollar el front-end. Diseño y desarrollo de interfaces de usuario. • Desarrollo de integración. Si es necesario, desarrollar código para integrarse con otros sistemas. • Implementación de tecnología. Asegurarse que toda la implementación trabaja correctamente. Esta actividad cubre revisión de código, mejores prácticas, revisión de complejidad ciclomática, pruebas funcionales, entre otros.

Pruebas La principal diferencia entre las metodologías tradicionales y la propuesta para SaaS radica en que las pruebas de integración necesitan validar la integración correcta entre las aplicaciones y la plataforma. Otra diferencia importante es en cuanto a las pruebas de rendimiento y métricas de uso. • Pruebas unitarias. Estas pruebas son desarrolladas y ejecutadas por cada desarrollador. • Pruebas de integración. Pruebas importantes en cuanto a la integración con la plataforma, con otros módulos de la aplicación y con otras aplicaciones. • Pruebas de rendimiento. Cada aplicación tiene sus propios requerimientos de rendimiento, en este caso, las aplicaciones SaaS tienen una fuerte dependencia en el número de usuarios y sus especificaciones. • Pruebas de medición de tenants. La aplicación no debiera implementar código para logging o medición de uso. Estos componentes son responsabilidad de la plataforma misma. El objetivo de estas pruebas es asegurar que el uso y debug de cada aplicación es correctamente registrado y para cada tenant (cliente y/o proveedor).

• Aprobación Técnica. Consiste en correr todas las pruebas sistemáticamente y asegurarse que la aplicación es correctamente desplegada a producción. En el caso de actualizaciones y bugfixes, la plataforma debe proporcionar mecanismos de rollback cuando existan fallas y se pueda regresar a versiones anteriores.

Conclusión Nuevas plataformas conocidas como Software-as-a-Service (SaaS) serán un importante canal de distribución para el software empresarial en un futuro cercano. El proceso de desarrollo sobre estas plataformas debe considerar diversos factores que no presentan los métodos actuales de desarrollo de software. Las diferencias entre desarrollar software como servicio o como producto empaquetado son evidentes y estas diferencias cambian la manera en que las aplicaciones SaaS son desarrolladas. Dadas estas diferencias, este trabajo analiza las consideraciones necesarias para cada etapa de desarrollo en este nuevo tipo de aplicaciones y también presenta una guía para desarrollar aplicaciones en ambientes de negocio Software-as-a-Service.

Referencias [ Turner, M.; Budgen, D.; Brereton, P. “Turning software into a service”. Computer. Volume 36, Issue 10, Octubre 2003. ] [ Predicts 2007: Software as a Service Provides a Viable Delivery Model. Gartner Inc. 2006. ] [ Wolde, Erin Ten. Research Analyst, IDC. Agosto 2007. ] [ Natis, Yefim V. Introducing SaaS-Enabled Application Platforms: Features, Roles and Futures. Gartner Inc. 2007. ] [ Choudhary, V. “Software as a Service: Implications for Investment in Software Development”. Annual Hawaii International Conference on System Sciences, 2007. ] [ Olsen, E.R. “Transitioning to Software as a Service: Realigning Software Engineering Practices with the New Business Model”. Service Operations and Logistics, and Informatics, 2006. ] [ Carraro, Gianpaolo; Chong, Fred y Page, Eugenio Pace. “Efficient Software Delivery Through Service-Delivery Platforms”. The Architecture Journal. Microsoft MSDN Architecture Center ] [ Chou, Timothy. The End of Software. Sams Publishing, 2005. ]

Javier Mijail Espadas Doctoral Research Assistant Ph. D. Information Technology and Communications ITESM Campus Monterrey CETEC SouthTower Monterrey, Nuevo León, México.

www.sg.com.mx

NOV-ENE 2009

33


// PRÁCTICAS

/*PROGRAMACIÓN*/

Ofuscación de Código Dinámica Mecanismo de Protección o Amenaza Por Juan Olivares, Sandokan Barajas

Resumen La ofuscación de código dinámica es una nueva forma de enmascarar el código, a lo largo de este artículo veremos las ventajas y riesgos que implican el descubrimiento de esta nueva técnica, así como algunos de las métodos que existen tanto para ofuscar el código, como para lograr la desofuscación del mismo, además de las principales formas y lugares donde esta técnica puede ser aplicada.

La ofuscación de código dinámica es una técnica que transforma el código en garabatos incomprensibles, esta técnica puede ser utilizada con dos propósitos principales, el primero como una herramienta de protección de derechos de autor del código de los programas, y el segundo como una amenaza a los mecanismos actuales de seguridad en la red. La mayoría de las empresas tratan de evitar que su código fuente pueda ser obtenido por alguien más, es por esto que hacen uso de herramientas que les permitan evitar que alguien lo pueda obtener. Sin embargo la ofuscación también sirve como un mecanismo de para generar muchas versiones del mismo código, logrando de esta manera sobrepasar los mecanismos usuales de análisis de los sistemas de seguridad, como los antivirus.

La amenaza oculta En la actualidad, a pesar de que los antivirus son cada día más potentes y hacen uso de técnicas mucho más complejas para lograr evitar las amenazas, nace una nueva técnica que logra poner en dificultad a estos sistemas actuales de defensa, esta nueva técnica es llamada ofuscación de código dinámica, y se basa en la transformación o enmascaramiento del código para evitar que se pueda determinar la forma que tenía originalmente. La ofuscación de código dinámica empezó a funcionar con javascript un poco después de que fuera liberado este lenguaje en 1995, se hizo por la principal razón de proteger el código que tanto trabajo les costaba desarrollar a los programadores, y que cualquier usuario podía ver usando un explorador con esas características.

Figura 1. Existen muchas herramientas que ayudan a la fácil ofuscación de código, las cuales permiten proteger los códigos dinámicos o de scripting, aunque también se puede utilizar con fines malignos

La ofuscación también hace uso del polimorfismo que ya ha sido utilizado con anterioridad en los virus, y en la actualidad se está utilizando con los exploits de javascript para ocultar su peligrosidad y poder incrustarlo en páginas Web, a las cuaes son invitados a entrar los usuarios.

Mecanismo de protección El código fuente de un programa es muy valioso, siendo una creación intelectual, es susceptible de ser utilizado sin haber tenido que pasar por un proceso creativo nuevamente, es decir, una vez que se desarrollo el código puede volver a ser utilizado sin haber tenido que emplear tiempo en su desarrollo, es por esto que las empresas y desarrolladores protegen tan celosamente su código. Una manera de entre muchas que existen en la actualidad para proteger su código, en otras palabras su propiedad intelectual, es la ofuscación, que se ofrece como una manera de poder ejecutar el código por otras personas, sin que estas puedan llegar a entender cómo funciona en realidad. La ofuscación de código ha sido propuesta por un gran número de investigadores como un medio para dificultar la realización de ingeniería inversa sobre el código. Pero las transformaciones típicas de ofuscación se basan en razonamientos estáticos sobre ciertas propiedades de los programas, lo cual da como resultado que la ofuscación del código pueda ser fácilmente desentrañada mediante una combinación de análisis estáticos y dinámicos.

Juan Carlos Olivares Rojas es Maestro en Ciencias de la Computación por el Centro Nacional de Investigación de Desarrollo Tecnológico (CENIDET), actualmente es Profesor de Tiempo Parcial del Instituto Tecnológico de Morelia, sus áreas de interés son los Sistemas Distribuidos y la Ingeniería de Software.

36

NOV-ENE 2009

www.sg.com.mx


“El código fuente de un programa es muy valioso, siendo una creación intelectual, es susceptible de ser utilizado sin haber tenido que pasar por un proceso creativo nuevamente”.

Conceptualmente se pueden distinguir dos tipos de ofuscación de código: la ofuscación superficial y la ofuscación profunda. La primera siendo solamente un reacomodo de la sintaxis del programa, ya sea cambiando nombres de variables o algún otro método similar, y la segunda que intenta cambiar la estructura actual del programa, cambiando su control de flujo o modo de referenciar sus datos, esta última teniendo menos efecto en el proceso de estar oculto a la ingeniería inversa, ya que no se ocupa de disfrazar la sintaxis del código.

Técnicas de ofuscación Una de las técnicas de ofuscación es la llamada “aplanamiento de control de flujo básico”, la cual intenta esconder la lógica de flujo del programa para que simule que todos los bloques básicos tienen el mismo antecesor y el mismo predecesor. El control de flujo actual es guiado mediante un despachador de variables, el cual en tiempo de ejecución asigna a cada bloque básico un valor variable, que indica cual es el siguiente bloque básico que debe ser ejecutado a continuación. Entonces un bloque switch utiliza el despachador de variable para saltar de manera indirecta, a través de una tabla de saltos hacia el sucesor de control de flujo que debe ser. Existen varias mejoras en esta técnica de ofuscación, siendo una de ellas el flujo de datos interprocedimental, las variables que asignaba el despachador se encontraban disponibles dentro de la función misma, debido a lo cual aunque el comportamiento del control de flujo del código ofuscado no sea obvio, puede ser reconstruido mediante un análisis de constantes asignadas por el despachador de variables. La ofuscación del código puedes ser más difícil de reconstruir si además de lo anterior agregamos el paso de variables entre los procedi-

mientos, la idea es utilizar un arreglo global para pasar los valores asignados por el despachador de variables, así cada vez que se llame a la función se pasará el valor al arreglo de variables global, logrando de esta manera que los valores asignados cada vez que se llama la función no sean constantes, sino que al examinar el código ofuscado no sea evidente el proceso que se realizó en la llamada a la función. Otra mejora que se puede agregar a la técnica de ofuscación mencionada es la adición de bloques básicos al de flujo de control del programa, algunos de los cuales nunca van a ser ejecutados, pero lo cual es muy difícil de determinar mediante análisis estáticos, debido a que las llamadas se generan de manera dinámica durante la ejecución del programa. Entonces se agregan funciones de cargas hacia esos bloques inalcanzables a través de punteros, lo cual tiene el efecto de confundir a los análisis estáticos sobre el posible valor que asignó el despachador de variables.

Técnicas de desofuscación Así como existen varias técnicas y mejoras para la ofuscación del código, también existen técnicas para lograr desofuscar el código, o mejor dicho, técnicas de ingeniería inversa sobre el código ofuscado algunas de las cuales se describen a continuación. • Clonación. Muchas de las técnicas de ofuscación se basan en la creación de rutas de ejecución falsas para engañar a los programas de análisis estáticos, debido a que esas rutas nunca van a ser tomadas en el momento de ejecución del programa, mas sin embargo, causan información engañosa que se propagará a lo largo del análisis y reducirá la precisión de la información obtenida, lo cual hará más difícil de entender la lógica del programa analizado. Esa información defectuosa tiene la característica de introducir imprecisiones donde los caminos de ejecución se cruzan. Una forma de resolver este problema o desofuscar el código es mediante la clonación de porciones de código, de tal manera que las rutas de ejecución falsas no se unan con la ruta de ejecución original.

Figura 2. Análisis de un código ofuscado en Javascript. Se puede notar que son pocas las cadenas de texto legibles por humanos. Determinar la semántica de un código (el que realiza) es sumamente complicado, por este motivo la mayoría de las herramientas de protección bloquean en su totalidad programas de Javascript

www.sg.com.mx

Esta transformación tiene que ser aplicada con sumo cuidado, debido a que si no se hace de esta manera, puede incrementar el tamaño del código, y más aun que lograr desofuscar el código, empeore el problema de desofuscación, sin embargo como la meta de la desofuscación del código es la de remover código ofuscado, la clonación implica que se tenga un conocimiento previo de la ruta de ejecución actual, lo cual podría lograrse mediante la clonación selectiva en ciertos puntos donde las rutas de ejecución se unen. NOV-ENE 2009

37


// PRÁCTICAS

/*PROGRAMACIÓN*/

“La ofuscación de código ha sido propuesta por un gran número de investigadores como un medio para dificultar la realización de ingeniería inversa sobre el código”. • Análisis de factibilidad de ruta estática. Este es un análisis estático basado en cadenas, que evalúa la factibilidad de una ruta de ser ejecutada. En este análisis primeramente se debe crear una cadena que corresponda con la ruta de ejecución, la construcción de esta cadena se puede realizar de varias maneras, pero la meta, es que tome en cuenta los efectos de las operaciones aritméticas sobre los valores de las variables de los bloques de código, y que nos represente la propagación de constantes a través de una ruta de ejecución del programa, y después se evalué si esa ruta de ejecución es factible o no. Algunas de las formas de crear las cadenas anteriormente descritas son las siguientes: • Asignación • Aritmética • Indirección • Bifurcaciones • Combinación de análisis estáticos y dinámicos. Los análisis estáticos convencionales son inherentemente conservadores, por lo tanto al aplicar técnicas de desofuscación meramente estáticas al código ofuscado, el conjunto de resultados son en realidad un superconjunto de ese código ofuscado, inversamente a lo que resulta si se aplican técnicas de desofuscación dinámica, que no pueden tomar todos los posibles valores de entrada, por lo cual este análisis solamente nos regresa un subconjunto del código ofuscado. La naturaleza dual de estos dos tipos de análisis sugieren que se debe intentar realizar un análisis que abarque estas dos aproximaciones de solución para desofuscar un código, lo cual se puede realizar de dos maneras, primero realizando un análisis dinámico y después uno estático para agregar partes al control de flujo del programa, o se puede realizar de manera contraria, empezando primero con el análisis estático y después el dinámico, lo que nos servirá para reducir partes del control de flujo del programa. De cualquier manera, cuando se realiza una combinación de estos dos tipos de análisis no se puede garantizar la precisión, sin em-

bargo si lo vemos desde el punto de vista de la ingeniería inversa, al unir estos dos tipos, nos podemos sobreponer a las limitaciones que nos causan el hecho de realizar un análisis estático o uno simplemente dinámico.

La Web 2.0 y Ajax La Web 2.0 ofrece soluciones para compartir casi cualquier contenido digital pero también presenta desventajas. En algunos casos, el usuario pierde el control de sus creaciones en favor de las empresas que prestan el servicio. Aunque O’Reilly sostenga que la persona controla sus propios datos, esto sólo sería cierto en algunos casos, pero no en todos. Un consumidor tiene la libertad de decidir qué contenidos publicar en una Web, pero una vez que están dentro del servicio, en muchos portales se pierde parte del control sobre la información aportada, además, surge el peligro potencial de que algunos de los usuarios suban código potencialmente peligroso. Ajax surge como una nueva forma de lograr tener aplicaciones a través de la Web, que a diferencia de las paginas estáticas, permite a los usuarios participar, interactuar y compartir de una manera más plena la información con los sitios Web, lo anterior abre un mundo de posibilidades de interacción con los usuarios de estos sitios, pero además trae consigo el correspondiente aumento de riesgos en la seguridad, tanto para los usuarios como para los mismos sitios. El principal riesgo de seguridad que nos trae esta nueva tecnología es el que el usuario no siempre está consciente del código que puede estarse ejecutando en su máquina, ya que Ajax nos proporciona una manera de interactuar de forma asíncrona con los sitios, lo cual puede ser muy útil, ya que evita tener que estar recargando constantemente el código de las páginas. Así mismo, esta característica que nos permite la comunicación asíncrona, también presenta el mayor riesgo, ya que en una página se pueden tener objetos incrustados, que a primera vista parezcan inofensivos, y no tengan mayor propósito destructivo, pero que posteriormente se encarguen de descargar o incrustar mas código, que al ser ofuscado logre burlar a los mecanismos actuales de análisis de seguridad.

Sandokan Barajas es pasante de la carrera de Ingeniería en Sistemas Computacionales próximo a obtener el títiulo. Trabaja dentro del Centro de Investigación en Ecosistemas (CIECO) de la UNAM Campus Morelia.

38

NOV-ENE 2009

www.sg.com.mx


Es por esto que la Web 2.0 como tal, tiene que mejorar sus actuales mecanismos de seguridad, pensando especialmente que los beneficios que nos pueda brindar su versatilidad tiene asociados nuevos riesgos y novedosas formas de lograr vulnerar la seguridad.

Conclusión La ofuscación de código dinámica es una nueva técnica que tiene varias ventajas y desventajas, dependiendo del punto de vista y uso que se le de a la misma. Pues si es aplicada como un mecanismo de seguridad, puede ser muy prometedora, ya que aunque sea una técnica que puede ser vulnerada mediante el uso de algunos análisis estáticos y dinámicos, proporciona un nivel un poco más elevado de seguridad. En cambio si es utilizada como una arma para lograr burlar los actuales mecanismos de defensa puede ser muy peligrosa, pues aunque se podría detectar su peligrosidad mediante algunos de los análisis mencionados en este artículo, consumiría mucho tiempo y lo más probable es que mientras se realizara este tipo de análisis, se descuidara algun otro aspecto de la seguridad. En cuanto a la web 2.0 como la llamo O’Reilly, existe un riesgo potencial debido principalmente a las características que la hacen tan útil, pero a la vez tan peligrosa, debido a que esa manera de compartir contenidos a través de la web podría traer consigo la diseminación de código ofuscado dañino y que sería difícilmente detectable por su capacidad de transformarse de una infinidad de maneras, y el hecho de que el motor de generación no se encontraría en el mismo código sino en otra ubicación, lo cual imposibilitaría realizar un análisis de ese motor para lograr averiguar la forma en que el código ofuscado es generado.

Referencias [ Sharath, U. “Deobfuscation Reverse Engineering Obfuscated Code.” Proceedings of the 12th Working Conference on Reverse Engineering (WCRE’05), 2005. ] [ Amit, V. “Cobra: Fine-grained Malware Analysis using Stealth Localized-executions”. Proceedings of the 2006 IEEE Symposium on Security and Privacy (S&P’06), 2006. ] [ Karen, H. “New attacks tricks antivirus software”. Innovative technology for computer professionals. Volume 40, Number 5, May 2007. ] [ Arboit, G. “A method for watermarking java programs via opaque predicates”. Procedings of 5th. International Conference on Electronic Commerce Research (ICECR-5), 2002. ] [ Collberg, C.; Thomborson, C.; Low, D. A taxonomy of obfuscating transformations, 1997. ] [ de Roo, Arjan; van den Oord, Leon. Stealthy obfuscation techniques: misleading the pirates. ] [ Ernst, Michael D. “Static and dynamic analysis: Synergy and duality”. In WODA 2003: ICSE Workshop on Dynamic Analysis, Portland, OR, May 2003. ] [ Arnaud, G. “Automated Metamorphic Testing”. Proceedings of the 27th Annual International Computer Software and Applications Conference (COMPSAC’03), 2003 IEEE. ] [ Karl, L. “Towards a Metamorphic Testing Methodology for Service-Oriented Software Applications”. Proceedings of the Fifth International Conference on Quality Software (QSIC’05), 2005. ]

www.sg.com.mx

NOV-ENE 2009

39


// PRÁCTICAS

/*administración de base de datos*/

Diseño de Base de Datos La Importancia de los Catálogos Por Victor Hugo García

Los catálogos, en una base de datos, son indispensables para un buen diseño de la misma. Es por eso la importancia de conocer las ventajas y desventajas de su uso. Comencemos definiendo “catálogo” en una base de datos. Un catálogo es una tabla de datos que contiene información relevante sobre las opciones finales de un usuario en una aplicación. A continuación menciono las ventajas y desventajas de los catálogos en el diseño de base de datos:

Ventajas • Permite una rápida obtención de los datos requeridos al momento de realizar una consulta. • Permite una reducción de tiempo en programación. • Permite al usuario final la posibilidad de realizar una modificación de manera dinámica a las opciones del software, fácil y rápidamente desde una administración. • Permite crear una base de datos normalizada.

Desventajas • El uso de memoria en el servidor SQL puede verse afectado. La desventaja puede ser solucionada con el uso correcto de las consultas SQL, tal es el caso de evitar productos cartesianos al momento de dicha consulta y en su reemplazo utilizar INNER JOIN, LEFT JOIN, RIGHT JOIN según se requiera.

esta se pierde completamente. Los errores humanos siempre hay que tenerlos presentes y por tanto, alguien como usuario final puede llegar a escribir el nombre de un país de la manera incorrecta. Además la normalización no está presente en este caso. Cuando se obtienen los datos de manera estática en el código, se presenta el problema en el tiempo invertido que se requiere en la programación de los elementos, así como el mantenimiento de ciertos módulos. Enseguida muestro una solución utilizando los catálogos: Se diseña la tabla –Cliente- y la tabla –Pais-, La tabla Pais almacena los datos que necesitamos con dos simples campos: “idPais y nomPais”, dicha tabla siendo relacionada 1:N con la tabla clientes, de esta manera es posible obtener la información necesaria del cliente con una simple consulta SQL, además de que el proceso de normalización e integridad de los datos se está dando de manera automática. Si el usuario final desea que su sistema sea capaz de aumentar los datos de los países, el administrador del catálogo Pais podrá agregarlo fácil y rápidamente. Inclusive, los reportes que se hayan programado no requerirán de inversión de tiempo, puesto que la información que se pida será obtenida mediante una consulta SQL. En la siguiente figura muestro un diagrama de clases de lo que sería una relación de la tabla cliente con la tabla país (1:N).

Ciertos desarrolladores necesitan ver un proceso de normalización de una base datos, sin embargo, si comienzas a diseñarla utilizando catálogos, dicho proceso puede llegar a ser innecesario. Ejemplo 1 “Un sistema requiere que almacene el país de origen de un cliente” pero este dato puede cambiar y/o aumentar en base a las necesidades del usuario final. El desarrollador puede elegir entre varias opciones: a. Agregar un campo de tipo cadena de caracteres, permitiéndole al usuario escribir el dato en un campo de texto. b. Añadir un campo de tipo entero y colocando un campo de selección obteniendo la información desde el código de manera estática.

Ejemplo 2 “Un sistema requiere que se almacene la especialidad de un médico” este dato se puede aumentar, actualizar y/o eliminar.

Los problemas que se generan cuando se utiliza un campo de tipo cadena de caracteres, radica en la integridad de los datos, pues en

La solución fácil y rápida pero errónea, sería crear un campo en la tabla médico llamado “especialidadMedico” y que este sea de tipo

Victor Hugo García es Líder de Desarrollo Web en C-Technologies. Es egresado del Instituto Tecnológico de Ciudad Guzmán. Cuenta con experiencia en el diseño de base de datos y programación con tecnologías .NET y PHP. Actualmente se encuentra desarrollando software en diversas verticales de negocio para clientes en Estados Unidos. Durante el 2007 colaboró con proyectos en el Gobierno del estado de Guanajuato.

40

NOV-ENE 2009

www.sg.com.mx


cadena de caracteres. Como he venido platicado, esta solución pierde completamente la integridad de los datos y por consiguiente la normalización de la base de datos no existe. Por tanto si se elige la solución por catálogos como se muestra en la figura siguiente:

Realizar búsquedas, generar reportes, obtener información para desplegar en alguna lista, etc., todo esto puede llevarse a cabo de manera rápida y eficiente. En todos los sistemas una búsqueda es básica e indispensable, por lo tanto imaginemos esto: El cliente desea una lista desplegable con las especialidades que se tienen para realizar un mejor filtrado de la información. Ahora, imagina esto en más de 10 páginas. Por ultimo imagina que el usuario final te comenta que se requiere agregar una nueva especialidad. Considerar la creación de un catálogo para un mejor control e integridad de la información sería ideal para solucionar varios problemas como el que se describe en el párrafo anterior. Si se requiere un reporte de todos los médicos de cierta especialidad, esto sería muy sencillo de obtener mediante una consulta SQL. Permitirle al usuario modificar las opciones de un sistema es siempre ideal, pues el usuario verá lo sencillo que es hacerlo desde un ambiente grafico. Cuando se necesita cotizar una aplicación, se debe dejar en claro al cliente, que el administrador del sistema será capaz de modificar opciones del sistema de manera fácil y rápida; tu cliente verá esto como un buen desarrollo. Cuando me encuentro en reuniones con clientes para hablar sobre las opciones que se desean en el sistema, siempre hay un punto en el que se comenta “Este módulo debe ser así, porque CASI NO se eligen esas opciones” es entonces cuando se tiene que realizar un análisis de ese caso, puesto que si eliges una opción errónea, al momento de entregar tu software se te diga que SIEMPRE SI se usarán dichas opciones, para solucionarlo te podrías ver en la necesidad de reprogramar uno o varios módulos; sin embargo, al elegir la opción de catálogos, simplemente se agrega el dato a la base de datos y listo. Finalmente podemos concluir que si los desarrolladores ven la importancia del uso de catálogos, esto puede significar auténticos ahorros en tiempo de programación, proceso de normalización y mejorar la integridad de los datos en la aplicación. www.sg.com.mx

NOV-ENE 2009

43


// PRÁCTICAS

/*arquitectura*/

Una Receta para Desarrollar Arquitecturas Con Procesos Bien Definidos Por Miguel Armas

Cuando llega el momento de desarrollar la arquitectura de un sistema de software, es normal que surjan dudas como: ¿Por dónde empezar?, ¿qué documentos y diagramas hay que hacer? ¿cuáles hacemos primero y qué orden seguimos? y muchas de las veces incluso dudamos de ¿qué es la arquitectura de software? En esta ocasión haremos un resumen del marco de trabajo para arquitecturas y en particular del método para desarrollar arquitecturas propuesto por The Open Group. Método que nos puede ayudar a responder las preguntas planteadas.

¿Qué es y para qué sirve la arquitectura? La arquitectura de un sistema de software nos ayuda a satisfacer los requisitos de calidad que debe cumplir un sistema de software permitiendo que la solución creada sea confiable, mantenible, estable, usable y todos los “able” que nos enseñan en la preparación académica acerca de este tema.

Nos quedaremos con la siguiente definición de arquitectura de software, proveniente del libro Software Architecture in Practice: La arquitectura de software de un programa o sistema de cómputo es la estructura o estructuras del sistema, la cual incluye los elementos del software, las propiedades externamente visibles de esos elementos y las relaciones entre ellos. Por elementos del software, debemos entender prácticamente todo lo que podamos representar en UML y aún más, clases, objetos, componentes, hardware, pantallas, requisitos, casos de uso, etc. Pero ¿cuáles son los pasos para describir y plantear las relaciones entre todos esos elementos? Es precisamente eso lo que veremos a continuación.

Madurez en la disciplina de arquitectura de software

Otro hecho en la vida de un proyecto es que la única constante en el desarrollo del software es el cambio. Una buena arquitectura nos ayuda a realizar estos cambios con menos tiempo y esfuerzo, además de facilitar la implementación de una estrategia de re-uso.

El desarrollo de software ha dejado de ser un arte y poco a poco se ha ido convirtiendo en una ingeniería, lo mismo ha sucedido con la disciplina de arquitectura de software, esta madurez es tangible por los siguientes elementos: • Un cuerpo de conocimiento (Body of Knowledge, BOK) de arquitectura. • Certificaciones como arquitecto de software. • Modelo de procesos para desarrollar la arquitectura de software.

El término arquitectura de software es uno de los más extensos y documentados, y me refiero a lo siguiente, si le preguntas ¿qué es arquitectura de software? a cinco desarrolladores, seguramente obtendrás cinco respuestas distintas, incluso el SEI (Software Engineering Institute) en su sitio en internet tiene una sección que recopila definiciones de arquitectura de software (www.sei.cmu.edu/ architecture/published_definitions.html).

Aún falta trabajo por realizar, ya que actualmente contamos con varias iniciativas para formar un BOK de arquitectura, habría que unificar estas iniciativas para ganar aún más madurez. Lo mismo sucede con respecto a las certificaciones como arquitecto de software, existen certificaciones de Microsoft, Sun e IBM solo por mencionar algunas. Esperemos que en el futuro veamos la unificación de todas las certificaciones existentes, pues

sería un buen paso en beneficio de la comunidad de arquitectos de software. Anteriormente no contábamos con un modelo de proceso para desarrollar la arquitectura de un sistema de software. Y en todo caso, algunos de estos pasos se llegan a contemplar en los modelos de procesos para desarrollo de software como el Proceso Unificado en el Marco de Trabajo para Soluciones de Microsoft (UP y MSF), Iconix, sólo por mencionar algunos. La buena nueva es que ya existe un modelo de procesos creado específicamente para el desarrollo de arquitecturas de software, el cual complementa muy bien a los procesos de desarrollo de software existentes, como los antes mencionados.

Un marco de trabajo para arquitectura The Open Group es un consorcio de usuarios y fabricantes de la industria de TI que cuenta con varios foros, de los cuales el de arquitectura ha sido uno de los más activos, una de las conclusiones de este foro en 1994 fue que era necesario desarrollar un marco de trabajo para la arquitectura empresarial, resultando de esta iniciativa el Marco de Trabajo para Arquitecturas de The Open Group (TOG Architecture Framework, o TOGAF). Aunque TOGAF no es el único marco de trabajo para la arquitectura de software. Algunos de los más relevantes al momento son: • The Zachman Framework for Enterprise Architecture. • TOGAF. • The Federal Enterprise Architecture (FEA). • The Gartner Methodology.

Mike Armas es consultor e instructor senior certificado por la OMG en Milestone Consulting, primer empresa mexicana miembro de la OMG, especializada en la capacitación práctica y consultoría en UML y las mejores prácticas de ingeniería de software. info@milestone.com.mx www.milestone.com.mx

42

NOV-ENE 2009

www.sg.com.mx


Sin embargo estos marcos de trabajo tienen una estructura y enfoque distintos entre ellos. Al de Zachman se le conoce mas como una taxonomía, el de TOGAF se enfoca más en el proceso, el FEA es una arquitectura empresarial implementada y el de Gartner es la experiencia y conocimiento acumulada por algunos expertos para desarrollar buenas arquitecturas empresariales. Dado el interés de la industria, en nuestra empresa hemos decidido seleccionar a TOGAF como la opción para incrementar el catálogo de cursos al público. Además de ser la opción más madura al plantear un proceso para desarrollar la arquitectura.

TOGAF Para TOGAF la arquitectura de TI empresarial no tiene que ver sólo con las aplicaciones de la organización. Pues, propone una arquitectura de TI que funcione para el negocio, es decir, que este alineada y apoye a las estrategias del negocio. La arquitectura de TI empresarial considera las arquitecturas técnicas y de negocio, crea una visión estratégica y lleva esa visión hasta su implementación. TOGAF tiene tres componentes principales para lograr lo anterior: • Método para desarrollar la arquitectura. • Enterprise continuum. • Base de recursos de TOGAF. El enterprise continuum es un repositorio virtual de patrones, modelos, descripciones de arquitectura y otros artefactos, que constituyen en si un marco de trabajo dentro del marco de trabajo de TOGAF, que sirve para clasificar tanto el material del repositorio como al resto de modelos relevantes y similares que existen en la industria. La base de recursos es el conjunto de lineamientos, plantillas e información relacionada. El Método para desarrollar la arquitectura (Architecture Development Method, ADM) lo detallaremos en la siguiente sección. www.sg.com.mx

TOGAF más que ayudarnos a describir una Arquitectura Orientada a Servicios (SOA por sus siglas en inglés) particular, nos ayudará a decidir si SOA es lo mejor para el proyecto. La metodología de TOGAF ayuda al arquitecto a destilar el proyecto hasta el punto de tomar la decisión de si SOA es el estilo de arquitectura que nos ayudará a resolver mejor el problema original.

El método para desarrollar la arquitectura El ADM de TOGAF es una especie de “CMMI para arquitectura”. Nos presenta un proceso iterativo con fases que se deben realizar para desarrollar la arquitectura, definiendo las entradas y salidas de cada fase pero sin indicarnos como hacer cada uno de los entregables. Prelim: Framework and Principles

H. Architecture Change Management

G. Implementation Governance

F. Migration Planning

B. Business Architecture

E. Opportunities and Solutions

• Fase B. Arquitectura de negocio, se busca tener clara la arquitectura de negocio y sus metas para posteriormente poder alinear la TI al negocio. • Fase C. La arquitectura de sistemas de información contempla las arquitecturas particulares para datos y aplicaciones. • Fase D. La arquitectura tecnológica define la arquitectura integrada que se desarrollara en fases futuras. • Fase E. La fase de oportunidades y soluciones permite determinar qué partes se comprarán, construirán o reutilizarán y cómo se implementará la arquitectura de la fase D. • Fase F. El plan de migración sirve para priorizar los proyectos y desarrollar el plan de migración.

A. Architecture Vision

Requirements Management

tura definiendo el alcance y la estrategia para lograrla.

C. Information Systems Architecture

D. Technology Architecture

Figura 1. Fases del ADM de TOGAF

La fase preliminar es el momento en el cual se inicia el proceso de adopción del ADM al interior de la organización, difundiendo los beneficios e involucrando a todos las personas necesarias. • Fase A. Visión de la arquitectura, implica desarrollar una visión de la arquitec-

• Fase G. Control de la implementación es la ejecución de los proyectos para construir las soluciones de TI. • Fase H. La administración del cambio de la arquitectura implica monitorear y evaluar los sistemas existentes para determinar cuándo iniciar un nuevo ciclo de ADM.

Conclusión Contar con y conocer un proceso bien definido que nos indica paso por paso cómo se debe desarrollar la arquitectura empresarial es indispensable para un buen arquitecto. De otra forma no existe un consenso respecto a los documentos y diagramas que se deben tener para definir la arquitectura de un sistema de software. Sin embargo el ADM, como cualquier modelo de procesos, debe adoptarse gradualmente, sin intentar implementarlo de inmediato al 100% y en todos los proyectos.

NOV-ENE 2009

43


// PM CORNER

La integración de un equipo de trabajo funcional Reto del Líder de Proyectos de Tecnologías de Información Por Francisco Vaca

En este artículo reflexionamos sobre la dificultad que tienen los líderes de proyectos para integrar equipos de trabajo altamente funcionales y productivos. En muchos casos la solución consiste en utilizar enormes cantidades de energía personal y de la organización para “hacer que las cosas sucedan” con lo cual pudiera parecer que se logran los resultados sin embargo los altos costos y efectos negativos secundarios no son evidentes. Proponemos que la labor de líder más que asegurar que “todos estén trabajando” consista en crear un contexto apropiado de trabajo en el que las personas que participan en el proyecto o en la tarea se integran de forma voluntaria y ordenada. “El mercado laboral para los profesionistas de TI demanda cada vez más personas con competencias para la conducción de grupos de trabajo bajo condiciones de alta presión, ambigüedad y recursos limitados” Esta afirmación no parece contener gran sabiduría ni grandes capacidades de observación para llegar a ella, sin embargo para el profesional de las tecnologías de información de principios del siglo XXI puede arrojar algunas reflexiones interesantes. Centrémonos en las competencias para la conducción de equipos de trabajo: Una carrera profesional exitosa conduce, en muchos casos, a un punto en el que se tiene a un grupo de personas sobre las que hay poco o ningún poder formal, un objetivo que cumplir, recursos limitados y unas expectativas enormes para cumplir fechas y presupuestos para entregar un producto terminado.

En este momento “crítico” los únicos patrones de conducta para conducir al equipo de trabajo posiblemente sean los aprendidos en la propia empresa o institución, los cuales resultan insuficientes con mucha frecuencia y los aprendidos en otros sitios posiblemente no se puedan aplicar. Ante el reto de la conducción del equipo planteemos el primer paso: La integración del mismo lo cual supone encontrar respuestas a peguntas como; ¿por dónde empiezo?, ¿cómo “integro” al equipo?, ¿cómo hago para que “se pongan la camiseta”?. Hemos visto como muchas personas (aún profesionales con largas carreras) no tienen buenas respuestas ya que su punto de partida contiene supuestos falsos u obsoletos: • “Son profesionales, tienen que cumplir el objetivo planteado” • “Es su chamba, no se los tengo que pedir” • “Estamos en el mismo barco” • “Hay que echarle ganas” • “Sé que tenemos algunas indefiniciones, pero vamos comenzando y las vamos resolviendo” • “Nos llevamos muy bien” Poco tiempo después comienzan los problemas y las frustraciones: cada quien “jala” por su lado, la gente dice que sí pero no cumple, no hay compromiso, no hacen caso… los trucos que utilizamos parecen no funcionar: hablarles suavecito o duro, leerles la cartilla, acusarlos con los jefes, hacer minutas detalladas, listas de tareas, estar detrás de ellos presionándolos… nada parece moverlos hacia delante ni motivarlos lo suficiente… a pesar de esto los vemos ocupados y dedicándole largas horas a su trabajo pero ¿y los resultados?.

Al final a base de “puro músculo” vamos avanzando y unos pocos días, semanas, meses o años más tarde entregamos un producto que hace cosas que se planearon, más cosas que no se planearon, otras más que ni se pidieron ni se planearon pero que ahí están a un costo 10%, 50%, 200% más alto del que se estimó al principio. ¡Listo!, ¡El siguiente! y vamos de nuevo… a vivir otra vez la misma película. Una forma más razonable para iniciar el proceso de conducción del equipo consiste en tener un mejor punto de partida: • Las personas no son integradas, las personas se integran. No hay autoridad formal por grande que sea, que ordene a una persona “intégrate” y que ésta se integre. A la larga (posiblemente más temprano que tarde) habrá problemas que pueden ir desde una resistencia pasiva hasta resistencias activas que producen conductas “tóxicas” para el equipo. • Las personas tienen una jerarquía de valores a partir de los cuales actúan y no necesariamente están alineados con los valores que se necesitan para cumplir con los objetivos. • Las personas tiene egos que los hacen actuar de forma individual, defensiva, y hasta de forma agresiva. • Las personas no comparten un objetivo por el simple hecho de comunicarlo y por más que creamos que es atractivo y deseable. La labor del líder consiste en crear las condiciones apropiadas para que las personas

Francisco Vaca Gómez es socio director TEDE de 2006 a la fecha. Ha realizado diseño e implementación de proyectos de educación basados en competencias, instrucción de programas de educación basados, investigación y promoción de la educación basada en competencias.

44

NOV-ENE 2009

www.sg.com.mx


puedan elegir de forma libre y voluntaria formar parte del equipo. Estas condiciones son: • Mantener el ego del líder bajo control. • Alinear los valores de las personas con los valores que necesitamos. • Objetivo compartido. • Claridad del rol. • Claridad en la responsabilidad.

• Alinear los valores de las personas con los valores que necesitamos. La alineación de los valores consiste en lograr un acuerdo sobre lo que es importante para el logro del objetivo y el desempeño del equipo, por ejemplo ¿qué es más importante el tiempo o el presupuesto?, ¿la rapidez o la calidad?, ¿la innovación o la confiabilidad de la solución?.

A continuación procedemos a describirlas:

En los casos que mencionamos podemos ver que lograr uno, es a costa de no cumplir el otro, esta situación puede provocar que una persona nos diga “SI” y luego descubramos que hizo otra cosa muy diferente.

• Mantener el ego del líder bajo control. Un ego bajo control consiste en primer lugar en reconocer que necesitamos cambiar, ajustar o adquirir conductas más efectivas para integrar un equipo. En segundo lugar aceptar a las personas tal como son: con sus fortalezas, debilidades, valores y objetivos personales. Por último significa aceptar que nuestra responsabilidad es asegurar que permitimos y facilitamos el crecimiento y desarrollo de los demás, inclusive en circunstancias que impliquen “el de ellos antes que el mío”.

www.sg.com.mx

• Objetivo compartido. No lograremos que las personas compartan un objetivo repitiéndolo una y otra vez; una forma segura de lograr que las personas compartan el objetivo es hacerlos participes del proceso de formulación y acuerdo de los objetivos. Pudiéramos recibir un objetivo general pero podemos establecer muchos objetivos intermedios que vayan conformando el cumplimiento del gran objetivo.

• Claridad del rol. Tener claridad sobre el rol que le toca a cada persona consiste en que ésta, tiene claro cómo es su aportación al equipo, en general los roles que definen, aprueban, construyen y controlan. • Claridad en la responsabilidad. La responsabilidad consiste en que cada miembro del equipo conoce y acepta los resultados que dependen de su intervención directa y por supuesto las consecuencias de que esos resultados no se den.

Conclusión Podemos agregar que una barrera muy significativa que encontramos para “iniciar por el principio” consiste en que recibimos presión o nosotros mismos nos presionamos para pasar de inmediato a la acción, sin darnos cuenta que se van a evitar muchos conflictos, reprocesos y errores por no dedicarle el tiempo necesario a integrar al equipo.

NOV-ENE 2009

47


// COLUMNA invitada

Desarrollo de Software, Analogías y Algo Más… Cuidado con las Semejanzas Por Carlos Ordóñez

D

esde hace mas de 40 años, cuando se adopta a la ingeniería de software como modelo para crear programas de cómputo, los ingenieros de software nos hemos dado a la tarea de asignar diferentes analogías acerca de cómo entender el desarrollo de software, basta con hacer una búsqueda con el texto “Desarrollar software es como” para darnos cuenta de la utilidad y creatividad que encontramos para explicar nuestra realidad, pues al final, un sistema de cómputo es una abstracción, una simulación en bits de lo que nos acontece. Una analogía se realiza asumiendo que si dos entes son semejantes en uno o varios aspectos, entonces es probable que se parezcan en otras facetas, este escrito pretende ser un panfleto técnico donde se analizan algunas analogías planteadas y cuyo único objetivo es el sembrar la semilla de la reflexión en todos aquellos colegas que se apasionan por eso que llamamos: Ingeniería de software…

mejora y al terminar el proceso tenemos un excelente párrafo, claro, con la inversión/desperdicio de una considerable cantidad de tiempo al haber tirado tres borradores antes de llegar al definitivo. Esta analogía al igual que todas aquellas donde se compara la ingeniería de software con un proceso de arte creativo (producción cinematográfica, escultura, pintura) por experimentación, ha sido de gran utilidad pues al evaluar nuestro proceso desde este enfoque nos damos cuenta que esta aproximación, jamás será la opción mas óptima cuando ya sabemos qué es lo que queremos desarrollar y conocemos las restricciones, pero sí funcionará para la creación e investigación de nuevas e innovadoras piezas de software.

De la línea de producción

De la poesía

Esta analogía, parte del hecho que el software, al tener un lenguaje, se lee y se escribe, Richard Gabriel dijo: “Desarrollar software es como escribir poesía, antes de hacer un buen poema tienes que leer miles de fuentes para aprender a escribir con la métrica adecuada y adoptar un estilo propio”. Esta analogía parece muy buena, pues si analizamos el proceso de escribir poesía, normalmente se comienza por redactar un párrafo, para luego evaluarlo y darnos cuenta que no es lo que buscamos y destruimos el papel donde está escrito. Después escribimos un nuevo párrafo, y nuevamente lo desechamos porque no cumple con las características necesarias y a generar un nuevo párrafo, este último parece no estar tan mal, se adapta, se

Esta analogía nos permite comprender como el proceso de desarrollo de software, desde una perspectiva de fabricación en serie, donde con base en una especificación inicial, el producto se construye, se valida, se empaca y se entrega, en esta categoría caen todas aquellas analogías que hacen referencia a una cadena de valor: manufactura, restaurantes de comida rápida, ensambladoras, etc. Principalmente se enfocan en como detectar lo que realmente le está agregando valor a mi producto terminado. Esta es una analogía muy común, y que llega a su formalización con la liberación del “Framework for Software Product Line Practice”, un marco de trabajo creado por el SEI (Software Engineering Institue) donde claramente se define una línea de producción de software como: “(…) Subconjunto de sistemas de software que comparten funcionalidades comunes satisfaciendo las necesidades específicas de un

Carlos “Fofo” Ordóñez es Ingeniero en Sistemas Computacionales por el ITESO. Cuenta con varias certificaciones por IBM y Sun Microsystems. Actualmente dirige un conjunto de proyectos de desarrollo en el centro de entrega global de TATA Consultancy Services. Es profesor asociado del ITESO, donde imparte materias de diseño, programación e Ingeniería de Software. La información en este artículo representa el punto de vista del autor y no necesariamente el de TATA Consultancy Services o ITESO. fofo@iteso.mx

46

NOV-ENE 2009

www.sg.com.mx


“Comparar con otras actividades, es útil cuando te permite formular preguntas, pero es peligroso cuando lo utilizas para justificar tus respuestas”.

segmento en particular, y que son previamente desarrolladas con base en un conjunto de activos de forma preescrita” Ese proceso de fabricación implica el uso de entornos de desarrollo especializados y configurados como esquemas, Domain Specific Languages (DSLs), patrones, frameworks, generadores de código, librerías especializadas, etc, todos coordinados y definidos de tal forma que integrados formen un tipo determinado de aplicaciones. “Los conceptos de fábrica se aplican de forma correcta a compañías donde se necesitan desarrollar varias versiones de sistemas similares o la construcción de soluciones basadas en un conjunto de requerimientos bien entendidos y con muchas restricciones externas” (CUSUMANO Michael, “The business of Software”, Nueva York, 2004). Como lo escribe Cusumano, esta aproximación funciona para desarrollos repetitivos y para un dominio o industria en especifico, pero como podemos notar, el proceso creativo queda completamente mermado por el proceso de construcción, y los problemas comienzan cuando queremos incluir como parte del proceso de fabricación un desarrollo de investigación para crear nuevas piezas de software, donde no existe un conjunto de activos que nos permiten fabricar los componentes de nuestra aplicación.

De la ingeniería civil

Esta analogía ha sido utilizada por muchos años y se fundamenta en las similitudes que existen entre el proceso de construcción inmobiliaria y el proceso de desarrollo de software. Es un hecho que no es lo mismo edificar una casa pequeña, que construir un rascacielos, pero para ambos se necesita analizar las necesidades, diseñar un conjunto de planos, comenzar la construcción, validar que esté quedando como fue acordado y finalmente entregarla. Como en cualquier proyecto de ingeniería, necesitas un plan para gestionar el proyecto, considerar componentes existentes que se www.sg.com.mx

pueden integrar, un conjunto de principios y herramientas estandarizadas para la construcción. Puedes gestionar el proyecto de inicio a fin, o dividirlo en pequeñas mejoras (Iterativas) con revisiones periódicas con los involucrados. La polémica comienza cuando incorporamos la siguiente cuestión: Los edificios son bienes físicos, mientras que el software, es un bien intelectual”, y desde esta perspectiva, el software nos permite realizar transformaciones imposibles en el mundo físico. Esto cambia por completo el panorama, pues los principios y reglas de los que hablamos anteriormente, en el mundo del software permanecen en constante evolución, y es entonces cuando nuestros proceso de diseño, con base a un conjunto de necesidades tiene que tomar en cuenta que el entorno se modificará y los involucrados cambiarán de parecer, y será entonces necesario crear una nueva pieza de software, donde este proceso es un proceso creativo, mas parecido al de escribir poesía.

De la ingeniería de software La ingeniería de software es un campo muy joven aun, tanto que resulta imposible evitar su evolución, y como consecuencia las analogías con las que la describimos tienden a cambiar por completo, de ser complementarias a ser conflictivas, algunas mejores que otras, todas tratando de explicar nuestra experiencia, lo que no es válido es tratar de forzar nuestros procesos para adaptarlos a la analogía, pues al final, la ingeniería de software es un modelo procesal para desarrollar sistemas de cómputo que cumplan con las necesidades de los involucrados, y jamás será: “hacer hamburguesas de McDonalds”, “edificar construcciones”, “escribir novelas”, “fabricar panecillos”, “hacer una película” o “cocinar chilaquiles”. “Comparar con otras actividades, es útil cuando te permite formular preguntas, pero es peligroso cuando lo utilizas para justificar tus respuestas (…), esto nos puede ayudar a revisar nuestras prácticas desde un punto de vista diferente, a cuestionarnos sobre como trabajamos”. Martin Fowler, December 2004.

Conclusión Podemos utilizar las analogías para facilitar la comprensión y explicar partes del proceso, pero jamás para explicar todo el ciclo, porque ese ciclo es único y flexible, pues desde mi punto de vista eso hace que la nuestra, sea un rama única e incomparable.

NOV-ENE 2009

47


// COLUMNA

/*tendencias en SOFTWARE*/

¿La Muerte del Software en su Forma Actual? El futuro de Windows: “Strata” Luis Daniel Soto Es 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 debate sobre que el 90% del software que hoy se utiliza pueda ser entregado como servicio está energizando las conversaciones del futuro del software, creando encabezados alarmistas. El anuncio de la muerte del software en su forma actual es prematuro: estamos observando una evolución y no una revolución.

Antes y después de Internet Hay que señalar que el requerimiento de las empresas, es utilizar el software para desarrollar mejor su negocio y ofrecer ventajas competitivas, sin importar el mecanismo de entrega. Es absurdo el abrirse a ultimatum “todo o nada”. Aclaremos las razones iniciando por entender las ventajas de dos modelos.

Software tradicional

· Respuesta inmediata por el uso de recursos locales · Opera fuera de línea, sin red · La privacidad está en control del usuario · Usuarios acostumbrados a esta experiencia · Alta capacidad de ser personalizado · Visibilidad y control · Alta manipulación de datos con aplicaciones

Software entregado como servicio · Redundancia de datos · Alcance mundial · Aprovisionamiento sencillo · Agilidad empresarial · Administración · Instalación casi nula · Acceso sencillo · Mantenimiento y nuevas versiones ocurren de forma automática · Acceso desde casi cualquier dispositivo a (casi) cualquier hora · Nuevos modelos de negocio

Pocos argumentarían que Internet ha transformado nuestras vidas de forma muy amplia. Casi nadie está en desacuerdo con que el tener la flexibilidad y opción de seleccionar una forma mixta de operar es crítica para el negocio. Es poco realista pensar que una empresa Fortune 50 tiene los mismos requerimientos que una empresa pequeña o un estudiante. Las normas de privacidad de datos en algunos países hacen difícil entender un escenario 100% en la nube. ¿Cómo una PyME en crecimiento puede transferir requerimientos básicos de cómputo en otros más avanzados?. La visión miope de entrega como servicio es incapaz de permitir conversaciones balanceadas. La combinación de “clientes” y “centros de datos” tanto internos como externos permiten edición dinámica en una PC, movilidad del teléfono y ubicuidad de trabajo. Las suites web como Netsuite y Zoho ofrecen ahora operación fuera de línea con Microsoft Office. Salesforce.com y Google Gears son ejemplos del reconocimiento de este modelo. Apple también lo reconoce: “I think the marriage of some really great client apps with some really great cloud services is incredibly powerful and right now, can be way more powerful than just having a browser on the client ”– Steve Jobs

48

NOV-ENE 2009

¿Cómputo en la nube? Aquí hay una primera confusión de términos: Web 2.0 se refiere a habilitar “la era de la participación” y “un internet más allá de texto e imágenes”. El problema es que el desarrollo de estas aplicaciones es muy complejo. Integrarlo a los sistemas existentes es otro reto significativo. Hay que entender cuál es la visión de “cómputo en la nube” de cada proveedor. ¿Es un outsorcing convencional? EDS e IBM han jugado en este campo por años. En Microsoft creemos que la diferencia fundamental está en la capacidad de construir software a la medida de forma simple. Windows “Strata” es el nombre clave que ofrece: • Menores costos. Mediante economías de escala de Internet, se ofrece arquitectura y ambiente escalable para que los desarrolladores ofrezcan servicios en Internet a costos menores que operados localmente. • Capacidades totales. Las ofertas iniciales de almacenamiento en la nube imponen restricciones en manipulación de datos. Pretendemos que todas las funciones de la plataforma aplicativa .NET, SQL Server y Biztalk operen para construir todo tipo de aplicaciones. • Mayor productividad. Visual Studio no solo ofrecerá desarrollo para cliente, dispositivos portátiles y servidor: también para la nube. Windows “Strata” incluye servicios fundamentales y servicios para construir aplicaciones, que permiten a los terceros entregar software. La mejor manera de disipar dudas de disponibilidad y seguridad es iniciando su evaluación inmediatamente. Servicios ServiciosTerminados terminados

Bloques Bloques de de construcción construcción

Servicios Servicios Básicos básicos

• Soluciones personales

Dispositivo, Sincronizar, Admi-

Cómputo (10% CPU, 1 CPU,

“Windows Live”

nistración de aplicaciones,

5000 CPUs), Almacena-

• Soluciones empresa-

Identidad, Control de acceso,

miento, Administración de

Gestión de Base de datos, Flu-

servicios, Redes, Distribu-

jos de Trabajo, Bus de servicios...

ción, Operaciones, Hardware

riales “Microsoft online”

Los clientes como Windows 7 y Windows Mobile 6.5; y el software en servidor continuarán un trayecto de evolución que responde a la juventud de la industria: hay mucho por hacer y ofrecer.

Conclusión El debate real es como las empresas atenderán las necesidades de los distintos tipos de usuarios aprovechando los avances de hardware en los dispositivos electrónicos portátiles y la innovación de software – la ubicación no importa... La nube es todo, pero sola, no es nada.

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


www.sg.com.mx

NOV-ENE 2009


// COLUMNA

/*PRUEBA DE SOFTWARE*/

Complejidad del Software Una Métrica Importante Para la Prueba de Software Luis Vinicio León Carrillo es actualmente Director General de e-Quallity, empresa especializada en prueba de software. Fue profesorinvestigador en el ITESO durante varios años, que incluyeron una estancia de posgrado en prueba de software en Alemania, en la que abordó aspectos formales de dicha 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 pasado, al hacer el análisis de los resultados del Concurso e-Quallity 2008 (ver e-quallity.net), hacíamos referencia a la complejidad de los productos participantes. Aunque no es el único, la complejidad es un atributo del software muy útil al distribuir adecuadamente el esfuerzo de prueba, porque ahí donde hay más complejidad hay más propensión a errores1. No estamos hablando de dificultad de desarrollo, que es algo más bien subjetivo que guarda dependencia con el nivel de experiencia del desarrollador, sino de un aspecto que puede ser medido de manera objetiva. Veamos a detalle esta característica.

Las caras de la complejidad del software Podemos hablar de dos vistas de la complejidad de un producto de software: la externa, que tiene que ver con el problema que resuelve el sistema (el proceso de negocio); y la interna, que se refiere a la manera como está programada la solución. En la interna podemos distinguir al menos los siguientes aspectos: • Su tamaño. Entre más grande sea un producto, mayor será su complejidad. Una métrica de tamaño (bastante primitiva, pero muy accesible y común) son las líneas de código (LCs). • Su estructura. Consideremos las siguientes abstracciones de subrutinas: 1. Una subrutina de 10 LCs con instrucciones primitivas (v.gr. asignaciones):

50

NOV-ENE 2009

(n) {

1: I1.1; 2: I1.2; … 10: I1.10;

}

Una subrutina de 7 LCs con instrucciones compuestas y primitivas: f2 (n) { 1: I2.1; 2: if Cond2.1 then 3: I2.2; 4: else 5: while Cond2.2 6: I2.3; } 7: I2.4;

Una subrutina de 5 LCs con instrucciones compuestas y primitivas: f3 (n) { 1: I3.1; 2: if Cond3.1 then 3: f3 (Exp3.1); 4: else 5: f3 (Exp3.2); }

Si no tomáramos en cuenta la complejidad interna, sino sólo el criterio del tamaño, diríamos que f1 es la más grande de las 3 subrutinas, pues tiene más LCs. Sin embargo, puede verse que no tiene la misma complejidad una secuencia de x instrucciones primitivas, que otra de llamadas recursivas.

La externa nos habla de la complejidad del problema, de la funcionalidad que se requiere del producto. Una métrica utilizada para medir este tipo de complejidad son los puntos de función3, que tienen la interesante ventaja de que se pueden obtener incluso a partir de los requerimientos. Una desventaja es que, si bien el algoritmo para calcularla no es complejo, no es trivial y sí es laborioso; lo peor es que obtenerla automáticamente a partir de requerimientos –cuando resultaría más útil– es prácticamente imposible a menos que éstos hayan sido especificados utilizando un lenguaje formal (como los de programación), situación casi exclusiva de los métodos formales4.

Impacto de la complejidad en la prueba de software Como mencionamos, ahí donde la complejidad en el software es mayor, hay más propensión a errores, lo que en particular implica que debemos probar más. Esto también podemos verlo si comparamos los grafos de control asociados a las primeras subrutinas mostradas arriba:

Durante el análisis sintáctico, los compiladores se dan cuenta de la cantidad de instrucciones de las que consta el programa que se procesa, y verifican si la estructura de los programas siguen las reglas gramaticales del lenguaje en cuestión2. Sería relativamente sencillo implementar una métrica inductiva dentro de los compiladores, que durante el procesamiento de un programa asociara una complejidad a cada tipo de construcción (tanto de datos como de control) para obtener la complejidad del todo combinando las de las partes. Del programa se puede obtener automáticamente la complejidad interna de la solución.

Figura 1. Izquierda: grafo de f1; derecha: grafo de f2

www.sg.com.mx


“Podemos hablar de dos vistas de la complejidad de un producto de software: interna y externa”.

En el segundo grafo, la cantidad de rutas distintas necesarias para visitar todas las aristas es mayor, lo que hace crecer también la cantidad de casos de prueba que se deben diseñar y aplicar.

Algunas reflexiones • Es muy importante tratar de mantener lo más simple posible los diseños y los programas de los sistemas que se desarrollan. Esto no solo reduce la probabilidad de introducir errores, sino que puede facilitar el mantenimiento, el reuso, y la prueba de software.

www.sg.com.mx

• La complejidad interna que considera la estructura de un sistema ofrece un dato más preciso que la métrica primitiva de la cantidad de líneas de código. Sin embargo, a pesar de que ese dato podría proporcionarlo fácilmente los compiladores, no es algo que suelan proveer. • Sería muy útil obtener de manera automática la complejidad externa de un sistema (asociada a la funcionalidad) en fases tempranas del proceso de desarrollo de software (luego de especificar los requerimientos), pues ello aceleraría también el resto del proceso (comenzando con las estimaciones e incluyendo las pruebas).

Referencias [ 1. León-Carrillo, L. “The Impact of Software Testing in small Settings”, en Oktaba, H. and Piatini, M. Software Processes in small Enterprises. IGI Global, 2008. ] [ 2. Aho, A.; Lam, M.; Sethi, R.; Ullman, J. Compilers: Principles, Techniques, and Tools. Second edition. ] [ 3. Garmus, E.; Herron, D. Function Point Analysis: Measurement Practices for Successful Software Projects. Addison Wesley ] [ 4. Jean-Francois Monin, J-F. Understanding Formal Methods. Springer Verlag. ]

NOV-ENE 2009

51


// TECNOLOGÍA

/*INFRAESTRUCTURA*/

Tecnología RFID Como Dispositivo de Seguridad Novedades en el 2008 Por Beatríz Ríos y Luis Joyanes

El presente artículo pretende mostrar un resumen del estado del arte sobre las tecnologías RFID (Radio Frequency Identification, identificación por radiofrecuencia), se presentan algunas noticias importantes publicadas en la página oficial de RFID en España y las distintas controversias que la tienen en el campo de la investigación.

Tecnologías RFID La seguridad de las computadoras se enfoca principalmente a evitar que la información almacenada sea alterada, robada o interceptada para realizar delitos informáticos, el campo incluye la protección de transferencias de fondos electrónicas, información propietaria (diseños de producto, listas de cliente, etc.), programas de computadora, otras comunicaciones y la prevención de los virus. Existen en la actualidad un gran número de soluciones, herramientas y dispositivos disponibles, dependiendo de lo que requiera mayor atención, entre ellos, los nuevos y avanzados dispositivos usados como herramientas de monitoreo, la tecnología llamada: RFID, que ha creado un gran debate entre diversos planos sectoriales, ya que tiende a suponer grandes beneficios en la gestión de la cadena de suministros, sobre todo en el sector de alimentación, farmacéutico y bebidas. Su implementación abarca un radio amplio de aplicaciones como: salud, alimentación, fabricación, transporte, distribución, ventas, seguimiento de ganado, localización de niños y animales, antirobo, construcción, alquiler de equipos, pago inteligente, venta inteligente de boletos, control de acceso a edificios, servicios públicos, aéreo, etc3.

¿Qué es RFID? Es un sistema basado en agentes dentro de tarjetas y lectores, es una tecnología, un método de identificación automática para el intercambio de datos remotos usando dispositivos llamados etiquetas de RFI o repetidores1. Una etiqueta RFID es un dispositivo pequeño, que puede ser adherida o incorporada a un producto, animal o persona.

RFID es un término genérico para describir un sistema que transmite la identidad de un objeto o persona (en forma de un único número de serie) de forma inalámbrica, usando ondas de radio. Está agrupada en la categoría de tecnologías de identificación automática. Las tecnologías de identificación automática incluyen códigos de barras, lectores ópticos de caracteres y algunas tecnologías biométricas, como escaneo de retinas1. Esta tecnología, junto al EPC (Código Electrónico de Producto), harán posible el rastreo y seguimiento de productos en tiempo real permitiendo una “visibilidad” casi perfecta de la mercancía desde el almacén de materia prima hasta el punto de venta1. El Código Electrónico de Producto es un número único que se graba en el chip contenido en una etiqueta RFID y se coloca en cada producto, lo que permite hacer un seguimiento exacto de cada unidad física en la cadena de suministros.

¿Dónde empezó todo? Durante la Segunda Guerra Mundial los Británicos desarrollaron el sistema llamado IFF, (Identify: Friend or Foe, Identificación: amigo o enemigo), sobre el que está basado el sistema actual de control de aviación privada y comercial. Esta aplicación fue el primer uso obvio de la tecnología de RFID. Otras de la primeras aplicaciones comerciales para RFID fueron en 1980 y 1990 las etiquetas de inventarios en pagos de tarifas de peaje en caminos, en pisos de tiendas o directamente en el ensamblado de automóviles. Existen también versiones de este sistema para implantes en humanos, como VeriChip en 2006. La práctica de implantar el chip a las personas es limitada, la mayoría de los implantes son usados para fines clínicos, para alertar al personal médico de las condiciones que un paciente tiene, en el caso de que esa persona no pueda comunicar los síntomas. México fue el primer país donde se usó para implantes en humanos en el 2004 se colocó un chip diminuto, menor que un grano de arroz a 18 agentes de la Procuraduría General de la República (PGR) para identificarlos cuando tuvieran contacto con documentos confidenciales y evitar así la corrupción4.

Beatríz Ríos catedrática del Instituto Tecnológico de San Luis Potosí, México. Ha trabajado en la banca en México, participado en el desarrollo de sistemas para empresas y docencia en ingeniería de software, sistemas operativos, lenguajes de programación. Actualmente estudiante del doctorado en Informática en ingeniería de Software en Universidad Pontificia de Salamanca en Madrid, España.

52

NOV-ENE 2009

www.sg.com.mx


Fábrica

Supermercado

Almacén

El Código de Producto (EPC) identiica inmediatamente el contenido de los pallets descargados en el almacén de distribución.

Figura 1. Diagrama de cadena de suministro con RFID

El presidente actual de Colombia declaró que se podrían implantar estos chips a los ciudadanos colombianos que quisieran ir a trabajar a Estados Unidos, para que el gobierno de ese país pudiera controlar su ubicación4.

• Etiquetas pasivas. Tienen 2 componentes conectados entre sí, un microchip y una antena. Estas etiquetas son las de menor tamaño, por ende las más livianas y con una vida útil que puede ir hasta los 99 años8.

Un reconocido club en Barcelona, España, utiliza un VeriChip para identificar a sus clientes VIP, lo utilizan para comprar las bebidas. El departamento de policía de la Ciudad de México ha implantado el VeriChip a unos 170 de sus oficiales de policía, para permitir el acceso a las bases de datos de la policía y para poder seguirlos en caso de ser secuestrados.

Pueden proporcionar información sobre la identificación y localización sobre el producto marcado con la etiqueta como por ejemplo precio, color, fecha de compra, etcétera, son usadas en los puntos

Un empresario del estado de Washington se implantó un chip RFID en su mano izquierda a principios de 2005. El chip medía 12 mm de largo por 2 mm de diámetro y tenía un radio de acción para su lectura de dos pulgadas (50 mm). Cuando le preguntaron qué pretendía hacer con el implante, él respondió: “estoy escribiendo mi propio software y lo estoy soldando sobre mi propia materia, prácticamente esto es lo que deseo”.

Clasificación Las etiquetas RFID se pueden clasificar principalmente en tres categorías, dependiendo del alcance y capacidad de memoria: pasivas, activas y semiactivas o semipasivas.

www.sg.com.mx

NOV-ENE 2009

53


// TECNOLOGÍA

/*INFRAESTRUCTURA*/

de venta en estaciones de gasolina y edificios con sistema de control de accesos, no tienen fuente de alimentación propia. Ejemplos de ellas tenemos: el sistema de compra rápida SpeedPass, funciona cuando el llavero con la etiqueta ondea enfrente de una área especial de la bomba de gasolina, una etiqueta lectora dentro de la bomba, lee el número secreto contenido dentro del dispositivo, que corresponde a la cuenta del cliente en curso del sistema SpeedPass, en este punto una insignia enciende la luz, (en este caso el tigre saltando) firmando el comienzo de la compra y es cargada a una tarjeta de crédito conectada a la cuenta del sistema SpeedPass, también se pueden comprar otros artículos como: botellas de agua, bolsas de botanas, etcétera.

ser de 30 metros bajo condiciones ideales, son mucho más pequeños que las activas y tienen más memoria de almacenamiento que las pasivas. En el manejo en la cadena de suministros de tiendas y librerías han usado artículos electrónicos de vigilancia de 1 bit desde RFID para controlar robos desde 1960. Etiquetas semiactivas indican si un artículo ha sido robado o propiamente sacado de la tienda, ya que un cajero usualmente desactivará la etiqueta antes de salir. El departamento de la Defensa de US y varios minoristas están conduciendo ya ensayos en la plataforma de RFID, de hecho una gran cadena americana de supermercados dentro de EUA y México, exigió a sus 600 proveedores que adopten este sistema desde enero del 2007.

En restaurantes de comida rápida trabaja exactamente igual, el cliente coloca su orden, entonces ondea su llave enfrente del controlador del lector, si todo funciona como debería, el dispositivo se iluminará y dará la comida. Se espera implementar este sistema SpeedPass en 400 restaurantes. Las etiquetas RFID de baja frecuencia se utilizan comúnmente para la identificación de animales, seguimiento de barricas de cerveza, y como llave de automóviles con sistema anti-robo. En ocasiones se insertan en pequeños chips en mascotas para que puedan ser devueltas a su dueño en caso de pérdida. En algunos modelos de coches desde el 2004, está disponible una “llave inteligente” como opción. La llave emplea un circuito de RFID activo que permite que el automóvil reconozca la presencia de la llave a un metro del sensor, el conductor puede abrir las puertas y arrancar el automóvil mientras la llave sigue estando en la cartera o en el bolsillo. Desde el 2004 se usa en el seguimiento de presos a los que se les colocan unos transmisores del tamaño de un reloj de muñeca que pueden detectar si los presos han estado intentando quitárselas y enviar una alarma a las computadoras de la prisión.

•Etiquetas activas. Las etiquetas activas RFID tienen cuatro componentes: un microchip, una antena, una tarjeta de fuente de poder y tarjetas electrónicas. La antena y el microchip tienen similar función a las pasivas, las etiquetas activas poseen su propia fuente de energía y son capaces de alcanzar mayores distancias (10 metros aproximadamente), al poseer una batería su vida útil es de hasta 10 años.

• Etiquetas semipasivas. Poseen baterías pero permanecen dormidas hasta que reciben una señal proveniente de un lector. El rango de lectura de una etiqueta semiactiva, o semipasiva, puede

Se utilizan en bibliotecas y seguimiento de libros, control de acceso en edificios, seguimiento de equipaje en aerolíneas, seguimiento de artículos de ropa y en pacientes de cen-

Luis Joyanes Aguilar Dr. Ingeniería Informática, Dr. Sociología, Lic. en Ciencias Físicas y Lic. de Enseñanza Superior Militar. Titular de la cátedra de Lenguajes y Sistemas Informáticos de la Universidad Pontificia de Salamanca, Madrid. Ex-Decano de la facultad de Informática y Dir. del Departamento de Postgrado en Ingeniería Informática. Ha publicado más de 60 libros sobre tecnologías de la Información, profesor del programa de doctorado en Sociología, Guatemala. Ha impartido cursos de doctorado en las Universidades Complutense, Politécnica de Madrid y Oviedo. casadellibro.com/libros/joyanes-aguilar-luis/joyanes2aguilar32luis

54

NOV-ENE 2009

www.sg.com.mx


tros hospitalarios para hacer un seguimiento de su historia clínica. Las etiquetas RFID de microondas se utilizan en el control de acceso en vehículos de gama alta, algunas autopistas, como por ejemplo la FasTrak de California, el sistema I-Pass de Illinois, el telepeaje TAG en las autopistas urbanas en Santiago de Chile y la Philippines South Luzon Expressway E-Pass para recaudación con peaje electrónico. Las tarjetas son leídas mientras los vehículos pasan, la información se utiliza para cobrar el peaje en una cuenta periódica o descontarla de una cuenta prepago. El sistema ayuda a disminuir el tráfico causado por las cabinas de peaje6.

Aplicaciones Identificación de Pacientes

www.sg.com.mx

En 2006, la FDA (Food and Drug Administration) aprobó los primeros chips RFID de EE.UU. que se pueden implantar en seres humanos. El uso de RFID para prevenir mezclas entre esperma y óvulos; en las clínicas de fecundación in vitro también se está considerado. Pueden incorporar información médica personal, podrían salvar vidas y limitar lesiones causadas por errores en tratamientos médicos. También se ha propuesto su aplicación en el hogar para permitir por ejemplo, que un frigorífico pueda conocer las fechas de caducidad de los alimentos que contiene, pero ha habido pocos avances más allá de simples prototipos.

Pasaporte

El nuevo documento de pasaporte a partir de agosto 2007 se emitió con este chip, algunos países como Canadá, Australia, EE.UU, Pakistan y en países de la Unión Europea ya lo tienen implantado. Tiene una mini antena que permite comunicarse con los datos, por medio de un lector RFID entre un radio de acción de 2 a 100 m.

Licencia de Conducir

El estado de Virginia ha pensado en poner etiquetas RFID en las licencias de conducir, para hacerlos mas confiables y evitar que se puedan conseguir documentos de identidad falsos.

Tráfico y Posicionamiento

En Londres, el control de acceso con vehículos particulares en el centro está desde hace un tiempo limitado mediante un peaje, cuando lo instalaron decidieron apostar por un sistema de más de 800 cámaras que controlaran el acceso y pago del peaje mediante dispositivos RFID en los autos1.

Desde 2004 Lisboa también hace uso de este sistema de control de acceso al centro de la ciudad. Estocolmo ha decidido usar la tecnología RFID para reducir gastos en el control del acceso. El sistema de peaje ha logrado reducir el tráfico en un 25% y ha incrementado el uso del transporte público en 40.000 usuarios más cada día6. Un dispositivo colocado en los vehículos permite identificarlos y aplicarles vía Internet un cargo de peaje con precios variables según la hora, el sistema también identifica las matrículas de los vehículos que no tienen ese dispositivo, obligándoles a realizar el pago oportuno en bancos o establecimientos autorizados.

Noticias importantes sobre futuras aplicaciones • Compras con RFID. Algunos clientes están considerando tener implantes de microchips para poder hacer compras7.

NOV-ENE 2009

55


// TECNOLOGÍA

/*INFRAESTRUCTURA*/

El sujeto es identificado desde que entra (nombre, domicilio, tarjeta de crédito, última visita a la tienda, tendencias de compra y gustos sobre ropa). La ropa lleva incorporada etiquetas RFID invisibles. Antes de pagar, se le somete a una prueba de reconocimiento facial para comprobar si efectivamente es quien su tarjeta de identidad dice que es. El sistema utiliza Internet y puede avisar a la policía si la persona sale de la tienda sin abonar la mercancía, así como proporcionarles información sobre dónde obtener fotografías on-line del sospechoso4.

se intentase quitarlo sin control médico podría producir daños severos y hasta la muerte13.

• Planean “etiquetar” a los pasajeros aéreos. BBC News anuncia nuevos y espeluznantes avances en la dudosa ciencia del pre-crimen. El proyecto Optag desarrollado en el University College London, ha llegado a la brillante conclusión científica, de que etiquetar a los pasajeros de los aviones ayudaría a combatir el terrorismo7.

• Detectan fugas de información en las nuevas tarjetas de crédito con RFID. Herald Tribune publica un artículo que revela que información sensible de las tarjetas de crédito de última generación que incorporan chips RFID, puede ser leída por un intruso mediante un equipo electrónico cuyo costo aproximado son 150 dólares, pero que podría reducirse en tamaño hasta algo similar a un paquete de chicles y precio de construcción seri de 60 dólares. Las pruebas se han realizado sobre 20 tarjetas de Visa, MasterCard y American Express. Algunos fabricantes habían hecho creer a los usuarios que los datos irían cifrados.

• La tarjeta inteligente, Visa con RFID. La Caixa introducirá en España las tarjetas de crédito equipadas con chip RFID, legibles a distancia sin necesidad de contacto físico con el aparato lector. La Caixa será la primera entidad financiera española en incorporar tecnología RFID a sus tarjetas de crédito12. • Parece Polvo. El novedoso chip RFID de Hitachi que mostraron al mundo el pasado 13 de febrero 2007. Estos tienen un tamaño de 0.05 x 0.05 mm y son hasta 64 veces más pequeños que sus actuales mu-chips de 0.4 x 0.4 mm, aparecerán en el mercado dentro de dos ó tres años más.

Pero no todo es perfecto con RFID • Logran clonar el VeriChip. Un investigador Canadiense anunció en el 2007 que logró clonar el implante subcutáneo RFID de VeriChip Corporation, pese a lo cual la empresa sigue afirmando en su Web que el chip provee de un identificador único y que el sistema es absolutamente seguro 8. • El VeriChip podría causar la muerte. El bio-chip está compuesto de un transponder, un sistema de almacenamiento, lectura de información a control remoto y una batería de litio recargable, la que se recarga por un sistema termopar (dispositivo capaz de convertir la energía calorífica en energía eléctrica) que produce fluctuaciones de la temperatura del cuerpo, razón por la que se determinó después de varias investigaciones millonarias, que el mejor lugar para implantarla es en la cabeza o la mano derecha. Aunque la empresa sigue asegurando que el bio-chip es seguro, la verdad es que el litio que contiene al ser derramado en el interior del cuerpo, produce úlceras y daños en los tejidos, que si

56

NOV-ENE 2009

• Problemas de lectura con los pasaportes RFID. No sólo son menos seguros; ahora también sabemos que la lectura de los pasaportes con el chip son menos fiables (prácticamente la mitad) que la de los tradicionales, requiriendo más tiempo y atención por parte de los empleados. Eso es lo que afirma un estudio del propio Departamento de Estado de los EUA 8.

• Peligros en datos biométricos. Fallos en RFID hacen peligrar los datos biométricos de los millones de personas que visitan Estados Unidos, para rastrear a los visitantes extranjeros tras su entrada por las dos fronteras terrestres de Estados Unidos, México y Canadá8. El controvertido RFID sigue “ganando enemigos” a lo largo y ancho de este mundo. Ahora son los usuarios del metro en Rheinberg, Alemania, que han descubierto que sus tarjetas llevaban escondido un chip RFID. Por el diminuto tamaño que está adoptando estos dispositivos, cada vez es más sencillo esconderlos en casi cualquier parte, desde billetes de banco, hasta boletos de metro. Aún con todos los problemas mostrados con la tecnología RFID, representa un gran avance su uso en la industria, ahorrará grandes tiempos en las líneas de producción, administración y distribución.

Las novedades de RFID en el 2008 1. Empresas en México con productos perecederos como las frutas y legumbres, implementarán RFID en su cadena de abasto, para monitorear el estado de cualquier fruta y determinar cual deberá ser puesta primero en el mercado y ahorrarse una gran cantidad de dinero al no tener que tirarla por estar en mal estado 9. 2. Se ha puesto en marcha el primer centro de distribución dirigida por voz en Colombia atreves de RFID. La distribución esta dirigida por voz y permite a los operadores recibir instrucciones paso a

www.sg.com.mx


paso directamente del sistema de control de almacén a través de un Talkman Vocollect que se porta en la cintura y una diadema con micrófono, dejando las manos y la vista libres para realizar las labores sin interrupciones ni tiempos muertos 2. 3. La Universidad de Arkansas está utilizando una tecnología de vanguardia para explorar las ventajas potenciales de RFID usando un detallado hospital virtual creado en Second Life, los expertos están examinando la manera en que los dispositivos basados en RFID pueden mejorar el sistema de salud en el mundo real 10. 4. Ahora no solo son utilizados los RFID en mascotas como perros y gatos, sino que además, se ha etiquetado algunos peces de las 20 especies más exóticas con el fin de mostrarles a los espectadores su ubicación en una pantalla, esto fue en un acuario en Singapur. 5. El 30% de las empresas españolas de logística y distribución ya han implantado RFID y el 83% se muestra satisfecho con ella. 6. Un 48% de las empresas (grandes y pymes) de diversos sectores en España, tienen pensado implantar RFID para control de procesos y logística. 7. Este año se ha anunciado como funciona los sistemas biométricos de huellas digitales y su uso en el nuevo DNI electrónico español 11. 8. Se ha anunciado la disponibilidad en España del nuevo lector de RFID modelo IP30, un dispositivo pequeño y compacto que puede integrarse en los dispositivos moviles más extendidos. De esta forma es posible combinar la RFID con otras tecnologías como la localización por GPS y las redes extendidas inalámbricas 2.

Conclusión La aplicación más importante de esta tecnología es con propósitos comerciales, ahora tiene la atención en el mundo de los negocios, esta tecnología tiene un amplio rango de industrias con una gran variedad de usos. La identificación de artículos mediante el código de barras, prácticamente estarán desapareciendo en un futuro inmediato, serán sustituidos por dispositivos con RFID, estándares y middleware sobre la tecnología RFID serán desarrolladas, también otras versiones sobre la seguridad y privacidad. Más de 250 corporaciones en 20 países están ya distribuyendo el

www.sg.com.mx

VeriChip y muchas naciones ya fueron privilegiadas para usarlo, entre ellas: Reino Unido, Canadá, E.U.A., Australia, Nueva Zelanda, Israel, Hong Kong, China, Indonesia, Macau, Malasia, Filipinas, Singapur, Tailandia, India, Taiwán, Sri Lanka, Costa Rica, Guatemala, Nicaragua, Panamá, Honduras, el Salvador y Brasil. El RFID Europa14, ha publicado que los países que más usan el dispositivo son: en primer lugar Asia con el 46% donde el país mayoritario es China además del tamaño de su población y de los proyectos de los juegos olímpicos que influyeron para subir los porcentajes de uso, le sigue Norteamérica con el 27% donde los países líderes son EUA y Reino Unido, Europa le sigue a la lista con el 17% donde lideran Alemania y Francia y el resto del mundo solo con 10% donde está incluido a Latinoamérica5.

Referencias [ 1. RFID, Identificación con seguridad. rfidding.com/1_definicion. html ] [ 2. RFID, España, rfid-spain.com ] [ 3. Tornton, Frank. et al. Computers Comunications NetWorking. 2006. ] [ 4. Ribeiro, Silvia. “Chips Espías, manipulación del consumo e impactos sobre la salud”. La Jornada. México, 10/12/2006. ] [ 5. Pink tentacle. pinktentacle.com/2007/02/hitachi-develops-rfid powder/ ] [ 6. “RFID para ayudar a reducir el tráfico”. Gobierno de Estocolmo. xataka.com/2006/04/12-rfid-para-reducir-el-trafico ] [ 7. “RFID, Nineteen, eighty four,Etiquetar a los pasajeros en los aeropuertos”. Video: spychips.com/RFIDairport.html ] [ 8. “RFID, Nineteen, eighty four”. Protestas e invasión a la privacidad. spychips.com/index.html, spychips.com/press-releases/verichip-hacked.html, kriptopolis.org/problemas-de-lectura-con-los-pasaportes-rfid ] [ 9. RFID, México. mexicorfid.com ] [ 10. Arkansas University. Video de proyecto U. Arkansas. es.youtube. com/watch?v=pNPG02uILXY ] [ 11. DNI electrónico España. dnielectronico.es/oficina_prensa/ noticia_destacada/mapa_provin_desp_dnie.html ] [ 12. Visa Europe. visaeurope.es/saladeprensa/notasdeprensa/ press42.jsp ] [ 13. “VeriChip, VeryVIP, VeryDangerous”. trinityatierra.wordpress. com/2008/03/10/verichip-verivip-very-dangerous/ [ 14. RFID Europe. rfid.idtechex.com/rfideurope08/en/rfidin2008.asp ]

NOV-ENE 2009

57


// tecnología

/*multicore*/

Perdiendo el Miedo a la Programación Paralela Ejemplo de Ordenamiento de Burbuja Paralelo Por Shannon Cepeda

Al igual que la mayoría de los ingenieros de sistemas, tengo malos recuerdos de lidiar con threads en mi clase de sistemas operativos en la universidad. Así que cuando me encontré en la necesidad, ya como profesional, de aprender a hacer programas que se ejecuten en distintos threads paralelos, debo aceptar que tuve mucho miedo. Sin embargo, descubrí que actualmente hay herramientas que hacen esto mucho más sencillo de lo que pensaba. Para reiniciarme en la programación paralela, decidí comenzar haciendo el ejercicio de implementar un ordenamiento de burbuja (bubble sort) paralelo. Éste es uno de los algoritmos de ordenamiento más sencillos y lentos. La forma en que funciona es que se recorre una lista de elementos, y se va comparando el elemento i con el i+1, y en caso de que el orden esté equivocado, se intercambia estos valores de posición. Este recorrido se repite n-1 veces (donde n es el número de elementos que contiene la lista) para asegurar que se hayan realizado los cambios necesarios y la lista está ordenada. Decidí ordenar palabras, ya que esto me daba una forma sencilla de repartir mis datos entre distintos threads (un thread podría ordenar las palabras que comienzan con “A”, otro las que empiezan con “B”, etc.). Al iniciar, el programa debe leer un archivo con palabras, contar cuantas palabras comienzan con cada letra (sin diferenciar entre mayúsculas y minúsculas), y guardar esta cuenta en un arreglo unidimensional de 26 elementos llamado letter_counts. Esto significa que el valor de letter_counts[0] es la cantidad de palabras que empiezan con la letra ‘a’, letter_counts[1] es la cantidad de palabras que empiezan con ‘b’, y así sucesivamente. El siguiente paso es volver a leer las palabras del archivo, y almacenarlas en un arreglo de arreglos (my_array), de acuerdo a la letra con la que empiezan. Es decir, my_array[0] apunta a un arreglo que contiene las palabras que comienzan con la letra ‘a’, my_array[1] contie-

58

NOV-ENE 2009

ne un arreglo con las palabras que comienzan con la letra ‘b’, y así sucesivamente. Una vez que se genera este arreglo “semiordenado” –ya que las palabras se encuentran agrupadas de acuerdo a la letra con la que empiezan –, se puede invocar a la función que se encarga del ordenamiento.

Ordenamiento sin paralelismo Primero realicé la prueba haciendo el ordenamiento de la forma tradicional, es decir sin paralelismo. El listado 1 muestra el código en lenguaje C para hacer esto. void bubble_sort (char *** &my_array, int letter_counts[26]){ char * temp; for (int letter =0; letter < 26; letter++) { for (int i =0; i < letter_counts[letter] - 1 ; i++){ for (int j =0; j < letter_counts[letter] - 1 - i; j++){ if (strcmp(static_cast<char *>(my_array[letter] [j+1]), static_cast<char *>(my_array[letter][j])) < 0){ temp = my_array[letter][j+1]; my_array[letter][j+1] = my_array[letter][j]; my_array[letter][j] = temp; } } } } } Listado 1. Ordenamiento sin paralelismo

El programa se ejecutó en una máquina con dos procesadores de cuatro núcleos, y al monitorear la ejecución me di cuenta que solo se usaba un núcleo. El tiempo de ejecución del programa fue de 7.4 segundos.

Implementando paralelismo con OpenMP Actualmente existen diversas librerías que abstraen y simplifican el manejo de threads. Una de ellas es OpenMP, la cual usé para este ejemplo. OpenMP es un API para programación paralela en C/C++ y Fortran. Es soportado por una gran variedad de compiladores incluyendo el compilador de Intel, gcc, y Visual Studio (2005 o mayor). Con OpenMP, es posible convertir un programa de un modelo single threaded a un modelo multithreaded sin necesidad de escribir un

solo fork, join, o siquiera crear un thread de forma explícita. Se implementa en el código por medio de directivas “pragma”. Como programador, lo único que necesitas hacer es determinar qué patrón de paralelismo requiere tu código, y entonces indicar la directiva pragma correspondiente. Uno de los elementos más sencillos y utilizados de OpenMP es el pragma “parallel for”. Este corresponde a lo que sería un “for” en programación single threaded. Lo que hace es dividir un ciclo de tareas en rangos, y asigna un segmento de tareas a cada procesador. OpenMP se encarga de crear los threads y asignarlos a cada procesador. En el caso de mi ejemplo, el pragma “parallel for” es justo lo que necesitaba, ya que mi algoritmo estaba estructurado en base a un ciclo maestro donde se trabaja de forma separada los distintos grupos de palabras en base a la letra con la que empiezan. Usando el parallel for a este nivel, no corría el riesgo de que dos threads accedieran el arreglo de la misma letra al mismo tiempo .El listado 2 muestra el código correspondiente, agregando el parallel for. void parallel_bubble_sort (char *** &my_array, int letter_counts[26]){ char * temp; #pragma omp parallel for for (int letter =0; letter < 26; letter++) { for (int i =0; i < letter_counts[letter] - 1 ; i++){ for (int j =0; j < letter_counts[letter] - 1 - i; j++){ if (strcmp(static_cast<char *>(my_array[letter] [j+1]), static_cast<char *>(my_array[letter][j])) < 0){ temp = my_array[letter][j+1]; my_array[letter][j+1] = my_array[letter][j]; my_array[letter][j] = temp; } } } } } Listado 2. Ordenamiento usando el parallel for

Eso fue bastante sencillo … ¿podría ser tan bello? Al ejecutar este código y monitorear el sistema me di cuenta que ya había actividad en los distintos núcleos de procesamiento. El tiempo de ejecución fue de 6.4

www.sg.com.mx


segundos, lo cual significó una pequeña reducción. Sin embargo, al verificar los resultados encontré que había errores ya que el arreglo no había sido ordenado correctamente. Muy probablemente esto se debía a que generé un error de data race. Un data race es cuando distintos threads acceden y modifican una misma variable de forma no coordinada; típicamente esto genera resultados erróneos en el valor de las variables.

Depurando con Intel Thread Checker Para encontrar el error, decidí utilizar el Intel Thread Checker. Este es un depurador para programas multithreaded. Lo que hace es monitorear la ejecución de un programa para encontrar errores como data races, deadlocks, fallas de sincronización, y tiempos de espera. La figura 1 muestra los resultados del Intel Thread Checker.

Esta opción me pareció mucho mejor, ya que esta variable no necesitaba ser compartida, y por medio de este mecanismo se evitó que cada thread tuviera que esperar a que los demás terminen.

Los primeros dos errores indicaban que mis sospechas eran correctas. Al revisar las líneas referidas, noté que la línea 96 era la sentencia:

Afortunadamente, en OpenMP es muy sencillo marcar variables como locales para cada thread. Simplemente se utiliza el comando private. El listado 3 muestra el código resultante.

Figura 1. Resultados del Intel Thread Checker

¡Perfecto! Afortunadamente, mi primera experiencia como profesional en la programación paralela no fue tan mala como mis memorias de manejo de threads en la universidad. Por supuesto, fue un ejemplo bastante sencillo. Sin embargo, refleja que utilizando un proceso adecuado y aprovechando las herramientas disponibles (las que mencioné en este artículo son gratuitas), hacer programas paralelos es mucho más fácil de lo que pensábamos.

temp = my_array[letter][j+1];

y la línea 98 era: my_array[letter][j] = temp;

Así que lo que estaba sucediendo es que distintos threads estaban recurriendo al mismo tiempo a la misma variable temp para reordenar los valores de los arreglos; también encontré warnings, indicando que había threads que esperaban más de 3 segundos para obtener acceso a un recurso, esto es bastante tiempo para un programa cuya ejecución total dura 6 segundos. Probablemente esto se debía a la pelea entre los 8 threads para acceder la misma variable temp. Ya que había encontrado el problema, tendría que pensar en la solución adecuada. Una opción era encerrar las líneas 96 a 98 en una sección crítica, o sincronizada, de forma que al mismo tiempo solamente un thread pudiera estar en esta sección, y hasta que terminara todas las operaciones de la sección liberaría el control para otro thread. Otra opción era hacer que la variable temp fuera local para cada thread.

void parallel_bubble_sort (char *** &my_array, int letter_counts[26]){ char * temp; #pragma omp parallel for private(temp) for (int letter =0; letter < 26; letter++) { for (int i =0; i < letter_counts[letter] - 1 ; i++){ for (int j =0; j < letter_counts[letter] - 1 - i; j++){ if (strcmp(static_cast<char *>(my_array[letter] [j+1]), static_cast<char *>(my_array[letter][j])) < 0){ temp = my_array[letter][j+1]; my_array[letter][j+1] = my_array[letter][j]; my_array[letter][j] = temp; } } } } } Listado 3. Código corregido

En esta ocasión, cuando ejecuté el programa el resultado fue correcto, y el tiempo de ejecución disminuyó significativamente. En lugar de los 7.40 segundos originales, ahora el ordenamiento se ejecutó en 1.60 segundos. Un vistazo al Intel Thread Checker indicó que ya no había errores ni avisos.

El método adecuado para desarrollar programas paralelos involucra cuatro pasos: • Análisis. Determinar los mejores lugares para usar threads • Implementación. Introducir en el código los elementos para ejecución paralela. • Depuración. Asegurar que todo esté funcionando correctamente. • Optimización. Realizar ajustes para maximizar desempeño. Este artículo abordó la implementación (a través de OpenMP) y depuración (con Intel Thread Checker). Para este pequeño programa el análisis fue automático. Sin embargo, para problemas reales, con mayor complejidad, es crítico comenzar con un buen análisis.

Referencias [ openmp.org/wp/ ] [ intel.com/software/products ] [ softwarecommunity.intel.com/isn/home/ ] [ devx.com/go-parallel ]

Shannon Cepeda ha laborado en Intel durante 7 años en roles relacionados con el análisis y optimización de desempeño de sistemas. Shannon es Ingeniero en Ciencias Computacionales, y Maestra en Ciencias de la Computación por la Universidad de Carolina del Norte.

www.sg.com.mx

NOV-ENE 2009

59


// tecnología

/*gadgets*/

Tivoli

NetWorks Radio Hay equipos de audio que se ven bien, otros que resultan funcionales, y los que proveen audio en alta definición. Pero hay pocos que logran combinarlo todo y además le agregan ese “pequeño extra” que los hace especiales. Tal es el caso de NetWorks Radio, fabricado por Tivoli, que luego de preguntarse: ¿qué haría un radio ideal? Materializaron esta monada que además de su diseño sencillo y moderno, permite el acceso a las ventajas del broadcasting por Internet de tal manera que con él se sintonizan estaciones de radio de cualquier parte del mundo sin interferencias, ofreciendo sonido cristalino y en el idioma original; o escuchar la música que se tiene almacenada en la PC desde cualquier habitación de la casa, a través de conexión Ethernet o de manera inalámbrica. Incluso cuando NetWorks es sólo un gabinete, se puede expandir conectándole un par extra de altoparlantes estéreo, un subwoofer o un reproductor de CD. Cuenta con control de balance, panel de iluminación LCD, reloj digital con fechador, volumen de alarma independiente, entradas auxiliares, control remoto, cable de corriente desmontable y capacidad de almacenamiento de hasta 200 estaciones para guardar favoritos; entre muchas otras características que lo hacen un equipo high-tech con estilo.

Firebox

Brick USB Para recordar aquellas épocas en las que todo era tan sencillo como unir bloques de colores para construir una casa o una nave espacial; ¿por qué no traer de regreso esas lindas memorias de la infancia a nuestro acelerado ritmo de vida en el que todo es llevar, traer y compartir información a través de pequeños dispositivos con gran capacidad? Y en respuesta a tan larga pregunta... unos legos USB (que no son oficialmente legos) disponibles en rojo, azul o amarillo con opción para guardar 2GB ó 4GB de documentos importantes, música, imágenes o cualquier otro tipo de archivo digital. Lo mejor de ellos es que se pueden unir unos con otros, de tal forma que a primera vista, pareciera que sólo se trata de un grupo de bloques de colores.

60

NOV-ENE 2009

www.sg.com.mx


Palm

Palm Treo Pro Bajo el lema “Acelerar en lugar de complicar” Palm lanza su teléfono inteligente Palm Treo Pro, dirigido al segmento corporativo. Este modelo está dirigido a los usuarios empresariales que requieren un dispositivo sencillo de usar, que ejecute de forma transparente aplicaciones basadas en plataforma Microsoft. Esto se logra gracias a que el Treo Pro funciona sobre la plataforma Windows Mobile 6.1 Professional, así que utiliza Outlook como cliente de correo, y permite abrir y editar nativamente archivos Word, Excel y Power Point. Adicionalmente, soporta acceso seguro a servidores de documentos SharePoint. Así que si buscas un dispositivo móvil que te permita manejar los mismos documentos que manejas en la oficina de forma rápido y sencilla, el Treo Pro puede ser una gran opción.

Casio

Exilim EX-Z300 Como parte de las nuevas tendencias en cámaras digitales para la temporada otoño - invierno 2008, Casio lanzó seis modelos de la serie Exilim, y elegimos la EX-Z300 por llevar consigo la etiqueta de “el mejor desempeño” y por estar dirigida hacia aficionados exigentes, que también disfrutan subiendo videos a YouTube. Con 10.1MP y zoom óptico de 4x, modo Make up para corrección de imagen, pantalla de 3” TFT LCD súper brillante, grabación de video en HD, objetivo de gran angular de 28 milímetros, modo de disparo especial para escenas nocturnas, detección de rostros y 300 imágenes con una sola carga de batería, resulta una pequeña gran opción, portátil, digital y, a buen precio.

HP

Mini-Note PC Como la nueva era de computadoras portátiles es una realidad, HP presenta su minicomputadora HP 2133, diseñada para el mercado empresarial, pero perfecta para usarse en la oficina, en la casa, en viajes de negocios o simplemente para llevarla a cualquier parte. Dentro de sus características principales destacan su peso de 1.10 kilogramos, cubierta de aluminio cepillado resistente, HP DuraKeys, que es una capa transparente aplicada sobre el teclado para proteger el acabado, las letras y caracteres impresos. Pantalla resistente a ralladuras de 8.9” y armazón reforzado con bisagras de magnesio. Tecnología inalámbrica Wi-Fi WLAN integrada y Bluetooth opcional. Memoria de 512MG y 1GB; disco duro desde 120GB; batería de 3 ó 6 celdas con rendimiento de hasta 55 horas. Opera con Windows Vista, XP o Linux.

www.sg.com.mx

NOV-ENE 2009

61


// fundamentos

¿Por qué Cuesta Tanto Darle una Oportunidad a la Usabilidad? Mejorando la experiencia del usuario Por Romeo Márquez

Cada vez más compañías descubren el alto valor de tener sitios web o Software desarrollados con principios de usabilidad. Aún así, el 80% de las empresas desarrolladoras de Software ignoran por completo el tema.

Usabilidad: casos de la vida real Es muy común que no se tome en cuenta o que se deje para el último aplicar usabilidad durante el proceso de desarrollo de un sitio web o una aplicación. La siguiente es una conversación que he tenido en más de una ocasión con diferentes compañías de desarrollo de software: Cliente: Necesitamos que hagan bonita nuestra aplicación. Romeo: Muy bien, ¿cuando empiezan el análisis de requerimientos con el usuario? Cliente: Eso ya lo hicimos Romeo: ¿ Ah si? Cliente: Así es, el desarrollo lo terminaremos en una semana más, por eso estamos viendo quien va a hacer la interfaz de usuario. Romeo: Plop! Claro que es posible mejorar en términos de usabilidad un sitio o un software ya diseñados, más vale tarde que nunca, pero ¿por qué dejarlo para el último o en las manos equivocadas? A veces queda la responsabilidad en los programadores de determinar el lugar de cada cosa en la interfaz, sin embargo la experiencia indica que eso es un grave error. A continuación veremos por qué tomar en cuenta a la usabilidad desde el inicio del proyecto, ayuda a obtener mejores resultados en el producto final, evitar reescribir

código y lo más importante: mejorar la experiencia del usuario.

Diseño y usabilidad • Arquitectura de información. En un sitio web, una buena arquitectura es fundamental pues determinará si los usuarios podrán o no llegar a la información preparada para ellos. Suena sencillo, ¿no?; A pesar de eso, la gran mayoría de los sitios web NO cuentan con una verdadera arquitectura de información. Esto se traduce en menús mal organizados con opciones interminables, secciones del sitio con nombres extravagantes, visitantes desubicados y lo más grave: usuarios frustrados. Las estadísticas lo confirman: • El 83% de los visitantes abandonan un sitio si tienen que hacer demasiados clicks para encontrar lo que buscan. • El 62% deja de buscar un artículo mientras visitan una tienda en línea. • 40% de los usuarios no regresan al sitio debido a una mala experiencia relacionada con la falta de usabilidad. Es importante definir bien la arquitectura de información en una aplicación, pues determinará si el usuario la considera fácil de utilizar y presenta menos resistencia al cambio.

• Diseño centrado siempre en el usuario. Para lograr un buen diseño de sitio o aplicación, será importante saber quién es el usuario promedio: cuales son sus hábitos de navegación, cómo usa la tecnología o que tipo de información busca. Si se incorpora esa información al diseño, el resultado será de mayor utilidad para el usuario final. Es indispensable diseñar el sitio tomando en cuenta el tiempo de descarga. Los usuarios son cada vez menos pacientes y el tiempo promedio de espera para un sitio Web es de 2 a 10 segundos. Esto no significa restringirse de usar multimedia en el proyecto, sin embargo será importante que el usuario mismo sea quien decida cuando y bajo que circunstancias desea verla en vez de forzarlo. Si tu proyecto tiene más de un tipo de usuario, será mejor diseñar secciones específicas para mostrar el contenido preparado para cada tipo de usuario. La Usabilidad en un sitio Web o aplicación debe:

Esto puede determinar si un software tendrá aceptación en el mercado o dentro de la compañía.

• Facilitar el acceso a la información. • Reducir la posibilidad de cometer errores. • Incrementar la productividad del usuario. • Reducir el tiempo dedicado a la capacitación. • Reducir el costo de dar soporte al usuario.

A menos que quieras ser como el dueño de una compañía de software que dijo: No queremos que nuestra documentación para el usuario final sea muy clara. Hacemos mucho dinero capacitando a nuestros clientes.

• Pruebas de usabilidad. Nada peor que hacer todo el esfuerzo de lanzar un sitio Web o software para descubrir que el usuario no encuentra lo que necesita, ni puede realizar sus actividades con facilidad.

Romeo Márquez Guzmán es fundador de gelattina, una compañía especializada en web 2.0, diseño de interfaces, E-Marketing, widgets y video para web y podcasting). Adicionalmente es miembro de la Usability Professionals’ Association. Para Gelattina, ha dirigido proyectos de diseños de interfaces para The Home Depot, Coca-cola, Banorte, Hoteles Marriott, Aba Seguros entre otros. www.gelattina.com romeo@gelattina.com

62

NOV-ENE 2009

www.sg.com.mx


El mejor método para detectar esas fallas es realizar pruebas de usabilidad. Aunque hay métodos sumamente sofisticados para hacer pruebas de usabilidad, inclusive pueden realizarseen papel. En cualquiera de los casos, es mejor realizar las pruebas durante las etapas más tempranas del diseño y repetirlo varias veces a lo largo del proyecto, para asegurar una interfaz con un alto nivel de usabilidad.

Algunas citas interesantes • “¿Cual es el costo de hacer feliz al usuario?; Es bajo si se hace al inicio del ciclo de desarrollo web.

Si cuesta $1 hacer el cambio en papel, entonces cuesta $10 hacerlo en el código y $100 cuando el sitio está en línea” - Theresa Cunnington, ComputerWorld

Conclusión Siempre será mejor aplicar conceptos de usabilidad desde el inicio del proceso de diseño y desarrollo de un proyecto. Para lo cual es importante incluir a los usuarios y realizar pruebas de usabilidad durante el proceso de diseño.

• “La acción mas común de un usuario en un sitio Web es huir!” - Edward Tufte, Information Design Guru • “La Usabilidad es crítica para cualquier aplicación, sin embargo, para el software orientado a mercados masivos, la usabilidad significa el éxito o fracaso más que cualquier otra característica.” - Dr. Jerrold Grochow, CTO, American Management Systems

Referencias [ “Google en 28 palabras”. tinyurl.com/5ak6fa ] [ “El laboratorio de usabilidad de Google”. tinyurl.com/6no9mo ] [ “La usabilidad incrementa las utilidades: 2 casos de éxito”. tinyurl.com/55wrol ]

INDEX

DIRECTORIO

Anunciante Adecco Avantare AMITI Brio Compusoluciones Compushow IT Institute Microsoft Milestone Consulting NYCE SafeNet SG Campus SIE Center

Páginas 2F, 1 41 49 39 45 51 9 F0 4F 3F 11 13 17

Sitio www.adecco.com.mx www.avantare.com www.amiti.org.mx www.brio.com.mx www.compusoluciones.com www.compushow.com.mx www.it-institute.org www.microsoft.com.mx www.milestone.com.mx www.nyce.org.mx www.safenet-inc.com www.sgcampus.com.mx esicenter.itesm.mx

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 2009

63


// carrera

¿Cómo Enseñar a los Programadores del Futuro? ¿Estructurada, POO o Scripts? Por Gunnar Wolf

Nuestro gremio se caracteriza por conformarse por dos principales perfiles: Autodidactas y escolarizados. Esto obedece a que el campo es aún novedoso, y es aún posible para un aficionado ir obteniendo de manera gradual e independiente los conocimientos para llegar a un nivel de competencia comparable con quien estudió una carrera formalmente. El programador autodidacta tí­picamente es un miembro muy valioso del equipo de desarrollo, dado que llegó a acumular sus conocimientos -teóricos y prácticos por motivación propia. Si bien es común que su formación muestre importantes “agujeros” cognitivos en aquellos campos que requieren mayor rigor teórico/matemático, o en aquellos por donde el interés no lo llevó, comúnmente los subsanará tan pronto se enfrente a situaciones que los requieran. Sin embargo, es justamente en las áreas más teóricas y áridas del cómputo donde hay una mayor proporción de profesionales con éste perfil. No puede ser casualidad que dentro de los desarrolladores de Software Libre haya tan alta proporción de autodidactas, gente formada en otras disciplinas, que ha ido encontrando su nicho de interés y trabajo en el cómputo, encontrando que en la creación de herramientas cubran sus necesidades particulares de una nueva vocación. Podríamos dedicar un amplio espacio a analizar la relación entre el conocimiento adquirido formal e informalmente, y en cómo insertar a estos en un esquema académicamente más formal... Pero el tema del que quiero ocuparme en esta ocasión es de quien viene de una enseñanza escolarizada. ¿Cómo transmitir el conocimiento, el interés y el entusiasmo, a los programadores escolarizados, para que alcancen un nivel de habilidad similar al de los autodidactas? Para esto, es fundamental que nos pregun-

temos, ¿qué y cómo enseñan a los alumnos las universidades en nuestro País, las carreras relacionadas con el cómputo? ¿Qué perfiles reales de egreso hay de cada una de estas carreras (desde la Licenciatura en Informática Administrativa, pasando por las Ingenierías, con perfiles orientados más hacia Sistemas, Electrónica u otras variantes, y hasta las Ciencias de la Computación)?  ¿Y cómo explicamos que, a la hora de buscar un trabajo, tan frecuentemente todos son puestos dentro de la misma bolsa? El primer obstáculo al que creo todos los programas académicos deben reaccionar es que, muchos alumnos sienten que programar es una tarea tediosa, un rol que se verán forzados a desempeñar durante los primeros años de su trabajo, en lo que logran un ascenso a un puesto de “responsabilidad”. Esto es, en buena medida, por lo torpe que resulta la enseñanza de los conceptos y habilidades básicos de la programación. Hay dos escuelas básicas: Comenzar enseñando programación utilizando un lenguaje mí­nimo aunque completo, apto para transmitir los fundamentos de la estructura y el control de flujo (al estilo de C o del venerable Pascal). En contraposición a ellos, muchos otros académicos defienden comenzar enseñando con un paradigma completamente POO, con lenguajes como Java o como C#. Y ambas alternativas nos dejan importantes huecos por llenar. Para alguien que inició con lenguajes de muy alto nivel, resulta más difícil comprender la traducción a código de más bajo nivel y la implementación en hardware del mismo, especialmente lo relativo a administración de memoria y el órden de complejidad; en este sentido, una de las más brillantes exposiciones la hace Ulrich Drepper, en su texto “What Every Programmer Should Know About Memory” 1. Para todas las aplicaciones que corren

“cerca del metal”, como desarrollos de sistemas tiempo real, embebidos, controladores de hardware o software orientado al alto rendimiento, es fundamental dominar estos temas. Por otro lado, para los programadores que parten de un entorno meramente procedimental, la POO se presenta como una complejidad adicional, un obstáculo para la manera que tienen y conocen de solucionar los problemas. Si bien la discusión académica respecto a estas dos escuelas está tan viva como cuando se planteó por primera vez hace más de 20 años (p.ej. 2 y sus respuestas en3), creo yo que el problema de la motivación reside en no enfocarnos en lenguajes y marcos “simples” (sin ser de juguete), que no permiten al alumno experimentar la “gratificación instantánea” de lograr resultados atractivos tras apenas un primer acercamiento. Los lenguajes denominados “de scripts” (Python, Ruby, Perl, y un largo etcétera) deben ser enseñados de otra manera, mucho más gradual, pero sin duda ayudan a mantener alta la motivación y baja la frustración. Pero... ¿No son lenguajes con relativamente baja penetración corporativa? Así­ es, y eso representa otra ventaja - Una de las principales cualidades de un programador debe ser la capacidad de aprender tecnologías nuevas. Al enseñar con herramientas distintas, ayudamos a que los estudiantes desarrollen la importante habilidad de “aprender a aprender”, no encasillarse en una herramienta. ¡Que se hagan el hábito de aprender nuevos lenguajes para diferentes retos!

Referencias [ 1. Drepper, Ulrich. “What Every Program mer Should Know About Memory”people. redhat.com/drepper/cpumemory.pdf ] [ 2. “Just say ‘A Class Defines a Data Type’”, mags.acm.org/communications/200803 ] [ 3. “Forum” , mags.acm.org/communications/200805 ]

Gunnar Wolf ha sido usuario y promotor de Software Libre en México por más de diez años. Es fundador del Congreso Nacional de Software Libre (CONSOL) y miembro externo del Departamento de Seguridad de Cómputo en la UNAM. Participa como desarrollador en el proyecto Debian desde el 2003. Trabaja como administrador de red y en el desarrollo de sistemas para el Instituto de Investigaciones Económicas de la UNAM.

64

NOV-ENE 2009

www.sg.com.mx




Turn static files into dynamic content formats.

Create a flipbook
Issuu converts static files into: digital portfolios, online yearbooks, online catalogs, digital photo albums and more. Sign up and create your flipbook.