SG32 (Mayo-Julio 2011) by Revista Software Guru

Estimaciﾃｳn de Proyectos P.36

Arquitectura de Software P. 40

Introducciﾃｳn a Node.js P.50

No.

Appcelerator Titanium

Caso de estudio:

CONOCIMIENTO EN PRﾃ，TICA

CMMI

para Servicios

Mayo-Julio 2011 www.sg.com.mx

Manejando la

Nube Empresarial

Mﾃｩxico, $65.00

CONOCIMIENTO EN PRÁCTICA

Pág.

32 .CONTENIDO Mayo-Julio 2011 |

www.sg.com.mx

En Portada Manejando la Nube Empresarial

Tejiendo Nuestra Red

Administrar entornos aplicativos en el contexto del cómputo en la nube no es algo trivial. Dediquemos un espacio a conocer estrategias para lidiar con estos retos.

Columnas por Hanna Oktaba

Tendencias de Software

por Luis Daniel Soto

Columna Invitada

por Héctor Santillán

Programar es un Estilo de Vida

por Gunnar Wolf

Tecno-lógico por Mauricio Angulo

.CONTENIDO

SG 32

Productos Lo que Viene

Cloud Foundry, VMM 2012, Ceylon

Tutorial Appcelerator Titanium

Desarrollo de aplicaciones móviles nativas.

Un Vistazo a la Plataforma BlueVia

Plataforma de negocio para desarrolladores.

En Cada Número Pág.

16 Emprendiendo

La Importancia de una Bolsa de Valores para Empresas de Innovación

Editorial

Noticias

Fundamentos

Biblioteca

Víctor Chapela comparte con nosotros un análisis de la industria de software en México y da sugerencias para mejorarla.

Tecnología

Caso de Estudio

Infraestructura

CMMI para Servicios

Gadgets

Conozcamos el rescate de las integradoras y empresas de producto.

Prácticas Project Management Estimación de Proyectos de Software

Francisco Valdés comparte un caso de estimación aplicada.

Usabilidad Perfiles de Usuario

Pamela Rodríguez recomienda cómo aprovechar los perfiles de usuario.

Arquitectura Integrando la Arquitectura al Ciclo de Desarrollo

Humberto Cervantes y Edith Valencia explican cómo realizar esta tarea.

Agilidad Innovación de Valor Mediante Lean-Agile

Masa Maeda recomienda apoyarse en Lean para brindar innovación de valor.

52 54

.EDITORIAL Bienvenida

No todo en la nube es color de rosa .

“La lección no es alejarse de la nube.”

l 21 de abril de 2011 posiblemente pase a la historia como el día en que el mundo se dio cuenta que no todo era color de rosa en la nube. La madrugada de ese día, Amazon tuvo una falla de servicios en su centro de datos de Virginia del Norte (uno de 5 centros globales que operan). Esta pequeña falla afectó a miles de usuarios y empresas en todo el mundo. Para algunas empresas, los daños fueron irreversibles. En el caso de SG, recibimos un aviso del proveedor de la aplicación de project management que utilizamos indicándonos que “era posible” que se hubieran perdido datos nuestros, así que “revisaramos a ver si nos faltaba algo”, y que si no teníamos respaldo de lo que nos faltaba, “lo sentían”. La lección aprendida no es que no debamos ir a la nube —sus ventajas son irrefutables. Simplemente, debemos tener mayor precaución al hacerlo. Así que consideramos que el tema principal de este número queda como anillo al dedo. También en abril realizamos la edición Spring 2011 de SG Virtual. Los resultados superaron las expectativas y hemos obtenido muy buena retroalimentación de todos ustedes. Agradecemos a todos los que hicieron esto posible, conferencistas, asistentes, sedes virtuales y patrocinadores. Hemos encontrado que hay mucho interés tanto en las conferencias virtuales como presenciales, por lo que continuaremos con ambos formatos. Nuestro próximo evento es SG Conferencia y Expo el 7 y 8 de septiembre en Ciudad de México. ¡Los esperamos!

››Equipo Editorial Software Guru

DIRECTORIO SG Dirección Editorial Pedro Galván / Dirección de Operaciones Mara Ruvalcaba Coordinación Editorial Vanessa Amaya / Arte y Diseño Oscar Sámano 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 Mauro Parra, Víctor Chapela, Carlos Escapa, Ajay Singh, Leslike Minnix-Wolfe, Eumir Reyes, Francisco Valdés, Pamela Rodríguez, Héctor Santillán, Humberto Cervantes, Edth Valencia, Masa Maeda, Gunnar Wolf, Mauricio Angulo, Daniel Zavala, Andrés Martínez 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 mayo de 2011 en 4Press.

.NOTICIAS

.Encuentro

Nacional de Clusters

Fotografía cortesía de Kris Krüg (@kk)

.SXSW Interactive

Del 12 al 15 de marzo se realizó en la ciudad de Austin, TX el festival South by Southwest Interactive. Dicho festival se ha posicionado en los últimos años como un evento de gran relevancia para los startups en Internet y empresas de medios interactivos. Esta edición resaltó por la participación de varios conferencistas latinoamericanos, quienes dejaron ver que nuestra región va tomando fuerza y ganándose un lugar en este espacio. Para redondear esto, el reconocido empresario y catedrático norteamericano Gary Hoover impartió una plática titulada “Why Mexico will change your life”.

La Cámara Nacional de la Industria Electrónica, de Telecomunicaciones y Tecnologías de la Información, CANIETI, organizó el 6to. Encuentro Nacional de Clústeres de TI, a través de su Consejo Nacional de Clústeres de Software el pasado 7 y 8 de abril en el Chapala Media Park en Jalisco. Al encuentro asistieron representantes de 25 clústeres de TI del país como InteQSoft, CsoftMty, CITI Tabasco, CITI Yucatán, Cluster TIM, entre otros. El objetivo principal del evento fue mejorar la coordinación y colaboración de los clusters tecnológicos en el país, para impulsar la industria, fomentar la innovación y mejorar la competitividad del país.

.API Hackaton

El pasado 30 de abril se realizó el primer API Hackaton en la Ciudad de México. A lo largo del día los participantes estuvieron desarrollando aplicaciones y servicios utilizando APIs abiertos y al final se seleccionaron los 3 mejores. El equipo de la empresa Ready2Fill se llevó el 3er lugar por agregar a su ERP la capacidad de autorizar procesos vía telefónica por medio del API de Twilio. El 2do lugar fue para Paola Villarreal quien desarrolló un servicio de trazo de rutas en Ecobici conjuntando los APIs de Foursquare y Google Maps. El 1er lugar fue para el equipo de TidySlice, quienes desarrollaron un servicio para determinar la ubicación de tus contactos en redes sociales y avisarte cuando alguno está cerca de tí. Twilio, Aspire Labs y Software Guru fueron los patrocinadores que hicieron este evento posible.

.Encuentro Genexus

Más de 1.300 asistentes participaron en el VIII Encuentro GeneXus México, Centroamérica y el Caribe. El eje central del Encuentro fue el nuevo Generador para Smart Devices, la última tecnología de GeneXus para dar respuesta al complejo desafío vigente en el mercado por el requerimiento de soluciones ubicuas con múltiples interfaces. Además de las conferencias relacionadas con el área de negocios, innovación y tecnología que brindaron los ejecutivos de Artech, el público disfrutó de una excelente presentación de la mano de Luis “Chapulín” Díaz, acerca de la optimización del trabajo en equipo.

Para mayor información, noticias al día y actualizaciones de la industria visita: www.sg.com.mx

www.sg.com.mx |

El pasado 17 de marzo dio inicio en la Ciudad de Villahermosa la gira para latinoamérica del escaparate internacional de aplicaciones móviles “AppCircus”. Con la colaboración de DotOpen, CITI Tabasco y Telcel se organizó el primer evento internacional de aplicaciones móviles en México, en el que se registraron para concursar casi 30 aplicaciones. El evento contó con la participación de programadores locales, así como de Chiapas, Querétaro, Oaxaca y el Distrito Federal. La aplicación ganadora fue Yumbling, cuyo premio fue la nominación para participar en los Mobile Premier Awards en Barcelona, España.

Software Guru

.AppCircus Villahermosa

.COLUMNA Tejiendo Nuestra Red

“Al diablo con los procesos,

hagamos prácticas”

dice ivar jacobson e impulsa una nueva iniciativa del

eguramente muchos de Ustedes conocen a Ivar Jacobson. Un sueco, que algunos viejitos como yo, lo conocimos como el padre de casos de uso gracias a su libro Object-Oriented Software Engineering (1992). Los más jóvenes deberían de reconocerlo como el co-autor, con Booch y Rumbaugh, de UML y del Proceso Unificado, cuando todos fueron socios en Rational. Hoy tiene su propia consultoría y no se queda quieto. En 2007 escribió un artículo titulado: Enough of Processes – Lets do Practices, que en mi traducción libre sirvió del título a esta columna. En él hace una crítica del mal uso actual de procesos y propone redescubrirlos a través de prácticas. Según Jacobson, el término “proceso” es una descripción explícita de la manera de trabajar. Todos los equipos tienen una forma de trabajar juntos, sea explícita o tácita. Las maneras de trabajar de los equipos de desarrollo de software, por lo general, están inspiradas en las ideas de los expertos externos o locales. Los expertos tienen su manera preferida de trabajar, y a veces, deciden presentarla en forma publicada (libros) tratando de que sea lo más único e individual posible. Esto ha ocasionado varios problemas.

Problemas con los procesos de hoy

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

• Negación de cosas comunes Cada proceso tiene muchas cosas comunes y pocas diferencias con otros. Lo que pasa es que los autores tratan de usar distinta terminología para ocultar lo común. Yo agregaría que, en muchas ocasiones siento que es “la misma gata pero revolcada”. • Problema de completitud Todos los procesos pretenden ser completos y esto nunca va a ser posible. Las definiciones de procesos se vuelven extensas y es difícil de encontrar en ellas lo que hace falta en un contexto dado. Yo agregaría, que la frontera entre el “qué” y el “cómo”, en el detalle de la descripción de los procesos, depende del conocimiento previo de los lectores. Por lo que nunca será posible tener una definición completa para todos.

SEMAT

• Problema de la adopción de procesos nuevos completos Al tomar la decisión de implementar los procesos nuevos completos, se pueden perder buenas prácticas que han servido a los equipos. Muchos cambios a la vez difícilmente serán aceptados. Yo agregaría, que la situación se vuelve más difícil si las nuevas prácticas no resuelven los problemas reales de la organización. • Problema de la brecha entre los procesos que se tienen y los que se necesitan La verdad es que los equipos difícilmente siguen los procesos oficiales de su organización. Usan una mezcla de lo que se sugiere y lo que sienten que se tiene que hacer. No se lo digan a nadie, así debe de ser (digo yo). • Problema de acceso al conocimiento La ley de la naturaleza humana dice que la gente no lee manuales (¡ni de procesos!). La presentación actual de procesos es aburrida. Se necesita una forma más útil de presentarlos y de tenerlos disponibles cuando se requieran. Yes, yes, yes!!! Ya es hora a que usemos nuestra propia tecnología para lograrlo (digo yo). • Problema de procesos “estúpidos” Los procesos, que se pide que sigan los equipos, no les sirven para hacer su trabajo. Para seguir los procesos se depende de expertos, mentores o coaches. Ni hablar (digo yo).

En consecuencia, dice Jacobson:

• Las empresas tienen dificultades en establecer formas efectivas de trabajar. • La adopción de procesos es una barrera y no una forma de establecer maneras efectivas de trabajar. • Los métodos ágiles surgieron para dar la solución a estos problemas, pero sus gurús siguen escribiendo libros.

Entonces ¿qué se puede hacer? La paradoja es que aunque a los desarrolladores no les gustan los procesos, ¡necesitan prácticas!

“La

situación se vuelve más difícil si las nuevas prácticas no resuelven los problemas reales de la organización .”

Una práctica proporciona una manera sistemática y verificable de atacar un aspecto particular de un problema, dice Jacobson. Una práctica es como una unidad que puede ser identificada, aprendida y adoptada por separado. Una práctica puede ser utilizada en conjunto con otras prácticas para crear una forma de trabajo coherente. ¿De dónde vamos a secar las prácticas? La respuesta de Jacobson es, ¿qué creen? - de los libros de Ingeniería de Software, de Modelos de procesos y de Métodos Ágiles. En el mismo artículo hace referencia a Prácticas Esenciales de Proceso Unificado cuyo sitio encontrarán en referencias. ¿Y qué onda con los procesos? Según Jacobson, un proceso puede ser considerado como una colección de prácticas relacionadas y altamente acopladas. De esta manera el proceso se vuelve como una guía de prácticas cuya adopción es un punto de partida para cambiar la forma de trabajar. Se puede adoptar una práctica a la vez, dejando sin cambio las prácticas que ya se siguen. Para documentar las prácticas, propone metáfora de “tarjetas” (electrónicas e impresas). Una tarjeta contiene el resumen de la práctica, el cual está acompañado de una guía que contiene los detalles. Esta propuesta no se quedó en el tintero. En marzo de 2010 Ivar Jacobson, Bertrand Meyer and Richard Soley convocaron a los mejores gurús de Ingeniería de Software a un taller en Zurich, en el cual constataron que la Ingeniería de software está “gravemente obstaculizada por las prácticas inmaduras”. Todos estuvieron de acuerdo que los problemas específicos son: • Prevalencia de las modas • Falta de una base teórica • Gran número de métodos • Falta de validación experimental creíble • División entre la práctica de la industria y la investigación académica Decidieron constituir una iniciativa bajo el nombre Software Engineering Method and Theory (SEMAT) cuyo objetivo principal es: “Apoyar un proceso de re-fundamentar la Ingeniería de Software basado en una teoría sólida, principios probados y las mejores prácticas.” Al inicio de 2011 la iniciativa fue transferida a Object Management Group para darle mayor respaldo institucional. Todos estamos invitados para participar. Para finalizar, quiero agradecer a Praxis por invitarme cada año a su evento de Calidad. Este hecho me obliga a explorar temas nuevos, que luego convierto en columnas. Este caso no es la excepción.

››Por Hanna Oktaba

Referencias: [1] Ivar Jacobson, Pan Wei Ng, Ian Spence: “Enough Process - Let’s Do Practices”, in Journal of Object Technology, vol. 6, no. 6, July-August 2007, pp. 41-66 http://www.jot.fm/issues/issue_2007_07/column5 [1] ESSWORK: www.esswork.com [1] Software Engineering Method and Theory (SEMAT): http://www.semat.org

.productos Lo Que Viene

Cloud Foundry

La libertad llega al PaaS

VMware sorprendió a la industria con el lanzamiento de Cloud Foundry, la primer Plataforma como Servicio (PaaS) abierta. Hasta ahora, uno de los principales temores de desarrollar bajo un esquema PaaS es el de atarse a un proveedor y tecnología. Cloud Foundry pretende cambiar todo esto, brindando flexibilidad y libertad en la elección de frameworks, servicios y ambiente de instalación. Respecto a este último punto, Cloud Foundry ofrece la posibilidad de utilizarse desde una nube pública, desde una nube privada o incluso desde tu propia computadora como una máquina virtual (micronube). Los frameworks y lenguajes soportados por ahora son Spring para Java, Rails y Sinatra para Ruby, Node.js y Grails. Cloud Foundry es software libre bajo licencia Apache 2.0, y además se cuenta con contratos de soporte comercial. Mayor información en http://cloudfoundry.com y http://cloudfoundry.org

Durante el Microsoft Management Summit, la empresa de Redmond anunció la disponibilidad pública de la beta para System Center Virtual Machine Manager 2012 (SCVMM 2012). Esta versión incorpora grandes mejoras en la gestión de sistemas y provee nuevas capacidades para administrar mejor los servicios de centros de datos. Virtual Machine Manager 2012 permitirá administrar nubes públicas y privadas, basadas tanto en plataformas Hyper-V como en Azure. También se encarga de la gestión de almacenamiento de principio a fin, soportando aprovisionamiento SAN con SMI-S. SCVMM 2012 se basa en el enfoque de bloques de construcción para permitir el aprovisionamiento de servicios de TI completos. Su capacidad para desplegar una infraestructura aplicativa completa a partir de un modelo será de gran utilidad.

Virtual Machine Manager 2012

Mejora la gestión del centro de datos

Mayor información en http://www.microsoft.com/systemcenter

Ceylon

Java sigue mutando

¿Cómo sería un lenguaje de programación para aplicaciones empresariales si se diseñara actualmente tomando en cuenta los éxitos y fracasos del lenguaje Java y su SDK? Bajo esta premisa es que Gavin King y su equipo en Red Hat diseñaron el lenguaje Ceylon. Entre las características de Ceylon podemos listar que correrá sobre la máquina virtual de Java, utilizará tipos estáticos (static typing), tendrá manejo de memoria automático, soportará funciones de primera clase y proveerá una sintáxis declarativa para definir estructuras de datos e interfaces de usuario. Ceylon apenas está en desarrollo. Se planea liberar un compilador en la segunda mitad del año. Si quieres conocer más sobre el lenguaje consulta los artículos que Gavin ha publicado en http://in.relation.to/tag/Introduction+to+Ceylon

.COLUMNA

Tendencias en Software

BigData

la base de datos relacional no lo es todo

Big Data

El término “Big Data” se está convirtiendo rápidamente en un nuevo foco de atención. El modelo actual de bases de datos es el relacional, donde explícitamente se ignora el orden de los renglones. Esta implementación impone un orden inherente en las tablas e inevitablemente resultará en recuperación de datos en forma no secuencial, una vez que no sea posible obtenerla de memoria RAM. A mayor información almacenada, el problema se incrementará. Se tiene que considerar la idea de abandonar el modelo relacional en cierto punto. En el 2011, administrar una base de datos mayor a 3 TB requiere definitivamente de mejores prácticas, aunque el costo del hardware ha caído dramáticamente. Los appliances de almacenes de datos pueden soportar hasta 80 TB en sistemas con memoria compartida (SMP) y el salto a los Petabytes generalmente requiere procesamiento paralelo. En Estados Unidos, el 60% de bases de datos en producción de empresas supera ya 1 TB de información y de acuerdo a Forrester el 13% supera los 15 TB. Los grandes sitios de Internet son sin duda los que tienen la mayor oportunidad en el denominado clickstream analysis.

Hadoop

Entre los inversionistas de las startups de mayor renombre, un área de inversión ha sido la relacionada al proyecto Hadoop de Apache. Esta tecnología es apropiada para crear índices y manipular grandes cantidades de información en las denominadas nubes públicas. Amazon con Dynamo y Google con BigTable emprendieron este camino por los requerimientos de negocio y alejándose de complejidad innecesaria para cierto tipo de escenarios. Prácticamente todos los fabricantes de data warehouse están incorporando esta capacidad nativa en la productos comerciales de base de datos. Los analistas consi09

deran que MapReduce ha alcanzado la velocidad de escape en nuevas tecnologías y permanecerá extendiendo a los actuales administradores de bases de datos.

Estandarizando el acceso

También existen productos “NoSQL”, aunque el creador del término dijo que debería ser “NoRel” dado que el SQL es conocido y tiene muchas ventajas. No hay normas para el acceso a la información, es una tecnología emergente con muchas indefiniciones y un mercado extremadamente fragmentado. En marzo del 2011, la ACM Association for Computing Machinery, publicó un artículo de Erik Meijer y Gavin Bierman en el que se propone un modelo “Co-Relacional” para grandes bancos de datos compartidos. LINQ es apropiado para efectuar consultas en cualquiera de estos modelos.

Gran complejidad

Big Data no solo es el almacenamiento de información, involucra también el análisis con datos que no fueron diseñados para inteligencia de negocio, compresión, archivado multi-temperatura, automatización y depurado de datos. Posiblemente responder a cambios en los sensores sin tener que almacenar toda la información, denominado Complex Event Processing. Por último, un sistema de datos requiere mayor seguridad para el manejo de información privada y alta disponibilidad.

Software Guru

a explosión de datos está sucediendo a todo nivel en todos los dispositivos electrónicos, aplicaciones, individuos y organizaciones. De acuerdo al “Estudio del Universo digital” de IDC, el año pasado excedimos 1.2M Zetabytes con un pronóstico de crecimiento de 44x en la presente década. El recurso humano asociado solo crecerá 1.4x, lo que representa una enorme oportunidad para la industria. Demos contexto a la capacidad: todas las palabras habladas en la historia de la humanidad representan 5 Exabytes, un millar de estos forman un Zetabyte. La mayor parte de estos datos carecen de estructura.

www.sg.com.mx |

Hacia el futuro

Gran complejidad significa grandes oportunidades para la mercadotecnia y venta de soluciones de tecnología. Ya se han iniciado las charlas del impacto social y de negocio de Big Data. Mi recomendación es no apresurarse sino esperar a que los fabricantes absorban los aprendizajes en la plataforma existente. Excepto que exista una necesidad muy puntual. Es cierto, la tecnología actual de base de datos es difícil de escalar, pero eso seguramente cambiará antes de ahogarnos en un océano de datos. Para mi gusto es un paso en la evolución de la plataforma aplicativa.

>> Por Luis Daniel Soto

Referencias: [1] Christof Strauch. “NoSQL Databases”. http://bit.ly/sg32r15 [2] “Tapping into the power of Big Data”, PwC. http://bit.ly/sg32r16 [3] “Big Data 2011 Preview”, GigaOm. http://bit.ly/sg32r17.org

Luis Daniel Soto Maldonado labora en la división de negocio de servidores y herramientas de Microsoft Corp. @luisdans

.productos Tutorial

Appcelerator Titanium ››Por Mauro Parra-Miranda

crea aplicaciones móviles nativas con javascript

itanium es una plataforma creada por la empresa Appcelerator que permite desarrollar aplicaciones para dispositivos móviles (iOS, Android y próximamente Blackberry) programando en Javascript. En este artículo conoceremos un poco sobre esta tecnología, sus ventajas y cómo comenzar a utilizarla para crear aplicaciones móviles.

Beneficios

Contrario a otras plataformas (como phonegap), Titanium genera aplicaciones nativas, por lo que se ejecutan con el desempeño y ventajas de una aplicación nativa. Básicamente, desde el ambiente de desarrollo de Titanium se crea la interfaz gráfica y se programa el comportamiento en javascript, y en base a esto el motor de Titanium genera un proyecto nativo en Xcode (en el caso de iOS) o un proyecto nativo de Android. Ya con esto, se puede compilar utilizando las herramientas correspondientes para generar ejecutables nativos para cada plataforma. Además de las ventajas de desempeño que ofrece el que se generen aplicaciones nativas, otra ventaja es que estas aplicaciones serán aceptadas en el Apple App Store sin problemas. La plataforma base de Titanium es software libre bajo licencia Apache 2 y es gratuito tanto para uso personal como comercial. Además de las ventajas de costo, el tener el acceso al código fuente nos permite verificar que no se esté inyectando ningún tipo de código malicioso en nuestra aplicación. Una de las grandes ventajas de programar en Javascript es que los desarrolladores pueden aprovechar sus conocimientos existentes con este lenguaje y aplicarlos para crear aplicaciones móviles nativas. Este es un gran logro, dada la escasez de programadores de iOS, debido a la misma juventud de la plataforma.

