SG30 (Diciembre 2010 - Febrero 2011) by Revista Software Guru

Modelado de Requerimientos

Arquitectura y Scrum

Prueba de Software

P.34

P.38

P.46

No.

Reportaje SG Emprende

CONOCIMIENTO EN PRﾃ，TICA Diciembre 2010-Febrero 2011 www.sg.com.mx

ENTREVISTAS

Andrﾃｩs Barreto Santiago Siri David Weekly

Mﾃｩxico, $65.00

ENCUESTA DE SALARIOS 2010

CONOCIMIENTO EN PRÁCTICA

Pág.

30 .CONTENIDO Diciembre 2010-Febrero 2011 |

www.sg.com.mx

En Portada Encuesta de Salarios 2010

¿Cuál es el salario que actualmente recibe un profesionista de software? ¿Qué habilidades y conocimientos son los mejor pagados? ¿Qué prestaciones son las que más nos atraen? Conoce la respuesta a estas preguntas en la encuesta de salarios SG 2010.

Columnas Tejiendo Nuestra Red

por Hanna Oktaba

Mejora Contínua

por Luis Cuellar

Prueba de Software

por Luis Vinicio León

Programar es un Estilo de Vida

por Gunnar Wolf

Columna Invitada por Héctor M. Cuesta

.CONTENIDO

SG 30

Pág.

Productos

Lo que Viene

OpenKinect, MonoDroid y Chrome OS

En Cada Número 06

Noticias

Industria

Infraestructura

Directorio

Gadgets

Biblioteca

Repasamos los aspectos más relevantes del congreso para startups SG Emprende.

Emprendiendo

Contabilidad para startups

Prácticas Requerimientos

Entrevistas

Entrevistamos a los conferencistas de SG Emprende: Andrés Barreto, Santiago Siri y David Weekly.

César Guerra e Ismael Caballero comparten su propuesta para incorporar el modelado de calidad de datos para aplicaciones web.

Procesos El Papel de la Arquitectura en Scrum

Edwin Vásquez y Germán Alférez nos explican como incorporar la práctica de arquitectura de software en proyectos basados en Scrum.

Arquitectura Documentación de la Arquitectura

Edith Valencia y Humberto Cervantes continúan con esta serie, donde ahora abordan cómo documentar y comunicar la arquitectura.

Agilidad Análisis de Distintos Contextos de Prueba Juan Gabardini comparte sus experiencias y reflexiones sobre “la mejor manera” de probar software.

44 Pág.

Software Guru

Especiales

www.sg.com.mx |

SG Emprende 2010

Editorial

.EDITORIAL Bienvenida

. “Es un gran momento para enterarse de cómo están los salarios en nuestra profesión”

¿Dónde quedó el año?

icen que el tiempo se pasa rápido cuando uno se está divirtiendo, y sin duda ese ha sido el caso en este año. En un abrir y cerrar de ojos ya estamos en las convivios de fin de año y planeando los proyectos del siguiente. ¿Qué te dejó este año?, ¿cuales fueron tus logros?, ¿qué cambiarás para el siguiente? En el caso de SG, uno de los retos que nos planteamos para el 2010 fue el de impulsar a los startups de software. Fue así que abrimos una sección editorial y organizamos el congreso SG Emprende. Es un orgullo ver que estos esfuerzos están rindiendo frutos, y que nuestro naciente ecosistema de startups tecnológicos se fortalece día con día. El cambio de año es un gran momento para enterarse de cómo están los salarios en nuestra profesión, y cuales son las habilidades y conocimientos más solicitados y mejor pagados. Así que la encuesta de salarios te vendrá como anillo al dedo. Esperamos que esta información te sea de gran utilidad. Probablemente esta edición esté llegando a tus manos hasta principios del 2011, te pedimos una disculpa por este inconveniente. Como parte de nuestros proyectos para el 2011 está una reingeniería completa de nuestro proceso editorial donde involucraremos a más editores. Si te interesa participar como colaborador o editor externo, por favor escríbenos a editorial@sg.com.mx. Con placer te informamos que la imprenta donde se imprime SG fue certificada como imprenta verde (la primera en México). Tal vez pronto llegue el día en que SG ya no se necesite imprimir, pero mientras tanto buscaremos hacerlo de la forma que afecte menos a nuestro planeta.

››Equipo Editorial SOFTWARE GURU

DIRECTORIO SG Dirección Editorial Pedro Galván / Dirección de Operaciones Mara Ruvalcaba Coordinación de Contenidos Alejandro Escamilla / Arte y Diseño Oscar Sámano, Alexis Ramírez Consejo Editorial Jorge Valdés - PMI / Luis Cuéllar - Softtek / Luis D. Soto - Microsoft / Hanna Oktaba - UNAM / Emilio Osorio - Sistemas Humanos / Luis Vinicio León - e-Quallity / Gloria Quintanilla

Colaboradores Ignacio Gallegos, Steve Blank, Celeste North, César Guerra, Ismael Caballero, Edwin Vásquez, Harvey Alférez, Humberto Cervantes, Edith Valencia, Juan Gabardini, Masa Maeda, Berenice Ruíz, Gunnar Wolf, Héctor Cuesta, Tino Rodríguez.

Ventas Claudia Perea / Marketing y RP Montserrat Ramírez / Desarrollo Web Karen Rodríguez Contacto info@sg.com.mx SG Software Guru es una publicación trimestral editada por Brainworx, S.A. de C.V., Temístocles 34 piso 3, México DF 11560. Los contenidos de esta publicación son propiedad intelectual de los autores y están licenciados bajo Creative Commons Atribución-No comercial 2.5 México. Todos los artículos son responsabilidad de sus propios autores y no necesariamente reflejan el punto de vista de la editorial. Reserva de Derechos al Uso Exclusivo: En trámite. ISSN: 1870-0888. Registro Postal: PP15-5106. Distribuido por Sepomex. Se imprimió en diciembre de 2010 en 4Press.

.NOTICIAS

.El Futuro se Construye Hoy

El pasado 4 y 5 de noviembre se llevó a cabo en la ciudad de Villahermosa, Tabasco, el Congreso Internacional El Futuro se Construye Hoy 2010, organizado por el CITI Tabasco, organización que aglutina empresas asociadas, bienes y servicios informáticos, orientado a promover el desarrollo del sector de TI. El objetivo del congreso fué promover la cultura emprendedora mediante la construcción de alianzas de negocios entre los conferencistas y empresarios, así como su vinculación con estudiantes y los proyectos que se realizan en las empresas e instituciones educativas.

.Empresas evaluadas en CMMI Empresa BrainUp Innevo SinergIT SUSOC

Evaluación CMMI for Services L3 CMMI L4 CMMi L2 CMMI for Services L2

.BlackBerry Developer Day

El pasado 23 de noviembre se realizó en la Ciudad de México el seminario BlackBerry Developer Day, organizado por Research In Motion (RIM), fabricante de teléfonos inteligentes BlackBerry. El evento fue dirigido a desarrolladores de aplicaciones móviles para teléfonos inteligentes que desean perfeccionar sus proyectos para la plataforma BlackBerry, una de las de mayor crecimiento a escala mundial.

.CIAPEM 2010

Del 22 al 24 de septiembre de 2010 se llevó a cabo la XXXIV Reunión Nacional CIAPEM. Durante tres días se sumaron, ideas, iniciativas y esfuerzos para hacer más competitiva la administración pública mediante el uso de la innovación y las tecnologías de Información y comunicaciones. El evento tuvo una asistencia de 652 participantes, representantes del sector público, relacionados con Tecnologías de Información.

.Tendencias 2010, Sector Finanzas

Select presentó el evento Tendencias 2010 bajo el lema “Liderazgo para una gestión dinámica con TIC en finanzas y otros prestadores de servicios”. Ricardo Zermeño González, director de la consultora, dirigió la plática magistral, en la que se destacó la relevancia e importancia del sector servicios. El evento contó con la participación de los principales representantes del sector financiero, y mostró una interesante agenda relacionada con la gestión de las TICs.

Para mayor Información, Noticias al Día y Updates de la industria visita: www.sg.com.mx

Software Guru

Con el fin de impulsar cadenas productivas que favorezcan el desarrollo del país, la Secretaría de Economía el pasado 24 de noviembre presentó el evento “Contacto Empresas Tractoras + PyMEs” donde más de 20 compañías tractoras expusieron su demanda de productos y servicios a más de 500 pequeños y medianos negocios para trabajar con ellos. Este evento reunió a empresas Tractoras y PyMEs provenientes de toda la República Mexicana; con el objetivo de establecer nuevas relaciones de negocio.

www.sg.com.mx |

.Contacto Empresas Tractoras + PyMEs

.INDUSTRIA

Prosoftware ››Por José Ignacio Gallegos

l pasado mes de mayo el nuevo consejo de administración encabezado por Ariel Jatuff tomó las riendas del Consejo de Administración de Prosoftware, A.C. A partir de ese momento la asociación que actualmente alberga ya a más de 50 empresas de Tecnologías de Información, la mayoría especializadas en el desarrollo, comercialización y servicios que giran alrededor del software ha dado un giro en su forma de trabajo tanto en la parte interna, apoyando a sus asociados como en la externa viéndose como una asociación fuerte y con representatividad ante la industria y los mercados. “El primer gran reto del Consejo ha sido generar una nueva versión de Prosoftware enfocados en la innovación. Esta, la estamos implementando en: nuestra forma de trabajo, en la relación entre los asociados, en la imagen que tenemos con la industria, el gobierno y la academia. Con esta premisa, durante las sesiones de planeación, dibujamos 13 objetivos a partir de los cuales estamos trazando las estrategias para posicionarnos como una “Red de Innovación” en la que todos los actores estamos enfocados en mejorar en el día a día, colaborando para transformar a la industria así como la imagen de las empresas pequeñas y medianas de TI en nuestro país.” Señaló Jatuff. De acuerdo a Jatuff, Prosoftware se encuentra trabajando en tres iniciativas principalmente: Vinculación Académica y Gobierno; Comunicación Interna e Integración y por último Investigación, Desarrollo e Innovación.

Vinculación académica

Prosoftware como parte de su programa para vincular “La Red de Innovación” con la Academia, ha firmado acuerdos con cinco universidades ubicadas en la zona metropolitana: ITESM Campus Estado de México, Instituto Politécnico Nacional, Universidad Autónoma de la Ciudad de México, Universidad Autónoma Metropolitana, y la UNAM. Buscamos que la integración de los estudiantes a la vida profesional se dé con transparencia. Esto solo se puede lograr si empiezan a conocer la forma en que se trabaja desde que se encuentran cursando sus estudios. Queremos aprovechar el entusiasmo y talento que hemos encontrado en las escuelas con la que ya hemos tenido un 08

trabajando por la innovación

entendimiento de la importancia del capital humano y siendo este un pilar fundamental del trabajo en conjunto.

Comunicación interna e integración

Prosoftware desde su creación ha tenido un reconocimiento por parte de la industria de TI. Con los logros de la administración anterior y el trabajo que hemos venido realizando a partir del mes de mayo, hemos logrado un incremento del 50% en la membresía. Seguimos trabajando en la integración de nuestros socios realizando una serie de eventos internos como las reuniones periódicas de asociados, en las cuales compartimos las experiencias del día a día y contamos con ponentes invitados que ofrecen diferentes panoramas de lo que sucede en la industria. También estamos trabajando en iniciativas para el desarrollo de mercados verticales en los cuales participan varias empresas de “La Red” y a través de las cuales buscamos atacar a un mercado de forma conjunta sin tener que realizar esfuerzos independientes.

Investigación, desarrollo e innovación (I+D+I)

Uno de los proyectos al que le hemos dedicado un esfuerzo mayor es el Metropolitan Innovation Center (MIC). Para la creación de este centro, Prosoftware ha trabajado en conjunto con la Secretaría de Desarrollo Económico del Gobierno del Distrito Federal, las autoridades de la Delegación Azcapotzalco y Microsoft México. El objetivo del MIC es mantener de forma permanente un centro en el cual estaremos desarrollando e innovando en soluciones, productos y servicios de TI que permitan a nuestros socios llegar a nuevos mercados nacionales e internacionales y será el laboratorio mediante el cual podremos concretar nuestra relación con la academia. Como colofón Jatuff nos comentó que cuentan ya con la autorización para el crecimiento del edificio en el cual se alojan, así como la firma de un acuerdo de colaboración con la embajada de Argentina en México para promover el modelo de Prosoftware en esa nación.

.PUBLIRREPORTAJE

NYCE y e-Quallity sellan alianza para

impulsar el Laboratorio Nacional de Pruebas de Software

“La alianza

NYCE - e-Quallity

, organismo nacional de normalización en Tecnologías de la Información y e-Quallity, consorcio especializado en prueba de software, han sellado recientemente una alianza para impulsar el Laboratorio Nacional de Pruebas de Software aplicando estándares NYCE armonizados con estándares internacionales, con lo que se podrá acelerar el acceso a los mercados internacionales de los productos de software desarrollados en el país. Lo anterior en concordancia con el Programa Nacional de Desarrollo de la Industria del Software (ProSoft). Hoy en día el contar con un producto de software de calidad, libre de defectos debe ser una prioridad para las empresas desarrolladoras y puede ser un parte aguas en esa industria en México. El Gobierno Federal a través de la Secretaría de Economía y el fondo Prosoft han hecho esfuerzos por impulsar la industria del software y sin lugar a dudas, el desarrollo de empresas dedicadas a realizar pruebas con las métricas aceptadas internacionalmente, puede ser uno de los baluartes en dicho desarrollo. Las pruebas para determinar la calidad del software que se produce por los departamentos de desarrollo de sistemas en las empresas, representan para algunas de estas compañías una gran inversión. Sin embargo cuando se compara con los costos que genera un software que al ponerlo en producción presenta fallas estructurales que van desde el diseño, la propia programación o la falta de seguridad en el mismo, es realmente pequeño. En 09

aplicaciones críticas como en la medicina o en instrumentos de medición utilizados en transacciones comerciales no puede caber un solo error y el software inmerso en ese tipo de sistemas debe forzosamente estar libre de errores y brindar la seguridad a los usuarios (médicos y pacientes, vendedores y consumidores), de que el software está haciendo los cálculos correctos so pena de poner en riesgo la salud de las personas o su economía. La alianza NYCE – e-Quallity, que deberá fortalecerse con la acreditación de un laboratorio de pruebas de software que será único en México, debe darle a la industria del software uno de los pilares que necesita, para despegar como lo ha hecho en otros países cuya industria les ha dado hasta el 7% del PIB. Dicha alianza, materializada a través de la empresa CIT Calidad y Software, ha iniciado operaciones en Guadalajara, en una de las oficinas del Centro de Software bajo la supervisión y apoyo de los expertos de ambas compañías, quienes se han dado a la tarea de elaborar los procedimientos que la deben llevar a la acreditación ante la EMA (Entidad Mexicana de Acreditación), y darle así el sustento jurídico necesario para que las empresas que logren la “certificación” de su software, junto con el sello de calidad de NYCE Test Proccesing Improvement y Test Maturity Model, tengan la certeza de que el laboratorio y el organismo de certificación son de clase mundial al cumplir con normas internacionales como la ISO/IEC 17025 y la ISO/IEC 060.

www.sg.com.mx |

NYCE

Software Guru

debe darle a la industria del software uno de los pilares que necesita. ”

.COLUMNA Tejiendo Nuestra Red

Desarrollo Global de Software E

retos y factores de

l desarrollo global de software, conocido también como desarrollo y entrega global, no es un concepto nuevo. El primer libro bajo este título fue publicado en 1998 [1]. La definición simple de lo que es el Desarrollo Global de Software habla de desarrollo entre varios equipos en localidades distribuidas geográficamente. Los equipos pueden ser de la misma organización o pertenecer a distintas organizaciones. La distribución geográfica puede variar desde distintos edificios de la misma ciudad hasta diferentes continentes.

Métricas del proyecto. La recolección de datos para mediciones establecidas para un proyecto de desarrollo global de software puede no ser tan fácil. Las diferencias en procesos o infraestructuras heterogéneas pueden ser causantes de datos poco coherentes y, en consecuencia, harán difícil la evaluación cuantitativa del éxito del proyecto.

• Desarrollo de sistemas complejos, que requieren de equipos con distintas especializaciones. • Desarrollo 24 hrs, que aproveche diferencias de horarios. • Estar más cerca del cliente o del mercado.

Cuestiones políticas. Tanto dentro de las organizaciones, que, por ejemplo, temen perder trabajo o resienten la competencia de sitios remotos, como en países o regiones, se pueden dar situaciones que conduzcan a agendas ocultas u objetivos contradictorios.

El desarrollo global de software es una fuente de nuevos retos para la Ingeniería de Software. Algunos de los más importantes son los siguientes [2]: Procesos. Los modelos de procesos que tenemos disponibles están diseñados para una sola organización y, a lo más incluyen a los subcontratados, pero no tenemos procesos para organizar la colaboración y coordinación entre varias organizaciones para un proyecto común. Hoy en día esta falta significa, según algunas fuentes, la disminución de productividad hasta en 50%. Comunicación. Si de por sí la comunicación es difícil dentro de un solo equipo y con un solo cliente, este problema se multiplica en caso de equipos distribuidos geográficamente. La comunicación incompleta da lugar a malos entendidos, omisiones, errores y, en consecuencia, re-trabajo.

Visibilidad y control. En proyectos tradicionales en un solo sitio, es viable transmitir de forma oportuna a todos los participantes el conocimiento sobre la estructura del proyecto, roles y sus responsabilidades, asignación de las actividades de desarrollo, así como el estatus global del avance del proyecto. Sin embargo, transmitirlo oportunamente a distintos sitios geográficamente distribuidos puede ser difícil, especialmente cuando se colabora con otras empresas o con equipos en distintas zonas horarias.

La motivación inicial de este tipo de desarrollo fue abaratar los costos de mano de obra. La India fue el primer país en la mira y lo supo aprovechar muy bien. Pero hoy en día esta práctica se ha popularizado entre múltiples actores y también puede tener otro tipo de motivaciones, como por ejemplo:

Retos

La Dra. Hanna Oktaba es profesora de la UNAM, miembro del IPRC, y directora técnica del proyecto COMPETISOFT. hanna.oktaba@ ciencias.unam.mx

éxito

Cuestiones culturales. Las barreras del idioma, las diferencias en formas de pensar y expresarse, así como diferentes costumbres y formas de trabajar pueden afectar a las relaciones entre equipos, disminuir confianza, y por lo tanto, ser causante de retrasos. Coordinación del trabajo. Distribuir las tareas entre varios sitios y zonas horarias es mucho más complejo que hacerlo para un proyecto de un solo sitio. En efecto, el costo de la coordinación es mayor y los resultados en vez de ser más rápidos se obtienen con retraso.

Protección de propiedad intelectual. Es una preocupación muy latente en desarrollo global especialmente en los países donde las leyes de propiedad intelectual son más laxas. Infraestructuras y herramientas de desarrollo. Al tener equipos distribuidos y multiempresa es común que la infraestructura y herramientas varíen. Quienes provienen de organizaciones más maduras cuentan frecuentemente con herramientas robustas y propietarias, mientras que los equipos más pequeños están utilizando las herramientas ligeras, con frecuencia de código abierto. Esto puede ser un causante adicional de incompatibilidades de ambientes de desarrollo y problemas de integración.

Factores de éxito

Según Global Software Development Handbook [3] los factores críticos de éxito de este tipo de proyectos son los siguientes: • Reducir ambigüedades de procesos organizacionales, de administración, de requerimientos y diseño. Cualquier ambigüedad puede llevar a diferentes entendimientos, estos a conflictos y re-trabajo. • Maximizar la estabilidad, sobre todo de requerimientos y de arquitectura. Según estudios, una solicitud de cambio a requerimientos en un proyecto distribuido requiere 2.4 veces más de tiempo que en uno de un solo sitio. • Entender dependencias, tanto técnicas como temporales, es

