SG #34

Repensando las Certificaciones

Anonymous — Thu, 01 Dec 2011 16:53:47 +0000

Repensando las Certificaciones Anonymous Thu, 12/01/2011 - 10:53

Publicado en

SG #34

Programar es un Estilo de Vida

Diversas personas me han preguntado qué certificaciones deberían buscar para afianzar su carrera o posición o cuál conviene a una empresa buscar en un prospecto de contratación. Me llama la atención principalmente el que asuman la respuesta a un cuestionamiento previo y condicionante a éste: ¿Vale la pena buscar certificaciones? Esta pregunta me puso a pensar en lo relativo a quién las pide (tanto desde el punto de vista del individuo que las persigue como del contratante que las valúa), dado el público alcanzado por esta revista, creo que puede ser de interés enfocar la columna hacia este tema.

¿Qué es una certificación?
Para el presente análisis me centro en las certificaciones como un documento emitido por una entidad comercial no dedicada principalmente a la educación superior, validando que el sustentante posee el dominio de un conjunto específico de herramientas o tecnologías (típicamente, aunque no necesariamente, limitadas a las generadas por la organización certificadora).
Las certificaciones difieren de otros métodos de calificación en que normalmente son otorgadas ante la presentación y aprobación de un examen; comúnmente no requieren que el sustentante siga un curso.

Además de lo anterior, las certificaciones frecuentemente tienen –a diferencia de prácticamente cualquier programa académico– una validez determinada, ya sea por un tiempo preestablecido, o por estar atadas a tecnologías específicas, con un ciclo de vida y obsolescencia planificado.

Y un punto adicional: Las certificaciones, si bien se presentan a sus clientes potenciales como una oportunidad de obtener mejores calificaciones para aumentar sus evaluaciones (redundando directamente en beneficios económicos), en ningún momento buscan ocultar que son para sus promotores un negocio antes que ninguna otra cosa. Lo cual, claro, no es ningún pecado, pero sí es un punto a considerar al evaluarlas. Consideremos dos perfiles en particular, los dos antiperfiles donde, a mi forma de ver, las certificaciones juegan en contra de la mayor parte tanto de individuos como de empresas.

Antiperfil 1: El recién egresado
El argumento para buscar certificaciones es simple: Si cuando un postulante es evaluado para un puesto laboral, el entrevistador de primer contacto no tiene un perfil técnico, sino que busca descartar a quien no cumpla con las características básicas que busca la empresa, en realidad la primer entrevista “real” se presenta una vez pasado ese filtro. El Can Cerbero corporativo no permitirá el paso del postulante si no cuenta con el altero completo de papeles.

Este punto de vista apunta a un postulante novato, probablemente recién egresado de la universidad, sin experiencia laboral en el mundo real, que no ha tejido aún redes profesionales y no encuentra una mejor vía de acceso. Este punto crece especialmente cuando estos nuevos integrantes de la fuerza laboral buscan emplearse en una de las relativamente pocas grandes empresas consultoras de desarrollo que hay en nuestro país.

Las certificaciones que están al alcance de un recién egresado, sin experiencia en el campo, son relativamente pocas, y el peso económico de perseguirlas resulta respectivamente elevado.

Muchas universidades han incorporado a los servicios que ofrecen a los alumnos el prepararlos para alguna certificación básica y reducir el precio a pagar por ella. Esto, en mi opinión, equivale a que dicha universidad se reconozca incapaz de ofrecer una formación suficiente para que sus egresados encuentren un puesto de trabajo adecuado y –al impulsar una tecnología específica– demerita la universalidad de la formación que dio nombre a las universidades desde un principio.

Antiperfil 2: El experto en certificaciones
Un perfil que nace como consecuencia lógica del anterior es el del experto en certificaciones. Si por cada examen que presento crece mi elegibilidad laboral, ¿por qué no acumularlos? Aprender el material necesario para presentar un examen es, a fin de cuentas, una habilidad que puede ser aprendida y dominada. Si bien muchas certificaciones incluyen la resolución de problemas prácticos, siguen presentándose en un entorno donde, hasta cierto punto, las situaciones son muy distintas a las de la vida real.
Por otro lado, una persona altamente calificada no necesariamente sabrá presentar un examen, cosa que a ninguno de ustedes debe sorprender — los ejemplos abundan, traigo ante ustedes a uno en particular, aunque sea sólo como evidencia anecdótica: He tenido oportunidad de trabajar con algunas personas verdaderamente talentosas, referencia en el campo de la seguridad y administración de sistemas, que frecuentemente asesoran a los técnicos de empresas transnacionales. Uno de ellos intentó certificarse en uno de los temas en que es pionero en nuestro país y no logró aprobarlo.
¿Significa esto acaso que su conocimiento de la tecnología, las herramientas y los procesos es menor que el de quien sí aprobó el curso? Definitivamente no. Solamente significa que los procesos mentales que ésta persona sigue no se alinean con los que la empresa certificadora sugiere. Y es precisamente esto lo que le ha permitido convertirse en su asesor: El seguir procesos creativos, no buscar dentro de lo predecible y tener un verdadero conocimiento profundo del sistema como un todo.

Alternativas
Y pasando de la crítica a la propuesta, ¿qué puedo aportar tras mi crítica a este modelo?

Para un recién egresado, enfrentarse al monstruo corporativo sin experiencia real previa no da espacio a la negociación. Mientras las empresas sigan imponiendo estos filtros previos a la entrevista real, ¿qué puede hacer quien inicia su carrera profesional?

Ser recién egresado no significa no tener experiencia real. Entrar a estudiar una carrera relacionada con la computación debería indicar una genuina afición al pensamiento analítico. En nuestro campo, tenemos la gran fortuna de que un aficionado sin estudios, sin equipo profesional y sin cualificaciones formales, puede desarrollar proyectos en casi cualquier ámbito del campo. En el cómputo, todos ustedes podrán citar numerosos ejemplos que han contribuido al campo de forma decisiva, sin formación profesional.

Claro, sería iluso pensar que todos coordináramos proyectos de gran envergadura siendo aún adolescentes o que impulsar una idea exitosa nos lleve a abandonar los estudios profesionales y saltar a la fama como estrellas de la programación. Sí podemos, sin embargo, ir haciendo públicos los pequeños proyectitos que hacemos, los retos interesantes que vamos resolviendo, los programas que escribimos por gusto. Publicar código, especialmente como software libre, es una muy buena manera de demostrar capacidad profesional, compromiso, capacidad de documentar y de brindar soporte a los usuarios. Es más, si nuestro proyecto juguete fue adoptado por una distribución de Linux, esto resulta clara muestra de que otros expertos juzgan nuestro trabajo digno de ser promovido.

Respecto al segundo antiperfil, el caso presentado ilustra que las competencias laborales de un profesional con trayectoria no pueden ser juzgadas de manera meramente cuantitativa. Los diversos campos relacionados con el cómputo requieren de una gran creatividad, y no pueden ser juzgados como una materia de la escuela, en que el desarrollo del resultado debe ser idéntico al que nos fue impartido en clase.

Quien busca contratar a un profesional con trayectoria no puede limitarse a evaluar en base a los certificados presentados. En mi experiencia, las veces que mi recomendación ha sido requerida para un proceso de selección de personal, coloco en último lugar todos los currículos que presentan certificaciones de forma destacada. Nunca me he arrepentido de hacerlo ya que estos tienden a ser los que menos conocimiento real tienen del campo.

El que una entrevista laboral para un puesto que requiere conocimientos especializados (sean de un estudiante recién graduado o de un experto) tenga que pasar por un filtro no conocedor de la materia es síntoma de un problema estructural: La tercerización a los corporativos de desarrollo de software ha crecido en detrimento de la capacidad de las entidades que las contratan. No con esto digo que deban desaparecer. Si bien debe ampliarse la capacidad de respuesta de los departamentos de sistemas de quienes típicamente contratan a estas empresas (entiéndase: Ampliarse su tamaño, sus áreas de especialización y la seguridad laboral brindada a sus integrantes), muchos de los proyectos podrían perfectamente ser encargados ya sea a empresas de escala más humana (PyMEs) o contratar a grandes empresas verdaderamente especializadas en un ramo específico. Esto, claro, reduciría el tamaño de las consultoras, pero aumentaría su calidad así como también las oportunidades laborales con una justa comparación basada en méritos reales, más cerca de quien verdaderamente requiera del servicio.

Por otro lado, no todos los proyectos en que participamos –por hobby o por encargo– puede ser publicado. Sin embargo, permítanme insistir en que la mejor carta de presentación es el trabajo realizado. En otras áreas laborales es común –incluso en algunos países, obligatoria– la pertenencia a colegios de profesionales — Cuerpos que establecen las normas mínimas de operación, calidad y cobro en el campo, y guardan registro de la actividad de sus agremiados. De tal suerte, en vez de requerir un certificado emitido por una empresa claramente parcial y con innegables intereses económicos en el área, habría una entidad a la cual preguntar acerca de la experiencia comprobable de un postulante.