Acceso a capacidades de dispositivos

En el caso de iOS, se tiene soporte para dos tipos de dispositivos: iPhone/iPod Touch e iPad. Titanium soporta las siguientes bibliotecas/funcionalidades de iOS: • Acelerómetro, para detectar movimientos del dispositivo. • Analytics, para proveer estadísticas de uso. Se puede utilizar el de iOS o Google Analytics. • Contactos, para acceder el directorio teléfonico nativo. 10

• Bases de datos, acceso a bases de datos tanto locales como remotas por web services. • Facebook, acceso a funcionalidad de Facebook Connect y Facebook Graph API. • Filesystem, acceso al sistema de archivos, limitado a los permisos propios de la aplicación. • Geolocalización, acceso directo al GPS del dispositivo. • Gesture, reconocimiento de gestos en dispositivos con pantalla táctil. • Locale, para soportar varios idiomas en una aplicación de forma nativa. • Map, acceso a la API de Google Maps. • Media, acceso a imágenes, audio, películas, tanto de forma local como remota. • Network, acceso a la red y web services. • UI, acceso a la interfaz nativa del sistema operativo, con opciones especificas para cada dispositivo soportado. • XML, acceso a procesamiento de XML tanto remoto como local. • Yahoo, acceso a las APIs de Yahoo.

¿Cómo empezar?

A continuación mostraré un breve ejemplo de cómo crear una aplicación móvil con Titanium. Me enfocaré en iOS, debido a que actualmente es para lo que hay mayor demanda en México. Sin embargo, confío que en unos meses la demanda para Android aumente significativamente, y cuando eso suceda será muy sencillo migrar sus aplicaciones de iOS a Android con Titanium; en muchos casos, bastará con presionar un botón. Prerrequisitos: • Tener una computadora Mac con XCode instalado, el cual se puede obtener desde la Mac App Store ($4.99 USD) o registrándose en el programa de desarrolladores de iOS ($99 USD). • Descargar e instalar Appcelerator Titanium http://www.appcelerator.com/products/download Una vez cumplidos los prerrequisitos, podemos obtener de github la aplicación demo de Titanium llamada “Kitchen Sink” (https://github.com/appcelerator/KitchenSink).

Figura 2. Test & Package.

Figura 3. Compilación del javascript.

Figura 4. Estructura de directorios base.

Primero abrimos Titanium Developer y presionamos “Import Project”: En el cuadro de diálogo de archivos, seleccionamos el directorio de Kitchen Sink que clonamos de github. Esto populará la información del proyecto tal y como se muestra en la figura 1. Ahora seleccionamos la pestaña “Test & Package”. Por default te activará la pestaña para “iPhone” y en la parte inferior verás información sobre la versión del SDK a utilizar, así como el nivel de verbosidad de los mensajes (Filter) durante la compilación (ver figura 2). Presionamos el botón “Launch” para iniciar la compilación del javascript y podremos visualizar la actividad en la consola, tal como lo muestra la figura 3. Conforme pasa esto, explicaré la estructura de archivos del proyecto, la cual se ilustra en la figura 4. Entre los directorios importantes está el de “build” donde se generará el código nativo para android y iOS, “Resources” donde va el código fuente de javascript, e “i18n” para archivos de localización de región e idioma. Si revisemos el contenido de “build” encontraremos dos directorios, uno para iPhone y otro para Android. En el de iphone, veremos algo similar a la estructura mostrada en la figura 5. Este 11

www.sg.com.mx |

Figura 1. Información del proyecto.

Software Guru

.productos Tutorial

Figura 5. Estructura de directorios para iPhone.

directorio contiene el proyecto para XCode. Como ya explicamos, Titanium toma el código Javascript y lo transforma en un proyecto de XCode nativo. Una vez que Titanium termina de generar el proyecto para XCode, se inicia el simulador. En el simulador veremos la aplicación ya corriendo, tal como lo muestra la figura 6.

.productos Tutorial

››“Los desarrolladores pueden aprovechar sus conocimientos existentes con este lenguaje y aplicarlos para crear aplicaciones móviles nativas.”

Figura 6. Imagen del simulador.

Como se puede ver en la figura 7, en el tab de “Phone” se tiene toda la funcionalidad nativa del teléfono. Una de las cosas que mas me ha gustado es el acceso directo a la camara. Incluso, ¡se cuenta con soporte para realidad aumentada! En la empresa que dirijo hemos utilizado la funcionalidad de realidad aumentada y luego revisado el código para ver qué tan complicado había sido. Nos llevamos una agradable sorpresa, es algo bastante sencillo y de unas cuantas líneas. Si les interesa, en una siguiente ocasión podremos ahondar en este tipo de ejemplos. Les recomiendo revisar el código de los ejemplos que viene incluido en Kitchen Sink, porque de verdad explota toda la funcionalidad nativa que soporta Titanium, mostrando además lo sencillo que se vuelve crear aplicaciones para dispositivos móviles. En el mapa de capacidades futuras para Titanium está el soporte de Android para Tablets, así como BlackberryOS tanto para teléfonos como tabletas. 12

Figura 7. Funcionalidad a la que se tiene acceso.

Conclusión

Appcelerator Titanium es una herramienta que facilita significativamente el desarrollo de aplicaciones móviles, manteniendo las ventajas de las aplicaciones nativas. Los invito a que lo conozcan y comiencen a hacer sus aplicaciones, ya sea para iOS o Android.

.BIO Mauro Parra es arquitecto de aplicaciones móviles para diferentes empresas, incluyendo la suya. Se especializa en el desarrollo de aplicaciones web y móvies, en linux y en seguridad cibernética. Es embajador de OpenSuse y lo pueden encontrar en http://mechulk.com

.productos Un Vistazo

BlueVia

una plataforma de negocio para desarrolladores

››Por Andrés Leonardo Martínez

urante los últimos años, siguiendo una estrategia basada en innovación abierta, compañías de todos los ámbitos han adoptado estrategias de acercamiento a los desarrolladores de software. Fruto de estas iniciativas, numerosas plataformas aglutinan y capitalizan el espíritu innovador de miles de desarrolladores. A pesar de esto, el esfuerzo de estos desarrolladores ha sido compensado solo parcialmente, debido principalmente a la orientación técnica del soporte ofrecido y la ausencia de modelos de negocio definidos por estas plataformas. Tras la identificación de estas limitaciones y otras áreas de mejora, Telefónica ha diseñado una nueva plataforma que está centrada en la perspectiva del desarrollador y sus necesidades de monetización. Esta plataforma se llama BlueVia, y en este artículo conoceremos un poco más sobre ella.

Principios

Durante los últimos 4 años, Telefónica ha llevado a cabo varias iniciativas relacionadas con desarrolladores. Litmus en el Reino Unido, Open MovilForum en España, las plataformas Movistar de desarrolladores en México y Argentina, y la plataforma Vivo en Brasil, constituyen los ejemplos más significativos. A lo largo de este tiempo, los desarrolladores han contribuido con sus experiencias, pero también con sus recomendaciones. Teniendo en cuenta esta experiencia y retroalimentación, así como las sugerencias planteadas por el informe Mobile Economics Report 2010 [2,3] y la colaboración estrecha con partners como Nokia, Microsoft, Oracle y RIM, Telefónica creo una nueva plataforma global para desarrolladores denominada BlueVia. Esta plataforma se fundamenta en los siguientes principios: • Escala. Las dificultades de monetización se contrarrestan ofreciendo escala y visibilidad. Por tratarse de una oferta global, el conjunto de más de 280 millones de clientes de Telefónica se integran en el mercado potencial. La posibilidad de integrar la facturación en el consumo prepago o mensual, sin duda resulta de alto valor en regiones en las que es tan común contar con una cuenta bancaria o una tarjeta de crédito. • Herramientas. Si bien esta característica es común en muchas plataformas, la principal novedad de BlueVia es su agnosticismo en términos de lenguaje y sistema operativo. Cualquier plataforma capaz de realizar llamadas HTTP puede integrar BlueVia. Además, con el fin de reducir la curva de aprendizaje y neutralizar la fragmentación se facilitan SDKs en distintos lenguajes como C#, Java, PHP o Ruby, pudiendo utilizarse en sistemas operativos como Android, iOS, Linux, Windows Phone, o Blackberry. • Modelos de negocio. BlueVia introduce mecanismos que 14

permiten implementar modelos de negocio de flujos de caja recurrentes por medio de un modelo de suscripción. También se introduce un esquema de beneficio compartido en el uso de capacidades de red. Es decir, el desarrollador monetiza el uso que sus clientes hacen de las capacidades de red de BlueVia (por ejemplo, envío de SMS desde una aplicación). • Acceso al mercado. Una de las limitaciones más importantes que presentan las plataformas actuales es la visibilidad. Los desarrolladores arrojan sus aplicaciones a un océano competitivo donde es muy dificil llegar a los clientes potenciales; el canal de venta se convierte en un canal ciego. BlueVia ofrece el canal exclusivo hacia sus clientes y proporciona información a los desarrolladores, en forma de API y de informes exclusivos, que permite mejorar el foco, teniendo en cuenta la diversidad derivada del enorme número de clientes y diversidad geográfica. Por último, la introducción de mecanismos de liquidación de saldos al desarrollador mediante PayPal o transferencia bancaria, así como el pago en una moneda única (euros), simplifica enormemente el acceso a mercados globales, lo que permite al desarrollador centrar su atención en la creación de buenas aplicaciones.

APIs y modelos de negocio

Además de las mejoras en el contexto de gestión de la innovación, recursos de red y relación con “stakeholders”, los desarrolladores tendrán interés en conocer cuáles son los mecanismos de monetización con los que cuenta BlueVia y muy especialmente aquellos que permiten implementar flujos de caja recurrentes. BlueVia introduce los siguientes modelos de negocio: • APIs de red. Esta categoría permite la definición de flujos de ingresos recurrentes. Si tu aplicación recibe mensajes (SMS o MMS) de otros usuarios, el beneficio compartido es de 20%. Si tu aplicación es la que envía los mensajes a otros usuarios, el beneficio compartido es de 10%. • Publicidad. Este API ofrece la posibilidad de integrar publicidad, en forma de texto o imagen, en las aplicaciones de los desarrolladores, recompensando con un 50% de los ingresos producidos. • Suscripciones. El desarrollador puede ofrecer un servicio en modo suscripción por el que cobra un precio correspondiente a un periodo de tiempo predefinido. El beneficio compartido es del 70%. • Venta de aplicaciones. Este es el modelo de negocio más común actualmente. El porcentaje de beneficio compartido es del 70%. A diferencia de los otros ingresos, este es un ingreso único que se produce solo en la venta de la aplicación.

De manera complementaria, se ofrece de manera gratuita un API de información contextual sobre los usuarios, que incluye información de las características de dispositivo, rango de consumo y otros detalles que permiten segmentar las aplicaciones en función de estas características. Adicionalmente, el acceso a estas capacidades se hace sin tener que adquirirlas por adelantado y siguiendo un proceso de registro vía web. En términos económicos, no existen costos de infraestructura por las capacidades utilizadas. BlueVia también proporciona un importante soporte en términos técnicos, sobre todo teniendo en cuenta el mundo en el que hasta ahora se movían las operadoras. Como planteamiento fundamental, en términos técnicos, las capacidades de red se ofrecen a través de APIs web, basadas en estándares como JSON o XML, y basadas en autenticación oAuth.

Conclusión

En un contexto de enorme competencia entre diferentes plataformas de desarrolladores, la incorporación de beneficios recurrentes derivados de las capacidades del operador constituye una innovación que determinará la viabilidad de numerosos desarrollos. Los desarrolladores, encontrarán en este esquema una gran ventaja. Esto puede equilibrar la situación actual donde el desarrollador cuenta con escasas oportunidades de monetización. Sin duda, a lo largo de los próximos meses, la introducción de nuevas APIs y esquemas de monetización constituirá una revolución dentro del mundo de las aplicaciones para movilidad.

Referencias: [1] http://www.bluevia.com [2] http://blog.insomne.org/2010/12/14/mobile-developer-economics-20102011 [3] http://www.visionmobile.com/BlueVia

.BIO Andrés Leonardo Martínez Ortiz es BlueVia Developer Program Engineer. almo@bluevia.com

.EMPRENDIENDO

La Importancia de una Bolsa de Valores para Empresas de Innovación ››Por Víctor Chapela

Este artículo es una versión editada de la nota titulada: “México: Innovar o Morir” del blog personal del autor. http://victorchapela.com/2011/03/13/mexico-innovar-o-morir/

urante años he estado promoviendo la necesidad de políticas públicas e iniciativas privadas para impulsar a México hacia una economía del conocimiento. Hay muchas visiones de cómo lograr este objetivo. En este documento propongo una acción puntual, la creación de una bolsa intermedia de valores para empresas de innovación.

Economía basada en innovación

El Foro Económico Mundial (WEF) publica anualmente un estudio comparativo de las economías del mundo. De acuerdo a este estudio, los países más desarrollados son aquellos que han transitado a una economía basada en la innovación. La innovación es ampliamente vista como un generador estratégico de competitividad en el largo plazo. Es el único “bien” que no padece de tasas de retorno decrecientes. Esto es especialmente cierto para los países que están en la frontera tecnológica. Para ellos, la capacidad de generar productos, servicios o procesos innovadores es esencial para el crecimiento sostenido. México debería tomar conciencia de su propio potencial innovador. Cualquier estrategia de desarrollo nacional debería incluir la meta de establecer un ecosistema que fomente la innovación [1]. Para que la innovación se consolide como una ventaja competitiva del país, no basta que se diseñe y desarrolle en México. Tiene que ser comercializada por empresas mexicanas [2]. Esto es un punto importante al pensar en la 16

.EMPRENDIENDO

Habiendo fundado o participado en la creación de más de diez empresas de tecnología e innovación en México y otros países, considero que hay tres elementos esenciales para el desarrollo de este tipo de emprendimientos: profesionistas creativos, emprendedores motivados y acceso a capital de riesgo o financiamiento.

Profesionistas creativos

En las últimas décadas México se ha enfocado principalmente a la producción industrial y la maquila. El problema de este enfoque es que depende de mano de obra barata, por lo que muchos profesionistas no encuentran una remuneración adecuada. Esto deriva en que seamos el tercer mayor exportador de profesionales del mundo. A la fecha, más de un millón de profesionistas, que estudiaron en México, viven en el extranjero. Profesionales entusiastas que se han marchado en busca de mejores horizontes, mejores ingresos y entornos adecuados donde puedan desarrollar sus ideas. Esta terrible situación no puede sino provocarnos un sentido de urgencia al no poder retener el talento, que es el ingrediente principal de la innovación. La creatividad y adaptabilidad de los profesionistas mexicanos es conocida y reconocida internacionalmente. Desde hace muchos años se nos considera mano de obra sofisticada. Pero la falta de competencia interna en las principales industrias y la falta de estímulos gubernamentales efectivos han desincentivado la innovación en las empresas mexicanas. Esto ha provocado a que no se valore competitivamente a los profesionistas e investigadores en nuestro país, al no apreciarse el valor intangible que podrían aportar a nuestras empresas y economía.

Emprendedores motivados

En países desarrollados, la innovación se lleva a cabo predominantemente por pequeñas y medianas empresas. El 60% del PIB alemán proviene de empresas de menos de diez personas y la mayoría de ellas exporta internacionalmente [3]. ¿Por qué en México no hemos logrado algo semejante? ¿Por qué, según el WEF, de 139 países, México ocupa el lugar 78 en innovación? 17

Acceso a capital de riesgo

El proceso de innovar, por naturaleza, es impredecible, su resultado es incierto y requiere de una forma de organización diferente a la de las empresas establecidas. Las empresas exitosas se organizan en torno a planes de trabajo predecibles y utilizan la información histórica para poder calcular con certeza aceptable el retorno de .BIO inversión. DesafortunadamenVíctor Chapela es Presidente y Director General de Sm4rt Security te, esto sólo permitiría que las Services, empresa especializada en Seguridad Informática. Tiene grandes empresas innoven de más de 25 años de experiencia en forma incremental al desarrollar emprendimientos tecnológicos. y ha fundado diez empresas en nuevos productos y hacer meMéxico y Estados Unidos incluyendo DigiLab, Celebrando.com, joras a procesos continuos [5]. TrueCentric y Sm4rt. Cualquier innovación disruptiva no encuentra un terreno fértil en los corporativos mexicanos. Sin Referencias: [1] Klaus Schwab, et al. The Global embargo, es en las innovacioCompetitiveness Report 2010-2011, World nes disruptivas donde se genera Economic Forum. Pág. 238. [2] Amar Bhidé. “Where innovation creamayor valor. No hay la cultura, tes value”. McKinsey Quarterly, Feb 2009 http://bit.ly/sg32r3 ni los mecanismos, ni los in[3] Rocío Senra, et al. “Alemania, el primer país de la UE”. http://bit.ly/sg32r4 centivos adecuados para que los [4] William W. Lewis. “The Power of Prograndes corporativos mexicanos ductivity: wealth, poverty, and the threat to global stability”. McKinsey & Co. Inc, innoven de esta forma. University of Chicago Press, 2004. [5] Vijay Govindarajan, et al. “The other El emprendedor en México side of innovation – Solving the execution no tiene acceso al financiamienchallenge”. Harvard Business Review Press. Boston, 2010. to apropiado ni al capital de riesgo adecuado.

Software Guru

¿Qué condiciones requiere un ecosistema de innovación?

En el caso de las grandes empresas, la falta de innovación es en parte por la carencia de modelos organizacionales y de planificación adecuados, pero más que nada porque no tienen necesidad de innovar debido a la escaza competencia que enfrentan. De acuerdo al estudio de McKinsey “The Power of Productivity” [4], el desarrollo económico de un país y la necesidad de innovación en las empresas son ambas producto de la competencia en los productos y servicios. La falta de competencia en la mayoría de las industrias del mercado mexicano, así como la sobreconcentración y dominancia en industrias estratégicas, como son las industrias financiera, energética y de telecomunicaciones, impiden que la innovación sea un mecanismo deseable o necesario para competir. Al tener una posición dominante con barreras de entrada muchas veces infranqueables, la mayoría de las empresas exitosas mexicanas no requieren de la innovación como elemento diferenciador. Todo esto no sólo limita a que la innovación nazca y se mantenga sana en las grandes empresas mexicanas, sino que adicionalmente carecen de incentivos para integrar y adquirir tecnologías o empresas innovadoras. Esta falta de incentivo limita el mercado de los emprendedores y las opciones de salida de los inversionistas por lo que aumenta el riesgo y reduce el beneficio de innovar en México. Por otro lado, esperaríamos que, como en muchas otras partes del mundo, fueran las empresas pequeñas y medianas las que se constituyeran en el motor de la innovación disruptiva. Sin embargo, las PyMEs en México no tienen una ruta de crecimiento saludable. Para innovar se requiere inversión; no para pensar la idea, sino para ejecutarla. Pero este tipo de empresas en México carecen de opciones de acceso a capital y por ende tienen una desventaja grande frente a empresas equivalentes en países desarrollados.

www.sg.com.mx |

investigación y desarrollo. Es necesario que las empresas innovadoras tengan el capital y recursos necesarios para comercializar de forma competitiva sus productos y servicios en el mundo.

.EMPRENDIENDO

Requiere de garantías inmobiliarias para obtenerlo. Estas garantías impiden la movilidad social, ya que solo permiten innovar al que ya tiene un patrimonio sustancial anterior. Para el emprendedor tecnológico la situación empeora, porque sus activos principales son intangibles y estos no son reconocidos ni cuantificables en México. El capital para innovar viene generalmente de una o más de las siguientes fuentes: 1. Pasivos - financiamiento bancario o bursátil. 2. Utilidades - la reinversión del resultado de ejercicios anteriores. 3. Capital de riesgo - de inversionistas externos o de los emprendedores. Estos tres mecanismos de acceso a capital están fundamentalmente rotos en México. Si revisamos estos rubros encontraremos que las condiciones a las que está sometido el emprendedor mexicano incrementan el riesgo muy por encima del retorno esperado. Esto genera un entorno adverso que desincentiva al “emprendedor natural”: jóvenes talentosos con ideas innovadoras.

Innovación = idea + ejecución

La innovación no consiste en tener la mejor idea. Debemos estar conscientes de que en otras partes del mundo surge ideas similares de forma simultánea. La innovación exitosa es aquella que es mejor ejecutada. Al emprender e innovar, la empresa que gana y recoge la gran mayoría de los beneficios es aquella que ejecuta mejor y más rápido. La ejecución consiste en el proceso de convertir una idea de innovación en un impacto en el mercado. Desde el diseño y producción, hasta la comercialización e implantación. Para lograr una ejecución rápida y efectiva se requiere de experiencia y capital. La experiencia puede ser subcontratada a proveedores en cualquier parte del mundo. Sin embargo, para que el retorno de la inversión pague impuestos en México y genere crecimiento y desarrollo local, las empresas que comercialicen la innovación deben ser fundadas en nuestro país. Estas empresas deben estar subordinadas a las leyes e instituciones locales, pero dependen también de la confianza internacional hacia nuestro país. Por lo anterior, el capital de riesgo extranjero rara vez es invertido en empresas mexicanas. Además de la desconfianza en las leyes e instituciones locales, hay un problema aún más profundo, la falta de estrategias de salida.

Capital de riesgo y estrategias de salida

En países desarrollados el ecosistema financiero busca canalizar recursos económicos a las empresas y personas innovadoras con las mejores probabilidades de éxito. Los mecanismos tradicionales para lograr esto son los “venture capitalists”, es decir, los inversionistas de capital de riesgo. El capital de riesgo requiere “estrategias de salida”, formas de desinvertir y monetizar el valor incremental que se haya generado en la empresa durante el tiempo que dura la inversión. Los inversionistas de riesgo generalmente necesitan salirse en un lapso de 5 a 7 años. Esto lo logran principalmente de dos formas: vendiendo la empresa a un corporativo o cotizando en el mercado de valores. En México la venta de las empresas captura muy poco valor al haber poca competencia por comprar las empresas y por 18