crucial. De esto depende la posibilidad de buena distribución del trabajo y la definición adecuada de actividades de coordinación en su volumen, frecuencia y tipo. • Facilitar la coordinación. Existen múltiples maneras de lograr la coordinación entre equipos. La más común es a través de comunicación, aunque también se puede lograr vía procesos, administración del proyecto o la arquitectura. • Balancear flexibilidad y rigidez en procesos. Los procesos tienen que ser lo suficiente flexibles para incorporar diferentes prácticas y experiencias de los equipos y dejarles cierto margen de libertad, pero lo suficientemente rígidos para asegurar que ciertos aspectos del proyecto estén perfectamente definidos, como por ejemplo: instrucciones comprendidas, arquitecturas respetadas, requerimientos cubiertos, administración de configuración definida y aplicada, procedimientos para integración y pruebas adecuados, etc. Para aterrizar estas ideas al territorio mexicano quiero agregar algo. Seguramente ya tenemos en México empresas que están involucradas en el desarrollo de software global. Sabemos poco de sus experiencias. Por otro lado, tenemos desde hace años el movimiento de creación de clusters, pero cuando los visito y pregunto por proyectos en los que participan varias empresas, la respuesta es que “todavía no, pero ya pronto”. Conozco los primeros intentos de este tipo de esfuerzos y los estoy observando con el objetivo de tener elementos para generar un modelo de procesos, que permita organizar las empresas pares para que colaboren en proyectos complejos. Digamos un MoProSoft Colaborativo. A los que tienen experiencia en este tipo de proyectos los invito a colaborar.

>> Por Hanna Oktaba

Referencias: [1] D. W. Karolak. Global Software Development: Managing Virtual Teams and Environments. IEEE Computer Society, 1998. [2] K. Fryer, M. Gothe. “Global software development and delivery: Trends and challenges”. http://bit.ly/sg30r2 [3] R. Sangwan, M. Bass, N. Mullick, D.J. Paulish & J. Kazmeier. Global Software Development Handbook. Auerbach Publications, 2007.

.COLUMNA Mejora Continua

Valores y Capacitación diferenciándonos de la

in de año, tiempo para la reflexión. Este fin de año en particular he estado trabajando mucho en la definición de diferenciadores de negocio, ¿qué hace que una compañía sea mejor que otra?, ¿cómo podemos diferenciar nuestro servicio al de nuestra competencia? Después de varios diálogos con compañeros y amigos, me inclino a pensar que una empresa de servicios sólo tiene dos posibles diferenciadores: 1. Los valores que guían los servicios que ofrecen. 2. El conocimiento que define qué tan bien los integrantes de la compañía saben ejecutar los servicios que ofrecen.

››Las tendencias de capacitación a nivel mundial han cambiado radicalmente. Me llama la atención que la mayoría de las industrias de servicio tienen esto perfectamente claro. La mayoría de ellos trabajan fuertemente para establecer los valores con los cuales se rigen y la institucionalización de su entrenamiento. ¿Quién no ha escuchado sobre los valores de servicio al cliente, comodidad y confianza de la industria hotelera, así como la fuerte cantidad de capacitación que se requiere para servir una taza de café en Starbucks o una hamburguesa en McDonald’s? En la industria de software en México apenas estamos entendiendo estos principios. Normalmente nos enfocamos mucho en la visión y misión de la organización, ¿dónde nos vemos en 10 o 15 años?, pero, ¿qué tan claro están los principios que debemos seguir durante este tiempo?.

Luis R. Cuellar es director de calidad a nivel mundial de Softtek. Es reconocido por la ASQ como Certified Quality Manager, Certified Sofware Engineer y Six Sigma Black Belt. @lcuellar

competencia

Honradez, confianza o apego a las necesidades del cliente, como ejemplos. Adicionalmente, ¿cómo estos principios deben de ser aplicados en nuestro día con día? ¿apego al cliente significa que haremos cualquier cosa que el cliente pida sin decir nada?, ¿o quiere decir que es parte de nuestra responsabilidad ayudar al cliente a hacer las cosas en forma más eficiente? Estas ideas son la base de las acciones y decisiones de la organización y es de suma importancia tomarlas en serio. El otro punto es el entrenamiento y crecimiento de nuestra gente. El grueso de la industria de software en México consiste de PyMEs, las cuales normalmente no tienen capital para mantener una cantidad significativa de empleados en la banca con la expectativa de que caerá un proyecto grande, por lo que cuando esto sucede salen al mercado a contratar personas para incorporarlas a los proyectos. Pero cuando todas las organizaciones se basan en traer gente de fuera, ¿cuál es entonces el diferenciador?, ¿qué hace que una compañía sea mejor que otra? Para resolver este dilema algunas compañías se basan en la especialización, esto es especialistas en una tecnología o un producto en particular, las cuales, cuando se requiere, pueden crecer rápidamente debido a que tienen suficiente gente que conoce la tecnología como para enseñar o controlar a la gente que se incorpora. Esto por supuesto funciona siempre y cuando el crecimiento no sea demasiado acelerado. En un siguiente nivel se encuentra la idea de definir los procesos con los que vamos a trabajar, estos procesos no son más que un acuerdo sobre cómo manejaremos los principales problemas con los que nos topamos y cómo deberían manejarse en un futuro. Estos procesos nos facilitan el incorporar a la gente en nuestra organi-

zación permitiendo traspasar rápidamente el aprendizaje de un grupo al nuevo grupo que se incorpora, los procesos son un excelente punto para incorporar el conocimiento de la organización y las mejores prácticas de la misma. Obviamente los procesos tienen sus limitantes, el tenerlos escritos no asegura que cualquier persona puede simplemente leerlos, entenderlos y cambiar su comportamiento. Este punto nos lleva al siguiente y último nivel de crecimiento el cual está enfocado a una estructura madura de entrenamiento dentro de la organización y qué tan rápida, completa y eficiente es para lograr los objetivos de crecimiento del personal. Una de las principales limitaciones de la capacitación y entrenamiento en la industria de software, es que en muchas ocasiones prevalece la idea de que capacitar es estar en un salón de clases con un instructor que les platica a nuestros empleados sobre las tecnologías del futuro y modelos interesantes que no se llevan a cabo en la práctica. A partir de ahí, la persona sale con mayor madurez y con nuevas ideas para tomar mejores decisiones en la organización. La realidad es que las tendencias de capacitación a nivel mundial han cambiado radicalmente, es de vital importancia un objetivo claro para un plan de capacitación el cual debe de enfocarse principalmente en asegurar que los individuos saben operar y tienen las habilidades necesarias para ejecutar correctamente y en forma eficiente los procesos que conllevan sus roles y los procesos necesarios para mejorar continuamente el trabajo que están haciendo. Las únicas restricciones reales de un plan de capacitación son: a) que el proceso sea repetible a través del tiempo, b) que se pueda evaluar su avance, c) que exista una forma clara de medir su éxito. En otra palabras, manejar un curso en un salón de clases es entrenamiento pero también lo es hacer una estructura virtual a través de cursos pre-grabados, también

podría utilizarse diferentes medios de comunicación como son vídeos, escritos y programas de audio, o grupos de apoyo a través de redes sociales. El “aprendizaje mientras trabajas” (on-the-job learning) funciona siempre y cuando esté claro lo que se debe aprender, tengamos una forma de medir qué se enseñó y cuándo, y podamos evaluar qué tan bien funciona esta capacitación. Si hacemos una búsqueda sobre tecnología de entrenamiento podemos encontrar capacitación virtual con objetivos sencillos hasta doctorados y especialidades, modelos de coaching para generar habilidades de dirección, simulaciones y juegos que enseñan desde tácticas de planeación hasta conocimiento sobre negociación en situaciones de liberación de rehenes. Todos estos son modelos de capacitación que pueden ayudar a nuestra compañía a adquirir en forma rápida el conocimiento que nos diferencie de la competencia. La capacidad para crecer de una organización depende en gran medida en su modelo de capacitación y entrenamiento. Conozco compañías de outsourcing de software en el extranjero en donde los tres accionistas principales son el presidente de la compañía, el director de operaciones, y el director de entrenamiento. Este foco en cómo hacemos que nuestra gente crezca lo más rápido posible, diferencia a una compañía que puede entregar lo que promete de una compañía que no. Estoy convencido que si queremos desarrollar la industria de software en México, el mayor retorno en inversión se encuentra en afianzar nuestros valores como compañías y asegurar que enfocamos nuestros esfuerzos de innovación en tecnología de entrenamiento. En la era del conocimiento lo único que diferencia una compañía mediocre y una compañía excelente son sus valores y qué tan bien sabemos aplicarlos. ¡Mucho éxito para el 2011!

››Por Luis Cuellar

.PRODUCTOS Lo Que Viene

Hace poco más de un año que Google anunció que estaba desarrollando un nuevo sistema operativo denomindo Chrome OS, diseñado especialmente para dispositivos portátiles conectados a Internet y cuya interfaz de usuario está fuertemente basada en el navegador Chrome. Recientemente el equipo de Chrome informó que están iniciando un programa piloto para Chrome OS. Debido a que este sistema operativo se basa en capacidades de hardware de última generación, a los participantes en el programa piloto se les dará una netbook de prueba con Chrome OS. Este programa ya está operando en Estados Unidos y se espera que pronto se extienda a otros países. También se dio a conocer la disponibilidad de la Chrome Web Store, que como habrás podido adivinar por el nombre, es una tienda de aplicaciones para Chrome. Otro avance interesante relacionado con Chrome es el progreso que se tiene en la implementación del estándar WebGL para poder ofrecer gráficos 3D en el navegador sin necesidad de plugins. Recientemente se liberaron demos de esta capacidad, incluyendo una vista tridimensional del cuerpo humano.

Chrome OS Ya está cerca

Consulta los demos de WebGL en http://www.chromeexperiments.com/webgl

A pocas semanas semanas de que se haya lanzado al mercado el Microsoft Kinect, podemos reportarles felizmente que ya existen drivers open source para interactuar con él. Posiblemente ya has visto en YouTube videos donde se usa el Kinect para todo tipo de cosas, desde simular a Tom Cruise en Minority Report hasta generar modelos 3D en tiempo real paseando la cámara por una habitación. Pero no te quedes nada más viendo los videos, te invitamos a que ya empieces a hacer tus propios experimentos. Por ahora, la librería más popular para interactuar con Kinect se llama libfreenect. Fue creada por el español Héctor Martín y donada como software libre al proyecto OpenKinect. También existe una iniciativa llamada OpenNI. El alcance de OpenNI es mayor al de OpenKinect, ya que pretende generar todo un framework y API para interactuar no solo con Kinect sino también con otros dispositivos de interfaz de usuario natural.

OpenKinect

Experimenta, aprende y diviértete

Mas información en http://openkinect.org y http://www.openni.org

MonoDroid es uno de los hijos más recientes del proyecto Mono. Su objetivo es proveer un mecanismo para desarrollar aplicaciones para dispositivos basados en Android, usando el lenguaje C# y componentes de la plataforma .Net.

MonoDroid

.NET para Android

MonoDroid expone dos conjuntos de APIs: • el API central de .NET con el que los programadores de C# están familiarizados, • un vínculo (binding) en C# para el API nativo de Android. • Las aplicaciones desarrolladas con MonoDroid se pueden instalar directamente a un dispositivo, o distribuir por medio de las tiendas de aplicaciones de Android MonoDroid actualmente se encuentra disponible como versión previa y se espera la versión 1.0 durante el primer trimestre del 2011. MonoDroid consiste del ambiente de ejecución, los vínculos al API de Android, un plugin para desarrollar aplicaciones Android desde Visual Studio 2010, y un SDK con las herramientas para construir, depurar e instalar las aplicaciones. Se espera que próximamente también esté disponible para el IDE MonoDevelop en Linux y OSX. Más información en http://monodroid.net

.EMPRENDIENDO

Contabilidad para Startups Enfócate en lo importante ››Por Steve Blank

El siguiente texto es una traducción del artículo “No Accounting for Startups” escrito por Steve Blank. Ha sido traducido y publicado con el permiso del autor. El texto original se encuentra disponible en http://steveblank.com/2010/02/22/no-accounting-for-startups. Te invitamos a visitar el blog de Steve para obtener información valiosa sobre emprendimiento. El libro de Steve sobre desarrollo de clientes titulado “The Four Steps to Epiphany” es un libro de cabecera para los emprendedores exitosos en Silicon Valley. Puedes encontrarlo en Amazon o en http://www.cafepress.com/kandsranch

os startups, quienes típicamente todavía están buscando un modelo de negocio, requieren evaluar su progreso de forma distinta a las grandes empresas que están ejecutando un modelo de negocio conocido. Sin embargo, la mayoría de los emprendedores y sus inversionistas hacen que los startups utilicen modelos financieros que dificultan su éxito. A continuación explico el por qué.

Gestionando el negocio

Cuando dirigía mis propios startups, nuestros inversionistas agendaban juntas periódicas con los fundadores. Durante el primer año o dos, eran cada mes, después cada seis semanas, y una vez que se encontraba un modelo de negocio rentable, se mantenían de forma trimestral. Para conocer el progreso del startup, los inversionistas típicamente echan un vistazo a tres documentos financieros: Estado de Resultados, Flujo de Efectivo, y Balance General. Si en ese entonces hubiera sabido lo que sé ahora, nunca hubiera dejado que eso sucediera. Estos documentos financieros eran más que inútiles para ayudarnos a entender que tan bien o mal estábamos haciendo las cosas. Simplemente eran un indicador de “Fui a una escuela de negocios pero no sé que información darte para que puedas medir, así que te daré esto”. Permítanme ser claro con esto, dichos estados financieros son ver16

daderamente importantes en dos puntos del tiempo. Primero, cuando vendes tu idea a inversionistas, necesitas un modelo financiero mostrando a los inversionistas cómo es que tu empresa se verá cuando ya no seas un startup y estés ejecutando el modelo de negocio rentable que encontraste. Si te parece que al hacer esto en realidad estás adivinando, es porque esa es la realidad, pero no por ello debes dejar de hacer este ejercicio. Armar un modelo financiero y que los fundadores entiendan las relaciones entre las variables que afectan el éxito o fracaso del startup, es un ejercicio valioso. El otro momento en el que es necesario generar y conocer estos reportes financieros es después de que has encontrado tu modelo de negocio rentable y repetible. Entonces usarás estos documentos para administrar tu negocio y monitorear la salud financiera de tu empresa mientras ejecutas tu modelo de negocio. El problema es cuando intentamos usar estos reportes financieros en otros momentos, especialmente en una junta de revisión con inversionistas de un startup. Lo único que esto provoca es que los fundadores se distraigan enfocándose en los números equivocados. Durante años me pregunté por qué para cada junta de revisión tenía que actualizar un estado de resultados que reportaba cero ingresos durante 18 meses hasta que empezamos a tener ventas.

Startups y modelos de negocio

Un startup es la búsqueda de un modelo de negocio repetible y escalable. Como fundador, estás probando una serie de hipótesis acer-

.EMPRENDIENDO

››El modelo de negocio adecuado es cuando

el costo de adquisición de clientes es menor al valor esperado del cliente.

ca de las piezas del modelo de negocio: ¿Quiénes son los usuarios y clientes? ¿Dónde y cómo construiremos el producto? ¿Cuál es el canal de distribución? ¿Cuál será la política de precios? ¿Cómo generamos demanda? ¿Quiénes son nuestros socios de negocio?, ¿Cómo financiaremos la compañía? La figura 1 ilustra la transición entre un startup y una empresa.

Recomiendo conocer el modelo AARRR (Acquisition, Activation, Retention, Referral, Revenue) de Dave McClure.

Figura 2. Métricas para startups y empresas

La figura 3 ilustra a grandes rasgos el flujo de cómo un cliente pasa por las distintas etapas hasta generar ingresos.

Figura 1. Transición de startup a empresa.

www.sg.com.mx |

Software Guru

Un indicador de que has encontrado el modelo de negocio adecuado es cuando consideras que el costo de atraer clientes es menor que los ingresos que dichos clientes generarán. Para los web startups, esto es cuando el costo de adquisición de clientes es menor que el valor esperado de ese cliente. Para los startups en biotecnología, es cuando el costo de la investigación y desarrollo requerida para encontrar y verificar una medicina es menor que el valor de la demanda del mercado por esa medicina. Este tipo de métricas son muy distintas a las que se capturan en un estado de resultados y balance general, especialmente al corto plazo. Entonces, ¿qué deberías presentar en tus juntas con inversionistas? Si estás siguiendo el modelo de desarrollo de clientes, la respuesta es sencilla. Las juntas se tratan de medir el progreso en base a las hipótesis del Descubrimiento y Validación de clientes. ¿Dichas métricas muestran que el modelo de negocio que estás creando soportará a la empresa que estás tratando de formar?

Métricas para startups

Los startups requieren métricas distintas que las empresas establecidas. Requieren métricas que indiquen qué tan bien va la búsqueda de un modelo de negocio, y si al final de la búsqueda valdrá la pena escalar ese modelo hacia una gran empresa o si es tiempo de cambiar de dirección y buscar un modelo de negocio distinto. En esencia, los startups deben “instrumentar” todos los aspectos de su modelo de negocio para medir cómo están saliendo libradas en el mundo real las hipótesis que plantearon en su Descubrimiento y Validación de Clientes. La figura 2 ilustra la diferencia de métricas entre un startup y una empresa establecida. Como mínimo, un web startup necesita entender los siguientes conceptos: Ciclo de vida del cliente, costo de adquisición de un cliente, costo de marketing, coeficiente viral y valor esperado de un cliente. 17

Figura 3. Ejemplo de ciclo de vida de cliente en web startup.

En cierto startup de web, nuestras juntas de revisión eran discusiones de los resultados de probar nuestras hipótesis en el mundo real. Habíamos hecho algunas suposiciones sobre los clientes potenciales y ya teníamos un website en vivo. Así que armamos una hoja de cálculo que daba seguimiento a estos clientes y números mensualmente. Cada mes reportábamos al consejo el progreso en usuarios registrados, activaciones, usuarios retenidos, etcétera. El listado 1 muestra un ejemplo de estos reportes.

.EMPRENDIENDO

BASE DE USUARIOS

• Registros (clientes que completaron el proceso de registro durante el mes). • Activaciones (clientes que tuvieron actividad de 3 a 10 días después de registrarse. Solo considerar registros de ese mes). • Porcentaje de activaciones (Activaciones/Registros). • Clientes retenidos más de 30 días. • Porcentaje de clientes retenidos más de 30 días entre total de activaciones. • Clientes retenidos más de 90 días. • Porcentaje de clientes retenidos más de 90 días entre total de activaciones. • Clientes que pagaron ese mes. • Porcentaje de clientes que pagaron ese mes entre activaciones + retenidos más de 30 días.

FINANZAS

• Ingresos. • Margen de contribución.

Sea cual sea tu modelo de negocio, debes poner especial atención al ritmo al que estás gastando tu capital, la cantidad de meses que te quedan de capital, y el tiempo que te tomará llegar a break-even.

Logra un acuerdo con tus inversionistas

Si tienes inversionistas, trabaja con ellos para acordar cuáles son las métricas que tienen sentido para tu startup. ¿Qué números representan la vida o muerte de tu startup? (Estos números deben estar relacionados con la hipótesis que estás probando en el Descubrimiento y Validación de Clientes). Acuerda con los inversionistas que éstos serán los números que estarán revisando en las juntas periódicas. Acuerda también que posiblemente haya momentos en que los números muestren que el modelo de negocio escogido no vale la pena ser escalado hacia una empresa, y que entonces acordarán que es tiempo de regresar y buscar un modelo de negocio distinto. Tanto tú como ellos sentirán que se están enfocando en los aspectos importantes.

Lecciones aprendidas

CAPITAL

• Burn rate (ritmo al que se gasta el capital). • Meses de capital disponible.

ADQUISICIÓN DE CLIENTES • Costo bruto por adquisición. • Costo neto por adquisición de cliente. • Gastos de publicidad. • Tasa de adquisición viral.

MÉTRICAS WEB • Total de visitas • Total de visitas únicas • Total de páginas vistas • Páginas vistas / visitas

Listado 1. Ejemplo de métricas para un startup web.

Un startup que vende por medio de una fuerza de ventas directa además querrá monitorear aspectos como tamaño promedio de un pedido, valor esperado del cliente, tiempo promedio para realizar el primer pedido, tiempo promedio para pedidos subsecuentes, tasa de ventas entre vendedores, tiempo para que un vendedor nuevo sea efectivo. 18

