SG #32

Introduccion a Node.js

Anonymous — Thu, 03 Nov 2011 04:20:36 +0000

Introduccion a Node.js Anonymous Wed, 11/02/2011 - 22:20

Publicado en

SG #32

Fundamentos

Autor

Daniel Zavala

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

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’);

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

ALM en el mundo de usuario y servicios: Mucho más que desarrollo

Anonymous — Tue, 17 May 2011 15:50:30 +0000

ALM en el mundo de usuario y servicios: Mucho más que desarrollo Anonymous Tue, 05/17/2011 - 10:50

Publicado en

SG #32

Tecno-lógico

Autor

Mauricio Angulo S.

Definir 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

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

Bio

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.

Georeferenciación a nuestras espaldas: ¿Invasión o Ventaja?

Anonymous — Tue, 17 May 2011 15:40:36 +0000

Georeferenciación a nuestras espaldas: ¿Invasión o Ventaja? Anonymous Tue, 05/17/2011 - 10:40

Publicado en

SG #32

Programar es un Estilo de Vida

Autor

Gunnar Wolf

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

Compañías telefónicas

En el diario alemán «Zeit Online» encontré un artículo publicado el 26 de marzo [2] que ilustra precisamente la 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?

Proveedores de hardware

También en días recientes se publicaron noticias acerca de la información de ubicación que guardan los teléfonos 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.

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 reportada 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].

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!

Referencias

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

Bio

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

MAAGTIC: Tips de instrumentación

Anonymous — Tue, 17 May 2011 15:30:22 +0000

MAAGTIC: Tips de instrumentación Anonymous Tue, 05/17/2011 - 10:30

Publicado en

SG #32

Autor

Héctor Santillán

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

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

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.

Coordinación con otras áreas

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.

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).
• 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.

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

En Facebook, a través de la página “instrumentando MAAGTIC”, se ha formado una comunidad que comparte sus experiencias y dudas.

Bio

Big Data: La base de datos relacional no lo es todo

Anonymous — Tue, 17 May 2011 14:45:35 +0000

Big Data: La base de datos relacional no lo es todo Anonymous Tue, 05/17/2011 - 09:45

Publicado en

SG #32

Tendencias en Software

Autor

Luis Daniel Soto Maldonado.

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

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

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.

Bio

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

Innovación de valor mediante Lean-Agile: Logrando ventaja competitiva

Anonymous — Mon, 16 May 2011 18:11:36 +0000

Innovación de valor mediante Lean-Agile: Logrando ventaja competitiva Anonymous Mon, 05/16/2011 - 13:11

Publicado en

SG #32

Agilidad

Autor

Masa K. Maeda

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

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:

a) El más barato.
b) 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 implica que si una de las dos empresas llevó a cabo innovación con respecto a valor para con el cliente tal que su producto es más atractivo entonces es más probable que tenga una ventaja competitiva.

Ahora bien, si tenemos de nuevo dos productos como en el caso anterior, pero en esta ocasión los dos productos ofrecen: mismas 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.

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.

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.

Pensamiento innovador

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.

Herramientas innovadoras

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.

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

Bio

El Dr. Masa K Maeda es Presidente y Fundador de Shojiki Solutions, una empresa dedicada a ayudar empresas en la adopción y mejoramiento del uso de metodologías Agile-Lean. Tiene más de 20 años de experiencia en la industria de software en Japón, México, y Estados Unidos. Obtuvo el Doctorado y Maestría en Sistemas Inteligentes y Ciencias de la Información en la Universidad de Tokushima en Japón y la Licenciatura en Ingeniería en Computación en la Universidad Nacional Autónoma de México. www.shojiki-solutions.com

Integrando la Arquitectura al Ciclo de Desarrollo de Software

Anonymous — Mon, 16 May 2011 17:54:01 +0000

Integrando la Arquitectura al Ciclo de Desarrollo de Software Anonymous Mon, 05/16/2011 - 12:54

Publicado en

SG #32

Arquitectura

Autor

A 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 primarios y las restricciones del sistema. La arquitectura se puede diseñar alrededor de estos.
Diseñar la arquitectura e, idealmente, implementar una “arquitectura ejecutable” que permita materializar el diseño de la arquitectura.
Documentar los aspectos fundamentales del diseño, teniendo especial cuidado en capturar las decisiones de diseño, para comunicarlas al equipo y 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 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.

Métodos ágiles

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 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”).

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.

Bio

El Dr. Humberto Cervantes es profesor-investigador en la UAMIztapalapa. Ha realizado investigación en temas relacionados con arquitectura de software desde el año 2000 y recientemente se ha enfocado en el estudio y aplicación de métodos que apoyen al desarrollo de arquitectura de software dentro de la industria Mexicana. www.humbertocervantes.net

La MSc. Edith Valencia es arquitecto de software en la empresa QuarkSoft S.C. Obtuvo la maestría con honores en Ingeniería de Software en la Universidad de York en El Reino Unido. Sus áreas de interés incluyen arquitecturas de software, ingeniería de procesos de software y metodologías ágiles. evalencia@quarksoft.net

Perfiles de Usuario: Una herramienta indispensable

Anonymous — Mon, 16 May 2011 17:42:49 +0000

Perfiles de Usuario: Una herramienta indispensable

Anonymous Mon, 05/16/2011 - 12:42

Publicado en

SG #32

Usabilidad

Autor

Pamela Rodríguez

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

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.

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

Figura 1. Plantilla para definición de perfil

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.

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

Estimación de proyectos de software: Un problema, una solución

sg — Fri, 13 May 2011 21:13:26 +0000

Estimación de proyectos de software: Un problema, una solución sg Fri, 05/13/2011 - 16:13

Publicado en

SG #32

Gestión de Proyectos

Autor

Francisco Valdes Souto

Hoy 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”.

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

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.

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

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.

Figura 2. Desfasamiento estimado Vs. real.

“De acuerdo al testimonio de la Government Accountability 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:

The Standish Group International, Extreme Chaos, The Standish Group International, Inc, 2000 – 2004 Research Reports.
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

La importancia de una bolsa de valores para empresas de innovación

sg — Fri, 13 May 2011 20:35:59 +0000

La importancia de una bolsa de valores para empresas de innovación sg Fri, 05/13/2011 - 15:35

Publicado en

SG #32

Emprendiendo

Autor

Víctor Chapela

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

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

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?

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.

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 inversión. Desafortunadamente, esto sólo permitiría que las grandes empresas innoven de forma incremental al desarrollar nuevos productos y hacer mejoras a procesos continuos [5]. Cualquier innovación disruptiva no encuentra un terreno fértil en los corporativos mexicanos. Sin embargo, es en las innovaciones disruptivas donde se genera mayor valor. No hay la cultura, ni los mecanismos, ni los incentivos adecuados para que los grandes corporativos mexicanos innoven de esta forma.

El emprendedor en México no tiene acceso al financiamiento apropiado ni al capital de riesgo adecuado. 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:

Pasivos - financiamiento bancario o bursátil.
Utilidades - la reinversión del resultado de ejercicios anteriores.
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 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.

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

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:

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.

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/

Bio

Víctor Chapela es Presidente y Director General de Sm4rt Security Services, empresa especializada en Seguridad Informática. Tiene más de 25 años de experiencia en emprendimientos tecnológicos. y ha fundado diez empresas en México y Estados Unidos incluyendo DigiLab, Celebrando.com, TrueCentric y Sm4rt.