la falta de necesidad de innovar como un mecanismo de competencia de los grandes corporativos. Por otro lado, la carga regulatoria y el tamaño que debe tener la empresa para cotizar en la bolsa local lo vuelve un mecanismo de salida no viable para empresas de 5 a 7 años de edad. El capital de riesgo en México tiene muy pocas opciones para recuperar su inversión, esto origina que la mayoría de la innovación la fondee el emprendedor. Esto limita enormemente el potencial de nuestro talento al no tener una capacidad de ejecución equivalente al de sus competidores internacionales.

Los emprendedores financiando la innovación

Para el emprendedor, el efecto de tener que aportar todo el capital de riesgo y el colateral para préstamos significa que si el emprendimiento falla, es él quien pierde todo, no tiene forma de compartir el riesgo. En casi todas las opciones de arranque, los emprendedores requieren presentar como garantía un bien inmueble de tres veces el valor del crédito; lo mismo sucede para poder obtener una fianza para rentar un oficinas o recibir un anticipo de un cliente mayor. Los emprendedores que no cuentan con un bien inmueble totalmente pagado están muy limitados en su capacidad de ejecución. El emprendedor promedio “en el mundo” es joven y aún no tiene bienes inmuebles propios. a. La falta de un bien inmueble impide rentar locales comerciales y promueve la economía informal, que resulta ser lo único accesible para el emprendedor promedio en México. b. Si la innovación es algo que se le vende a empresas más grandes, la cultura de pago en México que consiste en “jinetear” el dinero, le hace muchísimo daño al flujo de caja del emprendedor. Tanto el gobierno como las grandes empresas tienen políticas que retrasan sistemáticamente todos los pagos en lapsos que van desde 30 hasta 180 días. Las pequeñas empresas –sin acceso a financiamiento− se ven obligadas a financiar a sus clientes más de 60 días en promedio, y esto sin considerar los tiempos previos de venta, producción y operación. ¿Cuántos emprendedores pueden resistir esto? ¿Cuánto pueden crecer y a qué velocidad, con sus propios recursos? c. Finalmente, si los emprendedores quieren tener acceso a capital se enfrentan al hecho de que en México no se financian ideas o equipos de personas, principalmente porque los inversionistas de riesgo no advierten mecanismos para recuperar su inversión. Aun si nuestras empresas son exitosas, no hay en México un mercado sano de compra-venta de empresas innovadoras o de acciones de las mismas. Una consecuencia ulterior de lo que se ha mencionado es el impacto de esta problemática sobre la movilidad social. La innovación, que debería propiciar la movilidad social, sencillamente no funciona si los emprendedores necesitan bienes inmuebles y capital propio antes de innovar o emprender. No obstante, en base a mi experiencia, el inversionista capitalista no deja de invertir en innovación mexicana porque no haya posibilidades de éxito o porque sea muy riesgoso, sino debido al bajo retorno al momento de vender su posición ya que no hay mecanismos de salida que generen liquidez en el mercado. El resultado final es que la forma más viable de innovación en Méxi-

Estrategias de salida

Las compras de empresas de innovación en México se valúan en promedio entre 3 y 6 veces EBITDA (utilidad antes de intereses, impuestos, depreciación y amortización). En cambio en países desarrollados ese número oscila entre 8 y 15 veces; es una diferencia abismal. La escasez de compradores, al tener México jugadores dominantes en casi todas las industrias estratégicas, impide que se genere competencia para adquirir la empresa innovadora, empujando los precios hacia abajo. Esto, aunado a la reducción de precios a proveedores, que, dicho sea de paso, constituye el deporte nacional de las áreas de compras de los clientes naturales de las empresas de innovación, redunda en una considerable merma de las utilidades y por ende, del EBITDA de las mismas. Múltiplos bajos y rentabilidad baja en el mercado local afectan de forma fundamental el retorno de cualquier inversión. La falta de capital es el gran obstáculo para que las empresas “productifiquen” sus ofertas y puedan competir a nivel internacional. Lastimosamente, hacen y terminan haciendo productos y servicios a la medida para cada cliente, y quedan vulnerables ante los productos empaquetados que han sido desarrollados en el extranjero. El tener un abanico más amplio de estrategias de salida beneficiaría a toda la cadena de valor al permitir que los inversionistas de capital de riesgo pudieran invertir con mayor certeza, reduciendo con ello la carga para el emprendedor y dejando la estructura corporativa más sólida para recibir préstamos. Esto fomenta la inversión en innovación, con el efecto agregado de que los inversionistas recuperan su inversión y los emprendedores retienen un parte mayor del valor generado. Esto permite a la larga un ciclo virtuoso de reinversión.

Bolsa intermedia para empresas de innovación

La solución puntual más efectiva es hacer algo que pueda ser llevado a cabo con intereses privados y que requiera de forma mínima de la intervención del gobierno. La resolución de aspectos como la seguridad jurídica, requerimientos de colaterales inmobiliarios, o inclusyo cambio de leyes y reglamentos, implica esperar muchos años, una buena dosis de voluntad política y condiciones especiales fuera de nuestro control. No podemos apostar a que esto sucederá en nuestro país, mucho menos en el corto plazo. Por ello, necesitamos crear una bolsa de valores intermedia especializada en pequeñas y medianas empresas de innovación, con un esquema de baja regulación. Esto permitiría complementar el ecosistema actual y tendría numerosos beneficios para el país. Las siete ventajas principales serían: 19

Permitir la valoración y la valuación de mercado de los activos intangibles contenidos en toda innovación. Un mercado de valores público es el medio que mejor se aproxima al valor real y potencial de la innovación. Canalizar recursos baratos a los innovadores más exitosos. Esta medida permitiría acceso no sólo a capital, sino que a raíz de esa capitalización también se abriría el acceso a créditos bancarios de bajo costo. Aumentar la distribución de la riqueza a los emprendedores. Esto evitaría que el valor de la innovación se concentrara en los grandes oligopolios existentes. Y al final del ciclo generaría nuevos inversionistas de capital de riesgo. Proveer un mecanismo de salida para los inversionistas de capital de riesgo, reduciendo el riesgo inherente de sus inversiones y logrando con ello un incremento en su apetito de inversión en este tipo de emprendimientos. Mejorar la postura competitiva de las empresas de innovación frente a los corporativos multinacionales. Esto permitiría que una mayor parte de la innovación sea comercializada por empresas mexicanas y se retenga con ello los beneficios de crecimiento, impuestos y trabajos bien remunerados para nuestro país. Reducir los requerimientos de control para hacer la oferta pública. Se buscaría eliminar el costo exorbitante que implica la regulación actual para una pequeña empresa. Esto se podría lograr utilizando un sistema jerárquico de corresponsabilidad donde la casa de bolsa o banquero de inversión que hace la oferta pública tenga la responsabilidad de gobernanza y supervisión sobre el uso adecuado de los recursos. Fomentar la atracción de talento a través de mecanismos de opciones futuras de acciones (stock options) para empleados. Los mecanismos de opciones son el principal instrumento para atraer talento en las empresas extranjeras, ya que permiten compartir el valor incremental futuro de la empresa con los empleados clave.

Conclusión

El mundo ha cambiado. La naturaleza competitiva de un país está íntimamente ligada a su capacidad de generar y comercializar innovación. Hay una ventana de oportunidad que se ha estado cerrando, tenemos poco tiempo para salvar a México del naufragio. En general hay pocas cosas que se pueden hacer desde la iniciativa privada y sin voluntad política. Sin embargo, este esfuerzo puntual, si logra estar bien encaminado y permanecer enfocado puede tener una incidencia de fondo en nuestro país. Hay una gran codependencia entre los elementos que impulsan una economía del conocimiento orientada a la innovación. Los profesionistas talentosos, los emprendedores motivados y el capital de riesgo deben estar disponibles y alineados. Es importante incidir en los tres aspectos de forma simultánea para generar una coevolución y un ciclo virtuoso. Considero que una bolsa intermedia para empresas de innovación cumple este propósito de forma efectiva y eficiente. Hagámoslo por el país desarrollado en el que queremos vivir. Hagámoslo por aprovechar el enorme talento que tenemos los mexicanos. Hagámoslo por las oportunidades que nos abre como profesionales, emprendedores e inversionistas. Hagámoslo por nuestros hijos que esperan lo mejor de nosotros. Es la mejor herencia que podemos dejar. No merecen ni merecemos menos.

www.sg.com.mx |

co se logra a través de reinvertir las utilidades del emprendedor. Esta mecánica tiene como grave desventaja que la rentabilidad de las pequeñas y medianas empresas tiende a ser insuficiente para ejecutar todo el ciclo de diseño, desarrollo y comercialización de la innovación de forma suficientemente rápida y competitiva como para ganar y sostener mercados locales o internacionales. La competencia en innovación es global. El que comercializa primero la idea se queda en general con el mayor beneficio. Si consideramos la misma idea siendo ejecutada en paralelo en México y en otros país desarrollado, la capacidad de ejecución de la empresa extranjera, mejor fondeada, será mucho mayor que la mexicana que tiene que usar sus propios flujos para innovar y comercializar.

Software Guru

.EMPRENDIENDO

La Nube en el Ámbito Empresarial caminos de adopción

Como

ya es bien sabido, el cómputo en la nube provee ventajas significativas para disminuir costos y aumentar la flexibilidad de los recursos TIC. A pesar de ello, en una gran cantidad de empresas todavía no se tiene un camino claro de adopción de este paradigma. En este artículo compartimos un panorama de caminos de adopción posibles para las empresas, así como algunos casos prácticos específicos.

Modelos de despliegue

Antes de revisar qué camino(s) tomar, vale la pena que nos pongamos de acuerdo sobre los distintos modelos de despliegue posibles: • Nube privada. Es operada específicamente para una organi21

zación o empresa. La infraestructura puede ser manejada por la misma empresa (in-house) o por un tercero. • Nube pública. La infraestructura está disponible al público en general por lo que logra grandes economías de escala por medio de grandes volúmenes de usuarios. Nótese que la infraestructura es propiedad de una empresa que provee servicios en la nube. • Nube de comunidad. En este escenario, varias organizaciones con intereses similares comparten recursos de infraestructura. • Nube híbrida. Se refiere a la combinación de diversos modelos de nube, donde cada uno está separado pero se habilita el intercambio e integración de datos y aplicaciones entre éstos.

www.sg.com.mx |

Este artículo está basado en el whitepaper titulado “Cloud Computing II” desarrollado por la empresa T-Systems y que está disponible en http://bit.ly/tsystems-papers. Agradecemos a T-Systems México por permitirnos traducir y editar este artículo.

Software Guru

.Principal

Economías de escala

Todos los modelos de despliegue en la nube generan economías de escala que resultan de ejecutar aplicaciones sobre una base de infraestructura común. La figura 1 ilustra como los distintos modelos de nube pueden generar economías de escala en dos sentidos. El eje de la Y refleja las economías obtenidas al aumentar la cantidad de usuarios atendidos por una infraestructura común. Como es de imaginarse, este es el escenario donde destacan las nubes públicas. Por otro lado, en el eje de la X se muestran las economías obtenidas al soportar distintas tecnologías y aplicaciones en una infraestructura común. Este es el enfoque que tienen las nubes privadas.

Nube privada

Bajo la estrategia de nube privada, las empresas pueden obtener algunos beneficios del cómputo en la nube ya sea en su centro de datos in-house o con un proveedor. En el aspecto técnico, ganan flexibilidad y estandarización en su infraestructura de TI, manteniendo un alto control sobre los recursos, servicios y datos almacenados. La estandarización y mejor utilización de los recursos trae beneficios en reducción de costos, aunque por supuesto no se puede esperar los mismos niveles de ahorro que se obtendrían con nubes públicas. Uno de los principales beneficios de este escenario es que se pueden establecer arquitecturas personalizadas a los requerimientos específicos de los clientes. Es así que las nubes privadas son las que mejor pueden satisfacer requerimientos legales y de cumplimiento de normas para el manejo y procesamiento de información.

Nube pública

En el contexto empresarial, las nubes públicas tienden a ser utilizadas en dos escenarios principalmente: a) Situación específica. Por ejemplo, durante las etapas de desarrollo o pruebas de los proyectos puede ser más conveniente utilizar una nube pública que conseguir un servidor in-house. b) Largo plazo. Se refiere a situaciones donde se espera un uso continuo y a largo plazo. Por ejemplo, la adopción de un CRM en la nube. Los corporativos ya han comenzado a reemplazar aplicaciones existentes por ofertas SaaS (Software as a Service) en la nube pública. Por 22

ejemplo, migrar de servidores de correo in-house de Microsoft Exchange al servicio Exchange Online, o incluso a Google Mail. En este caso, no se está migrando de aplicaciones, sino simplemente dando el salto a ofertas que ya han sido probadas en el contexto del consumidor.

Nube de comunidad

Las nubes de comunidad normalmente están disponibles solo para un grupo específico de usuarios, como podrían ser los de algún sector industrial. Los partícipes en nubes de este tipo pueden establecer mecanismos de colaboración inter-organizacional, apoyada en estándares y certificaciones de la industria. Las nubes de comunidad típicamente requieren de un proveedor de servicios de TIC con buen conocimiento de la industria correspondiente, incluyendo los requerimientos de seguridad y normatividad que apliquen en ella. Por ejemplo, Siemens está desarrollando una nube de comunidad para el sector salud. Otras nubes especializadas en una vertical son Flock IT en Australia y Dealer Track en Estados Unidos. También existen nubes de ámbito nacional, como Kasumigaseki Cloud en Japón o el proyecto Nebula de la NASA. En particular, las nubes de comunidad habilitan a las pequeñas empresas para entrar a la nube y obtener beneficios en reducción de costos. Un riesgo de este tipo de nube puede ser el quedar atado (lock-in) a un proveedor, debido a que es de esperarse que haya pocas alternativas.

Nube híbrida

Las nubes híbridas combinan, entre otras cosas, el bajo costo de las nubes públicas con el control de las nubes privadas. Puede parecer lo mejor de dos mundos, sin embargo requiere definir con gran precisión los requerimientos de la organización. Además, la adopción de un esquema híbrido involucra ajustes e integraciones que pueden impactar aspectos tecnológicos, de procesos, organizacionales e incluso legales. Es así que las empresas de consultoría e integradores de sistemas encontrarán grandes oportunidades para ofrecer servicios alrededor de este segmento.

Ejemplos prácticos

A continuación describimos algunos casos prácticos de adopción de cómputo en la nube en el ámbito corporativo.

.Principal

Figura 1. Economías de escala de los modelos de nube.

c. Nubes públicas para proyectos específicos de corta duración. Un ejemplo de lo sencillo que es obtener ahorros por medio de la utilización de nubes públicas es el del New York Times. Ellos tenían la necesidad de convertir 11 millones de artículos e imágenes a formato PDF para hacerlos disponibles por Internet. Su departamento de TI estimó que requerían adquirir hardware por 150,000 USD y que tardarían 7 semanas en completar la conversión. En vez de adquirir el hardware, decidieron utilizar 100 instancias de Amazon Elastic Compute Cloud. La conversión se hizo en 24 horas en lugar de 7 semanas y costó el 1% de lo que hubiera costado adquirir el hardware. d. Migración a SaaS. Un ejemplo común de adopción de servicios de nube pública es la utilización de SaaS como Google Apps, Salesforce CRM o Microsoft Office 365 en lugar de tener este software instalado localmente. Jaguar Landrover recientemente tomó la decisión de migrar 14,500 usuarios a Google Apps. Para ellos, las 23

e. Escenarios híbridos. Las cuentas de correo electrónico brindan un escenario típico para la adopción de una estrategia híbrida. Por ejemplo, una empresa puede decidir adoptar Microsoft Office 365 por razones de costo, pero por cuestiones de seguridad desea mantener algunas cuentas de correo específicas en servidores locales. Para lograr esto se asignan roles específicos a cada empleado dependiendo de su función, y en base a ese rol se asigna en donde se almacena su buzón de correo. Esto no es algo trivial, ya que también se debe implementar la gestión de roles y se debe soportar que un empleado pueda cambiar de rol (y por lo tanto de proveedor de servicio). Para ello, todos los proveedores de servicio deben poder acceder un Active Directory compartido, y los procesos ITIL correspondientes deben ser establecidos. f. Nubes de comunidad. Una implementación real de una “plataforma de procesos y servicio” es el servicio “Kindergarten Online” de la ciudad de Friedrichshafen, Alemania. Por medio de una aplicación web, los padres de familia pueden descubrir la ubicación de jardines de niños (kindergarten), así como sus detalles (horarios, concepto educativo, infraestructura). Una vez que encuentran un lugar que les guste, desde la aplicación pueden reservar un espacio para su hijo(a) en un máximo de 3 kinders ordenándolos por prioridad. La petición se envía al primer lugar elegido, y en caso de que no haya lugar disponible se envía al siguiente. Los administradores de los kinders también se benefician de este sistema, ya que les facilita muchas tareas administrativas. Por último, el gobierno municipal obtiene información transparente sobre la demanda y utilización en cada kinder. Los distintos usuarios (padres, kinders y gobierno) de esta comunidad lo acceden por medio de distintos portales. Cada grupo de usuarios tiene privilegios distintos y solo puede acceder la información que le corresponde. Este sistema fue implementado y es administrado centralmente por T-City, que es una alianza entre Deutsche Telekom y el gobierno de la ciudad de Friedrichshafen.

Software Guru

b. Servicios dinámicos en nubes públicas. Algunos proveedores también están ofreciendo capacidades de aprovisionamiento rápido de sistemas de software sobre nubes públicas. Por ejemplo, T-Systems está desarrollando una oferta de “SAP Landscape as a Service” por medio de la cual se podrá aprovisionar un entorno SAP completo en cuestión de minutos en una nube pública. Este tipo de esquemas no solo son aplicables a sistemas empresariales, sino a cualquier tipo de solución de software. Estos servicios facilitarán significativamente la replicación de ambientes para pruebas, así como la evaluación de nuevas soluciones.

limitantes que pudiera tener esta plataforma eran mucho menores que sus ventajas. La estandarización les brindó una oportunidad para mejorar la transparencia de su ambiente de TI. Adicionalmente, obtuvieron ahorros significativos no solo en cuanto al pago de licencias sino también en cuanto al costo de mantenimiento y personal de administración.

www.sg.com.mx |

a. Servicios dinámicos por medio de nubes privados. Los servicios de TI que están sujetos a regulaciones (protección de datos, leyes financieras, etcétera) son buenos candidatos para proveerse como servicios dinámicos en nubes privadas. Esta estrategia permite a las organizaciones adquirir recursos de TI de forma dinámica, bajo un modelo de pago por uso. Un ejemplo de este servicio es la oferta Dynamic Services de la empresa T-Systems, la cual ofrece ya más de 100 soluciones de esta forma. Por ejemplo, para un grupo petrolero internacional, T-Systems transfirió 232 sistemas de SAP a una plataforma dinámica. Gracias al modelo de pago por uso así como la consolidación y dinamización de la infraestructura, la empresa obtuvo ahorros por más de 100 millones de dólares.

.PRINCIPAL

Este artículo está basado en el whitepaper “Cloud Management Guide” disponible en http://bit.ly/sg32r13. Esta versión fue traducida y editada por SG con el permiso del autor.

Guía para la Gestión de la Nube un vistazo a las opciones ››Por Carlos Escapa

Conforme

las organizaciones suben cada vez más datos a la nube, la administración de estas nuevas infraestructuras se está convirtiendo en el principal desafío para las organizaciones de TI. Esta guía provee un panorama sobre el mercado de soluciones para administración de información y aplicaciones en la nube, así como consejos sobre cómo comparar a los proveedores principales y sus ofertas. Comencemos con un poco de antecedentes sobre los aspectos con los que lidia la gestión de cómputo en la nube.

Primero vino la virtualización

La adopción de la virtualización en centros de datos continúa acelerándose. De hecho, IDC afirma que los clientes ahora piensan en la virtualización como primera opción, lo cual se refleja en el aumento de 16% en servidores virtualizados implementados en el último año. Además, IDC prevé que 36 millones de nuevos servidores virtuales se implementarán durante el próximo par de años, lo cual representa crecimientos anuales de doble dígito. Dentro de los próximos 12 a 18 meses, se estima que cerca de la mitad de las cargas de trabajo en centros de datos a nivel mundial se ejecuten de manera virtualizada. El principal factor que impulsa la virtualización es la reducción de costos al aumentar la utilización de hardware (menos del 10% de la capacidad de la CPU se utiliza en promedio, de acuerdo con Gartner). La virtualización aumenta dramáticamente esa proporción de eficiencia, pero no puede plenamente optimizar la utilización de hardware, mientras que seres humanos aún tomen las decisiones sobre dónde y cómo son virtualmente implementados los servidores.

Llegó el cómputo en la nube y su gestión

Con millones de nuevos entornos virtuales por aprovisionar, es fácil ver por qué la virtualización, por necesidad, está evolucionando hacia el cómputo en la nube, donde los recursos son dinámicamente y automáticamente 24

aprovisionados y administrados por software y no por seres humanos. Este nuevo mercado de software está llegando a ser conocido como Gestión de la Infraestructura de la Nube o simplemente Gestión de la Nube. El software de gestión de la nube es un software de infraestructura que tiene las siguientes características principales: • Aprovisiona dinámicamente los recursos de infraestructura (servidores, almacenamiento y redes) para la nube (privada, pública o híbrida). • Asegura que los recursos abastecidos puedan ser consumidos de forma segura por las empresas virtuales. • Proporciona planificación de capacidad centralizada, monitoreo, informes y a veces incluso la cobranza de todos los recursos de infraestructura (físicos o virtuales) utilizados en la nube.

Beneficios del software de gestión de la nube

Al utilizar una consola única de administración, el software de gestión de nube aprovecha las diferentes islas de potencia de cálculo tanto en el mundo físico como en el virtual. Como resultado, una herramienta completamente funcional de software de la Administración en la Nube enterprise puede utilizarse para: • Adaptar los procesos de negocios de TI para proporcionar la potencia de cálculo como una utilidad. • Definir diferentes niveles de servicios computarizados, con diferentes modelos de costos. • Administrar las instalaciones de cálculo como una utilidad de múltiples usuarios, múltiples plataformas tanto dentro como fuera del firewall. • Garantizar el cumplimiento de normas corporativas para el uso de plataformas y middleware. • Medir el uso y costo, y optimizar la ubicación de la carga de trabajo, basado en políticas y cumplimiento de normas. • Migrar de manera transparente las cargas de trabajo a través de plataformas o fuera del firewall.

Existen actualmente diferentes tipos de software que permiten el cloud computing, incluyendo hypervisores, Infraestructura como Servicio (IaaS), Plataforma como Servicio (PaaS), Software como Servicio (SaaS), y software para gestión de la nube. Hipervisores. Los hipervisores ofrecen las tecnologías de virtualización, que son la piedra angular del mundo virtual. En el espacio de la nube privada o dentro del firewall, los proveedores claves incluyen a: VMware, Microsoft, Citrix y RedHat. Las nube públicas corren principalmente sobre hipervisores customizados, muchos basados en el hipervisor open source Xen.