Los colegios citados nacieron dada la necesidad de una entidad que validara, y asumiera responsabilidad ante dicha validación, a profesiones en las que puede haber amplia responsabilidad civil, como la medicina o la arquitectura. La importancia que van adquiriendo los desarrollos hoy en día nos lleva a plantear si no es momento de una reglamentación similar en nuestra área.
Hay lugar para las certificaciones. Hay trabajos en que hace falta contratar a alguien que domine una tecnología específica, aún sin ser un experto en el ramo entero. La distorsión, a mi opinión, está más en la escala que han adquirido. No pueden ser requeridas como carta de presentación, no puede dárselas un peso comparable al de un estudio prolongado y general (como un título universitario) o al de las capacidades demostradas con trabajo.

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

La Muerte del Botón

Anonymous — Thu, 01 Dec 2011 16:29:18 +0000

La Muerte del Botón Anonymous Thu, 12/01/2011 - 10:29

Publicado en

SG #34

Tecno-lógico

Diseñar interfaces gráficas requiere más trabajo de lo que los desarrolladores y líderes de proyecto les gusta pensar, no únicamente por el tiempo que requiere la producción de estas interfaces sino porque también necesitan pasar un proceso de revisión y pruebas de manera similar al software, pero con criterios y lineamientos completamente diferentes a los que los ingenieros y arquitectos de software están acostumbrados. Adicional a esto, las formas y maneras en que los usuarios utilizan tanto software como la tecnología están cambiando y se están diversificando: lejos están los días en que los botones y las teclas eran los puntos focales de interacción humano-máquina y hoy en día podemos afirmar sin duda que el botón, como concepto, es una especie en peligro de extinción.

Tres tipos de interacción
El término interfaz se utiliza para describir los instrumentos de comunicación e interacción entre un sistema y los usuarios que los manejan.

El ratón, el teclado y el monitor de una PC son interfaces físicas, y los elementos que están en la pantalla, desde ventanas, cajas de diálogo o de texto, iconos y demás son interfaces visuales. Los programas y servicios que corren en una computadora, un móvil o en la web realmente no necesitan interfaces, éstas existen para hacer el trabajo de sus usuarios más sencillo y para que no tengan que invertir demasiado tiempo aprendiendo comandos o realizando operaciones mecánicas una y otra vez.

La interfaz es un puente que comunica al sistema con su usuario. Las interfaces de sistemas se han hecho más sofisticadas con el tiempo, pasando de las incomprensibles tarjetas perforadas de los setentas a las sofisticados ambientes gráficos que utilizamos hoy en día, no sólo en las computadoras personales sino también en las televisiones, en dispositivos móviles y prácticamente en cualquier otro dispositivo digital.

En la historia de la computación hemos visto tres tipos de modelos generales de interacción conforme la técnica evoluciona y los usuarios no tecnológicos se vuelven más relevantes para la industria: el primero fue aquel de las Interfaces de Línea de Comando (Command Line Interface o CLI) donde el modelo de interacción estaba basado en la escritura de comandos en una consola que disparaban acciones en una aplicación. Este modelo es eficiente pero completamente desconectado del usuario y su buen funcionamiento depende de que tan bien el usuario conozca los comandos o “palabras mágicas” que lo hacen funcionar. Aunque es un entorno útil para un usuario con experiencia técnica, no es un buen punto de entrada a la tecnología en términos de una experiencia positiva o lúdica y es percibido más como una barrera que como una ayuda en la adopción tecnológica.

El siguiente modelo fue el de las Interfaces de Usuario Gráficas (Graphical User Interface o GUI), en el que imágenes y metáforas del mundo offline como un escritorio, carpetas, archiveros y documentos sustituyen los comandos por un acercamiento más humano e intuitivo. Los sistemas gráficos se basan en el reconocimiento de estas metáforas por parte del usuario y de la interacción basada en suposiciones, en prueba y error así como también de controles virtuales como menús, botones y ventanas. El problema con los entornos gráficos es que no hay consenso sobre su diseño e implementación y el usuario se ve forzado a aprender los cambios entre diferentes sistemas, aplicaciones e incluso en las diferentes versiones de los mismos.

En los últimos años las llamadas Interfaces Naturales (NUI: Natural User Interfaces) se han colocado como las preferidas de la industria de tecnologías de información porque favorecen la interacción de un usuario con la tecnología sin intermediarios físicos, como el mouse o el teclado. La idea es hacer la interacción con la tecnología lo más natural y simple posible, reemplazando los acercamientos tradicionales que vienen de las GUI como lo es la idea del botón.

Controles Naturales y No-Naturales
El botón, como lo conocemos, es una abstracción humana desarrollada durante la revolución industrial que representa el disparo o ejecución de una acción: al presionar el botón se activa un proceso y diferentes botones están asociados con distintos procesos. En las interfaces digitales, desde teléfonos inteligentes hasta páginas web, los botones son representados por gráficas de diferentes formas para que el usuario tenga opciones de navegación y acción.

El problema con el botón es que, por común que se haya vuelto, ¡no es un control natural! Los botones y todos sus parientes, los íconos, los switches, los links y los banners son solo una aproximación mental para resolver un problema pero por mucho no es la solución más óptima. La enorme cantidad de sistemas, dispositivos y herramientas que usamos hoy en día nos exigen mayor atención a las interfaces y entre más botones haya que tocar más difícil de manejar es un sistema.

Un experimento interesante al respecto es el que propone el Institute for Interactive Research con su sitio Don’t Click It (www.dontclick.it) en el que se proponen diferentes acercamientos acerca de cómo sustituir el clic en el ratón con gestos y movimientos simples sobre objetivos gráficos. El sitio ya tiene buen tiempo publicado -unos 7 años- y se ha ido enriqueciendo con la interacción y prueba de miles de usuarios que han experimentado con las interfaces del sitio.

Las nuevas interfaces táctiles en computadoras touch y en móviles inteligentes reemplazan el “clic” por el “tap”, el “flicking”, el “pinch” y otras maneras de interacción que resultan más naturales para las personas.

El Usuario y su Experiencia Digital
El diseño de interfaces digitales es un punto crucial en la aceptación o rechazo de un sistema, ya que si este es muy complicado de manejar, lo más probable es que sus usuarios no lo utilicen porque desde su punto de vista les ocasiona más problemas que soluciones. La búsqueda de esta experiencia positiva es el motor principal detrás de la evolución de las interfaces como las conocemos, conforme la tecnología se democratiza y cada vez más usuarios que no son ‘expertos’ en computación la adoptan, la industria siempre está buscando crear interfaces más simples, intuitivas y sencillas de utilizar.

Llevando el concepto de interfaces naturales al extremo, el usuario ya no necesitará tocar siquiera sus computadoras: estas responderán a la presencia del usuario, a su voz y a sus movimientos. Este tipo de interacción irá eliminando otros conceptos de las interfaces como las conocemos hoy tales como las contraseñas alfanuméricas, las identidades basadas en correo electrónico o el uso de múltiples identidades en la Red, volviendo nuestra interacción con nuestros dispositivos y también con la información, software y servicios en la Nube mucho más dinámica y personal. La finalidad del desarrollo de NUI es, por un lado, volver más accesible la tecnología a las personas que las están conociendo por primera vez (personas muy jóvenes, mayores o muy pobres) para cerrar la Brecha Digital y por otro lado, eliminar de nuestros procesos mentales la complejidad asociada con utilizar un sistema y permitirnos concentrarnos en simplemente utilizarlos.

La siguiente gran brecha digital existirá entre los Power Users que tienen años usando interfaces mecánicas basadas en palancas o botones y las personas que, siendo nativos digitales, aprendieron a utilizar las herramientas tecnológicas del siglo XXI de manera natural. El reto está, evidentemente, en que las empre- sas y personas que desarrollan software y sitios web puedan conocer e integrar los elementos de NUI a sus desarrollos para acercarnos cada vez más a una auténtica vida digital.

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 de innovación tecnológica, mercadotecnia digital y experiencia de usuario.

Datos como Plataforma

Anonymous — Thu, 01 Dec 2011 15:53:11 +0000

Datos como Plataforma Anonymous Thu, 12/01/2011 - 09:53

Publicado en

SG #34

Tendencias en Software

El costo de la “captura manual” de un petabyte de información en la década pasada rebasaba, dependiendo de la precisión, varios millones de dólares. Gracias a los avances tecnológicos, hoy el gran volumen de información “nace de forma digital”. Al ritmo actual de compresión y depuración automática de datos, el costo de almacenar un petabyte al final de la década será menor a cinco dólares estadounidenses.

El “valor” de la información será mayor que el “costo” de almacenarlo.

Las implicaciones son enormes. Todos debemos estar entusiasmados con las nuevas oportunidades que se abren:

Mashup de datos. La capacidad de mejorar el diagnóstico médico ANTES de llegar a la sala de urgencias se está volviendo una realidad en los países desarrollados y no me refiero a temas altamente relacionados con la privacidad como los productos que compramos en el supermercado y hábitos de ejercicio que podrían ser extraídos de nuestra “estela” transaccional, o el almacenamiento del registro médico en la nube. Expongo un ejemplo: Con los sensores de ubicación de las ambulancias “unido” a los patrones de tránsito en las ciudades es posible optimizar el movimiento para atender urgencias.