Las grandes empresas requieren herramientas financieras para monitorear que tan bien están ejecutando un modelo de negocio conocido. El estado de resultados, balance general y flujo de efectivo son buenas herramientas financieras para monitorear grandes empresas. Los startups requieren métricas para monitorear que tan bien van en su búsqueda de un modelo de negocio. Los startups requieren métricas para evaluar si el modelo de negocio que escogieron vale la pena ser escalado hacia una empresa. Utilizar herramientas financieras de empresas establecidas para evaluar el progreso de un startup es como darle un examen de admisión universitaria a un niño de primero de primaria. El objetivo es tener buenos resultados en el futuro, pero durante la etapa de startup solo pueden generar confusión y frustración.

.REPORTAJE

SG Emprende M anteniendo el interés de contribuir al desarrollo de nuestra industria y nuestro país, el pasado 23 y 24 de noviembre se llevó a cabo “SG Emprende”, foro para conocer, difundir y potenciar el emprendimiento basado en tecnología, organizado en conjuto por Software Guru y Emprende.la SG Emprende reunió a personas con amplia experiencia en la creación de startups en Estados Unidos y Latinoamérica, promotores de fondos y recursos para el emprendimiento en México, buscando la vinculación y apoyo a emprendedores. SG Emprende contó con el patrocinio de reconocidas empresas y organizaciones interesadas en el emprendimiento tecnológico como: FUMEC, Microsoft Bizpark Camp, Pronatura, Siestemas Humanos y Kilo. También fue apoyado por Secretaría de Economía mediante los fondos PROSOFT y por organismos como: Prosoftware, CANIETI, Csoftmty, CITI Tabasco, Fidsoftware e IJALTI.

Conferencias Magistrales

Parte importante del congreso fueron los contenidos, a cargo de magníficos conferencistas, emprendedores jóvenes y con un trecho recorrido, quienes a lo largo de sus ponencias nos permitieron escuchar sus experiencias en el ámbito del emprendimiento tecnológico. A continuación te compartimos algunos de los puntos más relevantes de sus conferencias: Andrés Barreto, presidente y fundador de PulsoSocial, comunidad en línea que publica información en lo último en tecnología. 20

Durante su charla exploró y comparó los modelos de negocio que se pueden ejecutar desde Latinoamérica, mencionando también las ventajas y desventajas de crear productos para el mercado regional. David Weekly, director cofundador de los espacios de colaboración Hacker Dojo y SuperHappyDevHouse, quien enfatizó la importancia de resolver problemas sin importar que la solución no utilice la última tecnología, además compartió ideas acerca de qué es el éxito y cómo lograrlo dentro de una empresa. Santiago Siri, fundó Evoluxion, la compañía que creó el primer juego publicado a nivel mundial en su país. Destacó temas como la historia del software en Latinoamérica, así como el valor de la innovación tecnológica.

.REPORTAJE

Programa Start Me Up

Parte fundamental de SG Emprende fue el programa Start Me Up, el cual consistó en convocar y preparar a un grupo de startups para madurar sus proyectos y presentarlos durante SG Emprende con la intención de atraer el interés de inversionistas y clientes potenciales. Start Me Up estuvo formado por dos componentes: Startup Dojo - Etapa de formación intensiva y asesoría con el objetivo de preparar a los fundadores y desarrollar su producto mínimo para ser lanzado. Startup Showcase - Los startups seleccionados presentaron su 21

Recursos de SG Emprende

Los asistentes a SG Emprende tuvieron oportunidad durante 2 días de contactar colegas, inversionistas e interesados en el emprendimiento basado en tecnología, así como convivir de cerca con expertos y jóvenes emprendedores quienes asistieron al congreso. Si estuviste ahí recuerda cada momento en www.sg.com.mx/sgemprende. Si por el contrario, te lo perdiste, entra y disfruta de los videos, entrevistas y conoce más sobre los proyectos participantes. Confiamos ampliamente que el evento estuvo a la altura de sus expectativas, por lo cual esperamos contar con su participación en próximos congresos similares cuyo objetivo será resaltar la importancia del emprendimiento en México.

www.sg.com.mx |

Se registraron más de 50 proyectos de los cuales finalmente se seleccionaron 7 con los que se trabajó la semana previa al congreso, para que finalmente durante SG Emprende se presentaran ante el panel de jueces. Los proyectos finalistas fueron: Aventones, AureaCode, Edictos+Remates, Regala, TrophyWall, Ready2Fill WAM y GiftyFifty. Después de las presentaciones y como cierre de SG Emprende, se anunció como ganador al proyecto presentado por Hugo Stevens, Cesar Salazar y Macario Ortega, titulado Regala, el cual consiste de una plataforma social de recaudación de fondos que permite a organizaciones sin fines de lucro incrementar sus donaciones, atraer más donadores y ofrecer una experiencia superior a sus usuarios.

Software Guru

idea y oferta ante el jurado y audiencia de SG Emprende donde además contaron con un espacio de exhibición.

.ENTREVISTAS

Conferencistas magistrales de SG Emprende ››Por Celeste North

Andrés Barreto

de latinoamérica para el mundo

on pocas las personas que a los 23 años pueden decir que han fundado no solo una, sino varias empresas con impacto global; Andrés Barreto es uno de ellos. Su creación más conocida se llama Grooveshark, un servicio de streaming de música por Internet que actualmente cuenta más de 20 millones de usuarios activos y que mantiene un ritmo de crecimiento fenomenal. Andrés es Presidente de Socialatom, empresa que asesora y provee servicios en social media y relaciones públicas para startups Latinoamericanos que buscan mercados globales. Hemos tenido varios eventos sobre emprendimiento en México en este año ¿Cuál fue tu percepción de SG Emprende? A mi me pareció excelente el evento porque siempre le he tenido mucha fé a las oportunidades que hay en México. Estoy convencido de que el talento está ahí, sólo falta el empujoncito de un evento como este, que muestre las experiencias de los speakers y también otros proyectos que están siendo ejecutados desde México para motivar a los asistentes a hacer sus propias empresas. Mi charla fue enfocada en que sí se pueden hacer empresas desde México, que no necesitan necesariamente depender de capital de riesgo de inversión para empezar, sino cortar el ciclo de desarrollo a lo mínimo posible, lanzar desde el primer día y hacer dinero desde el inicio. Y creo que lo beneficioso de estos eventos no es tanto el contenido en sí, sino que salgan con la motivación, las ideas y con una estrategia clara a empezar algo. ¿Consideras que la sinergia generada con Santiago Siri en Argentina, David Weekly en Silicon Valley y los múltiples esfuerzos locales generen una inercia en emprendimiento durante el próximo año? Yo creo que sí. Hemos visto un crecimiento de esa cultura de emprendimiento en México, la he vivido desde empezando el 2008 22

a 2009 y creo que estamos llegando al punto donde no es solamente la idea de emprender, sino que estamos ejecutando. Puede que en este momento haya tres o cuatro empresas desarrollando un producto y ejecutando algo pero yo sé que el próximo año van a ser ocho y el que sigue dieciseis y así sucesivamente. Y así vamos a seguir creciendo. Acaba de pasar lo que faltaba en el ambiente mexicano, que es la ejecución, entonces creo que comienza a cambiar la perspectiva. Mencionabas que muchas personas no creen que estés trabajando con talento mexicano ¿Está cambiando esta perspectiva? De eso se trata también, de demostrar globalmente. Sabemos que en México se hace desarrollo a la medida, pero no se hacen conocer en el mercado global. Creo que no se está aprovechando suficiente la cercanía a Estados Unidos. Pero los productos que he visto salir en los últimos nueve, doce meses, sí tienen la oportunidad de tener ese impacto para dar a conocer el talento de México globalmente. ¿Qué viene para Andres Barreto en el 2011? Tenemos planeado como objetivo cambiar la manera en que las personas consumen contenido, en el nuevo formato de tablet que está generando una serie de oportunidades nuevas. A ese cambio del desktop on click a lo que va ser ahora on swipe. Es precisamente cuando ves ese cambio de formatos o dispositivos que se presentan oportunidades. Lo vimos en Grooveshark cuando las personas pasaban de descargas a streaming, también lo vimos con Cloudomatic cuando se pasaba de Desktop en el software a Desktop en la nube, ahí fue otro cambio donde se aprovechó la oportunidad. Creo que lo que viene para el 2011 es el cambio de on click a on swipe. Todo lo que es tablet, los dispositivos de touch, abren un mercado totalmente nuevo, oportunidades nuevas y hay que aprovecharlas.

.ENTREVISTAS

Santiago Siri

Hasta ahora ¿cuál ha sido tu experiencia en México? La verdad es que tenemos el problema en América Latina de que estamos muy desconectados. En Brasil pasan cosas y no sabemos qué pasa, aquí pasan cosas y medio sabemos que pasa, en Argentina también y cuando me hicieron la invitación me entusiasmé mucho, en parte porque personalmente no lo conocía y también porque me he cruzado con algún que otro mexicano en eventos por el mundo y me daba mucha curiosidad. México es de los países más importantes en América Latina y me pareció una oportunidad excelente para conocerlo. Muchas de las cosas que ví me recuerdan mucho, aunque en un estadío más maduro, más formal, más avanzado, lo que era la génesis en Argentina de ciertos ecosistemas como lo la ADVA (Asociación de Desarrolladores de Videojuegos Argentina) para el mundo de los videjuegos, eramos 20 locos reúnidos en un Burger King delirando sobre hacer videojuegos y de ahí surgieron varias empresas que ahora emplean a mucha gente. Y llegar acá, ver este evento, los startups que presentaron, ver que hay un anhelo y una organización muy buena en torno al tema, que hay inversionistas y que se empieza a hablar de estas cosas, me da la pauta de que México tiene muy buena infraestructura y está dando los pasos indicados para generar eventualmente compañías de alto impacto en Internet y la tecnología en general. En tu experiencia ¿Cuáles son los elementos que necesita México para despegar? 23

México tiene un problema parecido a Brasil, tiene una fuerza de gravedad muy potente que es el mercado interno, 110 millones de personas que hace que haya muchas necesidades internas a satisfacer, muchos problemas donde hay que encontrar una solución. En ese sentido creo que es algo muy positivo porque implica un volumen potencial de transacciones y de acción de negocios muy grande pero al mismo tiempo no tiene que limitar la cabeza del emprendedor en pensar sólo en México sino también globalmente. Entonces creo que el emprendedor mexicano tiene que sacar la cabeza contemplando a México, sin descuidar México porque es un mercado muy valioso, pero también entendiendo que el día de mañana puede crecer hacia afuera. Y por otro lado, no hace falta tanto power point, tanto excel, tanto análisis de mercado, proyecciones y curvas simpáticas, lo que hace falta es embarrarse. Me parece que hay que inculcar una cultura de arremangarse los brazos y en 14 días programar, hacer algo que solucione una sola cosa, pero que lo haga bien. Hacer las cosas y avanzar en la práctica. Lo que necesitamos es acción, planificación hecha acción, pragmatismo puro. ¿Cómo podemos sumar esfuerzos en latinoamérica y vincular esfuerzos entre países? Todos los problemas que me cuentan acá son un calco perfecto de los problemas que tenemos en Argentina y los que hay en Brasil, en Chile, en Colombia. Estamos muy desconectados unos de otros y creo que Internet, si hay algo que es muy poderoso es que está cambiando la noción del orden mundial, la noción del estado nación. Los problemas de alguien en México son los mismos de alguien en Argentina y creo que esta simbiosis que puede haber entre la experiencia ganada de un país, las necesidades de otro y viceversa es algo fenomenal y debería ocurrir más seguido. Tampoco es tan complejo que ocurra, así que yo celebro la invitación que me hicieron al evento viniendo de Argentina, que haya venido Andrés siendo colombiano que creció en Miami y David que trae la mirada más fresca de Silicon Valley, creo que son cosas muy positivas y ese caldo de cultivo tiene que servirnos a todos.

www.sg.com.mx |

antiago Siri nació en Argentina y comenzó a hacer empresas a los 18 años. Fundó Evoluxion, la primer compañía argentina en publicar un videojuego a nivel mundial. Fué Director Creativo en Three Melons, una compañía de advergames recién adquirida por Playdom. Inició Palermo Valley, la escena local de emprendedores e inversionistas en tecnología que se ha expandido a través de America Latina. También es fundador de Popego y The Whuffie Bank, proyectos finalistas en Tech Crunch 50. Santiago visitó México por primera vez como parte de su participación en SG Emprende y nos compartió su perspectiva sobre el emprendimiento tecnológico en Latinoamérica.

Software Guru

aprovechemos nuestras similitudes

.ENTREVISTAS

David Weekly atestiguando la evolución

avid Weekly es cofundador y director de los espacios de colaboración Hacker Dojo y SuperHappyDevHouse en Silicon Valley. En el 2003 fundó lo que hoy es PBWorks, una de las empresas más grandes de colaboración por Internet, donde todavía se desempeña como miembro del consejo, y Chief Product Officer. Actualmente David dedica una buena parte de su tiempo a asesorar startups. Desde hace un par de años se ha interesado en la escena de emprendimiento en México, participando en distintos eventos y brindando asesoría a desarrolladores mexicanos. En base al tiempo que has pasado en México y lo que conoces sobre nuestro mercado ¿Cómo podemos generar más conciencia sobre el emprendimiento tecnológico en nuestro país? Creo que mucho sucederá con la primer empresa que tenga un éxito sobresaliente. Creo que con una compañía surgida de algún SuperHappyDevHouse —ya sea de la Ciudad de México, Hermosillo, Guadalajara o donde sea— si una de esas compañías se lanza y se convierte en una compañía de cien millones, creo que en ese punto parecerá un éxito de la noche a la mañana para todos los que no están poniendo atención. Se dirá “wow, México tiene una industria de emprendimiento tecnológico” y para los que llevan trabajando en esto por años dirán “si claro, es el resultado de mucho, mucho esfuerzo”. En tu experiencia ¿qué falta para escalar? Para pasar de un grupo de gente haciendo SuperHappyDevHouses, eventos y foros a realmente generar empresas en México. En términos de lo que falta, empezaré por lo que no falta. Lo que no falta es el talento en el código, los programadores aquí son igual de expertos, saben lo que hacen. Están al día con los estándares, tendencias, mejores prácticas y demás. Lo que no falta es diseño, lo ves desde cómo están hechas las presentaciones, la calidad de las presentaciones web, el diseño aquí es de clase mun24

dial, nada falta ahí. Si pienso que falta cierto refinamiento en el modelo de negocio, en cómo enmarcar un problema en términos de dolor y encontrar algo que se necesita urgentemente por un mercado que está dispuesto a pagar por una solución. Es algo que todavía está evolucionando, y es algo que ves mucho en Silicon Valley con los emprendedores primerizos, se topan con una idea que suena interesante y se casan con ella y tienen problemas para pensar racionalmente si hay un camino posible para que esa compañía se valúe en 100 millones de dólares, cómo se vería eso, qué se necesita realmente? Y es difícil, normalmente toma una segunda o tercera vez crear una compañía para tener un modelo de crecimiento saludable al igual que tener una visión de tus posibles mercados. Y siento que como aquí todos están de algún modo haciéndolo por primera vez, todavía está ese aprendizaje que es necesario para aprender a enmarcar el dolor. ¿Cómo pueden las empresas mexicanas alcanzar niveles globales? Creo que en la medida que el mercado valida como enmarcas su problema, encontrarás personas tocando a tu puerta, y tu empresa despegará. Y una idea puede despegar en escala global muy rápido en estos días. Algo se twittea y pasas de cero a cien mil visitantes en unos días y luego a algunos millones en algunas semanas. Los mexicanos tienen el mismo nivel de oportunidad de ser escuchados en una escala global como cualquiera en cualquier lugar, debido al Internet. A menos que estés en China, puedes consultar información de cualquier lugar y enviar información a cualquier lugar. ¿Vamos por buen camino? Claro que sí. Es fantástico venir a un evento como SG Emprende y ver emprendedores tecnológicos mexicanos, construyendo negocios, aprendiendo cómo hacer un pitch, aprendiendo cómo poner sus ideas afuera para una audiencia global, es muy emocionante.

.ESPECIAL

ENCUESTA DE SALARIOS 2010 Ha llegado el momento de compartir con ustedes los resultados de la Encuesta de Salarios SG 2010. Como ustedes saben, este es un ejercicio que realizamos periódicamente para conocer el estado de los salarios y compensaciones que reciben los profesionistas de software en nuestra región. Este reporte, al igual que en sus ediciones anteriores, ha sido generado a partir de información recopilada en una encuesta abierta por Internet. Más de 3 mil personas la contestaron en esta ocasión, sin embargo para este reporte solo se tomaron en cuenta 2,057 respuestas, ya que son las que fueron completadas al 100% y pasaron todos los criterios para eliminar posibilidad de duplicidad. Agradecemos a Secretaría de Economía, quien apoyó la realización de este estudio por medio del Programa para la Industria de Software (PROSOFT). 26

.ESPECIAL

Radiografía del capital humano

Los profesionistas de sistemas laboramos en distintos tipos de organizaciones. Hay quienes forman parte del área de informática de una empresa cuyo negocio principal no es el software ni la tecnología (es decir bancos, gobierno, manufactura, etc.), otros tantos laboran en empresas cuyo negocio es proveer servicios de desarrollo, implantación y mantenimiento de TIs. Otro tipo de organizaciones son los ISVs (Independent Software Vendors) que son las empresas que crean tecnología propia para comercializarla, así como los distribuidores o canales que revenden tecnología de terceros, y por último tenemos a las organizaciones cuyo negocio son los servicios educativos relacionados con tecnología de información. La tabla 1.1 muestra el desglose de los encuestados de acuerdo al tipo de organización en que laboran. Tipo de organización Área de sistemas Proveedor de servicios ISV Academia Servicios educativos (no academia) Canal/distribuidor de productos Otro

% 44.2 30.6 7.5 3.8 3.1 2.7 8.2

Tabla 1.1. Desglose por tipo de organización.

Podemos apreciar que las áreas de sistemas usuarias o “in-house” siguen siendo las que absorben mayor cantidad de profesionistas

Esquema de contratación

La tabla 1.2 muestra el desglose de la muestra en base al esquema de contratación bajo el que trabajan. Esquema Nómina Honorarios Independiente/Freelance Otro

% 68.2 19.9 6.9 4.4

Género

Las mujeres siguen siendo muy escasas en nuestra profesión, lo cual se refleja en los resultados mostrados por la tabla 1.5. La proporción de mujeres es incluso menor que la que reportamos en 2007 (14.3%). Ante la escasez de capital humano en nuestra industria, valdría la pena realizar un esfuerzo para conseguir que más mujeres ingresen (y se mantengan) en nuestra profesión. Sin duda esta es un área de oportunidad. Género Masculino Femenino

% 86.9 13.1

Tabla 1.5. Género. Tabla 1.2. Esquema de contratación

Geografía

Edad

La tabla 1.3 muestra el desglose por rango de edad de la muestra que contestó la encuesta. Edad 18 a 24 25 a 29 30 a 39 40 a 49 50 a 59 60 o más

% 12.4 35.3 41.0 9.3 1.7 0.3

Tabla 1.3. Rango de edad de la muestra.

Escolaridad

La tabla 1.4 indica el máximo grado de estudios completado.

¿Cómo están distribuidos geográficamente los profesionistas de software en nuestro país? En la tabla 1.6 listamos los 10 estados con mayor participación dentro de la muestra. Estado DF MEX JAL NL QRO VER GTO PUE BC HGO

% 35.7 11.9 10.2 7.0 3.5 3.1 2.9 2.7 2.0 1.7

Tabla 1.6. Participación de los estados en

Escolaridad Preparatoria Técnica / Vocacional Universidad (sin titular) Universidad (titulado) Maestría Posgrado Doctorado Tabla 1.4. Máximo grado de estudios.

% 1.1 2.3 27.6 47.6 15.6 5.1 0.8

la muestra.

En las siguientes páginas agregaremos a estos valores el dato de los sueldos promedio para cada segmento. No quisimos mostrar dicha información desde un inicio para no perder el enfoque de esta sección, que es la de analizar la estructura del capital humano de nuestra industria.

Software Guru

Tipo de organización

de TI. Sin embargo, estas organizaciones cada vez se apoyan más en proveedores de outsourcing, lo cual se refleja al comparar estos números con los de 2007, donde las áreas de sistemas tenían 47.4% del personal y los proveedores de servicios 26.8%.