SaaS. En la parte superior del stack están los proveedores del Software como Servicio (SaaS), que proporcionan servicios aplicativos bajo demanda. Los proveedores clave incluyen a: salesforce.com, NetSuite, RightNow, Google Apps, Zoho, LotusLive, y Microsoft Office 365. Gestión de la nube. El software para gestión de la nube es el pegamento que integra y gestiona las tecnologías de infraestructura de la nube mencionadas previamente. Entre los principales jugadores en este segmento están: Abiquo, BMC Software, CA Technologies, Cloud.com, Enomaly, Eucalyptus, Nimbula, Rackspace y VMware.

PaaS. La personalización de las nubes públicas se ha extendido al nivel de las plataformas de desarrollo, ofreciendo middleware en la nube. Este tipo de servicio es conocido como Platform as a Service y entre los principales jugadores están: Heroku, Google App Engine, Windows Azure, Force.com, CloudFoundry, DotCloud y Velneo. Actualmente este segmento tiene gran dinamismo y continuamente entran nuevos jugadores.

www.sg.com.mx |

IaaS. El siguiente conjunto de habilitadores de la nube son los proveedores de Infraestructura como Servicio (IaaS). Los proveedores de IaaS proporcionan servicios de infraestructura en la nube tales como almacenamiento y poder de cómputo. Los proveedores clave de IaaS incluyen a Amazon Web Services, Windows Azure, Terremark, Rackspace, GoGrid, IBM y Fujitsu.

Figura 1. Proveedores clave en cada espacio.

.BIO Carlos Escapa es CEO de VirtualSharp Software, compañía especializada en Disaster Recovery para VMware clouds. A lo largo de su carrera, Carlos ha ocupado posiciones ejecutivas en empresas como VMware, CA Technologies y Sterling Software. cescapa@virtualsharp.com

Software Guru

Principales jugadores en cada categoría

Enfrentando los Retos de la Operación Proactiva de la Nube ››Por Ajay Singh y Leslie Minnix-Wolfe

administración de los servicios de una aerolínea es compleja y altamente dinámica. Miles de pasajeros y piezas de equipaje se mueven continuamente entre cientos de aviones. Es complicado dar un seguimiento a todos estos detalles a la vez que se asegura que los clientes reciban la mejor experiencia. También se pueden tener alianzas con otras aerolíneas para cubrir más destinos, y la coordinación de esto añade aún mayor complejidad. Como si todo esto no fuera suficiente, está operación se da en un entorno en el que los problemas de recursos, como los problemas mecánicos de los aviones y el personal limitado, pueden hacer lentas sus operaciones y reducir la satisfacción de sus clientes. 26

De manera similar, el entorno operativo de la nube es complejo y está en constante cambio. Miles de cargas de trabajo se mueven entre cientos, o incluso miles, de servidores físicos, y dar seguimiento a estos detalles y asegurar el rendimiento óptimo de los usuarios finales es difícil. Tal vez tu organización utiliza servicios de múltiples fuentes, algunas internas y otras externas. Además, el personal y los recursos de TI insuficientes, así como un rendimiento de los servicios por abajo del nivel óptimo, pueden tener un efecto negativo enorme en el negocio. Para amplificar estos retos, se tiene la necesidad de combinar las operaciones de TI locales (in-house) con las de la nube por medio de una estructura unificada de centro de datos.

.Principal

Operaciones proactivas en la nube y BSM

Para administrar proactivamente los entornos de nube, se requiere superar cuatro desafíos importantes. Primero, debes entender tu entorno. Esto requiere reunir, consolidar, analizar y actualizar los datos de diversas fuentes, algunas internas y otras externas. Al mismo tiempo, debes mantener el control en un entorno altamente volátil, un entorno que está cambiando de forma continua y rápida en cuanto a estructura y cargas de trabajo. Adicionalmente, tienes que lidiar con el “efecto dominó” ya que un solo cambio o problema puede afectar cientos de servicios. Finalmente, debes automatizar la administración de solicitudes de servicio de manera que puedas responder rápidamente a cientos de solicitudes de servicio de los usuarios; proveer y administrar los servicios solicitados para cumplir con los niveles de servicio esperados; y hacer todo esto sin violar las políticas internas o las regulaciones externas. Las soluciones Business Service Management (BSM) pueden ayudar a hacer frente a estos cuatro desafíos. BSM brinda un modelo unificado que ayuda a los departamentos de TI a reducir los costos, 27

www.sg.com.mx |

Las organizaciones de TI que desean ser exitosas en este contexto requieren adoptar un modelo de administración de operaciones flexible y proactivo para la implementación y entrega de servicios de TI de calidad.

1. Entiende tu entorno: Reúne, consolida y analiza los datos Para administrar efectivamente el centro de datos moderno e híbrido, necesitas saber que hay “allá afuera”. Esto significa conocer qué activos físicos, virtuales y de nube se tienen y cómo encajan entre sí. Tener disponible esta información en todo momento es un gran desafío debido a la gran cantidad y variedad de recursos de cómputo, almacenamiento y comunicación que se utilizan en las organizaciones modernas. También es posible que en esta información se requiera incluir datos de los servicios provistos por recursos externos, como los proveedores de nubes públicas y de servicios administrados. El desafío está en consolidar, normalizar y analizar los datos para tener un panorama completo y unificado del rendimiento en tiempo real de todos sus servicios TI. Algunos proveedores de servicio externos han puesto a disposición interfaces de programación de aplicaciones (APIs) que le permiten aprovechar los datos de su infraestructura. Sin embargo, los datos expuestos por estas APIs tal vez no sean suficientemente granulares para sus propósitos, así que posiblemente tenga que hacer deducciones de acuerdo con el análisis de los datos disponibles. Las soluciones BSM pueden ayudar a cumplir con estos requerimientos. Primero, las soluciones BSM para descubrimiento y mapeo de dependencias reunen datos de fuentes dispares, los reconcilian, normalizan y consolidan en un solo repositorio de datos unificado (por ejemplo, una base de datos de administración de configuraciones, o CMDB) que puede ser compartido por distintas herramientas de administración de servicios. Algunas soluciones pueden analizar los datos de las aplicaciones y la infraestructura en tiempo real para crear y mantener automaticamente modelos de servicio en tiempo real que muestren las relaciones entre los recursos de TI internos y externos, y los servicios de negocio que soportan. Al mismo tiempo, las soluciones BSM pueden monitorear en tiempo real el rendimiento y disponibilidad de estos recursos. Las soluciones más avanzadas sincronizan en tiempo real las relaciones de modelos de servicios con la CMDB para asegurar que los modelos de servicio permanezcan actualizados de modo que puedan tomarse decisiones de TI precisas y oportunas. Estas soluciones pueden reunir y analizar datos provenientes de una gran variedad de recursos, incluso de proveedores de nube externos. De esta forma, las organizaciones de TI obtienen una vista completa de todos los recursos que soportan los servicios que ofrecen, y en caso de haber un problema pueden detectarlo con precisión y en tiempo real.

Software Guru

disminuir el riesgo, y mejorar la rentabilidad del negocio. Las soluciones BSM ofrecen una variedad de servicios de automatización, administración y analítica que permiten administrar los entornos de nube de manera proactiva. A continuación describimos cuatro estrategias que te pueden ayudar a hacer frente a estos desafíos.

.PRINCIPAL

2. Manten el control del entorno dinámico La virtualización, que brinda la base para el cómputo de la nube, ha elevado considerablemente la naturaleza dinámica del centro de datos. En el centro de datos moderno los recursos están virtualizados, incluyendo servidores, redes, aplicaciones y almacenamiento. Conforme las cargas de trabajo y requerimientos del negocio cambian, estos recursos son continuamente reconfigurados y aprovisionados. El centro de datos dinámico afecta diversas áreas de las operaciones virtuales y de nube. Descubrimiento. Es importante actualizar continuamente la vista del entorno para estar al día con los rápidos cambios de su configuración. Las soluciones de descubrimiento automático y de mapa de dependencias pueden ayudar a analizar continuamente el entorno, manteniendo actualizados los datos de las aplicaciones y la infraestructura, y actualizando los modelos de servicio por consiguiente. Además, algunas soluciones de administración del rendimiento complementan la CMDB y las soluciones de descubrimiento al detectar los cambios en el entorno de monitoreo en tiempo real y notificar a la CMDB para reconciliar los cambios y asegurar siempre la precisión en casi tiempo real de los modelos de servicio. Gestión del cambio y configuración. Otra área que afecta el centro de datos dinámico es la administración de los cambios y las configuraciones. Debemos asegurar que todos los cambios, sin importar lo rápido que ocurran, cumplan con las políticas internas y las regulaciones externas. Asimismo, hay que asegurar que los procesos de administración de los cambios no limiten la agilidad en los entornos virtuales y de nube. En resumen, necesitamos proveer rápidamente los recursos con la seguridad de que sean aprobados adecuadamente y usen sólo las configuraciones estándares. También necesitamos rastrear los cambios para propósitos de auditoría. Una vez más, las soluciones de administración de cambios y de configuraciones puedan ayudarle a superar el reto. Estas soluciones BSM automatizan un proceso de cambio de circuito cerrado que engloba la aprobación, la programación, la implementación, la verificación y el rastreo de los cambios. Al integrar la gestión de configuración y la del rendimiento, las soluciones BSM permiten que las operaciones de nube evalúen de inmediato el impacto que los recientes cambios en las configuraciones tienen en los niveles de servicio. Operaciones. La naturaleza dinámica del entorno de nube también complica las operaciones. En primer término, requerimos conocer cuándo ocurren los cambios en caso de que provoquen problemas de rendimiento. Los analistas de la industria reportan que el 80 por ciento de las interrupciones de servicio son causadas por cambios configurados de 28

forma inadecuada. En segundo término, debido al volumen y frecuencia del cambio, en los ambientes virtualizados y en la nube no es viable configurar manualmente umbrales estáticos ni recurrir a tendencias de rendimiento. Las cargas de trabajo varían según la hora del día, la semana, el mes y el año. Algunos cambios son predecibles, definidos por el “ritmo” natural del negocio, otros son definidos por factores incidentales, como las ofertas promocionales. Los umbrales deben ajustarse de forma constante y automática de acuerdo con todos estos factores. Para complicar las cosas, la naturaleza fundamental de los entornos virtuales y de nube es de un alto volumen de cambios, lo cual requiere ajustarse rápidamente a cambios en las necesidades de capacidad. En consecuencia, también necesita conocer y dar seguimiento a los ritmos normales de los cambios de la capacidad, así como conservar el aprendizaje del comportamiento cuando ocurren los movimientos para soportar estos cambios. Sólo así usted puede distinguir entre las fluctuaciones normales y anormales, y eliminar las alertas falsas. Las soluciones BSM facilitan determinar cuando un cambio reciente de la configuración es la causa de raíz de un problema de rendimiento. También, automáticamente aprenden y dan seguimiento a los cambios en los entornos virtuales y de nube. Sin esta tecnología, sería imposible realizar manualmente el análisis para determinar cuándo los cambios impactan a los niveles de servicio en los entornos dinámicos virtuales y de nube. Finalmente, las soluciones de administración de sistemas BSM ajustan los umbrales de modo automático y dinámico de acuerdo con el análisis en tiempo real de patrones de las cargas de trabajo. Al aprender los ritmos del negocio y el entorno de TI que los soportan, eliminan mucho del ruido de las herramientas tradicionales que generan alertas basadas en umbrales estáticos. 3. Lidia con el “efecto dominó” Los entornos virtuales y de nube incrementan exponencialmente el impacto de los problemas de rendimiento, ya que entre más servicios se hospeden en un recurso compartido mayor será el impacto cuando ocurran problemas en dicho recurso. Y eso no es todo, también hay que tomar en cuenta el impacto de los servicios dependientes entre sí. Por ejemplo, un servicio puede construirse combinando otros servicios. Así, un problema en cualquier servicio puede tener un “efecto dominó” en muchos otros servicios, algunos de los cuales funcionan sobre otros recursos físicos. Este efecto dominó es particularmente complicado para los proveedores de nubes públicas porque están atendiendo a un gran número de clientes, multiplicando el impacto de los problemas.

Conclusión

Al abordar los cuatro desafíos de las operaciones de nube proactivas, las organizaciones de TI pueden cumplir la promesa del cómputo en la nube en el ámbito empresarial. Dichas organizaciones pueden usar sus activos de TI de forma más efectiva para obtener el máximo retorno de su inversión. Gran parte de las tareas operativas y administrativas se pueden automatizar para reducir costos y proveer los más altos niveles de servicio. .BIO Ajay Singh es VicePresidente de Service Assurance en BMC Software. Leslie Minnix-Wolfe es gerente de producto de Service Assurance en BMC Software.

4. Automatiza la gestión de solicitudes Una de las capacidades principales de los entornos de nube es que 29

Software Guru

www.sg.com.mx |

los usuarios puedan solicitar servicios por medio de un portal de autoservicio. Las organizaciones de TI deben atender rápidamente las solicitudes sin descuidar el cumplimiento de las políticas internas y regulaciones externas. Por ejemplo, debe proveer sólo los servicios a los que el usuario solicitante está autorizado a acceder de acuerdo con su rol en la organización. Además, los servicios pueden tener diferentes niveles de privilegio, dependiendo del rol del usuario. Asimismo, puede tener que proveer el servicio usando configuraciones estándares, y necesita rastrear el aprovisionamiento para propósitos de auditoría. Las soluciones BSM pueden determinar los niveles de privilegio de los usuarios y configurar y proveer los servicios solicitados. Asimismo, rastrean las solicitudes desde la captura hasta la ejecución y permiten a los usuarios monitorear el estatus de sus solicitudes. Además, las soluciones despliegan y configuran automaticamente las herramientas requeridas junto con el servicio, asegurando que se cumplan los niveles de servicio adecuados. Por ejemplo, si un nivel de servicio oro se solicita para un servicio, la herramienta puede configurarse para medir la experiencia de los usuarios finales junto con los periodos especificados para resolver cualquier fallo de rendimiento de los usuarios finales.

El efecto dominó ejerce una gran presión en el personal de TI para estar pendiente de todos los servicios y recursos. Eso requiere la capacidad de monitorear de cerca los niveles de servicio para los servicios internos y aquellos provistos por recursos externos. Asimismo, requiere de la capacidad de atender rápidamente los problemas detectados, resolviendo los incidentes antes de que se deriven en la degradación del rendimiento o interrupciones. Por ejemplo, debe ser capaz de detectar, diagnosticar, priorizar y resolver rápidamente los incidentes, dirigiéndoles a los equipos indicados, algunos de los cuales pueden ser externos. Puede utilizar las soluciones BSM para monitorear los recursos físicos, virtuales y de nube y ofrecer una notificación oportuna de los problemas inminentes. Incluso, estas soluciones pueden evaluar y priorizar automáticamente los problemas de acuerdo con su impacto en los servicios. Algunas soluciones generan automáticamente tickets de problemas y anexan información sobre la causa de raíz y el impacto en los servicios para ayudar a acelerar la priorización de los problemas, el diagnóstico y la resolución. Estas soluciones trabajan junto con las soluciones BSM de administración de incidentes, cambios y problemas que conducen los incidentes de la detección a la resolución. Es necesario administrar con cuidado la capacidad para lograr una alta utilización de los recursos sin reducir la calidad de servicio. Esto requiere entender los patrones y tendencias de las cargas de trabajo para poder asegurar que la capacidad suficiente esté disponible cuándo y dónde se necesita. Las soluciones BSM pueden realizar un análisis de los datos del negocio, de las aplicaciones, de la infraestructura y de las cargas de trabajo para asegurar que la capacidad exacta se proporcione para cada servicio. Algunas soluciones se integran con las soluciones de administración y automatización de sistemas TI para facilitar la capacidad diaria para asegurar el rendimiento óptimo de los servicios. También pueden realizar un análisis “hipotético” que le ayude a determinar y planear los futuros requerimientos de capacidad. Con estas soluciones, usted puede brindar la capacidad que necesita –hoy y a futuro- sin gastar más de la cuenta los recursos de capital y operativos.

.PRINCIPAL

La Inteligencia de Negocios Llega a la Nube ya es momento de perderle el miedo ››Por Eumir P. Reyes

paradigma que parece estar evolucionando la computación moderna es el cómputo en la nube. Existen muchas definiciones del cómputo en la nube, pero una de las más acertadas a mi juicio es la del Instituto Nacional de Estándares y Tecnología (NIST) de los Estados Unidos, que la define como: “un modelo que habilita el acceso conveniente y bajo demanda a un conjunto compartido de recursos informáticos configurables (como redes, servidores, almacenamiento, aplicaciones y servicios) que pueden ser rápidamente provisionados y liberados con un mínimo esfuerzo de gestión por parte del proveedor de servicios”. Este modelo sobre la nube promueve la disponibilidad y se compone de cinco características esenciales, tres modelos de servicio, y cuatro modelos de despliegue. Cada vez encontramos más aplicaciones que empiezan a residir y operar sobre la nube. Algunas de las aplicaciones que más popularidad han tenido sobre la nube son el correo electrónico, sistemas para gestión de clientes (CRM), y almacenamiento de datos. Una de las aplicaciones más recientes en llegar a la nube es la inteligencia de negocios. Debido a la naturaleza de acceso a estos sistemas por parte de los usuarios finales, la Inteligencia de Negocios es un fuerte candidato para ser accedido a través de la nube, pues los tomadores de decisiones sólo requieren un navegador de internet para alcanzar el análisis de datos. Existen algunas inquietudes comunes para la incursión de la inteligencia de negocios hacia la nube, tales como: seguridad, desempeño, disponibilidad, integración y transporte de grandes volúmenes de datos. Afortunadamente existen estrategias identificadas y probadas para cada uno de estos obstáculos. A continuación ahondo con mayor detalle en cada punto.

Seguridad

La seguridad es quizá la principal preocupación de los usuarios al migrar a un ambiente en la nube. Esta inquietud no es exclusiva a la inteligencia de negocios, sin embargo en este caso se le da mayor prioridad debido a que estamos hablando de información muy importante para las organizaciones. La seguridad debe cuidarse especialmente en dos puntos: durante su transferencia y durante su almacenamiento. 30

El mecanismo utilizado para garantizar la seguridad durante la transferencia, es el cifrado de datos. Se pueden utilizar distintos algoritmos dependiendo del grado de seguridad deseado. Ya en la nube, estos datos son descifrados y posteriormente transformados para completar el ciclo de inteligencia de negocios. Cabe mencionar que el proceso de cifrado irá ligado con el proceso de compresión, el cual será tratado posteriormente en este artículo. Para garantizar la seguridad de los datos ya residiendo en la nube, se cuenta con dos mecanismos principales: cifrado de bases de datos y generación de bases de datos aisladas para cada cliente. Si se parte de que una de las características esenciales del cómputo en la nube es el compartir recursos, es comprensible que para muchos usuarios exista la preocupación de que su información puede estar compartiendo recursos con otras compañías, quienes incluso podrían ser competidores. Para estos casos, se cuenta con la generación exclusiva de bases de datos, a las cuales únicamente los usuarios autorizados podrán acceder. Cabe mencionar que las instalaciones físicas y lógicas de los proveedores globales de servicios de cómputo en la nube cumplen los estándares de seguridad y confiabilidad muy estrictos, siendo mucho más robustos y seguros que los centros de datos de la gran mayoría de las empresas.

Desempeño

El desempeño de una aplicación de inteligencia de negocios puede ser afectado por dos factores: procesamiento de datos y transferencia de datos desde la fuente hasta destino. El procesamiento de datos cuenta con dos capas: base de datos y aplicación. En un modelo de nube, ambas capas pueden incluso mejorar su desempeño comparado con instalaciones tradicionales. Para el caso de bases de datos, la información es distribuida en diversos discos duros virtuales con el proveedor de servicio de nube y así trabajar en paralelo durante el acceso a datos. Para el caso de la capa de aplicación, gracias a las prestaciones de elasticidad del cómputo en la nube, es posible provisionar rápida y sencillamente más poder de cómputo, tanto procesador como memoria, según sea la carga de trabajo de la aplicación de inteligencia de negocios.

Uno de los principales mecanismos para mantener alta disponibilidad en aplicaciones, incluso en ambientes en sitio, es la redundancia en hardware, tanto en formato activo-activo como activo-pasivo. Este esquema desde luego incurre en mayores costos para las empresas, pues se tiene que invertir prácticamente en el doble de recursos de cómputo. En el caso de la nube es factible contar con el mismo tipo de redundancia pero con costos más bajos, debido a que mientras no se utilice el ambiente pasivo o no se utilice a su máxima capacidad uno de los ambientes activos, no se tendría que pagar por el tiempo que no esté en operación. De esta forma, se logra capitalizar redundancia en hardware pero con mucho menos inversión que la que se requeriría en un modelo en sitio. Para lograr estos ahorros es necesario establecer la configuración adecuada para que las máquinas virtuales se aprovisionen automáticamente antes de que la aplicación deje de responder.

Integración

La integración de aplicaciones en la nube ha sido un importante factor que ha cohibido la migración hacia ese modelo. Lograr que las nuevas aplicaciones ofrecidas vía SaaS trabajen íntegramente con los sistemas legados en las organizaciones no es tarea fácil, sobre todo cuando se requiere del intercambio de información en ambos sentidos. Afortunadamente, para el caso de soluciones de inteligencia de negocios, las tareas de integración son llevadas a cabo a través de herramientas ETL (extracción, transformación y carga). La complejidad de utilización de este tipo de software es muy similar a la que se tendría en ambientes en sitio, ya que mientras se tengan los controladores adecuados para las bases de datos fuentes, y se tengan los canales de comunicación necesarios abiertos, la transferencia y carga de datos puede darse de forma natural. Cabe recalcar que este proceso debe acompañarse de mecanismos de cifrado de datos y de compresión, como se revisará más adelante.

Transporte de grandes volúmenes de datos

La transferencia de grandes volúmenes de datos a la nube es actualmente el principal obstáculo para las aplicaciones de inteligencia de negocios en la nube, sobre todo en países como el nuestro donde las conexiones a internet aún mantienen anchos de banda muy limitados. El proceso tradicional para una solución de este tipo consiste en cargar datos de forma batch al ser extraídos durante la noche por programas ETL. Dependiendo del tamaño de la empresa y sus necesidades, los volúmenes de datos pueden ser enormes por cada carga, llegando incluso a varios gigabytes.

Nuevas posibilidades