Enriquecimiento de información. Hasta hoy, la “inteligencia de negocios” se ha centrado al interior de la organización, pero la capacidad de conectar los datos con el resto de los que existen en el mundo abre nuevas puertas a realizar preguntas más sofisticadas, que antes era imposible contestar. Seguramente veremos el nacimiento de “mercados de datos” privados como una primer etapa y la creación de un nuevo ecosistema de datos públicos enriquecidos. RealtyTrac es un ejemplo real de empresa que revende información pública enriquecida por analistas financieros sobre compra de propiedades.

Nuevas posibilidades. Para generar más utilidades, un analista desea poner a prueba un nuevo modelo con datos históricos de la bolsa de valores. Para que el modelo funcione es necesario analizar épocas de auge y de crisis, digamos 30 años. Se desea incluir mercados internacionales y por supuesto, tomar la fuente con actualizaciones en tiempo real. Hasta recientemente esto era viable para organizaciones con recursos de cómputo masivos. Con tecnologías como Hadoop para Windows y el conector Hive de Excel, hoy esto es mucho más accesible.

El diluvio de datos se tendrá que enfrentar con nuevas herramientas interactivas para “explorar” cantidades masivas de información, la visualización continuará siendo muy relevante. Las plataformas de datos tendrán que evolucionar para administrar cualquier tipo de datos, gigantes o pequeños, desde cualquier lugar. La información deberá ser consumida desde cualquier dispositivo portátil y en un contexto que haga sentido al usuario. Los metadatos son fundamentales para habilitar los mercados de datos descritos.

Big Data se refiere al procesamiento de información no estructurada (video, audio) o semi-estructurada (bitácoras del web). Es tal la cantidad de datos que es impensable que un humano pueda realizar el análisis, por lo que el “aprendizaje basado en máquinas” será fundamental.

En el “nuevo mundo de datos” hay una variedad de nuevas tecnologías. Por ejemplo, hoy en día la respuesta a una búsqueda en sitios de búsqueda como Bing es distinta para cada usuario, las recomendaciones son específicas para el usuario de entre millones de combinaciones. Mediante Bing será posible extender aplicaciones de negocio, por ejemplo “obtener el sentimiento de medios sociales” de un producto en una zona geográfica. IntoNow me parece un interesante ejemplo del nuevo conjunto de tecnologías que hacen posible la magia de mejorar en tiempo real nuestro entendimiento. Sugiero leer http://swgu.ru/sg3408

En los años por delante, un área de gran acción será la de “los datos como plataforma” y tecnologías asociadas. Aunque la privacidad de datos continuará siendo tema de discusión, eventualmente las empresas explorarán la venta de datos. Emprendamos pues una conversación al rumbo de la auténtica economía de la información.

Bio

Luis Daniel Soto Maldonado es Director de Technical Product Management para SQL Server en Microsoft Corporation. @luisdans

Líneas de Productos de Software

Anonymous — Wed, 30 Nov 2011 22:54:18 +0000

Líneas de Productos de Software Anonymous Wed, 11/30/2011 - 16:54

Publicado en

SG #34

Arquitectura

Autor

Humberto Cervantes

La arquitectura de software es el resultado de un esfuerzo importante y su desarrollo puede representar una parte considerable del trabajo que se realiza en un proyecto de desarrollo. De lo anterior surge la pregunta, ¿habrá manera de aprovechar el esfuerzo que se hace respecto al desarrollo de la arquitectura de un sistema en el desarrollo de otros sistemas similares? Las líneas de productos de software buscan justamente lograr promover la reutilización sistemática de artefactos de los cuales la arquitectura es uno de los más importantes. Este enfoque busca tener distintos beneficios asociados a la reutilización como pueden ser la reducción del tiempo de desarrollo (pues ya no se tienen que desarrollar ciertas partes del sistema), y la mejora de la calidad (pues se incorporan partes que ya han sido verificadas previamente). En esta ocasión hablaremos al respecto de éste tema.

Reutilización

En el desarrollo de software, la reutilización se refiere a tomar uno o más artefactos realizados como parte de un desarrollo y utilizarlos nuevamente en el desarrollo de otro sistema. La reutilización no es un concepto nuevo y a lo largo de la historia del desarrollo de sistemas, han aparecido distintas técnicas que han facilitado de alguna manera la reutilización de artefactos de desarrollo de granularidad cada vez mayor, como lo muestra la figura 1:

Aún con las técnicas antes mencionadas, de manera general, la reutilización frecuentemente se realiza de manera oportunista, esto es que si durante el desarrollo los miembros del equipo de desarrollo ven la posibilidad de reutilizar algún artefacto entonces lo hacen, pero eso no ocurre de manera sistemática. Dada su naturaleza, la reutilización oportunista presenta beneficios muy variables, pues todo depende de que en un momento dado se identifiquen posibles artefactos que puedan ser reutilizados. A nivel de una organización, lo deseable es lograr un enfoque de reutilización sistemática con el fin de lograr diversos beneficios asociados con retomar artefactos previamente construidos en cada desarrollo nuevo que se realiza.

Líneas de productos

El concepto de líneas de productos busca justamente lograr un enfoque de reutilización sistemático dentro de una organización de desarrollo. Éste es un concepto que se originó, y que se usa frecuentemente, en industrias distintas al software. En la industria automotriz, por ejemplo, es común que un fabricante produzca distintas variantes de un vehículo (o productos) a partir de una base común que se reutiliza en todas estas variantes.

De acuerdo al SEI (Software Engineer Institute), una línea de productos de software se refiere a un conjunto de sistemas de software que comparten características y que son desarrollados a partir de un conjunto común de bienes núcleo (core assets). De la anterior definición es importante subrayar que los productos dentro de la línea de productos son los distintos sistemas y que los bienes núcleo son las partes reutilizables que permitirán desarrollar los productos. Los bienes núcleo son la base de la línea de productos e incluyen entre otros la arquitectura, componentes reutilizables, modelos de dominio, requerimientos, documentación, planes de prueba, etc. Un aspecto importante a considerar dentro de la línea de productos es que se debe establecer un alcance en donde se describe qué productos son parte de la línea.

Actividades del desarrollo de líneas de producto

También de acuerdo al SEI, el desarrollo de líneas de productos involucra tres actividades principales: el desarrollo de los bienes núcleo, el desarrollo de los productos y la administración, y estas actividades están íntimamente ligadas entre ellas, como se muestra en la figura 2:

A continuación se describen estas actividades en mayor detalle:

El desarrollo de bienes núcleo se refiere al establecimiento de las partes que serán reutilizadas. Cada uno de estos bienes debe ir acompañado de un proceso que explique la manera en que cada parte se usa al momento de incorporarla en un producto específico. Por otra parte, se establecen planes de producción que describen la manera en que los productos específicos son generados a partir de los bienes núcleo.
El desarrollo de productos cubre el objetivo último de la línea de producto: producir sistemas específicos dentro del alcance definido a partir de los bienes núcleo. Los insumos para esta actividad son los bienes núcleo, los procesos asociados a los bienes, los planes de producción y los requerimientos específicos a cada producto.
La administración juega un papel fundamental en la implantación de una línea de productos. La administración ocurre a un nivel técnico y organizacional. A nivel técnico, cubre tanto la supervisión del desarrollo de bienes núcleo como de productos específicos. A nivel organizacional orquesta el esfuerzo general de la línea de productos.

Arquitectura y líneas de producto

La arquitectura es un elemento clave dentro de la colección de bienes núcleo pues será compartida por los distintos productos de una línea particular. La arquitectura de una línea de productos es distinta a una arquitectura ‘típica’ pues para permitir la construcción de distintos productos por encima de ella, debe definirse una serie de puntos de variación que son necesarios para poder crear los distintos productos. En este tipo de arquitecturas, uno de los atributos de calidad más influyentes es entonces el que sea modificable.

Un ejemplo