www.sg.com.mx |

ntes de iniciar con los detalles de sueldos y sus variaciones, vale la pena echar un vistazo al perfil de quienes contestaron la encuesta. Esta información no solo es útil para poder entender mejor los resultados de la encuesta, sino también para conocer mejor la composición del capital humano de la industria de software y servicios.

.ESPECIAL

Salarios y Factores Y

entonces, ¿Cómo están actualmente los salarios para profesionistas de software en nuestra región?

La tabla 2.1 muestra el tabulador de salarios por rangos, indicando el porcentaje de personas de la muestra que caen en cada uno. Recuerda que estas cifras indican el salario bruto mensual de cada persona, antes de prestaciones y compensaciones adicionales. Rango de salario Menos de 4 mil pesos De 4 a 6 mil pesos De 7 a 10 mil pesos De 11 a 15 mil pesos De 16 a 20 mil pesos De 21 a 25 mil pesos De 26 a 30 mil pesos De 31 a 40 mil pesos De 41 a 50 mil pesos De 51 a 60 mil pesos De 61 a 80 mil pesos Más de 80 mil pesos

% 2.7 6.4 12.3 16.7 15.5 13.4 11.4 11.4 4.0 3.0 1.5 1.9

Tabla 2.1. Tabuladores de salario mensual.

Si calculamos un promedio ponderado en base a estos números, obtenemos un valor de $23,052 pesos, que sería el salario bruto mensual promedio de un profesionista de software en nuestra región. Esta cifra representa un aumento muy pequeño respecto a la obtenida en 2008 ($22,570 pesos), lo cual nos hace pensar que los salarios en nuestra industria se han mantenido fijos en el último par de años. En cierta forma esto era de esperarse debido al estancamiento económico que hemos vivido en este periodo.

Remuneración adicional

Aunque el principal componente de la remuneración laboral es el salario, sin duda otro elemento muy importante son las remuneraciones adicionales. La tabla 2.2 provee un tabulador del valor al que ascienden las prestaciones recibidas anualmente, tales como aguinaldo, bonos, reparto de utilidades, etc.

Remuneración adicional Ninguna Menos de 10 mil pesos De 10 a 25 mil pesos De 25 a 50 mil pesos De 50 a 100 mil pesos De 100 a 200 mil pesos Más de 200 mil pesos

% 26.0 22.7 24.3 14.3 8.5 2.9 1.3

Tabla 2.2. Remuneración adicional anual.

Prestaciones

La tabla 2.3 indica las prestaciones más comunes y el porcentaje de la muestra que recibe cada una. Prestación Flexibilidad de horario Gastos médicos mayores Préstamos Bonos por desempeño Gastos médicos menores Teletrabajo (desde casa) Celular Ayuda para educación Ayuda familiar Vivienda / departamento Automóvil Acciones (stock options)

% 39.6 39.4 30.1 24.2 19.8 18.9 18.3 10.9 6.0 4.8 4.3 3.4

Tabla 2.3. Cobertura de prestaciones.

mos tenido tanto en la conectividad como en la disponibilidad y calidad de las herramientas de colaboración remota, esta tendencia es de esperarse y sin duda mantendrá su crecimiento.

Variación por geografía

Como ustedes saben, los salarios varían muchísimo dependiendo de la zona geográfica. En el caso de México, la tabla 2.4 muestra los salarios promedio segmentados por entidad federativa. Para evitar valores no representativos, solo se incluyeron aquellas entidades de donde se obtuvieron más de 40 respuestas. Cabe notar que en cada edición de esta encuesta de salarios han alternado el liderazgo en este rubro el Distrito Federal y Nuevo León, lo cual se repitió en esta ocasión ya que DF había sido líder en 2008 y ahora es Nuevo León. Estado NL DF QRO MEX JAL BC GTO VER PUE

Sueldo $29,431 $27,920 $24,557 $22,526 $21,225 $20,714 $15,137 $13,200 $13,128

Tabla 2.4. Salario mensual promedio por entidad (México).

Comparando estas cifras con las obtenidas en 2008, notamos que en la mayoría de los casos se disminuyeron las prestaciones (es decir, el porcentaje de personas que las recibe). Por ejemplo, en el 2008 el 44.7% de la muestra recibía como prestación seguro de gastos médicos mayores y el 29.5% recibía bonos por desempeño. Consideramos que los dos factores que más han afectado esto son la migración hacia esquemas de subcontratación externa, aunado a la difícil situación económica que vivió nuestra región en este periodo. Por otro lado, vale la pena recalcar que los dos conceptos que aumentaron su participación respecto al 2008 fueron el de flexibilidad de horario y el teletrabajo. Teniendo en cuenta los avances y penetración que he-

Estado USA España Perú Argentina Colombia Venezuela

Sueldo $89,286 $50,143 $30,000 $16,750 $12,875 $10,000

Tabla 2.5. Otros países.

Cada vez recibimos más participación en esta encuesta de parte de profesionistas fuera de México, lo cual nos da un gran gusto. La tabla 2.5 muestra los salarios promedio estimados en base a estos resultados. En este caso solamente

.ESPECIAL Extra

Integrado

$25,469 $26,235 $22,806 $21,881 $21,789 $16,897

$3,391 $1,438 $1,889 $2,418 $2,009 $1,980

$28,861 $27,673 $24,695 $24,300 $23,798 $18,877

$16,786

$1,799

$18,585

mente, 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 desempeño dentro de la empresa.

Tabla 2.6. Compensación integrada por tipo de organización.

incluimos aquellos países de donde obtuvimos al menos 5 respuestas. Sabemos que con dicho criterio, las cifras arrojadas son poco representativas, así que habrá que tomarlas con reserva.

Tipo de organización

La tabla 2.6 muestra los salarios de acuerdo al tipo de organización donde laboran. Además del salario bruto incluimos las compensaciones extra, ya que éstas acostumbran tener una variación significativa dependiendo del tipo de organización. Como podemos apreciar, nos encontramos con un patrón muy similar al de años anteriores, donde los proveedores de servicios con los que ofrecen los sueldos brutos más altos pero las compensaciones adicionales más bajas, mientras que los canales/distribuidores son los que tienen mayores compensaciones adicionales, lo cual posiblemente se deba a comisiones de venta o bonos extraordinarios al cumplirse las cuotas de venta.

Género

La buena noticia para el sexo femenino es que a pesar de que la proporción de su género no ha mejorado, sí ha aumentado su compensación económica. La tabla 2.7 muestra el sueldo promedio por género. Aunque los hombres siguen ganando claramente más que las mujeres, la diferencia arrojada en esta ocasión es de cerca de un 20%, lo cual es mucho menor que el 33% que se había obtenido en el último par de ediciones de este reporte. Género Masculino Femenino

Sueldo $23,570 $19,631

% 86.9 13.1

Tabla 2.7. Sueldo por género.

Edad y Experiencia

En ediciones anteriores hemos reportado que el

salario de un profesionistas 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 y posteriormente baja después de los 60. Las tablas 2.8 y 2.9 confirman esto, pero nos hacen ver que más que la edad, lo que importa es la experiencia. Edad 18 a 24 25 a 29 30 a 39 40 a 49 50 a 59 60 o más

Sueldo $11,797 $18,576 $26,524 $35,539 $44,387 $42,667

% 12.4 35.3 41.0 9.3 1.7 0.2

Tabla 2.8. Sueldo por edad.

Experiencia Sueldo Menos de un año $8,340 1 a 3 años $12,779 3 a 5 años $19,101 5 a 10 años $23,458 Más de 10 años $32,581 Más de 20 años $40,697

% 5.2 18.1 19.8 28.1 22.2 6.6

Tabla 2.9. Sueldo por experiencia.

Escolaridad

La tabla 2.10 muestra los sueldos promedio de acuerdo al máximo grado de estudios. Tal como lo habíamos venido observando en ediciones anteriores, resalta que las compensaciones más altas no las obtienen las personas con maestría o doctorado, sino quienes cuentan con otro tipo de posgrado, como sería un diplomado, que requiere menos dedicación. La explicación que hemos dado anteriormente y que sostenemos es que este tipo de posgrados 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. Adicional-

Escolaridad Posgrado Maestría Doctorado Universidad (titulado) Técnica / Vocacional Universidad (sin titular) Preparatoria

Sueldo $29,901 $29,057 $28,857

% 5.1 15.6 0.8

$22,005

47.6

$20,732

2.3

$20,498 $18,100

27.6 1.1

Tabla 2.10. Sueldo por grado de estudios terminado.

Tipo de actividades

En un campo con tanta especialización como el nuestro, vale la pena calcular el sueldo promedio para distintos perfiles o tipos de actividad. La tabla 2.11 muestra dicha segmentación. Función Sueldo Dirección de negocio $49,956 Dirección de sistemas $41,478 Ventas/Preventas $36,152 Arquitectura de sistemas $31,077 Gestión de proyectos/servicios $27,917 Consultoría $26,057 Aseguramiento de calidad $24,341 Seguridad informática $22,630 Administración de sistemas $21,071 Administración de datos (DBA) $19,442 Desarrollo de aplicaciones $19,403 Administración de redes $17,353 Funciones generales de T.I $16,596 Profesor $13,827 Soporte técnico $11,647 Diseño y administración web $11,379

% 2.5 5.0 1.8 5.8 10.7 6.8 2.3 1.5 6.2 2.4 39.3 0.9 5.2 2.9 2.8 3.7

Tabla 2.11. Sueldo promedio de acuerdo a perfil.

Software Guru

Sueldo

www.sg.com.mx |

Tipo de organización Canal/distribuidor de productos Proveedor de servicios ISV Área de sistemas Otro Academia Servicios educativos (no academia)

.ESPECIAL

Conocimientos y Habilidades

na vez que hemos analizado aspectos generales que influencian nuestra compensación, entremos de lleno en los aspectos que tienen impacto directo en el trabajo que realizamos y los ingresos que obtenemos por este. Tal como su nombre lo indica, el ámbito de las tecnologías es altamente técnico, y por lo tanto es comprensible que los conocimientos y habilidades tengan una gran influencia en la compensación económica que podamos pretender. En la sección anterior ya se mostró una tabla en base al tipo de actividad. En la figura 3.1 ahondamos un poco más en este aspecto.

Una vez más, las tecnologías como Cobol y mainframe, que se utilizan mucho para sistemas de misión crítica en el sector financiero, tienen los salarios más altos a pesar de no ser tecnologías novedosas. Llama también la atención que plataformas como iPhone OS y Android rápidamente estén generando una base significativa de desarrolladores.

Certificaciones Figura 3.1. Actividades desempeñadas.

Lenguajes, plataformas y tecnologías

A pesar de que nuestra profesión involucra mucho más que programar, no podemos evadir la importancia de tener dominio de al menos un lenguaje de programación. De hecho, una de las preguntas que nos hacemos continuamente los profesionistas de software es “¿y ahora qué lenguaje o tecnología debería aprender? Las figuras 3.2 a 3.4 nos muestran los salarios promedio para distintas tecnologías, así como los porcentajes de la muestra que indicaron dominarlas.

Figura 3.2. Lenguajes y tecnologías.

A pesar de sus limitantes, las certificaciones son lo más cercano que tenemos a una “garantía” de conocimiento y por ende en nuestro campo se recurre ampliamente a ellas. La figura 3.5 muestra algunas de las certificaciones más populares entre profesionistas de software y el salario promedio para cada una. Como ya es costumbre, la certificación de PMP (Project Management Professional) del PMI es la que corresponde a los mayores ingresos. Una certificación que nos llama la atención por el ranking que obtuvo es la de Scrum (Certified Scrum Master). A pesar de que esta certificación es relativamente sencilla de obtener (basta con tomar un curso de un par de días), parece ser que los Scrum Masters sí la desquitan y se venden bien. Todavía tenemos una gran área de oportunidad para aumentar la cantidad de certificaciones en nuestro país. Consideramos que iniciativas como Mexico FIRST han contribuido significativamente a mejorar esta situación (seguramente han influido en el salto que tuvo Java del 6 al 13% en poco más de un año).

Inglés

Más de una persona responsable del reclutamiento en organizaciones de T.I. nos ha comentado que antes de averiguar los conocimientos y habilidades directamente relacionados con desarrollo de software que tenga una persona, lo que más le interesa es su nivel de inglés. Es así que en esta ocasión decidimos relacionar salarios con nivel de inglés, y los resultados son contundentes como lo muestra la figura 3.6. Conforme aumenta el nivel de inglés de la persona, también hay un aumento en el ingreso percibido.

Figura 3.3. Plataformas.

www.sg.com.mx |

Software Guru

.ESPECIAL

Figura 3.4. Bases de datos. 31.8k 16.9k

Figura 3.5. Certificaciones.

Figura 3.6. Nivel de ingl茅s.

20.7k 53.4%

27.5%

Avanzado (lectura, redacci贸n y conversaci贸n fluida)

Intermedio (escribo y hablo pero con algunos errores)

19.2%

B谩sico (leo y escribo con apoyo de diccionario)

$35k $30k $25k $20k $15k $10k $5k $0k

100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0%

.ESPECIAL

Información complementaria Satisfacción con empleo actual

La tabla 4.1 refleja la satisfacción de los encuestados con su empleo actual. En una columna indicamos la satisfacción con su trabajo, y en otra con su compensación. A grandes rasgos, econtramos un patrón similar al de años anteriores, donde las personas están en general más satisfechos con el tipo de trabajo que realizan, que con la compensación que reciben. Satisfacción Muy satisfecho Medianamente satisfecho Poco satisfecho Nada satisfecho

Con el trabajo % 30.7% 46.3% 19.2% 3.8%

Con la compensación % 17.5% 58.0% 18.6% 5.9%

Tabla 4.1. Satisfacción.

Motivadores

¿Qué es lo que las personas más aprecian de su empleo? Más allá del dinero, las personas valoran otros aspectos de sus empleos. Es bueno conocer qué es lo que motiva más al personal que trabaja contigo. Motivador Aprendizaje Flexibilidad de horario Estabilidad de la empresa Proyección de carrera Sueldo base Conveniencia (distancia, comodidad) Cultura, valores, ambiente Nivel de responsabilidad Prestaciones Seguridad de tu posición

% 19.2% 14.8% 13.4% 12.7% 10.4% 8.9% 7.2% 5.2% 4.7% 3.4%

Tabla 4.2. Motivadores.

Estatus de búsqueda

¿Qué tantas personas están actualmente buscando cambiar de empleo? La tabla 4.3 indica el estatus de búsqueda de los participantes en esta encuesta.

Búsqueda Pasivamente buscando empleo en otra empresa No buscando Buscando otra posición en la misma empresa Activamente buscando empleo en otra empresa

% 45.0% 27.5%

Tabla 4.5. Beneficios buscados.

11.8%

Conclusiones

La tabla 4.4 indica las principales razones por las que los encuestados cambiarían de trabajo.

Mayor sueldo Mayor desarrollo profesional Mejores prestaciones Mayor jerarquía/ responsabilidad Cambio de lugar/ciudad Menos trabajo Cambio de giro/carrera

40.7% 32.7% 10.4% 9.2% 5.2% 0.9% 0.9%

Tabla 4.4. Razones para buscar otro empleo.

Beneficio Bonos por desempeño Gastos médicos mayores Ayuda para educación Flexibilidad de horario Trabajo remoto Vivienda / departamento Automóvil Ayuda familiar Caja de ahorro Acciones (stock options) Gastos médicos menores Teléfono celular

15.7%

Tabla 4.3. Estatus de búsqueda.

Razón de cambio

Por último, en la tabla 4.5 podemos conocer cuáles son los beneficios o prestaciones que a la gente más le gustaría que sus empresas ofrecieran. Al parecer, lo primero que buscan las personas es mayores ingresos variables por medio de bonos de desempeño, y posteriormente el contar con seguros de gastos médicos mayores. Una vez que estos dos aspectos están cubiertos, lo que más le interesa a las personas es contar con apoyo para educación, ya sean cursos de capacitación o algún postgrado, seguido de tener una mayor flexibilidad en su horario. % 39.8% 39.2% 33.3% 28.6% 24.3% 24.1% 23.1% 15.9% 15.6% 13.7% 13.6% 5.2%

A lo largo de estas páginas hemos brindado un reporte extensivo sobre la situación del capital humano de tecnologías de información en nuestra región, los salarios y compensaciones que se perciben, los factores que tienen mayor impacto en esta compensación, y los principales objetivos que se tienen al buscar un nuevo empleo. Esperamos que esta información te sea valiosa, ya sea para determinar si tu compensación actual es justa, o qué es lo que debes hacer para mejorarla. Si eres un empresario o responsable de un área de reclutamiento, confiamos en que la información presentada te ayude a planear de mejor forma los salarios y prestaciones que ofreces. Agradecemos a todas las personas y organismos que participaron en esta encuesta. Nos vemos en la próxima edición de la encuesta de salarios SG.

Software Guru

ara cerrar este reportaje, echemos un vistazo a algunos aspectos relacionados con la situación laboral de los profesionistas de software.

www.sg.com.mx |

.PRÁCTICAS Requerimientos

Calidad de Datos en Aplicaciones Web

conceptos y enfoques

››Por César Guerra e Ismael Caballero

• Dependiente del sistema: se refiere al grado en el cual la calidad del dato es enriquecida y preservada dentro de un sistema de cómputo cuando el dato es usado bajo condiciones específicas.

n la actualidad, es fundamental mantener un nivel aceptable de calidad en los datos que gestionan las compañías, sobre todo en las aplicaciones Web. Para asegurar esos niveles de calidad de datos (DQ), es imprescindible llevar a cabo una gestión de los requisitos específicos de DQ durante todo el ciclo de desarrollo de la aplicación Web. Sin embargo, en el ámbito de desarrollo de aplicaciones Web no existen propuestas que contemplen artefactos para la gestión de este tipo de requisitos de calidad de datos. El objetivo de este trabajo es dotar a los analistas y desarrolladores de aplicaciones Web de las herramientas necesarias para especificar e implementar de forma clara e intuitiva los requisitos de DQ mediante distintos elementos de modelado. Considerando el enfoque MDA (Model Driven Architecture) y basándonos en la Ingeniería Web Dirigida por Modelos (MDWE), en este artículo se presenta una propuesta basada en extensiones al metamodelo WebRE, que permitirá modelar los elementos considerados básicos para la gestión de requisitos de DQ en aplicaciones Web. Adicionalmente se presenta los artefactos desarrollados que permiten hacerlo operativo a través de un plugin desarrollado en la plataforma Eclipse.

La tabla 1 en la siguiente página describe las dimensiones de calidad de datos propuestas por el estándar ISO/IEC 25012. Definimos un “requisito de calidad de datos” como “la especificación de las dimensiones o características que un conjunto de datos debería cumplir para una tarea específica”. El propósito principal es satisfacer las necesidades específicas de calidad en los datos que cada uno de los usuarios requiere en un momento determinado.

El Metamodelo WebRE

En lugar de crear una nueva metodología para desarrollo web que incorpore aspectos de calidad de datos, consideramos que es mejor ampliar una metodología existente. Analizando las distintas opciones de metodologías para desarrollo Web que soportan las fases de requisitos y diseño encontramos el metamodelo Web Requirementes Engineering (WebRE) propuesto por Escalona y Koch [2]. En la figura 1 se aprecia el metamodelo propuesto por WebRE. Las metaclases representan los conceptos sin ninguna información acerca de su representación, y son agrupados en dos paquetes siguiendo la estructura del metamodelo de UML “WebRE Structure” y “WebRE Behavior”.

Introducción a la calidad de datos (DQ)