Al implementar la inteligencia de negocios en la nube se abren nuevas posibilidades para el análisis de información. Debido a la gran cantidad de datos que existen en sitios en línea o incluso otras nubes, es posible obtener información de fuentes externas a las empresas, como aquellos reportes o recopilaciones desarrollados por organizaciones no lucrativas o información pública ofrecida por organismos gubernamentales, esto sin contar la creciente oferta de redes sociales (las cuales surgieron por sí mismas en un ambiente de nube). Esto es posible debido a que la transferencia de datos entre nubes es comúnmente más rápida, y el ancho de banda entre dos puntos deja de ser un obstáculo. Otro factor que abre nuevas alternativas es el creciente número de aplicaciones empresariales disponibles bajo el modelo de software como servicios, como es el caso de CRMs o ERPs. Ya sea por medio de los APIs que estos servicios ofrecen, o desarrollando conectores específicos, es posible extraer datos específicos de estas plataformas, para integrarlos en un data warehouse en la nube. De esta forma se da origen a nuevos cruces de información y correlaciones al combinar datos externos con internos, dando así un nuevo alcance al ofrecimiento actual de la inteligencia de negocios.

Conclusión

El paradigma del cómputo en la nube está listo para recibir soluciones de inteligencia de negocios. Esto es factible gracias a mecanismos como cifrado, compresión y aislado de datos, acompañados de redundancia de dispositivos y una adecuada configuración de herramientas. El único obstáculo que prevalecería es la transferencia de volúmenes de datos demasiado grandes, es por eso que mientras se incrementan los anchos de banda de conexiones a internet en nuestro país, la inteligencia de negocios sobre la nube es más viable a organizaciones que manejan volúmenes de datos moderados. .BIO Eumir Reyes es Socio Director de Intellego, donde actualmente es responsable del área de Creación de Valor. Eumir es Ingeniero en Sistemas de Información por el Tec de Monterrey y Maestro en Diseño de Sistemas y Administración por el Massachusetts Institute of Technology (MIT).

Software Guru

Disponibilidad

Un mecanismo que hemos probado con muy buenos resultados es el de la compresión de datos antes de ser transferidos al canal de comunicación. Gracias a que los datos crudos provenientes de bases de datos transaccionales son altamente comprimibles, es posible obtener hasta un 90% de reducción en el tamaño de los archivos a ser transferidos por internet, logrando disminuir considerablemente los tiempos de transferencia, incluso sobre conexiones modestas como los ADSLs ofrecidos por las compañías de comunicaciones de nuestro país.

www.sg.com.mx |

El tema de desempeño durante la transferencia de datos será tratado más adelante, en la sección de transmisión de altos volúmenes de datos.

.CASO DE ESTUDIO

CMMI Para Servicios

al rescate de integradores y empresas de producto

esde que John W. Tukey utilizó a palabra “software” por primera vez en 1957, muchas cosas han pasado en el mundo de lo que hoy conocemos como Tecnologías de la Información y Comunicaciones. Lo que en ese entonces solo representaba una herramienta más, principalmente utilizada para mejorar las capacidades de cálculo, hoy se ha transformado en el elemento central de nuestra vida cotidiana, impactando en temas vitales como progreso, innovación, eficiencia, productividad y calidad de vida. A lo largo de los últimos 60 años, la industria del desarrollo de software ha evolucionado a una velocidad tal que ha desafiado todas las predicciones que se hicieron en su favor, o en su contra, de manera que controlar la calidad de lo producido por esta industria ha sido un desafío mayor. En esta carrera por tomar el control de la producción de software, un evento se destaca significativamente, y es la creación del Software Engineering Institute en 1984, financiado por el Departamento de Defensa de los EEUU y administrado por la Universidad de Carnegie Mellon en Pittsburgh. Su modelo SW-CMM v.1 liberado en agosto de 1991, rápidamente se convirtió en un referente para la ingeniería de software a nivel mundial, liderazgo que hoy todavía mantiene gracias a la evolución de aquel modelo, que en 2002 dio paso al actual CMMI (Capability Maturity Model Intergation). En esta última década, CMMI ha sido el marco de referencia para proyectos de mejora en la industria del software a nivel mundial, pero fue la misma industria la que reclamó al SEI la falta de un modelo que contemplara la importancia del componente de servicios, que con el paso de los años se hizo más relevante en cualquier proyecto de TICs. Es importante entender el impacto que el Sector Servicios tiene en la economía mundial. Por ejemplo, en el año 2006, la OIT reportó en su informe anual, que este segmento de la economía representó el 40% de los empleos, y por primera vez superó a la agricultura y al sector industrial que aportaron 38.7% y 21.3% respectivamente. Con estos antecedentes, nace la versión 1.2 de CMMI, que introduce el concepto de “Constelaciones”, un set de componentes de CMMI diseñados para cubrir necesidades específicas de otros sectores adicionales al desarrollo de software. Las 3 constelaciones de CMMI v 1.2 son: Desarrollo, Servicios y Adquisiciones. CMMI es una estrategia de mejora de procesos, que define los elementos esenciales de un proceso efectivo. En el caso particular de CMMI Servicios, éste provee una guía para organizaciones proveedoras de servicios que facilita las tareas de administrar, establecer y entregar sus servicios, cubriendo buenas prácticas relacionadas con aspectos específicos de este tipo de organizaciones, como son: 32

• Entrega de servicios • Administración de la capacidad y disponibilidad • Continuidad de servicios • Transición del sistema de servicios • Prevención y resolución de incidentes • Desarrollo del sistema de servicios

CMMI-SVC en el mundo

Aparentemente el modelo está cumpliendo con los beneficios prometidos, muestra de ello son las 46 organizaciones que ya reporta el SEI al 30 de abril de este año como certificadas CMMI-SVC en alguno de sus niveles de madurez [1]. EEUU está liderando esta tendencia con el 39% de estas certificaciones, seguido en segundo lugar por México con un 17%. La figura 1 muestra estos datos. Es de esperar que países como India y China, en el corto plazo comiencen a levantar sus estadísticas en relación con esta constelación de CMMI, teniendo en cuenta que son proveedores globales de grandes corporativos que ya no compran software, sino Niveles de Acuerdo de Servicios (SLA).

CMMI-SVC en México

Nuestro país ha experimentado un crecimiento vertiginoso en la adopción de CMMI como modelo de referencia en la industria de software nacional, esto en gran parte se debe a PROSOFT, el programa para el apoyo de la Industria de Software de México, impulsado por el gobierno del Presidente Vicente Fox y que persiste hasta la actualidad, reconocido por la IP como uno de los programas de mayor impacto en México. PROSOFT no solo ha sido clave en la certificación de modelos de calidad, sino que fue determinante para que nuestro país se integrara como proveedor de servicios TICs al mercado global. En referencia a CMMI para Servicios, las estadísticas del SEI muestran a México como uno de los países que están liderando la adopción del modelo. Cecilia Scauso, Lead Apraisser que ha realizado el 75% de las evaluaciones oficiales de CMMISVC en México, comenta: “Es increíble revisar las estadísticas y ver a México en segundo lugar. Evidentemente es una métrica muy difícil de sostener, pero llama la atención la velocidad con la que las empresas mexicanas están entendiendo los beneficios de esta nueva Constelación”. En cuanto a su opinión respecto del valor de estas iniciativas agrega: “He visto con grata sorpresa cómo las empresas mexicanas han sabido entender el modelo y sacarle mucho provecho. Inclusive organizaciones que vendían servidores, laptops y PCs,

Organización

Lead Appraiser

Fecha

Modelo

BrainUp Systems

Cecilia Scausso

Oct-2010 CMMI-SVC v1.2 (L3)

Éxito Software

Cecilia Scausso

Feb-2011

Cecilia Scausso

Abr-2010 CMMI-SVC v1.2 (L2)

Cecilia Scausso

Nov-2010 CMMI-SVC v1.2 (L3)

Jun-2010 CMMI-SVC v1.2 (L2)

FineSoft Imagensoft Qualtop

RQPortillo Firm

Viviana Rubinstein Cecilia Scausso

CMMI-SVC v1.2 (L3)

Jun-2010 CMMI-SVC v1.2 (L2)

Susoc Guadalajara

Jose Luis Iparraguirre

Oct-2010 CMMI-SVC+SSD v1.2 (L2)

Estrasol

Cecilia Scausso

Mar-2011 CMMI-SVC v1.3 (L2)

Tabla 1. Empresas mexicanas acreditadas en CMMI-SVC

tuvieron la visión de integrar servicios de mayor valor agregado, y al adoptar CMMISVC están potenciando su oferta con procesos, políticas y procedimientos, que el cliente está valorando tanto como los propios productos que compró.” La Tabla 1 lista a las empresas en México reportadas por el SEI como acreditadas en CMMI-SVC. Raúl Quinteros es el Director General de RQ Portillo Firm, una empresa líder en implementación de ERPs con sede en la ciudad de Culiacán. Fue la primer empresa en recibir una certificación de CMMI en México, y una de las primeras inclusive a nivel mundial. A casi un año de haber pasado exitosamente la evaluación de Nivel 2 nos comenta: “Somos una Pyme más, como otras miles que hay en México, buscando ganarnos un lugar en este mercado tan competido. Al principio lo vimos como un diferenciador, pero si lo haces bien, se transforma en una herramienta de consolidación y crecimiento”. También de Sinaloa, en Los Mochis, hay dos empresas con mucho en común, ambas habían logrado en años anteriores certificarse en CMMI DEV (Desarrollo) Nivel 33

www.sg.com.mx |

Figura 1. Distribución por países, Fuente: SEI Published Appraisal Report al 30/04/2011

3, y ambas decidieron cambiar el rumbo a CMMI Servicios. Se trata de Imagensoft y Éxito Software, las dos primeras empresas mexicanas en lograr certificarse en Nivel 3 de CMMI-SVC. Imagensoft ofrece software para gasolineras, restaurantes, hoteles, y soluciones de ERP con facturación electrónica. Sus clientes están distribuidos por todo el territorio nacional, inclusive algunos en Centroamérica. El Ing. Jorge Orduño, Director General de la empresa nos comenta: “Queríamos mejorar el soporte a nuestros clientes desde nuestra mesa de ayuda, estábamos pensando en ITIL cuando nos enteramos de CMMI para Servicios. Decidimos por CMMI principalmente porque ya teníamos CMMI L3 para Desarrollo y conocíamos muy bien la estructura general del modelo. Al final lo que buscamos es que nuestros clientes nos vean comprometidos con atenderlos cada vez mejor.” Éxito Software fue fundada en 1988 y su mercado principal son las escuelas, con más de 1,000 implementaciones de su software en todo el país. Le preguntamos al Ing. Anselmo Inda su opinión respecto de esfuerzo requerido para lograr una certificación de CMMI SVC Nivel 3, y nos contestó lo siguiente: “El esfuerzo no es menor, pero ya estábamos acostumbrados con las dos certificaciones anteriores Nivel 2 y 3 de CMMI DEV. Lo importante para nosotros es mantener alto el nivel de satisfacción de nuestros clientes, esto implica un esfuerzo importante que requiere de mucho orden y control, y este modelo nos ayuda a lograr el objetivo.” Otra empresa de las ya certificadas en México es Estrasol, con sede en Guadalajara, especializada en la implementación de soluciones ERP y CRM de código abierto. Ignacio Navarro, su Director General, asegura que “es el modelo ideal para una empresa de producto, nos permite controlar nuestras actividades de desarrollo de software, pero finalmente lo que vendemos es un servicio que administra recursos humanos, materiales y tiempo. Por más bueno que sea nuestro producto, si fallamos en el servicio, perdemos el cliente.”

Software Guru

.CASO DE ESTUDIO

››En referencia a CMMI para Servicios, las estadísticas del SEI muestran a México como uno de los países que están liderando la adopción del modelo.

CMMI es un modelo “no prescriptivo”, no dá recetas mágicas, nos dice “qué” hay que hacer, pero el “cómo” debe definirse en función de diversos factores que varían de una organización a otra. Esta flexibilidad permite interpretar que la Constelación SVC pudiera ser aplicable a prácticamente cualquier organización que brinde servicios, relacionada con TICs o no. Reiteradamente el SEI proclama sus deseos de que CMMI-SVC sea adoptado por organizaciones cuyo negocio no es la industria de software y servicios de TI. El pasado 11 de abril en el Step Talk 2011 en Lisboa, Portugal, Eileen Forrester quien es Program Manager para CMMI-SVC en el SEI, comentó que se están llevando a cabo esfuerzos para detectar oportunidades en industrias tales como: Medicina, Energía, Educación, Hotelería y Transportes. En entrevista con Leonardo N’haux, Director General de Qualtop, empresa de consultoría que está liderando la implementación de CMMI-SVC en empresas mexicanas, le pedimos su opinión respecto del impacto que CMMI-SVC pueda tener en México en otros sectores económicos: “CMM tuvo rápida aceptación porque no había otra cosa en ese momento para la industria de software, cuando hablamos de meter CMMI-SVC en otras industrias debemos tener en cuenta que se estará compitiendo con muchos otros modelos ya posicionados, y eso en México, como en cualquier otro país, implica tiempo”. Respecto del tipo de empresas que están optando por este modelo en el sector de las TICs, nos comenta: “Hemos visto beneficios importantes en dos tipos de empresas principalmente: empresas de productos de software e integradores de TICs. En el primer caso, a diferencia de las empresas de software a la medida, las de productos tienen un componente muy alto de servicio, el cliente ya vió el producto en una demo, por consiguiente su nivel de satisfacción ahora depende de la implementación y posterior soporte. Respecto de los integradores TICs, si bien son empresas que venden tangibles en la mayoría de los casos, éstos son productos de terceros, con lo cual la gestión de adquisición, entrega e instalación, se convierte en un servicio que necesita ser eficientemente controlado para cumplir con las expectativas de sus clientes. Ya hemos certificado a 6 empresas en menos de un año, y actualmente estamos trabajando con 12 más”. Qualtop es la primer empresa mexicana de Consultoría en CMMI, en certificarse en CMMI-SVC. Leonardo N’Haux nos comenta los motivos que justificaron la inversión: “Para nosotros se trata de vivir lo que enseñamos, el proceso de implementar la norma internamente nos permite transmitir experiencias a nuestros clientes de una forma más real, nuestros consultores ganan más conocimiento y los beneficios se transfieren directamente a nuestros clientes. El proceso nunca se detiene, en este próximo junio tendremos nuestra evaluación de nivel 3.”

Lecciones aprendidas.

Una de las claves para el éxito en cualquier proyecto, consiste en analizar las experiencias anteriores, que en muchos casos nos dicen qué hacer o qué no hacer en proyectos futuros. A continuación Cecilia Scausso nos comparte algunos consejos respecto a qué “SI” hacer o “NO” hacer en un proyecto de mejora basado en CMMI: 1. SI Complementar procesos existentes acreditados en CMMIDEV o Moprosoft con CMMI-SVC. Muchas organizaciones en México cuentan con un producto que implementan en diversas organizaciones y al cual luego deben dar soporte. CMMI-SVC apoya en la etapa quizás más crítica de este proceso que es la entrega de servicios. Organizaciones como ImagenSoft y Éxito Software, que ya estaban acreditadas en CMMI-DEV ML3, extendieron sus procesos al área de servicio logrando que toda la organización comparta conceptos de calidad y mejora de procesos. 2. NO Implementar CMMI-SVC para el desarrollo de productos. Querer implementar las prácticas de CMMI-SVC en áreas de desarrollo implica forzar la implementación de las mismas. Cuando los procesos a mejorar tienen que ver con desarrollo, CMMI-DEV funciona de manera más apropiada y permite aplicar técnicas ágiles naturalmente. Antes de que surgiera CMMI-SVC, empresas que se dedicaban a la entrega de servicios forzaban las prácticas de CMMI-DEV para lograr una acreditación. Este fue uno de los motivos para crear un modelo específico para dominios de entrega de servicios. 3. SI Comenzar por donde duele más. La mejora de procesos es una actividad que implica un cambio cultural muy importan34

te en las empresas, la clave para que las mejoras sean ampliamente aceptadas es que causen un impacto positivo en problemas actuales. Los procesos de entrega de servicios tienen una gran interacción con el cliente, es por esto que ajustando algunos puntos clave en esta interacción logramos grandes beneficios. Lo fundamental es comenzar este tipo de proyectos realizando un diagnóstico de estos problemas para poder entender dónde enfocar primero la mejora. Involucrar a todas las personas que participan en la operación de los procesos ha resultado un factor clave de motivación. 4. NO Decir una cosa y hacer otra. El compromiso se transmite con la acción, no con las palabras. Es importante que los responsables de cualquier proyecto de mejora entiendan esta premisa. Un número importante de fracasos en este tipo de proyectos está relacionado con este tipo de actitudes. Resaltar la importancia de estas iniciativas en los discursos es muy importante, pero aún más lo es actuar en consecuencia. No hacerlo desmotiva a los demás integrantes de la organización, que necesariamente tienen que aportar un esfuerzo adicional para no afectar la operación de la empresa.

Software Guru agradece la colaboración de todas las empresas y personas entrevistadas para este artículo

Referencias [1] “Published Appraisal Results”. Software Engineering Institute. http://sas.sei.cmu.edu/pars/pars.aspx

.Prácticas Project Management

Estimación de Proyectos de Software “un problema una solución”

oy en día el factor del tiempo de duración de un proyecto es crucial y estratégico ya que se juega en una línea muy delgada que puede generar pérdidas o ganancias. En este sentido los proyectos relacionados con el manejo de información (Software: obtención, explotación) cobran una gran relevancia. La mayoría de las veces cuando se tiene que decidir la factibilidad de un proyecto de SW en etapas tempranas, la información con la que se cuenta es muy poca o es ambigua, esto sucede debido a que la adquisición de la información para un proyecto de SW es paulatina y en las primeras etapas es escasa y muy susceptible a cambios. Lo anterior ocasiona que la manera más utilizada, más rápida, menos costosa y la más utilizada a nivel mundial para estimar esfuerzo, duración, costo de un proyecto de este tipo sea la utilización de la experiencia de los empleados de una organización, mejor conocida como “Juicio de Experto”. Sin embargo, esto no siempre es una buena idea ya que esta manera de realizar estimaciones presenta algunos problemas como que le pertenece al experto y no a la organización, está influenciada por el contexto o circunstancias en las que esté el experto al realizar los juicios, además los expertos hacen inferencias a partir de variables de entrada con valores subjetivos (complejidad, experiencia del equipo, experiencia en la herramienta, etc.) no determinísticos y por si fuera poco, no se puede replicar sistemáticamente, lo que genera dependencia de los expertos. Hasta aquí es la parte que representa el problema descrito en el título, a continuación voy a presentar un ejemplo de esta situación: Para clarificar esta situación se describe a continuación un ejemplo de un proyecto específico el cuál se estimó en tiempo y esfuerzo de manera empírica, es decir utilizando juicio de experto, y las herramientas que tenía la organización a su alcance. La empresa y el nombre del proyecto no se mencionan por confidencialidad, pero los datos son reales.

El proyecto

La definición del proyecto que proporcionó el cliente en primera instancia fue la siguiente: “Desarrollar solución técnica que permita brindar el servicio de tercero confiable para apoyo n las operaciones de comercio exterior”

›› Por Francisco Valdés Souto

››Cuando se tiene que decidir la factibilidad de un proyecto de SW en etapas tempranas, la información con la que se cuenta es muy poca o es ambigua. Como podemos ver, la información está dada a un nivel de abstracción muy alto y es muy ambigua. El cliente pidió con esto una cotización, lo que implicaba una estimación de duración y esfuerzo del proyecto. Aunque sé que muchas personas por la finalidad de vender o por la costumbre de realizar así las estimaciones se verían tentados a dar los números solicitados, la realidad es que se pidió más información al cliente, éste proporcionó la siguiente información: • Contar con una herramienta que permita apoyar la operaciones de Comercio Exterior de carga, sin la necesidad de presentación física de papeles, haciendo más eficientes los procesos en las agencias aduanales en cuestión de resguardo y localización de pedimentos, sus anexos y documentos relacionados. • Contar con una herramienta que permita el resguardo digital de pedimentos, sus anexos y documentos relacionados por medio de un expediente único. • Dentro del proceso de resguardo de archivos autentificar los mismos mediante el certificado digital de Firma Electrónica Avanzada. • Contar con esquemas de búsqueda y consulta de información de acuerdo al rol del área y vigencia de resguardo. • Contar con esquema de “Facturación” que incluya costeo de almacenamiento, manejo de niveles de cuotas, bonificaciones y emisión de reportes. • Contar con información histórica (documentos) con una antigüedad hasta por 10 años.

Contexto del proyecto

El grupo que realizó las estimaciones conocía el contexto en el cual se realizaría el proyecto que lo describió de esta manera: • El equipo que iba a realizar la solución no contaba con un buen conocimiento del negocio ya que usualmente ellos se dedicaban a cuestiones financieras. 36

.Prácticas

Project Management

ORIGINAL EXPERT JUDGEMENT ESTIMATION PRACTITIONER JUDGEMENT

PEQUEÑO

PROMEDIO

[500-1000]

[1001-4000]

GRANDE

MUY GRANDE

[4001-10000]

[1001-19000]

PRACTITIONER JUDGEMENT ORIGINAL EXPERT JUDGEMENT ESTIMATION

Herramientas utilizadas para la estimación

Las herramientas con las que contaba la organización que realizó este proyecto eran la experiencia o sus expertos (herramientas empíricas, hojas de Excel generadas a partir de la experiencia, ejercicios históricos de FP (IFPUG) y Use Case Points (UCP)) y una clasificación en rangos de esfuerzo históricos por tipo de proyecto específica para la organización, similar a la que se muestra en la Figura 1.

Resultados

El proyecto que se estimó originalmente en 5 meses por un grupo de expertos de la organización, terminó en realidad en 13.25 meses lo que implicó un retraso de 165%. Cabe mencionar que este grupo realizó originalmente la estimación, en un aproximadamente una de esfuerzo. Se puede observar claramente que el realizar malas estimaciones tiene una repercusión directa en la economía de las empresas ya que este tipo de defasamientos, que son comunes en la industria [1] implica que alguien tiene que absorber el gasto, ya sea el cliente o el proveedor, implicando negociaciones por demás complejas y desgastantes. Ver Figura 2.

Office el pasado septiembre, si se establecieran con más realismo las líneas base de los requerimientos, costos, calendario y riesgos durante las fases de planeación de proyectos, cerca de la mitad de cancelaciones o programas que rebasan el presupuesto de TI podrían ser evitados. Eso ahorraría anualmente $5.5 billones, de acuerdo a un estudio hecho por Price Systems LLS, una compañía de software y consultoría de Mount Laurel, N.J de EEUU. El estudio considera 140 ejecutivos TI del Gobierno”. [2] La sección de la solución correspondiente al título se mostrará en otra edición debido a la limitación del espacio.