Un ejemplo práctico de línea de productos puede observarse en la plataforma Eclipse que sirve de base al popular entorno de desarrollo (IDE) del mismo nombre (http://www.eclipse.org/pla- tform/). La plataforma Eclipse está basada en una arquitectura extensible a base de plug-ins y la plataforma establece una serie de puntos de extensión en los cuales se conectan dichos plug-ins. Los puntos de extensión que provee la plataforma representan los puntos de variación de la arquitectura. Los bienes núcleo son los distintos elementos que conforman a la plataforma Eclipse y son retomados para construir una gran variedad de productos específicos. Los productos específicos se construyen a partir de plug-ins que son conectados a la plataforma. Un aspecto interesante de Eclipse es que los plug-ins pueden, a su vez, definir puntos de extensión por lo cual un producto específico, conformado por la plataforma Eclipse y una serie de plug-ins, puede volverse a su vez un conjunto de bienes núcleo para una línea de productos más especializada. Un ejemplo de esto se puede observar en un producto como EclipseUML, una herramienta UML construida por encima de la plataforma Eclipse (http://www.ejb3.org/). De la línea de producto particular de EclipseUML se derivan dos productos específicos: el “Viewer” y el Editor. La parte administrativa de la línea de producto que establece la plataforma Eclipse se puede apreciar en la administración individual tanto del proyecto, que corresponde al desarrollo de la plataforma Eclipse, como la administración de los productos específicos que se producen por encima de la plataforma. La enorme variedad de aplicaciones sofisticadas construidas sobre la plataforma Eclipse que existen hoy en día sirven de testimonio del éxito de este enfoque.

En conclusión

En Ingeniería de Software frecuentemente se habla de reutilización y los avances tecnológicos de las últimas décadas indudablemente han logrado que hoy en día se reutilicen partes con un nivel de granularidad cada vez mayor. Lograr realizar una reutilización sistemática dentro de una organización requiere un enfoque específico y es ahí donde las líneas de productos pueden ser de mucha ayuda. La implantación de un esquema de línea de productos dentro de una organización requiere de un esfuerzo importante, sin embargo los beneficios que puede aportar pueden hacer que realmente valga la pena.

Un aspecto central de las líneas de productos es la arquitectura que soporta los distintos productos y ésta debe ser realizada tomando en cuenta las posibles variaciones que permitirán generar los productos específicos. Por último, es importante recalcar que al desarrollar una arquitectura para una línea de producto, es muy conveniente aplicar todas las actividades de desarrollo de arquitectura que hemos tratado en ediciones previas de ésta columna.

Referencias

P. Clements y L. Northrop, “Software Product Lines: Practices and Patterns”, SEI Series in Software Engineering, 2002.

Bio

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

Estimación de Costos

hmcuesta — Wed, 30 Nov 2011 21:49:21 +0000

Estimación de Costos hmcuesta Wed, 11/30/2011 - 15:49

Publicado en

SG #34

Gestión de Proyectos

El Cliente dice: “¡Te damos tiempos límite razonables! ¿Por qué no puedes cumplirlos?”

Ese argumento es muy común en el desarrollo de software y el hecho de fijar la fecha de entrega antes de establecer los requisitos, es el problema más antiguo de la ingeniería de software, pero si ya estamos conscientes de todo esto ¿por qué la improvisación parece ser el estándar? y ¿por qué no se tienen procesos de estimación bien definidos?
Hoy en día existen diversas herramientas y metodologías que nos permiten estimar costos como SPR KnowledgePlan de Capers Jones o COCOMO II de Barry Boehm, por comentar algunos. Sin embargo fenómenos como el “Proyecto interminable” y la “Marcha de la muerte” siguen siendo comunes en muchos desarrollos. Existen muchos factores que afectan las estimaciones de costo como:

Incertidumbre en los requerimientos.
Términos contractuales rígidos.
Salud financiera (ganar licitaciones sacrificando costo y tiempo).
Falta de experiencia con “X” tecnología.

No existe una forma simple de calcular el esfuerzo requerido para desarrollar un proyecto de software. Las estimaciones iniciales se hacen bajo la base a la definición de requisitos que el cliente provee a un alto nivel (funcionalidades o pantallas). Los pasos típicos en una estimación son:

Análisis de los requisitos.
Predicción del tamaño.
Descripción de las Actividades.
Estimación de fallas potenciales y métodos de eliminación de defectos en el software.
Estimación de requisitos del personal.
Ajuste de suposiciones basadas en capacidades y experiencia.
Estimación del esfuerzo y fechas límite.
Estimación de costos del desarrollo.
Estimación de costos de mantenimiento y mejora.

A medida de que los proyectos de software aumentan en complejidad, se observa que no existe una relación simple entre el precio de software al cliente y los costos involucrados en el desarrollo, así como la falsa creencia que hay una relación entre el número de desarrolladores contra el número de funcionalidades del proyecto. Por eso y para facilitar el proceso de estimación se han establecido a lo largo del tiempo, métricas que ayudan a dar una idea aproximada del tamaño del software:

Medidas relacionadas con el tamaño del código ( LOC - Lines of code). Esta forma de medir el tamaño de un software era utilizado cuando los lenguajes de programación, patrones de desarrollo y entornos de desarrollo (IDE), no estaban ampliamente desarrollados. Hoy en día es impráctico tratar de estimar el software a través de sus líneas de código ya que depende de la experiencia de los programadores o si hablamos de lenguajes de programación dinámicos como Ruby, Scala y Groovy o herramientas e IDEs que facilitan gran parte del trabajo de programación.

Medidas relacionadas con la función (UFC – Puntos de Función). El total de puntos de función no es una característica simple sino que es una combinación de características del software a las cuales se les asigna un valor que cambia dependiendo de su complejidad.UFC es igual a la suma de los “n” elementos evaluados por el peso asignado al tipo de función.
Sin embargo a lo largo del proyecto las funciones cambian, las métricas de puntos de función tienen en cuenta esto y multiplican los UFC iniciales por un factor de complejidad (asignándoles un factor de peso que va desde 3 a 15 puntos). Una desventaja de los puntos de función se presenta cuando el sistema está orientado por eventos. Por eso algunos autores piensan que UFC no es muy útil para medir productividad.

Los Puntos de Objeto (PO). Los PO se utilizan en el modelo de estimación Cocomo II con el nombre de Puntos de Aplicación. Estos son una alternativa a los UFC, y son usados en los lenguajes orientados a objetos y de scripts. Dan valor a cada pantalla dependiendo de su complejidad: simples = 1, medianamente complejas = 2, muy complejas = 3. Los reportes van de 2 a 8 dependiendo del nivel de complejidad, y los módulos en lenguaje imperativo como Java o C++ se contabilizan como 10. Esto puede ser relacionado directamente a las historias de usuario de algunas metodologías agiles con lo cual facilita la estimación de la iteración.

Modelo Constructivo de Costo: COCOMO II

Uno de los modelos de estimación más usados es COCOMO (Constructive Cost Model) creado por el Dr. Barry Boehm. COCOMO apareció por primera vez en su libro Software Engineering Economics [1] en 1981. En 1999 se definió la segunda versión del modelo que toma en cuenta el proyecto, el producto, el hardware y la experiencia del equipo de desarrollo en sus fórmulas de estimación de costo, incluyendo mecanismos de predicción de tiempo.

Cocomo II provee niveles que nos permiten hacer estimaciones en diferentes momentos del desarrollo ya que la estimación de costos debe de ser un proceso dinámico a lo largo del desarrollo, actualizando constantemente las variables, la evolución del equipo de desarrollo, las herramientas y lenguajes involucrados. Los distintos niveles son:

Construcción de prototipos. Las estimaciones de tamaño están basadas en puntos de aplicación con base en componentes reutilizables, prototipos y la fórmula para estimar el esfuerzo requerido es muy simple: tamaño / productividad.

Diseño inicial. Está basado en los requerimientos originales del sistema a un alto nivel (pantallas, reportes, procesos, transacciones) lo que son traducidos a puntos de aplicación, esto nos sirve para hacer una predicción temprana del costo.

Reutilización. Este nivel se utiliza para calcular el esfuerzo requerido para integrar el código generado por los IDE’s o herramientas de generación de código reutilizable como Spring Roo o Genexus por ejemplo, tomando en cuenta componentes reutilizables que facilitan el desarrollo como Apache Commons.

Post-arquitectura. Ya diseñado el sistema se pueden hacer estimaciones más precisas del tamaño del software, aquí es importante señalar que el software tiene una tasa de crecimiento de los requerimientos del sistema entre el 2 y el 5 por ciento mensual, por lo cual no es posible hacer una estimación exacta pero las predicciones de costo se pueden acercar mucho a la realidad gracias a la aplicación de métricas que nos permiten tener una variación muy pequeña con respecto al producto final.

Cocomo está basado en fórmulas para hacer las estimaciones, véase la figura 1 donde se estima el esfuerzo del personal por mes (PM), después se hace la estimación del tamaño del proyecto (SIZE) y finalmente se obtiene una proyección del esfuerzo requerido (B) contemplando los factores involucrados (SF).

Obviamente el realizar los cálculos manualmente es una tarea lenta y tediosa por lo cual existen muchas aplicaciones que se encargan de realizar todas las fórmulas, como USC COCOMO II que es la aplicación de la página oficial de COCOMO. Podemos descargar gratuitamente el software en http://swgu.ru/sg3414

Conclusión

La estimación de costos es una actividad muy importante en el desarrollo de software. Esta actividad no es estática sino que cambia en diferentes puntos del ciclo de vida del desarrollo.

Se tienen que hacer estimaciones desde diferentes puntos de vista, desde la predicción de costos hasta la retrospectiva de comportamiento del costo, para lo cual las herramientas de estimación nos ayudan a agilizar la tarea. Sin duda el poder hacer predicciones con respecto al costo del software nos da ventajas que facilitan el éxito de un proyecto, sin embargo esto no debe de ser exhaustivo ya que se tienen variables que el modelo no contempla totalmente como la incertidumbre, la complejidad o factores humanos de los cuales no se puede tener control, por lo cual se deben tomar en cuenta los riesgos del proceso de desarrollo de software.

Una de las ventajas de COCOMO es el poder medir el comportamiento de costo de un proyecto de software de forma interna para la empresa de desarrollo. Lo que nos permite tener un referente en diferentes puntos del proyecto y así poder comprobar que las proyecciones de costo originales se cumplan.

Referencias
[1] B. Boehm. “Software Engineering Economics”. Prentice Hall, 1981.
[2] C. Jones. “Estimating Software Costs”. McGraw-Hill, 2007.
[3] “COCOMO II Model Definition Manual”. Center for Software Engineering, USC.
[4] B. Boehm, C. Abts, et al. “Software Cost Estimation with COCOMO II”. Prentice Hall, 2000.

Bio

Héctor Cuesta-Arvizu es Lic. en Informática y actualmente cursa la maestría en ciencias de la computación en la UAEM Texcoco. Cuenta con seis años de experiencia desarrollando y administrando proyectos de software en el ámbito de manufactura y recursos humanos. Adicionalmente se desempeña como instructor de TI para Nyce en el área de base de datos e ingeniería de software. @hmcuesta

M. en C. José Sergio Ruíz Castilla es Profesor Investigador de la Universidad Autónoma del Estado de México, estudia el Doctorado en Ingeniería de Software y trabaja en proyectos de Ingeniería de Software y Sistemas de Gestión del Conocimiento.

La Navegación y los Esquemas de Organización de la Información

Anonymous — Wed, 30 Nov 2011 20:17:36 +0000

La Navegación y los Esquemas de Organización de la Información Anonymous Wed, 11/30/2011 - 14:17

Publicado en

SG #34

Usabilidad

La definición de una arquitectura de información sólida es quizá el paso más importante a realizar en cualquier proyecto. Una vez que ha sido establecida, es momento de pasar a otros aspectos estructurales como lo son la navegación y la organización de la información, dos factores muy importantes de los cuales dependerá el que la arquitectura previamente definida sea asimilada por el usuario.

La arquitectura establecida ya define las principales rutas de navegación que se manejarán, mas no define la manera en la que estas serán presentadas para el usuario. También es importante mantener en mente que no existe una única manera de llegar a un destino dentro del proyecto, sobre todo si su contenido es de alta relevancia.

Organización del contenido

Antes de comenzar a pensar en los tipos de navegación y en las presentaciones de los mismos, es necesario establecer los esquemas para organizar el contenido que, aunque puede no estar completado en su totalidad, ya fue definido de manera general en la arquitectura de información.

El mayor seccionamiento de la información se lleva a cabo por medio de esquemas de navegación subjetivos, los cuales dependen de la índole del proyecto. Uno de estos esquemas comprende una organización por temas o categorías definidos con base en características o clasificaciones en común del contenido. Un ejemplo claro de este esquema es prácticamente cualquier sitio web de comercio electrónico asociado a una tienda departamental. La amplia gama de productos es clasificada por categorías (libros, discos, ropa, acceso- rios, entre otros).

Otra manera de organizar contenido es por tareas, es decir, actividades posibles a realizar por el usuario dentro del sistema. Google Docs, la aplicación web de manejo de documentos auspiciada por Google, tiene un menú de opciones dividiendo la creación de los diferentes tipos de documentos existentes (crear hoja de estilo, crear documento de texto, entre otros).

Sin embargo, y aunque los métodos anteriores son de gran utilidad, también es importante tener en cuenta que la presentación de la información (sobre todo en web, donde la atención del usuario es limitada) debe seguir un flujo común al usuario, de modo que este encuentre lo que busca con el menor esfuerzo posible. Este método de organización es el de flujo conversacional que se asegura de que la información se presente respondiendo a tiempo las preguntas que el usuario puede ir generando a través de su experiencia.

El sitio de Mint.com lleva a cabo esta clasificación de manera muy efectiva. Al entrar al sitio, la primera opción del menú responde a una pregunta que cualquier lector que no haya escuchado hablar de Mint antes debe estar haciéndose en este momento, y está etiquetada como tal: ¿Qué es Mint? Una vez que ya se conoce esto, la siguiente interrogante es ¿Cómo funciona?, la cual corresponde a la segunda opción del menú.

Existen otras maneras de clasificar la información cuando se manejan grandes volúmenes de la misma, las cuales resultan más objetivas. El esquema alfabético, por ejemplo, debe ser utilizado con cuidado pues no siempre resulta efectivo. Funciona cuando, por ejemplo, se presenta un listado de autores de novelas mas no funciona para un listado de países de nacionalidad de un usuario, puesto que un estudio de mercado podría arrojar que el mayor porcentaje de usuarios es proveniente de México y por ello poner este país al principio resultaría más congruente. Otro ejemplo de organización objetiva es el esquema cronológico, utilizado comúnmente para archivar los artículos de un blog, presentados por orden de publicación del más reciente al más antiguo.

Los distintos tipos de navegación
Trabajando en conjunto con los esquemas de organización de la información, existen distintas maneras de manejar la navegación dentro de un proyecto de desarrollo, considerando la relevancia de los destinos comprendidos por cada sistema de navegación a utilizar.

En primera instancia está el sistema global de navegación, el cual no solo es el más relevante si no también el más sencillo de comprender. Esta navegación incluye las ligas que estarán presentes en todas las páginas o pantallas dentro de nuestro proyecto. Por esta razón se encuentra siempre claramente separado del resto del contenido, formando parte de la plantilla general del diseño de las pantallas.

Adicionalmente está el sistema de navegación local, el cual también suele formar parte de la plantilla de diseño (es decir, visualmente separado del contenido cambiante de la página o pantalla), pero las ligas que lo conforman varían dependiendo de la sección. Ilustrando este punto, las opciones locales dentro de la sección de ¿Quiénes Somos? dentro de un sitio web (Historia, Visión, Misión, entre otras similares) no serán las mismas que aquellas de la sección de ¿Qué Hacemos? (Proceso, Metodología, Herramientas, entre otras).

Es importante definir qué secciones necesitarán manejar navegación local por su comple- jidad o robustez y qué ligas comprenderá esta navegación en cada una de ellas.

Otro sistema de navegación de apoyo es el sistema de navegación de cortesía, cuya representación es fácil de localizar dentro de los sitios web existentes en la actualidad. Se trata del conjunto de ligas que aparece en la parte inferior de todas las pantallas, comúnmente fijo en todo el sitio al igual que la navegación global. Comprende ligas a información adicional o ‘de cortesía’ como lo son los términos y condiciones de uso, contacto de la empresa, avisos legales, etcétera.

Por otra parte, todas las ligas dentro del resto del contenido (entre los párrafos, botones, etc.) forman parte del sistema de navegación contextual. Y existen también los sistemas de navegación adicionales, que proveen alternativas organizacionales del contenido de un proyecto. Estos son los mapas de sitio, los glosarios y los índices de conceptos, dependiendo del tipo de contenido que se esté manejando.

Posteriormente, al avanzar más en el proceso de diseño de una interfaz, la navegación traerá a la mesa consideraciones que involucrarán principalmente la correcta aplicación de la primera heurística de Nielsen que tiene que ver con la visibilidad de estado del sistema: en todo momento, el usuario debe tener muy claro qué camino fue el que siguió para llegar hasta donde se encuentra y saber exactamente dónde se encuentra.

Resumiendo

Existen muchos argumentos que ayudarían a resumir la importancia real de tener un buen diseño de navegación, pero quizá uno de los más efectivos se resume en una actualización reciente de Twitter del consultor estadounidense Jared M. Spool:

“A veces los sistemas de navegación son como los armarios. Hay cosas colgando dentro que no nos sirven y nunca encontramos lo que estamos buscando.”

Lo principal de trabajar a conciencia en el diseño de la navegación de un proyecto es, precisamente, hacer todo lo posible por no terminar diseñando un armario convencional.

Bio

Pamela Rodríguez 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

Capital Humano en Software

pedrogk — Wed, 30 Nov 2011 18:36:59 +0000

Capital Humano en Software pedrogk Wed, 11/30/2011 - 12:36

Publicado en

SG #34

Carrera

En SG tenemos ya 7 años contribuyendo al desarrollo de capital humano de software por medio de la revista, eventos y SG Campus. Conforme estuvimos desarrollando nuestro nuevo servicio llamado SG Talento, he estado reflexionando sobre este tema y considero pertinente compartir con ustedes algunas perspectivas. Las he dividido en secciones dependiendo de a quién van dirigidas.

Profesionistas
La revaloración del desarrollador
Tradicionalmente en nuestra región los desarrolladores han sido obligados a moverse a otros roles para poder mejorar su compensación económica. Todos hemos conocido excelentes programadores que se hicieron malos gerentes. Sin embargo, hoy la profesión del desarrollador se está revalorando y cada vez más los desarrolladores se pueden mantener en su rol sin necesidad de renunciar a sus expectativas económicas. Para crecer no necesitan cambiar de rol, sino ser mejores desarrolladores profundizando sus conocimientos, aprendiendo nuevas herramientas e incorporando una mayor variedad de skills (por ejemplo DevOps). Uno de los factores que ha contribuido a esta tendencia es el renacimiento de los lenguajes de programación, sobre el cual reportamos en la edición de Mayo 2008 de SG. Otro factor es la popularidad de los métodos ágiles, donde la estructura organizacional es más plana y por lo tanto los miembros del equipo tienen mayor responsabilidad y visibilidad.

Desarrolladores independientes
Otra tendencia es la creciente inclinación de los profesionistas por ser independientes. Antes, freelancer era sinónimo de desempleado. Hoy cada vez me encuentro con más personas que son independientes no por necesidad sino por elección, porque quieren poder escoger los proyectos, clientes, tecnologías, tiempos y tarifas con los que trabajan. Si te interesa tomar este camino debes construir una buena reputación. Algunas formas de lograr esto incluyen escribir artículos (ya sea para alguna publicación externa o tu propio blog), participar en foros especializados y participar en proyectos de software libre (o crear el tuyo propio). Adicionalmente, github cada vez se posiciona más como herramienta no solo para guardar sino para “presumir” tu código.

Estudiantes
El valor de la educación universitaria
¿Para qué estudiar? Después de todo ni Steve Jobs, ni Bill Gates ni Mark Zuckerberg terminaron la escuela.

Mi recomendación es que si tienes la posibilidad de estudiar una carrera universitaria –sin endeudarte significativamente–, lo hagas. El periodo universitario es una experiencia formativa en muchos sentidos más allá de los “conocimientos duros”. Una buena educación universitaria te ayudará a conocerte mejor a ti mismo, relacionarte con otras personas, y sobre todo te enseñará a aprender. Lo más importante no son los conocimientos duros que obtengas, sino el desarrollar la habilidad de aprender.

En el caso de países como Estados Unidos donde el costo de una carrera de cuatro años fácilmente supera los 150 mil dólares en colegiatura, es comprensible que cada vez sea más popular la recomendación de no estudiar y mejor utilizar ese dinero para emprender. Incluso, Peter Thiel está dando 100 mil dólares a jóvenes para que dejen la escuela [1]. Pero en el caso de países como México donde el costo de la educación universitaria es mucho menor, recomiendo que si tienes la posibilidad de estudiar, no la desaproveches.

En el caso particular de México hay otro beneficio de graduarte de una carrera universitaria: la visa TN. Esta es una visa de trabajo temporal en Estados Unidos especial para ciudadanos mexicanos que se desempeñan en profesiones especializadas. Es la forma más rápida y sencilla de conseguir visa de trabajo en EU, pero requiere que estés titulado y tengas tu cédula profesional.

Conocimientos requeridos
Una queja común de los alumnos es que en sus universidades les enseñan tecnologías muy viejas. Yo creo que en la universidad es más importante que aprendas bien los principios a que aprendas las tecnologías más modernas. Por ejemplo, si te enseñan Lisp, que es un lenguaje de 1958, te permitirá entender la programación funcional y así utilizar bien lenguajes modernos como Clojure o F#.

Habiendo dicho esto, es necesario que sí conozcas lenguajes y tecnologías modernas, ya que cuando busques trabajo dudo mucho que les interese que sepas Lisp. Mi recomendación de los 10 lenguajes/tecnologías que un buen desarrollador debe conocer actualmente son: Python, C#, Scala, Javascript, Node, HTML5+CSS3, git, gradle, NoSQL (Couch o Mongo), Hadoop. Lo más probable es que en la escuela te enseñen muy poco, o nada de ellos, así que tú tendrás que aprenderlos por tu lado. No te preocupes, si entiendes los principios será fácil. Adicionalmente, tu conocimiento con estas tecnologías debe ser comprobable con aplicaciones publicadas en algún lado. Ya te darás cuenta de que tener una aplicación publicada en un app store te servirá mucho más para conseguir empleo que un 10 final en el curso de compiladores.

¿Y entonces para qué aprender algebra lineal o compiladores, si no sirven para conseguir empleo? Los aprendes por dos razones: 1) Para desarrollar tu cerebro, y 2) Porque aunque lo más probable es que no te ayudarán a conseguir tu primer empleo, definitivamente son herramientas que te ayudarán a hacer mejor las cosas y por lo tanto potenciarán tu carrera profesional.