Es común que una aplicación de software presente comportamientos erróneos, no por defectos en la aplicación como tal, sino por defectos en los datos que utiliza. Es decir, por niveles inadecuados de calidad en sus datos. La calidad de los datos (DQ) depende del contexto en el que éstos se van a utilizar. Es decir, un dato es de calidad si es válido para el propósito en que un usuario quiere utilizarlo para una tarea determinada. Este concepto se conoce como “adecuación al uso” (fitness for use). Para abordar la calidad de datos en un contexto en específico, se acostumbra dividirla en partes más pequeñas, “calidades menores” conocidas como dimensiones de calidad de datos. La agrupación de varias de estas di.BIO mensiones recibe el nombre de modeCésar Guerra-García es profesor en el Departamento de Tecnologías los de calidad de datos. de Información en la Universidad Politécnica de San Luis Potosí, y Si bien no existe un modelo unidoctorando en la Universidad de versal de DQ, el propuesto por el esCastilla La Mancha. cguerra74@gmail.com tándar internacional ISO/IEC 25012 Ismael Caballero es profesor en para Sistemas de Información proporel Departamento de Tecnologías ciona una buena aproximación. Dicho y Sistemas de Información en la Universidad de Castilla-La Mancha modelo identifica 15 características o en Ciudad Real, España. ismael.caballero@uclm.es dimensiones consideradas desde dos puntos de vista: Referencias: [1] M. Ge & M. Helfert. “A Review of Information Quality Research”, International Conference on Information Quality, 2007. [2] D. Strong, Y.W. Lee, & R.Y. Wang. “Data Quality in Context”, Communications of the ACM Vol 40 Issue 5, 1997. [3] M.J. Escalona & N. Koch. “Metamodeling the Requirements of Web Systems”, Web Information Systems and Technologies, 2006. http://bit.ly/sg30r8

• Inherente: la calidad de datos inherente se refiere al grado en el cual las características de calidad del dato tienen el potencial intrínseco para satisfacer las necesidades implicadas cuando el dato es usado bajo condiciones específicas.

Figura 1. Metamodelo WebRE.

.PRÁCTICAS

Requerimientos

El grado en el cual el dato tiene atributos que correctamente representan el valor correcto del atributo intencionado de un concepto o evento en un contexto específico de empleo. El grado al cual el dato del sujeto asociado con una entidad tiene valores para todos los atributos esperados e instancias de entidad relacionadas en un con texto específico de uso. El grado en el cual el dato tiene los atributos que son libres de contradicción y son coherentes con otros datos en un contexto específico de uso. El grado en el cual el dato tiene atributos que son considerados como verdaderos y creíbles por usuarios en un contexto específico de uso. El grado en el cual el dato tiene los atributos que son del período correcto en un contexto específico de uso.

INHERENTES Y DEPENDIENTES DEL SISTEMAS Accesibilidad Conformidad Confidencialidad Eficiencia Precisión Trazabilidad Entendibilidad

El grado en el cual se puede accesar al dato en un contexto específico de uso, en particular por la gente que necesita el soporte de tecnología o una configuración especial debido a alguna inhabilidad (incapacidad). El grado en el cual el dato tiene atributos que se adhieren a normas, convenciones o regulaciones vigentes y reglas similares relacionadas con la calidad de datos en un contexto específico de uso. El grado en el cual el dato tiene los atributos que aseguran que éste es sólo accesible e interpretable por usuarios autorizados en un contexto específico de uso. El grado en el cual el dato tiene los atributos que pueden ser procesados y proporciona los niveles esperados de funcionamiento (desempeño) usando las cantidades y los tipos de recursos apropiados en un contexto específico de uso. El grado en el cual el dato tiene atributos que son exactos o que proporcionan la discriminación en un contexto específico de uso. El grado en el cual el dato tiene atributos que proporcionan un rastro de auditoría de acceso a los datos y de cualquier cambio hecho a los datos en un contexto específico de uso. El grado en el cual el dato tiene atributos que le permiten ser leído e interpretado por usuarios, y es expresado en lenguajes apropiados, símbolos y unidades en un contexto específico de uso.

DEPENDIENTES DEL SISTEMA Disponibilidad Portabilidad Recuperabilidad

El grado en el cual el dato tiene atributos que le permiten ser recuperados por usuarios autorizados y/o aplicaciones en un contexto específico de uso. El grado en el cual el dato tiene los atributos que le permiten ser instalado, substituido o movido de un sistema a otro conservando la calidad existente en un contexto específico de uso. El grado en el cual el dato tiene atributos que le permiten mantener y conservar un nivel especificado de operaciones y calidad, aún en caso de falla, en un contexto específico de uso.

Tabla 1. Dimensiones de DQ según el estándar ISO/IEC 25012.

››Un dato es de

calidad si es válido para el propósito en que un usuario quiere utilizarlo”

La funcionalidad de un sistema Web (WebRE Behavior) es modelada por un conjunto de instancias de dos tipos de casos de uso específicos “Navigation” y “WebProcess”, y actividades específicas como “Browse”, “Search” y “UserTransaction”. El segundo paquete del metamodelo “Structure Package”, contiene las metaclases usadas para describir los elementos estructurales del sistema Web: contenido (Content), nodo (Node) e interfaz de usuario Web (WebUI). Una breve descripción de cada elemento del metamodelo se muestra en la Tabla 2.

Metamodelo de Requisitos de Calidad de Datos para Aplicaciones Web

Una vez que hemos mostrado las características y elementos principales del metamodelo tomado como base (WebRE), describamos ahora la propuesta de metamodelo ampliado (DQ_WebRE) para la integración de elementos para la gestión de requisitos de calidad de datos. Para ello introducimos los siguientes conceptos: “DQRequirement”, “InformationCase”, “Add_DQ_Metadata”, “DQ_Validator” y “DQ_Metadata”. Dichos conceptos se presentan como elementos fundamentales dentro del metamodelo propuesto (ver Figura 2).

Software Guru

Exactitud Completitud Consistencia Credibilidad Actualidad

www.sg.com.mx |

INHERENTES

.PRÁCTICAS Requerimientos WebUser Representa cualquier usuario que interactúa con la aplicación Web. Navigation Representa un caso de uso específico, el cual incluye un conjunto de actividades de tipo “Browse” que el usuario web será capaz de desempeñar para alcanzar un nodo destino. Web-Process Modela las funcionalidades principales (normalmente procesos de negocio) de la aplicación Web. Representa otro caso de uso el cual puede ser refinado por diferentes actividades de tipo Browse, Search y UserTransaction. Browse Representa una actividad normal de navegación dentro del sistema, la cual puede ser mejorada por una actividad de búsqueda “Search”. Search Esta actividad tiene un conjunto de parámetros, la cual permite realizar consultas sobre los datos almacenados en la metaclase “Content”. Los resultados pueden ser mostrados en el nodo destino. User-Transaction Representa actividades más complejas que pueden ser expresadas en términos de transacciones iniciadas por los usuarios. Node Representa un punto de navegación donde el usuario puede encontrar información. Cada instancia de una actividad Browse inicia en un nodo (origen) y termina en otro nodo (destino). Los nodos se muestran al usuario como páginas. Content Representa el lugar donde se almacenan las piezas de información. WebUI Representa el concepto de página Web. Tabla 2. Elementos del metamodelo WebRE.

se encarga de agregar y/o verificar la información de DQ (metadatos de DQ) asociada a cada una de las instancias de las metaclases DQ_Metadata y DQ_Validator. La metaclase “DQ_Metadata” representa un elemento estructural de la aplicación Web. Aquí serán gestionados y almacenados los metadatos de DQ. Estos metadatos estarán asociados a los elementos de tipo “Content”. En este sentido, será posible especificar diferentes requisitos de DQ ligados directamente a los datos almacenados por los elementos de tipo “Content”. La metaclase “DQ_Validator” representa un elemento estructural del sistema Web, esta metaclase será la responsable de implementar funciones específicas de DQ, con el objetivo de validar o restringir los elementos de interfaz de usuario (WebUI) que proveerá la aplicación Web.

Aplicación usando plugin de Eclipse

Figura 2. Metamodelo para requisitos de calidad de datos DQ_WebRE.

La metaclase “DQ_Requirement” representa un caso de uso específico, necesario para modelar los requisitos de DQ (dimensiones de DQ) que estarán relacionados a los casos de uso “InformationCase” (IC). La metaclase “InformationCase” representa los casos de información (IC) de la aplicación Web. A diferencia de los casos de uso normales, la principal función de los IC es gestionar y almacenar los datos involucrados con las funcionalidades de tipo “WebProcess”. Estos datos estarán relacionados a los requisitos específicos de DQ (DQ_Requirement). La metaclase “Add_DQ_Metadata” representa una actividad concreta relacionada a las diferentes actividades “UserTransaction”, esta metaclase

El metamodelo DQ_WebRE se implementó en la plataforma Eclipse, haciendo uso del Eclipse Modeling Framework (EMF). Esto permite que los modelos generados a partir de este metamodelo podrán ser almacenados en formato XMI , el cual puede considerarse como un modelo de entrada para posteriormente implementar las transformaciones necesarias y convertir los modelos definidos a modelos de diseño (por ejemplo, diagramas de clases) y posteriormente código. Con el objetivo de soportar nuestro enfoque, se desarrolló un plugin usando GMF (Graphical Modeling Framework). Dicho plugin permite modelar los distintos elementos para la gestión de la calidad de datos mediante diagramas de casos de uso y diagramas de actividades. El plugin se desarrolló para proporcionar un ambiente de trabajo adecuado que entre otras cosas, permitiera realizar diagramas de modelado con los elementos definidos. En la parte derecha de la herramienta (ver Figura 3), se puede observar un “toolbox” especial con los elementos definidos en el metamodelo “DQ_WebRE”. El ejemplo ilustrativo describe un proceso de negocios típico de una aplicación Web, que permite llevar a cabo la reserva y pago de entradas para conciertos y eventos. En este ejemplo, un analista podría modelar el correspondiente caso de uso “Realizar reserva de entradas” 36

.PRÁCTICAS

Figura 4. Diagrama de actividades con gestión de DQ.

usando los elementos propios del metamodelo (ver Figura 3). En este diagrama el analista incluye el caso de uso “Hacer reserva y pago de entradas” (de tipo InformationCase), el cual se puede relacionar con los requisitos específicos de DQ (Asegurar Confidencialidad de los datos, Garantizar Exactitud de datos respecto al formato, Verificar Completitud en datos introducidos y Confirmar la Credibilidad de los datos), indicando de esta forma que los datos gestionados por este tipo de caso de uso deberán cumplir dichos requisitos de DQ, los cuales deberían ser implementados en las etapas posteriores de diseño y programación de la aplicación Web. Haciendo uso de los elementos definidos en el metamodelo, es posible también realizar los correspondientes diagramas de actividad (ver Figura 4). En esta figura, el diagrama modela las actividades principales llevadas a cabo con el objetivo de describir de mejor manera el caso de uso “Realizar reservación de entradas”. El cliente primeramente debería ser capaz de ver los conciertos y eventos disponibles. Sin embargo, para poder realizar una reserva de entradas tendrá que registrarse o iniciar sesión en la aplicación Web. Una vez que se consigue el acceso a la aplicación, el cliente podrá seleccionar el evento y verificar la disponibilidad y el coste; si el cliente está de acuerdo con los datos, podrá hacer la reserva introduciendo los datos específicos para la reserva. Enseguida el cliente podrá realizar el pago de las entradas y el sistema le enviará las entradas de forma electrónica por email. En este diagrama de actividades, el analista será capaz de modelar las actividades específicas para cumplir con los requisitos de DQ, estas actividades estarán relacionadas a los distintos elementos propios del modelado de la aplicación Web. En este ejemplo ilustrativo, la actividad “Verificar y agregar metadatos de confidencialidad” será la responsable de cotejar y anexar dichos metadatos de confidencialidad, los cuales serán almacenados en una instancia de la clase “DQ_Metadata”, cumpliendo de esta manera con el requisito de DQ de “Asegurar Confidencialidad de datos”. En el diagrama también se observa la relación existente de los metadatos de Confidencialidad con los datos de la reservación.

La actividad “Verificar Exactitud de los datos”, será la responsable de agregar las funciones específicas (almacenadas en una instancia de la clase “DQ_Validator”) para verificar el requisito de DQ “Garantizar Exactitud de datos respecto al formato”, de los datos gestionados en la “Página Web de reservas” (del tipo WebUI). De manera similar, la actividad “Verificar Completitud de datos” estará encargada de agregar las funciones específicas para verificar la completitud de cada uno de los elementos gestionados dentro de la “Página Web de pagos” (tipo WebUI). Finalmente, la actividad “Verificar Credibilidad de datos” será la responsable de gestionar y agregar los metadatos de DQ (almacenados en una instancia de la clase “DQ_Metadata”), con el objetivo de garantizar el requisito de DQ de “Confirmar la Credibilidad de los datos”, el cual estará relacionado con los datos respectivos de Facturación (de tipo “Content”).

Conclusiones y trabajo futuro

Una correcta gestión de los requisitos de calidad de datos contribuye significativamente a eliminar o al menos minimizar posibles problemas con los datos, permitiendo a los usuarios de los sistemas de información efectuar sus operaciones con un mayor nivel de confianza. En este artículo se muestra una propuesta de solución basada en el enfoque de desarrollo dirigido por modelos, presentando un metamodelo ampliado (DQ_WebRE) para la gestión de requisitos de calidad de datos tomando como base el metamodelo (WebRE). Mediante la especificación de este metamodelo y haciendo uso del plugin desarrollado, es posible gestionar y modelar los aspectos clave de DQ desde la etapa inicial del proceso de desarrollo, lo que permitirá a los desarrolladores el tener conciencia de los requisitos de DQ. Como trabajo futuro se ha planificado la incorporación de mecanismos o reglas de transformación de modelos, mediante el lenguaje QVT (Query/View/Transformation). Esto permitirá obtener a partir de modelos de análisis distintos modelos de diseño y posteriormente la generación de código de forma semiautomática.

www.sg.com.mx |

Figura 3. Diagrama de casos de uso especificando requisitos de DQ.

Software Guru

Requerimientos

.PRÁCTICAS Procesos

El Papel de la Arquitectura de Software en ¿Cómo incorporarla?

Scrum

››Por Edwin Rafael Mago Vásquez y Germán Harvey Alférez Salinas

omo ustedes saben, Scrum es una metodología ágil para la gestión del desarrollo de software, que está basada en un proceso iterativo e incremental. Debido a la importancia de la arquitectura de software, es primordial definir claramente su papel en scrum. Es por esto que en el presente artículo se describe una propuesta del papel de la arquitectura de software en el ciclo de desarrollo de Scrum y de las responsabilidades del arquitecto de software en esta metodología.

La competitividad del mercado de desarrollo de software y la necesidad de los clientes de reducir el “time to market” obligan a las organizaciones de desarrollo de software a ser agresivas en sus calendarios de entrega. Esto ha hecho que hayan surgido metodologías de desarrollo de software ágiles tales como Scrum: una metodología para la gestión y desarrollo de software basada en un proceso iterativo e incremental. Su estructura está basada en sprints los cuales son iteraciones de 1 a 4 semanas. Scrum se usa en proyectos de entorno complejos, donde se desea obtener resultados rápidos y la productividad es lo más importante [1]. En los proyectos basados en Scrum se consideran tres roles: • Dueño del producto (Product Owner): Es quien determina .BIO las prioridades de los entregables. Edwin Rafael Mago Vásquez es Director de la Escuela de Informática del • Maestro de Scrum (Scrum Instituto Universitario Adventista de Venezuela (IUNAV). Es graduado de la Master): Administra y facilita la Maestría en Educación con Énfasis en ejecución del proceso. Educación Superior de la Universidad de Montemorelos, México. Actual• Equipo de Trabajo (Stakeholmente está cursando la Maestría en Ciencias Computacionales en esta ders): Trabajan en conjunto para universidad. ermago@cantv.net entregar resultados en cada sprint. Germán Harvey Alférez Salinas es Director del Centro de Investigación y Desarrollo de Tecnología (CIDET) de la Facultad de Ingeniería y Tecnología en la Universidad de Montemorelos, e investigador asociado en Asia-Pacific International University, Tailandia. Es graduado con honores del Master of Science in Information and Communication Technology en Assumption University, Tailandia. Sus áreas de interés incluyen software product lines, model driven development, y software architectures. http://fit.um.edu.mx/harvey

Como se puede observar, en medio de los participantes del proceso no quedan claras las responsabilidades del arquitecto de software. Sin embargo, como comenta Charlie Alfred, “la arquitectura es el aceite y el filtro que lubrica adecuadamente a Scrum” [2]. Si se compara el rol del ar-

quitecto de edificaciones con el del arquitecto de software, se puede observar que ambos modelan las construcciones a un alto nivel de abstracción, proveen posibles soluciones, mejoran la comunicación con los miembros del equipo de construcción a través de modelos, visualizan las generalidades del problema, definen los roles y las interacciones entre los componentes de construcción, entre otras tareas. Al igual que es imposible pensar que un rascacielos puede ser construido sin una arquitectura sólida, es imposible pensar que productos de software empresariales puedan ser implementados sin una arquitectura bien pensada. Según Bass, Clements y Kasman [3], “la arquitectura de software de un programa o sistema informático, es la estructura o estructuras del sistema, que incluyen elementos de software, las propiedades externamente visibles de esos elementos, y las relaciones entre ellos.” Esta definición nos lleva a concluir que la arquitectura de software garantiza el buen desarrollo del software y a tener un sistema que cumpla con los requerimientos funcionales y no funcionales del cliente. Además, la arquitectura es clave en la reutilización de artefactos de software en sistemas de líneas de productos de software. Viendo la importancia de la arquitectura en el desarrollo de software, en éste artículo se presenta una propuesta para gestionar la arquitectura de software en Scrum. En el primer capítulo se trata el tema de la localización de la arquitectura de software en el ciclo de desarrollo de Scrum; en el segundo capítulo se describen las tareas del arquitecto de software en Scrum; finalmente se presentan las conclusiones y el trabajo futuro.

Arquitectura de software en el ciclo de desarrollo de Scrum

La idea fundamental de la presente propuesta es adicionar un sprint inicial llamado “Sprint 0” al inicio del ciclo de desarrollo. El objetivo principal del arquitecto en el Sprint 0 es analizar y diseñar la generalidad del sistema, que satisfaga los requisitos y sea entendible por los miembros del equipo desde sus diferentes puntos de vista durante el desarrollo. Un punto clave, es reutilizar artefactos de software creados a partir de la arquitectura para ser más ágiles en el desarrollo de productos específicos. En la Figura 1 se puede observar que el Sprint 0 comprende tres fases que fueron tomadas del ciclo de vida de entregas evolutivas [3]. En el 38

Sprint 0 se construye la arquitectura de forma iterativa mediante un análisis preliminar de los conductores arquitectónicos (requisitos funcionales, de calidad y del negocio), y de un estudio de factibilidad del proyecto. No se necesita tener todos los requisitos claros para comenzar la fase de diseño arquitectónico. Para determinar los conductores arquitectónicos, se debe identificar los objetivos del negocio de más alta prioridad, que son pocos. Estos objetivos del negocio se convierten en los escenarios de calidad o casos de uso. De esta lista, se deben escoger los que tendrán un mayor impacto sobre la arquitectura.El diseño arquitectónico puede comenzar una vez que se encuentran definidos los conductores arquitectónicos. El proceso de análisis de requisitos será entonces influenciado por las preguntas generadas durante el diseño arquitectónico. El resultado del Sprint 0 es un documento inicial que explica la arquitectura. El documento puede basarse en los pasos definidos por el método ADD (Attribute Driven Design). Este método ha sido probado exitosamente en proyectos anteriores [4]. Con ADD se puede definir una arquitectura de software mediante un proceso de descomposición basado en los atributos de calidad del software. El documento inicial de la arquitectura se debe evaluar con el fin de saber si la arquitectura cumple con los requisitos de calidad. Para realizar esta evaluación, se propone el método ATAM (Architecture Tradeoff Analysis Method). El ATAM revela cuán bien una arquitectura satisface los objetivos particulares de calidad y provee una aproximación de cómo los objetivos de calidad interactúan.

.PRÁCTICAS Procesos

cada sprint. Los equipos de Scrum realizan construcciones cortas, guiados por las estrategias de la arquitectura. A continuación se nombran algunas de las responsabilidades del arquitecto de software desde el Sprint 1 en adelante: El dueño del producto y el maestro de Scrum trabajan con el arquitecto para priorizar los requisitos a implementar en cada iteración. El arquitecto comunica las decisiones y facilita las conversaciones arquitectónicas de distintos puntos de vista en cada sprint. El arquitecto asegura que haya conformidad entre las entregas en cada sprint y la arquitectura. El arquitecto responde preguntas y da orientación arquitectónica cuando sea necesario. Junto con el maestro de Scrum, coordina a los miembros del equipo para adaptarse a la arquitectura prevista. El arquitecto junto con el dueño del producto y los miembros del equipo preparan el Product Backlog.