Referencias [1] The Standish Group International, Extreme Chaos, The Standish Group International, Inc, 2000 – 2004 Research Reports. [2] Off Base Insufficient expertise in setting baselines hits U.S federal IT budgets where it hurts”, PM NETWORK, March 2007 / VOLUME 21.

.BIO Francisco Valdés Souto es Candidato a PhD. en Ingeniería de Software con especialización en medición y estimación de software Universidad de Quebéc en École de Technologie Supérieure. Certified ScrumMaster (CSM). Project Manager Professional (PMP). Primer mexicano certificado como COSMIC FFP Size Measurer por el COMMON SOFTWARE MEASUREMENT INTERNATIONAL CONSORTIUM (COSMIC). COSMIC International Advisory Council (IAC). Experiencia de 14 años en desarrollo de Software Financiero de desempeño crítico, Socio de SPINGERE, primera empresa en ofrecer servicios especializados en dimensionamiento y estimación de software desde un enfoque ingenieril en América Latina. Participación en conferencias internacionales como: SERA2010, IWSM-Mensura 2007. @valdessoutofco

“De acuerdo al testimonio de la Government Accountability 37

Software Guru

• Tampoco se contaba con toda la experiencia de las tecnologías involucradas para el desarrollo de la solución como digitalización y firma electrónica aunque conceptualmente se conocían. • El líder de proyecto no tenía toda la disponibilidad ya estaba compartido en tres proyectos y el suplente no tenía mucha experiencia ni liderazgo para llevar a cabo un proyecto de manera independiente.

Figura 2. Desfasamiento estimado Vs. real.

www.sg.com.mx |

Figura 1. Rangos de Esfuerzo por tamaño de Proyecto.

.Prácticas Usabilidad

Perfiles de Usuario

una herramienta indispensable

levar a cabo la construcción de una interfaz de usuario efectiva involucra una serie de acciones que van mucho más allá de acomodar controles y elementos conocidos. Incluso antes de cualquier diagramado de procesos, es necesaria una investigación completa para establecer de manera sólida tanto las metas deseadas por la organización, como lo que los usuarios del sistema esperan ver o lograr al utilizarlo. En primera instancia, es recomendable realizar un análisis del proyecto dentro del contexto de los objetivos del negocio. Es importante tener claros los objetivos que el proyecto debe cumplir al ser completado: ¿Qué estrategias de negocio va a complementar? ¿Cuáles son los procesos de los que va a formar parte? Posteriormente, el enfoque del análisis deberá contestar preguntas de proceso más específicas tales como: ¿Qué información se necesita recopilar de los usuarios y de qué manera? ¿Será necesaria la integración con redes sociales? ¿Involucrará procesos de cobro? ¿Se requerirán zonas restringidas, es decir, que involucren la creación de cuentas de usuario? Tras tener claras las expectativas por el lado del negocio, es necesario también llevar a cabo un análisis para conocer lo que los usuarios esperan del sistema una vez que lo utilicen. Para esto, es necesario en un inicio tener una segmentación clara de la audiencia objetivo, es decir, saber de manera precisa quienes serán los usuarios del sistema que construiremos. Para obtener esta información podemos realizar encuestas entre personas de la audiencia objetivo. Aún si el desarrollo es interno, es decir, para los empleados de la organización, es de gran relevancia conocer sus perfiles como futuros usuarios del sistema. Si por otra parte, se trata del rediseño de una herramienta ya existente, este análisis puede apoyarse en estadísticas de uso de la versión vigente. Una vez reunidos los datos necesarios, plasmarlos para su correcto análisis involucra la creación de perfiles individuales, también conocidos como personas. En este contexto, persona se refiere a un perfil y no a un ser humano específico, para evitar confusión en este artículo nos referiremos a este concepto como “perfil de usuario”. La definición de perfiles de usuario es una gran herramienta para aterrizar los resultados del análisis de la audiencia objetivo.

›› Por Pamela Rodríguez

Definición

Para crear un perfil de usuario se sintetizan las características recurrentes entre la información recopilada durante el estudio y se crea un perfil de personaje ficticio que los englobe. De esta manera, se puede resumir el estudio en un número reducido de perfiles que se tomarán en cuenta para el diseño de la interfaz. La especificación de un perfil típicamente incluye la siguiente información: • Nombre y fotografía (no es que realmente exista el individuo, pero ponerle un nombre y darle una imagen ayuda a enriquecer el perfil, y lo humaniza más que solamente referirse a él como ‘el número 6’ o algo por el estilo). • Datos personales (edad, ocupación, entre otros). • Breve descripción personal. • Intereses personales. • Niveles y especificaciones de involucramiento tecnológico (Frecuencia con la que navega o utiliza la computadora, dispositivo o computadora que utiliza, navegador preferido, etcétera). • Nivel socioeconómico. • Nacionalidad (¿Se necesitará la inclusión de traducciones a otros idiomas o la adaptación de un idioma a distintos usos del mismo? Este último punto refiriéndose a que el mismo idioma puede tener variaciones de un país a otro). • Metas personales (¿con qué objetivo utiliza el sistema?, ¿cuáles son sus prioridades? ¿qué velocidad espera de sus actividades relacionadas?). Es recomendable utilizar una plantilla para documentar los perfiles. Si buscas en libros y en Internet seguramente podrás encontrar distintas plantillas. Escoge alguna con la que te sientas cómodo para usarla de base y modifícala de acuerdo a tus necesidades. Lo realmente importante es que la información recopilada para el perfil de la persona sea coherente y esté organizada de forma clara y sencilla. 38

Figura 1. Plantilla para definición de perfil

En la figura 1 muestro un ejemplo de una plantilla para documentar un perfil, propuesta por el consultor y autor Jean-Claude Grosjean [1].

Usos

El planteamiento de un perfil puede ser de gran utilidad para el equipo de trabajo. Además del uso primario para documentar y comunicar la información recopilada por el estudio de mercado, también sirven de apoyo al desarrollar las historias de usuario. El darle un nombre a la persona que realiza la acción dentro de una historia de usuario le da una mayor solidez, más aún cuando detrás de ese nombre ya hay una definición de características que explican a detalle el comportamiento que la historia del usuario expone. Los perfiles también son de gran ayuda durante el establecimiento de prioridades a lo largo del proyecto, ¿qué funcionalidades o elementos serán prioritarios dentro del desarrollo del mismo? Esta pregunta puede ser resuelta con la ayuda de los perfiles, pues el estudio de segmentación debe definir qué tipo de usuarios son los que abarcan mayores partes del mercado meta. Los perfiles de estas personas deben ser marcados como prioritarios y, por consiguiente, la prioridad de funcionalidades y elementos puede posteriormente basarse en esos datos.

Conclusión

La definición de perfiles o personas puede apoyar en gran manera a la integración de actividades al construir un sistema o aplicación de software. El detalle que se le de a los perfiles dependerá de la solidez de los datos recopilados durante la investigación previa, pero es sin duda una herramienta de gran utilidad que no debe ser ignorada.

Referencias [1] Jean C. Grosjean. “A Day in Life of an Agile UX Practitioner: Personas.” http://bit.ly/sg32r2

.BIO Pamela Rodríguez Domínguez es egresada de la Universidad de Monterrey de la carrera de Ingeniería en Sistemas Computacionales con estudios avanzados en diseño web. Actualmente es Diseñadora de Interfaces para Aplicaciones Móviles en Naranya AppHouse, docente, conferencista y autora de artículos relacionados. @thepam http://thepam.blogspot.com

.Prácticas Arquitectura

Integrando la

Arquitectura

al ciclo de desarrollo de software

››Por Humberto Cervantes y Edith Valencia

lo largo de las últimas ediciones de esta sección hemos realizado un recorrido a través de las distintas actividades asociadas con el desarrollo de la arquitectura de software, a saber: la captura y especificación de requerimientos que influyen en la arquitectura, el diseño de la misma, su documentación y su evaluación. Aunque dichas actividades no están asociadas a una metodología particular de desarrollo, en este artículo veremos cómo se pueden incorporar a cualquier ciclo de desarrollo.

La arquitectura dentro del ciclo de desarrollo

Ya hemos comentado la importancia de la toma de decisiones de diseño arquitectónico de manera temprana. La arquitectura de software se enfoca en lograr la satisfacción de requerimientos guía, y particularmente de atributos de calidad tales como el desempeño, disponibilidad, seguridad y modificabilidad. A diferencia de los requerimientos funcionales típicos, el código que implementa aspectos relacionados con atributos de calidad generalmente se encuentra disperso en una gran cantidad de módulos del sistema. Por otro lado, ciertas decisiones de diseño que se toman para satisfacer un atributo de calidad, por ejemplo el desempeño o la disponibilidad, influyen de forma general sobre todo el código de la aplicación, incluso sobre cuestiones físicas (por ejemplo la elección de hardware). Es así que realizar cambios en atributos de calidad de forma tardía es una cuestión compleja y problemática. Por lo anterior, es conveniente que las actividades relacionadas con la arquitectura de software se realicen de manera temprana en el desarrollo. En particular es necesario: • Identificar y especificar los requerimientos guía. Éstos incluyen a los atributos de calidad, los requerimientos funcionales prima.BIO rios y las restricciones del sistema. El Dr. Humberto Cervantes es profesor-investigador en la UAMLa arquitectura se puede diseñar Iztapalapa. Ha realizado investigación en temas relacionados con alrededor de estos. arquitectura de software desde el año 2000 y recientemente se ha • Diseñar la arquitectura e, enfocado en el estudio y aplicación idealmente, implementar una de métodos que apoyen al desarrollo de arquitectura de software “arquitectura ejecutable” que perdentro de la industria Mexicana. www.humbertocervantes.net mita materializar el diseño de la arquitectura. La MSc. Edith Valencia es arquitecto de software en la empresa • Documentar los aspectos QuarkSoft S.C. Obtuvo la maestría con honores en Ingeniería de fundamentales del diseño, teSoftware en la Universidad de York en El Reino Unido. Sus áreas niendo especial cuidado en capde interés incluyen arquitecturas turar las decisiones de diseño, de software, ingeniería de procesos de software y metodologías ágiles. para comunicarlas al equipo y evalencia@quarksoft.net que sirvan de guía.

• Realizar una evaluación poco después de que se ha terminado el diseño y antes de proceder a la construcción del sistema. Es importante recalcar que diseñar la arquitectura de forma temprana no significa que se deba realizar el desarrollo siguiendo un enfoque secuencial (en cascada) de tal forma que primero se obtengan y especifiquen todos los requerimientos, luego se realice todo el diseño y luego se construya y pruebe la misma. El realizar un diseño completo de alto nivel conceptual (en documentación y no en código) que en inglés se conoce como “Big Design Up Front” (o BDUF), en raras ocasiones es exitoso. Repasemos algunas metodologías de desarrollo populares, explicando cómo se pueden integrar en ellas las actividades arquitectónicas.

TSP

El proceso de desarrollo por equipos (TSP) promueve la creación de equipos auto-dirigidos y la mejora continua. TSP define cuatro fases: requerimientos, diseño de alto nivel, implementación y pruebas. Aunque la estructuración del sistema en base a componentes se considera en el diseño de alto nivel, no hay un énfasis particular en cuestiones de arquitectura. En TSP, un proyecto se estructura por ciclos que pueden o no estar enfocados a una fase específica. Un problema frecuente con TSP es que se utiliza un enfoque de ciclos asociados a fases específicas: uno o más ciclos enfocados a requerimientos seguidos de uno o más ciclos enfocados a diseño de alto nivel, seguidos de ciclos enfocados a la construcción y prueba del sistema. Lo anterior resulta en desarrollos en cascada. La integración de actividades de arquitectura en TSP depende de la complejidad del proyecto y del contexto. Sin embargo, lo más recomendable es tener uno o más ciclos al inicio del proyecto enfocados específicamente al desarrollo de la arquitectura y dentro de los cuales se realicen actividades asociadas a las distintas fases de TSP. Un ciclo de arquitectura incluiría actividades de especificación de requerimientos guía, diseño de la arquitectura, desarrollo del prototipo y evaluación del diseño. Una vez que se termina la arquitectura, la construcción del sistema se realiza de forma incremental por encima de ésta [1, 2].

RUP

El Proceso Unificado de Rational (RUP) es un marco enfocado a desarrollo iterativo e incremental. Su estructura general se compone de 4 fases y 9 disciplinas. Las 4 fases son: inicio, elaboración, construcción y transición y se llevan a cabo en ese orden. Las disciplinas son conjuntos de actividades que abordan un aspecto del proyecto, tales como: modelado de negocios, gestión de requerimientos, análisis y diseño, implementación, pruebas, implantación, administración de la configuración 40

.Prácticas

Arquitectura “En

las metodologías ágiles no es común encontrar actividades específicas para desarrollar la arquitectura .”

El desarrollo de software ágil engloba una serie de metodologías cuya esencia se encuentra definida en el “Manifiesto para el desarrollo de software ágil“ (www.agilemanifesto.org). Esta filosofía se basa en el enfoque en factores humanos como cooperación, comunicación y confianza, el desarrollo iterativo, la simplicidad y la adaptabilidad. Extreme Programming y Scrum son dos métodos ágiles populares. En general, en las metodologías ágiles no es común encontrar actividades específicas para desarrollar la arquitectura. Esto se puede asociar a diversos factores tales como: • El enfoque en actividades que contribuyen al desarrollo y entrega de un producto funcional, en vez de actividades orientadas al diseño y documentación del sistema. El tiempo requerido para la generación y documentación de la arquitectura suele verse como una actividad secundaria que no forma parte del producto final. • La mayoría de las metodologías ágiles funcionan con equipos pequeños y sistemas de tamaño medio. La importancia de la definición de la arquitectura puede no ser

A pesar de esto, algunos métodos ya están incorporando adaptaciones a sus prácticas a fin de incluir actividades relacionadas con la definición de la arquitectura de software. Por ejemplo, algunos equipos que utilizan Scrum han incluido una iteración inicial llamada “Sprint cero”. En esta iteración, se genera una arquitectura de alto nivel que establece la forma en la que serán implementadas las características del sistema. Otro ejemplo es la recomendación de incluir y manejar los requerimientos no funcionales como historias de usuario. Más información respecto a metodologías ágiles y arquitectura de software se puede encontrar en [5].

Conclusión

Las actividades arquitectónicas se pueden integrar dentro de cualquier metodología de desarrollo. A menos que se desarrollen sistemas muy simples, estas actividades son indispensables. Un aspecto que se debe cuidar, particularmente en organizaciones medianas a grandes es que la incorporación de actividades arquitectónicas dentro de la metodología de la empresa es un proyecto de mejora que requiere de una cuidadosa implantación. Además de considerar los ajustes a la metodología propia de la organización, se debe considerar la documentación de los métodos y la capacitación de los arquitectos e ingenieros. La realización de evaluaciones de arquitectura también debe considerar cuestiones de logística que incluyen la conformación de los equipos de evaluación. Finalmente, es conveniente disponer de algún promotor (o “champion”) de la arquitectura que impulse la adopción del desarrollo de arquitectura de software dentro de la organización.

Referencias [1] R. Nord, J. McHale, F. Bachmann, “Combining Architecture-Centric Engineering with the Team Software Process”. Software Engineering Institute, Diciembre 2010. [2] H. Cervantes, I. Martinez, J. Castillo, C. Montes de Oca: “Introducing Software Architecture Development Methods into a TSP-Based Development Company”, SATURN 2010, Mayo 2010. [3] R. Kazman, P. Kruchten, R. Nord, J. Tomayko, “Integrating Software Architecture-Centric Methods into the Rational Unified Process”. Software Engineering Institute, Julio 2004. [4] J. Eckstein, “Agile Software Development in the Large: Diving Into the Deep”, Dorset House Publishing Co., 2004. [5] IEEE software, “Agility and Architecture”, Marzo-Abril 2010.

Software Guru

Métodos ágiles

tan evidente en dichos escenarios, en los cuales pueden funcionar prácticas tales como la simplicidad, que sugiere enfocarse en los elementos del sistema identificados actualmente y posponer la adición de complejidad hasta el momento que se necesite (mediante la reestructuración de código o “refactoring”).

www.sg.com.mx |

y cambios, administración de proyectos y entorno. Dentro de cada fase se realizan actividades asociadas a las distintas disciplinas a lo largo de un número variable de iteraciones. Estas actividades se realizan con mayor o menor énfasis, dependiendo de la fase en la que se encuentre el proyecto. Para RUP, la arquitectura de software es una cuestión fundamental y, de hecho, la fase de elaboración tiene como objetivo producir y validar la arquitectura del sistema que se materializa como una arquitectura ejecutable. La arquitectura ejecutable es “una implementación parcial del sistema construida para demostrar funcionalidades y propiedades específicas del sistema, en particular aquellas que permiten satisfacer los atributos de calidad”. RUP promueve que la arquitectura se diseñe, valide y codifique de forma temprana, antes de iniciar la construcción del sistema, con el fin de mitigar riesgos técnicos. RUP también promueve un esquema de documentación del diseño de la arquitectura, que es el modelo 4+1 vistas. A pesar del énfasis que pone RUP en la arquitectura de software, no entra en detalles muy finos relativos a la especificación de atributos de calidad, el diseño de la arquitectura y su evaluación. Sin embargo, los métodos que hemos presentado ateriormente en esta sección se pueden integrar de forma natural dentro de RUP.

.Prácticas Ágil

Innovación de Valor Mediante Lean-Agile logrando ventaja competitiva

odo profesionista eventualmente llega a la realización de que todo proyecto y equipo de trabajo es distinto. Lo interesante está en que por otro lado tenemos estándares, modelos y métodos para ayudarnos a reducir el nivel de caos en los proyectos. Esto ha tenido como consecuencia que muchos líderes y equipos caen en la trampa de la plantilla y hacen las cosas siguiendo ciegamente los estándares sin percatarse de la contradicción de sus actos con respecto a la realidad de los proyectos y equipos. El uso combinado del pensamiento lean y ágil ha demostrado ser muy exitoso para mejorar organizaciones. Mediante mi propia práctica así como casos reportados, he encontrado que el éxito no es tan completo como pudiera serlo porque el alcance es típicamente limitado a los confines del desarrollo de software, dejando a un lado otros factores tales como interacción con clientes, comunicación y colaboración entre stakeholders, incremento de ventaja competitiva y enfoque en innovación.

››Por Dr. Masa K. Maeda

mas características, misma calidad, mismo precio y son igualmente atractivos. ¿Cuál compraría usted? Digamos que como no hay diferenciador, ambas empresas venden exactamente el mismo número de unidades. Ahora bien, si una de las empresas llevó a cabo innovación con respecto a la forma en que su producto fue creado entonces es probable que el costo de producción, distribución y operaciones sea menor. Ello quiere decir que esa empresa obtuvo mayor ganancia. Y aún más, esa empresa tiene mayor probabilidad de que su siguiente producto sea más atractivo o de menor costo, así como también pueda ser lanzado al mercado en menor tiempo. Esto quiere decir que llevar a cabo innovación con respecto a valor hacia el cliente y con respecto a valor hacia la empresa, nos da potencialmente una ventaja competitiva significativa. Esto lo podemos representar mediante el Prisma Lean-Agile.

Valor

El Prisma Lean-Agile

Digamos que dos nuevos productos son ofrecidos en el mercado por empresas enteramente nuevas, por lo que no se cuenta con una imagen empresarial establecida. Así mismo, no se llevó a cabo ninguna actividad de mercadotecnia por lo que el único parámetro de evaluación que los clientes tienen son los productos mismos. Ambos productos ofrecen las mismas características y la misma calidad (ver Figura 1). La pregunta es: ¿cual producto compraría usted? Al hacer esta pregunta dos respuestas prevalecen: • El más barato. • El que más me guste. Exploremos estas respuestas un poco más con una tercer pregunta. ¿Si el que le gusta más tiene mayor precio, estaría usted dispuesto a gastar ese dinero extra y de ser necesario, esperarse un poco de tiempo hasta tener el dinero para comprarlo? Consistentemente, la mayoría de la gente contesta “sí”. Esto impli.BIO ca que si una de las dos empresas El Dr. Masa K Maeda es Presidente y Fundador de Shojiki Solutions, una llevó a cabo innovación con resempresa dedicada a ayudar empresas en la adopción y mejoramiento del pecto a valor para con el cliente uso de metodologías Agile-Lean. tal que su producto es más atracTiene más de 20 años de experiencia en la industria de software en Japón, tivo entonces es más probable que México, y Estados Unidos. Obtuvo el Doctorado y Maestría en Sistemas Intenga una ventaja competitiva. teligentes y Ciencias de la Información Ahora bien, si tenemos de en la Universidad de Tokushima en Japón y la Licenciatura en Ingeniería nuevo dos productos como en el en Computación en la Universidad Nacional Autónoma de México. caso anterior, pero en esta ocasión www.shojiki-solutions.com los dos productos ofrecen: mis-

Innovación

Restricciones Calidad

Figura 1. El Prisma Lean-Agile.

En el Prisma Lean-Agile tenemos: • Restricciones. Son los elementos establecidos en el triángulo de hierro de gestión de proyectos, es decir presupuesto, itinerario y alcance. • Calidad. Es aquella establecida por el cliente y la cual tenemos la obligación de alcanzar y de hecho exceder. • Innovación. La que estamos definiendo en el presente artículo. • Valor. Es el factor más importante, por ello su posición de pináculo en la estructura. El valor es establecido por el cliente y el valor para la empresa debe estar supeditado al valor para con el cliente.

Innovación de valor

El término innovación de valor fue acuñado por Chan Kim y Mauborgne, y tiene que ver con enfocarse en crecer el negocio mediante la identificación de nuevos mercados en lugar de enfocarse en competir. La manera en la que yo he introducido innovación de valor es un poco diferente pero alineado en buena medida con esa definición. 42

.Prácticas Ágil

››El uso combinado del pensamiento lean y ágil ha demostrado ser muy exitoso para mejorar organizaciones.

El pensamiento innovador es el estado mental en el que los stakeholders: • Están dispuestos a aceptar y pasar por una transformación de la manera en que ven y hacen su trabajo. • Aplican pensamiento en sistemas para entender mejor lo que se debe lograr y resolver problemas complejos de forma más eficiente. • Utilizar el sistema de conocimiento profundo como una guía para mejorar la gestión y la organización. • Utilizar pensamiento esbelto (lean) para mejorar procesos. • Utilizar pensamiento ágil para utilizar herramientas innovadoras de forma más eficiente. Esta transformación facilita reconocer la importancia de contar con agentes de cambio en todos los niveles de la organización.

Ambiente que fomenta innovación