Universidades
Prepara ingenieros de software, no IT Pros
Un problema común que encuentro en los planes de estudio de las universidades en nuestra región es que están orientados a formar “técnicos en informática” (IT Pros) en lugar de ingenieros de software. El trabajo del IT Pro consiste en administrar infraestructura de TI tal como computadoras y redes; pero su preparación dista mucho de lo que se requiere para desarrollar software profesionalmente, y es para esto último para lo que hay trabajo. Entonces, no es ninguna sorpresa que anualmente miles de graduados salen a buscar trabajo y se dan cuenta que no saben hacer lo que la industria demanda: desarrollar aplicaciones.

Recomiendo a las universidades que busquen formar ingenieros de software a que obliguen a sus alumnos a desarrollar aplicaciones desde los primeros semestres. Existen universidades donde se pasan 4 años estudiando teoría pero sin haber construido una aplicación de software de principio a fin. Creo que es mucho mejor que los alumnos comiencen a desarrollar aplicaciones completas (sencillas, pero completas) desde los primeros semestres y conforme vayan avanzando en su carrera vayan aprendiendo aspectos como configuration management, testing, distintos paradigmas de programación, que apliquen en sus proyectos para hacer mejor software. El objetivo es que cuando se gradúen lleven 4 años desarrollando software, no 4 años estudiando técnicas que nunca han aplicado.