Conclusión y trabajo futuro Figura 1. Propuesta de gestión de la arquitectura de software en Scrum.

Si en la evaluación de la arquitectura se encuentra que se deben realizar cambios a la misma, entonces ésta se debe refinar hasta llegar a tener como resultado del Sprint 0 el documento pulido de la arquitectura junto con el sistema esqueleto. Finalmente, la arquitectura creada en el Sprint 0 beneficiará el desarrollo en los siguientes sprints.

Rol del arquitecto de software en Scrum

El rol y actividades del arquitecto de software cambia de enfoque dependiendo de si se está en el Sprint 0, o en sprints subsecuentes. Sprint 0. En sistemas complejos, una persona difícilmente puede cubrir con amplitud técnica las decisiones arquitectónicas y dar credibilidad a la arquitectura de software [5]. Esto quiere decir que la participación del equipo es de vital importancia para la creación y el mantenimiento de la arquitectura. Un equipo de arquitectos de software que se aísle del equipo de Scrum, puede producir una arquitectura que corra el riesgo de ser rechazada. Es por esto que recomendamos que el arquitecto o los arquitectos de software sean miembros del equipo de Scrum. Una de las actividades que se debe realizar en equipo es la evaluación de la arquitectura. Específicamente, en el método ATAM se requiere la participación mutua de tres equipos que trabajan en conjunto con los arquitectos de software: el de evaluación, el de tomadores de decisiones del proyecto, y el de los involucrados en la arquitectura.

La arquitectura de software y Scrum no se repelen, más bien se complementan. El arquitecto describe las tácticas que se deben seguir para cumplir con los requisitos de calidad del sistema, teniendo clara la imagen global de éste. Además, permite que los artefactos a construir se reutilicen con el fin de reducir el tiempo de desarrollo y mejorar la calidad del producto. En el presente artículo ofrecimos una propuesta para incluir la arquitectura de software en Scrum. En el Sprint 0 se realizan las actividades concernientes al análisis y diseño de la arquitectura de software, y el sistema esqueleto. En los siguientes sprints el arquitecto de software se asegura de que la implementación cumpla con la arquitectura. En un futuro proyecto implementaremos la presente propuesta en una línea de productos de software.

Referencias [1] O. Soto & G.H. Alférez. “Scrum, ¿Un Paradigma de Administración de Proyectos que Cumple lo que Promete?” Software Guru, Agosto 2009. http://bit.ly/sg30r3 [2] C. Alfred. “Scrum and Architecture Partners or Adversaries”. http://bit.ly/sg30r4 [3] L. Bass, P. Clements, & R. Kasman. Software Architecture in Practice. Addison Wesley, 2da ed., 2003. [4] O. Soto & G.H. Alférez. “An Architecture Proposal for Academic Software in Adventist Universities”. Catalyst, Asia-Pacific International University, Vol. 4, num. 1. http://bit.ly/sg30r5

Sprints subsecuentes. El arquitecto de software asegura que el equipo de Scrum entienda el enfoque y los retos arquitectónicos más importantes en

[5] R. Malan & D. Bredemeyer. “Architecture Teams”. http://bit.ly/sg30r6 [6] R. Sullivan. “Scrum and Architecture”. http://bit.ly/sg30r7

.PRÁCTICAS Arquitectura

Documentación de Arquitectura

conceptos y enfoques

››Por Humberto Cervantes y Edith Valencia

n entregas previas de esta sección, nos hemos enfocado en aspectos relativos a los requerimientos que influyen a la arquitectura, y a la manera de diseñar la arquitectura con el fin de satisfacer estos requerimientos. Para ser útil, este diseño necesita ser comunicado de forma adecuada. Así que en esta ocasión abordamos aspectos de comunicación del diseño y más particularmente en la actividad de documentación de la arquitectura. La documentación del diseño de la arquitectura de software cumple varios propósitos importantes. Entre ellos están: • Comunicar a los distintos involucrados el diseño y las decisiones que permitieron llegar a éste. • Permitir realizar análisis y evaluación del diseño. • Soportar las actividades de mantenimiento. ¿Cómo se documenta el diseño arquitectural? Para contestar esto, primero recordemos que hemos definido la arquitectura de software como un conjunto de estructuras compuestas por elementos con propiedades y relaciones entre ellos. Entonces, para documentar un diseño arquitectural requerimos poder representar estas distintas estructuras. De manera similar a lo que se hace en la construcción, en donde se tienen distintos planos para un mismo edificio, las estructuras del diseño arquitectural se documentan .BIO de forma separada a través de distintas El Dr. Humberto Cervantes es profesor-investigador en la UAM-Izvistas. Cada vista modela una parte del tapalapa. Ha realizado investigación en temas relacionados con arquitecdiseño arquitectural desde distintas tura de software desde el año 2000 perspectivas que pueden ser por ejemy en años recientes se ha enfocado en el estudio y la aplicación de plo dinámicas, lógicas o físicas. métodos que apoyen al desarrollo de arquitectura de software dentro de la industria Mexicana. www. humbertocervantes.net La MSc. Edith Valencia es arquitecto de software en la empresa QuarkSoft S.C. Cuenta con más de 10 años de experiencia profesional y obtuvo la maestría con honores en Ingeniería de Software en la Universidad de York en El Reino Unido. Sus áreas de interés incluyen arquitecturas de software, ingeniería de procesos de software y metodologías ágiles. evalencia@ quarksoft.net

Referencias: [1] Kruchten Philippe, “Architectural Blueprints—The “4+1” View Model of Software Architecture”, IEEE Software 12, 1995 [2] IEEE Computer Society, “IEEE Recommended Practice for Architectural Description of Software-Intensive Systems”, IEEE Std 1471-2000, 2000 [3] Clements P. et al. Documenting Software Architectures, Views and Beyond. Addison Wesley, 2003

El concepto de vista

La documentación de una vista normalmente incluye una representación gráfica (es decir un diagrama) de la estructura que se está modelando. Aunque existe libertad con respecto a la notación usada, lo más común y conveniente es usar UML. Contar con diagramas que representan una estructura indispensable, pero generalmente no es suficiente para poder comunicar el diseño de forma adecuada. Así que al documentar una vista, conviene acompañar al diagrama de información adicional donde se expliquen decisiones de diseño, además de brindar mayor detalle sobre los elementos mostrados en el diagrama y las relaciones entre estos.

Cabe señalar además que puede ser necesario dividir el diagrama si la estructura es muy compleja. En ese caso, cada parte de la estructura se documenta como una vista individual y se incluye un diagrama de contexto que permite comprender la ubicación de la estructura dentro del sistema completo.

Enfoques de documentación

Es conveniente usar un enfoque preestablecido que sirve de guía en la elección y organización de las vistas. Estos son algunos enfoques populares: 4+1 Views. El enfoque (o modelo) 4+1 vistas es muy popular, particularmente porque está asociado al proceso de desarrollo RUP. Este modelo propone que se usen 5 vistas: • Vista lógica. Modela elementos que soportan la funcionalidad que el sistema provee al usuario final de un punto de vista estático o dinámico mediante diagramas tales como clases, paquetes y secuencia. • Vista de proceso. Esta vista opcional modela los aspectos dinámicos del sistema y captura aspectos tales como concurrencia y sincronización mediante diagramas tales como el de actividades. • Vista de desarrollo. Modela la organización estática del software en su ambiente de desarrollo, típicamente mediante diagramas de componentes. • Vista física. Modela el mapeo del software con el hardware, típicamente con diagramas de implantación. • Vista de casos de uso. Esta es la vista adicional (+1) que es central al modelo y que agrupa escenarios de casos de uso principales. Para su representación se puede usar un diagrama de casos de uso acompañado de descripciones textuales de los escenarios. Las otras vistas deben permitir comprender la manera en que los escenarios de casos de uso son soportados por la arquitectura. IEEE 1471. Es un estándar de la IEEE para la descripción arquitectural de sistemas intensivos de software. IEEE 1471 define un marco conceptual que relaciona los conceptos de sistema, descripción arquitectural y vista. En éste marco, las vistas se deben ajustar a un viewpoint (punto de vista), el cual especifica las convenciones para construir y usar una vista, e incluye elementos tales como los lenguajes que pueden ser usados para describir la vista así como los métodos de modelado y las técnicas de análisis que pueden ser aplicados a las representaciones de la vista. En IEEE 1471, una descripción arquitectural incluye uno o más viewpoints, los cuales se seleccionan con base en los involucrados hacia los cuales está dirigida la arquitectura. Views and Beyond. Este enfoque, desarrollado por el SEI, establece que la documentación de una arquitectura de software involucra la elección de las vistas relevantes de la arquitectura, la documentación de cada una de esas vistas, así como la documentación de la información que aplica a más de una vista o a un conjunto de vistas en su totalidad. Los detalles del enfoque incluyen el método para elegir las vistas más relevantes para los 42

.PRÁCTICAS

Arquitectura involucrados de la arquitectura, plantillas estándar para documentar las vistas, información necesaria para documentar información que aplica a través de varias vistas, así como definiciones del contenido de las plantillas. A diferencia del enfoque 4+1 vistas, Views and Beyond no especifica el número de vistas a usar.

Ejemplo

Apliquemos el modelo 4+1 vistas al ejemplo que hemos venido desarrollando en artículos anteriores de esta sección. Recordando, el ejemplo hacía referencia a la “compañía xyz que se dedica a la comercialización de productos de diversos fabricantes”. Vista de casos de uso. La vista de casos de uso incluiría un diagrama con los casos de uso primarios junto con descripciones de estos escenarios. Uno de los escenarios que debería incluir esta vista es el flujo principal del caso de uso primario “Realizar consultas del catálogo de productos”. Vista lógica. La vista lógica (ver Figura 1) presenta los módulos para llevar a cabo las consultas al catálogo de productos, como son “consulta de productos” y “administrador de búsquedas”, además de los módulos necesarios para comprar productos específicos como son “carro de com-

pras”, “pagos” y “administrador de compras”. Cabe señalar que el diagrama presentado muestra un segundo nivel de descomposición del sistema. Un tercer nivel de descomposición requeriría tomar los diferentes módulos y descomponerlos en componentes asociados a las tecnologías específicas utilizadas en el sistema. De un punto de vista dinámico, la realización del caso de uso “Realizar consultas del catálogo de productos” se aprecia en la Figura 2. Esta representación supone que se ha realizado una descomposición del sistema, de la cual surgieron los componentes especificados en el diagrama de secuencia, y supone además que se eligieron las tecnologías JSF para la capa de presentación y Spring Webservices para la capa de integración. Vista física. La vista física muestra mediante un diagrama de implantación (deployment) de UML, la terminal por medio de la cual se va a utilizar el sistema, el servidor de aplicaciones en el que van a estar instaladas las capas de la aplicación: vista, negocio e integración, y sistemas en servidores externos a través de los cuales nuestro sistema va a obtener información. Otras vistas. De forma similar sería necesario incluir la vista de desarrollo. La vista de proceso no es necesaria en éste ejemplo debido a que el sistema no requiere representar elementos de concurrencia o sincronización.

Conclusión

www.sg.com.mx |

Software Guru

La documentación de la arquitectura es una actividad fundamental para poder realizar una comunicación adecuada del diseño. Es importante recalcar que no existen criterios precisos que permitan determinar el grado exacto de documentación que se debe realizar, y esto se debe determinar considerando diversos aspectos que incluyen a los involucrados, el tipo de proyecto y la experiencia del equipo de desarrollo.

Figura 1. Diagrama de paquetes asociado al caso de uso de consulta de catálogo de productos.

Figura 2. Diagrama de secuencia asociado al caso de uso de consulta de catálogo de producto.

Figura 3. Figura 3. Diagrama de implantación general al sistema.

.PRÁCTICAS Agilidad

Análisis de Distintos Contextos de Prueba

¿existe la “mejor” forma de probar?

››Por Juan Gabardini

s tentador pensar que siempre hay una “mejor manera” de hacer las cosas. Alguna vez pensé conocer “la mejor manera” de probar software. Luego aprendí o cambié de contexto, y “la mejor manera” cambió. A partir de entonces soy algo escéptico cuando me encuentro con una “mejor manera”. Esta nueva “mejor manera”, ¿que problemas viejos resuelve? ¿que problemas nuevos crea? ¿en qué contexto está siendo usada? En este artículo comparto mi experiencia personal con diferentes formas y contextos de prueba, analizando los problemas comunes y cultura, y también si ese contexto es un estado final o sólo un paso hacia otro estado. Este texto se basa en la presentación que realicé en el congreso Ágiles 2010 en Lima, que pueden ver en http://bit.ly/b9bIrT Aclaro que no trato el problema más general de la calidad de software, sino solamente sobre la prueba.

El modelo

La estructura de este artículo está organizada en base al modelo de prueba comentado en el libro “Agile testing”, de Lisa Crispin y Janet Gregory (ver figura 1). En este modelo, tenemos 4 tipos de prueba: • Pruebas manuales. • Pruebas de interfase usuaria o UI (automatizada). • Pruebas de aceptación (automatizada). • Pruebas técnicas o unitarias y de componentes (automatizada). El costo de ejecución es menor en las pruebas técnicas y va creciendo hasta el máximo costo, que es la ejecución de pruebas manuales. El costo de mantenimiento de las pruebas automáticas también es creciente, desde el mínimo en las pruebas técnicas, hasta el máximo en las pruebas de UI. El mantenimiento de las pruebas manuales es equivalente o menor que el caso de pruebas técnicas automatizadas. En todos los casos, el costo y mantenimiento de las pruebas automatizadas requiere una inversión importante en experiencia e infraestructura. Pero esa inversión se puede llevar en muchos casos de un proyecto a otro. Los costos consideran esa inversión amortizada o distribuida en gran cantidad de pruebas. La relación entre los costos lleva a sugerir que la forma más eficiente de dedicar esfuerzo tiene la forma de una pirámide, con las pruebas técnicas (unitarias y de componentes) en la base, las de aceptación (o API) luego, y finalmente las pruebas de UI en el vértice de la pirámide. .BIO

Juan Gabardini participa en equipos como tester y ayudando a incorporar el desarrollo ágil de software. Participa también en la organización de los eventos latinoamericanos Ágiles 20xx y Agile Open Tour. Es Ingeniero Electrónico egresado de FIUBA, miembro del IEEE, SADIO, Scrum Alliance, Agile Alliance, Agilar Argentina y Jefe de Trabajos Prácticos en FIUBA. Cuenta con más de 10 años de docencia universitaria y más de 20 años de experiencia en desarrollo de software, enseñanza y consultoría.

Figura 1. Distintos tipos de prueba.

Contexto: Prueba ad-hoc

Durante los primeros años de mi carrera trabajé en grupos de 5 personas o menos, realizando desarrollos a la medida para áreas muy distintas. En estos equipos no había clara separación de roles, todos hacíamos un poco de todo. En particular, las pruebas las hacíamos entre todos, intercambiábamos roles probando la funcionalidad realizada por otro. La prueba final la hacían los jefes, usuarios o, si existían, las personas de servicio a cliente. Al no haber responsables claros, la prueba suele quedar huérfana, sin mejora. Aparecen problemas con las tareas poco atractivas y complejas, como realizar pruebas de regresión. La evolución de este contexto suele ser incorporar un tester o área de testing para prueba manual (camino tradicional) o que los programadores empiecen a desarrollar pruebas técnicas o incluso test driven development (camino del desarrollo ágil). Motto: Problemas: Cobertura: Responsable: Organización:

¡No vale la pena probar! Baja calidad, baja previsibilidad, regresiones No hay métricas Todos y ninguno. Pruebas por el usuario Generalmente chicas y con poca estructura

Contexto: Prueba manual

En mi siguiente reencarnación estuve 8 años en una compañía que se dedicaba a ayudar a empresas de contexto Ad hoc a madurar su práctica de prueba. Este cambio cultural es difícil, y con riesgo de involuciones. Por eso se busca separar en un grupo más o menos autónomo a los responsables de probar. La separación y la función de probar, que a veces se desvirtúa como prueba de programador en vez de prueba del producto, provoca enfrentamientos y fricciones con los programadores. El diseño de las pruebas es divertido, pero ejecutarlas una y otra vez es terriblemente aburrido, lo que lleva a que pocas personas quieran quedarse mucho tiempo haciendo esto. Resultado: muchas personas capaces se van a otras áreas, más divertidas (como desarrollo), lo que produce mucho recambio y mayoría de novatos en los roles de prueba. El problema es que la prueba de regresión de productos medianos y grandes, se hace muy costosa, lo que lleva a ciclos de desarrollo muy largos (para minimizar las pruebas de regresión) o disminución de las pruebas realizadas durante la regresión (lo que lleva a baja calidad). La solución sería la automatización, pero no es sencilla, ya que las personas en el grupo de prueba no tienen conocimientos técnicos, y la relación con el grupo de programación, que puede aportar el conocimiento técnico, no es la mejor. Motto: Problemas: Cobertura: Responsable: Organización: Prácticas:

¡No vale la pena automatizar las pruebas! Costo de ejecución, que a su vez lleva a seleccionar las pruebas, que baja la confianza y lleva a pocos releases Requerimientos, casos de uso Testers / QA Testing separado Casos de prueba manuales, checklist 44

.PRÁCTICAS Agilidad

Motto: No podemos mejorar la producción del código. Problemas: Mantenimiento de las pruebas Cobertura: Requerimientos, riesgos Responsable: Testers, Testers automatizadores, QA Organización: Organizaciones grandes, grupos separados Prácticas: Pruebas automatizadas de UI

Contexto: Prueba técnica

Algunos equipos en los que trabajé tenían la cultura de calidad incorporada con fuerte influencia de XP, por ejemplo con prácticas de integración continua, TDD y pair programming incorporadas (en mayor o menor medida). En estos equipos la calidad es alta comparada con los contextos de prueba manual. Se suele utilizar cobertura de código como métrica relevante. Los problemas que suelen presentarse son el mantener el tiempo total de ejecución de las pruebas bajo (<10 min), y que nuestro producto pase todas las pruebas (en este contexto, significa pruebas unitarias automatizadas), pero no es aceptado por el usuario. Las funcionalidades requieren siempre al menos dos iteraciones para ser aprobadas y el grupo se desmotiva por los cambios de UI y de requerimientos que parecen llegar siempre tarde, y siempre hay uno más. Motto: Problemas: Cobertura: Responsable: Organización: Prácticas:

Sólo vale la pena las pruebas automatizadas Usabilidad y regresiones en cuanto a requerimientos Líneas de código Programador. Equipo de programadores TDD (Test Driven Development), CI (Continuous Integration)

Contexto: Prueba técnica++

Los equipos en este contexto son equipos que vienen de la prueba técnica (agregando prueba de APIs y quizás de UI) o de la prueba manual optimizada (agregando prueba unitaria y quizás de API). En ambos casos, tienen desbalanceada la pirámide de prueba. En el caso de los que vienen desde prueba manual optimizada, puede ocurrir que pierdan la prueba manual o la prueba de UI automatizada, dado que el esfuerzo por incorporar pruebas unitarias es grande, y se detecta duplicación de esfuerzo entre las pruebas existentes (manuales o automáticas a nivel UI). Luego de lograr el balance en la pruebas automatizadas, el problema remanente son las pruebas de difícil automatización y la falta de prueba

Motto: Sólo valen la pena las pruebas automatizadas Problemas: Usabilidad, requerimientos no funcionales Cobertura: Líneas de código y requerimientos Responsable: Usuario y programador Organización: Equipo de programadores Prácticas: ATDD (Acceptance Test Driven Development), BDD (Behavior Driven Development), TDD, CI

Contexto: Nirvana

Estos equipos han incorporado todas las prácticas de XP. Están en continuo aprendizaje sobre como complementar los distintos tipos de pruebas, la automatización a diferentes niveles y la exploración, para lograr la combinación óptima. Están en un equilibrio dinámico, siempre cambiante, atentos a cambios en el negocio, el producto y las tecnologías. Se preocupan por la cadena de valor completa. Motto: Problemas: Cobertura: Responsable: Organización: Prácticas:

Optimizamos el todo Buscar el balance óptimo Líneas de código y requerimientos, riesgos Equipo completo (whole team) Lean ATDD, BDD, TDD, CI

Re-visitando

Las descripciones dadas en cada contexto plantean la visión que tenía de lo ‘correcto’ cuando estuve en ellos. Mirando ahora hacia atrás, tengo una visión distinta. Comparto mis reflexiones: Ad hoc. ¿Qué pasa cuando la solución implica poco o nada de programación en el sentido estricto, sino más bien configurar soluciones existentes o crear contenido? En algunas situaciones, la prueba Ad hoc podría ser lo mejor: ej. desarrollo de sitios sencillos usando un CMS. Prueba Manual y Prueba Manual Optimizada. Cuando hay en juego mucho dinero o vidas, queremos redundancia. Podemos pagar prubas manuales para lograr independencia (dos grupos, con dos técnicas distintas). Por otra parte, hay que recordar que el producto a probar no es sólo software: puede ser factible automatizar parte de la prueba (correspondiente al software) y realizar el resto en forma manual, por ejemplo: CMS complejos, en los que no solo se desarrolla contenido, sino también extensiones o aplicaciones; productos en los que el software acompaña al texto, y probablemente el texto sea lo más importante, como tutoriales; soluciones que incluyan actividades manuales realizadas por humanos.

Conclusiones

Las metodologías ágiles han logrado una mejora muy importante en la calidad lograda en los desarrollos. Es tentador aplicar siempre las técnicas y prácticas que han permitido estas mejoras, y es tentador pensar que nuestros problemas se resuelven con más y mejor aplicación de las mismas. Por otro lado, he hecho críticas a algunas prácticas (como el (ab)uso de métricas de cobertura de código), para luego encontrar que personas a las que respeto encuentran estas críticas inconvenientes. Estos contextos me han ayudado a aclarar las discusiones sobre la conveniencia de la utilización o no de las distintas prácticas. Espero que pueda ayudar a otros. ¿Tú que opinas? 45

Software Guru

Luego de 6 años en prueba manual reencarné en prueba manual optimizada, porque un cliente exigió en un proyecto que automatizaramos. Con gran esfuerzo se mantiene un conjunto de pruebas automatizadas, que permiten tener regresiones en forma rápida. El ahorro en tiempo y esfuerzo es grande, pero por otro lado, debido a la separación entre los grupos de programación y los de prueba, es frecuente que cambios realizados en forma inconsulta en el producto rompan las pruebas automatizadas. Por eso, y por el hecho de que estas pruebas suelen ser de caja negra a través de la UI, el costo de mantenimiento de las pruebas automatizadas es alto. Es una situación extraña, ya que en muchos casos nos damos cuenta que se podría ser mucho más eficiente si algunas pruebas se hicieran por caja blanca, por los programadores, o si los testers pudieran participar en la toma de decisiones sobre cambios al producto.

exploratoria. Esto último puede llevar a productos que son correctos desde el punto de vista funcional, pero que no son sobresalientes.

www.sg.com.mx |

Contexto: Prueba manual optimizada

.COLUMNA Prueba de Software

El Estado del

Arte y la Prueba de Software

cómo el presente y el futuro podrían

confluir

Luis Vinicio: Esta entrega es especial para mí en dos sentidos: por un lado este tema es de gran interés para mí, y por otra parte, esta será la última vez que escriba como responsable de esta columna, la cual quedará en manos de Berenice, a quien le doy la bienvenida y le deseo que disfrute esta actividad.

Luis Vinicio León Carrillo es actualmente Director General de eQuallity, empresa especializada en prueba de software, de la que es co-fundador. Fue profesor-investigador en el ITESO durante varios lustros, que incluyeron una estancia de posgrado en prueba de software en Alemania, en la que abordó aspectos formales de esa disciplina. Fue co-fundador del Capítulo Jalisco de la AMCIS.

Sandra Berenice Ruiz Eguino es consultora de e-Quallity en proyectos de mejora de organizaciones de prueba de software. A lo largo de su trayectoria profesional ha actuado también como Ingeniero de Pruebas Senior, Líder y Administradora de Proyectos de pruebas nacionales e internacionales, y Directora de Operaciones. Fue profesora de la Universidad Autónoma de Guadalajara, institución en la que realizó sus estudios de Maestría en Ciencias Computacionales.

n el ámbito del desarrollo de software, el estado del arte (state of the art) típicamente ha estado vinculado con la evolución de los lenguajes de computación. Uno de los primeros grandes saltos en esa dirección fue el desarrollo del primer lenguaje de alto nivel, FORTRAN. En sus inicios, el desarrollo de software en ese lenguaje era considerado “programación automática” porque requería menos conocimientos técnicos que los lenguajes ensambladores. Los detractores (gurús que programaban en lenguaje ensamblador) solían justificar su rechazo mostrando que los programas en FORTRAN eran significativamente más ineficientes comparados con los que ellos escribían. Hoy no solo tenemos lenguajes de programación de alto nivel, de “cuarta” y de “quinta generación”, funcionales u orientados a objetos; también lenguajes de documentación (Latex, HTML, etc.), de especificación (bison, flex, etc.), y otros. Sin embargo, estos lenguajes hoy representan más bien lo que suele llamarse el “state of practice”: lo que incorporan las herramientas comerciales y que utiliza la industria. Una de las vertientes del “state of the art” tiene que ver con lo que denominamos “métodos formales” (MF). En términos generales, los MF son técnicas mediante las cuales: 1. Se escribe la especificación del sistema a desarrollar utilizando un lenguaje formal L1 (usualmente del paradigma declarativo), que luego es verificada con intervención humana y procesada mediante un compilador C1 para así generar el código en otro lenguaje formal L2 que representa un diseño de alto nivel. 2. Este diseño escrito en el lenguaje L2 a su vez es verificado con intervención humana y procesado mediante un compilador C2 que genera el código en otro lenguaje formal L3 (usualmente del paradigma imperativo). 3. Este código en el lenguaje L3 se procesa mediante un compilador C3 para obtener finalmente el sistema ejecutable. Las verificaciones mencionadas suelen ser demostraciones matemáticas de que el código actual Cn tiene ciertas propiedades.

En realidad, en el desarrollo de software siempre utilizamos un tipo de MF, pues finalmente se escribe el sistema en algún lenguaje Lx, que es procesado por un compilador Cx, el cual usualmente genera código ejecutable. Sin embargo, esta transformación suele realizarse solamente para la fase final de las arriba descritas (la generación del sistema ejecutable a partir del programa escrito en un lenguaje de programación, usualmente imperativo), no para todo el ciclo de desarrollo (requerimientos-diseño-programación). Los MF abordan el ciclo completo. Algunos de los métodos formales más conocidos son el “Método B” y la “Notación Z”.

Ejemplo de un método formal

Muchos de ustedes, estimados lectores, habrán llevado algún curso de construcción de compiladores durante su carrera. Recordarán que un compilador contiene 4 grandes bloques: 1. El analizador léxico, que se encarga de concatenar caracteres significativos para construir “palabras”. 2. El analizador sintáctico, que verifica que esas “palabras” formen “oraciones” con un orden que es permitido. 3. El procesador semántico, que checa que esas “oraciones” tengan significado. 4. El generador de código, que finalmente transforma el programa escrito en el lenguaje fuente en otro documento escrito en el lenguaje destino. Probablemente también recuerden que el analizador sintáctico o “parser” suele definirse mediante una gramática, usualmente utilizando alguna nomenclatura especializada como los grafos de sintaxis (GS). Hay un tipo de gramáticas (las descendentes predictivas) para las cuales es relativamente fácil la escritura del parser que las procesen, pero tienen ciertas restricciones; en particular: • la definición no puede tener recursión izquierda (el procesamiento se ciclaría indefinidamente), • en una alternación de grafos, no puede ocurrir que un par de ellos comience con la misma cadena (siempre tomaría la primer alternativa). 46

.COLUMNA

Prueba de Software

“Uno de los mitos de

Utilizando el MF para desarrollar ese componente de un compilador, nuestra actividad se centra más en el diseño de una gramática que tenga características deseables, que en la escritura de un programa que la procese. Para lograrlo fue necesario conocer el lenguaje de especificación (los GS), y las características que deben tener las gramáticas (v.gr. no recursión izquierda). Ese es el enfoque usual en los MF.

Aplicación de los métodos formales en la industria

El uso de los MF en el desarrollo de sistemas críticos no es poco común. En el artículo “Software’s Chronic Crisis” [1] pueden encontrarse algunos casos clásicos, entre ellos el uso del método formal “B” para desarrollar un sistema que solucionaba el siguiente problema del metro en París: La cantidad de usuarios de las líneas del metro se había incrementado considerablemente, de manera que era necesario construir más vías para que circularan más trenes, o bien automatizar la sincronización de las llegadas y salidas de las líneas a cada estación, de manera que se redujera el tiempo entre la partida de un convoy y la llegada de otro. Esta automatización es un buen ejemplo de un sistema crítico: si el software fallara al sincronizar llegadas y salidas, podría ocurrir que sobre la misma vía arribara un convoy en una dirección al tiempo que llegara otro en la dirección opuesta, ocasionando una colisión en la que podría morir mucha gente. Obviamente, ante esa posibilidad no es aceptable un sistema con digamos 99.99999% de confiabilidad (que puede fallar una vez en

Algunos mitos sobre los MF

Uno de los mitos de los MF es que son difíciles de aprender. En realidad, la dificultad para aprenderlos solamente radica en que son un tanto “diferentes” de lo usual, pero finalmente están basados en lenguajes formales, y los podemos aprender como aprendemos los de programación (finalmente, lo aprendimos también en nuestro curso de Compiladores). Otro mito más es que poca gente los conoce, y que no son enseñados en las universidades. Este, junto con el anterior, genera un círculo vicioso que se romperá cuando uno de ellos sea descartado. En buena medida gracias a estos prejuicios (y otros más), y a que no se tienen métodos formales genéricos e integrados, esta técnica no ha proliferado en proporción a su potencial. Sin embargo, cada vez más elementos de los incluidos en ellos se han venido introduciendo en muchos ambientes de programación.

Los métodos formales y la prueba de software

Este paradigma cambia tanto la actividad de la programación de sistemas, como la de la prueba de los mismos: el desarrollo tiene que ver menos con escribir código e incluye más tareas de verificación (detección de errores “de alto nivel”), que actualmente se incluyen en las actividades de pruebas. En ese sentido, ambas actividades parecieran confluir. Sin embargo, aún en ese escenario, será necesario probar para revisar por un lado si el sistema desarrollado cumple con los requerimientos del usuario (aspecto que no puede validar el método formal), y por otro si no se cometieron errores durante las verificaciones. Además, hoy en día tenemos tecnologías que interactúan cada vez más con otras, y la integración de sistemas de sistemas es algo que también debe ser probado. Las pruebas serían pues también necesarias, aunque con variaciones significativas.

>> Por Luis Vinicio León Carrillo

Referencias: [1] W. Gibbs; “Software’s Chronic Crisis”, Scientific American, September 1994. http://bit.ly/sg30r1

Software Guru

Las reglas para construir un parser descendente predictivo son relativamente sencillas y pueden ser automatizadas para generarlos en pseudocódigo; por razones de espacio, nos ahorraremos su definición aquí. Con esa automatización tendríamos un pequeño MF: 1. Escribiríamos la especificación del parser a desarrollar utilizando el lenguaje formal de los grafos de sintaxis, que sería verificada por un compilador de GS para detectar, entre otras cosas, recursión izquierda y/o alternaciones de GS no permitidas; en caso de haberlas, la especificación sería corregida con intervención humana. Una vez corregida y verificada, el compilador de GS podría generar el “diseño” del parser en pseudocódigo, como lenguaje intermedio. 2. Este “diseño” a su vez sería procesado mediante un compilador de pseudocódigo que generaría el programa P en algún lenguaje de alto nivel, a elección del usuario (v.gr. Java, LISP). 3. El programa P sería procesado por el compilador correspondiente y generaría el código ejecutable.

diez millones). En lugar de ello se utilizó el MF B para “desarrollar software libre de defectos por construcción”: se escribió una especificación formal que fue verificada matemáticamente, a partir de la cual se generó un diseño que fue igualmente verificado, para de ahí generarse el código fuente del que se obtuvo luego el sistema ejecutable.

www.sg.com.mx |

los métodos formales es que son difíciles de aprender.”

.COLUMNA Programar es un Estilo de Vida

Los Muchos Significados del

“cómputo en la nube”

desmitificando el concepto

no de los términos ampliamente en boga en nuestro campo hoy en día es el “cómputo en la nube”. Tan en boga que me parece que se ha convertido en una palabra mágica, bastante hueca y sintomática de querer parecer en sintonía con los últimos desarrollos tecnológicos, sin comprenderlos en realidad. Además, al ser una frase que de golpe comenzó a escucharse con tanta insistencia, asumimos que es una estrategia nueva, una idea posibilitada por los nuevos avances tecnológicos — Y esto dista de ser el caso. En esta columna busco clarificar los conceptos y tipos básicos de cómputo en la nube, sus principales ventjas y desventajas, y brevemente encontrar paralelos con casos documentados de estos ”novedosos” conceptos. No critico, ojo, a las estrategias que están detrás de este sonoro término — Muy por el contrario, resultan muy convenientes a la hora de implementar, y como profesionales del desarrollo de software tenemos la obligación de estar familiarizados con ellas. Lo que critico es el abuso de un término ambíguo, que suele poner en problemas a los implementadores, al no estar claramente comprendido. La mayor parte de las referencias que consulté mencionan a tres capas o niveles principales: El software –o la aplicación– como un servicio (Software as a Service, SaaS), la plataforma como un servicio (Platform as a Service, PaaS) y la infraestructura o el hardware como un servicio (Infrastructure as a Service, IaaS). Mi punto de vista, es que más que un nivel distinto, IaaS es un conjunto de cualidades adicionales que dan valor agregado a una oferta de PaaS.

SaaS: Bloques de construcción

Gunnar Wolf es administrador de sistemas para el Instituto de Investigaciones Económicas de la UNAM y desarrollador del proyecto Debian GNU/Linux. www.gwolf.org

Cuando uno de nuestros sistemas utiliza un API público remoto, o cuando para nuestro flujo de trabajo empleamos a una aplicación que reside y es administrada fuera de nuestra organización, estamos empleando SaaS. Nuestro proveedor puede cobrar su servicio de diversas maneras: a través de una renta directa, requiriendo del despliegue de publicidad, recibiendo autorización para recolectar nuestra información y hacer minería de datos sobre de ella — Hay una enorme variedad de esquemas, que refleja la gran variedad de niveles de integración que se puede dar a los servicios. Notarán que la principal diferencia con los esquemas tradicionales cliente-servidor con que hemos trabajado

desde hace décadas es el uso explícito de un proveedor externo — Sin embargo, técnicamente, nuestros sistemas no seguirán una lógica o un proceso de desarrollo diferente de como lo vienen haciendo por décadas. Al mismo tiempo, sí hay una importante diferencia: Al no controlar nosotros el proceso que ocurre dentro de uno de nuestros subsistemas, nos vemos forzados a hacer bien lo que ya deberíamos estar haciendo: Implementar una separación limpia de responsabilidades entre los componentes, utilizando exclusivamente las interfaces publicadas explícitamente — No brincarnos las capas de abstracción, como muchas veces estaríamos tentados a hacerlo en un desarrollo interno. Hay algo que no podemos perder de vista cuando empleamos un servicio de aplicaciones como parte de nuestra infraestructura en sistemas: Al depender de un tercero, ponemos en sus manos parte importante de nuestras promesas (y, por tanto, requerimientos), en tanto a disponibilidad, protección de datos y continuidad de la operación. Respecto a la disponibilidad, resulta natural que una falla en el servicio de cualquiera de nuestros proveedores de aplicaciones llevará a que nuestro sistema presente información incompleta o errónea a sus usuarios. En cuanto a la proteción de datos, no sólo debemos tener en cuenta las implicaciones directas (el proveedor tendrá acceso a todos los datos específicos que le enviemos para operar), sino también las indirectas: todo ataque por medio del cual un agente hostil pueda llevar a cabo recolección de información sobre de nuestros proveedores resultará en la probable divulgación de información interna nuestra, e incluso el mismo proveedor puede estar realizando un seguimiento estadístico de nuestros patrones de uso, revelando mucho más de lo que podríamos querer darle. En tanto a la continuidad de operación, si el proveedor del servicio decide cambiar los términos bajo los cuales brinda sus recursos, o si sencillamente deja de operar, podemos quedar sin una alternativa disponible para parte importante de nuestro flujo de trabajo. Como corolario de la dependencia de terceros, al depender de aplicaciones como servicio perdemos la capacidad de planear las actualizaciones de nuestra infraestructura — Al depender de proveedores externos, en el momento en que cualquiera de sus APIs cambia, nos vemos forzados a actualizar de inmediato. Nuestros servicios en producción pueden fallar, y el mero concepto de “rama estable” pierde buena parte de su atractivo [1]. 48

.COLUMNA

Programar es un Estilo de Vida

“Lo que critico

Mientras que en el apartado anterior partíamos de que –desde el punto de vista del usuario– hay una aplicación central que corre en sus instalaciones y consume procesamiento realizado por componentes distribuídos por el mundo (”en la nube”), aquí la aplicación completa será desplegada en el proveedor de servicios. El usuario deja de emplear un servidor –o una granja de servidores– para consumir sólo los recursos. Y, consecuentemente, el esquema de utilidad para un proveedor de servicios bajo esta modalidad puede ir desde la renta a costo fijo hasta un cobro por uso de recursos, típicamente permitiendo reconfiguraciones dinámicas del paquete (del conjunto máximo de recursos) como respuesta a la demanda del sistema. La justificación detrás de este concepto es que los servidores ”en casa” representan un gasto demasiado grande — Compra y actualización periódica de equipo, consumo eléctrico, uso de espacio físico y de ancho de banda, siendo que las instalaciones de la mayor parte de los usuarios no cuentan siquiera con un centro de datos. Además, todo servidor debe ser adquirido contemplando la carga estimada que sostendrá, pero contemplando un espacio para sobreconsumo en picos de actividad no planificable. En cambio, un proveedor masivo de servicios balancea el exceso de demanda de un usuario con la reducción de demanda de otro, permitiendo un menor sobredimensionamiento — Y una reducción neta de precios. Nuevamente, apreciarán que la idea no es nueva — Los proveedores de presencia o de hosting existen desde hace muchos años en Internet. Más allá aún, precisamente este esquema fue planteado a mediados de los 1960, cuando fue desarrollado el sistema MULTICS [2]. La principal diferencia con el esquema tradicional de renta de servidores es que bajo este esquema, el usuario deja de ser responsable de la administración incluso del servidor en el que se ejecutarán sus aplicaciones; el proveedor de servicios ofrece una cartera de plataformas administradas. Las plataformas pueden ser desde aplicaciones medianamente complejas, como plataformas Web que llevan un grado no trivial de configuración y representan una solución completa e integrada, hasta marcos para el desarrollo de sistemas (como Rails, Struts, Django, GWT), para los cuales los clientes sólo proveen el código específico de su aplicación, y aprovechan todo el andamiaje común que ya existe para una amplia base de clientes. Respecto a consideraciones de seguridad y confiabilidad: Si bien al emplear PaaS no caemos ya en la trampa descrita en el primer apartado respecto a emplear código del cual no tenemos más conocimiento que el API, éste esquema sigue depositando todos nuestros datos en control del proveedor, en infraestructura compartida, con lo cual la probabilidad de que un ataque a un sistema sin relación aparente con el nuestro puede dar