Las personas que practican lean-agile ya tienen un buen entendimiento de las ventajas de contar con un ambiente que fomenta la innovación. El ambiente apropiado conjunta los recursos humanos y materiales adecuados de manera tal que facilita las actividades de innovación. Es decir: • Mejora la comunicación entre todos los stakeholders tanto internos como externos a la empresa (incluye clientes y de ser posible usuarios finales). • Facilita la colaboración entre todos los stakeholders. • Es transparente con respecto a todos los aspectos del proyecto y la organización. Entre mayor es el nivel de conocimiento compartido mejores decisiones y mejor acción se puede llevar a cabo, resultando en incrementos de productividad y calidad. Así mismo, la motivación de los stakeholders también se incrementa. • Le permite a los stakeholders explorar y encontrar mejores formas de hacer las cosas y crear mejores productos y servicios • Le da autonomía a los stakeholders.

Un gran ejemplo de ese tipo de herramienta es el método Kanban, el cual incrementa la efectividad del equipo y promueve mejoras de parte de los stakeholders externos al equipo. Al mismo tiempo provee herramientas visuales y evidencia cuantitativa facilitando el análisis de causa raíz, permitiendo así dedicar más tiempo a la generación de las mejoras mismas. Las herramientas innovadoras están en alineación con la autonomatización (la automatización con toque humano), se motiva el automatizar para que los recursos humanos puedan ser canalizados a actividades que realmente requieren del ingenio y otros factores humanos con lo que efectivamente llevarán a cabo mejoras. Nótese que algunas herramientas innovadoras no incrementan automatización pero incrementan productividad y/o calidad.

Factor humano

Así como el Prisma Lean-Agile tiene valor como su pináculo, innovación de valor tiene como su cúspide el factor humano, el cual es a fin de cuentas lo que hace que la innovación suceda. Las herramientas, el ambiente y el pensamiento innovador son las bases para que las personas generen ventajas competitivas y maduren la empresa. A fin de cuentas, lo que los líderes deben gestionar no son proyectos sino personas.

Caso de éxito

En México apliqué innovación de valor como parte de la adopción lean-agile. La tabla 1 muestra la transformación obtenida. Antes

Después

Productividad

72 hrs/semana

45 hrs/semana

Defectos

N defectos

N/20 defectos

Requerimientos

T tiempo

T/5 tiempo

Integración

Manual

90% Automatizada

Comunicación con el cliente

Terrible

La mejor relación de su historia

Proyecto

A punto de ser cancelado

Rescatado e instalado en 3 sedes (planeado a 20 sedes adicionales)

Tabla 1. Antes y después de adoptar lean-agile Kanban utilizando innovación de valor.

Software Guru

Pensamiento innovador

Herramientas innovadoras

www.sg.com.mx |

La forma que propongo para pensar en innovación es tomar como punto de inicio cosas que ya existen y generar algo nuevo que resulta en un cambio positivo significativo que agrega valor al cliente y a la empresa. Ello implica éxito comercial. Ese algo nuevo puede tener que ver con procesos, herramientas, formas de colaborar, etc. y puede ser de cualquier tamaño y grado de simplicidad. Su resultado es una aceleración en la ventaja competitiva y en la madurez empresarial con lo cual se alcanza flujo continuo de valor más fácilmente y se mejora construyendo sobre sus propios éxitos.

.COLUMNA Invitada

MAAGTIC tips de instrumentación ›› Por Héctor Santillán

omo muchos de ustedes saben, en noviembre de este año vence el plazo otorgado para que las Unidades de Tecnologías de la Información (UTIC) de la Administración Pública Federal en México concluyan la instrumentación del MAAGTIC (Manual Administrativo de Aplicación General en Materia de TIC). A pesar de que ya hemos compartido en estas páginas artículos que describen MAAGTIC, consideramos oportuno ahondar en algunos aspectos importantes para su instrumentación, que no necesariamente son obvios.

Flexibilidad de instrumentación

El contexto del MAAGTIC no sólo se refiere a los cuerpos de conocimientos y modelos de referencia en los que se basó su definición, también hay trabajo que realizar hacia el interior de la Dependencia o Entidad. Parte de la confusión que se ha provocado con este marco de rerencia, tiene que ver con los aspectos técnicos que son a discreción de la UTIC y los que son de observancia obligatoria por su carácter normativo. La UTIC puede y debe decidir sobre los aspectos técnicos de adopción e instrumentación relativos al Modelo de Gobernabilidad de las TIC’s. Los aspectos normativos residen en la sección de reglas de cada proceso del MAAGTIC definido por la SFP, de manera que deberán de ser observados, o en su defecto, justificar porque no fueron instrumentados. La manera en la que la UTIC realiza su adopción e instrumentación es flexible, siempre y cuando observe y cumpla con las reglas y el demás marco normativo observable.

La complejidad para realizar cambios

Además de la tarea abrumadora de instrumentar la Gobernabilidad de las TIC’s basándose en el MAAGTIC, se pueden requerir cambios en otros contextos que a primera vista no son tan obvios, pero que sí resultan necesarios en el entorno de la Administración Pública Federal. La figura 1 muestra los probables cambios implicados en el cumplimiento del MAAGTIC. Los cambios estructurales son los más arduos de lograr, ya que generalmente dependen de la autorización e intervención de Entidades Normativas Globalizadoras como son Secretaría de la Función Pública y Secretaría de Hacienda, entre otras.

Algunas de las razones para iniciar estos cambios son: 1. El marco regulatorio observable debe de moldearse para ser coherente y consistente con la adición del MAAGTIC. 2. La coyuntura del MAAGTIC para institucionalizar la innovación y modernización de la gestión administrativa a través de las TIC’s. 3. La conveniencia de que la UTIC dependa directamente del titular de la dependencia o entidad, para agilizar y facilitar la colaboración y sinergia con las demás Unidades Responsables (UR’s). 4. Que la UTIC cuente con una estructura autorizada adecuada, para cumplir con los niveles de operación pactados con las demás UR’s, en particular con aquellos servicios que sean delicados por su importancia a nivel de responsabilidades. 5. La existencia de asimetrías o falta de alineación estructura o jurídico-facultativa, que implique la actualización del reglamento interno o algún otro instrumento jurídico equivalente. MAAGTIC deja sin efecto la normatividad que hubiera emitido la institución relativa a cualquier aspecto de Gobernabilidad de las TIC’s, pero no hay que perder de vista que sus reglas deben amoldarse y acomodarse con respecto al marco regulatorio observable. Los principales componentes normativos que típicamente integran el marco regulatorio observable son: • Leyes, reglamentos y circulares emitidos por organismos globalizadores o normativos, relevantes para la dependencia o entidad. • Reglamento interno o equivalente. • Guía técnica para la elaboración de manuales. • Manual de la organización. • Manual de políticas y normas. • Plantilla laboral autorizada. • Manual de procesos y/o procedimientos. • Observaciones de auditorías pendientes de atender o en proceso de atención. Es necesario revisar el marco jurídico y administrativo que debe ser observado. Si la operación de la UTIC no es conforme a lo que jurídica o administrativamente se debe de apegar, existe un riesgo muy alto e innecesario de que tras una auditoría, al personal de mando se le finquen responsabilidades administrativas ante la SFP, en un escenario de incumplimiento grave a la normatividad. 44

.COLUMNA Invitada

“E ste

involucramiento conviene realizarlo lo más temprano posible, buscando que las áreas se sensibi licen y asimilen que el cumplimiento del MAAGTIC es de su interés y competencia .”

Adicionalmente, por su estrecha relación con procesos, es necesaria la coordinación específica con las siguientes áreas: • La Dirección General de Personal. • La Dirección General de Recursos Materiales. • La Dirección General de Recursos Financieros. • El área de Programación y Presupuesto. Este involucramiento conviene realizarlo lo más temprano posible, buscando que las áreas se sensibilicen y asimilen que el cumplimiento del MAAGTIC es de su interés y competencia.

Cambios a nivel operativo de la UTIC

Los procesos en los que deben involucrarse los mandos superiores y que no es conveniente delegar a los mandos medios, son: • Establecimiento del Modelo de Gobernabilidad de TIC (EMG). • Administración de la Evaluación de TIC (AE). • Operación del sistema de gestión y mejora de procesos de la UTIC (OSGP). Los procesos en los que conviene que en sus iteraciones iniciales participen mandos medios y superiores, son: • Administración del portafolio de servicios de TIC (APS).

Figura 1. Probables cambios implicados en el cumplimiento del MAAGTIC.

• Diseño de servicios de TIC (DSTI). • Operación de la mesa de servicios (OMS). Todos los servidores públicos de mando de la UTIC deben involucrarse para lograr la implantación del MAAGTIC. La estrategia de asignar la tarea a un puñado de personas no es recomendable debido a que: • El esfuerzo de adopción está entre 20 y 40 meses hombre, para una dependencia o entidad mediana. • Hay muchas áreas y dominios tecnológicos involucrados, por lo que difícilmente un pequeño equipo interno tendrá el cúmulo suficiente de conocimientos y experiencias para desarrollar todos los aspectos sin ayuda interna y externa. • Es imprescindible que las áreas realicen las definiciones de los procesos para hacerlos suyos, facilitando el proceso de adopción del cambio. La mejor estrategia de instrumentación es mediante ciclos evolutivos, buscando que cada ciclo materialice procesos y productos que vayan dando visibilidad, sustentabilidad y que permitan una transición más cómoda hacia el modelo de gobernabilidad que busca el MAAGTIC. Sobre esta recomendación y la profundización sobre el tema ya se ha hablado con anterioridad, pero es conveniente reiterarlo. El arranque del MAAGTIC comienza con la planeación presupuestal del 2012, asociado con los proyectos TIC’s y la sustentabilidad presupuestal de los actuales servicios.

››Por Héctor Santillán En Facebook, a través de la página “instrumentando MAAG TIC”, se ha formado una comunidad que comparte sus experiencias y dudas.

.BIO Héctor Santillán cuenta con 25 años de experiencia profesional como consultor, dedicando los últimos 12 años a la Administración Pública Federal. Sus áreas de especialidad incluyen arquitectura de procesos de negocios, mejora contínua, modelos de referencia y gobernabilidad. hsantillan@smartsol.com.mx

Software Guru

Su adopción involucra a toda la Dependencia o Entidad Federal, no solo a la UTIC, por lo que con las demás áreas, conviene contemplar las siguientes actividades: • Difundir su impacto en el quehacer de la institución y en su relación con la UTIC. • Explicar y concertar los acuerdos de niveles de operación (OLA), así como allegarse de los recursos necesarios para poder cumplirlos. • Definir su participación en: la planeación estratégica de las TIC’s, la administración del portafolio de proyectos de las TIC’s, el proceso de administración de la evaluación de la TIC’s. • Compartir el nuevo modelo de contacto, a partir de la mesa de servicios, el cual es resultado de la instrumentación del MAAGTIC. • Comunicar el proceso para allegarse una solución tecnológica, tomando en cuenta el MAAGTIC.

www.sg.com.mx |

Coordinación con otras áreas

.COLUMNA Programar es un Estilo de Vida

Georeferenciación ¿invasión o ventaja?

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

a nuestras espaldas

a idea para la columna de este número surgió de una plática con mi padre, comentando acerca de un texto que él presentó como parte del espacio de la Academia de Ciencias de Morelos en el periódico La Unión de Morelos el pasado 18 de abril [1]. En éste, habla sobre la disparidad de las cifras reportadas ante la manifestación dirigida por Javier Sicilia en Cuernavaca el pasado 6 de abril, y acerca de métodos que podrían utilizarse para tener una estimación más precisa. Yo, como buen consultor, le sugerí algo bonito y preciso en teoría, pero impracticable para todos los que no contamos con el poder coercitivo gubernamental: acceder a los registros de las compañías de telefonía celular, para averiguar cuántas personas entraron durante el periodo de nuestro interés a la región por donde cruzó la marcha. A fin de cuentas, una muy alta proporcionón de la población hoy en día cuenta con teléfono celular, y podría ser una buena manera no sólo de estimar la magnitud de la marcha, sino de hacerlo a lo largo del tiempo que duró. Ahora, dado que la información que poseen las telefónicas no es pública, dejamos la conversación a un nivel puramente especulativo —seguros de que las autoridades de Seguridad Pública tienen acceso a estos datos, pero que a la mayor parte de nosotros nos resultan inalcanzables, como no sea a través de una órden judicial. En los días siguientes a esta conversación, sin embargo, se presentaron varias noticias que se me hicieron interesantes, y que vinculan a esta discusión relativa a la participación ciudadana en la política nacional con temáticas más cercanas a las que toca esta revista: el cómputo ubicuo, la rastreabilidad de un dispositivo móvil, la seguridad de la información de geolocalización, y nuestro derecho a controlar quién tiene acceso a ella.

profundidad de esta información: Malte Spitz, del Partido Verde alemán, presentó una demanda judicial para obligar a Deutsche Telekom a entregarle todos los datos suyos que tuvieran registrados en los últimos seis meses. Los datos están disponibles en crudo y adicionalmente se realizó una simple aplicación [3] para presentar esta información de una manera fácil de comprender. La aplicación nos permite apreciar la profundidad de los patrones de comportamiento que puede construirse de cada uno de nosotros: ubicación geográfica, llamadas y mensajes recibidos/enviados, conexión de datos, etcétera. Si bien la geolocalización es mucho menos precisa que la que arrojaría un GPS (es obtenida por triangulación entre las torres de telefonía celular, resultando en una precisión de unos cien metros), el punto más importante es que esta información se genera y almacena centralmente, en las instalaciones del proveedor de telecomunicaciones, e independientemente de las capacidades tecnológicas de nuestro teléfono. Y si bien Malte Spitz tuvo acceso a sus datos a través de los canales legales, ¿qué tanto podemos confiar en que dichos datos estén adecuadamente protegidos de los ojos de atacantes capaces de vulnerar servidores conectados a Internet? Precisamente, el experimento de Spitz fue llevado a cabo para sustentar el peligro de la ordenanza de 2008 que obliga (y por tanto permite) a las compañías de telecomunicaciones a guardar esta información por medio año —ordenanza que en marzo de 2010 fue declarada inconstitucional. En México nos hemos topado una y otra vez con casos en que datos confidenciales han sido encontrados en el mercado negro. ¿Qué nos garantiza que esta información, escalofriantemente precisa acerca de nuestros hábitos, no está disponible al mejor postor?

Compañías telefónicas

Proveedores de hardware

En el diario alemán «Zeit Online» encontré un artículo publicado el 26 de marzo [2] que ilustra precisamente la

También en días recientes se publicaron noticias acerca de la información de ubicación que guardan los teléfo46

.COLUMNA

Programar es un Estilo de Vida

“La

tecnología va cambiando nuestra vida , y lo que para muchos puede ser visto como una invasión a la privacidad , para muchos otros representa la gran conveniencia de contar con una ubicación razonablemente precisa en un tiempo aceptable y poder compartirla con nuestros contactos facilmente.”

Conclusión

Sé que este texto puede ser leído como una carta escrita por un paranóico de las teorías de la conspiración. No es así, estoy consciente de que la tecnología va cambiando nuestra vida, y lo que para muchos puede ser visto como una invasión a la privacidad, para muchos otros representa la gran conveniencia de contar con una ubicación razonablemente precisa en un tiempo aceptable y poder compartirla con nuestros contactos facilmente. Mi convocatoria, claro, al tiempo que lleva a que tengamos conciencia de los insospechados ojos que pueden estar aprendiendo de nuestras vidas con cualquier tipo de fines, también lleva a que, como desarrolladores de aplicaciones, sepamos ser creativos y aprovechar la información que tenemos a nuestro alcance — ¡Porque sin duda podrán encontrar también maneras lícitas y atractivas de emplear estas fuentes de información!

››Por Gunnar Wolf

Referencias [1] Kurt B. Wolf. “¿Cuántos miles marchamos?”, La Unión de Morelos, 18 de abril 2011, pag. 34. http://bit.ly/sg32r5 [2] Kai Biermann. “Betrayed by our own data”, Zeit Online. http://bit.ly/sg32r6 [3] “Tell-all telephone”, Zeit Online. http://bit.ly/sg32r7 [4] Dan Goodin. “iPhones secretly track scary amount of your movements”. The Register. http://bit.ly/sg32r8 [5] Alasdair Allan, Pete Warden. “iPhoneTracker”. http://bit.ly/sg32r9 [6] Huseyin T. “iPhoneTrackerWin”. http://bit.ly/sg32r10 [7] Matthen Panzarino. “It’s not just the iPhone, Android stores your location data too”. The Next Web. http://tnw.co/sg32r11 [8] Samy Kamkar. “Android Map”. http://bit.ly/sg32r12

Software Guru

Para verificar (y/o jugar con) esta funcionalidad, pueden instalar en cualquier computadora con la que hayan sincronizado un iPhone o iPad el iPhoneTracker (MacOS) [5] o iPhoneTrackerWin (Windows) [6]. En el sitio del iPhoneTracker hay una interesante lista de cuestionamientos. Claro, pero el que Apple controle los dispositivos que los usuarios han comprado no es novedad. Quienes me conozcan, probablemente esperan que haga a continuación una apología de por qué el software libre es más seguro, y por qué deberían todos cambiar a un teléfono basado en el sistema Android. Sin embargo, la situación no es tan distinta ahí. Con la salvedad de que para que éste archivo exista el usuario tiene que haber aceptado previamente que el teléfono provea servicios relacionados con los datos de geolocalización (sin duda una muy importante característica de los equipos, y que poca gente dejará desactivada), los teléfonos Android guardan también información con nivel de detalle muy similar [7]. Al menos, la información no se mantiene a largo plazo: los dispositivos Android guardan solamente las últimas 50 ubicaciones derivadas de torres celulares, y hasta 200 derivadas de redes WiFi. Ahora, de este último punto podemos aún jalar más hilo: Si bien el contrato de licencia del software de Apple permite que reciban todos los datos de ubicación, hasta el momento han negado estar utilizándolos. Sin embargo, al autorizar a Android, explícitamente estamos autorizando que esta información sea re-

portada a Google. Adicionalmente, los dispositivos con Android notifican a Google la ubicación de cada red inalámbrica que encuentran, como lo demuestra el sitio Web desarrollado por Samy Kamkar [8].

www.sg.com.mx |

nos inteligentes. Los equipos iPhone e iPad de Apple que corren el iOS versión 4 o superior guardan un registro histórico de los puntos por los que ha pasado el usuario [4]. Y si bien esto no debería sorprendernos, hay tres puntos clave en lo revelado: • Los datos son guardados sin cifrado, y son incluídos en todo respaldo hecho al dispositivo. • La licencia de uso del software permite expresamente a Apple recolectar, usar y compartir información precisa respecto a la ubicación, incluyendo la ubicación geográfica en tiempo real de tu dispositivo. • La información recopilada no se limita a una ventana de tiempo preestablecida, sino que durará la vida entera del equipo.

.COLUMNA Tecno-lógico

ALM en el Mundo de Usuario y Servicios

mucho más que desarrollo

efinir la administración del Ciclo de Vida de una Aplicación (Application Lifecycle Management o ALM) no es fácil: diferentes personas, diferentes empresas y proveedores de servicios tienen diferentes perspectivas sobre el tema y la información pública al respecto tiende a ser confusa. Sin embargo, ALM es un proceso importante en la producción de aplicaciones por lo que vale la pena entender los conceptos que engloba y cómo nos beneficia. Un error común es hacer la equivalencia de ALM con el proceso de Ciclo de Vida de Desarrollo de Software (Software Development Lifecycle o SDLC) ya que esta comparación es muy limitada. ALM es mucho más que únicamente SDLC. Para que nuestra visión de ALM sea tanto justa como útil debemos tener una perspectiva más amplia para definir lo que es la “vida de la aplicación”, algo que debería incluir todo el tiempo en el que una empresa invierte dinero en un producto de software, desde la idea inicial hasta el último momento en la vida de una aplicación.

Los tres aspectos de ALM

Mauricio Angulo es programador desde 1989, divulgador, ávido escritor y emprendedor. Actualmente es CEO y fundador de Tesseract Space donde realiza funciones de asesor y consultor en innovación tecnológica, mercadotecnia digital y experiencia de usuario.

La Administración del Ciclo de Vida de una Aplicación se divide en tres áreas: Gobernanza, Desarrollo y Operaciones. De la misma manera que en el desarrollo de algo vivo, un proyecto de software está marcado por eventos significativos. Empezamos con una idea: ¿por qué no hacemos algo que resuelva esto o aquello? Una vez que la aplicación es creada –o al menos un primer acercamiento- el siguiente gran evento es la entrega (deployment) cuando la aplicación sale a producción y finalmente, cuando la aplicación ya no tiene valor comercial esta se quita de servicio y llega al final de su vida. Podemos hablar rápidamente de los tres pilares horizontales que componen ALM durante el ciclo de vida de un producto de software: • El primer paso de la gobernanza es el desarrollo de los casos de negocio. Este análisis por lo general pasa antes de que el proceso de desarrollo comience y una vez que el caso de negocio es aprobado es cuando el desarrollo comienza y la gobernanza es implementada durante la ejecución del proyecto. • El proceso de desarrollo –o SDLC- es una parte del proceso de ALM y es normalmente representado como una serie de interacciones entre el equipo que escribe código de la aplicación y otras personas que proveen servicios de revisión, testeo, aseguramiento de la calidad y varios más. Los acercamientos a cómo se desarrolla el software varían según el caso y los recursos con los que se cuenten. • Al igual que con la gobernanza, el proceso de operaciones está íntimamente ligado a la línea de desarrollo.

Por ejemplo, la planeación para implementación comienza poco después de que la aplicación es completada y el acto de liberación en sí mismo es una parte fundamental de las operaciones. Una vez que la aplicación es liberada, ésta debe ser monitoreada durante el resto de su ciclo de vida y en cada mejora o corrección se debe repetir el proceso de liberación.

Un mundo de servicios

Si bien los procesos de ALM se ajustan a los ciclos de diseño-creación-liberación de software que requiere administración y reemplazo, los nuevos modelos de desarrollo basados en la red y más aún, el modelo de Software + Servicios que propone el desarrollo no sólo de aplicaciones sino de servicios que viven en la Nube y cuyo ciclo de vida es diferente que lo que conocemos como una ‘aplicación’, un término que se refiere normalmente a un programa construido por varios componentes corriendo en un dispositivo digital como una computadora o un dispositivo móvil, pero que ahora muchos de esos componentes –o servicios- no se encuentran ni en nuestra organización y su desarrollo, aunque en la mayoría de los casos esté bien documentado, se encuentra fuera de nuestro control directo. En un mundo de servicios ¿cómo administramos la vida de nuestras aplicaciones cuando algunos de sus componentes siguen ciclos de vida diferentes? Tal vez el término correcto debería ser ‘Software Life Management’ o SLM en lugar de ALM, aunque este es sólo un ajuste en la nomenclatura. Como podemos ver, la visión tradicional de ALM deja de funcionar en la medida en que las redes se vuelven omnipresentes y tanto los dispositivos como los servicios se multiplican.