Empresas
Como bien comenta Erick Camacho en su post “¿Y donde está el talento?”[2], los desarrolladores de software experimentados no están buscando ofertas de empleo en bolsas de trabajo. Las bolsas de trabajo tradicionales son un buen mecanismo para promover posiciones “entry level” donde buscas recién graduados, o personas que buscan un cambio de carrera, pero si buscas perfiles con mayor especialización, debes utilizar otras herramientas.

Menos tweets y más branding
No importa cuantos tweets envíes con “urge” y “please RT”, si tu empresa no tiene un “buen nombre” entre los profesionistas de software no vas a atraer talento. Y si logras atraer talento, solo lo vas a lograr a billetazos, y así como llegó, se va a ir al próximo mejor postor.

Una de las cosas que puedes hacer para mejorar tu branding hacia desarrolladores es participar en eventos dirigidos a esta audiencia. Dependiendo del tipo de evento, así como presupuesto que tengas, hay distintas opciones desde poner un stand hasta patrocinar las cervezas o rifar libros.

Algo más que te recomiendo es fomentar que tus empleados compartan conocimiento con el exterior, ya sea escribiendo artículos, dando pláticas en eventos, o simplemente blogueando. No se trata de que explícitamente promuevan tu empresa, sino que compartan con colegas conocimiento técnico adquirido en proyectos reales de la empresa. El efecto que buscas es que la gente piense “aquí hacen proyectos interesantes y valoran el talento.”

Alimenta la curiosidad de tus devs
Los desarrolladores son curiosos por naturaleza. Si no dejas que alimenten su curiosidad, dejarán tu empresa. Hay distintas cosas que puedes hacer, por ejemplo hay empresas donde por política los empleados deben dedicar cierto porcentaje de su tiempo a actividades que no estén relacionadas con el proyecto al que están asignados. Otra práctica que un colega de India me comentó que aplicaban en su empresa era que las personas no podían durar más de 12 meses en el mismo proyecto, y que al terminar un proyecto debían tomar 2 semanas de entrenamiento en nuevas tecnologías antes de entrar a un nuevo proyecto. Otra posibilidad es la de “donar” tiempo de nuestros empleados para participar en proyectos de software libre. De esta forma, pueden estar dedicando tiempo a algo que los apasione, al mismo tiempo que aprenden, contribuyen a la comunidad y dan un buen nombre a tu empresa.

Sé Flexibe
Los profesionistas cada vez valoran más su libertad, incluso sobre el dinero. Un estudio recientemente realizado por Cisco [3] entre estudiantes y jóvenes profesionistas arrojó que este segmento valora la libertad más que el salario. ¿Libertad de qué? Principalmente la libertad de usar redes sociales, escoger tu computadora/teléfono o de trabajar fuera de la oficina.

Conclusión
La situación no es sencilla. El reto de los candidatos es desarrollar los conocimientos prácticos que busca la industria, sin descuidar las habilidades y aptitudes fundamentales que lo ayudarán a ser un mejor profesionista a lo largo de su carrera. Por su parte, las empresas requieren poder atraer y retener al capital humano que necesitan, y para ello necesitan cambiar muchas de sus prácticas actuales de RH.

En SG estamos conscientes de las necesidades en este rubro, es por ello que creamos un nuevo servicio llamado SG Talento [4] con el que buscamos que los profesionistas de software puedan evaluar y reflejar sus habilidades de forma sencilla, facilitando así a los reclutadores encontrar el talento que buscan.

Referencias
[1] S. Ludwig. “Peter Thiel pays kids to drop out of college”,Venture Beat.
[2] E. Camacho. “¿Y dónde está el talento?”.
[3] “Cisco Connected World Technology Report”.
[4] SG Talento.

Bio

Pedro Galván Kondo (@pedrogk) es director y socio fundador de Software Guru, y es un apasionado del desarrollo de capital humano.

Conociendo a Arduino

Anonymous — Wed, 23 Nov 2011 16:56:06 +0000