a un intruso acceso pleno a nuestra información. El riesgo de que el proveedor cambie sus políticas de cobro a un esquema que no nos convenga se reduce también fuertemente, dado que en principio tenemos todo lo necesario para replicar la instalación con cualquier otro proveedor, o incluso migrar a una solución ”en casa”. Sin embargo, seguiremos sujetos a los “días bandera” de actualización forzada, dado que el proveedor típicamente ofrecerá la misma versión base a todos sus clientes — Y este factor puede dificultarnos una migración entre proveedores. Hablando meramente de la conveniencia: Podemos enviar a uno de nuestros sistemas a la nube dados sus requisitos de almacenamiento de información, o de ancho de banda. Ahora bien, ¿cómo estamos realizando nuestros respaldos? Para poder hacer frente a contingencias, contar con una estrategia de respaldos buena y probada es mucho más importante aún que cuando hablamos de despliegues en infraestructura propia. Por último, respecto al IaaS: Este resulta el más nebuloso y ambiguo — Ya no se trata de sistemas o entornos para que éstos se ejecuten, sino que de recursos de cómputo que están a nuestra disposición: Espacio en disco o en memoria, ”ticks” de procesador, ajuste de ancho de banda, como componentes discretos y ajustables en vivo — Atributos que se apoyan fuertemente en la virtualización para poder ser desplegados y controlados. Hay quien incluye la virtualización de escritorios dentro de la definición de IaaS, pero si mucho, eso debe ser visto como consolidación de recursos y mejoría en el aprovechamiento de recursos, pero por calidad en el servicio debe hacerse utilizando recursos internos a la organización — Y por tanto, se aleja de las definiciones básicas de en la nube. Llevamos años haciendo cómputo en la nube de un tipo o de otro. Al desmitificarlo un poco, espero abonar a una mejor utilización. Y al hablar acerca de los nada ignorables riesgos que conlleva, apunto a la cautela que debemos tener al adoptarlo, no entrar de lleno sólo porque es la moda.

››Por Gunnar Wolf

Notas: [1] Un ejemplo de esto se dio en agosto de este año cuando Twitter cambió su esquema de autenticación, obligando a miles de aplicaciones a migrar su código al nuevo esquema. [2] El sistema operativo MULTICS partía del planteamiento de que el cómputo se convertiría en un servicio provisto centralmente, como la electricidad o el teléfono. http://www.multicians.org

www.sg.com.mx |

PaaS+IaaS: Flexibilidad en el uso de recursos

Software Guru

es el abuso de un término ambíguo”

.COLUMNA Invitada

Cómputo Ubicuo + humanos

dispositivos

+ ambiente

“Una tecnología suficientemente avanzada, es indistinguible de la magia.”

sta afirmación hecha por el brillante escritor de ciencia ficción Arthur C. Clark nunca ha sido más cierta que cuando nos enfrentamos con una tecnología embebida en nuestras labores cotidianas. La mejor forma de saber que estamos frente a computación ubicua es que las computadoras están integradas al ambiente de tal forma que nuestra interacción con estas sea casi invisible pero si perceptible, por esto también es llamada Inteligencia Ambiental.

“En el cómputo ubicuo se pasa de un usuario operador a uno que

interactúa de forma natural.”

No importa como la llamemos, la computación ubicua está a nuestro alrededor y poco a poco ha ido generando ambientes amigables al usuario, el soporte eficiente y distribuido de servicios, el aumento del poder del usuario sobre su entorno, y el soporte para la interacción humana. Es un ambiente basado en un modelo de interacción en el cual los usuarios están rodeados de un entorno digital consiente de su presencia, sensible al contexto y que puede adaptarse a sus necesidades y hábitos, Además, el cómputo ubicuo es una visión que coloca al ser humano como centro de desarrollo futuro en la sociedad del conocimiento, la información y la tecnología. Estas tecnologías serán empotradas en dispositivos cotidianos y casi invisibles a aquellos que las utilizan, las interfaces serán sencillas y usables en un modo natural. Esta visión nos propone un distanciamiento de las computadoras de escritorio tradicionales hacia una amplia gama de dispositivos embebidos en nuestro entorno y que son accedidos desde interfaces inteligentes como RFID (tarjetas de identificación por radiofrecuencia), los dispositivos móviles (PDA’s, Celulares, etc.) con conexiones bluetooth, infrarrojo o wifi. Los siguientes son ejemplos de objetos inteligentes dentro de un entorno ubicuo: • Sintonización automática del canal de televi.BIO sión más adecuado a la hora, día y grupo de miemHéctor Cuesta Arvizu es Lic. en Informática y actualbros de la familia sentadas en el sillón en frente de mente cursa la maestría en ciencias de la computación la televisión. en la UAEM Texcoco. Cuenta • Control de iluminación de un hogar u oficina con seis años de experiencia desarrollando y administranacorde con las personas presentes, nivel de luminodo proyectos de software en el ámbito de manufactura y sidad o actividad en curso. recursos humanos. Adicional• Apertura automática de puertas, llamada de mente se desempeña como instructor de TI para Nyce en ascensores y subida a los pisos correctos dependienel area de base de datos e ingenieria de software. do de los usuarios presentes en el ascensor. @hmcuesta • Transacciones económicas facilitadas por nues-

tros dispositivos o tarjetas inteligentes, entre ellos el próximo DNI digital. • Ofrecimiento de servicios en base a nuestra localización actual, por medio de nuestro teléfono móvil. ¿En realidad cómo se coordinan los dispositivos a nuestro alrededor para darnos la sensación de inteligencia ambiental? La respuesta a esta pregunta no es trivial, ya que hay muchos aspectos y tecnologías involucradas. Sin embargo, dos tecnologías fundamentales para este paradigma es el Internet y los servicios web. El papel que juega el Internet en el cómputo ubicuo es primordial: la alta conectividad, la capacidad de interconectar sistemas y acceder a diferentes bases de datos. Los servicios web nos permiten acceder a todo esto de forma sencilla y estandarizada. Cualquier dispositivo con conectividad a Internet tiene el potencial de realizar peticiones a web services y de esta forma recibir o actualizar información.

Conclusión

En los próximos años, estaremos trabajando en aspectos tecnológicos y sociales que nos acerquen a la computación ubicua. En el aspecto tecnológico, debemos enfocarnos en el desarrollo de entornos y objetos inteligentes, así como en el Internet “de las cosas” y no solo “de los documentos”, donde damos un entendimiento semántico y no solo sintáctico. Por el lado social hay muchas críticas a esta tendencia, argumentando que es un riesgo a la privacidad. Ya se ha iniciado la creación y adopción de mecanismos, prácticas y legislación relacionadas con la gestión de la privacidad de la información en el mundo digital, pero sin duda es un área donde nos falta mucho por madurar. Sin lugar a dudas, el cómputo ubicuo es el siguiente paso evolutivo en la computación, donde se pasa de un usuario operador a uno que interactúa de forma natural.

››Por Héctor M. Cuesta

Referencias [1] A. Greenfield. Everyware: The Dawning Age of Ubiquitous Computing. New Riders Publishing, 2006.

.TECNOLOGÍA Infraestructura

Redes Inalámbricas ››Por Tino Rodríguez

retos para soportar los nuevos patrones de uso

in lugar a dudas, la computación en la nube (cloud computing) y las nuevas tendencias en comunicaciones, como la videoconferencia, las comunicaciones unificadas o las aplicaciones de colaboración, representan oportunidades para el sector corporativo, tanto grandes corporaciones como pequeñas y medianas empresas. Correctamente implementados, estos recursos aportan un avance importante en la productividad de los trabajadores y las empresas. Tanto las aplicaciones de computación en la nube como las nuevas herramientas de comunicación están teniendo un auge importante en el presente. De manera paralela están surgiendo, cada vez con mayor velocidad, nuevos equipos que rápidamente encuentran su lugar en la vida empresarial. No hace mucho tiempo aparecieron las netbooks, y ahora se encuentran en pleno apogeo las tabletas (tablets) y los smartphones. A la vez, continúan desembarcando en las empresas equipos tradicionales como notebooks, desktop y teléfonos WiFi, entre otros. Tanto las aplicaciones como los nuevos dispositivos conectados enriquecen el trabajo en las empresas. Pero, ¿qué sucede con la red que debe soportar todos estos equipos y la multiplicación del tráfico? No solo está aumentando la cantidad de equipos conectados a nuestras redes, sino la cantidad de datos que cada uno transmite o recibe. Es así que los departamentos de infraestructura de TI requieren cada vez más agilidad para dar respuesta a la demanda de conectividad de sus clientes internos. Afortunadamente hay nuevas tecnologías también en este campo. La maduración del estándar 802.11n, que ofrece capacidades de transmisión de hasta 600 Mbps, está impulsando las ventas del equipamiento de red, lo que muestra claramente que los departamentos de IT de las empresas están conscientes de la necesidad de aumentar la capacidad de transmisión de su infraestructura. Aunque 802.11n permite una mayor capacidad de transmisión en los nodos de nuestra red, esto de nada sirve esto si no se acompaña de un adecuado planeamiento de la red. El problema que enfrentamos es que la mayoría de las redes inalámbricas existentes son de tipo “estrella”, con un controlador central que

administra aspectos como la seguridad de la red, la calidad de servicio (Quality of Service, QoS) y el tráfico de datos. Al añadir mayor capacidad de transmisión en los nodos, se aumenta exponencialmente el tráfico dirigido hacia el controlador central, lo que puede ocasionar congestionamientos en esta instancia de la red y ocasionar deficiencias en el servicio y pérdidas en la transmisión de datos. Ante esta problemática, los fabricantes de equipo de infraestructura de redes ya están buscando soluciones. La mayoría de los proveedores están optando por la incorporación de más equipamiento a la infraestructura, para soportar mayores cantidades de tráfico de forma central. Por su parte, Motorola ha desarrollado recientemente una nueva tecnología para la gestión de redes inalámbricas denominada WiNG 5, que permite a los nodos de una red comunicarse directamente entre sí, sin necesidad de pasar por el controlador central, lo que reduce sustancialmente el tráfico que éste debe administrar, ayudando a aliviar posibles congestionamientos. Esta innovación permite establecer rutas inteligentes para el tráfico de la red, potenciar su capacidad y aumentar la velocidad de transmisión. A la vez, la calidad de servicio y la seguridad se gestionan desde cada punto de acceso, lo que permite la administración de estos aspectos en el “borde” de la red. Con el desembarco de nuevos dispositivos y la proliferación de aplicaciones que demandan cada vez más capacidad de transmisión, la gestión del tráfico será sin dudas un punto importante en la agenda de los departamentos de IT de todas las organizaciones. Los responsables de tecnología deben comenzar a buscar soluciones que les ofrezcan la agilidad necesaria para responder a la demanda creciente del tráfico de red, la infraestructura tecnológica clave que está por detrás de los procesos de negocios. .BIO Tino Rodríguez es Gerente de Productos de Redes Inalámbricas para Latinoamérica en Motorola Solutions.

Directorio Alpha Consultoría

Pág. 11

Pág.39

Manpower Professional

Pág.4F

www.alpha-consultoria.com

Itera www.iteraprocess.com

www.manpowerprofessional.com.mx

Motorola

Pág.51

Pág.15

www.motorola.com

Neubox www.newbox.com

Pronatura

www.pronatura.org.mx

Pág.2

Qualtop

Pág. 13

www.qualtop.com

SG Campus

Pág.19

www.sgcampus.com.mx

Sistemas Humanos

Pág.41

www.humanos.com.mx/agiles

T-Systems

Pág.3F

parquecientifico.tamaulipas.gob.mx

Pág.25

www.t-systems.com.mx

Tecnotam

TENEMOS UN ESPACIO RESERVADO PARA TI SG se distribuye de manera impresa en la República Mexicana, y de manera digital llega a más de 25mil lectores de habla hispana. El anuncio en la revista digital cuenta con hiperliga directa a tu sitio web, lo que te dará la oportunidad de acercarte a nuevos clientes. “Es una gran oportunidad participar con Software Guru, pues comprobamos que es un medio efectivo.” Novalys Latinoamérica Contáctanos en el (55) 5239.5502 o en publicidad@sg.com.mx

.TECNOLOGÍA Gadgets

Mouse deportivo MOTORMOUSE

Como su nombre lo indica y como lo habrás podido constatar en la imágen, el motormouse es un mouse inalámbrico en forma de auto deportivo. En su cajuela almacena el transmisor de 2.4 Ghz. y dos baterías AAA. Sus llantas son de hule e incluye una llanta de repuesto para la rueda de scrolling. Sin duda es un lujo, pero seguro lo valemos. Disponible en http://motormouse.us.com. (Fotografía cortesía de IEEE Spectrum).

SAMSUNG

Galaxy Tab Samsung lanzó en México la nueva Galaxy Tab. Este precioso gadget de tan solo 380 gramos de peso cuenta con el sistema operativo Android 2.2 con acceso a Android Marketplace. Con su pantalla de 7” TFT-LCD, permite que te comuniques a través de correo electrónico, llamadas de voz y video llamadas, SMS/MMS o utilizar las redes sociales con una interfaz muy sencilla y dinámica. La Galaxy Tab puede reproducir video en alta definición, y tiene la posibilidad de desplegar señales de televisión análoga gratuita. Adicionalmente integra un lector de libros, revistas y periódicos digitales, conectividad inalámbrica con otros productos Samsung gracias a All Share (DLNA), Wi-Fi Router y dos cámaras, una frontal 1.3 MP para video llamada y otra trasera de 3.2 MP con flash.

SONY

Alpha SLT-A55 Sony anuncia la disponibilidad de la nueva cámara tipo réflex Sony Alpha SLT-A55, la primera en grabar video en Full HD con enfoque automático. Gracias a la novedosa Tecnología Translucent logra ser la cámara réflex más rápida del mercado, ya que realiza tomas de alta velocidad de 10 fps (cuadros por segundo) con enfoque automático continuo de detección de fase. Cuenta con Sensor Exmor APS HD y Quick AF Live View que permiten una mejor calidad de imagen y una capacidad de respuesta casi instantánea de auto-enfoque. Por si fuera poco el nuevo modelo, además de ser el más compacto en comparación con las cámaras réflex tradicionales, está equipado con la tecnología Sweep Panorama y 3D Sweep Panorama de Sony, está última permite apreciar imágenes en 3D a través de los televisores BRAVIA compatibles con esta tecnología. 54

.TECNOLOGÍA Gadgets

Optimus 7 LG

LG lanzó el primer teléfono en México con el sistema operativo Microsoft Windows Phone 7. Esta equipado con funciones como Play To, que consiste en enviar con tan solo el toque de un dedo, un archivo multimedia a través de Wi-Fi, a diferentes dispositivos habilitados con la tecnología DLNA como pantallas, Blu-ray, consolas de juego Xbox y sistemas de audio, lo que permitirá compartir de manera fácil y rápida la información de su teléfono. Entre las funciones exclusivas del nuevo LG Optimus 7 se encuentra la aplicación de reconocimiento de voz para crear mensajes de texto, asi podrás actualizar todas tus redes sociales, envíar correos electrónicos, mensajes de texto o crear recordatorios sin necesidad de utilizar el teclado. Cuenta con: cámara con resolución de 5.0 MP, flash, enfoque automático y opción para grabar video en alta resolución, toma de fotografias panoramicas y sistema GPS.

THECORPORA

Qbo

En esta edición de gadgets quisimos incluir información de algún robot, ya que es un área que está teniendo un gran desarrollo, y cada vez es menos descabellada la idea de tener robots en la casa u oficina. Uno de los proyectos recientes que llamó nuestra atención es el Qbo, un robot de código abierto que cuenta con visión estereoscópica, sistema de reconocimiento de voz, sistema para la Síntesis de la Voz, API y Panel de Control Web, conexión Wi-Fi & Bluetooth, así como sensores de ultrasonido para evitar colisiones y caídas. El Qbo está basado en una versión reducida de Ubuntu denominada OpenQbo, y es código abierto así que puedes consultarlo y modificarlo para ajustar o extender el comportamiento de tu robot. Puedes consultar el avance del Qbo y descargar el sistema operativo en http://thecorpora.com/blog

ACER

Proyectores HD 3D Acer se complace al presentar en el mercado mexicano su nuevo proyector de alto rendimiento preparado para proyectar gráficos con tecnología NVIDIA® 3D Vision. Es el único proyector que soporta 120 cuadros por segundo con frecuencia de 120 Ghz y resolución Full HD 1080P en modo 3D Vision™. Con este modelo, los usuarios podrán disfrutar la más alta calidad en definición de audio y video gracias a la conectividad HDMI incluída, ademas realizarán presentaciones más dinámicas con una calidad nítida e impresionante. Ya sea para el hogar o la oficina, la nueva línea de proyectores de Acer es una gran opción. 55

.BIBLIOTECA

The Shift: The Evolving Market, Players

and Business Models in a 2.0 World” Allison Cerra & Christina James 2010

A pesar de no ser un libro “formal” publicado por una editorial, “The Shift” es una obra que sin duda provee información que será de interés para los lectores de SG. “The Shift” es coescrito por personal de la empresa Alcatel-Lucent y en realidad es una herramienta para plasmar la visión de dicha empresa respecto al futuro de la red e invitar al lector a reflexionar su rol en el contexto de dicha visión. “The Shift” provee un análisis del vertiginoso ritmo al que los consumidores están adoptando nuevas tecnologías, y el impacto que esto tiene en el ecosistema de fabricantes de equipo, proveedores de telecomunicaciones y desarolladores de aplicaciones conforme trabajan para lograr satisfacer las demandas de los consumidores para estar conectados en todo momento, desde cualquier lugar y cualquier dispositivo. En el libro se introduce al lector al concepto de un nuevo tipo de red de telecomunicaciones inteligente. Hasta ahora, hemos lidiado con redes de telecomunicación en cierta forma “tontas”, ya que solamente sirven para transportar datos. La visión que se impulsa en el libro involucra un nuevo tipo de red “inteligente” que ofrecer a los usuarios y desarrolladores de aplicaciones servicios de valor agregado como cobranza y geolocalización entre otros. Dicha red brinda una nueva capa que ofrece servicios para el desarrollo y operación de aplicaciones de software en dispositivos móviles. Estos son algunos de los hallazgos que se comunican en “The Shift”:

Los consumidores modernos valoran las aplicaciones que incorporan inteligencia basada en la red y están dispuestos a pagar entre 25 y 35% más por un servicio con tres capacidades operando de forma simultánea a diferencia de servicios separados. Más del 50% de los consumidores no tienen inconveniente en confiarle a su operador de servicios de telecomunicaciones información sensible como datos personales, ubicación y perfil de comportamiento. Cerca del 50% de los desarrolladores de software independientes están dispuestos a pagar el doble por APIs integrados a diferencia de APIs separados. Los desarrolladores corporativos están dispuestos a pagar hasta el triple. Cerca de una tercera parte de los anunciantes está interesado en utilizar servicios que les permitan enviar publicidad dirigida en base a los intereses y comportamiento de los consumidores. “The Shift” no está disponible a la venta. Puedes solicitar una copia gratuita desde el sitio web http://theshiftonline.com. En dicho sitio web también podrás discutir las ideas planteadas en el libro y contactar a los autores.

Masterminds of Programming: Conversations with the Creators of Major Programming Languages Federico Biancuzzi & Shane Warden O’Reilly Associates, 2009

“Masterminds of Programming” es una colección de entrevistas exclusivas con los creadores de varios de los lenguajes de programación de mayor importancia. Por medio de esta obra conocerás sobre las situaciones y razonamiento detrás de las decisiones de diseño tomadas durante la creación y evolución de estos lenguajes. El libro incluye entrevistas con: Adin Falkoff (APL); Thomas Kurtz (BASIC); Charles Moore (FORTH); Robin Milner (ML); Donald Chamberlin (SQL); Alfred Aho, Peter Weinberger, y Brian Kernighan (AWK); James Gosling (Java); Charles Geschke y John Warnock (PostScript); Bjarne Stroustrup (C++); Bertrand Meyer (Eiffel); Brad Cox y Tom Love (Objective-C); Larry Wall (Perl); Simon Peyton Jones, Paul Hudak, Philip Wadler y John Hughes (Haskell); Guido van Ros-

sum (Python); Luiz Henrique de Figueiredo y Roberto Ierusalimschy (Lua); Grady Booch, Ivar Jacobson y James Rumbaugh (UML); Anders Hejlsberg: (Delphi, C#). “Masterminds of Programming” es una valiosa cátedra sobre diseño de lenguajes, prácticas de ingeniería de software, y perspectivas únicas sobre la historia de las ciencias de la computación. A nuestro parecer, las entrevistas más interesantes son aquellas con los creadores de lenguajes antiguos o poco conocidos, ya que abordan retos y perspectivas en las que no estamos acostumbrados a pensar. Compartimos con ustedes una de nuestras frases favoritas extraídas del libro: “The software business is one of the few places we teach people to write before we teach them to read. That’s really a mistake.” — Tom Love 56