De frente al usuario

Otro concepto normalmente dejado al final, si no es que completamente de lado en la administración del ciclo de vida de una aplicación es lo pertinente a Experiencia de Usuario (User Experience o UX) que abarca cuestiones de diseño de interfaces, usabilidad, accesibilidad, utilidad y otros lineamientos de mercadotecnia que se crean durante el proceso de gobernanza, los cuales tienen un impacto claro y cuantificable sobre los objetivos de negocio en la liberación del producto y que encarecen el proceso de operación al relegarlos a los ciclos de actualización y mantenimiento. Los conceptos asociados a lograr buenas experiencias de usuario deben ser incluidos como parte vital del ciclo de vida de una aplicación desde su principio hasta su fin: en el proceso de gobernanza se debe poner foco en las necesidades y problemas de los usuarios a quienes va dirigida una aplicación; 48

en el proceso de desarrollo se debe interactuar con usuarios tipos y tener como motor de desarrollo las necesidades de ellos, y finalmente los ciclos de operación deben considerar la retroalimentación de sus usuarios para crear mejores productos de software.

Conclusión

ALM es mucho más que sólo escribir código, ya que los tres aspectos del ciclo de vida de una aplicación –gobernanza, desarrollo y operaciones- son igualmente importantes. Si tenemos un proyecto en el que la gobernanza inicial tiene mal definidos los aspectos de arranque, por ejemplo, tal vez no entendiendo las necesidades de negocio o al no elegir a los patrocinadores correctos para el proyecto. No importa que tan bien el equipo que haga el desarrollo o maneje la operación haga su trabajo, el proyecto simplemente no proveerá ningún valor de negocio y acelerará su tiempo de fin de vida. De igual manera, un proyecto que tenga los lineamientos y visión adecuada utilizando un proceso de primer nivel para el desarrollo pero que deje de lado los temas de operación, como proveer suficientes recursos para que la aplicación corra de manera confiable terminará en fracaso, ya que el valor de negocio que se pretende proveer no tendrá el tiempo de vida lo suficientemente largo o la confianza de sus usuarios para ser económicamente viable. Muchas empresas y grupos de desarrollo de software se crean una visión miope de ALM limitada por lo que las herramientas de administración del ciclo de vida pueden o no hacer y esto es un claro error. Una visión más amplia de ALM puede ayudar a las organizaciones que desarrollan tecnología a evitar este tipo de problemas cuyo alcance va más allá de sólo manejar código y pruebas. La visión y las expectativas de la tecnología también han cambiado y no podemos hablar de manejar ciclos de vida y manejo de versiones como lo hemos visto hasta hoy: la visión del desarrollo orientada a servicios nos obliga a tener una visión más amplia y holística de ALM para mejorar los procesos críticos del negocio y del desarrollo a futuro.

››Por Mauricio Angulo

.Fundamentos

Introducción a Node.js ››Por Daniel Zavala

n los últimos años Javascript ha crecido y empezado a tener un espacio importante en la escena de los lenguajes de programación. Poco a poco el potencial de los navegadores web ha aumentado, y con ello la capacidad de construir aplicaciones interactivas sin necesidad de instalar plugins o instalar software adicional. Esto atrajo a muchos programadores, quienes a su vez empezaron a sacar a Javascript del browser y han creado frameworks de javascript para crear aplicaciones móviles, tales como Phonegap y Titanium Appcelerator. En el lado del servidor, Javascript también ha evolucionado significativamente. Una de las personas que más ha contribuido en este sentido es Douglas Crockford, quien actualmente es Arquitecto Javascript en la empresa Yahoo!. Una de las tecnologías “server-side” javascript que más fuerza está tomando y que promete mucho, es Node.js. Conocido también como “Node”, éste fue creado por Ryan Dahl y presentado por primera vez en el JSConf2009, y en poco tiempo ha logrado desplazar en popularidad a otras implementaciones de server-side javascript como Rhino, Ringo y Narwhal. Un aspecto fundamental de Node.js es que es un non-blocking event server (servidor de eventos sin bloqueo). Algunas alternativas similares son Event Machine en Ruby y Twisted en Python. ¿Qué es eso de un servidor de eventos sin bloqueo? Bueno, pues sucede que en la mayoría de los lenguajes de programación, el comportamiento default al realizar una petición a la base de datos, es que el programa se quede esperando la respuesta y no haga nada más; es decir, las peticiones se manejan de forma síncrona. En cambio, en un servidor de eventos las peticiones son asíncronas, por lo que se realiza una petición, y mientras llega la respuesta se pueden realizar otras tareas y una vez que se reciba la respuesta se procesa la información correspondiente. Este tipo de comportamiento es el mismo que se tiene con Ajax en el lado del cliente. Node.js corre sobre V8, el motor de Javascript de Google Chrome, el cual es conocido por su velocidad. La buena noticia es que Mozilla Software Foundation ya está implementando Node.js sobre su su propio motor de Javascript, SpiderMonkey, con lo cual se generará competencia y seguramente estaremos viendo que el desempeño de estos motores mejore aun más en los próximos meses. Por ahora, uno de los usos más comunes de Node.js es crear aplicaciones web que funcionan en tiempo real utilizando web sockets o comet (long polling). Otras aplicaciones comunes de node.js es el monitoreo de servidores y scripts para reducir (minify) CSS y Javascript.

javascript sigue evolucionando

Hola mundo

El típico “hola mundo” de Node.js consiste en programar un servidor web. El listado 1 muestra el código para esto: var http = require(‘http’); http.createServer( function (req, res) { res.writeHead(200, {‘Content-Type’: ‘text/plain’}); res.end(‘Hello World\n’); }).listen(1337, “127.0.0.1”); console.log(‘Server running at http://127.0.0.1:1337/’); Listado 1. Servidor web en node.js

Lo primero que hace el código es cargar el módulo http y guardarlo en una variable. Después creamos un servidor con la función “createServer”, la cual toma como parámetro una función callback que recibe como parámetros una petición y una respuesta (req, res). En este caso, la respuesta consiste en imprimir una página web en texto plano que diga “Hello World”. Una vez que definimos lo que va a realizar nuestra función, comenzamos a escuchar peticiones en un puerto específico (en este caso elegimos el 1337) e imprimimos un mensaje de aviso. Para generar un servidor web tipo Comet, lo único que tenemos que hacer es retrasar la respuesta hasta que tengamos la información que deseamos enviar. El listado 2 muestra como hacerlo. var http = require(‘http’); var e = require(‘events’).EventEmitter; http.createServer( function (req, res) { event.on(‘comet’, function (data) { res.writeHead(200, {‘Content-Type’: ‘text/plain’}); res.end(data); }); }).listen(1337, “127.0.0.1”); console.log(‘Server running at http://127.0.0.1:1337/’); Listado 2. Servidor tipo comet

Es un código muy similar al anterior, con la diferencia de que cargamos el módulo emisor de eventos de Node.js (EventEmitter) y esperamos a tener un evento de tipo ‘comet’ para responder a la nueva conexión que tenemos. Para disparar el evento, en algun lugar de nuestra aplicación agregaríamos algo como: event.emit(‘comet’, ‘Esta es tu nueva información’);

››un aspecto fundamental de node.js es que es un non-blocking event server, o servidor de eventos sin bloqueo.

Así, podemos usar jQuery y hacer una petición con $.ajax() al url donde tengamos nuestro servidor y responder a eventos como mensajes en un chat o cambio a un archivo. También podemos hacer que una url en nuestra aplicación cada que reciba una petición publique lo que recibe y de esta forma conectarlo con cualquier aplicación que utilice webhooks. Generar un servidor de Comet con Node.js implica agregar un par de líneas a nuestra aplicación, mientras que lograr esto mismo en un servidor Apache es mucho más complicado y poco eficiente.

Por donde empezar

Las instrucciones para instalar Node.js están disponibles en https://github.com/joyent/ node/wiki/Installation su sistema operativo. Una vez que lo tengan instalado les recomiendo ir a http://search.npmjs.org para buscar librerías. También existen PaaS tipo Heroku para Node.js como No.de, Nodester y DotCloud. .BIO Daniel Zavala es un desarrollador web freelancer. Actualmente colabora con la Facultad de Filosofia y Letras de la UNAM para generar la Biblioteca Digital del Pensamiento Novohispano. También ayuda con la organizacion del Super Happy Devhouse Mexico City y es cofundador del Hacker Room. @siedrix

.TECNOLOGÍA Infraestructura

Predicción y Medición del

Desempeño Paralelo

conoce la aceleración potencial de tus aplicaciones ››Por Intel Software Network

onstruir software paralelizable habilita a las aplicaciones para ejecutar múltiples operaciones al mismo tiempo, mejorando así su desempeño. El éxito de la paralelización suele cuantificarse midiendo la aceleración de la versión paralela relativa a la versión serial. Sin embargo, también es útil comparar la aceleración lograda con su límite máximo de aceleración potencial. En este artículo veremos como hacer esto.

Aceleración y eficiencia

Cuanto más rápido se ejecuta una aplicación, menos tiempo necesitará esperar un usuario para obtener resultados. Un tiempo de ejecución más corto permite también a los usuarios operar sobre conjuntos de datos más grandes (por ejemplo, más registros de datos, más píxeles o un modelo físico más grande) en una cantidad de tiempo aceptable. El término “aceleración” (speedup) se utiliza para comparar el tiempo de ejecución entre una versión serial y una versión paralela. Por ejemplo, si la aplicación serial se ejecuta en 6,720 segundos y la aplicación paralela se ejecuta en 126.7 segundos (usando 64 núcleos de procesamiento), la aceleración obtenida es 53X (6720/126.7 = 53.038). En una aplicación que escala bien, la aceleración debería aumentar a un ritmo cercano al que se aumentan el número de núcleos. Si al aumentar el número de núcleos la aceleración no crece a un ritmo comparable, entonces la aplicación no escala bien. La métrica de eficiencia indica qué tan bien el software utiliza los recursos computacionales del sistema. Para calcular la eficiencia de la ejecución paralela, tome la aceleración observada y divídala entre el número de núcleos usados. Entonces este número se expresa como un porcentaje. Por ejemplo, una aceleración de 53X en 64 núcleos es igual a una eficiencia de 82.8% (53/64 = 0.828).

Ley de Amdahl

Antes de iniciar un proyecto de paralelización, es posible calcular la aceleración que se puede lograr. Si se conoce (o se puede estimar) el porcentaje de ejecución de código serial que se podría ejecutar en paralelo, se puede emplear la Ley de Amdahl para calcular un límite superior en la aceleración de una aplicación sin necesidad de escribir código concurrente.

Figura 1. Fórmula de Ley de Amdahl para estimar aceleración.

La figura 1 muestra una formulación simple de la Ley de Amdahl para estimar la aceleración de una aplicación paralela: donde pctPar es el porcentaje (propuesto) de tiempo de ejecución paralela, 1-PctPar es el porcentaje de ejecución serial y p el número de núcleos a utilizar. Por ejemplo, si el 95% del tiempo de ejecución de una aplicación serial pudiera realizarse en paralelo con ocho núcleos, entonces la aceleración estimada según sería cercana a 6X (1 / (0.05 + 0.95/8) = 5.925). Las formulaciones de la Ley de Amdahl asumen que los cálculos que se pueden ejecutar en paralelo serán divisibles entre un número infinito de núcleos. Tal suposición hace que el segundo término del denominador tienda a cero, lo que significa que la mayor aceleración posible es simplemente el inverso del porcentaje de ejecución serial. Este enfoque omite las tareas de procesamiento adicionales inherentes a la parelelización tales como la comunicación, sincronización y administración de threads. Adicionalmente, asume un conjunto de datos fijo, lo cual tampoco es realista ya que conforme aumente el número de núcleos, es probable que también aumente la cantidad de datos que se manejan.

Ley de Gustafson

Si una aplicación paralela usando ocho núcleos pudiera operar sobre un conjunto de datos ocho más grande del original, ¿aumenta el tiempo de ejecución de la porción serial? Incluso si lo hiciera, no sería en la misma proporción que aumentó el conjunto de datos. En la práctica se ha visto que el tiempo de ejecución serial se mantendrá casi constante. La Ley de Gustafson, conocida también como aceleración escalada (scaled speedup), toma en cuenta un incremento en el 52

.TECNOLOGÍA

Infraestructura

“Un tiempo de ejecución más corto per-

mite también a los usuarios operar sobre conjuntos de datos más grandes.”

donde p es elnúmero de núcleos y s el porcentaje de tiempo de ejecución serial en una aplicación paralela para un tamaño determinado del conjunto de datos. Por ejemplo, si 1% del tiempo de ejecución en 32 núcleos se destinará a la ejecución serial, la aceleración de esta aplicación comparada con una ejecución sobre un solo núcleo utilizando el mismo conjunto de datos sería: 32 + (1 - 32) (0.01) = 32 - 0.31 = 31.69X. Consideremos ahora la estimación que nos arrojaría la Ley de Amdahl con estas suposiciones. Si el porcentaje de ejecución serial es 1%, entonces la Ley de Amdahl produce 1/(0.01 + (0.99/32)) = 24.43X. Sin embargo, éste es un cálculo falso, ya que el porcentaje dado de tiempo serial es relativo a la ejecución con 32 núcleos. Los detalles de este ejemplo no indican cuál sería el porcentaje de ejecución serial correspondiente para más o menos núcleos (o incluso un núcleo). Si el código es perfectamente escalable y el tamaño de los datos escala con el número de núcleos, entonces este porcentaje se pudiera mantener constante y el cálculo de la Ley de Amdahl sería la aceleración estimada del problema (de tamaño fijo) trasladado de 1 núcleo a 32 núcleos. Por otro lado, si se conoce el tiempo de ejecución total de la aplicación paralela con 32 núcleos, entonces se puede calcular el tiempo de ejecución serial y se podría estimar la aceleración para ese problema de tamaño fijo con la Ley de Amdahl en 32 núcleos. Supongamos que el tiempo de ejecución total de una aplicación paralela es 1,040 segundos en 32 núcleos, y que el 1% de ese tiempo fuera de ejeución serial (10.4 segundos). Para determinar el trabajo total de procesamiento en todos los co-

Consideraciones adicionales

Al calcular la aceleración, debemos utilizar como referencia el mejor algoritmo serial y el código serial más rápido posible, aún si dicho algoritmo y código no sean los que más se prestan a paralelización. En muy raras circunstancias, la aceleración de una aplicación excede el número de núcleos. Este fenómeno se conoce como aceleración súper lineal. La causa típica de la aceleración súper lineal es que la descomposición de un conjunto de datos de tamaño fijo provoca que las partes sean los suficientemente pequeñas como para alojarse en el caché local. Al ejecutarse de forma serial, los datos tenían que ser transportados al caché y el procesador debía esperar mientras se buscaban y reacomodaban los datos en el caché. Existen otros modelos que incorporan detalles que la Ley de Amdahl omite. Aun así, si se tiene en cuenta que lo que nos da la Ley de Amdahl es solamente un límite superior teórico de forma sencilla, consideramos que es una forma muy práctica para estimar el potencial de aceleración de una aplicación serial.

.BIO Este artículo es parte de la serie “Intel Guide for Developing Multithreaded Applications” , que proporciona lineamientos para el desarrollo de aplicaciones multithreaded eficientes. Puedes consultar la versión original en http://intel.ly/sg32r1

Software Guru

Figura 2. Fórmula para la aceleración escalada.

res, multiplicaríamos el tiempo de ejecución paralela (1029.6 segundos) por el número de núcleos (32) y sumaríamos el tiempo serial (1029.6*32+10.4 = 32957.6 segundos). El tiempo serial (10.4 segundos) es 0.032% de ese tiempo de trabajo total. Con esa cifra, la Ley de Amdahl nos da una aceleración de 1/ (0.00032 + (0.99968/32)) = 31.686X. Dado que para usar la Ley de Gustafson se requiere conocer el porcentaje de tiempo serial dentro de la ejecución paralela, esta fórmula típicamente se utiliza para estimar la aceleración de la ejecución paralela escalada (conjuntos de datos más grandes conforme aumenta el número de núcleos) respecto a la ejecución serial del mismo problema.

www.sg.com.mx |

tamaño de los datos en proporción al incremento en el número de núcleos y calcula la aceleración (límite superior) de la aplicación, como si el conjunto de datos de mayor tamaño se pudiera ejecutar en forma serial. La figura 2 muestra la fórmula de la aceleración escalada:

.TECNOLOGÍA Gadgets

Sony

Internet TV La palabra “entretenimiento” en cuanto a televisión se refiere toma una nueva forma alineada a la realidad que vivimos ¡una realidad donde ya nada es pasivo! Sony Internet TV es la nueva línea de pantallas Bravia que cuentan con el procesador X-Reality (exclusivo de Sony) que reproduce imágenes con detalles mucho más nítidos y definidos, con texturas únicas de alta calidad de imagen en movimiento, además, combina la funcionalidad de un buscador web con una amplia variedad de contenidos como Facebook, Twitter, Picasa y Skype, además ofrecen programación on demand, como Wired, Video Detective, Tara Stiles (clases de yoga), GolfLink.com (videos para practicar y mejorar en el golf ) y acceso a contenido de Youtube. La nueva línea de pantallas Bravia, esta disponible desde el día 6 de mayo en tiendas SonyStyle Store, tiendas especializadas, departamentales, clubes de precio y a través de la página www.sonystyle.com.mx. “La televisión deja hoy de ser pasiva, para convertirse en un portal hacia un universo de entretenimiento”.

Razer

Switchblade Con las opciones que se tienen en el mercado respecto a videojuegos, desde un aparador podría no llamarnos la atención el nuevo Razer Switchblade porque se trata mas bien de un “amor a segunda vista”: Tiene la forma de una mini laptop, con Windows 7, conectividad 3G y WiFi, salida mini HDMI y puerto USB 3.0, hasta aquí todo normal ¿no? Lo que la hace diferente es su pantalla LCD multitáctil y que su teclado tiene una capa de botones transparentes que van cambiando de contenido de cada tecla dependiendo del juego que se elija, incluso mientras se va jugando, dependiendo del nivel o necesidad del juego el teclado va cambiando. El Razer Switchblade es tan intuitivo como tú.

MILI

iPhone projector ¿Por qué no un gadget más para el iphone? ¡A sacarle más jugo! El MILI iphone projector es un proyector portátil diseñado para ser conectado a los puertos del iPhone o también del Ipod para visualizar lo que tengas almacenado y quieras compartir a lo grande. Cuenta con altavoces, y con 3 horas de carga podrás tener por lo menos una hora y media de proyecciones con sonidos. Su utilidad va más allá del entretenimiento, conservando la satisfacción personal y profesional que se adquiere con el iphone, el MILI iphone projector puede ser utilizado para entretenimiento y en los negocios. ¡Proyéctate!

Directorio Advantage

www.reachcore.com

Pág. 51

Agile Conference México 2011

Pág. 2F

www.cutter.com.mx/ agileconferencemexico2011

Alpha Consultoría

Pág. 49

Pág.15

Pág.35

PI Consulting www.piconsulting.com.mx

Pág.07

Pronatura www.pronatura.org.mx

Pág. 4F

Qualtop

Pág. 39

www.alpha-consultoria.com

Embarcadero Technologies

www.embarcadero.com

Extend Solutions www.extend.com.mx

www.qualtop.com

Sequal Solutions

Pág.13

www.sequal.com.mx

SG Guía

Pág. 3F

www.sg.com.mx/guía

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

.biblioteca

Las 17 Leyes Incuestionables del Trabajo en Equipo John C. Maxwell Grupo Nelson, 2001

Siendo el desarrollo de software una gran labor de trabajo en equipo en donde los clientes y los usuarios también son parte del mismo, les recomendamos ampliamente el libro “Las 17 Leyes Incuestionables del Trabajo en Equipo” de John C. Maxwell, quien es un conocido experto estadounidense en liderazgo, que ha enseñado por años los beneficios del liderazgo y de la creación efectiva del mismo. Cada ley es explicada de forma clara, lo suficientemente amplia para comprender sin aburrir al lector. Incluye casos y anécdotas que ilustran el contexto para su mejor comprensión, así como también puntos específicos de acción, frases y preguntas que invitan a la reflexión, pero sobre todo, invitan a la acción. Leyes como “La ley de lo trascendental”, “La ley de la especialización”, “La ley de la confiabilidad”, reflejan la necesidad de su aplicación en cada una de las fases del desarrollo de proyectos. Este libro es ideal para Líderes de TI que desean incrementar la productividad en sus equipos ya que hay varias razones por las que los profesionistas del software insisten en el trabajo solitario, pero hay muchas más y mejores razones para poder trabajar en equipo. Aunque desarrollemos siempre en las mismas plataformas y lenguajes, no encontraremos dos proyectos iguales en circunstancias y contextos. Así como los proyectos de desarrollo de software vienen en todas formas y tamaño, de la misma manera vienen los equipos.

Manual de Aplicaciones:

Guía para Manejar con Maestría el Ciclo de Vida de las Aplicaciones Modernas Brad Hipps, Mark Sarbiewski HP, 2010

A pesar de que esta es una guía desarrollada y publicada por una empresa de software, no le quitamos merito ya que su contenido es muy relevante y valioso para todos aquellos que forman parte de una organización de TI. El libro comienza con una reflexión bastante interesante, “la empresa moderna se construye a partir de widgets y bits”. Estamos dejando atrás los días en que las empresas se apoyaban en un conjunto pequeño de “super aplicaciones”. En las organizaciones modernas, prácticamente todos los procesos de negocio se realizan por medio de la interacción con sistemas de información. Cada vez más, nos encontramos con sistemas atómicos que realizan una sola función, que se integran con muchos otros sistemas similares para sustentar

procesos de negocio completos. Dichos sistemas atómicos son accesibles de distintas formas, desde widgets hasta aplicaciones móviles, y pueden o no estar bajo el control y operación de la empresa. Este panorama involucra un nuevo y enorme reto para los responsables de administrar dichos entornos. La guía está estructurada en 4 capítulos que corresponden a las etapas de ciclo de vida de una aplicación: planeación, desarrollo, ejecución y retiro. Los temas que se abordan a lo largo de los distintos capítulos involucran aspectos como gestión de portafolio de aplicaciones, gobernabilidad, ciclos de vida para el desarrollo de aplicaciones, gestión del rendimiento de las aplicaciones, gestión de la seguridad y gestión de cambios. La guía se puede obtener en formato digital en http://bit.ly/sg32r18 56