Conociendo a Arduino Anonymous Wed, 11/23/2011 - 10:56

Publicado en

SG #34

Temas especiales

Arduino es una plataforma abierta para cómputo físico que se basa en hardware y software sencillo y libre. Los sistemas Arduino pueden sondear el ambiente al recibir información de una gran variedad de sensores, y pueden afectar al ambiente al controlar luces, motores u otros actores.

En este artículo veremos como se hace un “Hola Mundo” en Arduino.

El hardware

Dado que Arduino es open hardware, tú mismo puedes construir tarjetas guiándote en los esquemas de diseño, o puedes comprar tarjetas preconstruidas. Para este ejercicio nos basaremos en una tarjeta Arduino Uno, que es la más básica y se puede adquirir por alrededor de 40 dólares. La figura 1 muestra una imagen.

El software

Las tarjetas Arduino se programan en un ambiente de desarrollo (IDE) basado en el lenguaje Processing, que es un lenguaje bastante sencillo. Ya que tienes tu programa listo, el IDE lo convierte a C, compila un binario y lo carga al microprocesador. El ciclo de programación es básicamente el siguiente:

Conecta la tarjeta a tu computadora via USB
Escribe el programa en el IDE.
Envía el programa a la tarjeta y espera a que se reinicie.
La tarjeta ejecuta el programa.

El código

Nuestro hola mundo consistirá en hacer que un LED (diodo de luz) se prenda y apague. Para ello, conectamos nuestra tarjeta a la computadora, y conectamos un LED en el pin digital #13. Nota: La pata larga es el ánodo, el cual va al pin, y la pata corta es el cátodo que va a tierra.

El listado 1 muestra el código que necesitamos.

El código es bastante sencillo. Primero definimos una constante para indicar el número de pin donde tenemos el LED. Luego tenemos el método obligatorio setup() que es donde hacemos las configuraciones necesarias para ejecutar un programa. En nuestro caso, estamos indicando que queremos usar el pin 13 como salida (los pines digitales pueden usarse ya sea como entrada o salida). Posteriormente tenemos el método obligatorio loop() el cual ejecuta el ciclo maestro del programa. En nuestro ciclo lo que estamos haciendo es prender el voltaje del LED al enviarle una señal HIGH, esperar mil milisegundos, bajar el voltaje del LED al enviar una señal LOW, y esperar. Este ciclo se ejecutará de forma continua mientras el sistema se encuentre encendido.

Como has podido constatar, Arduino es muy sencillo. Te recomiendo que le hagas caso a ese gusanito curioso dentro de ti y consigas cuanto antes una tarjeta y empieces a jugar.

Generación de Modelos de Negocio

Anonymous — Wed, 23 Nov 2011 16:52:53 +0000

Generación de Modelos de Negocio Anonymous Wed, 11/23/2011 - 10:52

Publicado en

SG #34

Emprendiendo

Constantemente le pregunto a mis alumnos de la Maestría de Negocios del ITESO en Guadalajara, a los participantes del Bootcamp en TechBA Silicon Valley y en los Startup Weekends ¿qué es más importante: un excelente producto o un excelente modelo de negocio? Y normalmente llegamos a la misma conclusión, es más importante tener un buen modelo de negocio. Tal y como menciona Henry Chesbrough: “A mediocre technology pursued with a great Business Model may be more valuable that a great technology exploited via a mediocre Business Model.”

Del artículo de “Reinventing your Business Model” de Harvard Business Review [1] destacaré dos cifras que dan una idea de la importancia del concepto:

11 de las 27 compañías nacidas en los últimos 25 años y que han crecido hasta estar dentro de las Fortune 500 en los últimos diez años, lo hicieron a través de la innovación en sus modelos de negocio.
Una encuesta del 2005 practicada por la Unidad de Inteligencia de The Economist, reportó que más del 50% de los ejecutivos creen que la innovación en el Modelo de Negocio llegará a ser más importante para el éxito que la innovación en productos y servicios.

Con el propósito de generar un entendimiento común sobre el concepto de Modelo de Negocio les pido hacer una reflexión, pregunten a la gente que tengan alrededor, ¿qué es un Modelo de Negocio? Apuesto a que una gran parte de ustedes obtuvieron la siguiente respuesta… “es la manera en que hacemos dinero”. Esta respuesta es parcialmente correcta, ya que la corriente de ingresos es uno de los nueve elementos del modelo, al igual que la fórmula de rentabilidad, pero no lo es todo.

El Modelo de Negocio es cómo la compañía crea, entrega y captura valor.

Alexander Osterwalder es un renombrado consultor en innovación y modelos de negocio que se dio a la tarea de crear algo que hacía mucha falta: un texto metodológico completo sobre modelos de negocio. Es así que en 2010 en conjunto con Yves Pigneur publicó el libro “Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers” [2].

La metodología planteada por Osterwalder plantea de forma simple y puntual los elementos básicos pero suficientes para integrar el negocio. No se necesita un extenso documento con decenas o cientos de páginas que diga cómo se quieren generar los ingresos para la compañía. Debemos ser capaces de mostrar en una sola imagen todos los elementos que le dan viabilidad y sustentabilidad a nuestro negocio.

Los nueve bloques constructores

El modelo se describe a través de nueve dimensiones o bloques que muestran la lógica de cómo una compañía pretende ganar dinero y la interacción entre cada uno de los bloques. Dichos bloques se ilustran en la figura 1.

Figura 1. Los nueve bloques constructores

Obviamente, la definición de modelo tendrá que ver con la necesaria interconexión o interrelación entre todos los bloques, los cuales no se pueden ver de manera aislada; unos son consecuencia de otros y por lo tanto se trata de poder construir un flujo basado en ellos. En el centro está la propuesta de valor, hacia el lado derecho a quién se entrega y cuánto nos genera y en el lado izquierdo cómo se construye y cuánto nos cuesta.

Siguiendo la lógica anterior explicaremos brevemente a qué se refiere cada bloque.

Segmento de clientes. Este es el primero de los bloques con el cual se debe iniciar la lógica del modelo, debiendo entender cuál es el racional en base al cuál vamos a segmentar al grupo de personas u organizaciones que vamos a servir, cuál es su necesidad a satisfacer y una vez entendida, se puede diseñar el modelo de negocio.

Propuesta de valor. Describe cuál es el paquete de productos y servicios que crean valor para esos segmentos específicos de clientes. Es lo que hace a las compañías únicas y diferentes y por lo cual sus clientes van a preferirlos por sobre otras empresas. Se basa en la satisfacción de problemas o necesidades de los clientes entregándoles beneficios valiosos. Algunos de los elementos que crean valor para los clientes pueden ser la novedad, la mejora en desempeño, la individualización, el precio, la reducción de riesgos, la conveniencia, etc.

Canales. Cómo una compañía se comunica y llega a sus segmentos de clientes para entregar la propuesta de valor. Son los puntos de contacto que juegan un papel importante en la experiencia de usuario del cliente. Aquí la principal definición es si los canales serán directos o indirectos, lo que obviamente tiene una afectación en margen pero puede potenciar el alcance. El balance adecuado será el que maximice los ingresos.

Relaciones con clientes. El tipo de relaciones que se mantengan con los clientes es fundamental para la adquisición, retención y crecimiento de los clientes y obviamente tendrá una relación directa con el canal que se haya elegido.

Flujos de ingresos. Representa el efectivo que la empresa genera de cada segmento de clientes. Básicamente los ingresos pueden ser de dos tipos, transaccionales, de única ocasión, o recurrentes. Los ingresos llegarán a la compañía si esta entiende bien cuál es el valor por el cual los clientes realmente están dispuestos a pagar. Aquí encontramos varias maneras en cómo se pueden generar esos ingresos: por la venta de un producto, cobrar suscripciones, renta, licenciar propiedad intelectual, publicidad, etc.

Actividades clave. Este bloque describe las actividades más importantes que una compañía debe hacer para que su modelo de negocio funcione. Dichas actividades pueden ser divididas en producción, que tiene que ver con la entrega física de un producto; de solución de problemas o de creación de una plataforma.

Recursos clave. Este bloque incluye a los recursos o activos que se requieren para desempeñar dichas actividades clave. Los recursos pueden ser materiales, financieros, humanos y más importante aún, intelectuales como patentes, marcas, etc.

Alianzas clave. Describe la red de proveedores y socios que se requieren para que el modelo funcione adecuadamente, creando dichas alianzas sobre todo para optimizar el modelo por economías de escala, la reducción de riesgo e incertidumbre o la adquisición de recursos para el desempeño de ciertas actividades. Pueden ir desde una simple relación proveedor-comprador hasta una alianza estratégica.

Estructura de costos. Cuáles son los costos que se generan a propósito de las actividades y los recursos necesarios para desempeñarlos. Las estructuras de costos se pueden basar en dos enfoques principalmente: aquellos guiados por el costo y aquellos guiados por el valor. El primer enfoque se basa en minimizar el costo al máximo posible, mientras que el segundo se centra en el costo que sea necesario para crear el valor necesario para entregar.

La expresión gráfica del modelo se lleva a cabo en lo que se llama el Business Model Canvas que proviene y recuerda al lienzo de un pintor. Normalmente lo desarrollamos a través de talleres con expertos en los temas dentro de una empresa, y es una actividad colaborativa que busca fomentar el entendimiento, discusión, creatividad y análisis. Se puede desarrollar de manera física en un poster en donde podemos pintar o pegar notas o de manera electrónica en donde ya existe la aplicación para iPad creada por el propio Osterwalder.

Referencias

Bio

Víctor Reyes (@vmreyesp) ha tenido una trayectoria de más de 20 años en puestos gerenciales y directivos en los sectores privado y público. Es ex Director de Negocios de Innovación del CONACYT y actualmente es fundador, cofundador y/o participante activo de varias iniciativas que buscan impulsar el emprendimiento e innovación tecnológica como MexicoInnova, INPROTEC, Startup Dojo, Mexican VC, Startup Weekend, TechBA Silicon Valley.

Diseño de un Robot Compatible con RDS

Anonymous — Wed, 23 Nov 2011 16:44:11 +0000

Diseño de un Robot Compatible con RDS Anonymous Wed, 11/23/2011 - 10:44

Publicado en

SG #34

Temas especiales

Autor

Pedro Galván

Microsoft Robotics Developer Studio (RDS) es una plataforma para el desarrollo de aplicaciones robóticas. RDS provee un framework de programación, ambiente de ejecución (runtime), herramientas para creación y simulación de aplicaciones, ejemplos de código, plantillas y tutoriales entre otras cosas. En este artículo veremos los aspectos fundamentales de un robot diseñado para operar aplicaciones creadas con RDS.

Las personas que desean construir aplicaciones robóticas se en- cuentran con que existe una gran variedad de robots disponibles en el mercado, con poca estandarización entre ellos y gran variedad en capacidades y precios. Ante esta problemática, el equipo de Microsoft Robotics se dio a la tarea de definir las características esenciales de un robot que aproveche los servicios de RDS. El objetivo es que las personas puedan facilmente construir su propio robot, o que terceros construyan y vendan robots “listos para usarse”, de manera que los desarrolladores pueden concentrarse más en construir las aplicacio- nes del robot, que en construir el robot en sí. El resultado de este es- fuerzo es la “RDS Reference Platform”. Esta plataforma de referencia es una guía que describe el diseño recomendado para crear un robot “real” (es decir, un robot físico) que pueda operarse con RDS.

MARK

El diseño robótico de referencia utiliza al sensor Microsoft Kinect, el cual provee una cámara de video, sensor de profundidad 3D y micrófono. Este diseño fue bautizado como MARK (Mobile Autonomous Robot using Kinect). El diseño del MARK se basa en cuatro principios: mobilidad, autonomía, interactividad y extensibilidad.

La mobilidad es provista por una tracción diferencial, la cual es fácil de controlar y permite que el robot gire en su mismo lugar.
Para ser autónomo, el robot recurre a una computadora a bordo. Las capacidades avanzadas como visión computarizada, reconocimiento de voz, o conectividad a redes, requieren capacidad de procesamiento mucho mayor a la que proveen los mi- crocontroladores de bajo rango. Incorporar una PC en el diseño también permite comunicación inalámbrica con otras PCS y/o robots por medio de WiFi.
La interactividad considera dos aspectos: la interacción humano-robot, y la interacción del robot con el ambiente. El campo de la robótica personal tiene la necesidad de interfaces de usuario sencillas y confiables. La interactividad es facilitada por la inclusión del sensor Kinect, lo cual puede simplificar dramáticamente la programación de la interfaz de usuario, proporcionando datos 3D e información esqueletal. Los datos 3D también son muy útiles para que el robot pueda desplazarse exitosamente a través de obstáculos.
La extensibilidad es inherente al diseño de referencia ya que no especifica detalles de bajo nivel, por lo que no está restringido a una construcción en particular. Este permite que los usuarios y partners de Microsoft Robotics puedan cambiar piezas o variar el diseño siempre y cuando se respeten los aspectos fundamentales.

Arquitectura de hardware

La figura 1 muestra el ejemplo de una implementación de un robot MARK.

A continuación se describe de forma general el hardware de este robot.

Bases. Se requiere un mínimo de dos bases o plataformas en el robot. En la base inferior va el sistema de tracción y en la superior va la computadora y el Kinect. La base de mayor tamaño (típicamente la inferior) debe ser circular y ningún componente debe rebasar su circunferencia, esto permitirá que el robot pueda girar en su lugar sin golpear objetos externos. Se recomienda que las bases tengan un diámetro menor a 60 cm para que puedan pasar por las puertas de una casa. La base superior debe tener un soporte para montar la cámara del Kinect. Para maximizar el campo de visión del Kinect, la altura ideal a la que se debe montar es a 60 centímetros del suelo.

Sistema de tracción. La tracción diferencial consiste en dos ruedas cuya velocidad puede variar de manera independiente. Los motores típicamente se controlan utilizando circuitos de tipo puente H (H-brid-ge). El sistema de tracción considera: las ruedas, el eje de las ruedas, los motores que las mueven, los sensores de rotación de las ruedas (wheel encoder), los puentes H, y los accesorios de montaje. Se recomienda utilizar motores silenciosos, no solo para evitar la molestia del ruido, sino también porque afecta la capacidad de reconocimiento de voz. Dado que la tracción diferencial consiste de solamente dos ruedas, para que el robot tenga estabilidad se recomienda agregar ruedas (una al frente y otra atrás) para que den estabilidad. Estas ruedas deben ser giratorias para no obstruir el desplazamiento y rotación del robot.

Sensores de proximidad. A pesar de que podríamos utilizar el sensor de profundidad del Kinect para detectar obstáculos y evadirlos, se recomienda tener sensores de proximidad dedicados para la evasión de obstáculos. Se debe incluir al menos dos tipos distintos de sensores, ya que combinar distintos tipos incrementa la probabilidad de detectar obstáculos. Por ejemplo los sensores infrarrojos no detectan vidrio pero los de sonar sí, asímismo hay objetos que no son bien detectados por los de sonar pero sí por los infrarrojos.

Controlador de I/O. El controlador de I/O, conocido como brick (ladrillo) es una tarjeta de circuitos que actúa como interfaz entre el hardware del robot y la PC.

Sistema de energía. La energía para el robot debe ser provista por una o más baterías recargables. Se recomienda utilizar baterías de 12V tipo SLA (Sealed Lead Acid). Los componentes del robot que requieren energía incluyen: Kinect (12V a 1.1A), motores y controladores, sensores de proximidad, controlador IO. Por simplicidad, la computadora a bordo puede utilizarse con su batería por lo que no es necesario contemplarla en la lista de componentes soportados por el sistema de energía.

Arquitectura de software

La figura 2 ilustra a grandes rasgos la arquitectura de software de la plataforma de referencia del RDS.

En la capa superior tenemos servicios de alto nivel que pueden ser provistos por RDS, terceros, o creados por el desarrollador. Un servicio en esta capa que ya está incluido como parte del RDS es el Robot Dashboard, un aplicativo que funciona como consola maestra para permitir al usuario controlar al robot y consultar su estatus. Otro servicio de esta capa que ya es provisto por RDS es el de evasión de obstáculos.

Los servicios de bajo nivel son una capa de abstracción de hardware. Proveen servicios para interactuar con el hardware (Kinect, sistema de tracción, sensores) mediante el controlador de I/O. Los servicios de esta capa son programados por el fabricante del robot, o el usuario en caso de estar construyendo su propio robot.

El CCR (Concurrency and Coordination Runtime) y DSS (Decentralized Software Services) son componentes de RDS. Todos los servicios se ejecutan en el contexto de un nodo DSS, y varios nodos DSS se pueden comunicar entre sí a través de una red.

RDS está basado en .NET, el cual a su vez opera sobre el sistema operativo Windows.

En la capa más baja está el hardware. Algunos dispositivos, como el control de Xbox están directamente soportados por drivers para Windows. El controlador de I/O contiene firmware que se comunica via Windows utilizando un puerto serial, USB, red u otro medio.

Para crear aplicaciones robóticas que funcionen con RDS se requiere una computadora con el siguiente software: Windows 7 (32bit o 64bit), Visual Studio 2010 Express o superior, Kinect for Windows SDK (y prerrequisitos asociados), Robotics Developer Studio 4 (y prerrequisitos asociados).

Conclusión

Hemos visto algunos aspectos fundamentales para el diseño de un robot con RDS. Te invito a que consultes la especificación completa y que comiences a desarrollar aplicaciones robóticas. Te comento que RDS incluye una versión simulada de esta plataforma de referencia, de modo que puedes comenzar a desarrollar aplicaciones robóticas en un ambiente simulado sin necesidad de contar con el robot físico. La figura 3 muestra este ambiente de simulación.

Bio

Pedro Galván es cofundador y director editorial de SG Software Guru. De vez en cuando quiere publicar artículos sobre temas para los que no encuentra autores y no le queda otra más que escribirlos él mismo por lo que que pasa noches en vela para poder conocer lo suficiente sobre el tema para escribir dichos artículos.